JPNIC News & Views vol.476【臨時号】

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

本号では、vol.470、vol.471に引き続き、第69回IETFのレポート[第3弾]とし
て、IPv6関連WGの動向についてお届けします。

□第69回IETF報告 特集
○[第1弾] 全体会議報告 (vol.470)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol470.html
○[第2弾] DNS関連WG報告 (vol.471)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol471.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第69回IETF報告 [第3弾]  IPv6関連WG報告
                                   JPNIC IPアドレス検討委員会メンバー/
                                     NTT情報流通プラットフォーム研究所
                                                              藤崎智宏
                                     NTT情報流通プラットフォーム研究所
                                                              松本存史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2007年7月22日(日)から7月27日(金)まで、米国シカゴにて第69回IETFミーティ
ングが開催されました。本稿では、会期中に議論された、IPv6に関連したト
ピックスをいくつか紹介します。

◆dhc WG (Dynamic Host Configuration WG)

DHCP/DHCPv6の機構および新規オプションの定義に関する話題を扱う、dhc WG
のミーティングは、月曜日朝一番目のコマで開催されました。今回のミーティ
ングで大きな議論になったのは、'Extensions to DHCPv6 for prefix and 
default router information'というタイトルで報告された、DHCPv6の拡張に
関する話題です。IPv6では、ネットワーク上に接続されているルータのIPアド
レスを通知するために、ルータ広告(RA, Router Advertisement)メッセージを
用いますが、設定ミスなどによりこのメッセージを不正に出してしまうノード
が存在すると、IPv6通信が阻害されてしまいます。実際に、イベント会場など
でこの問題はよく発生しています。また、故意にRAを送信し、他人のパケット
を不正中継するなどといったことが可能になってしまうという問題もありま
す。この問題に対して、IPv4と同じく、ルータの情報をDHCPv6にて配布するこ
とで解決してはどうかという提案です。この提案に対しては、IPv6の基本仕様
にまで影響することや、仮にDHCPv6を利用してルータ情報を配布したとして
も、問題の完全な解決にはならないこと(DHCPサーバの認証が必要になる)、他
にも取り得る方法(RAをセキュアにするプロトコルを使用するなど)が存在する
ことから、DHCPv6でルータ情報を配布することに関しては、見送りとなりまし
た。同じ話題が、v6ops WGでも議論されています。

□dhc WG
  http://www.ietf.org/html.charters/dhc-charter.html

□第69回 IETF dhc WGのアジェンダ
  http://www3.ietf.org/proceedings/07jul/agenda/dhc.html


◆v6ops WG (IPv6 Operations WG)

IPv6とIPv4の共存技術、IPv6のデプロイメントに関する話題を扱うv6ops WGの
ミーティングは、初日、午後一番目のコマにて開催されました。今回は、チェ
アより簡単に現在のWGドキュメントステータス(「RFCエディタに提示中」「AD
預かり」「ワーキンググループラストコール(WGLC)終了」)の説明がありまし
た。

その後、本題として主に、

1. 始点アドレス選択
2. CPE セキュリティに関する話題
3. Teredo に関する話題
4. DHCP に関する話題

の4項目について議論されました。

1.については、問題提起に関するドラフト(draft-ietf-v6ops-addr-select-ps)
と、解法に関する要求条件ドラフト(draft-ietf-v6ops-addr-select-req)が前
回WGLCとなっており、筆者から、メーリングリストで受けたコメントの紹介、
ドラフト改版案が提示されました。この2ドラフトについては特にコメントが
無く、次のステップに進むことになりました。その後、始点アドレス選択問題
の解法として、draft-arifumi-v6ops-addr-select-solドラフトについて、説
明および議論が実施されました。解法については、「デプロイメントまで考え
ると、どの解法も実施困難である」「そもそもマルチプリフィクスは無用」
「一つの解では全ての場合をカバーできないので場合に応じた解法が必要」と
いった意見が出されました。この解法ドラフトに関しては、WGアイテムとして
取り上げるコンセンサスは得られず、継続議論となっています。

2.は、小規模オフィスやホームネットワーク環境での、CPEデバイスのあり方
に関する議論です(draft-ietf-v6ops-cpe-simple-security)。IPv4のNATによ
るセキュリティの担保や、CPEへの穴あけプロトコル(UPnPなど)が、IPv6環境
ではどのようにあるべきかについて、議論されました。ファイアウォールは必
要無い、その理由として、「ファイアウォールの存在はIPv6にもNATを持ち込
むことになってしまいかねない」「ホストがガードすべき」といった意見や、
「実際にそのような環境で日々過ごしており、問題無い」といった意見が表明
されました。議論は収束せず、ML上で継続議論を実施することになりました。

3.は、teredoのセキュリティに関する問題提起です。
(draft-hoagland-v6ops-teredosecconcerns-01)
Teredoは、NATを超えてIPv6 over IPv4トンネルを実現するプロトコルであ
り、Windows Vista等に標準で実装されています。Teredoを使うと、意図せず
Firewall/NAT等をバイパスされてしまう可能性があることから、これがセキュ
リティリスクになり得ることを指摘しており、管理者は、「Teredoの使用を禁
止する」「Teredoパケット(UDP)をフィルタする」等の方策を取ることを推奨
しています。このドラフトは、WGアイテムとして議論されることになっていま
す。

4.は、同日午前中のdhc WGで議論されたものと同一のプレゼンテーションが実
施されました。v6ops WGでは、解決策として、DHCPv6サーバの認証やSEND(RA
をセキュア化するプロトコル)の利用をすべきであり、DHCPv6でルータ情報を
配布することは問題を悪化させるだけである、という意見が主流を占めまし
た。

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

□第68回 IETF v6ops WG のアジェンダ
  http://www3.ietf.org/proceedings/07mar/agenda/v6ops.txt


◆その他

vol.470のIETF Operations and Administration Plenaryの紹介でも触れられ
ていましたが、オンサイトミーティングを実施せず、既存IPv6仕様の標準化等
のみを進めていくことになっていたIPv6 WG について、IPv6 WGとして活動が
必要な話題が最近出てきていることもあり、次回のバンクーバーミーティング
にて、新IPv6 WGのミーティングが実施されることになっています。現在の
IPv6 WGはクローズし、新たにIPv6のメンテナンスのみを目的としたWGが設立
される予定です。(既にミーティング中に、新たなWGが提案され、(IPv6
Maintenance Working Group(6man))取り組み内容について、議論が始まってい
ます)


◆ ram(rrg)

前回の第68回IETFミーティングでは、intareaセッションでID/Loc Separation
BoFが開催され、デフォルトフリーゾーンにおけるルーティングスケーラビリ
ティ問題について検討が行われたことは、前回報告した通りです。その後も
ram(Routing and Addressing)やrrg(Routing Research Group)といったメーリ
ングリストで、ID/Loc分割に基づくさまざまな提案について議論が行われまし
た。今回のIETFミーティングでは、最終日の金曜日に丸一日rrgのセッション
を使って、主にramのメーリングリストで行われている提案について、発表や
議論が行われました。

このルーティングスケーラビリティの問題は、IPv6のみに関係するものではな
く、IPv4では既に問題が顕在化し始めています。IPv6ではIPv4に比べてさらに
状況が悪化することも予想されており、現在そして今後のインターネットを占
う重要なトピックであるといえます。

まずrrgのチェアであるTony Li氏から、設計目標についてのドラフトのアップ
デート状況について発表があった後、Lixia Zhang氏から解決アプローチの分
類学について発表があり、IDとLocatorのマッピングの管理方法、通信障害の
検出・使用方法について、各種方式の分析が行われました。

また、rrgということでリサーチグループよろしく、研究論文の紹介も2件ほど
行われました。一つはケンタッキー大学からの発表で、階層化されたルーティ
ングとフォワーディング方式により、スケーラビリティを高めるといった研究
が提案されました。また、ベルギーのルーバンカトリック大学からは、ID/Loc
分離を実際に行った場合の、IDとLocatorのマッピングキャッシュサイズや、
マッピング解決に必要なトラフィック等のコストに関する研究が発表されまし
た。コスト見積もりには、LISPと呼ばれるID/Loc 分離プロトコルを例に取
り、大学ネットワークで観測されたユーザートラフィックとBGP経路表が用い
られ、キャッシュのタイムアウト時間にも依存するものの、既存のDNSのよう
な枠組みでマッピングシステムが実現可能であることなどが示されました。

本セッションのメインである、ID/Loc分離方式に関する議論では、大きく分け
てLISPとSIX/Oneと呼ばれる方式が発表されました。LISPとは、Locator
Identifier Separation Protocolの略で、通信を行うホストが位置するサイト
のゲートウェイルータ(トンネルルータ)同士で、パケットのカプセル化/デカ
プセル化を行うことにより、ホストには一切変更を加えずにマルチホームを実
現するというものです。サイト内で使うアドレスがIdentifier、トンネルルー
タに付与されパケットのカプセル化に用いられるアドレスがLocatorとして機
能することになります。SIX/One方式は、これまでIETFのshim6ワーキンググ
ループで検討されてきた、ホストによって実現されるマルチホーム方式である
shim6プロトコルをベースとし、途中のルータでパケットのアドレスフィール
ドを変更することを許容するというものです。これにより、shim6の弱点とさ
れていた、ISPなどにおけるサイト管理者のポリシーを反映したマルチホーム
を行うことが可能となりますが、ホストのプロトコルスタックに変更を加えな
ければならないという点は変わりありません。これら以外にも、LISPの変更・
拡張方式である、APT、LISP-CONS、LISP-NERDなどの発表が行われ、活発な議
論が行われました。

特に、LISP方式はramのメーリングリストでも最も注目を集めており、また実
装も既に開始されるなど、IETFとしては非常に短いタイムスケールで実用化に
向けた活動が行われているように思われます。今後、オペレーターコミュニ
ティなどで意見を吸い上げ、いかに効果的で実用可能な方式を策定できるか
が、成功のポイントになることでしょう。

□ 第69回IETF rrgのアジェンダ
   http://www3.ietf.org/proceedings/07jul/agenda/RRG.html

□ 第69回IETF rrgの発表資料
   https://datatracker.ietf.org/meeting/69/materials.html


第69回IETFミーティングの各種情報は、以下のURLより参照可能です。

□ 全体プログラム、WGアジェンダ、発表資料
   https://datatracker.ietf.org/meeting/69/materials.html

□ 録音
   http://videolab.uoregon.edu/events/ietf/


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【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.476 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


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

Copyright(C), 2007 Japan Network Information Center
このページを評価してください
