IPv6の拡張機能：IPv6ネットワークへの招待（最終回）

　最終回の今回は「IPv6の拡張機能」と題し、IPv6が標準で備える「セキュリティ機能」と「モバイル機能」の説明をしたい。

端末間セキュリティを実現するIPv6でのIPSec

　IPv6では、IPSecの実装が必須とされている。IPSecとは、IPv4の世界でもすでに実用化されているパケットの認証や暗号化のための標準プロトコルである。IPSecのメカニズム自体はIPv4とIPv6で完全に共通であり、変化はない。IETFの標準化ドキュメントも、「RFC 2002 - IP Authentication Header」および「RFC 2406 - IP Encapsulating Security Payload (ESP)」にまとめられている。IPv6における認証ヘッダ（Authentication Header：AH）と暗号化ヘッダ（Encapsulated Security Payload：ESP）は、それぞれ拡張ヘッダとして組み込まれる。

　IPSecの基本的なメカニズムについては、本サイトでも「PC Insider」の「IT管理者のためのIPSec講座」などですでに解説されている。IPv6の世界でも、基本的には完全に同じなので、ここでは繰り返し説明することを避ける。

　同一のメカニズムを採用しているのなら、セキュリティの観点からIPv6に移行するメリットはどこにあるのだろうか。

　IPSecはネットワーク層のセキュリティ技術で、アプリケーションに関係なく特定のコンピュータ間のトラフィックを認証したり、暗号化することでほかのコンピュータから通信内容を見えなくするために使われる。IPv4の世界において、こうした機能は主にファイアウォールに組み込まれ、ネットワーク拠点間の通信や、ネットワーク拠点と端末の間の通信を対象としたセキュリティの確保に使われてきた。

　IPv6の世界ではIPSecの実装が必須になっているため、IPv6を話すことのできる端末は、すべてIPSecを利用する下地を与えられることになる。端末間の通信をIPSecで守ることが、これまでよりも飛躍的に行いやすくなる。端末対端末のIPSecは、IPv4の世界ではほとんどだれも想像していなかったことだ（一部の米国セキュリティ・ベンダは、「エンド・ツー・エンド・セキュリティ」をコンセプトに掲げ、端末単位のIPSec製品を販売してきたが、端末がこうした機能を標準搭載していない環境で、後から導入していくことはとても難しい）。

　IPv4では、ネットワーク拠点間のIPSecを構成する場合に、NAT^＊1が大きな障害となってきた。IPv4の世界では、社内の全端末に配布できる数のグローバルIPアドレスをもらうことが非常に困難なため、まったくそんなことを考えずに、半自動的に社内ネットワークをプライベートアドレスで構成し、NATを通してインターネットと接続するようになってしまった。このため、それぞれプライベートアドレスで構成したネットワーク間にIPSecでVPN^＊2を設定しようとすると、拠点間でアドレスの重複が起こってしまうことがよくあるのだ。

　IPv6では、グローバルIPアドレスを潤沢に利用することができるため、NATを使う必要はない。すべての拠点の全端末にグローバルIPアドレスを与えれば、アドレスの衝突が起こることはあり得ず、IPSec導入の障害になることはない。

　なお、企業ネットワークの管理者の間では、NATはセキュリティのために不可欠だという意見が根強い。内部のトポロジ情報や端末の実アドレスを隠ぺいできるということを理由として挙げる人が多いようだ。一方、IPv6でアドレスの自動構成機能を利用すると、インターフェイスIDの部分はMACアドレスに基づいて生成されるため、NICを入れ替えない限り不変となり、これが外部に知られることを心配する人がいる。しかし、IPv6では複数のIPアドレスを使い分けたり、乗り換えたりすることができる。インターフェイスIDには、毎時間や毎日などの頻度でランダムに生成される番号を使ってもよい。これは、「RFC3041 - Privacy Extensions for Stateless Address Autoconfiguration」として、標準化が進められているもので、これを活用すれば、追跡のしにくいグローバルIPアドレス利用環境が実現できる。

Mobile IPのコンセプト

　移動する端末が、その位置と無関係に一貫したIP通信を実行できるようにするための技術がMobile IPである。Mobile IPはIPv4の世界ですでに標準化が進められ（RFC 2002）、一定の支持を獲得している。IPv6におけるMobile IPv6は、このMobile IPv4をベースとし、IPv4とIPv6の違いへの対応とオプション的な機能の取り込みなどにより、発展させたものである。

　まず、IPv4におけるMobile IPを紹介しよう。Mobile IPは、移動する端末が同一のIPアドレスを保ちながら、通信を途切れさせずに異なるネットワーク・セグメントを渡り歩くことができるようにするための仕組みを提供している。こうした仕組みは、今後IP化される携帯電話、さらには将来自動車や電車が自律的に各種情報の収集や交換作業をIP通信経由で行うような場合に必要である。

　例えば、IP化された携帯電話では、利用者が自動車などで地理的に移動しているうちに、最初の接続時とは異なるネットワーク・セグメントに移ってしまうことが想定される。現状では、そのたびに新しいIPアドレスやネットマスクなどの構成情報で再接続する必要がある。これでは、いったんセッションが途切れてしまうことになる。通信をまったく途切れないように保ちながら、端末が自由に動き回れる環境を実現するにはどうしたらいいか。この問題を解決するのがMobile IPだ。

　IPのメカニズムは、もともと地理的に固定された端末からのネットワークアクセスにしか対応していない。IPアドレスそのものに、地理情報が書き込まれているようなものだからである。

　IPアドレスには「ネットワーク部」というものがある。あるネットワーク拠点に与えられたIPアドレスレンジにネットマスクを適用してネットワークを分離したのが「ネットワーク・セグメント」あるいは「サブネット」である。

　各端末に割り当てられるIPアドレスは、そのネットワーク部で、どのネットワーク・セグメントに属しているのかを示していることになる。ある端末が、外部の端末と通信中に、通常自分の存在しているネットワーク・セグメントから突然いなくなり、ほかのセグメントに移動したとしても、外部端末は自分の知っているIPアドレスを頼りに送信を行うしかない。この外部端末の送ってきたパケットは、その送信先アドレスのネットワーク部に従って、ルータ間をバケツリレーされて、移動してしまった端末がそれまで存在していたネットワークに到達し、そこでやっと相手がいなくなったことに気付くという結果になる。

図1　移動によって通信が中断する様子。端末Aの移動によって、端末Bからのパケットは正しくネットワークセグメント1に送られても、端末Aに届かなくなる

　図1で、移動する端末をAとし、この端末が自分のホームネットワークであるネットワーク・セグメント1にいるときに、端末Bと通信を開始し、そのままネットワーク・セグメント2に移動したとする。それでも端末Bは、端末Aが最初にIPアドレスを獲得したネットワーク（ルータ）にパケットを送り付けてくる。しかし、端末Aは移動してしまって、そこには存在しないため、通信ができなくなってしまう。

　Mobile IPでは、通信相手（この場合はB）を「だます」ことで、この問題を解決する。つまり、移動する端末は元のIPアドレス（以後、「ホーム・アドレス」と記述）を保ちながら、移動先をホーム・ネットワークに伝えることで、転送してもらうのだ。

　ネットワーク・セグメント1にホーム・エージェント（home agent）と呼ばれるものを置く（ネットワーク・セグメント1のルータがホーム・エージェント機能を担ってもよい）。そして端末Aは、移動先で新たなネットワークに入った時点で、そのネットワーク・セグメントにおける新しいIPアドレスを、DHCP^＊3などによって手に入れる。端末Aは、registration requestというメッセージによって、この新たなアドレスをホームエージェントに登録する。すると、ホーム・エージェントは、端末Aがもともと使っていたIPアドレスあてに届くパケットを自分がいったん受け取り、これをカプセル化して端末Aの新規アドレスに送る。端末Aは、ホーム・アドレスを保持しているので、転送されてきたパケットのカプセル化を解き、中のパケットを何事もなかったかのように処理することができる（図2）。

図2　Mobile IPのメカニズム。端末Aはネットワークセグメント1におけるアドレスをキープしながら、移動先のセグメントでcare-ofアドレスを取得、これをホームエージェントに登録し、自分あてのパケットを転送してもらう。ホーム・エージェントは端末Aへのパケットを代理で受け、カプセル化して端末Aが知らせてきたcare-ofアドレスに転送する。端末Aから端末Bへの送信は、元のアドレスを送信元として行う

　移動する端末Aが行き先で入手し、ホーム・エージェントに報告するIPアドレスはcare-ofアドレスと呼ばれる。「care-of」とは、日本語でいう「気付」である。気付という言葉も、最近はあまり日本で使われなくなったが、「自分がいま身を寄せている場所の住所」というような感覚で使える。

　移動する端末のMobile IP機能を助ける目的で、移動先のネットワーク（この場合ネットワーク・セグメント2）内にフォーリン・エージェント（foreign agent）を設置してもよい。フォーリン・エージェントは移動してくる端末のためにcare-ofアドレスを持っておき、移動端末に代わってホーム・エージェントに対し、registration requestを送る。そしてホーム・エージェントから送られてきた移動端末向けのパケットのカプセル化を解き、中のパケットを移動端末に送る。

　では、端末Aから端末Bへ送信されるパケットはどうなるのか。端末Aは自分のホームアドレスを送信元アドレスとし、端末Bを送信先アドレスとしたIPパケットを送る。だからこそ端末Bはだまされ続けるわけだ。

　IPの仕組みからすると、ルータはIPパケットの送信先アドレスのみを見てパケットを転送するので、移動端末がトポロジ的に不整合な送信元アドレスで送信しても問題はない。ただし、セキュリティ上の問題から、自分の配下のネットワークにおけるアドレスレンジ以外を送信元アドレスとするパケットを受け入れないようなフィルタリングがなされているルータが多い。すると移動端末からの送信ができなくなってしまうが、これについては後で述べる。

IPv4におけるMobile IP

　Mobile IPv4では、ホーム・エージェントやフォーリン・エージェントが定期的に、agent advertisementというメッセージを含んだrouter advertisementをブロードキャストする。agent advertisementでは、自分がホーム・エージェントなのかフォーリン・エージェントなのかを明らかにし、サポートしているカプセル化の手段や、登録を受け付ける期限を示すとともに、フォーリン・エージェントの場合は自分の持っているcare-ofアドレスを伝える。

　移動端末は、受け取ったagent advertisementメッセージに含まれるネットワーク情報が、それ以前のagent advertisementのものと同じであるかを比較し、違っていた場合には自分が移動していることを認識する。移動端末が移動を検出するもう1つの方法としては、自分がこれまで受けていたagent advertisementの有効期限が切れてしまったときに、自分は元のエージェントと通信できなくなったことを知り、自分の周りにあるエージェントを探す、というものがある。

　移動したことを知った移動端末は、ホーム・エージェントに対してregistration requestを送る。フォーリン・エージェントが存在する場合には、registration messageの送信を代行してもらうこともできる。こうして自分が現在属しているネットワークにおけるIPアドレス、あるいはフォーリン・エージェントのIPアドレスを伝え、ホーム・エージェントにパケットの転送を依頼する。

　さて、先ほど、Mobile IPにおける移動端末からのデータ送信は、通常のルーティング・メカニズムを使って行われるが、現在では自分の配下に存在しないIPアドレスを送信元アドレスとした、外へのデータ送信を認めない設定のルータが多いと書いた。こうした場合には、移動端末から発信されるパケットについてもカプセル化して、ホーム・エージェント経由で届けるようにするしか回避法はない。これをreverse tunneling extension（逆方向トンネリング拡張）といい、RFC 2344に規定されている（図3）。

図3　逆方向トンネリングの仕組み。ネットワークセグメント2のルータは、このセグメントの内部に存在しないはずのIPアドレスからの送信をブロックする。そのため端末Aは、自分あてのパケットの受信だけでなく、送信についてもホームエージェント経由で行う

　Mobile IPにおける拡張としては、Route Optimization（経路最適化）と呼ばれるものもある。これはトンネリングによるパフォーマンスの低下やホーム・エージェントの過剰負荷を避けるために、移動端末自身が、通信相手に対し、最新のcare-ofアドレスを教えることで、以後の通信をホーム・エージェント経由でなく直接行うというものだ。このメカニズムを実現させるためには、通信相手がbinding cacheというキャッシュ機能を備えていることが前提となる。移動端末がbinding updateとして自分のcare-ofアドレスを伝えると、通信相手は移動端末の元のアドレスとcare-ofアドレスを結び付ける情報を自分のbinding cacheに登録することで、その後の通信が直接行えることになる。

　もう1つの拡張として、フォーリン・エージェントを階層的に配置し、組織内における端末の移動については、フォーリン・エージェント同士の情報交換によって解決することで処理の集中を防ぐといった方法も、インターネット・ドラフトとして議論されている。

IPv6におけるMobile IP

　Mobile IPv6はインターネット・ドラフト段階だが（Perkins,C. & Johnson, D.B., Mobility Support in IPv6）、その基本的なメカニズムはMobile IPv4と共通している。移動する端末はホーム・アドレスを保ちながら、一時的なcare-ofアドレスを取得してホーム・エージェントに登録し、自分あてのパケットをまずトンネリングにより転送してもらう。上述のRoute OptimizationはMobile IPv6では必須である。移動する端末の通信相手となる端末は、必ずbinding cache機能を持っていなければならない。従って、ホーム・エージェント経由のトンネリングが行われるのは最初だけで、後は直接の通信に切り替わる。

　Mobile IPv6では、フォーリン・エージェントの利用は考えられていない。移動する端末は、自分のためにMobile IPv6サービスを実行しなければならない。

Mobile IPv6のメカニズム

　Mobile IPv6において、移動端末は一般的なIPアドレスの構成方法を使ってcare-ofアドレスを取得する。つまり、移動先のネットワークに存在するルータのrouter advertisementに含まれるネットワーク・プレフィックスと、自分のMACアドレスから生成されるインターフェイスIDを組み合わせて自動構成するか、DHCPv6などによってアドレスを割り当ててもらうか、どちらかである。

　Mobile IPv6では、移動端末が自分が移動したことを知る方法として、さまざまな手段が用意されている。主な方法は、router advertisementを使うことだ。移動端末は、新しいネットワーク・セグメントに移動した後、そのセグメントのルータから定期的に発信されるrouter advertisementを受けて登録する。そして、これまで自分が使っていたデフォルト・ルータのrouter announcementの有効期限が切れると、移動が起こったと認識し、新たなルータをデフォルト・ルータとして設定し、このrouter announcementに含まれていた新ネットワーク・セグメントのネットワーク・プレフィックスを使って、care-ofアドレスを自分で構成する。

　IPv4の場合と同じように、移動端末は新しいcare-ofアドレスを登録しなければならない。Mobile IPv6では、移動端末はbinding updateを、拡張ヘッダの1つとしてホーム・エージェントや通信相手に対する送信パケットに含めることにより、新しいcare-ofアドレスを知らせる（図4）。Mobile IPv4におけるregistration requestに似た仕組みだ。この際、移動端末は確かにbinding updateを受け取ったという返答を相手に要求することができ、要求された相手は、binding acknowledgementという拡張へッダを通じて返事をすることができる。

図4　Binding Updateメッセージ

　移動端末からのパケット送信については、Mobile IPv4の場合、ホーム・アドレスを送信元アドレスに使うか、ホーム・エージェントに逆方向トンネリングでパケットを送るかのどちらかだったが、Mobile IPv6では、まったく別の方法を採用している。

　それは、home addressオプションという拡張へッダを組み込むことだ。Mobile IPv6では、移動端末はcare-ofアドレスを送信元アドレスとしてパケットを送ることになっている。しかし、自分が送るすべてのパケットについて、ホーム・アドレスが書き込まれたhome addressオプションを付けなければならない。送信先ノードはパケットを受け取った時点で、この拡張ヘッダを読み取り、パケットの送信元アドレスをホーム・アドレスに読み替えて処理する。したがって、より上位のレイヤのアプリケーションは、相手がホーム・アドレスから動いていないかのようにだまされてやり取りを続けることになる。

経路最適化のメカニズム

　どんなIPv6端末でも、binding cache機能を備えていなければならない。そして自分がパケットを送信する際には、binding cacheをチェックして、送信アドレスがbinding cacheに登録されているかどうかを調べなければならないことになっている。binding cacheへの登録がなければ通常の通信として扱う。従って、端末Bはネットワーク・セグメント1にパケットを送る。そのときに端末Aが移動してしまっていたなら、ホーム・エージェントが受け取ったパケットを端末Aの新しいcare-ofアドレスに転送する。一方、登録が見つかった場合には、IPv6における拡張ヘッダの1つであるルーティング・ヘッダ（routing header）を使って端末Aに直接パケットを送る。

　本連載の第3回「IPv6のヘッダフォーマット」で触れたように、送信元は、パケットが通過しなければならないルータのアドレスをルーティング・ヘッダ内にリストすることで、伝送経路を指定できる。そこで、端末Bは自分のbinding cacheに端末Aのホーム・アドレスに対するcare-ofアドレスの登録が見つかった時点で、これ以後端末Aに送るパケットのすべてにルーティング・ヘッダを付ける。そしてこのルーティング・ヘッダでは、最初のホップを端末Aのcare-ofアドレスに指定し、次のホップを端末Aのホーム・アドレスに指定する。従って、あくまでも、このパケットの送信先アドレスはホーム・アドレスなのだが、実際のパケットは必ずcare-ofアドレスにまず送られ、次に端末A内でループバックしてホーム・アドレスを通じて処理される（図5）。

図5　ルーティングヘッダの活用例。ルーティングヘッダには、1番目のホップとして端末Aのcare-ofアドレスを指定し、2番目のホップとして端末Aのホームアドレスを指定することで、端末BはIPv6パケットの送信先アドレスを端末Aのホームドレスとしたまま、care-ofアドレスに送り込むことができる

　この方式では、カプセル化という作業が不要になる。各パケットには拡張ヘッダが1つ加わっただけで、その後に何もなかったかのように、上位層のデータを続けていくことができる。これは不要なオーバヘッドを回避するという点でもメリットがある。

Mobile IPv6のメリットとは

　Mobile IPv6がMobile IPv4に基づいているなら、IPv6はIPv4よりもモバイル・サポートに優れているといえないのではないかという反論が聞こえてきそうだ。しかし、Mobile IPv6はいくつかの点で、Mobile IPv4の現実における適用が妨げられている部分を克服することができる。

　一番分かりやすい点としては、Mobile IPv6ではルータで一般に行われている内から外へのパケットフィルタリングを簡単に超えることができる。Mobile IPv4では、移動端末から通信相手へのパケットについては、ホーム・アドレスをそのまま送信元アドレスとして使って直接送るか、もしくはホーム・エージェントまでトンネリング（上述の逆方向トンネリング）してから送るかの選択肢しかなかった。上述のように、ルータでは、自分の配下のネットワークに存在しないアドレスを送信元アドレスとするパケットを通さない設定がなされていることが多い。すると最初の選択肢は汎用性という点で大きな問題を生じる。逆方向トンネリングにしても、パフォーマンスの点から現実には利用が困難である。Mobile IPv6では、home addressというオプションを拡張ヘッダに組み込むことにより、care-ofアドレスを送信元アドレスとしてパケットを送ることができるため、フィルタリングの対象とならずに通信を行うことが可能だ。

　IPv6では、アドレスの自動構成機能によって、特別なサーバの助けなしに自分でcare-ofアドレスを設定することができる。移動先ネットワークでMobile IPをサポートするための用意が特に必要ではないということだ。IPv4と比べてアドレス空間が膨大であり、自動構成されたアドレスがすでにそのネットワークに存在しているノードのものと衝突する可能性はゼロといっていいということも、現実の運用における大きな助けになるはずだ。こうしてMobile IPが、やっと身近なものになってくる可能性は高い。

最終回を迎えて：

　これまで述べてきたように、IPv6は現在のIPv4と完全に異なるプロトコルではない。むしろIPv4に欠けていた部分を補うことで、IPを成長させるものである。

　今後の展開における課題としては、通信品質管理をはじめ、より運用に近い部分の標準化作業が早期に進むことが望まれる。IPv6対応通信機器のパフォーマンスや拡張性の進歩も必要だ。だがこうした問題は、現実のサービスにおける導入が進むことで、急速に解決されていく可能性が高い。通信サービスにしても、レイヤ2のサービスがこれほど広範に提供されるようになってくると、その上でIPv4とIPv6の双方を必要に応じて並行的に利用することは非常に簡単であり、一部の人々が騒ぎ立てるほどIPv4とIPv6の共存やIPv6への移行が困難であるとは思われない。

　マイクロソフトが開発者のためとはいえ、Windows XPにIPv6を搭載してきたことは利用促進の点から大きな進展だといえる。しかし、PC以外のサービス、例えばゲーム専用機を使ったオンラインゲームの進展や、自動販売機やエレベータなどの機器を対象としたネットワークによる遠隔監視・制御の発達などのほうが、IPv6普及のより強力な触媒となっていくに違いない。

　ネットワーク、あるいはインターネットが電話や水と同じように使えるような時代は来るはずだし、来るべきでもある。しかしIPv4のままでは、電気や水のようなサービスは到底実現できない。そう考えると、IPv6がIPネットワーキングを支える基盤として活躍する日は、そう遠くないように思われる。