ニュースレターNo.60/2015年7月発行

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

第92回IETFで筆者が会合に参加した、IPv6に関連するWorking Group(WG)の中から、6man WG、v6ops WG、sunset4 WGについて、主な議論の概要を報告いたします。

6man WG(IPv6 Maintenance, Int Area)

6man WGは、IPv6の仕様およびアーキテクチャのメンテナンスと、最新化を行うWGです。IETFにおけるIPv6関連トピックの受け皿となり、IPv6の仕様拡張や変更に関して、責任を持っています。6man WGから下記のRFCが発行されたことが、チェアから報告されました。

RFC7421 - Analysis of the 64-bit Boundary in IPv6 Addressing: https://tools.ietf.org/rfc/rfc7421.txt

IPv6ユニキャストアドレスのインタフェース識別子(IID)が64-bitで固定されていることの利点および可変にしたときの影響について、調査結果をまとめたInformational RFCです。

今回は一つのワーキンググループドラフト、11の個人ドラフト(そのうち四つが新規ドラフト)が話し合われましたが、特に議論を集めた3項目について紹介いたします。

(1) Validation of IPv6 Neighbor Discovery Options (draft-ietf-6man-nd-opt-validation)

2015年3月にワーキンググループドラフトとして提出されたもので、IPv6近隣探索(ND)におけるNDメッセージのオプション情報の評価について、推奨のルールを決めています。Source Link-Layer Address(SLLA)オプションとTargetLink-Layer Address(TLLA)オプションについて、オプション内のリンクレイヤアドレスに、ブロードキャストアドレス・マルチキャストアドレスまたは受信ノードのリンクレイヤアドレスが指定されている場合は、このオプションを無視しないと、パケットの転送を反復させる攻撃が可能となってしまいます。それ以外のオプションについての記述は、既存の文書(RFC4861、RFC2464)と大きな変更が無いので、この二つのオプションの記述のみに絞るべきかどうかが議論されています。

(2) A survey of issues related to IPv6 Duplicate Address Detection (draft-yourtchenko-6man-dad-issues, draft-nordmark-6man-dad-approaches)

近隣探索プロトコルの無線環境における問題についての議論の一環です。重複検出(DAD)について、問題点と解決に向けたアプローチが、それぞれまとめられています。「アドレス重複が起こる確率は低いので、配慮する必要は無いのでは」という意見がある一方、「実際にアドレス重複が起きたらトラブルシュートするのは時間がかかるので、解決手段を得るためには必要だ」という意見もありました。こちらは多くの関心を集めており、引き続き議論されていく予定です。

(3) IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh

こちらも近隣探索プロトコル(ND)に関連し、定期的なマルチキャストのルータ要請(RA)は無線環境には適さないことから、ユニキャストでルータ探索(RS)を更新できるように、RSメッセージにR-flagを追加しようという提案です。また、RAメッセージにオプションを追加して、ルータ側から更新時間を通知できるようにします。この提案は「IPv6のRFC全体に影響を与えることから、問題の解決策としてはよいアプローチではない」という意見が大勢を占めました。

v6ops WG(IPv6 Operations, Ops Area)

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

今回のv6ops WGでは、“IPv4 as a service”と呼ぶ、新しいプロジェクトを始める提案がチェアからなされました。IPv6のネットワーク上において、IPv4を必要なサービスとして提供する(ただし、徐々に減らしていく)というシナリオを前提として、IPv4 over IPv6技術の展開における運用ガイダンスを書くというプロジェクトです。対象とする技術は、現在、次の九つです。

464XLAT(RFC 6877)
SIIT-DC(draft-anderson-v6ops-siit-eam, draft-ietf-v6ops-siit-dc, draft-ietf-v6ops-siit-dc-2xlat)
MAP-E encapsulation(draft-ietf-softwire-map)
MAP-T translation(draft-ietf-softwire-map-t)
RFC6145 translation(stateless translation to an IPv4-embedded IPv6 Address)
RFC6146 translation(stateful translation IPv6 clients->IPv4 servers)
DS-LITE(RFC 6333)
Lightweight 4over6(draft-ietf-softwire-lw4over6)
LISP(4 over 6, various RFCs and drafts)

これらの技術に関する経験の集約には、オペレーターからの意見が重要なので、各地のNOG(Network Operators Group)と連携しながら進めていきたいと表明されました。これらの技術の利用が既に始まっている日本から、多くの貢献ができるのではないかと筆者は考えています。

この提案に関連する形で、日本でのMAP-Eの利用状況について、日本ネットワークイネイブラー株式会社(JPNE)の中川あきら氏が発表を行いました。中川氏の発表では、日本におけるIPv6普及状況とIPv6トラフィックが増加していること、JPNEがMAP-Eを選択した理由と現状で特に大きな問題が発生していないことが報告されました。

JPNEがMAP-Eを選択した理由としては、「ステートレスであるためログ収集が不要で運用が楽なこと」「カスタマサポートが容易なこと」「エンド-エンドで通信が可能であること」が挙げられていました。また、「速度測定結果ではIPv6通信とIPv4通信が同程度であること」「ポート利用状況の統計データからユーザーに十分な数のポートが割り当てられていること」「接続判定ページが提供されており、トラブルシュートが容易になっていること」などの実用的な情報提供がされました。

会場の参加者は非常に興味を持っており、スライドの内容について詳しく知りたいという内容の質問が相次ぎました。また、日本のIPv6の普及状況について、日本のコンテンツプロバイダに対してIPv6でのサービスを促してはどうか、という突っ込んだ内容の発言もありました。

インドからは、MAP-Tのトライアルについての発表がありました。発表の構成は中川氏とほぼ同様でしたが、MAP-TとMAP-Eを比較して、「MAP-TはQoS/SLAなど顧客単位のポリシー適合が容易であること」「DPI装置の利用が容易であること」などが挙げられ、国が異なれば選択される技術が異なることが、興味深かったです。

また、中国からは、CERNETとChina Telecom社における、MAP-TとMAP-Eの同時提供のトライアルについての発表がありました。同一のBR(Border Relay)とCPE(Customer Premises Equipment)で、MAP-TモードとMAP-Eモードを自動的に変更できるという、非常にユニークな構成となっています。MAPによるアドレス共有比率について実際のユーザーで試した結果、「1/256(1ユーザーあたり255 port) はOK」「1/512(1ユーザーあたり127 port) では、一部のユーザーに影響があったかもしれない」など、興味深いデータが提供されていました。

2日目のv6ops WGでは、2件のドラフトが、WGLC(Last Call)となることの同意が得られました。

- Some Design Choices for IPv6 Networks(draft-ietf-v6ops-design-choices)

IPv6ネットワークをデザインするにあたり、ルーティングに関してどのような選択肢があり、それぞれにどのようなメリット・デメリットがあるのかを、網羅的に調査したドラフトです。リンクローカルアドレスしか付与されていないインタフェースについて、“unnumbered”と呼ぶか“link-local-only”と呼ぶか(あるいはそれ以外か)という議論に、白熱するという一幕もありましたが、ミーティングでは後者に落ち着き、WGLCをすべきかの採決が行われ、賛成多数となりました。

- Close encounters of the ICMP type 2 kind(near misses with ICMPv6 PTB)(draft-jaeggli-v6ops-pmtud-ecmp-problem)

「ロードバランサ環境下で、ICMPv6type 2“Packet Too Big”(PTB)メッセージ応答が元のサーバに返らない」問題です。こちらもWGLCをすべきかの採決が行われ、賛成多数となりました。

また、データセンター内ネットワークのIPv6化に関して、次のような注目すべき発表が行われました。

- SIIT-DC(draft-anderson-v6ops-siit-eam, draft-ietf-v6ops-siit-dc, draft-ietf-v6ops-siit-dc-2xlat)

“IPv4 as a service”プロジェクトでも取り上げられている、IPv6で構成されたデータセンター内ネットワークにおいて、IPv4での接続性を提供する方法に関する一連のドラフトです。

draft-anderson-v6ops-siit-eamは、RFC6145にて定義され、464XLATではCLAT側で使われている、ステートレスなIPv4/IPv6変換(Stateless IP/ICMP Translation(SIIT))のアドレスマッピングルールを、緩和することを提案するものです。元は、draft-ietf-v6ops-siit-dcに含まれていた内容でしたが、単体で有用と見なされ、切り出されました。

RFC6145では、IPv6アドレス(64:ff9b::/96)の中にIPv4アドレスを埋め込むなど、RFC6052で定義されたマッピングルールしか認めていません。しかし、464XLATで利用するにはこの制約は不都合であるため、任意のIPv6アドレスに静的にマッピングする方法が求められています。事実、Androidの464XLAT実装では、RFC6052のルールを既に使っていないというコメントが会場から出されました。そのため、このドラフトはRFC6145をアップデートするものとして、ワーキンググループドラフトとして採用される予定です。

draft-ietf-v6ops-siit-dcとdraft-ietf-v6ops-siit-dc-2xlatは、共に前回のIETF 91にて、ワーキンググループドラフトに採用されています。例えるならば、データセンター側にステートフルNAT64または464XLATを提供し、IPv4ネットワークからIPv6データセンター内の、IPv6/IPv4サーバに接続できるようにする提案です。特に、464XLATに類似した手法を使った場合、データセンター内でIPv4のみのソフトウェアやデバイスをサポートできるようになります。これらの二つのドラフトは、利用形態やレファレンスが多く重複することから、一つのドラフトとしてまとめられることとなりました。

sunset4 WG(Sunsetting IPv4, Int Area)

sunset4 WGは、IPv6への完全な移行に向けて、アプリケーション・ホスト・ネットワークが、IPv4への依存無しに機能することをめざすWGです。他のWGに対して、プロトコルの策定に際してIPv4に依存しないよう、働きかけを行うことも目標にしています。

前回のIETF 91ではミーティング自体が開催されず、MLの流量も少ないため、残念ながらあまり活発ではなくなってしまったWGです。なぜこちらのWGを取り上げたかというと、“IPv4 as a service”プロジェクトについて、v6ops WGとsunset4 WGのどちらが適切か、という議論があったためです。しかし、両WGの違いはどこなのか、という議論にすり替わり発散してしまったため、特に決定事項はありませんでした。

ワーキンググループドラフトとして、IPv6移行の最終段階においてIPv4を実際に無効化するときの難しさについて列挙したdraft-ietf-sunset4-gapanalysisが残っており、MLで引き続き議論をしていくことが確認されました。