(57)【要約】  モバイルノードのホームエージェント（４１０、７０８）を通じてＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２、７１２）を通じてＩＰｖ４／ＵＤＰ双方向トンネル（４０７、７０７）内でＩＰｖ６トラヒックを送受信することにより、ＩＰｖ６モバイルノード（４０２、７０２）がもう１つのＩＰｖ６ノード（４０４、７０４）と通信するためにＩＰｖ６モバイルノード（４０２、７０２）によって用いられるルート最適化の方法（３００、６００）であって、ＩＰｖ６モバイルノードともう１つのＩＰｖ６ノードとのうち少なくとも一方が、ＩＰｖ４アクセスネットワーク（４０６ａ、４０６ｂ、７１６ａ、７１８ｂ）に位置する方法が、本明細書において記述される。
2008543198.tif 000002
【特許請求の範囲】
【請求項１】
別のノード（４０４，７０４）と通信するモバイルノード（４０２，７０２）であって、
当該モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより前記別のノード（４０４，７０４）と通信し、
当該モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置する
ことを特徴とするモバイルノード。
【請求項２】
前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ，７１６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ，７１６ｂ）であることを特徴とする請求項１に記載のモバイルノード。
【請求項３】
当該モバイルノードと前記別のノードとが両方とも同一または異なるＩＰｖ４アクセスネットワーク内に位置しているか、あるいは、当該モバイルノードと前記別のノードとのうちの一方は、ＩＰｖ４通信接続性も有するＩＰｖ６アクセスネットワーク内に位置していることを特徴とする請求項１に記載のモバイルノード。
【請求項４】
前記別のノードがコレスポンデントノードである場合、当該モバイルノードは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を実行することを特徴とする請求項１に記載のモバイルノード。
【請求項５】
前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされているＨｏＴＩメッセージを送信するステップと、
前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされているＣｏＴＩメッセージを送信するステップと、
前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信されたＢＡメッセージを受信するステップと、
を更に備えることを特徴とする請求項４に記載のモバイルノード。
【請求項６】
前記別のノードが第２のモバイルノードである場合、当該モバイルノードは、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立するステップ（６０６）と、
当該第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）と、
を実行することを特徴とする請求項１に記載のモバイルノード。
【請求項７】
当該第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
当該第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされているＨｏＴＩメッセージを送信するステップと、
前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされているＣｏＴＩメッセージを送信するステップと、
当該第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信されたＢＡメッセージを受信するステップと、
を更に備えることを特徴とする請求項６に記載のモバイルノード。
【請求項８】
当該第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
のうちの少なくとも一方を満たすことを特徴とする請求項６に記載のモバイルノード。
【請求項９】
モバイルノード（４０２，７０２）と別のノード（４０４，７０４）との間でのルート最適化のための方法（３００，６００）であって、前記モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置しており、当該方法は、
前記モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより、前記モバイルノード（４０２，７０２）が前記別のノード（４０４，７０４）と通信することを可能にするステップを備え、
前記モバイルノードと前記別のノードとがそれぞれＩＰｖ４およびＩＰｖ６の能力を有する
ことを特徴とする方法。
【請求項１０】
前記モバイルノードは前記ＩＰｖ４アクセスネットワークにアタッチしており、
前記モバイルノードは、当該モバイルノードにＩＰｖ４気付アドレスを割り当てる前記ホームエージェント（４１０，７０８）に対して、ホーム登録手順を実行する
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記別のノードがコレスポンデントノードである場合、前記可能にするステップは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を更に含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定する前記ステップが、前記コレスポンデントノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップを更に含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされているＨｏＴＩメッセージを送信するステップと、
前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされているＣｏＴＩメッセージを送信するステップと、
前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信されたＢＡメッセージを受信するステップと、
を更に含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記モバイルノードは、前記ＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（４２２）の背後に位置することを特徴とする請求項１０に記載の方法。
【請求項１５】
前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ）であり、
前記別のノードは、ＩＰｖ６アクセスネットワークまたはＩＰｖ４／ＩＰｖ６アクセスネットワーク（４１４）内に位置する
ことを特徴とする請求項１０に記載の方法。
【請求項１６】
前記コレスポンデントノードは、モバイルノードであることを特徴とする請求項１１に記載の方法。
【請求項１７】
前記別のノードが第２のモバイルノードである場合、前記可能にするステップは、
前記第１のモバイルノードが、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルの一方向を確立するステップ（６０６）と、
を実行するステップと、
前記第２のＩＰｖ６モバイルノードが、
前記第１のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０８）と、
有する場合、前記第１のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６１０）と、
確立可能な場合、前記第１のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルのもう一方向を確立するステップ（６１２）と、
を実行するステップと、
前記第１のモバイルノードと前記第２のモバイルノードとが、
前記第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）を実行するステップと、
を更に含むことを特徴とする請求項１０に記載の方法。
【請求項１８】
前記第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
前記第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされているＨｏＴＩメッセージを送信するステップと、
前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされているＣｏＴＩメッセージを送信するステップと、
前記第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信されたＢＡメッセージを受信するステップと、
を更に含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
のうちの少なくとも一方を満たすことを特徴とする請求項１７に記載の方法。
【請求項２０】
モバイルノード（４０２，７０２）と、
別のノード（４０４，７０４）と、
を備え、
前記モバイルノードは、前記モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより前記別のノードと通信し、
前記モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置する
ことを特徴とする通信ネットワーク。
【請求項２１】
前記別のノードがコレスポンデントノードである場合、前記モバイルノードは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を実行することによって、前記別のノードと通信する
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２２】
前記モバイルノードが第１のモバイルノードであり、前記別のノードが第２のモバイルノードである場合、
前記第１のモバイルノードは、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルの一方向を確立するステップ（６０６）と、
を実行し、
前記第２のモバイルノードは、
前記第１のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０８）と、
有する場合、前記第１のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６１０）と、
確立可能な場合、前記第１のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルのもう一方向を確立するステップ（６１２）と、
を実行し、
前記第１のモバイルノードと前記第２のモバイルノードとは、
前記第１のモバイルノードと前記第２のモバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）を実行する
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２３】
前記モバイルノードは前記ＩＰｖ４アクセスネットワーク内に位置し、
前記モバイルノードは、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを取得するために、ホームアクセスネットワーク内のホームエージェントに対してホーム登録プロセスを完了させる
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２４】
前記モバイルノードは、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを配信するために、ＩＰｖ４気付アドレスのオプションを使用することを特徴とする請求項２０に記載のネットワーク。
【請求項２５】
前記モバイルノードは、ＲＨ２を使用し、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートをＩＰｖ６気付アドレス内に符号化することにより、前記グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを配信することを特徴とする請求項２０に記載のネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰｖ４限定のアクセスネットワークに移動でき、その後もなお、異なるアドレス空間に位置する別のＩＰｖ６ノードへのその到達可能性を維持できるようなＩＰｖ６モバイルノードに関するものである。
【背景技術】
【０００２】
下記の略語集が、本明細書と共に定義されており、少なくともその一部は、本発明の先行技術および好適実施形態についての以下の記述の中で言及される。
【０００３】
ＭＮ    Ｍｏｂｉｌｅ  Ｎｏｄｅ（モバイルノード）は、インターネット（ＩＰネットワーク）との接続点を変えながら、自分のホームアドレスを用いて他の移動ノードまたは静止ノードと通信できる移動端末である。
【０００４】
ＨＡ    Ｈｏｍｅ  Ａｇｅｎｔ（ホームエージェント）は、ＭＮのホームネットワーク内のルータである。
【０００５】
ＣＮ    Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ（コレスポンデントノード（通信相手ノード））は、ＩＰｖ６ノードである。ＭＮもＣＮであるが、ＣＮは、まったく移動しないノードである場合もあるだろう。
【０００６】
ＮＡＴ    Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（ネットワーク・アドレス・トランスレータ）である。
【０００７】
ＣｏＡ    Ｃａｒｅ−ｏｆ  Ａｄｄｒｅｓｓ（気付アドレス）は、在圏中のネットワーク内でＭＮによって用いられるＩＰｖ６アドレスまたはＩＰｖ４アドレスである。ＭＮがインターネットへの接続を変えると、このアドレスは変わる。ＭＮがＩＰｖ４アクセスネットワークにアタッチする場合、ＭＮはＩＰｖ４のＣｏＡに加えてＵＤＰのポート番号も必要とする。これは、ＩＰｖ４トンネリングが、１つ以上のＮＡＴを経由する可能性があるからであり、それらのＮＡＴは、アドレスの変換を行うのにＵＤＰポートを必要とするからである。
【０００８】
ＨｏＡ    ＭＮのＨｏｍｅ  Ａｄｄｒｅｓｓ（ホームアドレス）は、ＭＮに対して常に到達可能なＩＰｖ６アドレスまたはＩＰｖ４アドレスである。ＭＮがホームリンク内にいない場合、ＨＡはパケットをＭＮへトンネルさせ、パケットはＭＮのＨｏＡに到着する。
【０００９】
ＨＬ    Ｈｏｍｅ  ｌｉｎｋ（ホームリンク）である。
【００１０】
ＨｏＴＩ    Ｈｏｍｅ  Ｔｅｓｔ  Ｉｎｉｔ．（ホーム・テストＩｎｉｔ）である。
【００１１】
ＨｏＴ    Ｈｏｍｅ  Ｔｅｓｔ（ホーム・テスト）である。
【００１２】
ＣｏＴＩ    Ｃａｒｅ−ｏｆ  Ｔｅｓｔ  Ｉｎｉｔ．（気付テストＩｎｉｔ）である。
【００１３】
ＣｏＴ    Ｃａｒｅ−ｏｆ  Ｔｅｓｔ（気付テスト）である。
【００１４】
ＢＵ  Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ（バインド更新）である。
【００１５】
ＢＡ  Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（バインド確認応答）である。
【００１６】
無線通信分野では、モバイルＩＰｖ６として知られるプロトコルが現在用いられているが、このプロトコルによって、ＩＰｖ６のＭＮがインターネットのようなＩＰネットワークに接続されたＩＰｖ６アクセスネットワーク内で移動している間も、そのＭＮに到達可能な状態を維持できる。このモビリティのサポートがなければ、ＩＰｖ６のＭＮを宛先とするパケットは、ＭＮが自分のホームリンクから離れた位置にある間は、そのＭＮに到達することができないであろう。モバイルＩＰｖ６プロトコルについては、下記の文書の中に詳細に記述されている。
・Ｓ．Ｄｅｅｒｉｎｇ他、「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様」ＲＦＣ２４６０、１９９８年１２月
・Ｄ．Ｊｏｈｎｓｏｎ他、「ＩＰｖ６におけるモビリティのサポート」ＲＦＣ３７７５、２００４年６月
これらの文書の内容は、参照により本願に援用する。
【００１７】
現在、ＩＰｖ６アクセスネットワークに加えて、インターネットに接続されているＩＰｖ４アクセスネットワークも使用されている。ＩＰｖ４アクセスネットワークは、モバイルＩＰｖ４として知られる別のプロトコルに合致するように設計され、構築されている。モバイルＩＰｖ４プロトコルによって、ＩＰｖ４のＭＮが自分のＨＬではないＩＰｖ４アクセスネットワーク内に位置している間も、それに到達することが可能になる。モバイルＩＰｖ４プロトコルについては、下記の文書の中に詳細に記述されている。
・Ｃ．Ｐｅｒｋｉｎｓ、「ＩＰモビリティサポート」、ＲＦＣ２００２、１９９６年１０月
この文書の内容は、参照により本願に援用する。
【００１８】
残念ながら、モバイルＩＰｖ４プロトコルおよびモバイルＩＰｖ６プロトコルは、それぞれ、ＩＰｖ４限定のアクセスネットワーク用およびＩＰｖ６限定のアクセスネットワーク用として設計されている。従って、モバイルＩＰｖ６プロトコルは、ＩＰｖ４ネットワークへの後方互換性を提供しない。これは、モバイルＩＰｖ６は、（パブリックネットワークであれプライベートネットワークであれ）複数のＩＰｖ４アクセスネットワークを跨いだモビリティ管理を行うことができないということを意味する。しかし、ＩＰｖ４（パブリックおよびプライベート）アクセスネットワーク内に位置するＩＰｖ６ＭＮのモビリティ管理は、特に重要である。なぜなら、ＩＰｖ６ＭＮ（例えばＩＰｖ６モバイルコンピュータ）は、インターネットに接続されようとする装置人口の大半もしくは少なくとも相当な割合を占めると思われるからである。そして、インターネットへのアクセスネットワークの一部は、ＩＰｖ４限定のアクセスネットワークであろう。このモビリティ管理の問題に対する解決策の提案を、図１および２に関して下記に詳述する。
【００１９】
図１Ａおよび１Ｂ（先行技術）を参照すると、ＩＰｖ６ＭＮ１１０がＩＰｖ４限定アクセスネットワーク１１６へ移動してもなお、ＩＰｖ６のＣＮ１０２へのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題の解決策を説明する一助とするのに用いられる、図およびシグナリングフロー図が示されている。図１Ａに示すように、ＩＰｖ６のＣＮ１０２は、ＩＰｖ４ルータ１０６とＩＰｖ６ルータ１０８とを有するＩＰｖ４／ＩＰｖ６混合アクセスネットワーク１０４に位置する。そして、ＭＮ１１０は、ＨＡ１１４を有するＨＬ１１２から、ＩＰｖ４ルータ１１８を有するＩＰｖ４アクセスネットワーク１１６へ、移動してきた。ＭＮ１１０は、次に論じるように、インターネット１２０を経由してＣＮ１０２と通信できる。
【００２０】
図１Ａおよび１Ｂに示すように、ＭＮ１１０は、ＨＬ１１２からＩＰｖ４アクセスネットワーク１１６へ移動した後、ＨＡ１１４にホーム登録を行う（信号１および２を参照のこと）。ホーム登録を行うため、ＭＮ１１０は、ＢＵをＨＡ１１４へ送信する（信号１）。ＭＮ１１０はＩＰｖ４アクセスネットワーク１１６の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ１１０はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ１１４は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ１１０に送信する（信号２）。ホーム登録の後、ＣＮ１０２は、ＨＬ１１２を経由してトラヒック（トンネルされたデータ）をＭＮ１１０へ送信する（信号３を参照のこと）。また、ＭＮ１１０は、ＨＬ１１２を経由してトラヒック（トンネルされたデータ）をＣＮ１０２へも送信する（信号４を参照のこと）。加えて、ＭＮ１１０は、ルーティングテーブルを有する。典型的なルーティングテーブルを以下に示す。
【００２１】
ＭＮのルーティングテーブル１２２
-------------------------------------------------------------------------------
|宛先：           |次のホップ：               |Ｉｎｔｆ：                     |
-------------------------------------------------------------------------------
|"ＨＡ  ＩＰｖ６" |"ＨＡ  ＩＰｖ４"           |ＵＤＰ  ｔｕｎｎｅｌｉｎｔｆ０ |
-------------------------------------------------------------------------------
|"ＨＡ  ＩＰｖ４" |"デフォルトＩＰｖ４ルータ" |Ｉｎｔｆ０                     |
-------------------------------------------------------------------------------
【００２２】
この解決策の欠点は、ＭＮ１１０についての着信トラヒックおよび発信トラヒックが、ＨＬ１１２の中に存在するＨＡ１１４を経由して常にトンネルされることである。たとえＣＮ１０２とＭＮ１１０とが同じアクセスネットワーク内に位置していたとしても、同じトラヒックルートは、やはり必要であろう。なぜなら、ＭＮ１１０が別のアクセスネットワーク（不図示）へ移動する場合、ＣＮ１０２とＭＮ１１０とは接続性を失う可能性があるため、ＣＮ１０２とＭＮ１１０とは、トラヒックが最短パス（ＭＮ１１０、ＩＰｖ４ルータ１１８、インターネット１２０、ＩＰｖ４ルータ１０６、ＣＮ１０２）を経由してルーティングされるようなルート最適化手順を行うことができないからである。ＭＮ１１０とＣＮ１０２とが、ルート最適化手順を行うことができるならば、望ましいであろう。本発明はこの必要性に取り組むものである。
【００２３】
図２Ａおよび２Ｂ（先行技術）を参照すると、ＩＰｖ６ＭＮ２０２および２１２が両方ともＩＰｖ４限定アクセスネットワーク２０４および２１４へ移動しても、ＩＰｖ６ＭＮ２０２がもう１つのＩＰｖ６ＭＮ２１２への到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題の解決策を説明する一助とするのに用いられる図およびシグナリングフロー図が示されている。図２Ａに示すように、第１のＩＰｖ６ＭＮ２０２は、ＩＰｖ４ルータ２０６を有するＩＰｖ４アクセスネットワーク２０４の中に位置している。第１のＭＮ２０２は、ＨＡ２１０を有するＨＬ２０８からＩＰｖ４アクセスネットワーク２０４へ移動した。第２のＩＰｖ６ＭＮ２１２は、ＩＰｖ４ルータ２１６を有するＩＰｖ４アクセスネットワーク２１４の中に位置している。第２のＭＮ２１２は、ＨＡ２２０を有するＨＬ２１８からＩＰｖ４アクセスネットワーク２１４へ移動した。そして、以下に述べるように、第１のＭＮ２０２は、インターネット２２２およびＨＡ２１０および２２０を経由して、第２のＭＮ２１２と通信することができる。
【００２４】
図２Ａおよび２Ｂに示すように、第１のＭＮ２０２は、ＨＬ２０８からＩＰｖ４アクセスネットワーク２０４へ移動した後、ＨＡ２１０にホーム登録を行う（信号１ａおよび１ｂを参照のこと）。ホーム登録を行うため、第１のＭＮ２０２は、ＢＵをＨＡ２１０へ送信する（信号１ａ）。第１のＭＮ２０２はＩＰｖ４アクセスネットワーク２０４の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ２０２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ２１０は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ２０２へ送信する（信号２ａ）。同様に、第２のＭＮ２１２は、ＢＵをＨＡ２２０へ送信する（信号１ｂ）。ＭＮ２１２はＩＰｖ４アクセスネットワーク２１４の中に位置することから、そのグローバルなＩＰｖ４アドレスとＵＤＰポートとを知るため、ＭＮ２１２はＢＵにＩＰｖ４気付アドレスのオプションを追加する。次いで、ＨＡ２２０は、ＭＮのグローバルなＩＰｖ４アドレスとＵＤＰポートとを保持するＩＰｖ４気付アドレスのオプションを搬送するＢＡを、ＭＮ２１２に送信する（信号２ｂ）。ホーム登録の後、第２のＭＮ２１２は、２つのＨＬ２１８および２０８を経由してトラヒック（トンネルされたデータ）を第１のＭＮ２０２へ送信する（信号３を参照のこと）。また、第１のＭＮ２０２は、２つのＨＬ２０８および２１８を経由してトラヒック（トンネルされたデータ）を第２のＭＮ２１２へも送信する（信号４を参照のこと）。加えて、ＭＮ２０２および２１２はそれぞれ、ルーティングテーブル２２４および２２６を有する。典型的なルーティングテーブル２２４および２２６を以下に示す。
【００２５】
ＭＮ１のルーティングテーブル２２４
-------------------------------------------------------------------------------
|宛先：             |次のホップ：                 |Ｉｎｔｆ：                 |
-------------------------------------------------------------------------------
|"ＨＡ１  ＩＰｖ６" |"ＨＡ１  ＩＰｖ４"           |ＵＤＰ  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"    |
-------------------------------------------------------------------------------
【００８５】
ＭＮ２のバインドキャッシュ７３６
-------------------------------------------------------------------------------
|"ＭＮ１  ＩＰｖ６  ＨｏＡ" ＜−＞ "ＭＮ１  ＩＰｖ６  ＣｏＡ"                 |
-------------------------------------------------------------------------------
|"ＭＮ  ＩＰｖ４" ＨｏＡ" ＜−＞ "ＭＮ  ＩＰｖ４  ＣｏＡ"                     |
-------------------------------------------------------------------------------
【００８６】
図８を参照すると、ＭＮ７０２とＭＮ７０４との両方がＩＰｖ４プライベートアクセスネットワーク７１６ｂおよび７１４ｂへ移動した場合でもなお、ルート最適化方法６００がどのようにして、ＩＰｖ６ＭＮ７０２がもう１つのＩＰｖ６ＭＮ７０４へのその到達可能性を維持できるようにするかを説明する一助とするのに用いられる図が示されている。図８に示すように、第１のＩＰｖ６ＭＮ７０２は、ＮＡＴ７２６を有するＩＰｖ４プライベートアクセスネットワーク７１６ｂに位置する。第１のＭＮ７０２は、ＨＡ７０８を有するＨＬ７２０から、ＩＰｖ４プライベートアクセスネットワーク７１６ｂへ、移動してきた。第２のＩＰｖ６ＭＮ７０４は、ＮＡＴ７２８を有するＩＰｖ４プライベートアクセスネットワーク７１４ｂに位置する。第２のＭＮ７０４は、ＨＡ７０６を有するＨＬ７２４から、ＩＰｖ４プライベートアクセスネットワーク７１４ｂへ、移動してきた。
【００８７】
ＭＮ７０２は、この場合、ＮＡＴ７２６と７２８とが存在するためにホーム登録手順が異なるということを除いて、図７Ａおよび７Ｂに関して上記で論じたものと同様に、ＩＰｖ４／ＵＤＰ双方向トンネル７０７を経由して第２のＭＮ７０４と通信できる。ホーム登録プロセスの違いを、次に説明する。ＭＮ７０２は、自分が(例えば）ＩＰｖ４プライベートアクセスネットワーク７１６ｂに接続していることを発見すると、自分のＨＡ７０８へＢＵメッセージを送信する。ＭＮ７０２は、ＢＵメッセージに「ＩＰｖ４気付アドレスのオプション」を追加する。特に、ＭＮ７０２は、自分のＩＰｖ４アドレスを気付アドレスとして、そして、ソースＵＤＰポートをＵＤＰポートとして、使用する。ＩＰｖ４プライベートアクセスネットワーク７１６ｂはＮＡＴ７２６の背後にあるため、オプションはＩＰｖ６ヘッダの内側にあり、かつ、これらのヘッダはＩＰＳｅｃで暗号化されていることから、オプションは変換されないであろう。従って、ＨＡ７０８は、ＢＵを受信すると、トンネルされたパケットの外側ヘッダのソースアドレスおよびＵＤＰポートを、「ＩＰｖ４気付アドレスのオプション」のＩＰｖ４アドレスおよびＵＤＰポートと比較する。それらが異なる場合には、ＨＡ７０８は、ＮＡＴ７２６のＩＰｖ４ソースアドレスとＵＤＰポートとを、受信したＩＰｖ４ヘッダからのオプションにコピーする。このオプションは、ＭＮ７０２に返信されるＢＡに追加される。このようにして、ＭＮ７０２は、ＢＡを受信すると、自分がＮＡＴの背後に位置しているのかどうかを知るであろう。加えて、ＭＮ７０２は、ＩＰｖ６トラヒックをＩＰｖ４／ＵＤＰトンネル内でトンネルさせるのに必要な、グローバルにルーティング可能なＩＰｖ４アドレスとＵＤＰポートとを知っている。この例では、ＭＮ７０４は、ＮＡＴ７２８の背後に位置しているため、同じホーム登録手順に従う。加えて、ＭＮ７０２は、ルーティングテーブル７２６とバインド更新リスト７２８とバインドキャッシュ７３０とを含む。そして、ＭＮ７０４は、ルーティングテーブル７３２とバインド更新リスト７３４とバインドキャッシュ７３６とを含む。典型的なルーティングテーブル７２６および７３２とバインド更新リスト７２８および７３４とバインドキャッシュ７３０および７３６については、上述した。
【００８８】
ここで理解されるべきだが、本発明は、図３乃至８に関して上記で論じた前述のシナリオに加えて、別のシナリオにおいて使用されてもよい。下記の「テーブル」は、本発明が利用されてもよい別のシナリオをいくつか示す。
【００８９】
-------------------------------------------------------------------------------
|モバイルノード  |別のノード（ＣＮ|同じホーム|同じネット|コメント             |
|                |またはＭＮ）    |ネット    |ワーク内の|                     |
|                |                |ワーク    |ノード    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|いいえ    |いいえ    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム          |いいえ    |いいえ    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム          |いいえ    |いいえ    |トンネル不使用（１） |
-------------------------------------------------------------------------------
|ホーム          |リモートＩＰｖ６|いいえ    |いいえ    |トンネル不使用（２） |
-------------------------------------------------------------------------------
|ホーム          |リモートＩＰｖ４|いいえ    |いいえ    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|はい      |いいえ    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム          |はい      |いいえ    |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム          |はい      |いいえ    |トンネル不使用（１） |
-------------------------------------------------------------------------------
|ホーム          |リモートＩＰｖ４|はい      |いいえ    |                     |
-------------------------------------------------------------------------------
|ホーム          |リモートＩＰｖ６|はい      |いいえ    |トンネル不使用（２） |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|いいえ    |はい      |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|ホーム          |いいえ    |はい      |                     |
-------------------------------------------------------------------------------
|リモートＩＰｖ６|ホーム          |いいえ    |はい      |トンネル不使用（１） |
-------------------------------------------------------------------------------
|リモートＩＰｖ４|リモートＩＰｖ４|はい      |はい      |                     |
-------------------------------------------------------------------------------
【００９０】
（１）このシナリオでは、ＩＰｖ４／ＵＤＰトンネルがＭＮともう１つのノードとの間で設定されることはないであろうが、ＨｏＴＩ／ＨｏＴメッセージおよびＣｏＴＩ／ＣｏＴメッセージの中のフラグは使用されなければならない。
【００９１】
（２）上記のコメント１を参照のこと。また、もう１つのノードがＣＮに限定される場合には別のネットワークに移動できないので、このシナリオは、もう１つのノードがＭＮである場合に限って、論理にかなう。
【００９２】
以下に、ルート最適化方法６００に関連する追加の特徴の一部を示す。
【００９３】
・本発明の解決策をサポートしない第３のＭＮ（不図示）が、「ＩＰｖ４気付アドレスのオプション」をパケットのＩＰｖ６ヘッダに追加した（例えば）ＭＮ７０２からトンネルされたトラヒックを受信した場合、第３のＭＮはこのＭＮ７０２とルート最適化手順を行うことはできないであろう。なぜなら、ＭＮ７０２がＩＰｖ４アクセスネットワーク内にいる間は、ＭＮ７０２のＩＰｖ６  ＣｏＡはグローバルにルーティング可能なＩＰｖ６アドレスではなく、第３のＭＮが送信するＨｏＴＩメッセージおよびＣｏＴＩメッセージは、ＭＮ７０２によって受信されることができないからである。
【００９４】
・本発明の解決策をサポートしない第３のＭＮ（不図示）が、（例えば）ＭＮ７０２からトンネルされたトラヒックを受信し、これらのＭＮが両方ともＩＰｖ６アクセスネットワーク（不図示）にアタッチしている場合には、２つのＭＮは、ルート最適化を完了しないであろう。なぜなら、第３のＭＮは、ＨｏＴＩ／ＨｏＴメッセージおよびＣｏＴＩ／ＣｏＴメッセージの予約フィールド内にフラグをセットしていないであろうからである。更に、ＭＮ７０２は、自分がある時点でＩＰｖ４アクセスネットワークへ移動しないとは保証できず、かつ、これが発生した場合には、ＭＮ７０２は、第３のＭＮが（存続時間がゼロに設定された）トンネルされたＢＵをサポートするとは確信できないため、トラヒックは、２つのノード間でルート最適化されないであろう。
【００９５】
・（例えば）ＭＮ７０２がＩＰｖ４アクセスネットワーク７１６にアタッチされている間、ＭＮ７０２は、「ＩＰｖ４気付アドレスのオプション」を自分のＩＰｖ６パケットに追加する。ＭＮ７０２が、トンネルされたトラヒックを、本発明を実装しない第３のＭＮから継続的に受信する場合には、ＭＮ７０２は、第３のＭＮがルート最適化をサポートしないという事実に注目して、パケットのオーバヘッドを削減するため、これらのオプションをパケットに追加するのを中止してもよい。
【００９６】
・「ＩＰｖ４気付アドレスのオプション」は、ＴＬＶ符号化されてもよいだろうが、それはＩＰｖ４気付アドレスとＵＤＰポートとを保持しなければならない。また、この情報は、ＩＰｖ４アクセスネットワークにアタッチされる場合、ＭＮ７０２および７０４のＩＰｖ６  ＣｏＡへと符号化されてもよいだろうが、受信器にＣｏＡがグローバルにルーティング可能なＩＰｖ６アドレスではないことを知らせるため、何らかのフラグが必要である。これは、例えば、前述のＲＦＣ３７７５の中に規定されているＲＨ２を用いて行われてもよいだろう。トラヒックに若干オーバヘッドを追加するとはいえ、本発明の方がシンプルな解決策である。
【００９７】
・（例えば）ＭＮ７０２があるＩＰｖ４アクセスネットワークから、別のＩＰｖ４アクセスネットワークへ移動する場合には、ＭＮ７０２は自分の新たなＩＰｖ４気付アドレスをＨＡ７０８に登録しなければならない。これは、ＩＰｖ４／ＵＤＰトンネルの中でＢＵをトンネルさせることによって行われる。この後で、ＭＮ７０２は、そのバインド更新リスト（ＢＵＬ）の中のすべてのバインドを、新たなＩＰｖ４気付アドレスで更新することができる。次いでＭＮ７０２は、自分の気付アドレスが変わったことを知らせるため、自分がバインドしている各ＭＮ／ＣＮへＢＵを送信する。この後、すべてのトラヒックは、その新たな位置へ送信可能である。
【００９８】
・ＭＮのうちの１つ（例えば、ＭＮ７０２）が、ＩＰｖ６ネットワークへ移動する一方で、他のＭＮ（例えばＭＮ７０４）がＩＰｖ４ネットワークに留まる場合には、確立した双方向トンネルは、ＭＮ７０２および７０４のルーティングテーブルから削除されなければならない。ＩＰｖ４アクセスネットワークからＩＰｖ６アクセスネットワークへの移動を行ったＭＮ７０２は、存続時間＝０のＢＵメッセージを自分のＨＡ７０８を通じてトンネルすることによって、これを開始することができる。受信側のＭＮ７０４が、このトンネルされたＢＵを自分のＨＡ７０６から受信すると、ＭＮ７０４は、自分のバインド更新リスト（ＢＵＬ）とＢＣを、トンネルされたパケットのホームアドレスで確認し、対応するＢＵＬエントリを削除する。この後、２つのＭＮ７０２と７０４との間のトラヒックは、それらのＨＡ７０６および７０８を経由してトンネルされる必要がある。また、２つのＭＮ７０２および７０４が両方ともＩＰｖ６アクセスネットワーク内にいる間にそれらの間のルーティングを最適化し、それらのうちの１つがＩＰｖ４アクセスネットワークへ移動する場合も、同様の手順が行われる。存続時間＝０のＢＵが、ＨＡを経由して他方のＭＮへトンネルされるであろう。
【００９９】
・また、本発明は、ＭＮのうちいずれか１つが、イントラネット、エクストラネットに接続されている場合に使用されてもよいし、更には、ＭＮのうちいずれか１つが、イントラネット／エクストラネットに接続され、それが次いでインターネットに接続されている場合に使用されてもよい。
【０１００】
本発明の２つの実施形態を、添付の図面で図解し、前述の詳細な説明の中で記述してきたが、理解されるべきことは、本発明は、開示された実施形態に限定されるのではなく、上述した、また、下記の請求の範囲によって定義された本発明の精神から逸脱することなく、数多くの再構成、修正、および置換が可能であるということである。
【図面の簡単な説明】
【０１０１】
【図１Ａ】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。
【図１Ｂ】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。
【図２Ａ】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動しても、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。
【図２Ｂ】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動しても、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を用いない既知の解決策を説明する一助とするのに用いられる図である。
【図３】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。
【図４Ａ】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。
【図４Ｂ】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。
【図５】ＩＰｖ６ＭＮがＩＰｖ４限定アクセスネットワークへ移動してもなお、ＩＰｖ６ＣＮへのその到達可能性を維持できる場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明の一実施形態による解決策を記述する一助とするのに用いられる図である。
【図６】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。
【図７Ａ】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。
【図７Ｂ】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。
【図８】ＩＰｖ６ＭＮが両方ともＩＰｖ４限定アクセスネットワークへ移動してもなお、一方のＩＰｖ６ＭＮが他方のＩＰｖ６ＭＮへの到達可能性を維持する場合のシナリオにおいて、モビリティ管理の問題に取り組むためのルート最適化手順を正に用いる、本発明のもう１つの実施形態による解決策を記述する一助とするのに用いられる図である。
【図１Ａ】
2008543198.tif 000003
【図１Ｂ】
2008543198.tif 000004
【図２Ａ】
2008543198.tif 000005
【図２Ｂ】
2008543198.tif 000006
【図３】
2008543198.tif 000007
【図４Ａ】
2008543198.tif 000008
【図４Ｂ】
2008543198.tif 000009
【図５】
2008543198.tif 000010
【図６】
2008543198.tif 000011
【図７Ａ】
2008543198.tif 000012
【図７Ｂ】
2008543198.tif 000013
【図８】
2008543198.tif 000014
【手続補正書】
【提出日】平成19年4月3日(2007.4.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
別のノード（４０４，７０４）と通信するモバイルノード（４０２，７０２）であって、
当該モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより前記別のノード（４０４，７０４）と通信し、
当該モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置し、
前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能か否かを当該モバイルノードが判定できるように、当該モバイルノードは、ＨｏＴＩメッセージとＣｏＴＩメッセージとを前記別のノードへ送信し、
前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能な場合、当該モバイルノードは、前記別のノードに対して前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックを送受信する前に、前記別のノードへＢＵメッセージを送信し、前記別のノードからＢＡメッセージを受信する
ことを特徴とするモバイルノード。
【請求項２】
前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ，７１６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ，７１６ｂ）であることを特徴とする請求項１に記載のモバイルノード。
【請求項３】
当該モバイルノードと前記別のノードとが両方とも同一または異なるＩＰｖ４アクセスネットワーク内に位置しているか、あるいは、当該モバイルノードと前記別のノードとのうちの一方は、ＩＰｖ４通信接続性も有するＩＰｖ６アクセスネットワーク内に位置していることを特徴とする請求項１に記載のモバイルノード。
【請求項４】
前記別のノードがコレスポンデントノードである場合、当該モバイルノードは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を実行することを特徴とする請求項１に記載のモバイルノード。
【請求項５】
前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
前記ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
を更に備えることを特徴とする請求項４に記載のモバイルノード。
【請求項６】
前記別のノードが第２のモバイルノードである場合、当該モバイルノードは、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立するステップ（６０６）と、
当該第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）と、
を実行することを特徴とする請求項１に記載のモバイルノード。
【請求項７】
当該第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
当該第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
当該第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
を更に備えることを特徴とする請求項６に記載のモバイルノード。
【請求項８】
当該第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
のうちの少なくとも一方を満たすことを特徴とする請求項６に記載のモバイルノード。
【請求項９】
モバイルノード（４０２，７０２）と別のノード（４０４，７０４）との間でのルート最適化のための方法（３００，６００）であって、前記モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置しており、当該方法は、
前記モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより、前記モバイルノード（４０２，７０２）が前記別のノード（４０４，７０４）と通信することを可能にするステップを備え、
前記モバイルノードと前記別のノードとがそれぞれＩＰｖ４およびＩＰｖ６の能力を有し、
前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能か否かを前記モバイルノードが判定できるように、前記モバイルノードは、ＨｏＴＩメッセージとＣｏＴＩメッセージとを前記別のノードへ送信し、
前記別のノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネルすることが可能な場合、前記モバイルノードは、前記別のノードに対して前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックを送受信する前に、前記別のノードへＢＵメッセージを送信し、前記別のノードからＢＡメッセージを受信する
ことを特徴とする方法。
【請求項１０】
前記モバイルノードは前記ＩＰｖ４アクセスネットワークにアタッチしており、
前記モバイルノードは、前記ホームエージェント（４１０，７０８）に対して、ホーム登録手順を実行する
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記別のノードがコレスポンデントノードである場合、前記可能にするステップは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を更に含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定する前記ステップが、前記コレスポンデントノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップを更に含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定する前記ステップと、前記確立するステップとが、
前記ホームエージェント（４１０）を介して、前記コレスポンデントノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
前記コレスポンデントノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰトンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
前記ホームエージェントを介して前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記コレスポンデントノードから、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰトンネルの中で前記コレスポンデントノードへ送信するステップと、
前記コレスポンデントノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
を更に含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記モバイルノードが、前記ＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（４２２）の背後に位置することを特徴とする請求項１０に記載の方法。
【請求項１５】
前記ＩＰｖ４アクセスネットワークは、ＩＰｖ４パブリックアクセスネットワーク（４０６ａ）またはＩＰｖ４プライベートアクセスネットワーク（４０６ｂ）であり、
前記別のノードは、ＩＰｖ６アクセスネットワークまたはＩＰｖ４／ＩＰｖ６アクセスネットワーク（４１４）内に位置する
ことを特徴とする請求項１０に記載の方法。
【請求項１６】
前記コレスポンデントノードは、モバイルノードであることを特徴とする請求項１１に記載の方法。
【請求項１７】
前記別のノードが第２のモバイルノードである場合、前記可能にするステップは、
前記第１のモバイルノードが、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルの一方向を確立するステップ（６０６）と、
を実行するステップと、
前記第２のＩＰｖ６モバイルノードが、
前記第１のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０８）と、
有する場合、前記第１のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６１０）と、
確立可能な場合、前記第１のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルのもう一方向を確立するステップ（６１２）と、
を実行するステップと、
前記第１のモバイルノードと前記第２のモバイルノードとが、
前記第１のＩＰｖ６モバイルノードと前記第２のＩＰｖ６モバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）を実行するステップと、
を更に含むことを特徴とする請求項１０に記載の方法。
【請求項１８】
前記第１のモバイルノードによって実行される前記２つの判定するステップと前記確立するステップとが、
前記第２のモバイルノードがＩＰｖ４気付アドレスおよびＵＤＰポートを有するか否かをチェックするステップと、
前記第１のモバイルノードのホームエージェントと前記第２のモバイルノードのホームエージェント（７０６，７０８）とを介して、前記第２のモバイルノードのＩＰｖ６／ＩＰｖ４アドレスへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＨｏＴＩメッセージを送信するステップと、
前記第２のモバイルノードのＩＰｖ４アドレスおよびＵＤＰポートへ、前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立する要求を示すフラグがセットされている前記ＣｏＴＩメッセージを送信するステップと、
前記第１のモバイルノードの前記ホームエージェントと前記第２のモバイルノードの前記ホームエージェントとを介して前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＨｏＴメッセージを受信するステップと、
前記第２のモバイルノードから、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをトンネル可能であるということを示すフラグがセットされたＣｏＴメッセージを受信するステップと、
前記ＢＵメッセージを前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記第２のモバイルノードへ送信するステップと、
前記第２のモバイルノードから、前記ＩＰｖ４／ＵＤＰトンネルの中で送信された前記ＢＡメッセージを受信するステップと、
を更に含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記第１のモバイルノードが、前記第１のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２６）の背後に位置すること、および、
前記第２のモバイルノードが、前記第２のＩＰｖ４アクセスネットワークに関連付けられたネットワーク・アドレス・トランスレータ（ＮＡＴ）（７２８）の背後に位置すること、
のうちの少なくとも一方を満たすことを特徴とする請求項１７に記載の方法。
【請求項２０】
モバイルノード（４０２，７０２）と、
別のノード（４０４，７０４）と、
を備え、
前記モバイルノードは、前記モバイルノードのホームエージェント（４１０，７０８）を介してＩＰｖ６トラヒックをルーティングすることなしに、ＩＰネットワーク（４１２，７１２）を介してＩＰｖ４／ＵＤＰ双方向トンネル（４０７，７０７）の中で前記ＩＰｖ６トラヒックを送受信することにより前記別のノードと通信し、
前記モバイルノードと前記別のノードのうちの少なくとも一方はＩＰｖ４アクセスネットワーク（４０６ａ，４０６ｂ，７１６ａ，７１８ｂ）内に位置し、
前記ＩＰｖ４アクセスネットワークは、トンネルサーバとインタフェースしたりトンネルサーバを使用したりすることはなく、また、前記モバイルノードと前記別のノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックを送受信するために使用されるＩＰｖ４ルータ（４２０，７１８）またはＮＡＴ（４２２，７２６）以外には、専用のルーティングサーバを持たない
ことを特徴とする通信ネットワーク。
【請求項２１】
前記別のノードがコレスポンデントノードである場合、前記モバイルノードは、
前記コレスポンデントノードがＩＰｖ４の能力を有するか否かを判定するステップ（３０２）と、
有する場合、前記コレスポンデントノードが前記ＩＰｖ４／ＵＤＰトンネルを確立可能か否かを判定するステップ（３０４）と、
確立可能な場合、前記コレスポンデントノードとの前記ＩＰｖ４／ＵＤＰトンネルを確立するステップ（３０６）と、
前記ＩＰｖ４／ＵＤＰトンネルの中で前記ＩＰｖ６トラヒックを前記コレスポンデントノードへルーティングするステップ（３０８）と、
を実行することによって、前記別のノードと通信する
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２２】
前記モバイルノードが第１のモバイルノードであり、前記別のノードが第２のモバイルノードである場合、
前記第１のモバイルノードは、
前記第２のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０２）と、
有する場合、前記第２のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６０４）と、
確立可能な場合、前記第２のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルの一方向を確立するステップ（６０６）と、
を実行し、
前記第２のモバイルノードは、
前記第１のモバイルノードがＩＰｖ４の能力を有するか否かを判定するステップ（６０８）と、
有する場合、前記第１のモバイルノードが前記ＩＰｖ４／ＵＤＰ双方向トンネルを確立可能か否かを判定するステップ（６１０）と、
確立可能な場合、前記第１のモバイルノードとの前記ＩＰｖ４／ＵＤＰ双方向トンネルのもう一方向を確立するステップ（６１２）と、
を実行し、
前記第１のモバイルノードと前記第２のモバイルノードとは、
前記第１のモバイルノードと前記第２のモバイルノードとの間で前記ＩＰｖ４／ＵＤＰ双方向トンネルの中で前記ＩＰｖ６トラヒックをルーティングするステップ（６１４）を実行する
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２３】
前記モバイルノードは前記ＩＰｖ４アクセスネットワーク内に位置し、
前記モバイルノードは、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを取得するために、ホームアクセスネットワーク内のホームエージェントに対してホーム登録プロセスを完了させる
ことを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２４】
前記モバイルノードは、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを配信するために、ＩＰｖ４気付アドレスのオプションを使用することを特徴とする請求項２０に記載の通信ネットワーク。
【請求項２５】
前記モバイルノードは、ＲＨ２を使用し、グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートをＩＰｖ６気付アドレス内に符号化することにより、前記グローバルにルーティング可能なＩＰｖ４アドレスおよびＵＤＰポートを配信することを特徴とする請求項２０に記載の通信ネットワーク。
【国際調査報告】
2008543198.tif 000015
2008543198.tif 000016
2008543198.tif 000017