=================================== __ /P▲ ◆ JPNIC News & Views vol.1039【臨時号】2012.12.11 ◆ _/NIC =================================== ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ News & Views vol.1039 です ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本号では、vol.1036、vol.1037に続き、第85回IETFのレポート[第3弾]とし て、IPv6関連WGの動向についてお届けします。 発行済みの全体会議やDNS関連WGの報告については、バックナンバーのページ に掲載していますので、以下のURLからぜひご覧ください。 □第84回IETF報告 特集 ○[第1弾] 全体会議報告 (vol.1036) http://www.nic.ad.jp/ja/mailmagazine/backnumber/2012/vol1036.html ○[第2弾] DNS関連WG報告 (vol.1037) http://www.nic.ad.jp/ja/mailmagazine/backnumber/2012/vol1037.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ 第85回IETF報告 [第3弾] IPv6関連WG報告 ~6man WG、softwire WGについて~ NTTサービスインテグレーション基盤研究所 ネットワーク技術SEプロジェクト 松本存史 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 米国アトランタで開催された第85回IETFでのWGの中で、筆者が会合に参加し てきたWGの中から、IPv6への移行技術などについて活発な議論が行われてい る、6manWGとsoftwire WGの二つの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のrapid commit(急速コミット)を用いることで、やり取りする メッセージ数は同じく減らせるはずだ、セキュリティを考慮すればメッセー ジ数は減らせないのではないか、などの意見がありました。本提案も会場で の挙手をすること無く、継続議論となっています。 ◆ 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通信方式で すが、今回の議論により、もう少し標準化に時間を要する可能性も出てきま した。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ わからない用語については、【JPNIC用語集】をご参照ください。 http://www.nic.ad.jp/ja/tech/glossary.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ ◆◇◆◇◆ 本号のご感想をお聞かせください ◆◇◆◇◆ ┃ ┃良かった ┃ ┃→ http://feedback.nic.ad.jp/1039/f18dccac1d65f49f877900508dd61c0d┃ ┃ ┃ ┃悪かった ┃ ┃→ http://feedback.nic.ad.jp/1039/66b76514458d6753eaa0842123ee553c┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ___________________________________ ■■■■■ JPNICの活動はJPNIC会員によって支えられています ■■■■■ ::::: 会員リスト ::::: http://www.nic.ad.jp/ja/member/list/ :::: 会員専用サイト :::: http://www.nic.ad.jp/member/ (PASSWORD有) □┓ ━━━ N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□ ┗┛ お問い合わせは jpnic-news@nic.ad.jp まで ┗┛  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ =================================== JPNIC News & Views vol.1039 【臨時号】 @ 発行 社団法人 日本ネットワークインフォメーションセンター 101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F @ 問い合わせ先 jpnic-news@nic.ad.jp =================================== ___________________________________ 本メールを転載・複製・再配布・引用される際には http://www.nic.ad.jp/ja/copyright.html をご確認ください  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 登録・削除・変更 http://www.nic.ad.jp/ja/mailmagazine/ バックナンバー http://www.nic.ad.jp/ja/mailmagazine/backnumber/ ___________________________________ ■■■■■ News & ViewsはRSS経由でも配信しています! ■■■■■ ::::: http://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ■■◆ @ Japan Network Information Center ■■◆ @ http://www.nic.ad.jp/ ■■ Copyright(C), 2012 Japan Network Information Center