ニュースレターNo.38/2008年3月発行

IPv6関連WG報告

2007年12月2日（日）から12月7日（金）まで、カナダのバンクーバーにて第70回IETFミーティングが開催されました。例年は、11月中に開催されることの多い冬のIETFミーティングですが、12月ということで、会議初日には積雪があり、厳しい寒さの中でのIETFとなりました（バンクーバーで積もるほど雪が降るのは珍しいとのことです）。

本稿では、会期中に議論された、IPv6に関連したトピックスをいくつか紹介します。

6man WG（IPv6 Maintenance WG）

IPv6のプロトコル仕様を標準化していた、IPv6 WGのface-to-faceミーティングは2年前に終了しており、メーリングリストでの議論のみが続いていました。しかしながら、IPv6の実利用が本格的になるにつれ、その仕様や、IPv6 WGにて策定された、いくつかのRFCに対する変更が提案されるようになり、新たに、IPv6のメンテナンスを目的としたWGが設立されました。6man WGのチャーターでは、IPv6のマイナーな改版のみを実施するということが明記されており、現在記載されている議論内容としては、

RAフラグオプション
ルーティングヘッダタイプ0（RH0）の無効化
IPv6 over PPP圧縮ネゴシエーション
管理組織割り当てユニークローカルIPv6アドレス（ULA-C）

が挙がっています。このうち、RAフラグオプション、ルーティングヘッダタイプ0の無効化については、ほぼ議論は終わっており、IPv6 over PPP圧縮については、今回は議論が実施されませんでした。

さて、今回初会合となる6man WGは、水曜日の朝一番目のコマで開催されました。

項目としては、

RFC3177改版ドラフトに関する議論の喚起
RFC 4294 IPv6 Node Requirementsの改版について
インタフェース識別子の登録について
ルータ広告（RA）とDHCPオプションについて
アドレス選択について
IPv6のアドレス自動設定機構の変更提案
管理組織割り当てユニークローカルIPv6アドレス（ULA-C）について

等が議論されています。このうち、IPv6のアドレス自動設定変更提案や、ルータ広告とDHCPオプションに関する提案は、IPv6の基本的な仕様に影響するような変更提案であり、今回のミーティングでは否決されています。しかしながら、今後、同様の提案がされる可能性もあり、IPv6を先行して導入している組織等への影響を考慮し、議論の動向を注視する必要があります。

□6man WG: http://www.ietf.org/html.charters/6man-charter.html
□第70回IETF 6man WGのアジェンダ: http://www3.ietf.org/proceedings/07dec/agenda/6man.txt

v6ops WG（IPv6 Operations WG）（1/2）

IPv6とIPv4の共存技術、IPv6のディプロイメントに関する話題を扱うv6ops WGのミーティングは、月曜午後二番目のコマと、木曜日午後一番目のコマにて、2回開催されました。

一番目のコマでのセッションは、「IPv6 Operations“normal”meeting」と題され、現在進行中である、v6ops WGにおけるワーキンググループドラフトに関する進行状況の紹介と、

不正ルータ広告（RA）について
不正ルータ広告（RA）の、L2での防御に関する提案
Teredo のセキュリティに関する提案

の議論が実施されました。1.と2.の不正ルータ広告に関しては、前回のIETFミーティングでもかなり議論されました。

既にIETFでは標準化済みのSEND（RFC3971）を利用すれば、この問題は解決できるが、

実装が少ない
設定が手間である

といった意見が出され、また、2.では、L2スイッチを利用して、RAを送出できるノードを制限することで解決する、という提案もされました。

しかしながら、

無線環境などではL2スイッチがいつでもあるわけではない
不正RAには、a）設定ミス、b）不正アタックが考えられ、どのような手段を用いても、a）は防ぐことが困難である

という意見も出されました。

3.のTeredo セキュリティに関しても、継続的に議論されています。Teredoを利用すると、NATやファイアウォールなどを超えて、ネットワークのセキュリティポリシーを無視した通信が可能になってしまうことへの問題提起や、Teredoプロトコル自体のセキュリティを強化するため、Teredoが使用するポートを乱数化すべきである、ということが議論されました。策定したプロトコルに対するセキュリティ問題対策が、後手後手になっていることを指摘する声や、極論として、議論を実施する時間が無駄なので、Teredoのような、危険なプロトコルは使用禁止としてしまうだけでよい、といった意見もありましたが、既にプロトコルとして広く実装されていることなども鑑み、v6ops WGとして取り組みを実施していくことになっています。

v6ops WG（IPv6 Operations WG）（2/2）

二番目のコマとなるセッションでは、“IPv6 Transition Discussion”と題して、IPv4-IPv6トランスレーション方式である、NAT-PTのRFCが廃止（Historical）になったことを受けて、代替となる技術についての議論が行われました。

セッションの概況としては、まずはじめにJordi Palet氏より、IPv6における現在のトラフィックボリュームに関する報告があり、あるサイトではTeredoや6to4などのトンネルトラフィックを含めると、IPv4よりもIPv6の方がトラフィック量が多いという驚くべき調査結果が提示されました。

続いて、新たなIPv4ホストとIPv6ホスト間の相互通信を実現する技術を検討していくにあたって、どのような問題があるかという問題をまとめた発表や、問題を解くにあたってどのような要求条件があるか、例えばIPv4ホストに対する変更を許容するのかどうかをまとめた発表や、そしてIPv6への移行シナリオはどのようになるのか、といった移行シナリオに関する検討などが発表されました。

トランスレータの代替となる技術もいくつか提案が行われましたが、基本的にはNAT-PTのように、通信路中の装置によってIPv4-IPv6変換を行うというアプローチではなく、端末自体を含む通信路中で2回IPv4-IPv6変換を行うことによって、結果的にアプリケーションには途中でのプロトコル変換による影響は発生しないというアプローチでした。というのも、NAT-PTが廃止された理由の一つには、IPv6インターネットにIP層のアドレス変換を行う装置（つまりNAT）を導入することになるという点があり、NATによるアプリケーションへの影響が問題視されているからです。

また、これまでも、このワーキンググループでは移行シナリオ・移行技術についての検討が行われてきましたが、今回のセッションでは、IPv4の在庫枯渇が目前に迫っているという事実を反映した議論が行われ、IPv4-IPv6デュアルスタック環境による移行シナリオでも、グローバルIPv4アドレスが不足しているために、ISPでNATを行い、ユーザーにはプライベートアドレスを割り振るというモデルについての議論が行われました。

IPv4アドレスの在庫枯渇まで2年などと言われている昨今ですが、トランスレータを必要としている事業者に対してIETFが魅力的な解を提示できない限り、IPv6への移行は各事業者が手探りで進めることとなり、混迷を極めることになるかもしれません。

□v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
□第70回 IETF v6ops WGのアジェンダ: http://www3.ietf.org/proceedings/07dec/agenda/v6ops.txt

rrg（Routing Research Group）

以前より本誌でもご紹介している、rrgでのID/Loc分離に基づく新しいルーティングアーキテクチャに関する議論ですが、今回も前回に引き続き本WGにて行われました。前にもお伝えしましたが、この議論はインターネットのデフォルトフリーゾーンにおける、経路爆発の問題を解決することを目的としています。この問題は、現在はIPv4の経路に関して非常に深刻な状態になりつつありますが、将来的にIPv6が普及した場合には、IPv6においてもより重大な問題となる可能性があり、今後のインターネットを占う重要なトピックであると言えます。

セッションの冒頭で、rrgのチェアであるTony Li氏から今後の方向性が示され、ラフコンセンサスによって一つの提案に絞り込み、新たなワーキンググループを立ち上げて、実際のエンジニアリング作業を行っていくという議論収束についての目標が掲げられました。スケジュールとしては、2008年の3月より議論収束をめざし、2009年の3月までには完了するという予定になっています。

以前より提案が行われ、また今回も活発に議論が行われたのは、Six/One、LISP、そしてAPTという三つの方式です。これらは全てLoc/ID分離に基づく方式ですが、Six/Oneは経路中のルータにおいてパケットのアドレスフィールドを書き換えることによって、またLISPとAPTは同じく経路中のルータにおいてトンネリングを行うことによって、IDとLocの切り替えや、Locの変更による冗長化を実現する方式です。両者の本質的な違いは、アドレス変換か、もしくはトンネルかという点だけで、その他の必要な機能であるIDとLocをマッピングするデータベースを、どこでどのように持つかといった部分は共通の課題です。

LISPとAPTは非常に類似した方式ですが、マッピングデータベースを全てのこの方式に対応したルータで持つのか、もしくは各ルータは自分のサイトにおけるデータベースだけを持つのかという点、通信障害発生時の対応、またルータをPEに設置するのか、CEに設置するのかという点が異なるようです。これらの違いはあるものの、本質的には非常に類似しているため、LISPの沢山ある亜種の一つとして提案し直すことも検討されています。

今回の議論では、Six/OneやLISPとその亜種を含め、方式としての成熟度が高まってきており、最初は新しい方式に対応したサイト間での、通信の冗長化に関する検討のみでしたが、現在は非対応サイトとの通信の信頼性を高めるための、ProxyやNATといった方式が検討されています。またSix/Oneの提案者からは、IPv4からIPv6への移行を実現する手段としての用途も提案され、ルーティングスケーラビリティの問題と、IPv6への移行の問題という、インターネットが抱える二つの大きな問題を同時に解決するといった議論も、今後活発になってくるかもしれません。