ネットワークを持つ企業やエンドユーザーは、いずれ現行のIPv4から次のIPv6への移行を検討する時期がくる。その際に使われるさまざまな移行技術の一長一短、あるいはIPv6利用時のセキュリティについて、どのように考えればいいのだろうか。シスコシステムズでIPv6移行技術「6rd」に携わるタウンズレー氏と、IPv6セキュリティに携わるビンケ氏に聞いた。
6rdとはどのような技術か。
ディスティングイッシュト・エンジニア エリック・ビンケ氏（左）
ディスティングイッシュト・エンジニア マーク・タウンズレー氏
6rdは、IPv4ネットワークの上にIPv6パケットを流すトンネリング技術だ。私がパリの自宅で使っているプロバイダー（ISP）は、既に6rdを採用している。このプロバイダーが6rdを使い出したら、そのネットワークにおけるIPv6接続のトラフィック統計値がすぐに増えた。プロバイダーは6rdを採用することで、トンネリングなどを使わず直接IPv6ネットワークにつながるネイティブ接続と同じように、IPv6インターネット接続サービスをエンドユーザーに提供できる。
どのような特徴があると考えるか。
6rdは、IPv4ネットワークを活用して早くIPv6ネットワークを展開できる手段だ。これは裏を返せば、6rdはIPv4に依存するため、IPv4からIPv6への完全移行に時間がかかるということでもある。この点でIPv6のネイティブ接続は、IPv4を利用せずに済み、アドレスプランに自由度を持たせられるというメリットがある。
6rdは「6to4」というトンネリング技術をベースにしている。プロバイダーが6to4を実装していれば、若干の修正を加えれば利用できる。6to4は「2002:」で始まるプレフィックスしか使えず、これだとエンドユーザーがインターネット上で使っていくうえで信頼性が足りない。自由に中継できてしまうためだ。6rdでは、IPv6プレフィックスはプロバイダーのものになる。プロバイダーが中継するため、自身で装置やサービスをコントロールできる。
6rdはこの技術に対応するブロードバンドルーターやケーブルモデムなどのCPE（customer premises equipment）が必要になる。CPEの扱い方はプロバイダーによって異なるが、6rdはどのようなプロバイダーに向いているか。
いちばん採用しやすいプロバイダーは、市販品ではなくプロバイダー自身が配るCPEを使うところだろう。6rdが日本のプロバイダーで使われることも多分あると思う。IPv6普及のスケジュールは短縮できるという意識になってきている。私が6rdに携わっているのは、世界中のプロバイダーが直面する問題の解決策として、うまくはまると考えたからだ。
CPEの内側にあるパソコンに6rdの機能を入れてしまう計画はないのか。
そのような話はいろいろ出ている。ただ、パソコンの外側では（CPEなどで）NAT（network address translation）が実施される。率直にいえば、NATを介して6rdが機能するメカニズムにすると非常に複雑になる。6rdはIPv6のネイティブと同等のサービスを提供することが目的で、ユーザーがソフトウエアのインストールなどをせずに使えるのがメリットだと考えている。つまりパソコンに入れてしまうと、どうしても6rdのメリットが薄れてしまう。よって、今作成しているインターネットドラフトには、NATに対応させる機能は含まれていない。パソコンに6rdを追加するよりは、L2TP（layer 2 tunneling protocol）というトンネリング技術を採用したほうがいいかもしれない。
6rdとL2TPはどう使い分けるといいのか。
L2TPとPPP（point to point protocol）を採用しているプロバイダーの場合、PPPはIPv4とIPv6のデュアルスタックで使えるため、この組み合わせは非常に良いものだと思う。一方、L2TPとPPPのインフラを持っていないプロバイダーや、PPPをIPoE（IP over Ethernet）に移行しようとしているプロバイダーにとっては、6rdが役に立つ。
このほか、L2TPを採用しているプロバイダーがIPv6サービス用に別のインフラを作るとなると、すべてのPPPセッションのステートについて、IPv4とIPv6の冗長構成にしなくてはならない。今はまだIPv6のトラフィックは全体から見ると少ないわけだが、プロバイダーがIPv6サービスをきちんと提供しようとすれば、「L2TP Network Server（LNS）」というトンネルコンセントレータが多数必要になる。このためサポートできるユーザー数にはどうしても限界がある。6rdの場合は、個々のユーザーのステートを保持する必要はない。ユーザー数ではなくトラフィックの負荷を考えればよい。こうした拡張性の点では、6rdのほうが優れていると思う。
IETFにおける、6rdのインターネットドラフトの議論の進展は。
広島のIETF会合では、「Softwire WG」というワーキンググループの冒頭でプレゼンテーションをした。関連するワーキンググループのチェアからは、「次のバージョンのドラフトを出してほしい」と強いプッシュがかかっているが、RFC（Request for Comments）になるのは今年のどこかでという感じだろう。
ただ、IETFで標準化にかかわる作業をしたり、ベンダーでの仕様実装に携わったりした経験から、「RFCがすべてではない」ということがいえる。ほかのベンダーとやりとりして、実装の一貫性や相互運用性をきちんと持たせることが大切だ。6rdに関して、今年は相互運用に関わるイベントを開催できると確信している。
IPv4アドレス枯渇の対策技術として、プロバイダー網内でNATを実施する「NAT444」などが議論されている。
IPv6とNATには、前者は「（その気になれば）使うことができる」、後者は「（嫌がおうにも）使わざるを得ない」という違いがある。私が特に6rdのようなテクノロジーを紹介するのは、IPv6を一緒に導入することなくIPv4のNATサービスを始めてしまうプロバイダーが出てこないことを願っているためだ。私の思いとしては、NAT444よりも先にIPv6を普及させたい。
