NTT情報流通プラットフォーム研究所 藤崎 智宏／松本 存史

1. 第69回IETF概要

　2007年7月22日(日)から7月27日(金)まで、米国シカゴにて第69回IETFが開催された。プレナリ(毎回、水曜日夕刻に開催される全体ミーティング)中の報告では、今回は世界40カ国から1,146名が集まったとのことである。(チェコのプラハで開催された第68回で、45カ国、1,129名の参加)。人数的に、ここ数回ほぼ1,100人程度で推移している。図1に、参加者の変遷を示す。参加者の国別割合(図2)については、米国、日本が多いというのは前回と同様である。

2. IEPG (Internet Engineering and Planning Group)ミーティング

　IETFは通常、会期中最初の日曜日午後から開始となる。それに先だって、日曜日の午前中に、IEPGミーティングが開催される。IPEGミーティングは、主にインターネットオペレーションやアドレス管理関連の話題が取り上げられることが多い。今回は、IPv6関連の発表が数件あった。中でも、Randy Bush氏によるIPv6への移行の話題、「IPv6 Transition & Operational Reality」は。「IPv4アドレスが枯渇する」、「IPv6への移行は簡単である」、「IPv6はNATをなくす」、「IPv6は経路制御の負荷を下げる」、といったような様々な問題を「神話」というもじりで紹介し、今後IPv6をデプロイしていくためにしなければならないことを領域別(サーバ、企業、アプリケーション等)にあげており、非常に興味深かった。時間がなく議論があまりなかったのが残念である。その他、IPv6導入に関する実例紹介や、IPv4アドレス枯渇に関する話題について発表があった。発表資料は、IEPGのWebページからたどることができる

□IEPG の web ページ
http://www.iepg.org [1]

3. dhc WG (Dynamic Host Configuration WG)の動向

　dhc WGでは、DHCP(v4)、DHCPv6自体の機構や、新規オプションの定義に関する話題を扱う。IPv6関連では、DHCPv6のテストツールの紹介と、IPv6のディフォルトルータ情報のDHCPv6での配布に関する話題があった。

　DHCPv6テストツールは、IPv6の仕様に関するコンフォーマンステストを実施しているTAHIプロジェクトから紹介があった。当該ツールを利用することで、DHCPv6サーバ・リレーエージェント・クライアントの実装がDHCPv6の基本スペックに合致しているかどうかを確認することができる。また、DHCPv6について、IPv6 Ready Logoの付与が開始されているという報告もあった。ツールによる実装の試験状況についての報告もあったが、クライアント実装がまだそれほど多くないとのことである。

　今回大きな議論になったのは、「Extensions to DHCPv6 for prefix and default router information」というタイトルで報告された DHCPv6の拡張に関する話題である。IPv6では、ネットワーク上に接続されているルータのIPv6アドレスを通知するために、ルータ広告(Router Advertisement/RA)メッセージを使用する。設定ミスなどによりこのメッセージを不正に出してしまうノードが同一セグメント上に存在した場合、IPv6による通信が阻害されてしまう可能性がある。実際に、IETF会場のネットワークや、多くのイベント会場などでこの問題は多発している。また、事故でなく、故意にRAを送信し、他人のパケットを不正中継するなどといったことも可能になってしまうという問題もある。

　この問題に対して、IPv4と同じく、ディフォルトルータの情報をDHCPv6にて配布することで解決してはどうか、ということが提案された。この提案に対しては、IPv6の基本仕様にまで影響することや、仮にDHCPv6を利用してルータ情報を配布したとしても、問題の完全な解決にはならないこと(DHCPサーバの認証が必要になる)、他にもとりうる方法(RAをセキュアにするプロトコルを使用するなど)が存在する、などの意見が出され、DHCPv6でルータ情報を配布する拡張については見送りとなった。

　なお、同じ話題が、v6ops wg でも議論されている。

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

4. v6ops WG (IPv6 Operations WG)の動向

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

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

の4項目について議論があった。

　1の「始点アドレス選択」は、複数のIPv6アドレスを持つホストが、通信を開始する際にどのアドレスを使用するかを選ぶ手法に関する議論である。その際の問題提起に関するドラフト(draft-ietf-v6ops-addr-select-ps) と、解法に関する要求条件ドラフト(draft-ietf-v6ops-addr-select-req)が、前回のIETFではミーティングにて WGLC となっており、筆者から、メーリングリストで受けたコメントへの対応、今後のドラフト改版案が提示された。ミーティングにおいては、この2ドラフトについては特に追加コメントはなく、次のステップに進むこととなった。その後、始点アドレス選択問題の解法として、draft-arifumi-v6ops-addr-select-sol ドラフトについて筆者より説明があり、議論が実施された。解法については、デプロイメントまで考えると、ドラフトで提示されているどの解法も実施困難であるといった意見や、そもそもIPv6ネットワークにおいてマルチプレフィックスは無用であるといった極論や、一つの解ではすべての場合をカバーできないので場合に応じた解法が必要、といった意見が出された。議論の後、チェアより、この解法ドラフトをWGアイテムとして取り上げるかどうかの採決があった。反対者より賛成者が多かったが、WGアイテムとして取り上げるコンセンサスは得られていないと判断され、継続議論となった。

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

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

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

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

5. shim6 (Site Multihoming by IPv6 Intermediation) WG の動向

今回も、shim6 WGのオンサイトミーティングは開催されなかった(前々回のミーティングでは、今回のシカゴIETFにて、できているであろうshim6 実装をもとに具体的な議論に入ることになっていた)。ミーティング後に、チェアよりshim6の基本プロトコルの3つのドラフトについて、RFC化の処理を進めている旨、報告があった。

6．その他のIPv6に関する動向

IPv6 WGは、オンサイトミーティングを実施せず、既存IPv6仕様のStandard化等のみを進めていくことになっていたが、IPv6 WGとして活動が必要な話題が最近出てきていることもあり、次回のバンクーバミーティングにて、新IPv6 WGのミーティングが実施されることになった。現在のIPv6 WGはクローズし、新たにIPv6のメンテナンスのみを目的としたWGが設立されることとなっている。新しいWGの名称は、IPv6 Maintenance Working Group(6man)であり、取り組みの内容としては、

 　・RAフラグオプション
 　・タイプ0ルーティングヘッダの無効化
 　・PPPv6ヘッダ圧縮
 　・ULA Centralに関する議論

となっている。

7. ram (rrg)に関する動向

前回の第68回IETFミーティングではインターネットエリア(intarea)セッションでID/Loc Separation BoFが開催され、デフォルトフリーゾーン(DFZ)におけるルーティングスケーラビリティ問題について検討が実施された(http://www.ipv6style.jp/jp/20070331/ietf2.html)。その後も、ram(Routing and Addressing) やrrg(Routing Research Group)といったメーリングリストでID/Loc分割に基づく様々な提案について議論が続けられ、今回のIETFミーティングでは、最終日となる金曜日に丸一日rrgとしてのセッションが開催され、主にramのメーリングリストで行われている提案について発表や議論が実施された(通常、金曜日の午前中でIETFミーティングは終了するため、異例である)。

このルーティングスケーラビリティの問題は IPv6のみに関係するものではなく、IPv4では既に経路表の爆発問題として問題が顕在化している。IPv6ではアドレス空間の大きさや、プレフィックス長の長さから、IPv4に比べてさらに状況が悪化することも予想されており、現在そして今後のインターネットを支えていくための重要なトピックであるといえる。

ミーティングでは、rrgのチェアであるTony Li氏より、次世代ルーティングアーキテクチャの設計目標についてのドラフトのアップデート状況の発表があった。その後、Lixia Zhang女史より解決アプローチの分類について発表があり、IDとLocatorのマッピングの管理方法、通信障害の検出・使用方法について各種方式についての分析が実施された。

また、rrgということで、研究論文の紹介も2件、実施された。1つはケンタッキー大学からの発表で、階層化されたルーティングとフォワーディング方式によりスケーラビリティを高めるといった研究である。また、ベルギーのルーバンカトリック大学からは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などのサイト管理者のポリシーを反映したマルチホームを行うことを可能としているが、ホストのプロトコルスタックに変更を加えなければならないという点はshim6と同等であり、デプロイメント上、問題になると思われる。

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

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

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

なお、第69回IETFミーティングの各種情報は、以下のURLより参照可能となっている。

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

■録音
http://videolab.uoregon.edu/events/ietf/ [7]