ニュースレターNo.46/2010年11月発行
Google IPv6 Implementors Conference 2010報告(2010.6.10~6.11)
2010年6月10日、11日の2日間、米国カリフォルニア州マウンテンビューにあるGoogle本社にて、「Google IPv6 Implementors Conference 2010」が開催されました。
本カンファレンスは、IPv6導入(製品への実装だけではなくネットワークやサービスへの導入も含む)経験を共有することを目的に、Google社が主催して2008年から毎年行われています。今年はVint Cerf氏からのビデオメッセージで幕開けとなりました。
参加者は約170名、うち米国からが8割程度、ヨーロッパからが2割弱、日本からは10名強でした。また東日本電信電話株式会社(NTT東日本)水越一郎氏、株式会社インターネットイニシアティブ(IIJ)松崎吉伸氏、NECビッグローブ株式会社 川村聖一氏、筆者の4名が発表を行いました。
過去2回のカンファレンスでは、IPv6実装技術全般および欧米アクセス系ISPにおけるIPv6への取り組み紹介がメインでしたが、今年は、
- コンテンツプロバイダーやCDN(Contents Delivery Network)におけるIPv6導入状況
- 携帯電話におけるIPv6実装状況
- CPE&ホームネットワークにおけるIPv6実装状況
が紹介されたことが大きな特徴です。本稿では上記3点に、
- アクセス系ISPにおけるIPv6導入状況
を加えた4点について、簡単ですがご紹介させていただきたいと思います。
(1)コンテンツプロバイダーやCDNにおけるIPv6導入状況
Google社、Yahoo!社、Facebook社、Limelight Networks社から発表があり、次の内容が紹介されました。
- 既知の問題(パフォーマンス、コスト、レイヤ4ポート番号の不足、abuse対応)に加えて、Geo-location(クライアント側IPアドレスなどを元に位置情報を特定する技術)の精度が低下することもCGN(Carrier Grade NAT)の大きな問題であること
- サーバ側のコードすべてをIPv6対応にすることが困難な場合には、まず負荷分散装置、リバースプロキシー、CDNなどのフロントエンドをIPv6対応させる手法も有効であること
- Google社およびYahoo!社ではIPv6への対応が不十分なユーザーへの対策としてDNS Whitelistingを使っていること
またNECビッグローブ社の川村氏からも、同社ポータルサイトおよびホスティングサービスにおけるIPv6導入時の経験について発表があり、ルータ、負荷分散装置、監視ソフトの間で仕様整合性が一部取れていないこと、クライアントソフトやクライアント側ネットワークに依然として問題が隠れていること、運用ツール(監視ソフトや各種解析ツール)でのIPv6対応が遅れていることが指摘されました。
この中で特筆すべきは、「DNS Whitelisting」の採用です。一般にクライアントとサーバがIPv6を使って通信するかどうかは、クライアントがDNSのAAAAレコードに対する問い合わせを行い、かつサーバ側のDNSがそのAAAAレコードにIPv6アドレスを返すかどうかで決まります。しかしこのDNS問い合わせは現時点では、IPv6ではなくIPv4パケットを使って行われているため、実際にはIPv6での到達性が無かったり、不十分なクライアントであったりしてもAAAAレコードに対する回答を得ることができます。そのようなクライアントが、一つのFQDNにIPv4/IPv6双方のアドレスを持っているサーバにアクセスすると、IPv4に通信がフォールバックするまで数分待たされたり、タイムアウトしてアクセスできなくなったりする問題が起きます。
Google社やYahoo!社での実測値によると、この問題は約0.05~0.1%のユーザーに発生しているようです。DNS Whitelistingはこの問題を防止するための手法で、IPv6対応を行っていると確認できたISPのDNSサーバからAAAAレコード問い合わせを受けた場合のみ、サーバのIPv6アドレスを返すようサーバ側DNSを設定します。本手法は確かに有効ではありますが、「IPv6に伴う諸問題を先送りにしているに過ぎない」「原因はホームネットワーク内にあることも多く、ISPがIPv6に対応してもそれらは問題として残る」「ISPがIPv6対応したときに、DNS Whitelistingを採用しているコンテンツプロバイダーすべてに連絡することは運用上困難」との議論も行われました。なおIPv6対応したISPからコンテンツプロバイダーへの連絡に関しては、DNSの逆引きのTXTレコードに特定文字列を登録するという手法が、Google社から提案されました。
またIIJ社の松崎氏からは、IPv6インターネットへの到達性が不十分なクライアントの一例として、IPv4の場合と同様にPath MTU Discoveryがうまく働いていないケースが紹介され、対策としては
- CPE(Customer Premises Equipment)からRA(Router Advertisement)を使ってMTU(Maximum Transmission Unit)サイズを各ホストに通知すること
- IPv4の場合と同様、CPEにMSS(Maximum Segment Size)hackを実装すること
のいずれかが有効であることが述べられました。
(2)携帯電話におけるIPv6実装状況
Nokia Siemens Networks社、T-Mobile社、Verizon Wireless社、go6.si、Ericsson社から、携帯電話におけるIPv6への移行動機および現在の実装状況について発表がありました。
IPv6への移行動機については、次の内容が挙げられていました。
- 携帯電話事業者においては以前からNAT44の利用が一般的であるが、NAT内部のプライベートアドレスが不足するため、プライベートネットワークを複数に分割するようになっており(Verizon Wireless社の場合、40以上に分割)その運用負荷が大きいこと
- データ通信の利用率向上やプッシュ型アプリケーションの普及によりNAT44を使ってもIPv4グローバルアドレスが不足しそうなこと
- プッシュ型アプリケーションではNAT対策としてTCPセッションを長時間保持することが行われているが、これが端末の電池を浪費する原因になっていること
次に現在の実装状況については、3GPP(Third Generation Partnership Project)での標準化状況や各社製品の実装状況の紹介に加えて、go6.siおよびEricsson社から米国の携帯事業者網(=IPv6未対応)にローミングしている携帯端末に、ホーム網側からIPv6アドレスを割り当て、通信を行うという大変興味深いデモも行われました。
(3)CPE&ホームネットワークにおけるIPv6実装状況
Cisco社、Arris社、Iskatel社、D-Link社から標準化動向、各社製品の実装状況が紹介されました。その中でも、ホームネットワークに対して複数アップストリームがある構成(マルチホーム)や複数プリフィクスが割り当てられる構成(マルチプリフィクス)における、CPEに求められる機能について多くの時間が割かれ、「各アップストリームから到達できるサービスや機能に基づいて、アップストリームやプリフィクスを使い分ける機能が必要」「セキュリティポリシーとの連動も必要」「追加機能を実装していないCPEとの互換性確保も重要」との指摘がありました。日本でもフレッツ光ネクスト上でのIPv6インターネット接続は、まさに上記の構成にあたるため、非常に興味深い議論でした。
また携帯電話端末がホームネットワークのゲートウェイとしても機能している構成が、他の発表を含めて何度か紹介され、ホームネットワークの典型的な構成例の一つとなっていくであろうことを予感させました。
(4)アクセス系ISPにおけるIPv6導入状況
Comcast社、AT&T社、NTT東日本、ソフトバンクBB株式会社からIPv6の導入状況および今後のロードマップについて紹介がありました。
Comcast社からは、今年1月から6rd(IPv6 rapid deployment)、デュアルスタック、DS-Liteを使ったトライアルを開始し、5,400人のボランティアが参加していること、デュアルスタックは地域限定だが、他のソリューションの場合は地域に対する制限は無いとのことでした。
またAT&T社からは、6rdを使ってIPv6サービスを提供予定であること、ネットワークアドレスを固定で割り当てる企業向けサービスと組み合わせるためには、現在の6rdの仕様では足りないこと、6rdを実装できないCPEを交換する費用やVoIPやIPTVなどのサービスをIPv6対応させていくためのコスト捻出が難しいこと、が紹介されました。
NTT東日本の水越氏からは、フレッツ光ネクストの概要、その上でのIPv6インターネット接続サービス形態として案2(トンネル方式)と案4(ネイティブ方式)が進められていること、フレッツ光ネクスト上ではIPTVサービスにIPv6を使っており、ピーク時にはトラフィックが50Gbpsに達していることが紹介されました。
筆者からは、ソフトバンクBB社ではADSLやフレッツユーザーに対しては6rdを用いてIPv6サービスを順次提供し始めていること、フレッツ光ネクストユーザーに対しては、案4を用いて2011年春から提供予定であることを説明させていただきました。
最後は主催者Google社からの「できればIPv6 Implementors Conferenceは来年で終わりにしたい(再来年にはIPv6が当たり前になっていて欲しい)」との冗談本気半々の挨拶で、2日間にわたった本カンファレンスは終了しました。
なお、各プレゼンテーション資料および大半のプレゼンテーションビデオが、下記URLに掲載されていますので、ご参照ください。
- □Google IPv6 Implementors Conference 2010 Agenda
- http://sites.google.com/site/ipv6implementors/2010/agenda
(ソフトバンクBB株式会社 山西正人)