その時、IPv6が動いた
World IPv6 Dayで得られた成果とこれからの課題

株式会社インターネットイニシアティブ
松崎吉伸
2011/8/4

国内で焦点となった「IPv6→IPv4フォールバック」対応

　日本では主にIPv6→IPv4フォールバックの問題に焦点を当てて、対応策が検討されました。

　将来的にみんながハッピーになれるのは、IPv6のインターネット接続環境を導入することです。そうすれば多くのソフトウェアが想定しているとおりの挙動になり、問題なく利用できるようになります。

　現時点では、家庭で利用できるIPv6対応のインターネット接続サービスが各社から提供されています。しかし、World IPv6 Dayへの対策を検討していた段階では、それらのサービスがいつから提供できるかまだ定かではなく、一部のISPのみがトンネル技術などを利用してサービス提供している段階でした。

　そこで、想定していなかった環境でも問題なく通信できるように、さまざまなソフトウェアで検証を行い、開発元で実装を修正していただけるようにお願いしました。

　OSやWebブラウザなど昨今のソフトウェアは、通信部分をマルチスレッド処理としている実装も多く、どのタイミングで何が起こるかによって挙動が変わるなど、複雑になっています。NTT東西の提供するフレッツ光サービスでは、IPv6→IPv4のフォールバックを素早く行えるように、IPv6でインターネットに対する接続要求（TCP SYN）がIPv6閉域網内に送信された場合はTCP RSTを応答しています。この応答をどの段階で受け取るかによっても、ソフトウェアの挙動は異なるため、再現性のある検証はなかなか難しいものになりました。

　見つけた問題は、それぞれの開発元に報告して修正をお願いしました。残念ながらさまざまな事情があり、すべての実装、バージョンに関して修正が行われたわけではありません。古いバージョンでは修正が入らなかったものもあります。しかし、最新バージョンのソフトウェアであれば、これまでの知見が盛り込まれ、より幅広い環境で問題なく利用できる実装になっています。

　この結果、Webブラウザでは体感的にも素早くコンテンツが表示されるようになっているはずですし、セキュリティの観点からもさまざまな対策がなされています。可能な限り最新版に更新して利用されることをお勧めします。

ポリシーテーブルとAAAA filterという回避策

　場合によっては、これまた諸事情により、Webブラウザなどのソフトウェアを更新できないこともあります。そんな時にはRFC3484で定義されているポリシーテーブルを利用することで問題を回避できます。

　Windowsなど、ポリシーテーブルが実装されているOSであれば、IPv6閉域網で利用されているIPv6プレフィックスを別なラベルに設定することにより、IPv6閉域網内の通信でのみ利用するよう設定できます。これにより無用なIPv6→IPv4のフォールバックを発生させることなく、適切に通信させることが可能です。ポリシーテーブルはとてもうまく動くのですが、これが実装されていない製品やOSでは利用できないという欠点があります。

　最終手段としてISPが検討したのは、AAAA filterと呼ばれる方式でした。ISPで、IPv6のレコードであるAAAAレコードを応答しないキャッシュDNSを用意します。そしてこれを、無用なIPv6→IPv4のフォールバックが発生しているユーザー向けに提供することで、問題を回避してもらおうというものです。

図2　AAAA filterによって無用なIPv6→IPv4のフォールバックを発生させないようにする

　これを実現するためのDNS実装はすでにあり、ユーザーが直接このキャッシュDNSを参照するのであれば、大きな問題もなく動くことが分かりました。各ISPでは当日までに検証と準備を行い、World IPv6 Dayに備えました。またISPによっては準備が間に合わない恐れがあったので、JPNAPとJPIXによってAAAA filterが実装されたキャッシュDNSのサービスも提供されることになりました。

　World IPv6 Dayの参加者であるWebコンテンツの提供者は、それぞれにコンテンツのIPv6対応を進めました。単純にWebサーバをIPv6/IPv4のデュアルスタックにしたり、IPv4のWebサーバの横にリバースプロキシサーバを設置してIPv6のアクセスを別サーバで収容するようにしたり、ロードバランサの機能を利用してIPv6対応したり、IPv6に対応したCDNサービスを利用したりするなど、対応方法はそれぞれの運用ポリシーによってさまざまでした。中には、「ipv6」といったそれらしいホスト名を設定して、実際にアクセスできるかどうかを事前に検証していたところが多かったようです。

和やかに始まったW6D当日

　World IPv6 DayでのIPv6トライアルは6月8日の朝09:00から（日本時間）となっていましたが、一部の参加サイトは予定を前倒しし、IPv6対応しているところもありました。

　当日は世界の関連ISPや事業者がIRC（Internet Relay Chat）で連絡を取り、お互いの状況を確認しながらイベントが進行しました。といっても何か式次第に沿って進行が行われるのではなく、各参加サイトがそれぞれWebサイトにAAAAレコードを付けていくので、それを各地で観測した結果だとか、ユーザーからの問い合わせやその他異常がないかといった状況を情報交換する場として使われていました。

　開始1時間前には各国からオペレータが参加し、それぞれ時差が違うので「夕ご飯を食べてきた」とか、「まだインターネットは無事かい？」とか挨拶を交わしながら、和やかなムードでそれぞれの状況を交換していました。

　今回、事前に十分な準備を行ったところでは、問題なくAAAAレコードの追加削除ができていたようです。ただ、一部サイトで設定ミスと思われるような事例が報告されています。

　具体的には権威DNSがエラーするようになってしまったり、ホスト名とコンテンツをひも付ける仮想サーバの設定で何かを失敗したのか、IPv6でアクセスするとHTTPが404エラーを応答するようになったサイトの事例が報告されています。また、リバースプロキシでIPv6対応サーバを運用したサイトで、このプロキシからのアクセスが元サーバのアクセス数制限を超えてしまったために、アクセスしづらい状況が発生したとの報告もありました。

　これらの事例は、IPv6がどうこうというよりも、十分な検証をしないまま設定変更や導入を行ってしまったことが原因として考えられます。各サイトでの運用技術の向上が重要だといえるでしょう。

　Path MTU Discoveryに関連する問題も報告されています。IPv6でTCP接続はできるものの、コンテンツが得られないといった状況です。

　おそらく、ICMPv6がサーバ側に到達しないような設定が経路上のどこかにあったため、途中のMTUの小さなリンクをコンテンツを含んだパケットが通過できない事象が発生していたようです。各サイトでは経路上のフィルタルールの見直しを行ったり、サーバ側でTCP MSSを少し小さな値に上書きするなどして対策を行っていました。

　これらの問題は発見次第、IRCを通じて各サイトに報告されて対策を促していました。今後はIPv4と同じく、ブロードバンドルータ側でTCP MSSを上書きするなどの対応が広がってくるのではないかと考えています。

　また、今どきのWebサイトは、いろいろなサーバからのコンテンツを読み込んで1つのページに見せたり、あるいはユーザーに適切なコンテンツを応答するためにサーバ間で通信したりする場合があります。自サイトはIPv6対応していないつもりでも、組み込まれたコンテンツがIPv6対応していたり、サーバ間の通信がホスト名で指定されていると、知らぬ間にIPv6で通信していることもあります。特にサーバ間の通信では、セキュリティ上の理由でパケットフィルタなどが適用されている場合もあるため、周囲がIPv6対応していく中で注意が必要なポイントです。

World IPv6 Dayで得られた成果とこれからの課題
	大きな混乱なく終了したWorld IPv6 Day 幅広い多様な環境で「本気」の検証 再認識された問題点
	国内で焦点となった「IPv6→IPv4フォールバック」対応 ポリシーテーブルとAAAA filterという回避策 和やかに始まったW6D当日
	IPv6トラフィックは増加、Gbps単位の観測も みんなで頑張って幸せになろう！

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）