ニュースレターNo.37/2007年11月発行

IPv6関連WG報告

本稿では、会期中に議論された、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）終了」）の説明がありました。

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

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

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

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

写真:Registration Desk — 受付デスク(Registration Desk)の様子

（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/
□第69回 IETF v6ops WG のアジェンダ: http://www3.ietf.org/proceedings/07jul/agenda/v6ops.txt

その他

全体会議報告で紹介した、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より参照可能です。