JP4607998B2 - 異なるアドレス空間におけるモバイルＩＰｖ６のルート最適化 - Google Patents

Description

本発明は、ＩＰｖ４限定のアクセスネットワークに移動でき、その後もなお、異なるアドレス空間に位置する別のＩＰｖ６ノードへのその到達可能性を維持できるようなＩＰｖ６モバイルノードに関するものである。

下記の略語集が、本明細書と共に定義されており、少なくともその一部は、本発明の先行技術および好適実施形態についての以下の記述の中で言及される。

ＭＮ Ｍｏｂｉｌｅ Ｎｏｄｅ（モバイルノード）は、インターネット（ＩＰネットワーク）との接続点を変えながら、自分のホームアドレスを用いて他の移動ノードまたは静止ノードと通信できる移動端末である。

ＨＡ Ｈｏｍｅ Ａｇｅｎｔ（ホームエージェント）は、ＭＮのホームネットワーク内のルータである。

ＣＮ Ｃｏｒｒｅｓｐｏｎｄｅｎｔ Ｎｏｄｅ（コレスポンデントノード（通信相手ノード））は、ＩＰｖ６ノードである。ＭＮもＣＮであるが、ＣＮは、まったく移動しないノードである場合もあるだろう。

ＮＡＴ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（ネットワーク・アドレス・トランスレータ）である。

ＣｏＡ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ（気付アドレス）は、在圏中のネットワーク内でＭＮによって用いられるＩＰｖ６アドレスまたはＩＰｖ４アドレスである。ＭＮがインターネットへの接続を変えると、このアドレスは変わる。ＭＮがＩＰｖ４アクセスネットワークにアタッチする場合、ＭＮはＩＰｖ４のＣｏＡに加えてＵＤＰのポート番号も必要とする。これは、ＩＰｖ４トンネリングが、１つ以上のＮＡＴを経由する可能性があるからであり、それらのＮＡＴは、アドレスの変換を行うのにＵＤＰポートを必要とするからである。

ＨｏＡ ＭＮのＨｏｍｅ Ａｄｄｒｅｓｓ（ホームアドレス）は、ＭＮに対して常に到達可能なＩＰｖ６アドレスまたはＩＰｖ４アドレスである。ＭＮがホームリンク内にいない場合、ＨＡはパケットをＭＮへトンネルさせ、パケットはＭＮのＨｏＡに到着する。

ＨＬ Ｈｏｍｅ ｌｉｎｋ（ホームリンク）である。

ＨｏＴＩ Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ．（ホーム・テストＩｎｉｔ）である。

ＨｏＴ Ｈｏｍｅ Ｔｅｓｔ（ホーム・テスト）である。

ＣｏＴＩ Ｃａｒｅ−ｏｆ Ｔｅｓｔ Ｉｎｉｔ．（気付テストＩｎｉｔ）である。

ＣｏＴ Ｃａｒｅ−ｏｆ Ｔｅｓｔ（気付テスト）である。

ＢＵ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ（バインド更新）である。

ＢＡ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（バインド確認応答）である。

無線通信分野では、モバイルＩＰｖ６として知られるプロトコルが現在用いられているが、このプロトコルによって、ＩＰｖ６のＭＮがインターネットのようなＩＰネットワークに接続されたＩＰｖ６アクセスネットワーク内で移動している間も、そのＭＮに到達可能な状態を維持できる。このモビリティのサポートがなければ、ＩＰｖ６のＭＮを宛先とするパケットは、ＭＮが自分のホームリンクから離れた位置にある間は、そのＭＮに到達することができないであろう。モバイルＩＰｖ６プロトコルについては、下記の文書の中に詳細に記述されている。
・Ｓ．Ｄｅｅｒｉｎｇ他、「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様」ＲＦＣ２４６０、１９９８年１２月
・Ｄ．Ｊｏｈｎｓｏｎ他、「ＩＰｖ６におけるモビリティのサポート」ＲＦＣ３７７５、２００４年６月
これらの文書の内容は、参照により本願に援用する。

現在、ＩＰｖ６アクセスネットワークに加えて、インターネットに接続されているＩＰｖ４アクセスネットワークも使用されている。ＩＰｖ４アクセスネットワークは、モバイルＩＰｖ４として知られる別のプロトコルに合致するように設計され、構築されている。モバイルＩＰｖ４プロトコルによって、ＩＰｖ４のＭＮが自分のＨＬではないＩＰｖ４アクセスネットワーク内に位置している間も、それに到達することが可能になる。モバイルＩＰｖ４プロトコルについては、下記の文書の中に詳細に記述されている。
・Ｃ．Ｐｅｒｋｉｎｓ、「ＩＰモビリティサポート」、ＲＦＣ２００２、１９９６年１０月
この文書の内容は、参照により本願に援用する。

残念ながら、モバイルＩＰｖ４プロトコルおよびモバイルＩＰｖ６プロトコルは、それぞれ、ＩＰｖ４限定のアクセスネットワーク用およびＩＰｖ６限定のアクセスネットワーク用として設計されている。従って、モバイルＩＰｖ６プロトコルは、ＩＰｖ４ネットワークへの後方互換性を提供しない。これは、モバイルＩＰｖ６は、（パブリックネットワークであれプライベートネットワークであれ）複数のＩＰｖ４アクセスネットワークを跨いだモビリティ管理を行うことができないということを意味する。しかし、ＩＰｖ４（パブリックおよびプライベート）アクセスネットワーク内に位置するＩＰｖ６ＭＮのモビリティ管理は、特に重要である。なぜなら、ＩＰｖ６ＭＮ（例えばＩＰｖ６モバイルコンピュータ）は、インターネットに接続されようとする装置人口の大半もしくは少なくとも相当な割合を占めると思われるからである。そして、インターネットへのアクセスネットワークの一部は、ＩＰｖ４限定のアクセスネットワークであろう。このモビリティ管理の問題に対する解決策の提案を、図１および２に関して下記に詳述する。

図１Ａおよび１Ｂ（先行技術）を参照すると、ＩＰｖ６ＭＮ１１０がＩＰｖ４限定アクセスネットワーク１１６へ移動してもなお、ＩＰｖ６のＣＮ１０２へのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題の解決策を説明する一助とするのに用いられる、図およびシグナリングフロー図が示されている。図１Ａに示すように、ＩＰｖ６のＣＮ１０２は、ＩＰｖ４ルータ１０６とＩＰｖ６ルータ１０８とを有するＩＰｖ４／ＩＰｖ６混合アクセスネットワーク１０４に位置する。そして、ＭＮ１１０は、ＨＡ１１４を有するＨＬ１１２から、ＩＰｖ４ルータ１１８を有するＩＰｖ４アクセスネットワーク１１６へ、移動してきた。ＭＮ１１０は、次に論じるように、インターネット１２０を経由してＣＮ１０２と通信できる。

図１Ａおよび１Ｂに示すように、ＭＮ１１０は、ＨＬ１１２からＩＰｖ４アクセスネットワーク１１６へ移動した後、ＨＡ１１４にホーム登録を行う（信号１および２を参照のこと）。ホーム登録を行うため、ＭＮ１１０は、ＢＵをＨＡ１１４へ送信する（信号１）。ＭＮ１１０はＩＰｖ４アクセスネットワーク１１６の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ１１０はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ１１４は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ１１０に送信する（信号２）。ホーム登録の後、ＣＮ１０２は、ＨＬ１１２を経由してトラヒック（トンネルされたデータ）をＭＮ１１０へ送信する（信号３を参照のこと）。また、ＭＮ１１０は、ＨＬ１１２を経由してトラヒック（トンネルされたデータ）をＣＮ１０２へも送信する（信号４を参照のこと）。加えて、ＭＮ１１０は、ルーティングテーブルを有する。典型的なルーティングテーブルを以下に示す。

ＭＮのルーティングテーブル１２２
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ６" |"ＨＡ ＩＰｖ４" |ＵＤＰ ｔｕｎｎｅｌｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

この解決策の欠点は、ＭＮ１１０についての着信トラヒックおよび発信トラヒックが、ＨＬ１１２の中に存在するＨＡ１１４を経由して常にトンネルされることである。たとえＣＮ１０２とＭＮ１１０とが同じアクセスネットワーク内に位置していたとしても、同じトラヒックルートは、やはり必要であろう。なぜなら、ＭＮ１１０が別のアクセスネットワーク（不図示）へ移動する場合、ＣＮ１０２とＭＮ１１０とは接続性を失う可能性があるため、ＣＮ１０２とＭＮ１１０とは、トラヒックが最短パス（ＭＮ１１０、ＩＰｖ４ルータ１１８、インターネット１２０、ＩＰｖ４ルータ１０６、ＣＮ１０２）を経由してルーティングされるようなルート最適化手順を行うことができないからである。ＭＮ１１０とＣＮ１０２とが、ルート最適化手順を行うことができるならば、望ましいであろう。本発明はこの必要性に取り組むものである。

図２Ａおよび２Ｂ（先行技術）を参照すると、ＩＰｖ６ＭＮ２０２および２１２が両方ともＩＰｖ４限定アクセスネットワーク２０４および２１４へ移動しても、ＩＰｖ６ＭＮ２０２がもう１つのＩＰｖ６ＭＮ２１２への到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題の解決策を説明する一助とするのに用いられる図およびシグナリングフロー図が示されている。図２Ａに示すように、第１のＩＰｖ６ＭＮ２０２は、ＩＰｖ４ルータ２０６を有するＩＰｖ４アクセスネットワーク２０４の中に位置している。第１のＭＮ２０２は、ＨＡ２１０を有するＨＬ２０８からＩＰｖ４アクセスネットワーク２０４へ移動した。第２のＩＰｖ６ＭＮ２１２は、ＩＰｖ４ルータ２１６を有するＩＰｖ４アクセスネットワーク２１４の中に位置している。第２のＭＮ２１２は、ＨＡ２２０を有するＨＬ２１８からＩＰｖ４アクセスネットワーク２１４へ移動した。そして、以下に述べるように、第１のＭＮ２０２は、インターネット２２２およびＨＡ２１０および２２０を経由して、第２のＭＮ２１２と通信することができる。

図２Ａおよび２Ｂに示すように、第１のＭＮ２０２は、ＨＬ２０８からＩＰｖ４アクセスネットワーク２０４へ移動した後、ＨＡ２１０にホーム登録を行う（信号１ａおよび１ｂを参照のこと）。ホーム登録を行うため、第１のＭＮ２０２は、ＢＵをＨＡ２１０へ送信する（信号１ａ）。第１のＭＮ２０２はＩＰｖ４アクセスネットワーク２０４の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ２０２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ２１０は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ２０２へ送信する（信号２ａ）。同様に、第２のＭＮ２１２は、ＢＵをＨＡ２２０へ送信する（信号１ｂ）。ＭＮ２１２はＩＰｖ４アクセスネットワーク２１４の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ２１２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ２２０は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ２１２に送信する（信号２ｂ）。ホーム登録の後、第２のＭＮ２１２は、２つのＨＬ２１８および２０８を経由してトラヒック（トンネルされたデータ）を第１のＭＮ２０２へ送信する（信号３を参照のこと）。また、第１のＭＮ２０２は、２つのＨＬ２０８および２１８を経由してトラヒック（トンネルされたデータ）を第２のＭＮ２１２へも送信する（信号４を参照のこと）。加えて、ＭＮ２０２および２１２はそれぞれ、ルーティングテーブル２２４および２２６を有する。典型的なルーティングテーブル２２４および２２６を以下に示す。

ＭＮ１のルーティングテーブル２２４
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ１ ＩＰｖ６" |"ＨＡ１ ＩＰｖ４" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＨＡ１ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＭＮ２ルーティングテーブル２２６
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ２ ＩＰｖ６" |"ＨＡ２ ＩＰｖ４" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＨＡ２ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

この解決策の欠点は、ＭＮ２０２とＭＮ２１２との間の着信トラヒックおよび発信トラヒックが、ＨＬ２０８および２１８の中に存在する２つのＨＡ、すなわちＨＡ２１０およびＨＡ２２０、を経由してトンネルされる必要があることである。たとえＭＮ２０２とＭＮ２１２とが両方とも同じアクセスネットワーク内に位置していたとしても、同じトラヒックルートは、やはり必要であろう。なぜなら、ＭＮ２０２と２１２のうちのいずれか一方もしくは両方がＩＰｖ４ネットワーク２０４および２１４へ移動する場合、ＭＮ２０２とＭＮ２１２とは接続性を失う可能性があるため、ＭＮ２０２とＭＮ２１２とは、トラヒックが最短パス（ＭＮ２０２、ＩＰｖ４ルータ２０６、インターネット２２２、ＩＰｖ４ルータ２１６、ＭＮ２１２）を経由してルーティングされるようなルート最適化手順を行うことができないからである。留意すべきだが、たとえ２つのＭＮがＩＰｖ６ネットワークにいる場合であっても、それらのうち一方がいつ何時ＩＰｖ４アクセスネットワークへ移動するかもしれないので、それらは互いの間でルーティングを最適化することができない。ＭＮ２０２とＭＮ２１２とが、ルート最適化手順を行うことができるならば、望ましいであろう。本発明はこの必要性に取り組むものである。

本発明は、別のノードと通信するためにＩＰｖ６モバイルノードによって使用されるルート最適化のための方法であって、ＩＰｖ６モバイルノードは、ＩＰｖ６モバイルノードのホームエージェントを介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワークを介してＩＰｖ４／ＵＤＰ双方向トンネルの中でＩＰｖ６トラヒックを送受信することにより、別のノードと通信し、ＩＰｖ６モバイルノードと別のＩＰｖ６ノードとのうちの少なくとも一方は、ＩＰｖ４アクセスネットワーク内に位置する方法を含む。

本発明の一層完全な理解は、添付の図面に関連して下記の詳細な説明を参照することによって、得られるであろう。

図３乃至８を参照すると、本発明によるルート最適化方法３００および６００に関する２つの実施形態が開示されている。ルート最適化方法３００および６００の議論を助けるため、本明細書ではいくつかの異なる典型的なネットワークが用いられ、それらは、ＩＰｖ４アクセスネットワーク、ＩＰｖ６アクセスネットワーク、ＩＰｖ４／ＩＰｖ６アクセスネットワーク、ＨＬ、ＨＡ、ＩＰネットワーク（インターネット）、ＩＰｖ４ルータ、ＩＰｖ６ルータなどのようなよく知られたコンポーネントを含んでいる。明確にするため、本明細書で提供される記述は、本発明を理解するのに必要ない、よく知られたコンポーネントについての一定の詳細は省略する。

図３乃至５を参照すると、本発明によるルート最適化方法３００の第１の実施形態を記述する一助とするのに用いられる図がいくつか示されている。基本的に、ルート最適化方法３００は、ＩＰｖ６ＭＮ４０２がＩＰｖ４限定アクセスネットワーク４０６ａおよび４０６ｂへ移動してもなお、ＩＰｖ６のＣＮ４０４へのその到達可能性を維持するのを可能にする。この解決策において、ルート最適化方法３００は、いくつかの前提条件があれば、異なるアドレス空間においてもＭＮ４０２とＣＮ４０４との間で機能することができる。第１に、ＭＮ４０２とＣＮ４０４とはいずれも、両方がＩＰｖ４アドレスとＩＰｖ６アドレスとを持つことを意味する、デュアルスタック・ノードである必要がある。また、ＭＮ４０２とＣＮ４０４とは、ＩＰｖ４／ＵＤＰ双方向トンネルにおいて、ＩＰｖ６トラヒックのトンネリングをサポートしなければならない。加えて、ＭＮ４０２とＣＮ４０４とは、トンネリングのため、自分たち自身のグローバルにルーティング可能なＩＰｖ４アドレスとＵＤＰポートとを知る必要がある。

ＭＮ４０２は、自分のＨＬ４０８にアタッチしている間、ＣＮのＩＰｖ６アドレスと自分自身のＩＰｖ６ホームアドレスとを用いて直接ＣＮ４０４と通信できる（この状況は、図４および５のシナリオには示されていない）。ＭＮ４０２は、ＩＰｖ６接続性が得られるような外部ネットワークへ移動する場合、通常は、従来型のルート最適化手順を自分自身とＣＮ４０４との間で開始するであろう（この状況は図４および５のシナリオには示されていない）。ＭＮ４０２がＩＰｖ４アクセスネットワークへ移動する時のように、ＩＰｖ６接続性が保証できない環境においてＭＮ４０２が使用される場合には、ＩＰｖ６トラヒックがＭＮ４０２とＣＮ４０４との間で効率的にルーティングされうるようにルート最適化方法３００が使用される必要がある（この状況は図４および５のシナリオに示されている）。言い換えると、ＭＮ４０２は、自分がＩＰｖ４アクセスネットワークへ移動しているのか、あるいはＩＰｖ６アクセスネットワークへ移動しているのか、事前の知識を持っていないのだから、ルート最適化方法３００（および方法６００）を使用すべきである。

ルート最適化方法３００が図４および５に示される２つの異なるシナリオにおいてどのように用いられるかを議論する前に、ルート最適化方法３００の基本的なステップについて簡単な説明を提供する。第１に、ＭＮ４０２は、ＨＡ４１０を通じて送信されるＣＮ４０４のトラヒックの中でＣＮ４０４がＩＰｖ４気付アドレスというオプションをＭＮ４０２へ送信しているかどうかチェックすることによって、ＣＮ４０４のＩＰｖ４到達可能性を判断する（図３のステップ３０２を参照のこと）（図４および５も参照のこと）。送信しているならば、ＭＮ４０２は、ＣＮ４０４がインターネット４１２を通じて直接ＭＮ４０２とＣＮ４０４との間でＩＰｖ４／ＵＤＰ双方向トンネル４０７を確立できるかどうか、判断する（図３のステップ３０４を参照のこと）。確立できるならば、ＭＮ４０２は、ＣＮ４０４とのＩＰｖ４／ＵＤＰ双方向トンネル４０７を確立する（図３のステップ３０６を参照のこと）。その後、ＩＰｖ６トラヒックは、ＩＰｖ４／ＵＤＰ双方向トンネル４０７の中でＭＮ４０２とＣＮ４０４との間で往復するようにルーティングされる（図３のステップ３０８を参照のこと）。ステップ３０２および３０４のいずれかの判断が、ＮＯであれば、ＩＰｖ４／ＵＤＰ双方向トンネル４０７は確立できず、ＭＮ４０２は、インターネット４１２とＨＡ４１０の両方を通じて、ＩＰｖ６トラヒックをＣＮ４０４と送受信しなければならない（図３のステップ３１０を参照のこと）（図１Ａを参照のこと）。以下に、ステップ３０２、３０４．．．３０８が、どのようにして実装されうるかについて、図４および５に示す２つのシナリオに関して詳細に記述する。

図４Ａおよび４Ｂを参照すると、ＩＰｖ６ＭＮ４０２がＩＰｖ４公衆アクセスネットワーク４０６ａへ移動した後でもなお、ＩＰｖ６のＣＮ４０４へのその到達可能性を維持できるように、ＩＰｖ６ＭＮ４０２によってどのようにルート最適化方法３００が用いられうるかを説明する一助とするのに用いられる、図およびシグナリングフロー図が示されている。図４Ａに示すように、ＣＮ４０４は、ＩＰｖ４ルータ４１６とＩＰｖ６ルータ４１８とを有するＩＰｖ４／ＩＰｖ６混合アクセスネットワーク４１４に位置する。そして、ＭＮ４０２は、ＨＬ４０８から、ＩＰｖ４ルータ４２０を有するＩＰｖ４パブリックアクセスネットワーク４０６ａへ、移動してきた。ＭＮ４０２は、次に論じるように、ＩＰｖ４／ＵＤＰ双方向トンネル４０７を通じてインターネット４１２を経由して、ＣＮ４０４と通信することができる。

図４Ａおよび４Ｂに示すように、ＭＮ４０２は、ＨＬ４０８からＩＰｖ４パブリックアクセスネットワーク４０６ａへ移動した後、ＨＡ４１０にホーム登録を行う。ホーム登録を行うため、ＭＮ４０２は、ＢＵをＨＡ４１０へ送信する。ＭＮ４０２はＩＰｖ４パブリックアクセスネットワーク４０６ａの中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ４０２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ４１０は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ４０２に送信する。ホーム登録の後、ＭＮ４０２とＣＮ４０４との間のトラヒックは、以下のように、方法３００に従ってルート最適化されうる。

１．トンネルされたデータ：ＭＮ４０２は、ＣＮ４０４のＩＰｖ４アドレスとＵＤＰポートとを搬送するＩＰｖ４気付アドレスのオプションを含む、トンネルされたトラヒックを、ＣＮ４０４から受信する。この情報を受信すると、ＭＮ４０２は、ＣＮ４０４へ向けたルート最適化手順を開始する。

２．ＨｏＴＩ：ＭＮ４０２がＣＮ４０４のＩＰｖ４アドレスを知っている場合、ＭＮ４０２はＨｏＴＩメッセージをＣＮ４０４へ送信する。ＨｏＴＩメッセージは、ＨＡ４１０を経由してＣＮ４０４へトンネルされる。ＨｏＴＩメッセージの中では、予約フィールドからの１ビットが、ＭＮ４０２が２つのノード４０２と４０４との間でトラヒックをトンネルさせたいと望んでいるということをＣＮ４０４に知らせるためのフラグとしてセットされ、使用される。

３．ＣｏＴＩ：ＭＮ４０２がＣＮ４０４のＩＰｖ４アドレスを知っている場合、ＭＮ４０２はＣｏＴＩメッセージをＩＰｖ４／ＵＤＰトンネル４０７の中で直接ＣＮ４０４へ送信できる。ＣｏＴＩメッセージの中では、予約フィールドからの１ビットが、ＭＮ４０２が２つのノード４０２と４０４の間でトラヒックをトンネルさせたいと望んでいるということをＣＮ４０４に知らせるためのフラグとしてセットされ、使用される。

４．ＨｏＴ：ＣＮ４０４は、ＭＮ４０２によって送信されたＨｏＴＩメッセージに対してＨｏＴメッセージで応答する。ＨｏＴメッセージは、ＭＮ４０２のＩＰｖ４／ＩＰｖ６のＨｏＡへ送信され、ＨＡ４１０を経由してＭＮ４０２へトンネルされる。ＣＮ４０４は、ＩＰｖ４／ＵＤＰトンネル４０７の中でＩＰｖ６パケットをトンネルさせることができる場合、ＣｏＴメッセージの予約フィールドの中にフラグをセットする。

５．ＣｏＴ：ＣＮ４０４は、ＭＮ４０２によって送信されたＣｏＴＩメッセージに対してＣｏＴメッセージで応答する。ＣｏＴメッセージは、ＩＰｖ４／ＵＤＰトンネル４０７の中をＭＮ４０２のＩＰｖ４アドレスへトンネルされる。ＣＮ４０４は、自分がＩＰｖ６パケットをＩＰｖ４／ＵＤＰトンネル４０７の中でトンネリングできることをＭＮ４０２に知らせるため、ＣｏＴメッセージ内の予約フィールドの中にフラグをセットする。着信するＣｏＴメッセージをＭＮ４０２が受信するためには、ＭＮ４０２は、ＩＰｖ４／ＵＤＰトンネル４０７の中でＩＰｖ６トラヒックをトンネルする目的で自分が用いるＵＤＰポートをリッスンする必要がある。特に、ＭＮ４０２は、自分のプライベートＩＰｖ４アドレスおよびＵＤＰポートをリッスンする。

６．ＢＵ：ＭＮが（指定のフラグビットがセットされている）ＨｏＴメッセージおよびＣｏＴメッセージを受信した場合、ＭＮ４０２は、ＩＰｖ４／ＵＤＰトンネル４０７の中でＢＵメッセージをＣＮ４０４へトンネルする。またＭＮ４０２は、対応するＣＮ４０４についての自分のバインド更新リスト（ＢＵＬ）のエントリを更新する（図４Ａを参照のこと）。ＨｏＴメッセージおよびＣｏＴメッセージの予約フィールドの中のフラグのうちいずれか１つでもセットされていなかった場合には、ＭＮはＢＵを送信せず、トラヒックは２つのノード４０２と４０４との間でルート最適化されない。

７．ＢＡ：ＣＮ４０４は、ＢＵを受信した場合、ＭＮ４０２についての自分のバインドキャッシュ（ＢＣ）へのエントリを作成し、また、ＩＰｖ４／ＵＤＰ双方向トンネル４０７についてのエントリを自分のルーティングテーブルに追加する（図４Ａを参照のこと）。ＢＣエントリが作成された後、ＣＮ４０４は、ＢＡメッセージをＭＮ４０２へ送信する。ＢＡメッセージは、ＩＰｖ４／ＵＤＰ双方向トンネル４０７を通って、ＭＮ４０２に直接送信される。

８：ルート最適化されたデータ：ＢＵメッセージとＢＡメッセージとの交換が成功した後、ＭＮ４０２とＣＮ４０４とは、それらの間のすべてのＩＰｖ６トラヒックをＩＰｖ４／ＵＤＰトンネル４０７の中でトンネルできる。

以上のように、前述のルート最適化手順は、ＨｏＴＩメッセージ、ＣｏＴＩメッセージ、ＨｏＴメッセージ、ＣｏＴメッセージ、ＨｏＴメッセージ、ＣｏＴメッセージ、ＢＵメッセージおよびＢＡメッセージの利用を含む。これらのメッセージの詳細は、よく知られており、下記の文書の中で見つけられる。
・Ｊｏｈｎｓｏｎ、Ｐｅｒｋｉｎｓ、Ａｒｋｋｏ：「ＩＰｖ６におけるモビリティサポート」、ＲＦＣ３７７５、２００４年６月」
この文書の内容は、参照により本願に援用する。

ＭＮ４０２は、ルーティングテーブル４２４とバインド更新リスト４２６とを含む。そして、ＣＮ４０４は、ルーティングテーブル４２４とバインドキャッシュ４３０とを含む。典型的なルーティングテーブル４２４および４２８、バインド更新リスト４２６およびバインドキャッシュ４３０を、下記に示す。

ＭＮのルーティングテーブル４２４
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ６" |"ＨＡ ＩＰｖ４" |ＵＤＰ ｔｕｎｎｅｌｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＣＮ ＩＰｖ６" |"ＣＮ ＩＰｖ４" |ＵＤＰ ｔｕｎｎｅｌｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＣＮ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＭＮのバインド更新リスト４２６
-------------------------------------------------------------------------------
|"CN IPv6" ＜-＞ "MN IPv6 CoA" ＜-＞ "MN IPv6 HoA" ＜-＞ “HA IPv6" |
-------------------------------------------------------------------------------
|"CN IPv4" ＜-＞ "MN IPv4 CoA" ＜-＞ "MN IPv4 HoA" ＜-＞ "HA IPv4" |
-------------------------------------------------------------------------------

ＣＮのルーティングテーブル４２８
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ６ ＣｏＡ" |"ＭＮ ＩＰｖ４ ＣｏＡ" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４ ＣｏＡ" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＣＮのバインドキャッシュ４３０
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ６" ＨｏＡ" ＜−＞ "ＭＮ ＩＰｖ６ ＣｏＡ" |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４" ＨｏＡ" ＜−＞ "ＭＮ ＩＰｖ４ ＣｏＡ" |
-------------------------------------------------------------------------------

留意すべきことだが、ＣＮ４０４が、ＩＰｖ４／ＵＤＰトンネル４０７内でのＩＰｖ６トラヒックのトンネリングをサポートしない場合は、たとえＭＮ４０２がＩＰｖ６アクセスネットワークにアタッチしていても、ＭＮ４０２は、ＣＮ４０４とのルート最適化を実行できない。これは、ＭＮ４０２が、ＩＰｖ４アクセスネットワーク４０６へ移動しないであろうとは保証できないからである。更に留意すべきことだが、ＭＮのいずれか１つがイントラネットまたはエクストラネットに接続されている場合、あるいは、ＭＮのいずれか１つがイントラネット／エクストラネットに接続され、それが次にインターネットに接続されている場合にも、本発明を使用可能である。

図５を参照すると、ＭＮ４０２がＩＰｖ４プライベートアクセスネットワーク４０６ｂへ移動した後でもなお、ＩＰｖ６ＣＮ４０４へのその到達可能性を維持できるように、ＩＰｖ６ＭＮ４０２によってどのようにルート最適化方法３００が用いられうるかを説明する一助とするのに用いられる図が示されている。図５に示すように、ＣＮ４０４は、ＩＰｖ４ルータ４１６とＩＰｖ６ルータ４１８とを有するＩＰｖ４／ＩＰｖ６混合アクセスネットワーク４１４に位置する。そして、ＭＮ４０２は、ＨＬ４０８から、ネットワーク・アドレス・トランスレータ（ＮＡＴ）４２２を有するＩＰｖ４プライベートアクセスネットワーク４０６ｂへ、移動してきた。

ＭＮ４０２は、この場合、ＮＡＴ４２２が存在するためにホーム登録手順が異なるということを除いて、図４Ａおよび４Ｂに関して上記で論じたものと同様に、ＩＰｖ４／ＵＤＰ双方向トンネル４０７を経由してＣＮ４０４と通信できる。ホーム登録手順の違いを、次に説明する。ＭＮ４０２は、自分がＩＰｖ４プライベートアクセスネットワーク４０６ｂに接続していることを発見すると、自分のＨＡ４１０へＢＵメッセージを送信する。ＭＮ４０２は、ＢＵメッセージに「ＩＰｖ４気付アドレスのオプション」を追加する。特に、ＭＮ４０２は、自分のＩＰｖ４アドレスを気付アドレスとして、そして、ソース（送信元）ＵＤＰポートをＵＤＰポートとして、使用する。ＩＰｖ４プライベートアクセスネットワーク４０６ｂはＮＡＴ４２２の背後にあるため、オプションはＩＰｖ６ヘッダの内側にあり、かつ、これらのヘッダはＩＰＳｅｃで暗号化されていることから、オプションは変換されないであろう。従って、ＨＡ４１０は、ＢＵを受信すると、トンネルされたパケットの外側ヘッダのソースアドレスおよびＵＤＰポートを、「ＩＰｖ４気付アドレスのオプション」のＩＰｖ４アドレスおよびＵＤＰポートと比較する。それらが異なる場合には、ＨＡ４１０は、ＮＡＴ４２２のＩＰｖ４ソースアドレスとＵＤＰポートとを、受信したＩＰｖ４ヘッダからのオプションにコピーする。このオプションは、ＭＮ４０２に返信されるＢＡに追加される。このようにして、ＭＮ４０２は、ＢＡを受信すると、自分がＮＡＴ４２２の背後に位置しているのかどうかを知るであろう。加えて、ＭＮ４０２は、ＩＰｖ６トラヒックをＩＰｖ４／ＵＤＰトンネル内でトンネルさせるのに必要な、グローバルにルーティング可能なＩＰｖ４アドレスとＵＤＰポートとを知っている。加えて、ＭＮ４０２は、ルーティングテーブル５２４とバインド更新リスト５２６とを含む。そして、ＣＮ４０４は、ルーティングテーブル５２８とバインドキャッシュ５３０とを含む。典型的なルーティングテーブル５２４および５２８、バインド更新リスト５２６およびバインドキャッシュ５３０を、下記に示す。

ＭＮのルーティングテーブル５２４
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ６" |"ＨＡ ＩＰｖ４" |ＵＤＰ ｔｕｎｎｅｌｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＣＮ ＩＰｖ６" |"ＣＮ ＩＰｖ４" |ＵＤＰ ｔｕｎｎｅｌｉｎｔｆ１ |
-------------------------------------------------------------------------------
|"ＨＡ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＣＮ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＭＮのバインド更新リスト５２６
-------------------------------------------------------------------------------
|"CN IPv6" ＜-＞ "MN IPv6 CoA" ＜-＞ "MN IPv6 HoA" ＜-＞ “HA IPv6" |
-------------------------------------------------------------------------------
|"CN IPv4" ＜-＞ "MN IPv4 CoA" ＜-＞ "MN IPv4 HoA" ＜-＞ "HA IPv4" |
-------------------------------------------------------------------------------

ＣＮのルーティングテーブル５２８
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ６ ＣｏＡ" |"ＭＮ ＩＰｖ４ ＣｏＡ" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４ ＣｏＡ" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＣＮのバインドキャッシュ５３０
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ６" ＨｏＡ" ＜−＞ "ＭＮ ＩＰｖ６ ＣｏＡ" |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４" ＨｏＡ" ＜−＞ "ＭＮ ＩＰｖ４ ＣｏＡ" |
-------------------------------------------------------------------------------

図６乃至８を参照すると、本発明によるルート最適化方法６００の第２の実施形態を説明する一助とするのに用いられる図がいくつか示されている。基本的に、ルート最適化方法６００は、ノード７０２と７０４とのうちの一方もしくは両方がＩＰｖ４限定アクセスネットワーク７０６および７１４へ移動してもなお、ＩＰｖ６ＭＮ７０２がもう１つのＩＰｖ６ＭＮ７０４へのその到達可能性を維持するのを可能にする。ＭＮ７０２は、いくつかの前提条件があれば、異種の環境あるもう１つのＭＮ７０４との間でルート最適化方法６００を用いることができる。第１に、ＭＮ７０２と７０４とは、両方とも、ＩＰｖ４アドレスとＩＰｖ６アドレスとを持つ必要がある。また、ＭＮ７０２と７０４とは、ＩＰｖ４／ＵＤＰトンネル７０７内でのＩＰｖ６パケットのトンネリングをサポートしなければならない。加えて、ＭＮ７０２と７０４とは、「ＩＰｖ４気付アドレスのオプション」をサポートしなければならない。このオプションは、自分たち自身のグローバルにルーティング可能なＩＰｖ４アドレスとＵＤＰポートとを知るため、そして、どのＩＰｖ４アドレスに対してルート最適化されたＩＰｖ６パケットをトンネルしなければならないかをＭＮ７０２と７０４とのうちの相手側に知らせるため、ＭＮ７０２と７０４の各々によって用いられる。留意すべきだが、ＭＮ７０２と７０４とは、異なるアドレスバージョンを用いるアクセスネットワーク内にそれらが位置している場合、相互の間でルーティングを最適化することができない。

ルート最適化方法６００が図７および８に示される２つの異なるシナリオにおいてどのように用いられるかを議論する前に、ルート最適化方法６００の基本的なステップについて簡単な説明を行う。第１に、ＭＮ７０２（ＭＮ１）は、ＭＮ７０４が、２つのＨＡ７０６と７０８とを通じて送信されるＭＮ７０４のトラヒックの中でＩＰｖ４気付アドレスというオプションをＭＮ７０２へ送信しているかどうかチェックすることによって、ＭＮ７０４（ＭＮ２）のＩＰｖ４到達可能性を判断する（図６のステップ６０２を参照のこと）（図７および８も参照のこと）。送信しているならば、ＭＮ７０２は、ＭＮ７０４がインターネット７１２を通じて直接ＭＮ７０２とＭＮ７０４との間でＩＰｖ４／ＵＤＰ双方向トンネル７０７を確立できるかどうか、判断する（図６のステップ６０４を参照のこと）。確立できるならば、ＭＮ７０２は、ＭＮ７０４とのＩＰｖ４／ＵＤＰ双方向トンネル７０７の一方向を確立する（図６のステップ６０６を参照のこと）。同様に、ＭＮ７０４も、ＭＮ７０２が、２つのＨＡ７０８と７０６とを通じて送信されるＭＮ７０２のトラヒックの中でＩＰｖ４気付アドレスというオプションをＭＮ７０４へ送信しているかどうかチェックすることによって、ＭＮ７０２のＩＰｖ４到達可能性を判断する（図６のステップ６０８を参照のこと）（図７および８も参照のこと）。送信しているならば、ＭＮ７０４は、ＭＮ７０２がインターネット７１２を通じて直接ＭＮ７０２とＭＮ７０４との間でＩＰｖ４／ＵＤＰ双方向トンネル７０７を確立できるかどうか、判断する（図６のステップ６１０を参照のこと）。確立できるならば、ＭＮ７０４は、ＭＮ７０２とのＩＰｖ４／ＵＤＰ双方向トンネル７０７の一方向を確立する（図６のステップ６１２を参照のこと）。その後、ＩＰｖ６トラヒックは、ＩＰｖ４／ＵＤＰ双方向トンネル７０７の中でＭＮ７０２とＭＮ７０４との間で往復するようにルーティングされる（図６のステップ６１４を参照のこと）。ステップ６０２、６０４、６０８、および６１０のうち、いずれかの判断が、ＮＯであれば、ＩＰｖ４／ＵＤＰ双方向トンネル７０７は確立されず、ＭＮ７０２は、インターネット７１２とＨＡ７０６および７０８の両方を通じて、ＩＰｖ６トラヒックをＭＮ７０４と送受信しなければならない（図６のステップ６１６を参照のこと）（図２Ａを参照のこと）。以下に、ステップ６０２、６０４．．．６１６が、どのようにして実装されうるかについて、図７および８に示す２つのシナリオに関して詳細に記述する。

図７Ａおよび７Ｂを参照すると、ＭＮ７０２とＭＮ７０４との両方がＩＰｖ４パブリックアクセスネットワーク７１６ａおよび７１４ａへ移動した場合でもなお、ルート最適化方法６００がどのようにして、ＩＰｖ６ＭＮ７０２がもう１つのＩＰｖ６ＭＮ７０４へのその到達可能性を維持できるようにするかを説明する一助とするのに用いられる、図およびシグナリングフロー図が示されている。図７Ａに示すように、第１のＩＰｖ６ＭＮ７０２は、ＩＰｖ４ルータ７１８を有するＩＰｖ４パブリックアクセスネットワーク７１６ａに位置する。第１のＭＮ７０２は、ＨＡ７０８を有するＨＬ７２０から、ＩＰｖ４パブリックアクセスネットワーク７１６ａへ、移動してきた。第２のＩＰｖ６ＭＮ７０４は、ＩＰｖ４ルータ７２２を有するＩＰｖ４パブリックアクセスネットワーク７１４ａに位置する。第２のＭＮ７０４は、ＨＡ７０６を有するＨＬ７２４から、ＩＰｖ４パブリックアクセスネットワーク７１４ａへ、移動してきた。そして、第１のＭＮ７０２は、次に論じるように、ＩＰｖ４／ＵＤＰ双方向トンネル７０７を通じてインターネット７１２を経由して、第２のＭＮ７０４と通信することができる。

図７Ａおよび７Ｂに示すように、第１のＭＮ７０２は、ＨＬ７２０からＩＰｖ４パブリックアクセスネットワーク７１６ａへ移動した後、ＨＡ７０８にホーム登録を行う（信号１ａおよび２ａを参照のこと）。ホーム登録を行うため、第１のＭＮ７０２は、ＢＵをＨＡ７０８へ送信する（信号１ａ）。第１のＭＮ７０２はＩＰｖ４パブリックアクセスネットワーク７１６ａの中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、第１のＭＮ７０２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ７０８は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ７０２に送信する（信号２ａ）。同様に、第２のＭＮ７０４は、ＢＵをＨＡ７０６へ送信する（信号１ｂ）。第２のＭＮ７０４はＩＰｖ４パブリックアクセスネットワーク７１４ａの中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ７０４はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ７０６は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ７０４に送信する（信号２ｂ）。ホーム登録の後、ＭＮ７０２とＭＮ７０４の間のトラヒックは、以下のように方法６００によってルート最適化されうる。

１ａおよび１ｂ．ＢＵ：ＭＮ７０２と７０４とは両方とも、新たなＩＰｖ４限定アクセスネットワーク７１６ａおよび７１４ａに移動する場合、ＢＵをそれらの各々のＨＡ７０８および７０６へ送信する。ネットワークがＩＰｖ４ネットワークであると想定すれば、ＭＮ７０２および７０４はそれぞれ、そのグローバルＩＰｖ４アドレスとＵＤＰポートとを知るために、ＢＵメッセージにＩＰｖ４気付アドレスのオプションを追加する。これらのステップは、ホーム登録プロセスの一部である。

２ａおよび２ｂ．ＢＡ：ＭＮ７０２および７０４が、ＨＡ７０８および７０６からＢＡを受信した後、ホーム登録は完了する。また、ＢＡメッセージは、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送する。これらのステップは、ホーム登録プロセスの一部である。

３．トンネルされたデータ：ＭＮ７０２は、ＭＮ７０４からトンネルされたデータを受信する。このトラヒックは、ＭＮ７０４のグローバルなＩＰｖ４アドレスとＵＤＰポートとを搬送するＩＰｖ４気付アドレスを保持する。理解されるべきだが、ＭＮ７０２がＩＰｖ６アクセスネットワーク内に位置する場合、ＭＮ７０２に着信するパケットがその中に「ＩＰｖ４気付アドレスのオプション」を有するならば、ＭＮ７０２はルート最適化を開始しないであろう。また、２つのＭＮ７０２および７０４がＩＰｖ６アクセスネットワーク内にいる場合、ルート最適化は、通常通り行われる[ＲＦＣ３７７５を参照のこと]。

４．ＨｏＴＩ：ＭＮ７０２は、ＨｏＴＩメッセージをＭＮ７０４へ送信する。ＨｏＴＩメッセージは、ＩＰｖ４／ＵＤＰトンネルの中でＨＡ７０８へトンネルされる。次いで、ＨＡ７０８は、ＨｏＴＩメッセージをＨＡ７０６へ送信する。ＨＡ７０６は、パケットをＭＮ７０４へトンネルさせる。ＨｏＴＩメッセージの中では、ＭＮ７０２が２つのＭＮ７０２と７０４との間でトラヒックをトンネルさせたいと望んでいることをＭＮ７０４に知らせるため、予約フィールドの中にフラグがセットされている。

５．ＣｏＴＩ：また、ＭＮ７０２は、ＣｏＴＩメッセージをＭＮ７０４へ送信する。ＣｏＴｉパケットは、「ＩＰｖ４気付アドレスのオプション」の中で指定された、ＭＮ７０４のＩＰｖ４ ＣｏＡとＵＤＰポート番号とを用いて、直接ＭＮ７０４へトンネルされる。ＣｏＴＩメッセージの中では、予約フィールドからの１ビットが、ＭＮ７０２が２つのノード７０２と７０４との間でトラヒックをトンネルさせたいと望んでいることをＭＮ７０４に知らせるためのフラグとしてセットされ、使用される。ＣｏＴＩメッセージをＭＮ７０４が受信するためには、ＭＮ７０４は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６トラヒックをトンネルする目的で自分が用いるＵＤＰポートをリッスンする必要がある。

６．トンネルされたデータ：ルート最適化が完了する前に、ＭＮ７０２は、パケットをＭＮ７０４へ送信する。ＭＮ７０２は、「ＩＰｖ４気付アドレスのオプション」をトンネルされるパケットに追加する。これらのトンネルされたパケットによって、ＭＮ７０４は、ＭＮ７０２とのルート最適化を開始する。

７．ＨｏＴ：ＭＮ７０４がＩＰｖ４／ＵＤＰトンネリングをサポートする場合、ＭＮ７０４は、ＭＮ７０２によって送信されたＨｏＴＩメッセージに対してＨｏＴメッセージで応答する。このパケットは、ＭＮ７０２のＨｏＡへ送信され、ＨＡ７０６と７０８とを経由してＭＮ７０２へトンネルされる。加えて、ＭＮ７０４は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６パケットをトンネルさせることができる場合、ＨｏＴメッセージの予約フィールドの中にフラグをセットする。留意すべきだが、ＨｏＴＩメッセージが、メッセージの予約フィールドの中にセットされたフラグを有しない場合には、ＭＮ７０４は、ＨｏＴＩメッセージには応答しないであろう。

８．ＣｏＴ：ＭＮ７０４がＩＰｖ４／ＵＤｐトンネリングをサポートする場合、ＭＮ７０４は、ＭＮ７０２によって送信されたＣｏＴＩメッセージに対してＣｏＴメッセージで応答する。このパケットは、ＣｏＴＩメッセージ内の「ＩＰｖ４気付アドレスのオプション」の中に提供されたＭＮ７０２のＩＰｖ４ ＣｏＡとＵＤＰポートとに直接トンネルされる。加えて、ＭＮ７０４は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６パケットをトンネルさせることができる場合、ＣｏＴメッセージの予約フィールドの中にフラグをセットする。留意すべきだが、ＣｏＴＩメッセージが、メッセージの予約フィールドの中にセットされたフラグを有しない場合には、ＭＮ７０４は、ＣｏＴＩメッセージには応答しないであろう。

９．ＨｏＴＩ：ＭＮ７０４は、トンネルされたトラヒックをＭＮ７０２から受信し、これらのパケットがその中に「ＩＰｖ４気付アドレスのオプション」を有する場合、ルート最適化手順を開始する。ＭＮ７０４は、ＨｏＴＩメッセージをＭＮ７０２のＩＰｖ６ホームアドレスへ送信することによって、手順を開始する。ＨｏＴＩメッセージは、ＨＡ７０６と７０８とを経由してＭＮ７０２へトンネルされる。ＨｏＴＩメッセージの中では、ＭＮ７０４が２つのＭＮ７０２と７０４との間でトラヒックをトンネルさせたいと望んでいることをＭＮ７０２に知らせるため、予約フィールドの中にフラグがセットされている。

１０．ＣｏＴＩ：また、ＭＮ７０４は、ＣｏＴＩメッセージをＭＮ７０２へ送信する。ＣｏＴＩパケットは、「ＩＰｖ４気付アドレスのオプション」の中に指定されたＭＮ７０２のＩＰｖ４ＣｏＡとＵＤＰポート番号とを用いて、直接ＭＮ７０２へトンネルされる。ＣｏＴＩメッセージの中では、予約フィールドからの１ビットが、ＭＮ７０４が２つのノード７０２と７０４との間でトラヒックをトンネルさせたいと望んでいることをＣＮ７０２に知らせるためのフラグとしてセットされ、使用される。ＣｏＴＩメッセージを受信するためには、ＭＮ７０２は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６トラヒックをトンネルする目的で自分が用いるＵＤＰポートをリッスンする必要がある。

１１．ＨｏＴ：ＭＮ７０４がＩＰｖ４／ＵＤＰトンネリングをサポートする場合、ＭＮ７０２は、ＭＮ７０４によって送信されたＨｏＴＩメッセージに対してＨｏＴメッセージで応答する。このパケットは、ＭＮ７０４のＨｏＡへ送信され、ＨＡ７０６と７０８とを経由してＭＮ７０４へトンネルされる。加えて、ＭＮ７０２は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６パケットをトンネルさせることができる場合、ＨｏＴメッセージの予約フィールドの中にフラグをセットする。留意すべきだが、ＨｏＴＩメッセージが、メッセージの予約フィールドの中にセットされたフラグを有しない場合には、ＭＮ７０２は、ＨｏＴＩメッセージには応答しないであろう。

１２．ＣｏＴ：ＭＮ７０２がＩＰｖ４／ＵＤｐトンネリングをサポートする場合、ＭＮ７０２は、ＭＮ７０４によって送信されたＣｏＴＩメッセージに対してＣｏＴメッセージで応答する。このパケットは、ＣｏＴＩメッセージ内の「ＩＰｖ４気付アドレスのオプション」の中に提供されたＭＮ７０４のＩＰｖ４ ＣｏＡとＵＤＰポートとに直接トンネルされる。加えて、ＭＮ７０２は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＩＰｖ６パケットをトンネルさせることができる場合、ＣｏＴメッセージの予約フィールドの中にフラグをセットする。留意すべきだが、ＣｏＴＩメッセージが、メッセージの予約フィールドの中にセットされたフラグを有しない場合には、ＭＮ７０２は、ＣｏＴＩメッセージには応答しないであろう。

１３．ＢＵ：ＭＮ７０２は、ＭＮ７０４からＨｏＴメッセージおよびＣｏＴメッセージを受信した後、両方のメッセージが予約フィールドの中にセットされたフラグを有する場合、ＢＵをＭＮ７０４へ送信するであろう。ＢＵは、ＭＮ７０４のＩＰｖ４ＣｏＡとＵＤＰポートとに直接トンネルされる。また、ＭＮ７０２はＢＵＬエントリを追加するが、その中でＭＮ７０２は、ＭＮ７０４のＩＰｖ６ ＨｏＡおよびＣｏＡと、ＩＰｖ４のＣｏＡおよびＵＤＰポートとを追加する。また、ＭＮ７０２は、ＭＮ７０４へのＩＰｖ４／ＵＤＰ双方向トンネル７０７についてのルーティングテーブルのエントリを追加する。

１４．ＢＡ：ＭＮ７０４は、ＢＵを受信した場合には、ＭＮ７０２についてのＢＣエントリを追加する。このエントリの中に、ＭＮ７０４は、ＭＮ７０２のＩＰｖ６ ＨｏＡおよびＣｏＡと、ＩＰｖ４ ＣｏＡおよびＵＤＰポートとを追加する。また、ＭＮ７０４は、ＭＮ７０２へのＩＰｖ４／ＵＤＰ双方向トンネル７０７を、自分のルーティングテーブルに追加する。ルーティングテーブルとＢＣとが更新されると、ＭＮ７０４は、ＩＰｖ４／ＵＤＰトンネル７０７の中でＢＡメッセージをＭＮ７０２にトンネルする。

１５．ＢＵ：ＭＮ７０４は、ＨｏＴメッセージとＣｏＴメッセージとをＭＮ７０２から受信した後、メッセージが両方とも予約フィールドにセットされたフラグを有する場合に限って、ＢＵをＭＮ７０２へ送信するであろう。ＢＵは、ＭＮ７０２のＩＰｖ４ＣｏＡとＵＤＰポートとに直接トンネルされる。また、ＭＮ７０４は、ＢＵＬエントリも追加するが、その中で、ＭＮ７０２のＩＰｖ６ ＨｏＡおよびＣｏＡと、ＩＰｖ４ ＣｏＡおよびＵＤＰポートとを追加する。また、ＭＮ７０４は、ＭＮ７０２へのＩＰｖ４／ＵＤＰ双方向トンネル７０７についてのルーティングテーブルのエントリを追加する。

１６．ＢＵ：ＭＮ７０２は、ＢＵを受信すると、ＭＮ７０４についてのＢＣエントリを追加する。このエントリの中に、ＭＮ７０２は、ＭＮ７０４のＩＰｖ６ ＨｏＡおよびＣｏＡと、ＩＰｖ４ ＣｏＡおよびＵＤＰポートとを追加する。また、ＭＮ７０２は、ＭＮ７０４へのＩＰｖ４／ＵＤＰ双方向トンネル７０７を自分のルーティングテーブルに追加する。ルーティングテーブルとＢＣとが更新された場合には、ＭＮ７０２は、ＩＰｖ４／ＵＤＰトンネル７０７の中で、ＭＮ７０４へのＢＡメッセージをトンネルする。

１７．ルート最適化されたデータ：ＭＮ７０２と７０４との両方が、それらが送信したＢＵについてのＢＡを受信した後で、ルート最適化手順は終了し、２つのＭＮ７０２と７０４との間のＩＰｖ６トラヒックは、相互に直接、ＩＰｖ４／ＵＤＰ双方向トンネル７０７の中でルーティングされる。

１８．ＢＵ（存続時間＝０）：例えば、ＭＮ７０２が、ＩＰｖ４アクセスネットワークにアタッチするＭＮ７０４とバインドしている間にＩＰｖ６アクセスネットワークへ移動する場合、ＭＮ７０２は、ホーム登録を実行した後でＢＵメッセージ（存続時間＝０）を２つのＨＡ７０６と７０８とを経由してＭＮ７０４へトンネルさせる。このＢＵにおいて、バインドに関する存続時間は、トラヒックは２つのＭＮ７０２と７０４との間でこれ以上ルート最適化されえないことをＭＮ７０４に知らせるためにゼロに設定される。理解されるべきだが、ＭＮ７０２と７０４のうちの１つが、別のＩＰｖ４アクセスネットワークへ移動する場合、それらの間のバインドは、「ＩＰｖ４気付アドレスのオプション」の中に新たなＩＰｖ４ ＣｏＡを含む新たなＢＵを送信することによって、更新される必要がある。

加えて、ＭＮ７０２（ＭＮ１）は、ルーティングテーブル７２６と、バインド更新リスト７２８と、バインドキャッシュ７３０とを含む。そして、ＭＮ７０４（ＭＮ２）は、ルーティングテーブル７３２と、バインド更新リスト７３４と、バインドキャッシュ７３６とを含む。典型的なルーティングテーブル７２６および７３２、バインド更新リスト７２８および７３４、バインドキャッシュ７３０および７３６を以下に示す。

ＭＮ１のルーティングテーブル７２６
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ１ ＩＰｖ６" |"ＨＡ１ ＩＰｖ４" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＭＮ２ ＩＰｖ６ ＣｏＡ" |"ＭＮ２ ＩＰｖ４ ＣｏＡ" |ＵＤＰ tunnelintf1 |
-------------------------------------------------------------------------------
|"ＨＡ１ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４ ＣｏＡ" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＭＮ１のバインド更新リスト７２８
-------------------------------------------------------------------------------
|"MN2 IPv6 CoA" ＜-＞ "MN IPv6 CoA" ＜-＞ "MN1 IPv6 HoA" ＜-＞ “HA IPv6" |
-------------------------------------------------------------------------------
|"MN2 IPv4 CoA" ＜-＞ "MN IPv4 CoA" ＜-＞ "MN IPv4 HoA" ＜-＞ "HA IPv4" |
-------------------------------------------------------------------------------

ＭＮ１のバインドキャッシュ７３０
-------------------------------------------------------------------------------
|"ＭＮ２ ＩＰｖ６ ＨｏＡ" ＜−＞ "ＭＮ２ ＩＰｖ６ ＣｏＡ" |
-------------------------------------------------------------------------------
|"ＭＮ２ ＩＰｖ４" ＨｏＡ" ＜−＞ "ＭＮ２ ＩＰｖ４ ＣｏＡ" |
-------------------------------------------------------------------------------

ＭＮ２のルーティングテーブル７３２
-------------------------------------------------------------------------------
|宛先： |次のホップ： |Ｉｎｔｆ： |
-------------------------------------------------------------------------------
|"ＨＡ２ ＩＰｖ６" |"ＨＡ１ ＩＰｖ４" |ＵＤＰ tunnelintf0 |
-------------------------------------------------------------------------------
|"ＭＮ１ ＩＰｖ６ ＣｏＡ" |"ＭＮ１ ＩＰｖ４ ＣｏＡ" |ＵＤＰ tunnelintf1 |
-------------------------------------------------------------------------------
|"ＨＡ２ ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＭＮ１ ＩＰｖ４ ＣｏＡ" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０ |
-------------------------------------------------------------------------------

ＭＮ２のバインド更新リスト７３４
-------------------------------------------------------------------------------
|"MN1 IPv6 CoA" ＜-＞ "MN2 IPv6 CoA" ＜-＞ "MN2 IPv6 HoA" ＜-＞ “HA2 IPv6" |
-------------------------------------------------------------------------------
|"MN1 IPv4 CoA" ＜-＞ "MN2 IPv4 CoA" ＜-＞ "MN2 IPv4 HoA" ＜-＞ "HA2 IPv4" |
-------------------------------------------------------------------------------

ＭＮ２のバインドキャッシュ７３６
-------------------------------------------------------------------------------
|"ＭＮ１ ＩＰｖ６ ＨｏＡ" ＜−＞ "ＭＮ１ ＩＰｖ６ ＣｏＡ" |
-------------------------------------------------------------------------------
|"ＭＮ ＩＰｖ４" ＨｏＡ" ＜−＞ "ＭＮ ＩＰｖ４ ＣｏＡ" |
-------------------------------------------------------------------------------

図８を参照すると、ＭＮ７０２とＭＮ７０４との両方がＩＰｖ４プライベートアクセスネットワーク７１６ｂおよび７１４ｂへ移動した場合でもなお、ルート最適化方法６００がどのようにして、ＩＰｖ６ＭＮ７０２がもう１つのＩＰｖ６ＭＮ７０４へのその到達可能性を維持できるようにするかを説明する一助とするのに用いられる図が示されている。図８に示すように、第１のＩＰｖ６ＭＮ７０２は、ＮＡＴ７２６を有するＩＰｖ４プライベートアクセスネットワーク７１６ｂに位置する。第１のＭＮ７０２は、ＨＡ７０８を有するＨＬ７２０から、ＩＰｖ４プライベートアクセスネットワーク７１６ｂへ、移動してきた。第２のＩＰｖ６ＭＮ７０４は、ＮＡＴ７２８を有するＩＰｖ４プライベートアクセスネットワーク７１４ｂに位置する。第２のＭＮ７０４は、ＨＡ７０６を有するＨＬ７２４から、ＩＰｖ４プライベートアクセスネットワーク７１４ｂへ、移動してきた。

ＭＮ７０２は、この場合、ＮＡＴ７２６と７２８とが存在するためにホーム登録手順が異なるということを除いて、図７Ａおよび７Ｂに関して上記で論じたものと同様に、ＩＰｖ４／ＵＤＰ双方向トンネル７０７を経由して第２のＭＮ７０４と通信できる。ホーム登録プロセスの違いを、次に説明する。ＭＮ７０２は、自分が(例えば）ＩＰｖ４プライベートアクセスネットワーク７１６ｂに接続していることを発見すると、自分のＨＡ７０８へＢＵメッセージを送信する。ＭＮ７０２は、ＢＵメッセージに「ＩＰｖ４気付アドレスのオプション」を追加する。特に、ＭＮ７０２は、自分のＩＰｖ４アドレスを気付アドレスとして、そして、ソースＵＤＰポートをＵＤＰポートとして、使用する。ＩＰｖ４プライベートアクセスネットワーク７１６ｂはＮＡＴ７２６の背後にあるため、オプションはＩＰｖ６ヘッダの内側にあり、かつ、これらのヘッダはＩＰＳｅｃで暗号化されていることから、オプションは変換されないであろう。従って、ＨＡ７０８は、ＢＵを受信すると、トンネルされたパケットの外側ヘッダのソースアドレスおよびＵＤＰポートを、「ＩＰｖ４気付アドレスのオプション」のＩＰｖ４アドレスおよびＵＤＰポートと比較する。それらが異なる場合には、ＨＡ７０８は、ＮＡＴ７２６のＩＰｖ４ソースアドレスとＵＤＰポートとを、受信したＩＰｖ４ヘッダからのオプションにコピーする。このオプションは、ＭＮ７０２に返信されるＢＡに追加される。このようにして、ＭＮ７０２は、ＢＡを受信すると、自分がＮＡＴの背後に位置しているのかどうかを知るであろう。加えて、ＭＮ７０２は、ＩＰｖ６トラヒックをＩＰｖ４／ＵＤＰトンネル内でトンネルさせるのに必要な、グローバルにルーティング可能なＩＰｖ４アドレスとＵＤＰポートとを知っている。この例では、ＭＮ７０４は、ＮＡＴ７２８の背後に位置しているため、同じホーム登録手順に従う。加えて、ＭＮ７０２は、ルーティングテーブル７２６とバインド更新リスト７２８とバインドキャッシュ７３０とを含む。そして、ＭＮ７０４は、ルーティングテーブル７３２とバインド更新リスト７３４とバインドキャッシュ７３６とを含む。典型的なルーティングテーブル７２６および７３２とバインド更新リスト７２８および７３４とバインドキャッシュ７３０および７３６については、上述した。

ここで理解されるべきだが、本発明は、図３乃至８に関して上記で論じた前述のシナリオに加えて、別のシナリオにおいて使用されてもよい。下記の「テーブル」は、本発明が利用されてもよい別のシナリオをいくつか示す。

-------------------------------------------------------------------------------
|モバイルノード |別のノード（ＣＮ|同じホーム|同じネット|コメント |
| |またはＭＮ） |ネット |ワーク内の| |
| | |ワーク |ノード | |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|いいえ |いいえ | |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム |いいえ |いいえ | |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム |いいえ |いいえ |トンネル不使用（１） |
-------------------------------------------------------------------------------
|ホーム |リモートＩＰｖ６|いいえ |いいえ |トンネル不使用（２） |
-------------------------------------------------------------------------------
|ホーム |リモートＩＰｖ４|いいえ |いいえ | |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|はい |いいえ | |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム |はい |いいえ | |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム |はい |いいえ |トンネル不使用（１） |
-------------------------------------------------------------------------------
|ホーム |リモートＩＰｖ４|はい |いいえ | |
-------------------------------------------------------------------------------
|ホーム |リモートＩＰｖ６|はい |いいえ |トンネル不使用（２） |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|いいえ |はい | |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム |いいえ |はい | |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム |いいえ |はい |トンネル不使用（１） |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|はい |はい | |
-------------------------------------------------------------------------------

（１）このシナリオでは、ＩＰｖ４／ＵＤＰトンネルがＭＮともう１つのノードとの間で設定されることはないであろうが、ＨｏＴＩ／ＨｏＴメッセージおよびＣｏＴＩ／ＣｏＴメッセージの中のフラグは使用されなければならない。

（２）上記のコメント１を参照のこと。また、もう１つのノードがＣＮに限定される場合には別のネットワークに移動できないので、このシナリオは、もう１つのノードがＭＮである場合に限って、論理にかなう。

以下に、ルート最適化方法６００に関連する追加の特徴の一部を示す。

・本発明の解決策をサポートしない第３のＭＮ（不図示）が、「ＩＰｖ４気付アドレスのオプション」をパケットのＩＰｖ６ヘッダに追加した（例えば）ＭＮ７０２からトンネルされたトラヒックを受信した場合、第３のＭＮはこのＭＮ７０２とルート最適化手順を行うことはできないであろう。なぜなら、ＭＮ７０２がＩＰｖ４アクセスネットワーク内にいる間は、ＭＮ７０２のＩＰｖ６ ＣｏＡはグローバルにルーティング可能なＩＰｖ６アドレスではなく、第３のＭＮが送信するＨｏＴＩメッセージおよびＣｏＴＩメッセージは、ＭＮ７０２によって受信されることができないからである。

・本発明の解決策をサポートしない第３のＭＮ（不図示）が、（例えば）ＭＮ７０２からトンネルされたトラヒックを受信し、これらのＭＮが両方ともＩＰｖ６アクセスネットワーク（不図示）にアタッチしている場合には、２つのＭＮは、ルート最適化を完了しないであろう。なぜなら、第３のＭＮは、ＨｏＴＩ／ＨｏＴメッセージおよびＣｏＴＩ／ＣｏＴメッセージの予約フィールド内にフラグをセットしていないであろうからである。更に、ＭＮ７０２は、自分がある時点でＩＰｖ４アクセスネットワークへ移動しないとは保証できず、かつ、これが発生した場合には、ＭＮ７０２は、第３のＭＮが（存続時間がゼロに設定された）トンネルされたＢＵをサポートするとは確信できないため、トラヒックは、２つのノード間でルート最適化されないであろう。

・（例えば）ＭＮ７０２がＩＰｖ４アクセスネットワーク７１６にアタッチされている間、ＭＮ７０２は、「ＩＰｖ４気付アドレスのオプション」を自分のＩＰｖ６パケットに追加する。ＭＮ７０２が、トンネルされたトラヒックを、本発明を実装しない第３のＭＮから継続的に受信する場合には、ＭＮ７０２は、第３のＭＮがルート最適化をサポートしないという事実に注目して、パケットのオーバヘッドを削減するため、これらのオプションをパケットに追加するのを中止してもよい。

・「ＩＰｖ４気付アドレスのオプション」は、ＴＬＶ符号化されてもよいだろうが、それはＩＰｖ４気付アドレスとＵＤＰポートとを保持しなければならない。また、この情報は、ＩＰｖ４アクセスネットワークにアタッチされる場合、ＭＮ７０２および７０４のＩＰｖ６ ＣｏＡへと符号化されてもよいだろうが、受信器にＣｏＡがグローバルにルーティング可能なＩＰｖ６アドレスではないことを知らせるため、何らかのフラグが必要である。これは、例えば、前述のＲＦＣ３７７５の中に規定されているＲＨ２を用いて行われてもよいだろう。トラヒックに若干オーバヘッドを追加するとはいえ、本発明の方がシンプルな解決策である。

・（例えば）ＭＮ７０２があるＩＰｖ４アクセスネットワークから、別のＩＰｖ４アクセスネットワークへ移動する場合には、ＭＮ７０２は自分の新たなＩＰｖ４気付アドレスをＨＡ７０８に登録しなければならない。これは、ＩＰｖ４／ＵＤＰトンネルの中でＢＵをトンネルさせることによって行われる。この後で、ＭＮ７０２は、そのバインド更新リスト（ＢＵＬ）の中のすべてのバインドを、新たなＩＰｖ４気付アドレスで更新することができる。次いでＭＮ７０２は、自分の気付アドレスが変わったことを知らせるため、自分がバインドしている各ＭＮ／ＣＮへＢＵを送信する。この後、すべてのトラヒックは、その新たな位置へ送信可能である。

・ＭＮのうちの１つ（例えば、ＭＮ７０２）が、ＩＰｖ６ネットワークへ移動する一方で、他のＭＮ（例えばＭＮ７０４）がＩＰｖ４ネットワークに留まる場合には、確立した双方向トンネルは、ＭＮ７０２および７０４のルーティングテーブルから削除されなければならない。ＩＰｖ４アクセスネットワークからＩＰｖ６アクセスネットワークへの移動を行ったＭＮ７０２は、存続時間＝０のＢＵメッセージを自分のＨＡ７０８を通じてトンネルすることによって、これを開始することができる。受信側のＭＮ７０４が、このトンネルされたＢＵを自分のＨＡ７０６から受信すると、ＭＮ７０４は、自分のバインド更新リスト（ＢＵＬ）とＢＣを、トンネルされたパケットのホームアドレスで確認し、対応するＢＵＬエントリを削除する。この後、２つのＭＮ７０２と７０４との間のトラヒックは、それらのＨＡ７０６および７０８を経由してトンネルされる必要がある。また、２つのＭＮ７０２および７０４が両方ともＩＰｖ６アクセスネットワーク内にいる間にそれらの間のルーティングを最適化し、それらのうちの１つがＩＰｖ４アクセスネットワークへ移動する場合も、同様の手順が行われる。存続時間＝０のＢＵが、ＨＡを経由して他方のＭＮへトンネルされるであろう。

・また、本発明は、ＭＮのうちいずれか１つが、イントラネット、エクストラネットに接続されている場合に使用されてもよいし、更には、ＭＮのうちいずれか１つが、イントラネット／エクストラネットに接続され、それが次いでインターネットに接続されている場合に使用されてもよい。

本発明の２つの実施形態を、添付の図面で図解し、前述の詳細な説明の中で記述してきたが、理解されるべきことは、本発明は、開示された実施形態に限定されるのではなく、上述した、また、下記の請求の範囲によって定義された本発明の精神から逸脱することなく、数多くの再構成、修正、および置換が可能であるということである。

ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。 ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動しても、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動しても、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。 ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。 ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。

Claims (19)

1. 別のノード（４０４，７０４）と通信するモバイルノード（４０２，７０２）であって、
   当該モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより前記別のノード（４０４，７０４）と通信し、
   当該モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置し、
   前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能か否かを当該モバイルノードが判定できるように、当該モバイルノードは、ＨｏＴＩメッセージとＣｏＴＩメッセージとを前記別のノードへ送信し、
   前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能な場合、当該モバイルノードは、前記別のノードに対して前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックを送受信する前に、前記別のノードへＢＵメッセージを送信し、前記別のノードからＢＡメッセージを受信する
   ことを特徴とするモバイルノード。
2. 前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ，７１６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ，７１６ｂ）であることを特徴とする請求項１に記載のモバイルノード。
3. 当該モバイルノードと前記別のノードとが両方とも同一または異なるＩＰｖ４アクセスネットワーク内に位置しているか、あるいは、当該モバイルノードと前記別のノードとのうちの一方は、ＩＰｖ４通信接続性も有するＩＰｖ６アクセスネットワーク内に位置していることを特徴とする請求項１に記載のモバイルノード。
4. 前記別のノードがコレスポンデントノードである場合、当該モバイルノードは、
   前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
   有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
   確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
   前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
   を実行することを特徴とする請求項１に記載のモバイルノード。
5. 前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
   前記ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
   前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
   前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
   前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
   前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
   前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
   を更に備えることを特徴とする請求項４に記載のモバイルノード。
6. 前記別のノードが第２のモバイルノードである場合、当該モバイルノードは、
   前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
   有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
   確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立するステップ（６０６）と、
   当該第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）と、
   を実行することを特徴とする請求項１に記載のモバイルノード。
7. 当該第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
   前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
   当該第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
   前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
   当該第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
   前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
   前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
   前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
   を更に備えることを特徴とする請求項６に記載のモバイルノード。
8. 当該第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
   前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
   のうちの少なくとも一方を満たすことを特徴とする請求項６に記載のモバイルノード。
9. モバイルノード（４０２，７０２）と別のノード（４０４，７０４）との間でのルート最適化のための方法（３００，６００）であって、前記モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置しており、当該方法は、
   前記モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより、前記モバイルノード（４０２，７０２）が前記別のノード（４０４，７０４）と通信することを可能にするステップを備え、
   前記モバイルノードと前記別のノードとがそれぞれＩＰｖ４およびＩＰｖ６の能力を有し、
   前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能か否かを前記モバイルノードが判定できるように、前記モバイルノードは、ＨｏＴＩメッセージとＣｏＴＩメッセージとを前記別のノードへ送信し、
   前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能な場合、前記モバイルノードは、前記別のノードに対して前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックを送受信する前に、前記別のノードへＢＵメッセージを送信し、前記別のノードからＢＡメッセージを受信する
   ことを特徴とする方法。
10. 前記モバイルノードは前記ＩＰｖ４アクセスネットワークにアタッチしており、
    前記モバイルノードは、前記ホームエージェント（４１０，７０８）に対して、ホーム登録手順を実行する
    ことを特徴とする請求項９に記載の方法。
11. 前記別のノードがコレスポンデントノードである場合、前記可能にするステップは、
    前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
    有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
    確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
    前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
    を更に含むことを特徴とする請求項１０に記載の方法。
12. 前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定する前記ステップが、前記コレスポンデントノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップを更に含むことを特徴とする請求項１１に記載の方法。
13. 前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
    前記ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
    前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
    前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
    前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
    前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
    前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
    を更に含むことを特徴とする請求項１１に記載の方法。
14. 前記モバイルノードが、前記ＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（４２２）の背後に位置することを特徴とする請求項１０に記載の方法。
15. 前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ）であり、
    前記別のノードは、ＩＰｖ６アクセスネットワークまたはＩＰｖ４／ＩＰｖ６アクセスネットワーク（４１４）内に位置する
    ことを特徴とする請求項１０に記載の方法。
16. 前記コレスポンデントノードは、モバイルノードであることを特徴とする請求項１１に記載の方法。
17. 前記別のノードが第２のモバイルノードである場合、前記可能にするステップは、
    前記第１のモバイルノードが、
    前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
    有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
    確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルの一方向を確立するステップ（６０６）と、
    を実行するステップと、
    前記第２のＩＰｖ６モバイルノードが、
    前記第１のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０８）と、
    有する場合、前記第１のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６１０）と、
    確立可能な場合、前記第１のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルのもう一方向を確立するステップ（６１２）と、
    を実行するステップと、
    前記第１のモバイルノードと前記第２のモバイルノードとが、
    前記第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）を実行するステップと、
    を更に含むことを特徴とする請求項１０に記載の方法。
18. 前記第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
    前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
    前記第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
    前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
    前記第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
    前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
    前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
    前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
    を更に含むことを特徴とする請求項１７に記載の方法。
19. 前記第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
    前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
    のうちの少なくとも一方を満たすことを特徴とする請求項１７に記載の方法。

Images