ニュースレターNo.56/2014年3月発行
IPv6関連WG報告 〜6man WG、v6ops WGについて〜
カナダのバンクーバーにて開催された第88回IETFのWorking Group(WG)のうち、筆者が会合に参加したIPv6に関連するWGの中から6man WGとv6opsWGについて、主な議論の概要をご紹介したいと思います。
6man WG(IPv6 Maintenance WG)
6man WGは、IPv6プロトコルのメンテナンスを目的としたWGです。まず、最初のチェアからのプレゼンでは、6man WGの新しいチャーターとマイルストンが紹介され、U/Gビットやフラグメンテーション、拡張ヘッダに関する議論を行うことが示されました。なお、IPv6 over Foo(何らかの仕組み上でIPv6を使用)に関する議論は、新設された6lo(IPv6 over Networks of Resource-constrained Nodes) WGにて行われることになっています。その他にも、産業用無線ネットワークへの適用を目的とした6tisch(IPv6 over the TSCH mode of IEEE 802.15.4e)WGも新設されるなど、M2M(Machine to Machine)やIoT(Internet of Things)関連の標準化も活発化してきている状況です。
今回のセッションで筆者が特に興味を持ったのは、Deprecating EUI-64 Based IPv6 Addresses(draft-gont-6man-deprecate-eui64-based-addresses-00)で、「Modified EUI-64 FormatのようなHardware AddressをInterface ID(IID)に埋め込むようなIID生成方法は、セキュリティの観点から望ましくないため廃止しよう」という提案です。具体的には、ノードはHardware AddressをIIDに含めてはいけないことや、代替となるIID生成方法として、“A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration(IPv6ステートレスアドレス自動構成において意味的に理解しにくいインタフェースIDの生成方法)(draft-ietf-6man-stable-privacy-addresses-16)”を使用すべきとしています。
本提案をWGアイテムとすべきかどうかについての会場でのハミングでは、賛同者多数となったものの、要求水準(Requirement Level)をMUST NOTにすべきかSHOULD NOTにすべきかについては、検討が必要ということになりました。これを受けて、現在メーリングリスト(ML)上にて、WGで採択するかどうかの再確認が行われている状況です。
その他のトピックとしては、マルチキャストの抑制や省電力が求められるネットワーク(例えば、ワイヤレスやバッテリー駆動のデバイスなど)におけるND(Neighbor Discovery、近隣探索)の最適化を行った方式である、Wired and Wireless IPv6 Neighbor Discovery Optimizations(有線/無線でのIPv6近隣探索最適化)(draft-chakrabarti-nordmark-6man-efficient-nd-04)や、プライバシーやセキュリティの観点からさまざまなアドレス生成の方式について比較検討、整理を行っているPrivacy Considerations for IPv6 Address Generation Mechanisms(IPv6アドレス生成メカニズムにおけるプライバシーの考慮)(draft-ietf-6man-ipv6-address-generation-privacy-00)の議論が行われるなど、IPv6普及による実践的なテーマへと議論の軸が移ってきていることが感じられました。
v6ops WG(IPv6 Operations WG)
v6ops WGは、IPv6運用上の問題解決のための議論を第一優先として、その他にはIPv6普及に向けた運用上のガイドラインなども取り扱うWGです。
今回のセッションで筆者が特に興味を持ったのは、DHCPv6/SLAAC Address Configuration Interaction Problem Statement(DHCPv6/SLAACアドレス構成対応問題に関するステートメント)(draft-liu-bonica-v6ops-dhcpv6-slaac-problem-00)です。一般的なホストでは、DHCPv6やStateless Address Autoconfiguration(SLAAC)を実装していますが、これらの挙動はRA(Router Advertisement、ルータ広告)の「A(Autonomous address configuration)」「M(Managed address configuration)」「O(Other configuration)」の各フラグ状態によって変化します。なお、このドキュメントでは、Windows 7、Linux、Mac OS X、iOS、Androidの各ホストにおける挙動が異なっている点が指摘されています。例えば、Mフラグを「M＝1」から「M＝0」に変化させた場合、Windows 7では DHCPv6にて取得したアドレスをリリースするのに対し、LinuxやMac OS Xではアドレスをリリースせずにそのまま保持し続けるといったように、ホストにより挙動が明らかに異なっています。
このようにホストごとに挙動が異なっているのは、RFC2462やRFC4862で定義されてきたSLAACの仕様に、曖昧さが残っていることに起因しています。
本ドキュメントについて、会場では問題点の共有が行われ、問題がある(Problem Statement)として6man WGに対して提示すること、およびオペレータ向けの現時点でのガイドラインとして、v6ops WGのWG Itemとして取り扱うことで検討が進んでいます。
その後、本ドラフトは2013年11月26日(火)に、draft-ietf-v6ops-dhcpv6-slaac-problem-00として、WG Draftとして発行されています。
その他のトピックとしては、T-Mobile USA社が464XLATを利用したIPv6サービスを開始したことに伴い、CLAT(customer-side translator)内部で必要となるローカルなIPv4アドレスについて、IANAから適切なアドレスプールの割り当てを要求する464XLAT CLAT IPv4 Address(draft-byrne-v6ops-clatip-00)の提案や、モバイルネットワークにおいてローミングを行う際の想定シナリオや、それに伴いローミングに失敗するケースの分析などがされているIPv6 Roaming Behavior Analysis(draft-chen-v6ops-ipv6-roaming-analysis-02)など、実際のIPv6サービスに関連する提案も増えてきている状況です。
なお、今回のv6ops WGで最初に行われたプレゼンでは、Microsoft社のChris Palmer氏から、Microsoft社のTeredoサービスとXbox Oneに関するプレゼンが行われ、Windows向けのTeredoサービスに関しては、2014年の前半にはサービスを終息する予定であるとの報告がありました。またXbox Oneに関しては、Teredo ＋ IPv6 IPsecによるP2P Connectionの確立を行っており、IPv6 Nativeよりも時には信頼性が高い側面があることなどが紹介され、身近なゲーム機での実装ということもあって、多くの参加者が興味を持って聞いていました。
また、11月5日(火)の昼には“IPv6 -- What Does Success Look Like?”と題して、恒例のISOC Briefing Panelが開催されたり、11月7日(木)の夜にはBits-N-Bitesにて、Huawei社やChina Telecom社がSDN(Software-defined networking)や、NFV(Network Functions Virtualization)の要素を取り入れた「OpenV6 ： Unified IPv6 Transition」のデモを行うなど、IPv6に関連する話題が盛りだくさんの第88回IETFでした。
(NECアクセステクニカ株式会社 川島正伸)
