ニュースレターNo.61/2015年11月発行

第93回IETF報告 IPv6関連WG報告〜6man WG、v6ops WG、sunset4 WG〜

IETF 93で筆者が会合に参加した、IPv6に関連するWorking Group(WG)の中から6man WG、v6ops WG、sunset4 WGについて、主な議論の概要を報告いたします。なお、今回はv6ops WGとsunset4 WGは合同でミーティングが開催されました。

6man WG(IPv6 Maintenance, Int Area)

6man WGは、IPv6の仕様とアーキテクチャのメンテナンスと最新化を行うWGです。IETFにおけるIPv6関連トピックの受け皿となり、IPv6の仕様の拡張や変更に関して、責任を持っています。

最初にチェアから、前回のIETF 92(ダラス)から継続議論となっている、無線環境などのようなパケットロスが多い環境における重複検出(DAD: Duplicate Address Detection)の改善について、ML上でより活発に議論をして欲しいとの呼びかけがありました。こちらについては継続的にウォッチしているため、これまでの報告^※1にも目を通していただければ幸いです。

本稿では、ドラフト無しで提起された二つの議題について、取り上げて紹介します。

1. Source Address Dependent Routing for IPv6 hosts analysis

IPv6アドレスを持つホストのソースアドレスに依存したルーティング(SADR: source address dependent routing)について、6man WGとして取り組むべきかどうか、という問題が、Brian Carpenter氏から提起されました。複数のIPv6グローバルアドレス(GUA: Global Unicast Address)を持つホストにおいて適切なGUAを選択しないと(あるいはルーティングによって適切な出口を選択しないと)、上流のネットワークにおいてBCP38(送信元アドレスの検証: Source Address Validation)が行われている場合、正しく通信ができないという問題があります。この問題が既存のメカニズムによって解決されているのであれば、特に新しいアクションは必要ないですが、もし未解決問題があるとすれば、6man WGで扱いたい、という趣旨です。

日本においては、ISPとNGNにおけるマルチプリフィクス問題と似た設定であると考えることが可能であり、ソースアドレスの選択については、RFC6724のRule5.5が適応されていれば問題がないことが議論で指摘されました。しかし、ISPに接続する前にルーティングドメインがあるHomenetのような状況では、ソースアドレスの選択だけでなく、ソースアドレスに依存したルーティングが必要となることから、Homenet WG のメンバーからは、このドラフトを支援することが表明されました。WGとしてこのドラフトを扱うことに強い同意(Hum)が示されましたが、発表者が提案する解決方法については明確な同意は得られず、他の解決策を模索する、として議論が終わりました。

2. IPv6 specifications to Internet Standard

チェアから、IPv6関連の仕様を記載した一連のRFCのカテゴリーをINTERNET STANDARD^※2としたい、という提起がされました。しかしこれは、RFCの複雑に絡んだ系譜を解きほぐす、非常に手間のかかる作業となりそうです。DRAFT STANDARDとなっているIPv6関連のRFCは、RFC2460(Internet Protocol, Version 6(IPv6) Specification)やRFC4291(IP Version 6 Addressing Architecture)をはじめとして少なくとも九つ以上あり、さらにRFC2460だけでも、九つ以上のドキュメントによってアップデートされています。INTERNETSTANDARDになるためには、Errataが存在しないことや使われていない複雑な仕様がないことなど厳しい条件があり、RFC2460をアップデートしているRFCがすべてINTERNET STANDARDの基準を満たすとは限りません。

短期的にはRFC2460を改定するRFC2460bisを作成してINTERNET STANDARDとすることを目的とし、その後にその他のRFCに拡張していく方針となりましたが、標準文書を増やすことで市場に混乱を与えないように、明確な文書となることを心がけるべき、などの意見が出ました。

今回は上記以外に九つの個人ドラフトの発表が用意されていましたが、時間切れにより最初の四つのドラフトしか議論ができませんでした。発表されなかったドラフトの中には、Google社のLorenzo Collitti氏による「ルータ広告(RA)による電力消費計測(RA power measurements)」というものがあり、非常に残念でした。次回のIETF 94横浜で発表があるかもしれないので注目しています。

v6ops WG(IPv6 Operations, Ops Area) & sunset4 WG(Sunsetting IPv4, Int Area)合同ミーティング

v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運用上の課題に対処することに焦点を当てたWGです。また、新しいネットワークや既存のIPv4ネットワークにIPv6を導入するためのガイドラインや、IPv4/IPv6共存ネットワークの運用ガイドラインを作成することも目的としています。sunset4 WGは、IPv6への完全な移行に向けて、アプリケーション・ホスト・ネットワークがIPv4への依存無しに機能することを目指すWGです。他のWGに対して、プロトコルの策定に際してIPv4に依存しないよう働きかけを行うことも目標にしています。

今回合同でミーティングが行われた理由には、sunset4 WGの活動が活発ではないということと、両者の取り扱う領域が一部重複しているため、v6ops WGのCharterを更新するにあたって対象領域を整理したいということが挙げられます。合同ミーティングは7月21日と24日の2回にわたって行われました。

1. v6ops WGの Charter更新について

最初にv6ops WGのCharter更新について報告します。議論の主なポイントは以下の三つでした。

“IPv4/IPv6のインターネットの運用上の問題について解決策を決めるために、オペレーターやユーザーからの情報提供を要請する”という元の文章に対し、対象をIPv6インターネットだけに限定するか否か?
運用による解決策をInformational RFCまたはBCP RFCとしてまとめることをv6ops WGの仕事とするか?
IPv6オンリーのネットワークを展開するための運用上のロードマップをまとめることをv6ops WGの仕事とするか?

1点目に関して、IPv6だけに限定すべきという意見もありましたが、現在は両方を残す案がチェアから提起されています。

2点目に関して、IPv6だけあるいは、IPv6/IPv4デュアルスタックの課題解決策を考えることには賛成が多かったのですが、IPv4だけのトピックに関してはスコープ外ということが確認されました。しかし、これを厳格にしてしまうと、v6ops WGとsunset4 WGのどちらのWGでも拾えない領域が生まれてしまう恐れがあるという意見もあり、オペレーターの便宜のためにデフォルトの受け皿が必要だ、との意見もありました。

3点目に関して、これをv6ops WGの仕事とすると、必然的にデュアルスタックからIPv6オンリーに移行する方法を検討することになるので、sunset4 WGの範囲と重複してしまいます。sunset4 WGが休眠状態(dormant)になってしまうと、IPv4を止めるときの諸課題に対処する議論をする場がなくなってしまうので、v6ops WGで引き取るべきだという意見と、今回のような合同ミーティングを続けてはどうかという意見がありましたが、チェアが改訂案を提起して継続議論という結論となりました。

2. IPv6 and Appleについて

次に、Apple社のStuart Cheshire氏が発表した、“IPv6 and Apple”について紹介します。

発表では、iOSとOS XなどほとんどのApple製品についてIPv6がサポートされていることを紹介したあと、すべてのiOSのアプリケーションは、IPv6ネイティブサポートとNAT64ネットワークで動作しなければならない(MUST)というメッセージが打ち出されました。今年中にはアプリケーションを登録する上での要求条件になる、とも伝えています。Verizon社、AT&T社、T-Mobile社などのキャリアでIPv6対応が進み、CGN越しにIPv4通信をするよりもIPv6で通信をするインセンティブがあるため、新しいiOSとOS Xでは99%がIPv6通信になる挙動をするとのことです。

なぜNAT64なのか、ということで464XLATとNAT64/DNS64を比較していましたが、464XLATでは、IPv4のみのクライアントはIPv4サーバとしか通信ができないが、NAT64/DNS64では、IPv6のみのクライアントはIPv6/IPv4サーバ両方と通信できることから、後者が良いと主張しました。それに関して、「DNSSECのvalidationの点でDNS64を用いない464XLATの方が良い」「IPv4リテラルへの対応はどうするのか」「464XLATでもクライアントはIPv6を持っていることが仮定されているので変わらないのでは」などの意見が出ました。けれども、今回のApple社の方向性が、開発者にIPv6でのアプリ開発を促すものになるので、支持する声が大きかったです。

発表では、開発者に向け、OS X 10.11(El Capitan)のInternet Sharing機能を用いて、NAT64/DNS64テストネットワークを作成し、モバイル端末のテストをする方法が紹介されました。テスト用のNAT64配下のIPv6ネットワークについては、Benchmark WGがRFC5180にて確保しているテスト用のアドレス帯(2001:2::/48)から、2001:2:0:aab1/64が使われるだろうと、MLで議論されています。

99%がIPv6通信になるというiOS 9とOS X 10.11(El Capitan)のHappy Eyeballsの新しい実装(β版)については、“Apple and IPv6 - Happy Eyeballs”という件名でv6ops MLに投稿されたメールで詳しく説明されています。このHappy Eyeballsとは、IPv6/IPv4デュアルスタック環境において、IPv6とIPv4の両方のプロトコルを用いて同時に接続を行い、先に成功した方の結果を用いて、フォールバック問題を緩和する方法で、RFC6555にて標準化されています。

拙訳を紹介します。

アップデートされた実装は、以下のように振る舞います。

1. DNSリゾルバにAクエリとAAAAクエリを出します
- もしDNSレコードがキャッシュに無い場合、リクエストはワイヤ上で連続して送信されます(AAAAが先)

2-1. もし最初の応答がAAAAだった場合、IPv6のSYNを直ちに送ります

2-2. もし最初の応答がAだった場合、AAAAを期待して、25msのタイマーを開始します
- もしタイマーが切れたら、IPv4のSYNを送ります
- もし25ms以内にAAAAを受け取ったら、アドレス選択に進みます

3. IPアドレスのリストがある場合(DNSキャッシュからの場合か、IPv4とIPv6を近接して受け取った場合)、それらのソートのために、アドレス選択アルゴリズムを実施します。このアルゴリズムは、過去のRTT値のデータを用いて遅延の少ないアドレスを優先しますが、25msのゆとりを持ちます。もし、過去のRTT値の差が25ms以内だった場合、RFC3484を使ってベストなアドレスを選択します

4. リストがソートされたら、リストの1番目のアドレスにSYNを送ります。また同時に、過去のTCPのRTT値の平均と分散をベースとしたタイマーを開始します。大雑把に言えば、1番目のSYNの再送信と同じくらいの時間に2番目のアドレスのSYNを送ります

5. 1番目のアドレスのSYN-ACK応答が競争に勝ったら、他のTCP接続の試みをキャンセルします

こちらの挙動は、β版なので詳細は変更される可能性はありますが、将来のApple社製品のIPv6トラフィックを飛躍的に増加させるものとして、成功が期待されています。

3. OTEにおけるIPv6展開について

IPv4 as a Serviceプロジェクトの一環として、ギリシャのISPであるOTE(Organismos Tilepikinonion Ellados)におけるIPv4 over IPv6サービス事例が共有されました。Meetechoというツールを使って、ギリシャから遠隔で発表するスタイルで行われました。今回のギリシャの事例では、StatelessであることからMAPを当初検討していたが、シンプルなプロビジョニングを実現できることから、最終的にはLightweight 4 over 6を採用したことが説明されました。

4. ホストアドレスに複数のアドレスを利用することの推奨について

Google社の Lorenzo Colitti氏とVint Cerf氏、Apple社のStuart Cheshire氏が筆者ということで、非常に注目を集めているドラフトです。MLに投稿された直後から、今でもずっと議論が続いています。

IPv6とIPv4の大きな違いは、ホストで複数のアドレスを持てることです。そのことがきちんと理解されていないということが、ドラフトを書いたモチベーションだと説明されました。複数のアドレスを持つことのメリットとして、次の利用方法が挙げられました。

IPv6プライバシーアドレス
ホスト内の複数のVirtual Machineやプロセッサへのアドレス付与
テザリング
IPv4 over IPv6技術
その他、将来のアプリケーション

これらの技術は、複数アドレスの恩恵を受けることができます。上記の一部はNAT66によっても解決することができますが、NAT越えの問題やNATのキープアライブの問題(QUICは15秒間隔でキープアライブを実施)があるため、NAT66は望ましくないとしています。

これらの主張に対して、内容をサポートする意見が多かったです。しかし、ドラフトの内容はまだ問題を明確に記述することができていないため、それを確認するための質問が続きましたが、時間の関係で議論が途中で切り上げられてしまいました。ただ、WGドラフトとして扱うかどうかには同意(Hum)が圧倒的に多かったため、今後はWGドラフトとなる可能性が非常に高いです。v6ops MLで盛り上がっている議論を、今後も注意深く追っていく必要があります。

その他、sunset4 WGとして二つ発表がありましたが、いずれも議論が活発でないために、継続してレビューを求む、となっています。また、v6ops WGとして他に五つの発表がありました。その中で、前回の報告で紹介したSIIT-DC:Stateless IP/ICMP Translation for IPv6 Data Centre Environments(v6ops-siit-dc)と、SIIT-DC: Dual Translation Mode(siit-dc-2xlat)については、ドキュメントを整理した上で再提出された内容がよく精査されていたことから、WGラストコール(WGLC)を迎える予定となっています。また、Sending Solicited RAs Unicast(v6ops-solicited-ra-unicast)については、RAのマルチキャストがモバイルネットワークにおいて非効率である問題の解決策について引き続き議論が行われましたが、WGドラフトとすることの同意(Hum)が得られ、次からはWGドラフトとして再提出される予定です。

(NTTコミュニケーションズ株式会社西塚要)

※1 JPNIC News & Views IETF関連記事: https://www.nic.ad.jp/ja/mailmagazine/backnumber/ietf.html
※2 RFCのカテゴリー: 従来のINTERNET STANDARD、DRAFT STANDARD、PROPOSED STANDARDの三つのレベルに分かれていたものが、RFC6410によって、INTERNET STANDARDとPROPOSED STANDARDの二つに集約されています