Tweet

少し遅くなってしまいましたが、今回は6月8日に実施された、Word IPv6 Day(以後、W6D)についての後日談を書いてみたいと思います。

W6Dの目的とISPの準備

今回のW6D、随分と注目を集めたようで、一般誌や新聞でもその話題を目にすることもありました。が、「IPv6への移行に伴い大規模障害が発生する可能性」なんて見出しで取り上げられていたりと、ちょっと変な方向に話が行ってしまった感じもありました。

今回のW6Dの目的は、「WebサーバをIPv4/IPv6両対応にしても、既存のインターネット利用に悪影響を及ぼさない」事の確認です。そのために、時間を限定して普段使っているWebサーバをIPv6での接続に対応させてみて、その時に何が起こるのか様子を観察する、という事を行いました。

IPv6対応のためには、Webサーバ管理者が次の二つの作業を行う必要があります。

• Webサーバと、サーバが接続されたネットワークをIPv6対応にする
• DNSサーバに対象サーバのAAAAレコードを登録する

この両方の条件がそろって初めて、そのWebサーバがIPv6対応になります。「サーバやネットワークだけをIPv6対応にしても、IPv6での通信は行われない」という点に注目してください。

そして、W6Dでもう一つ重要なことは、「普段使っているホスト名(FQDN)をIPv6対応にする」と言うことです。実験用のIPv6サーバを作るのではなく、普段使っているWebサーバをIPv6に対応させて初めて、実際のインターネットでの問題が洗い出されるという考えなのです。

さて、サーバがIPv6に対応したとして、クライアント(Web閲覧者のパソコン)がIPv6に対応していない場合はどうなるのでしょうか。DNSサーバにAAAAレコードが登録されていることがわかると、パソコンは優先的にIPv6を使って通信しようとします。一方、AAAAレコードがあることがわかっても、残念ながらパソコンとサーバ間のネットワークでIPv6が使えない場合は、自動的にIPv4での通信に切り替わる、フォールバックという仕組みがあるのです。このような仕組みがある為、ほとんどのケースでは利用者は自分のパソコンとネットワークでIPv6が使えるかどうかを意識する必要はありません。

しかし、実際にはいくつかのパターンでこのフォールバックが期待通りに機能しない可能性が指摘されていました。IPv6に関する仕様を適切に満たしていない機器や、通信路がある場合に、このような問題が発生する可能性があります。この問題自体は世界中で発生する可能性があったのですが、特に日本ではNTT東西のフレッツシリーズで「インターネットに繋がっていないIPv6アドレス」が使われており、これが原因でフォールバックが正しく行えず「インターネットが使えない」という問題が多発するのではないか、と考えられていました。

もちろん、日本のインターネット関係者は、問題が発生しないように事前に様々な手を打っていました。しかし、それでも大きな問題が起こってしまったらどうするのか……何しろ、W6Dは世界的な取り組みです。仮に日本で何か大きな問題が起こっていたとしても、それを理由にW6Dを中止するわけにはいきません。

そういった懸念を元に、日本のISPの中には、顧客に提供しているDNSサーバに「AAAA filter」を設定し、IPv6での通信を抑止してしまうことで問題を回避しようとしたところもありました。AAAA filterを使うとIPv6を使った通信が全く行われなくなってしまうため、W6Dというイベントで実験を行う意味が無くなってしまいます。しかし、それよりも問題が起こる可能性を重視して、混乱を回避しようという判断もあったのです。AAAA filterを採用するかどうかの判断はISPによってまちまちで、W6D開始前からAAAA filterを設定していたISPもあれば、何か問題が起きた場合にAAAA filterを設定することができるようにと準備だけしていたISPもあったようです。

ここで取り上げたAAAA filter対応を含め、各ISPはW6Dの当日に向けて技術的な手当だけでなく、お客様サポートの人員を厚くするなど、様々な備えを取ってきました。中には、当日何かがあった時に即座に意思決定ができるように、主要なスタッフをオフィスに留め置いたという話もあったようです。まるで2000年問題の対応のようだった、という声もありました。

AAAA filterとは

前述の通り、IPv6の通信が行われるためにはAAAAレコードが存在することが必要です。つまり、AAAAレコードを「なかったこと」にしてしまえば、IPv6による通信を抑止することができるのです。
DNSでは、あるドメインのオリジナルの情報を保持している「DNS権威サーバ」と、権威サーバから情報を検索するための「DNSキャッシュサーバ」があります。個人や小規模な組織ではキャッシュサーバはISPが用意しているものを使っているケースがほとんどです。
AAAA filterでは、ISPが用意しているキャッシュサーバで権威サーバが返すAAAAレコードをフィルタしてしまい、あたかも「AAAAレコードが存在しない」ように見せかけます。AAAAレコードが存在しないように見える以上、IPv6による通信は発生しません。

なお、この手法はあくまで緊急的な回避方法であり、常用すべきものではありません。

そして当日

さて、そんなことで迎えたW6D当日ですが、結論を先に書いてしまうと、事前に身構えていたほどの混乱は発生しませんでした。

全く何もなかったか、というと、やはりいくつか問題は発生しており、「DNSサーバの設定ミス」や「Path MTU Discovery問題の考慮漏れ」など、Webサーバ側の問題でサイトが閲覧できないという問題があったようです。幸いそれらの問題は局所的な範囲に収まり、当初懸念されていたような大規模な「インターネットが使えない」問題も無く、ISPの問い合わせ窓口もほとんど平常通りだったようです。

前述のAAAA filterもトラブル回避には役に立っていたようですが、思ったほどの問題が無かったこともあり、事前に設定していたAAAA filterをW6Dの最中に解除してしまうISPもあったという話も聞こえてきました。

Path MTU Discovery問題とは

インターネット上の通信では、データをパケットに分割してやりとりしますが、通信路によっては通過できるパケットのサイズの上限が異なる事があります。もし、通信途中の機器が大きすぎるパケットを受け取った場合、その機器が”ICMPv6 Packet Too Big”というメッセージをパケットの送信元に伝え、小さなパケットでデータを送り直すことを要求します。しかし、何らかの理由でこのメッセージが伝えられないと、パケットの再送が行われず、通信ができなくなってしまいます。このような問題が起こる原因の一つは、ルータやFirewallのfilter機能の設定ミスです。同様の問題はIPv4でもありましたが、ブロードバンドルータにこの問題を回避する仕組みが取り入れられているので、現在ではあまり表面化していません。IPv6ではこういった機器が十分に出回っていないため、問題が顕在化しているのでしょう。

実際のところ、どのぐらいIPv6は使われたの?

と言うことで、当初の目的であった「WebサーバをIPv4/IPv6両対応にしても、既存のインターネット利用に悪影響を及ぼさない事」の確認は、概ね達成できたというのが関係者間の共通の認識です。これ自体は喜ばしいことですが、一方で「実際のところ、W6DでどのぐらいIPv6の利用が増えたのか？」と言う話にも興味が湧きます。

インターネット全体で、というのを調べるのは難しいですので、このblogではIIJでの状況を紹介しましょう。

まず、主に個人でご利用頂いていると思われる、ブロードバンド回線向けのIPv6サービスです。こちらは「フレッツ光ネクスト(PPPoE方式)対応サービス」「IPv6仮想アクセス(端末型)」「IPv6仮想アクセス(ネットワーク型)」の3種類が該当します。グラフにそれぞれのサービスのセッション数(その瞬間の利用者数)を表しています。¹残念ながらいずれも目立った動きはありませんが……「全体としては増加傾向」「IPv6仮想アクセス(端末型)は瞬間的に接続数が伸びた」「やっぱりピークは夜(22時頃)だった」あたりでしょうか。

もう一つグラフを。これはIIJバックボーンのとあるところのIPv6のトラフィックグラフです。ご覧の通り、W6D開始以降、IPv6のトラフィックが伸びているのが確認できます。このグラフはどちらかというと、クライアント的な使い方をされている²トラフィックが乗っているポイントで観測しているのですが、おそらく、普段利用しているサイトがIPv6に対応した事により、利用者が無意識のうちにIPv6 Webサーバにアクセスするようになったと言うのがここに反映されているのだと考えています。

この先はどうするの？

ということで、きわめて限定的ではありますが、W6D当日のIPv6利用状況の一端をご紹介いたしました。ブロードバンド回線でのIPv6対応も始まった直後と言うこともあり、まだ、IPv6対応の回線が普及しきっていない印象です。そのため、グラフ的にはいまいち盛り上がりに欠ける感じであったのは否めません。

さて、6/9 9:00(日本時間)をもって、最初のWorld IPv6 Dayが終了したわけですが、この先はどうなるのでしょうか？いくつかのWebサイトでは「どうやら問題なくIPv6に対応できるらしい」という手応えをつかんだのか、W6D終了後もそのままIPv6対応を継続しているようです。また、この「お祭り」に合わせて進んだインターネット接続サービスのIPv6化も、後戻りする事はないと思われます。これからは「いつの間にかIPv6を使っている」という局面が増えてくるかもしれません。

しかし、それでも世界の隅々までIPv6が普及するのにはまだまだ時間もかかります。今回のW6Dに参加したWebサイトは世界中でも数百だったようです。これをどんどん増やしてゆき、いずれは「IPv6対応が普通」になる事を目指さなければなりません。また、今回は主目的ではなかったクライアント(Webサイトを閲覧する)側のIPv6対応も、さらに進めていかなければなりません。こういった動きを推進すべく、IPv6界隈では「次回のWorld IPv6 Dayの開催はどうする」とか「むしろWorld IPv6 Weekぐらいやってみよう」という声も聞こえ始めています。

繰り返しになりますが、重要なことは「IPv6に対応しても、既存のインターネットは壊れない」という事がわかったと言うことです。今回は幾分チャレンジングな側面があったW6Dですが、次回はその輪を広げていくという方向で取り組みが行われると良いのではないかと思います。

余談

完全に余談ですが、今回は実験と言うことで、しゃれたIPv6アドレスを使った組織もいくつか見受けられました。以下に挙げたのは自分で見つけたり、Twitterで見かけたものですが、皆さんいろいろ工夫を凝らしていたようです。(ちょっと苦しいのも見受けられますが……)³

何にせよ、W6Dでは「一般に公開しているWebサイトをIPv6対応しても、大きな問題は起こらない」と言うことが確認できたわけです。今までIPv6対応に不安を感じていたコンテンツ事業者にとって、この結果はIPv6対応に向けて背中を押してくれることになったのではないでしょうか。

Tweet

1. 大人の事情で「縦方向のスケール」は非公開です。前後の日との相対値としてお楽しみください。 [↩]
2. サーバを設置している訳ではない、と推測される [↩]
3. 他にもネタっぽいのがあったのですが、わかりやすいのだけにしています。いずれも6/9 9:00現在のものなので、今は変更されている可能性があります。 [↩]