＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.702【臨時号】2009.12.14 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.702 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.699、vol.700に続き、2009年11月に広島で開催された、第76回
IETFのレポート[第3弾]として、「IPv6関連WG報告」をお届けします。

今回の「IPv6関連WG報告」は、前後編に分けての発行となっています。前編と
なる本号は、6man WGとv6ops WGについてのご報告です。

なお、その他の話題につきましては、以下のバックナンバーをご覧ください。

□第76回IETF報告
  ○[第1弾]  全体会議報告(vol.699)
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2009/vol699.html

  ○[第2弾] DNS関連WG報告(vol.700)
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2009/vol700.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第76回IETF報告 [第3弾]  IPv6関連WG報告
   ～6man WG、v6ops WGについて～
                  NTT情報流通プラットフォーム研究所 藤崎智宏／松本存史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、第76回IETFミーティングの会期中に議論されたIPv6に関連したト
ピックスのうち、IPv6に特化した内容を議論するWGでの話題を中心に紹介しま
す。

◆6man WG (IPv6 Maintenance WG)

6manワーキンググループは、IPv6プロトコルのマイナーなメンテナンスを実施
しているWGです。今回のミーティングは、11月10日(火)の午前最初のコマに
て、開催されました。

会議は、前回と同様、チェアよりのミーティングの議題確認および、WGで取り
組み中である文書のステータスについての報告から始まりました。現在、6man
WGにて正式に取り組み中の文書(WG document)は、

・フラグメント重複問題(IESG(*1) review中)
・ノード要求仕様(メーリングリストで議論中、アジェンダからは落ちました)
・アドレス選択(今回、議論されました)
・IPv6推奨アドレス表記(今回、議論されました)
・IPv6サブネットモデル(ワーキンググループラストコール中：ラストコール
  は最終合意のこと。以下、Working Group Last Callを略してWGLCと表記。)
  ※11月14日に終了
・経路制御ヘッダ(WGドラフト化)

の六つとなっています。

今回のミーティングの議題は、

・IPv6アドレスのテキスト表記方法
                           (draft-ietf-6man-text-addr-representation)
・6LoWPANでの近隣探索                         (draft-ietf-6lowpan-nd)
・アドレス選択に関する次へのステップ
    - アドレス選択ポリシー間の矛盾解決
                            (draft-arifumi-6man-addr-select-conflict)
     - アドレス選択デザインチーム議論報告
                         (draft-ietf-6man-addr-select-considerations)
・近隣探索キャッシュの更新について
                          (draft-kitamura-ipv6-neighbor-cache-update)
・P2Pリンクでの/127プリフィクス長の利用
                                     (draft-kohno-ipv6-prefixlen-p2p)
・ノード要求仕様文書に関する議論       (draft-ietf-6man-node-req-bis)
・IPv6のUDPチェックサムついて    (draft-fairhurst-tsvwg-6man-udpzero)

となっています(上記の通り、ノード要求仕様については簡単なコメントのみ
で議論されませんでした)。このうち、いくつかについて簡単に紹介します。

・IPv6アドレスのテキスト表記方法

前回のミーティング、およびその後のメーリングリスト(ML)での議論で、6man
WGとして取り組んでいくことに合意し、今回のミーティングの前にWGLCが終
わっていました。ミーティングでは、IETF75からの変更点について簡単に解説
がありました。会場からのコメントも、文章表現についての簡単なもので、
RFC化に向けて進めることになっています。

・アドレス選択問題について(アドレス選択ポリシー間の矛盾解決)

今回も引き続き、IPv6サイト／ホストがアドレスプリフィクスを複数持った場
合の、アドレス選択のあり方の検討状況報告がありました。前回は、複数の上
流から矛盾するアドレス選択ポリシーが配布された場合の、コンフリクトの解
消(ポリシーのマージ)についての提案・議論がありましたが、今回は、主にポ
リシーを配布するプロトコルについての議論がありました。プロトコルとし
て、ルータ広告、DHCPv6、もしくは経路制御プロトコルのオプションを利用す
る場合の利点、欠点の検討紹介について、どれか一つに決めるべきである、
DHCPv6でも情報をアップデートは可能、といったコメントがありました(その
後、MLでも手法についての議論が延々と続いています)。提案文書について、
より多くのコメントが欲しい、とのことです。

・P2Pリンクでの/127プリフィクス長の利用

現在、アドレスのプリフィクス長に/127を利用することはIPv6の仕様的に問題
があるとされており、/127のプリフィクスを使用することの問題点を記述した
文書(RFC3627)も出版されています。これに対して、特にオペレーションの観
点から、P2Pリンクにて/127より短いプリフィクスを利用することの問題点を
提示し、P2Pリンクでの/127の利用を明示的に可能とすることについての提案
です。リンクローカルアドレスに関する問題等仕様上の注意点が指摘はされま
したが、賛成も多く、今後WGとして継続して議論することになると思われま
す。

・IPv6のUDPチェックサムついて

ここしばらくIETFで議論されている、UDPにおけるチェックサム計算をしなく
てもよいことにする提案に関する議論です。IPv6では、IPv6ヘッダにチェック
サムがないため、IPv4と違ってUDPにおけるチェックサムの計算を必須として
います。しかしながら、UDPを利用したトンネルの際に、トンネルの中を通る
パケットレベルで相当のチェックをしている場合には、外側のUDPでのチェッ
クサム計算が必要ない、途中のルータでトンネルリンクにパケットをフォワー
ドする際に、UDPチェックサムを計算するコストが高くなってしまう、などが
問題とされていました。今回は、計算コストに関する議論、チェックサムを廃
止した場合の影響が検討され、ミーティング中の議論では、UDPのチェックサ
ム処理への変更は実施しない方向となっています。


□6man WG
  http://www.ietf.org/dyn/wg/charter/6man-charter.html

□第76回 IETF 6man WGのアジェンダ
  http://www.ietf.org/proceedings/76/agenda/6man.html

(*1) Internet Engineering Steering Group
     http://www.nic.ad.jp/ja/basics/terms/iesg.html


◆v6ops WG (IPv6 Operations WG)

v6opsはIPv6に関するオペレーション技術や、移行技術に関する議論を実施す
るWGです。今回は、11月10日(火)、11月12日(木)午後最初の、合計2コマにて
議論が実施されています。今回も、数々の新提案があり、内容も多岐にわたっ
ていました。

議論内容は以下の通りです。

11月10日(火)
・家庭向けIPv6インターネットサービス提供用CPEにおける簡易セキュリティ
  推奨機能                     (draft-ietf-v6ops-cpe-simple-security)
  (アジェンダから消されました)
・IPv6 CPEに関する高機能セキュリティ
                                (draft-vyncke-advanced-ipv6-security)
・BitTorrentネットワークでのIPv6トラフィック測定
                         (draft-defeche-ipv6-traffic-in-p2p-networks)
・IPv6 CPEルータ推奨機能           (draft-ietf-v6ops-ipv6-cpe-router)
・IPv6 CPEルータ拡張推奨機能(draft-wbeebee-v6ops-ipv6-cpe-router-bis)
・IPv4/IPv6共存フレームワーク(PET)           (draft-cui-softwire-pet)
・PETでのIPv6からIPv4への通信              (draft-cui-softwire-pet64)
・Internet Exchange(IXP)でのIPv6ディプロイメント
                                           (draft-ietf-v6ops-v6inixp)

11月12日(木)
・ICPに対するISPのIPv6移行サービスのプロビジョンに関する推奨
                                     (draft-qin-v6ops-icp-transition)
・IPv6ディプロイメントに関する新サービスプロバイダシナリオ
                                (draft-carpenter-v6ops-isp-scenarios)
・IPv6移行のための段階的キャリアグレードNAT(CGN)導入
                                  (draft-jiang-v6ops-incremental-cgn)
・ISATAPと6to4における経路ループ：問題提起と解決案
                                   (draft-nakibly-v6ops-tunnel-loops)
・Teredoの拡張 (draft-thaler-v6ops-teredo-extensions)
・IPv4サーバにアクセスするIPv6アプリケーションの構築
                                    (draft-wing-v6ops-v6app-v4server)

いくつかの内容について、簡単に紹介します。

・IPv6 CPEに関する高機能セキュリティ

IPv6 CPEに関する高機能セキュリティは、現在議論中である「簡易セキュリ
ティ推奨機能」(当初、議題には挙がっていましたが、議論はされませんでし
た)に対する、より高度なセキュリティモデルとしての提案です。IPv6ネット
ワークは、IPv4グローバルアドレスを内部にも使っている企業ネットワークと
同等であり、セキュリティポリシーを考える際に、企業で利用しているポリ
シーが参考にできると考えて、七つのホームネットワーク用セキュリティポリ
シーを提案しています。特に、CPEデバイスを外部から動的にアップデートす
ることで、より強固なセキュリティを担保できるようにすることの必要性を強
調していました。提案に対する賛成意見もありましたが、一方で、これはIPv6
に特化したものであるのか、また、動的アップデートには標準等は必要ないた
め、IETFでなく、ブロードバンドフォーラム等で議論すべき内容ではないかと
の反対意見もあり、提案に対する賛成、反対も含め、MLで継続議論となりまし
た(火曜日のセッション終了後、継続議論されています)。

・IPv6 CPEルータ推奨機能、IPv6 CPEルータ拡張推奨機能

ここ数回のIETFで議論を続けている、IPv6対応のCPEルータが持つべき機能に
関する提案です。今回から、検討事項が多い部分を拡張機能として別ドラフト
(フェーズ2ドラフト)に切り出し、WANとLANの設定や、基本的なルータ機能、
セキュリティ機能のみを基本部分として分離しています。基本部分のドラフト
については、MLにて意見を集め、それを反映後にWGLCを実施することとなりま
した。フェーズ2ドラフトの議論項目としては、マルチキャスト、DNS、プレ
フィックスの再委譲、IPv6移行機能、パケットフィルタ、QoS等が挙げられて
おり、議論を継続していくこととなりました。

・Internet Exchange (IXP)でのIPv6ディプロイメント

IXPにおけるIPv6導入モデルは、3度目の発表となります。今回は、AMS-IXで導
入されている、余計なARPトラフィックを減少させるための仕組みであるARPス
ポンジと同等の機能を、IPv6で実装する方法についての検討報告がありまし
た。ARPスポンジは、多くのIXPで導入されているそうです。IPv6では、近隣探
索プロトコルへの対応となりますが、アドレス長の違い、利用されていないア
ドレスが広大なことによる必要資源の増加等が問題となるようです。会場から
は、この問題はIXPに特有でなく一般的な問題である、利用されていないアド
レス対策が必要なら、/64より長いプリフィクスを使ったらどうか、といった
質問がありました。コメントを反映して改版後、WGLCに進むことになりまし
た。

・ICPに対するISPのIPv6移行サービスのプロビジョンに関する推奨

ICPをどのようにIPv6対応にしていくべきかをまとめようとしている提案で
す。利用できる移行機構(デュアルスタック、NAT64、IVI)を列挙し、利用でき
るツール等をまとめることを目的としています。会場からは、重要な観点であ
り、利用可能な技術を集めて情報共有をすることは意味がある、という意見
や、重要ではあるが、多くのプロトコルは現状、標準化中であったり、どれが
よい、と選べるものではなかったりと、まとめ方には注意が必要だ、といった
意見がありました。今後デザインチームを作って、各機構、ツールの利点、欠
点、ユースケース等を議論することになっています。

□v6ops WG
  http://www.ietf.org/dyn/wg/charter/v6ops-charter.html
  http://www.6bone.net/v6ops/

□第76回 IETF v6ops のアジェンダ
  http://www.ietf.org/proceedings/76/agenda/v6ops


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.702 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  http://www.nic.ad.jp/
■■

Copyright(C), 2009 Japan Network Information Center