ニュースレターNo.58/2014年11月発行

第90回IETF報告　IPv6関連WG報告

第90回IETFのWorking Group(WG)のうち、筆者が会合に参加したIPv6に関連するWGの中からv6ops WGとhomenet WGについて、主な議論の概要をご紹介したいと思います。なお、今回のIETFでは、6man WG(IPv6 Maintenance WG)は開催されませんでした。

v6ops WG(IPv6 Operations WG)

v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運用上の課題に対処することに焦点を当てたWGです。また、新しいネットワークや既存のIPv4ネットワークにIPv6を導入するためのガイドラインや、IPv4/IPv6共存ネットワークの運用ガイドラインを作成することも目的としています。

今回のv6ops WGでは、2014年7月17日(木)〜18日(金)に香川県高松市で開催された、JANOG34で行われたIPv6 ULA(Unique Local Address)に関する実験^※1の結果について、NTTコミュニケーションズ株式会社の小原泰弘氏が発表を行いました。

IPv6 ULA(fc00::/7)は、IPv4におけるプライベートアドレス^※2に相当するアドレスです。ただし、下記2点のような違いがあり、IPv4におけるプライベートアドレスと完全に一致しているわけではありません。

IPv6では一つのIFがULA(Unique Local Address)とGUA(Global Unicast Address)の両方のアドレスを持てる点
ランダムに生成することが推奨されている40bitのフィールドをprefixに含んでいることから、実質上はグローバルにユニークであることが期待されている点

当初、IPv6におけるプライベートネットワーク用としては site-local addresses(fec0::/10)が予約されていましたが、定義が曖昧だったことから非推奨となり、代わりにIPv6 ULAが、2005年にRFC4193^※3において定義されました。

IPv6 ULAの利用シーンとしてさまざまな構成が考えられるため、それぞれの構成の利点と欠点を明確にするためのドラフト(draft-ietf-v6ops-ula-usage-recommendations-02)が提出されており、v6ops WGのメーリングリスト(ML)では、このドラフトについて現在も活発に議論がされています。

JANOG34では、ドラフトに記載されている利用シーンのうち、以下の二つのシチュエーションを構築して実験を行いました。

ULA along with GUA: IPv6 ULA + GUAで構成したネットワーク(IPv4アドレスはあり)。IPv6サイトへはGUA(またはULA+NPTv6)、IPv4サイトへはNAT44で通信を行う。
ULA-only Deployment: IPv6 ULAのみで構成したネットワーク(IPv4アドレスは無し)。IPv6サイトへはNPTv6、IPv4サイトへはNAT64/DNS64で通信を行う。

前者のケースでは、さまざまなアプリケーションで通信にまったく問題が無かったこと、ソースアドレスとしてULAを選択した通信が発生しなかったこと(Neighbor DiscoveryとmDNS通信を除く)が報告されました。また、後者のケースでも、IPv4アドレスが無いと動作しないSkypeを除き、ほとんどのアプリケーションで問題が無かったことが報告されました。

会場からは、実験内容の詳細について尋ねる質問が多かったですが、マイクに立った質問者全員が、コメントの冒頭で、貴重な実験結果を共有したことに対しての感謝の意を述べていました。

今回の実験では、ほとんどの場合で通信に影響が無いという良好な結果でしたが、アプリケーションに依存して、または、端末のソースアドレスセレクションのルールに依存して、通信への影響が発生することが想定されるため、「次はもっとアプリケーションと端末のバリエーションを増やして実験をして欲しい」というコメントが、大勢を占めていました。

今回の発表は、JANOG34の会場ネットワークでULAに関する実験を発案した、シスコシステムズ合同会社の土屋師子生氏が、v6ops WGのMLに実験内容について投稿したことがきっかけで実現しました。IETFでは現在、IETFの上位組織であるISOC(Internet Society)におけるDeploy360^※4という取り組みの中で、運用者の意見をプロトコルの標準化に積極的に取り込んでいこうという試み「Operators And The IETF」^※5を行っています。日本の運用者の意見が集約されるJANOGから、IETFの場に意見をインプットしていくことは非常に重要であり、今後も継続していくべきと感じました。

v6ops WGでは他にも、次のような注目すべき発表が行われました。

DHCPv6/SLAAC Address Configuration Interaction Problem Statement(DHCPv6/SLAACアドレス構成対応問題に関するステートメント)
(draft-ietf-v6ops-dhcpv6-slaac-problem)

JPNIC News & Views vol.1153で「DHCPv6/SLAACアドレス構成対応問題」として取り上げられているので、詳細はこちらをご参照ください。今回の進捗としては、文章の細かい修正を経て、内容に技術的な間違いが無いことが確認されたため、WGLC(Last Call)をすべきかの採決が行われ、賛成多数となりました。

Close encounters of the ICMP type 2 kind(near misses with ICMPv6 PTB)(ICMP type2 パケットとの遭遇(ICMPv6 Packet-Too-Big パケットのニアミス問題))
(draft-jaeggli-v6ops-pmtud-ecmp-problem)

ロードバランサやAnycastを用いている環境で、サーバからサイズの大きいパケットを送った際に、ICMPv6 type 2“Packet Too Big”(PTB)メッセージ応答が、元のサーバに返らない問題をドラフト化したものです。Fastly社のJoel Jaeggli氏が発表を行いましたが、この問題は日本国内では既に指摘されている事象です。特定の状況で起こる事象ですが、v6ops WGとして解決すべき問題という位置付けとするかどうかの採決が行われ、賛成が多い結果となりました。今後、WGドラフトとなるための協力を求むとして、発表は終わりました。ちなみに、この一風変わったドラフトタイトルは、「未知との遭遇」(原題:Close Encounters of the Third Kind)をもじったものです。

Power consumption due to IPv6 multicast on WiFi devices(Wi-FiデバイスにおけるIPv6マルチキャストパケットによる電池消費)
(draft-desmouceaux-ipv6-mcast-wifi-power-usage)

IPv6のWi-Fiに接続した時に、マルチキャストパケットによって端末の電池の消耗が早くなってしまう可能性について、実測した結果について述べた発表です。同じ発表が、intarea WG(Internet Area WG)においても行われました。実験結果から、IPv6のWi-Fiネットワークに所属しただけで、少なくとも4パケット、可能性としては20パケット以上のマルチキャストパケットが発生するなど、興味深い知見が得られています。v6ops WGの反応としては、電池の消耗を比較するのであれば、他の場合と慎重に比較すべきだ、との意見がありました。

IPv4 Address Literal in URL(URLにおけるIPv4アドレス表記)
(draft-osamu-v6ops-ipv4-literal-in-url)

NAT64/DNS64環境においては、通常では“http://192.0.2.10/index.html”のような、IPv4リテラル表記が含まれるURLを持つIPv4サイトには到達することができません。これは、IPv4アドレスをマッピングしたIPv6アドレスを通じて、外部のIPv4サイトと接続する必要があるためです。このようなIPv6マッピングアドレスを得るために、「<ipv4-address-literal>.TLD」をDNSに登録(あるいはホストに登録)する手法について、奈良先端科学技術大学院大学の櫨山寛章氏が発表を行いました。また、IPv4リテラルに自動的にsuffixを付与し、名前として解釈するGoogle Chromeのplug-inを開発し、問題なく動作したことが紹介されました。

チェアであるFred Baker氏は、このことは解決すべき問題であると会場に対し表明し、賛同を得ました。しかし、TLD(Top Level Domain)を使うアプローチであることから、他の実装との干渉を心配する会場の声も多く、標準化にあたっては注意深く手順を踏んで欲しいという意見が、参加者から複数ありました。

homenet WG

homenet WGは、家庭内が複数のセグメントに分かれ、複数の上流ISPを持つ(来るべき)状況を想定し、ルーティング(Interior Gateway Protocol; IGP)、アドレス選択、DNSキャッシュサーバ選択、セキュリティ、境界検出(border discovery)、それらの自動設定に関する問題の解決を目的としたWGです。

今回は、ルーティングプロトコルをどのように標準化するかについて、時間を20分取ってじっくりと議論が行われました。チェアの1人であるMark Townsley氏のスライドにおいて、IETF 89で示された三つの方向性についての再確認が行われました。

ルーティングプロトコル無しで実装する(HNCP(Home Networking Control Protocol)フォールバックを用いる)
一つのルーティングプロトコルを選択する(OSPF(Open Shortest Path First)、IS-IS(Intermediate System to Intermediate System)、etc..)
二つ以上のルーティングプロトコルを選択する

これまでの議論をまとめると、1)、2)に対しては賛成多数であるが、3)に対しては賛成少数という状況です。チェアは、ルーティングプロトコルを一つに絞りきれなければ、Coin-flip(コイントス)による決定も考えていると表明しました。会場からは、1)と2)の意見が半々といった状況でした。既存のルーティングプロトコルに依存せずに1)で進めたい意見がある一方、1)では結局homenet WGで新しいルーティングプロトコルを生み出すことが必要となり、難しいのではないかという反対派もおり、結局何も決まらないままタイムアップとなってしまいました。

続いて、IS-IS Implementation Reportでは、ルーティングプロトコルとしてIS-ISを用いたhomenetの実装(送信元/先のアドレスの組を用いたルーティング)の報告が行われました。現在、homenetにおいて利用可能なルーティングプロトコルとして、IS-IS、OSPF、Babelの三つの実装が存在することとなりました。

その他、下記を含む多岐にわたる提案が、十分な議論の時間が取れないまま大量に行われました。最終日である金曜日の午前に行われたため、一部参加者のフライトスケジュールに配慮した都合によって、時間を巻いて行われたという側面もあります。

上流ISPから割り当てられたアドレスを、自動的にhomenet内の複数セグメントにfloodingする方法の提案(draft-pfister-homenet-prefix-assignment)
homenet内のノードの名前解決をインターネット上のサードパーティーDNSにアウトソースする方法の提案(draft-mglt-homenet-front-end-naming-delegation)
homenetに適したPCP(Port Control Protocol) proxyの実装の提案(draft-stenberg-homenet-minimalist-pcp-proxy-00)など

homenet WGは、家庭内に小規模なマルチホームネットワークを丸ごと作ることを課題設定としているため、必然的に他のエリアやWGに関わる提案が多くなります。ルーティングエリアとのコンフリクトを懸念したり、チェアや参加者から他のWGでも議論するよう求められたりと、標準化における難しいプロセスを、これから先、いくつもクリアしていく必要がありそうです。