ニュースレターNo.53/2013年3月発行

IPv6関連WG報告～6man WG、softwire WGについて～

6man WG (IPv6 Maintenance WG)

6manは、IPv6仕様の軽微なメンテナンスを行うWGです。新たなトピックを含め、今回のセッションでは、九つのドキュメントについて議論が行われました。そのうち、新規のものやWGアイテム採択が決まったものなどを中心に、概況をお伝えします。

1. Distributing Address Selection Policy using DHCPv6
(DHCPv6を用いたアドレス選択ポリシー配布)
draft-ietf-6man-addr-select-opt-06.txt

この提案は、筆者が提案しているものです。WGLC(WG最終合意確認)を終え、そこで出た意見などの報告を行いました。本提案は、RFC6724で規定されたホストにおけるIPv6アドレス選択ルールを、ネットワーク側から配布するポリシーで変更できるようにするものです。大きな変更を求める意見はなく、ネットワークから受信したポリシーが期限切れになった際に、デフォルトポリシーに戻すべきなのか、それとも、ポリシーを受信する前に有効であったポリシーに戻すべきなのか、といった議論の状況が共有されました。本提案のドラフトは、エディトリアルな修正の後、次の段階であるIESGレビューへと進む予定になっています。

2. Efficiency aware IPv6 Neighbor Discovery Optimizations
(効率性を考慮したIPv6近隣探索最適化)
draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

6lowpanという、低消費電力でIPv6通信を行う方式を検討するWGにおいて策定された通信方式を、6lowpan専用のネットワークだけでなく、通常のホストが存在するようなネットワークにおいても使用できるようにしようという提案がありました。6lowpan-ndと呼ばれるRFC6775で規定された本方式は、

• 定期的なマルチキャストRAを用いない
• DAD(重複アドレス検出)ではなくARO(アドレス登録オプション)を用いる
• マルチキャストNS(近隣要請)を用いない

などの特徴があり、これらによって、消費電力を抑えながらIPv6のローカルネットワーク内通信を実現しています。本提案は、ルータが送信するRAにフラグ(Eビット)を付加し、このフラグを用いて、6lowpan-nd対応のネットワークであることを通知し、6lowpan-nd対応のホストがAROやユニキャストRS/NSを用いることで、常時RA/NSメッセージを受信する必要なく動作することを可能にしようというものです。

しかし、6manでのセッションでは、興味を持った参加者が少なかったのか、マイクでの議論もなく、WGアイテムとして採用するかどうかという問いかけに対しても、ほんの数名程度が賛成するにとどまりました。今後、MLで議論を継続することになっています。

3. IPv6 RA Options for Multiple Interface Next Hop Routes
(複数インタフェースで複数のネクストホップ経路を扱えるIPv6 RAオプション)
draft-sarikaya-mif-6man-ra-route-01.txt

RFC4191では、RAに経路情報を含めるオプションが規定されていますが、ここにネクストホップのアドレスを記述することはできず、RAの送信元のアドレスがネクストホップとして利用されることになっています。この仕様では、RAを送信するルータ以外のルータをネクストホップとするような経路を配ることができないため、RFC4191を拡張し、ネクストホップ情報を記述できるようにしようという提案がありました。

セッションで挙げられた意見としては、現在RFC4191で実現できているfate sharingが損なわれる、つまりルータがダウンした場合に経路も広告されなくなるので、ルータの死活と経路の死活が連動する、という特性が損なわれてしまうというものや、他のネクストホップの経路を広告するのではなく、他のネクストホップに経路広告を促すようなメッセージを規定した方がいいのではないか、などがありました。本提案はWGアイテム採択の挙手は行われずに継続議論となりました。

4. Prefix Delegation extension to Neighbor Discovery protocol
(近隣探索プロトコルへのプリフィクス配布拡張)
draft-kaiser-nd-pd-00.txt

現在、プリフィクスの配布はDHCPv6を用いる方式が規定されていますが、ND(近隣探索)を用いてこれをできるようにしようという提案がありました。NDを用いることの利点としては、DHCPv6の実装はまだ広く普及していないがNDは普及していること、やり取りするメッセージ数が4個ではなく2個でよいため、速く設定が完了すること、などが挙げられました。会場からの反応としては、DHCPv6のrapidcommit(急速コミット)を用いることで、やり取りするメッセージ数は同じく減らせるはずだ、セキュリティを考慮すればメッセージ数は減らせないのではないか、などの意見がありました。本提案も会場での挙手をすること無く、継続議論となっています。

softwire WG

softwireは、IPトンネルを用いてアクセス網などのネットワークを構成する技術を扱うWGですが、ここ数年はもっぱら、ISPなどのアクセス網におけるIPv4アドレス在庫枯渇対策・IPv6移行促進技術についての議論がメインのトピックとなっています。

1. Mapping of Address and Port with Encapsulation (MAP-E)
(カプセル化を用いたアドレスとポートのマッピング(MAP-E))
draft-ietf-softwire-map-02.txt

前回のIETFミーティングにおいて、MAP-Tや4rdなどの競合方式よりも多くの支持を集め、MAP-Eはスタンダード、MAP-Tおよび4rdはエクスペリメンタル(実験的)な寄書とすることが決まりました。今回のMAP-Eの発表では、MAP-Eの寄書に関する各種論点を「issue tracker」というウェブツールを用いて管理しており、その状況について報告がありました。issueのほとんどは、仕様に変更をもたらすものではなく、文章の記述の修正で済むようなものでした。アドレスとポートマッピングのアルゴリズムについては、複雑であるという問題点が指摘されており、仕様を単純化することも含めて検討されましたが、設定や用途の柔軟性を犠牲にすることになるため、文書の記述を見直すという意見が出されました。今後、今回議論された修正を盛り込んだ改版をもって、WGLCが行われる見込みです。

2. Lightweight 4over6: An Extension to the DS-Lite Architecture
(軽量IPv4オーバーIPv6：DS-Liteアーキテクチャへの拡張)
draft-cui-softwire-b4-translated-ds-lite-09.txt

今回のsoftwireのセッションで、大きな議論が行われたのが本提案でした。DS-Liteでは、AFTRと呼ばれる網側のトンネル終端装置においてNATを行うため、フロー単位のセッション情報をここで保持することになります。本発表では、ユーザーごとにアドレスとポート範囲を割り当て、NAT機能をB4と呼ばれるユーザー側のトンネル終端装置に移動させ、網側ではセッション情報を保持せず、どのユーザーにどのアドレスとポート範囲を割り当てたか、という情報のみを管理する、という方式を提案しました。利点としては、網側の装置をステートレスにするというMAP-E/MAP-T/4rdなどの方式と類似点が多く、これらの方式との差別化ポイントとしては、ユーザーごとにアドレスやポート数などを個別設定したり、変更したりすることが容易であること、また1ユーザーに1アドレスを割り当てる、1:1モードと呼ばれる設定に関しては、MAP-E等の方式のような複雑さが軽減される、といったことが主張されました。

会場からは、

• MAP-EやMAP-Tの方式は複雑ではなくMAP-Eの1:1モードで良いのではないか
• 柔軟性と拡張性は二律背反にあり、すべてのユーザーのニーズに合うように方式をカスタマイズすることは現実的ではない
• 同じ問題を解くための方法は一つにするべきだ

などの意見があり、最後にはArea Directorからの提案で、MAP-Eを拡張することで、このLightweight 4over6が解こうとしている問題を解くことができないのかどうかを集中的に検討しよう、ということになりました。前回のIETFミーティングで決着したかに見えたステートレスIPv4 over IPv6通信方式ですが、今回の議論により、もう少し標準化に時間を要する可能性も出てきました。

(NTTサービスインテグレーション基盤研究所ネットワーク技術SEプロジェクト 松本存史)