とうとうIPv4アドレス在庫が枯渇しましたが、Yahoo! JAPANではそれに先立つ2009年ごろから、IPv6対応に向けた準備を進めてきました。この連載では、サービスプロバイダとしての視点から、どういった対応を進めてきたかを紹介します。(編集部)
こんにちは。ヤフーのIPv6プロジェクトスタッフの内田幸治です。前回はYahoo! JAPANのIPv6に対する取り組みや社内でのIPv6対応方法、そしてWorld IPv6 Day(以下、W6D)期間中にページが表示できなくなる人に向け、どういった対策を用意したかを紹介しました。
今回は、W6D以前から社内で実施していたIPv6対応活動の経緯に始まり、W6D前に実施したお客さまの環境調査の方法と結果、そしてW6D当日の動きについて説明します。全体的にインフラ構築の現場からの視点で解説していきます。
Yahoo! JAPAN社内におけるIPv6対応の取り組みは、IPv6に関するトピックがこれほど注目を浴びる前の2008年から、インフラ運用の部署で細々と始まりました。
当時、IPv6機能を実装しているネットワーク機器をいろいろと調査しましたが、IPv4と同等のネットワークを構築できる機器は少なかった印象があります。IPv6による通信こそ可能なものの、IPv4では当たり前に動作する機能が実装されておらず、特に冗長構成の面で不安要素が多かったと記憶しています。
例えば、ルータがIPv6に対応した時期は早かったのですが、ロードバランサ、ファイアウォール、コアスイッチなど、ネットワークインフラを構成するほかの機器となると、「冗長構成が組めない」「一部の機能がCPUリソースを極端に消費する」などの問題が発生し、IPv4と同じようには運用できないと思ったことを覚えています。
しかしながらこのような取り組みを進めていくことで、IPv4と同等の構成は難しくても、機能検証結果が一通り出そろい始めました。そして2009年4月、社内の有志エンジニアによって「IPv6プロジェクト」が結成されました。ちょうど世間でも、IPv4アドレス枯渇問題がニュース記事になるなど、話題になってきた時期のことです。
それ以降の取り組みが、前回記事の冒頭へつながることになります。
IPv6プロジェクトの取り組みの中でも興味深いのが、ユーザーのIPv6接続性調査です。
Yahoo! JAPANでは、2010年4月にIPv6接続性調査を実施しました。この時の調査では、「Yahoo! JAPANがいますぐIPv6対応した場合、お客さまの0.23%ではページが表示されないといった悪影響が出る」という結果が出ました。ただ一方で、社内インフラのIPv6対応も完全ではなかったため、お客さまへの対応よりも、まずは社内インフラのIPv6対応強化を進めることになりました。
そして2011年5月、IPv4アドレス枯渇タスクフォースの協力を得てIPv6閉域網も対象に加え、再度調査を行いました。再調査の結果では、IPv6対応時に出る悪影響は全体の0.18%となりました。
調査の詳細やその他の取り組みのいくつかは、Tech Blogで公開しています。上の結果とは異なる視点での調査分析や、実際にネットワークを構築するときに参考になるかもしれない情報も公開していますので、興味ある方はぜひご覧ください。
このブログでは例えば、
といったエントリを公開しています。
さて、ヤフーがこのような調査を進めていく中、「W6Dというものをやるらしいよ」という話が出始めます。これまで蓄積してきたさまざまな活動の結果もあって正式にW6Dへの参加が承認され、社内でも参加に向けた動きがスタートしました。
次の章では、W6D前に実施した接続性調査の詳細を説明したいと思います。
IPv6接続性調査はいったいどのように実施するかというと、まず、Webページ内にさまざまなオブジェクトを取得するJavaScriptを埋め込みます。このJavaScriptは「ビーコン」と呼ばれます。
ビーコンは、IPv6アドレスの付いたFQDNなど、さまざまなパターンのオブジェクトに対してアクセスを行い、最後に、各オブジェクトに対するアクセス成功/失敗の結果を集計サーバに送信します。その結果を解析することで、お客さまの環境でIPv6アクセスをした場合に問題が発生するかどうかを判定するわけです。
W6D前に実施したIPv6接続性調査では、前述のように、IPv4枯渇対応タスクフォースの皆さんにも協力してもらうことにより、IPv4とIPv6閉域網につながるお客さまに対する影響調査も合わせて実施することができました。以下その調査結果を説明します。
2011年5月に実施したテストのポイントは、以下の通りです。
まず、v6オブジェクトとv6tfオブジェクトに対し、ビーコン取得が成功したかどうかを調査しました。その結果は表1の通りです。
v6アクセス | v6のみOK | v6tfのみOK | v6/v6tf OK | No v6/v6tf | ヘッダ異常 |
---|---|---|---|---|---|
割合 | 4.90% | 4.46% | 0.00% | 90.63% | 0.01% |
表1 v6/v6tfオブジェクトに対するアクセスの成功/失敗の値 |
この結果は、以下のような状況を意味しています。
・v6のみOK
v6オブジェクト取得に成功し、v6tfオブジェクト取得に失敗した割合が4.90%です。
・v6tfのみOK
v6tfオブジェクト取得に成功し、v6オブジェクト取得に失敗した割合が4.90%です。
・v6/v6tf OK
v6オブジェクトとv6tfオブジェクトの両方の取得に成功した割合です。表には0.00%と記載しましたが、正確には0.0008%となります。この割合は正しくマルチホーム設定をしているホストと考えられます。
・No v6/v6tf
v6オブジェクトとv6tfオブジェクトの両方の取得に成功した割合が90.63%です。これらのホストは、IPv6アドレスのみのサーバにはアクセス困難です。
・ヘッダ異常
HTTP Hostヘッダが異常であり、v6/v6tfオブジェクトの取得判定が困難であった割合が0.01%です。まれに、一般的でないOSのブラウザでビーコン取得を行う場合、こちらに分類されてしまうことがあります。
Copyright © ITmedia, Inc. All Rights Reserved.