ニュースレターNo.55/2013年11月発行

IPv6関連WG報告〜6man WG、softwire WG、behave WG、v6ops WG、sunset4 WGについて〜

本稿では、ドイツのベルリンで開催された、第87回IETF会合におけるIPv6関連のWGとして、6man WG、softwire WG、behave WG、v6ops WG、sunset4 WGの五つのWGにおける議論の概要と、SA46T/SA46T-PR/SA46T-PT提案について報告いたします。

6man WG(IPv6 Maintenance WG)

6man WGは、IPv6の基本仕様のメンテナンスを行うWGです。IPv6アドレスのプライバシーに関連する議論や、連鎖可能な最大拡張ヘッダ数に関する議論のほか、IPv6フラグメントヘッダの廃止についての興味深い議論が行われました。特に、IPv6フラグメントヘッダの廃止は重要なテーマですので、少し長くなりますが、詳しく報告します。

インターネットは、さまざまな種類のデータリンクを相互接続して構成されますが、最大フレーム長はデータリンクにより異なります。そのため、大きいフレームを扱えるリンクから、それより小さいフレームしか扱えないリンクにパケットを転送する際、サイズが超過し転送できない場合があります。その際、小さいフレームにパケットを分割して転送します。この分割の処理を、フラグメンテーションと呼びます。

IPv4では、当初、ルータにてフラグメンテーションを行う仕様でしたが、ネットワークの高速化に対応するために、PMTUD(Path MTU Discovery)という、パケットを発信するホストでフラグメンテーションを行う仕様が追加されました。ルータでのフラグメンテーションとPMTUDのどちらを用いるかは、パケットを発信するホストが選択します。IPv6では、後者のPMTUDが前提となっており、ルータはフラグメンテーションを行いません。

PMTUDでは、パケットを次ホップに転送できなかった場合、そのルータはパケットを廃棄し、ICMPエラーメッセージに、転送可能な最大フレーム長(MTU)を格納して発信ホストに返信します。以後、このホストは、通知されたMTUに合わせてパケットをフラグメンテーションして送信します。

ところで、インターネット上にはICMPメッセージをフィルタ、つまり廃棄するネットワークが存在すると言われています。ICMPをフィルタしてしまうと、PMTUDで用いられるICMPエラーメッセージもホストに返信されなくなります。よって、ホストはいつまでたっても廃棄されることになるパケット長で送信を繰り返し、それがルータで廃棄されますので、いつまでたっても通信は成功しません。このような状態をPMTUDブラックホールと呼びます。

この問題を回避するために、現在のIPv4環境では、TCP MSS(Maximum Segment Size)と呼ぶ、上位のトランスポート層であるTCPでのデータ長のネゴシエーション機能を操作するか、もしくはルータでフラグメンテーションをさせ、PMTUDを用いない制御を行うといった、先祖帰りのような方法が採られています。前者はTCPには有効ですが、UDPやGRE(Generic Routing Encapsulation)トンネルには効果はありません。しかも、IPv4だけでなくIPv6にも影響します。また、後者の対応はIPv6では規定されていませんので、取りようがありません。なお、IPv4では機能したとしても、性能が劣化することになると考えられます。

また、v6ops WGにて議論されている、“Why Operators Filter Fragments and What It Implies”によると、IPv6のフラグメント化されたパケット、つまりフラグメントヘッダが付いているパケットすら、廃棄するネットワークが存在するようです。これは厳密には、PMTUDが機能しても、フラグメント化されたパケットは廃棄されるという別の問題ですが、フラグメンテーションが機能するための環境が、思いのほか厳しいものであると言えそうです。

今回行われた議論は、「機能しないなら、いっそのことネットワーク層の機能として廃止してしまえ」というものです。フラグメンテーションは必要ですので、もし廃止されてしまえば、そのしわ寄せは上位層、つまり、トランスポート層もしくはアプリケーションに向かうことになります。RFC4821の“Packetization Layer Path MTU Discovery”はその候補です。

6man WGにおけるこの検討はIPv6のみに限定していますが、IPv6の通信だけではなく、カプセル化やIPv4-IPv6変換などの移行技術にも関連します。そして、実はIPv4環境でもUDPは対応できませんので、DNSSECの普及にも影響する可能性がありそうです。

ところで、筆者はSA46Tを提案しており、実験等を行いますが、実際、通信できないサイトに出くわすことがあります。TCP MSSを操作することにより通信できるようになるので、このサイト、もしくは、このサイトの経路上のネットワークで、ICMPエラーがフィルタされているものと推測しています。もちろん、TCP MSSを操作しなくても通信できるサイトもたくさんありますので、ICMPエラーがきちんと返送されるサイトもしくはネットワークも存在します。ICMPエラーの廃棄は、推測の域を出ませんが、しかし、実際に出くわす現象です。

このように、フラグメンテーションはIPv6だけではなく、IPv4にも影響を及ぼす、インターネット全体に関わる問題ですので、IETFのような標準技術の開発コミュニティだけではなく、運用コミュニティとの連携など、業界を挙げた問題解決が必要なのではないかと思います。私自身はやはり、PMTUDがきちんと動作することがインターネット全体の利益になると思いますし、TCP MSSによる解決策は、抜本解というより緊急避難的なものに思えます。このフラグメントヘッダの廃止提案は、建設的な提案というより悲鳴に聞こえました。この解釈は人によって異なるかもしれません。何が問題なのかの整理が必要になっていそうです。並行して、実態の把握が必要でしょうし、なぜPMTUDに関連するICMPエラーが廃棄されるかについても、原因の調査が必要でしょう。原因が分かれば対処できるかもしれません。もし、どうしてもICMPエラーをフィルタしたいなら、少なくとも、1,500ByteのIPパケットの転送を保証すべきというような解決策もあり得るかもしれません。

繰り返しになりますが、この問題に関しては、問題をきちんと定義し、実態を把握し、原因を突き止め、問題を解決していく必要があると思います。インターネットをきちんと動かし続けるためには、業界連携、つまり業界の果たすべき役割があるように思えます。いかがでしょうか。ご意見をお待ちしています。

softwire WG(softwire WG)

今回は、MAP-Eに関する議論は行われず、LW4o6、4rd、MAP-Tについての提案が行われたほか、DHCP関連の提案がなされました。大きな流れとしては、unified CPEの標準化に焦点が移っているように感じます。

なお、筆者の提案である、SA46T、SA46T-PR、SA46T-PTがアジェンダに含まれていましたが、アジェンダの消化率が65％でした。そのためほかの多くの提案同様、議論に至らずミーティングが終了しました。

behave WG(Behavior Engineering for Hindrance Avoidance WG)

今回、IPv4 onlyクライアントから、IPv6 onlyサーバにアクセス可能とする、NAT46の提案がなされました。この前提は、サーバに割り振るIPv4アドレスが枯渇し、一方クライアント側は依然としてIPv4アドレスを利用している状況に対応するものです。筆者もこのような状況を想定し、SA46T-AS(SA46T Address Sharing)を提案しています。

検討が一段落したためか、しばらくWGの開催はありませんでしたが、今回の会議では、提案が増えてきていると感じました。なお、前回のオーランド会議で、筆者はSA46T-AT(SA46T Address Translator)という技術の提案を行っています。

v6ops WG(IPv6 Operation WG)

Teredoサーバの停止に関する報告や、Happy Eyeballsの効果測定、NAT64の運用に関する報告などが行われました。また、慶應義塾大学の中村修先生が、NAT64環境を想定し、URLでのIPv4アドレス表記に関する提案を行いました。

sunset4 WG(Sunsetting IPv4 WG)

奈良先端科学技術大学院大学の櫨山寛章先生が、IPv6 onlyネットワーク環境での利用を想定した、DNS Aレコードのフィルタリングに関する提案を行いました。この提案は、WIDE合宿での実験をベースにしており、説得力があり、多くの方から興味を持たれました。

また今回は、DHCP WGとのjoint meetingが開催され、DHCPv6を用いてIPv4を停止する提案、DHCPv4 over DHCPv6などの議論がなされました。

SA46T/SA46T-PR/SA46T-PT提案について

今回のSA46T/SA46T-PR/SA46T-PT提案のスライドは、以下のURLにて参照できます。

http://tools.ietf.org/agenda/87/slides/slides-87-softwire-20.pdf

SA46T-PRとSA46T-PTは、今回はじめてIETFに提案しましたが、一足早く、Interop 2013 Tokyoにてデモンストレーションを通じてご紹介いたしましたので、既にご存知の方もいらっしゃるかと思います。

今回のIETFでの提案に関し、実は、富士通は特許の扱いに関する方針転換を行いました。SA46Tに関しては特許が成立しており、IETFへの提案に際し「妥当で公平なライセンス」であるRAND(Reasonable and Non Discriminatory Licensing)条件のStatementを提出していました。これに対し「RAND条件ではIETFでの標準採用は難しいのでは」というアドバイスをいただくなどしていたため、今般、Non-assertion条件に変更を行いました。興味のある方は、IETFに提出されているPatent Statementをご覧ください。