JP5087012B2 - ロケーションプライバシをサポートする経路最適化 - Google Patents

Description

本出願は、モバイル通信システムに関する。より詳細には、本発明は、モバイルインターネットプロトコル（モバイルＩＰ）又は他のプロトコルに基づくモバイル通信のためのロケーションプライバシ及び経路最適化に関する。

本発明は、モバイルインターネットプロトコルバージョン６（モバイルＩＰｖ６）の例として記述される。しかし、本発明は、モバイルＩＰの記述されたエンティティに対応する同等のエンティティを定義する他のプロトコルにも適用することができる。

モバイルＩＰｖ６は、現在、２つの動作モードを定義する。すなわち、双方向トンネリング及び経路最適化である。前者のモードでは、すべてのデータパケットを送信元モバイルノードのホームエージェントを経由してルーティングされる必要があるが、後者は、モバイルノードと通信相手との間の直接のパスを使用する。

経路最適化モードの方が効率的で、パケット遅延を低減することができる。これは、モバイルＩＰｖ６のスケーラビリティ及び対話型通信のサポートにとってとても重要である。が、通信相手に関するロケーションプライバシを提供しない。通信相手は、モバイルノードが現在どこに位置するかを把握する。これとは対照的に、双方向トンネリングではロケーションプライバシが提供されるが、効率が悪く、遅延の影響を受けやすいアプリケーションでは許容できない程度までパケットを遅延させることがある。

通信システムは、インターネットプロトコル（ＩＰ）ベースのネットワークに向けてますます発展している。通信システムは、多数の相互接続されたネットワークからなり、音声及びデータはいわゆるパケットと呼ばれる断片で端末間を伝送される。これらのパケットは、ルータによってコネクションレス方式で宛て先にルーティングされる。したがって、パケットは、ＩＰヘッダとペイロード情報とからなり、ヘッダはとりわけソース（送信元）及び宛て先ＩＰアドレスを有する。スケーラビリティの理由から、ＩＰネットワークは、階層型アドレッシング方式を使用する。それゆえ、ＩＰアドレスは、相手方端末を識別するだけでなく、この端末に関するロケーション情報を更に含む。ルーティングプロトコルによって追加情報が提供されるので、ネットワーク内のルータは、特定の宛て先へ向けて次のルータを識別することができる。

端末（以下、モバイルノード（ＭＮ）と呼ぶ）がモバイルであって、サブネット間を移動する場合、階層型アドレッシング方式のためにそのＩＰアドレスをトポロジ的に正しいＩＰアドレスに変更しなければならない。しかし、ＴＣＰコネクションなどの上位レイヤ上でのコネクションは、通信中のノードのＩＰアドレス（及びポート）で定義されるので、一方のノードが移動などのためにそのＩＰアドレスを変更すると、コネクションは切断される。

モバイルＩＰｖ６［Ｄ．Ｊｏｈｏｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「ＩＰｖ６でのモビリティサポート（Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６）」ＩＥＴＦ ＲＦＣ ３７７５、２００４年６月］は、ＭＮが上位レイヤ及びアプリケーションに透過（トランスペアレント）な方法で、すなわち、上位レイヤのコネクションを切断することなしに、サブネット間を移動することができるようにするＩＲベースのモビリティプロトコルである。したがって、ＭＮは、２つのＩＰアドレスを構成している。すなわち、気付アドレス（ＣｏＡ：Care-of Address）とホームアドレス（ＨｏＡ：Home Address）である。ＭＮの上位レイヤは、通信相手（宛て先端末）（以降、コレスポンデントノード（ＣＮ：Correspondent Node）と呼ぶ）との通信のためにＨｏＡを使用する。このアドレスは変更されず、ＭＮを識別するために用いられる。トポロジの観点から、このアドレスは、ＭＮのホームネットワーク（ＨＮ：Home Network）に属する。これと対照的に、ＣｏＡは、移動のたびに変更され、サブネットが変更され、ルーティングインフラストラクチャのためのロケータとして使用されるトポロジの観点から、このアドレスは、ＭＮの現在の在圏ネットワークに属する。ホームリンク上に存在するホームエージェント（ＨＡ）の組のうちの１つのホームエージェントがＭＮのＨｏＡに対するＭＮのＣｏＡのマッピングを維持し、ＭＮの着信トラフィックを現在のロケーションに転送する。１つのＨＡでなく１組のＨＡを有する理由は、冗長構成及び負荷平衡である。

上記のように、モバイルＩＰｖ６は、現在２つの動作モードを定義する。すなわち、双方向トンネリングと経路最適化である。双方向トンネリングを使用する場合、ＣＮがＭＮのＨｏＡ宛てに送信したデータパケットはＨＮ内でＨＡによって受信（intercept）され、ＭＮのＣｏＡへトンネリングされる。ＭＮが送信したデータパケットは、ＨＡへ逆トンネリングされ、パケットはデカプセル化されてＣＮへ送信される。この動作のためには、ＭＮのＣｏＡについて、ＨＡに対してのみ通知がされる必要がある。したがって、ＭＮは、バインディングアップデート（ＢＵ：Binding Update）メッセージをＨＡに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティアソシエーション上で送信され、その結果、認証されかつその完全性が保護される。ＣＮはＭＮのＣｏＡを認識していないため、ＭＮのロケーションを抽出できず、ロケーションプライバシが提供される。しかし、ＭＮはホームネットワークから遠く離れ、かつＣＮがＭＮに近い場合には、通信パスは不必要に長くなり、非効率的なルーティングやパケット遅延が生じる。

経路最適化モードは、ＣＮとＭＮとの間に直接のパスを用いてこの非効率を防止することができる。したがって、ＭＮはＣＮへＢＵメッセージを送信し、次に、ＣＮはＭＮへデータパケットを直接送信することができる（タイプ２ルーティングヘッダを用いて直接のパス上でパケットを送信する）。この場合、ＣＮが、モバイルＩＰｖ６経路最適化をサポートしていなければならないことは当然である。ＢＵメッセージを認証するため、ＭＮとＣＮは、ＨｏＡ及びＣｏＡにＭＮが到達したかを試験し、共有セッション鍵を生成する、いわゆるリターンルータビリティ手順を実行する。しかし、ＣＮは、ＢＵメッセージによってＭＮのＣｏＡを認識するので、そのロケーションを抽出することができる。すなわち、ロケーションプライバシは提供されない。

ＶｏＩＰなどの対話型アプリケーションではパケット遅延が短いことが要求されるので、ロケーションプライバシ及び経路最適化の両方を提供する機構が望ましい。この機構は、２つのモバイルノードが通信し、両方のＭＮが互いにそのロケーションを秘匿する（双方向ロケーションプライバシ）シナリオをサポートする必要がある。

以下、経路最適化及び／又はロケーションプライバシをある程度提供することができる従来技術の文献及びそれらの解決方法の欠点について説明する。

ＨＭＩＰ［Ｈｅｓｈａｍ Ｓｏｌｉｍａｎ、Ｃｌａｕｄｅ Ｃａｔｅｌｌｕｃｃｉａ、Ｋａｒｉｍ Ｅｌ Ｍａｌｋｉ、Ｌｕｄｏｖｉｃ Ｂｅｌｌｉｅｒ、「階層型モバイルＩＰｖ６のモビリティ管理（ＨＭＩＰｖ６）（Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ （ＨＭＩＰｖ６））」、ＩＥＴＦ ＲＦＣ４１４０、２００５年８月］は、（潜在的に離れた）ＨＡへＢＵメッセージを送信することに起因するレイテンシ及びシグナリングオーバヘッドを低減するために策定された。モビリティを部分的にローカルに扱うことが提案されている。したがって、モビリティアンカポイント（ＭＡＰ：Mobility Anchor Point）の階層構造が在圏ネットワークに導入される。ＭＮは、ローカルＭＡＰにそのＣｏＡを登録するだけでよい。追加のＣｏＡ、いわゆるリージョンＣｏＡ（ＲＣｏＡ）がＭＡＰのサブネットから入手され、ＭＡＰはこれを用いてＭＡＰの領域内のＭＮのモビリティをＨＡ（経路最適化の場合はＣＮ）に対して秘匿する。さらに、ＭＮは、ＣｏＡとしてＲＣｏＡを用いて経路最適化モードを開始することができる。それゆえ、経路最適化及びロケーションプライバシのある程度のサポートが提供されるが、ＣＮはＭＮが現在位置するＲＣｏＡ、すなわちＭＡＰリージョンを知っているため、ロケーションプライバシは極めて限定される。

ＡＲＥＣ［ＷＯ２００４０５５９９３］［Ｇ．Ｋｒｉｓｈｎａｍｕｒｈｉ、Ｈ．Ｃｈａｓｋａｒ、Ｒ．Ｓｉｒｅｎ、「ＩＰベースのモバイル通信でのエンドツーエンドのロケーションプライバシの提供（Ｐｒｏｖｉｄｉｎｇ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｌｏｃａｔｉｏｎ Ｐｒｉｖａｃｙ ｉｎ ＩＰ−ｂａｓｅｄ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）」、ＩＥＥＥ ＷＣＮＣ、２００４年３月］は、在圏ネットワークごとに各アクセスルータ（ＡＲ）の変更が必要となる。バインディング情報は、ＭＮ及びＣＮのＨＡからＡＲへそれぞれ送信され、データパケットは、ＨＡの関与なしにＭＮ及びＣＮのそれぞれのＡＲ間でトンネリングされる。こうして、ＭＮとＣＮ間の直接の、すなわち最短の経路が使用され、ロケーションプライバシがサポートされる。また、ＷＯ２００４０１０６６８では、極めて似た手法が提示される。しかし、ＨＡからＡＲへのバインディング情報の配信には標準化が必要な新しい複雑なプロトコルが必要であろう。

ＯＲＣ［Ｒｙｕｊｉ Ｗａｋｉｋａｗａ、「最適化経路キャッシュプロトコル（ＯＲＣ）（Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅ Ｐｒｏｔｏｃｏｌ （ＯＲＣ））」、インターネットドラフトｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ、２００４年１０月］は、モバイルネットワーク（ＮＥＭＯ）の経路最適化のために策定され、バインディング情報の提供を含む在圏ネットワークのエッジルータの変更を必要とする。ＭＮは、データパケットをＣＮの現在のネットワーク（ＣＮがモバイルの場合）のエッジルータへトンネリングする。ＣＮは、ＭＮの現在の在圏ネットワークのエッジルータへデータパケットをトンネリングすることができる。パケットをエッジルータにトンネリングできるためには、各ノードは、ＣＮに関するロケーション情報を示す通信相手のエッジルータのＩＰアドレスを知っていなければならない。すなわち、ロケーションプライバシサポートは、一方向であり、双方向ではない。

ＧｌｏｂａｌＨＡＨＡ［Ｐ．Ｔｈｕｂｅｒｔ、Ｒ．Ｗａｋｉｋａｗａ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「グローバルＨＡ間プロトコル（Ｇｌｏｂａｌ ＨＡ ｔｏ ＨＡ ｐｒｏｔｏｃｏｌ）」、ＩＥＴＦインターネットドラフトｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００、２００４年１０月］によれば、様々なトポロジ上のロケーションからホームネットワークのプレフィックスへの経路を複数のＨＡに公示させることで、通常はホームリンクに限定されているＨＡをインターネット内に分散することが可能となる。ＭＮは、プロキシＨＡとしての役割を果たす最も近いＨＡにバインドすることができ、その結果、経路は最適化される。双方向トンネリングを使用すればロケーションプライバシが得られる。それゆえ、経路最適化とロケーションプライバシとが同時に得られる。しかし、すべての在圏ネットワークが他のすべてのネットワークへの経路を公示すると（複数のＭＮに対してすべてがホームネットワークである）、アドレス階層構造がもはや提供されないため、ルーティングのスケーラビリティの問題が起こる。さらに、こうした分散ホームネットワークは、手動で構成されなければならない。安全なオンデマンド構成はサポートされず、標準化が必要な新しい複雑なプロトコルが必要であろう。

ＷＯ０３０４１３５８では、各ネットワークにいわゆるロケーションプライバシエージェント（ＬＰＡ：Location Privacy Agent）及びロケーションプライバシサーバ（ＬＰＳ：Location Privacy Server）が導入される。ＭＮは、そのＬＰＡへロケーションプライバシ要求メッセージを送信し、ＬＰＡはＣＮに近いＬＰＡを選択する。このＬＰＡのアドレスがＭＮに与えられ、次に、ＭＮはこのＬＰＡへＢＵメッセージを送信する。それゆえ、この手法はＯＲＣの手法に似ている。ＬＰＡはＣＮのネットワークに近いため、ＣＮのロケーションをある程度知っており、ＣＮがモバイルであれば、ロケーションプライバシサポートが無効になる。さらに、この解決方法では新しいシグナリングプロトコルが必要である。

ＵＳ２００５０４１６７５及びＷＯ２００４０４３０１０では、ロケーションプライバシは、ＩＰアドレスの暗号化によって変更したプレフィックスによって達成される。プレフィックスは、普通、ルータがＩＰパケットをルーティングするために使用するので、この手法は、インターネット内のすべてのルータを変更しなければならず、そうでなければロケーションプライバシは制限される。

ＷＯ０３０４４６２６では、マルチキャストアドレスがＣｏＡとして使用される。マルチキャストアドレスにはロケーション情報が含まれないので、経路最適化モードでもロケーションプライバシサポートが提供される。しかし、この解決方法では、大規模な配備によってインターネットでフラットなルーティングが実行されるため、ＭＮの数に対応したスケーラビリティが得られない。

［Ｊ．Ｚｈａｎｇ、Ｄ．Ｐｅａｒｃｅ、「モバイルＩＰｖ４経路最適化のためのエージェントベースのリターンルータビリティテスト（Ａｇｅｎｔ−Ｂａｓｅｄ Ｒｅｔｕｒｎ Ｒｏｕｔａｂｉｌｉｔｙ Ｔｅｓｔ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ４ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ）」ＩＥＴＦインターネットドラフトｄｒａｆｔ−ｚｈａｎｇ−ｍｏｂｏｐｔｓ−ａｇｅｎｔ−ｍｉｐ４ｒｒ−００．ｔｘｔ、２００５年８月］では、ＭＩＰｖ４経路最適化のためにＭＩＰｖ６経路最適化方式を採用することが提案されている。リターンルータビリティに関してＣＮの代理をする通信相手エージェント（ＣＡ：Correspondent Agent）が導入される。こうしてＣＮの実装を変更する必要がなく、データパケットは、ＭＮとＣＡとの間で直接にトンネリングすることができる。ＣＡの副次的な効果は、ＭＮのロケーションがＣＮから見えないという点である。この手法はＯＲＣに似ている。それゆえ、ＣＮがモバイルでロケーションプライバシサポートが片方向のみである場合、ＣＮのロケーションはＭＮに対して明らかにされる。

解決すべき問題は、新しい、標準化が必要なシグナリングプロトコルを導入する必要なしに、できる限り端末及びネットワーク装置に変更を加えずにモバイルＩＰｖ６ベースの通信のロケーションプライバシ及び経路を同時に提供することである。これは配備が非常に大幅に容易であるだろう。

発明の概要

この目的は、独立請求項の主題によって解決される。本発明の有利な実施の形態は、独立請求項の主題である。

この目的を達成するために、本発明は、複数のアクセスネットワークを備えるモバイル通信システムで第１のモバイルノードと第２のモバイルノードとの間のパケット交換データ伝送の経路最適化のための方法、装置、システム及びコンピュータが読み取り可能な媒体を提供する。リターンルータビリティプロトコルパケット及びデータパケットが伝送され、リターンルータビリティプロトコルパケット及びデータパケットは分析され、リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスの少なくとも一部が取り除かれる。

有利な一実施の形態によれば、ヘッダに含まれるアドレスからロケーション情報がないアドレスが変換規則によって導出され、ヘッダに含まれるアドレスは、ロケーション情報のないアドレスと置換される。

本発明の別の実施の形態では、アドレスは、気付テスト開始メッセージ又はバインディング更新メッセージのインターネットプロトコルヘッダ内の気付アドレスである。

別の実施の形態では、分析及び除去ステップは、インターネットプロトコルヘッダのソースアドレスフィールドにおいて第１のアクセスルータによって実行される。

別の有利な実施の形態は、分析及び除去ステップ後に気付アドレスをヘッダ内に置換するステップを有する。

本発明の別の実施の形態では、変換規則は、気付アドレスにビットを加えるステップを有する。

別の有利な実施の形態では、第１のモバイルノードは、ロケーション情報がないアドレスを用いてバインディング更新メッセージ内の第１のオーセンティケータを計算する。

本発明の別の有利な態様によれば、第２のアクセスルータは、バインディング更新メッセージ内の第２のオーセンティケータを、ロケーション情報がないアドレスを用いて計算される第１のオーセンティケータで置換する。

本発明の別の実施の形態は、ロケーションプライバシ要求を示す第１のフラグを第１のモバイルノードがホームテスト開始メッセージ内にセットするステップと、分析及び除去ステップを実行するように構成されているか否かを示す第２のフラグを第２のアクセスルータがホームテスト開始メッセージ内にセットするステップとを含む。

本発明の別の有利な態様は、除去ステップを実行する気付テスト開始メッセージを示すプライバシフラグを第１のモバイルノードがセットするステップと、気付アドレスをホームアドレスと置換する必要があるリターンルータビリティプロトコルパケット及びデータパケットを第１のアクセスルータが識別するステップとを含む。

本発明の別の実施の形態では、第１及び第２のアクセスルータが分析及び除去ステップを実行できるか否かを示す第３のフラグが第１及び第２のアクセスルータによってセットされ、第１及び第２のアクセスルータがそれぞれ第２及び第１のアクセスルータのフラグの状態に関する情報を維持し、モバイルノードのホームエージェントがロケーションプライバシ要求を示す第４のフラグをホームテストメッセージ又はホームテスト開始メッセージ内にセットする。

第２のモバイルノードが別のアクセスネットワークへ移動する場合、第２のモバイルノードに関する状態情報は、第１のアクセスルータから第３のアクセスルータへ転送されることが有利である。

本発明の別の有利な実施の形態によれば、第２のモバイルノードが別のアクセスネットワークへ移動する場合、第２のモバイルノードは、第１のモバイルノードにバインディングリフレッシュ要求メッセージを送信する。

本発明の別の有利な実施の形態では、第２のモバイルノードは、上記第１のモバイルノードのために記述されたステップを実行する。

本発明の別の有利な実施の形態は、第１のモバイルノード（１００）と第２のモバイルノード（２００）との間のパケット交換データ伝送の経路最適化のための複数のアクセスネットワークを含むモバイル通信システムであって、第１のモバイルノード（１９９）がリターンルータビリティプロトコルパケットを送信することができ、第１のアクセスルータ（２０２）がリターンルータビリティプロトコルパケット及びデータパケットを分析し、リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスの少なくとも一部を取り除くことができるモバイル通信システムに関する。

本発明の別の実施の形態は、ロケーション情報がないアドレスを用いてバインディング更新メッセージ内の第１のオーセンティケータを計算するための計算手段を備えるモバイル通信システムのモバイルノードに関する。

本発明の別の実施の形態は、複数のアクセスネットワークを備えるモバイル通信システムのアクセスルータであって、リターンルータビリティパケット及びデータパケットを分析するように構成された分析手段と、リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスの少なくとも一部を取り除くように構成された置換手段とを備えるアクセスルータに関する。

本発明の別の実施の形態は、アクセスルータによって実行される場合に、アクセスルータに、リターンルータビリティプロトコルパケット及びデータパケットを分析し、リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスの少なくとも一部を取り除くことで複数のアクセスネットワークを備えるモバイル通信システムの第１のモバイルノードと第２のモバイルノードとの間のパケット交換データ伝送の経路を最適化させる命令を格納しているコンピュータが読み取り可能な媒体に関する。

添付の図面は、本発明の原理を説明するために本明細書に組み込まれ、その一部を形成する。これらの図面は、本発明を構築し使用する方法の図示及び説明された例に本発明を限定するものと解釈すべきではない。添付の図面に図示された以下の本発明のより具体的な説明を読むことで本発明の詳細な特徴及び利点が明らかになろう。

発明の詳細な説明

本発明は、ロケーションプライバシ（すなわち、コレスポンデントノードに対してモバイルノードのロケーションを秘匿する機能）と経路最適化を同時に提供する機構を提案する。この機構は、モバイルＩＰｖ６への変更量が最小で済み、リターンルータビリティ手順に基づいている。

なお、様々なタイプのロケーションプライバシを区別することができることに留意されたい。本発明が目的とするロケーションプライバシのタイプは、ＣＮに対するＭＮのロケーション（それゆえ、ＣｏＡ）の秘匿である。他のタイプには、盗聴者に対するロケーションの秘匿又はＭＮのロケーションの追跡の防止がある。

この解決方法は、双方向のロケーションプライバシを提供する。すなわち、両方の通信相手がモバイルである場合に、ロケーションは双方向に秘匿される。この解決方法は、標準のモバイルＩＰｖ６と同じレベルのセキュリティを提供する。

本発明の主要な考え方は、ＡＲ（アクセスルータ）の機能を拡張することで、ＭＩＰｖ６経路最適化にロケーションプライバシサポートを追加することである。ＡＲは、リターンルータビリティプロトコル及びデータパケットをモニタし、ロケーション情報を含むＩＰヘッダ内のアドレス（の一部）を置換する。両方のＡＲがこの処理に関与する場合、ロケーションプライバシサポートは双方向である。すなわち、２つのモバイルノードが相互に通信している場合、いずれのモバイルノードも相手のロケーションを判定することができない。リターンルータビリティプロトコルが使用され、プロトコルメッセージ自体を変更する必要はないため、新しいプロトコルを策定し、標準化し、ネットワーク又は端末装置に導入する必要はない。このため、システム配備は大幅に容易になる。２つの解決方法の変形形態が提案されている。一方は、ＡＲでの処理量を増やす必要があるがＭＮの実施態様の変更は不要であり、他方は、ＭＮ実施態様の変更が必要であるがＡＲでの処理量は低減する。

言い換えれば、ＡＲは、リターンルータビリティプロトコル及びデータパケットのＩＰヘッダ内のＣｏＡ（気付アドレス）をロケーション情報を含まないアドレスと置換する。この文脈でのロケーション情報がないＣｏＡ（以降、ＣｏＡｘと呼ぶ）は、周知の変換規則を用いてＣｏＡから導出することができる。アドレスのプレフィックスだけがロケーション情報を含んでいるため、例えば、規則は、ＣｏＡのプレフィックスを０などの周知の値に設定することである。

以下、両方の通信相手がモバイルであって、かつホームから離れているシナリオを想定する。ＭＮがホームにいる場合、経路最適化を起動する必要はない（経路は既に最短経路である）。レガシ固定ＣＮ（コレスポンデントノード）のサポートについては、以下を参照されたい。

図２は、本発明を実施した場合のデータパケットのＩＰヘッダ内のデータパス及びアドレスを示す図である。標準のモバイルＩＰｖ６双方向トンネリング又は経路最適化モード（図１を参照）と比較して、パスの長さは経路最適化モードの場合と同じ程度に短い。

リターンルータビリティ手順
ＭＮ（モバイルノード）１００は、ＨＡ（ホームエージェント）１０２上で逆トンネリングされるＨｏＴｉ（ホームテスト開始）メッセージを送信することによりリターンルータビリティ手順を開始する。ＨｏＴｉメッセージは、要求に対する応答をマッピングすることができるクッキーを含む。ＣＮ１０６は、ＨｏＡ及びｎｏｎｃｅから鍵付きハッシュ関数で計算されるクッキー、ｎｏｎｃｅインデックス及びホームｋｅｙｇｅｎトークンを含むいわゆるＨｏＴ（ホームテスト）メッセージで応答する。この交換と並行して、又はその後に、ＭＮ１００は、直接のパス上でＣＮ１０６へＣｏＴｉ（気付テスト開始）メッセージを送信する。ＣｏＴｉもクッキーを含み、ＣＮ１０６は、ＣｏＡ及びｎｏｎｃｅから鍵付きハッシュ関数で計算されるクッキー、ｎｏｎｃｅインデックス及び気付ｋｅｙｇｅｎトークンを含むＣｏＴ（気付テスト）メッセージで応答する。ハッシュ関数のための鍵及びｎｏｎｃｅは、ＣＮ１０６にだけ知られている。ＭＮ１００は、ＨｏＴ及びＣｏＴメッセージの両方を受信した後、ＨｏＴ及びＣｏＴメッセージ内のｋｅｙｇｅｎトークンの連結のハッシュ値であるバインディング鍵を計算する。

それゆえ、正しいバインディング鍵は、ＨｏＴ及びＣｏＴメッセージの両方を受信したエンティティによってのみ計算することができる。両方のメッセージは異なるパスで送信されるため、攻撃者は両方のパス又は（ＣＮ／ＭＮに近い）接続パス上に位置する必要がある。

次に、ＭＮ１００は、バインディング鍵で鍵が付けられたハッシュ関数を用いてオーセンティケータを計算する。オーセンティケータは、ＢＵ（バインディング更新）メッセージ、ＨｏＡ及びＣｏＡ上で計算され、ＢＵメッセージに追加される。この認証されたＢＵメッセージは、最後にＣＮへ送信される。検証が成功すると、ＣＮは、そのバインディングキャッシュ内にＨｏＡ及びＣｏＡのバインディングを生成し、直接のパス上でＭＮ１００へパケットを送信することができる。

ＣｏＡの置換
図３及び図４は、それぞれ変更ＭＮ実施態様が必要な／必要でないリターンルータビリティプロトコルのＣｏＡ置換の２つの変形形態を示す図である。図では、ＭＮ１ １００によって（ＭＮ２ １０６に送信されるトラフィックのため）片方向に最適化経路を構築した様子を示す。双方向経路最適化を達成するために、ＭＮ２ １０６によってもう一方の方向に同じ手順を繰り返さなければならない。

図３で、ＡＲ２ ２０２はＣｏＴｉ（３００）及びＢＵメッセージ（３０４）のＩＰヘッダのソースアドレスフィールド内のＣｏＡ_MN1をＣｏＡｘ_MN1と置換する。それゆえ、ＭＮ１ １００のロケーションは、ＭＮ２ １０６に対して秘匿されている。ＡＲ２ ２０２は、ＣｏＴメッセージ（３０２）及びデータパケット（３０８）の宛て先フィールド内のＣｏＡｘ_MN1をＣｏＡ_MN1に置換してこれらのパケットのＭＮ１ １００への正確なルーティングを可能にする。さらに、ＡＲ１ ２００は、ＭＮ２ １０６が送信したデータパケット（３１０）のＩＰヘッダのソースアドレスフィールド内のＣｏＡ_MN2を置換して、ＭＮ２のロケーションをＭＮ１ １００に対して秘匿することができる。

ＭＮ２ １０６は、ＣｏＡｘ_MN1のみを認識しており、それゆえ、ＣｏＡｘ_MN1に基づいてＣｏＴメッセージの気付ｋｅｙｇｅｎトークンを計算することに留意されたい。また、ＭＮ１ １００から受信したＢＵは、このアドレスに基づいて検証しなければならない。したがって、ＭＮ１ １００は、ＣｏＡｘ_MN1を認識しなければならず、ＢＵ認証を成功させるために、３０６内のＣｏＡｘＭＮ１（ＣｏＡ_MN1ではない）に基づいてＢＵオーセンティケータを計算しなければならない。また、ＢＵメッセージは、ＣｏＡ_MN1の代わりにＣｏＡｘ_MN1を含む必要がある。

図４は、この変更を防止する変形形態を示す図である。すなわち、ＭＮ１ １００は、通常通りにＣｏＡ_MN1を用いてオーセンティケータを計算する。ＣＮで成功した検証を許可するために、ＡＲ１ ２００は、ＣｏＡｘ_MN1を用いてオーセンティケータを再計算し、このオーセンティケータをＢＵメッセージ（４０８）内で置換する。したがって、ＡＲ１ ２００は、先に受信したＨｏＴ及びＣｏＴメッセージ（４００及び４０６）から決定することができるホーム及び気付ｋｅｙｇｅｎトークンを認識しなければならない。それらは、対応するＨｏＡ及びＣｏＡと共に格納される。ＣｏＡの交換は、変更ＭＮの変形形態と同様に実行することができる（４０２、４０４、４１０、４１２及び４１４）。

図７は、図３及び図４の方法をフローチャートの形式で示す図である。ステップ７００で、ＡＲ２は、ＣｏＴｉメッセージのＩＰヘッダのソースアドレスフィールド内のＭＮ１の気付アドレスをＭＮ１のＣｏＡｘと置換する。次に、ステップ７０２で、ＡＲ２は、ＣｏＴメッセージのＩＰヘッダの宛て先アドレスフィールド内のＭＮ１のＣｏＡｘをＭＮ１のＣｏＡと置換する。ステップ７０４で、ＡＲ２は、ＢＵメッセージのＩＰヘッダのソースアドレスフィールド内のＭＮ１のＣｏＡをＭＮ１のＣｏＡｘと置換する。

モバイルノードの実装が変更されている場合（７０６）、ステップ７０８で、ＭＮ１は、ＢＵ認証のためにそのＣｏＡｘに基づいてＢＵオーセンティケータを計算する。次に、ステップ７１６で、ＡＲ２は、データパケットのＩＰヘッダの宛て先アドレスフィールド内のＭＮ１のＣｏＡｘをＭＮ１のＣｏＡと置換する。

モバイルノード実装が変更されていない場合（７０６）、ステップ７１０で、ＭＮ１は、ＢＵ認証のためにそのＣｏＡに基づいてＢＵオーセンティケータを計算する。ＡＲ１は、ＢＵメッセージ内のＢＵオーセンティケータを再計算し、ＣｏＡをＣｏＡｘと置換する。

ＭＮ２がそのロケーションをＭＮ１（７１２）に対して秘匿したい場合、ＡＲ１は、ステップ７１４で、データパケットのソースアドレスフィールド内のＭＮ２のＣｏＡを置換する。次いでＡＲ２は、ステップ７１６で、データパケットのＩＰヘッダの宛て先アドレスフィールド内のＭＮ１のＣｏＡｘをＭＮ１のＣｏＡと置換する。

ＭＮ２がそのロケーションをＭＮ１（７１２）に対して秘匿したくない場合、ＡＲ２は、ステップ７１６で、データパケットのＩＰヘッダの宛て先アドレスフィールド内のＭＮ１のＣｏＡｘをＭＮ１のＣｏＡと置換する。

ケーパビリティ／要求ネゴシエーション及びその使用
図３及び図４で、ＡＲ２は、ＭＮ２に対してＭＮ１のロケーションを秘匿する役割を果たし、ＡＲ１は、ＭＮ１に対してＭＮ２のロケーションを秘匿する役割を果たす。すなわち、ＭＮは、コレスポンデントノードのＡＲを信頼しなければならない。このＡＲが本発明を実施しない場合、ＭＮのロケーションはＣＮに知られてしまう。ＭＮのロケーションを露呈する第１のメッセージは、ＣｏＴｉメッセージである。問題は、ＭＮ及びＭＮのＡＲがＣＮのＡＲが本発明を実施するか否かを知ることができない点である。

１つの解決方法は、すべてのＡＲが本発明を確実にサポートすることである。しかし、シナリオによっては、これはオプションにならない。そのようなシナリオでは、可能な解決方法は、ＡＲに、ＨｏＴ／ＨｏＴｉメッセージ内に本発明のサポートを示すフラグをセットさせ、ＣＮのＡＲが本発明をサポートしない場合に、ＣｏＴｉ／ＣｏＴメッセージの送信を防止することである。しかし、これは、ＣｏＴｉ／ＣｏＴ及びＨｏＴｉ／ＨｏＴの交換が並列に実行できないことを意味する。

次いで、２つの変形形態が提案される。１つは変更されたＭＮを必要とし、もう１つは変更されたＭＮを必要としない。

第１の変形形態はＭＮの実装の変更を必要とし、これを図５に示す。ＭＮ１は、ＡＲ２が本発明をサポートするか、又はＭＮ１がロケーションプライバシを必要としない場合、ＣｏＴｉのみを送信する（５１２）。同様に、ＭＮ２は、ＡＲ１が本発明をサポートするか又はＭＮ２がロケーションプライバシを必要としない場合、ＣｏＴメッセージのみを送信する（５１６）。ＭＮ１はロケーションプライバシ要求を示すフラグをセットし（５００）、ＡＲ１はそのＬＰＲＯＭサポートを示すフラグをセットする（５０２）ので、ＡＲ２（５０４）及びＭＮ２（５０６）は、ＨｏＴｉメッセージ受信時にＭＮ１の要求及びＡＲ１のＬＰＲＯＭ（ロケーションプライバシ経路最適化モード：Location Privacy Route Optimisation Mode）ケーパビリティを認識する。同様に、ＭＮ２は、ロケーションプライバシ要求を示すフラグをセットし（５０６）、ＡＲ１はそのＬＰＲＯＭサポートを示すフラグをセットする（５０８）。それゆえ、ＡＲ１（５１０）及びＭＮ１（５１２）は、ＭＮ２の要求及びＡＲ２のＬＰＲＯＭケーパビリティを認識する。

問題は、ＣｏＴｉ、ＣｏＴ、Ｂｕメッセージ及びデータパケットのいずれでＣｏＡを置換しなければならないか（ＭＮによってはロケーションプライバシは不要であることに留意されたい）を知らなければならないという点である。例えば５１４で、ＡＲ２は、ＭＮ２に対してＭＮ１のロケーションを秘匿するために、ＣｏＴｉメッセージのＩＰヘッダ内のＣｏＡ_MN1を置換しなければならないことを知っている必要がある。したがって、ＣｏＡが置換されるべきＣｏＴｉメッセージを表す特別のプライバシフラグがＭＮ１によってセットされる（５１２）。次に、ＡＲ２はこのＣｏＡを格納することができ（５１４）、後続のＣｏＴ（５１８）、ＢＵ（５２０）及びデータパケット（５２２）内でこのアドレスを置換する。それゆえ、後続のパケットは、プライバシフラグを立てる必要はない。さらに、ＡＲ２は、タイプ２ルーティングヘッダ内のＣｏＡのＨｏＡＭＮ１との置換を必要とするデータパケットを識別する（５２２）。このＨｏＡは、５０４の受信ＨｏＴｉメッセージから分かる。同様に、ＡＲ１は、ＨｏＡオプション内のＨｏＡ_MN2によるＣｏＡの置換を必要とするデータパケットを識別する（５２４）。ＡＲ１は、５１０で受信ＨｏＴメッセージからこのＨｏＡを知り、格納する。

第２の変形形態は、ＭＮの実装の変更を必要としない。これは、ＣＮのＡＲが本発明をサポートせず、ロケーションプライバシが必要な場合に、ＣｏＴｉ／ＣｏＴメッセージをＡＲに破棄させることで達成される。それゆえ、ＡＲは、他のＡＲの本発明のサポート及びＭＮのロケーションプライバシ要求に関する状態情報を維持する。ＡＲは、ＭＮのＨＡによってＨｏＴｉ／ＨｏＴメッセージに追加されるフラグによって通信相手のＭＮのロケーションプライバシ要求について知ることができる。次いでＨＡは、事前に（例えば、モバイルＩＰサービス加入時にオフラインで）ＭＮのロケーションプライバシ要求を通知される。

図６にこの変形形態を詳細に示す。ＨＡ１及びＨＡ２は、ＭＮ１及びＭＮ２のロケーションプライバシ（６０２、６０４、６１０及び６１２）要求を示すフラグをＨｏＴｉ及びＨｏＴメッセージ内にセットする。上記と同様に、ＡＲは、ＬＰＲＯＭのサポートを示すフラグをセットする（６００及び６０８）。それゆえ、ＡＲ２は、６０６で、ＭＮ１及びＭＮ２の要求及びＡＲ１のＬＰＲＯＭケーパビリティについて知ることができ、ＡＲ１は、６１４で、ＭＮ１及びＭＮ２の要求及びＡＲ２のＬＰＲＯＭケーパビリティについて知ることができる。

ＭＮ１の代わりに、ＡＲ２が本発明をサポートするか否か、またＭＮ１がロケーションプライバシを必要としないか否かをＡＲ１がチェックする（６１６）。両方の条件のうち一方が当てはまる場合、ＡＲ１はＣｏＴｉメッセージを転送する。そうでない場合、ＡＲ１はこのメッセージを破棄する。同様に、ＡＲ２は、ＡＲ１が本発明をサポートするか否か、またＭＮ２がロケーションプライバシを必要としないか否かをチェックし、その後、結果に応じてメッセージを転送又は破棄する（６１８）。

その他の手順（例えば、５１８〜５２４とパケット及び置換が必要なアドレスの識別）は、第１の変形形態の場合と同じなので、再度説明は行わない。

モビリティの扱い
本発明では、ＡＲが状態情報を維持することが必要である。例えば、ＡＲ２は、ＭＮ１のロケーションプライバシ要求と置換すべきＣｏＡ（ＣｏＡ_MN1）を知らなければならない。ＭＮ２が新しいＡＲ（ＡＲ２’）へ移動中の場合、ＭＮ２に対してＭＮ１のロケーションを秘匿できるようにこの状態情報も保持しなければならない。新しいＡＲ内でこの状態情報を確立する２つのオプションが提案されている。

第１のオプションは、（Ｊ．Ｌｏｕｇｈｎｅｙ、Ｍ．Ｎａｋｈｊｉｒｉ、Ｃ．Ｐｅｒｋｉｎｓ、Ｒ．Ｋｏｏｄｌｉ、「コンテキスト転送プロトコル（Ｃｏｎｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）」、ＩＥＴＦ ＲＦＣ４０６７、２００５年７月）などのコンテキスト転送プロトコルを用いてＡＲ２からＡＲ２’へ状態を転送する方法である。

第２のオプションは、ＭＮ１がリターンルータビリティ手順を繰り返し行って状態をＡＲ２’内に導入する方法である。ＭＮ２は、モバイルＩＰｖ６バインディングリフレッシュ要求（ＢＲＲ：Binding Refresh Request）メッセージをＭＮ１へ送信することによりＭＮ１にリターンルータビリティ手順を開始させることができる。しかし、ロケーションプライバシを保護するために（そうでなければ一部のパケットがＭＮ１のＣｏＡを含むＭＮ２に達することがある）、ＭＮ１によって開始された反復リターンルータビリティ手順は、ＭＮ２によって開始された反復リターンルータビリティ手順が完了する前に完了しなければならない。ノードは、ハンドオーバ後にＣＮ内のバインディングを更新するために常にリターンルータビリティ手順を実行しなければならないため、後者の（ＭＮ２が開始した）リターンルータビリティ手順は実行されなければならない。

トンネリングされたパケットへのアクセス
本発明では、ＡＲがモバイルＩＰｖ６ ＭＮ−ＨＡトンネル（例えば、ＨｏＴ／ＨｏＴｉメッセージ）内のパケットにアクセスしなければならない。保護されていないＩＰ−ｉｎ−ＩＰトンネリングを使用する場合、これは大きな問題ではない（ＡＲはトンネリングされたすべてのデータパケットを覗く必要があるため、小さい問題はＡＲで追加処理が必要であることであろう）。モバイルＩＰｖ６は、オプションとしてＩＰｓｅｃ ＥＳＰでＭＮ−ＨＡトンネルを暗号化することができる（Ｓ．Ｋｅｎｔ、「ＩＰカプセル化セキュリティペイロード（ＥＳＰ）（ＩＰ Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ （ＥＳＰ））」、ＩＥＴＦ ＲＦＣ４３０３、２００５年１２月）。この場合、ＡＲは、暗号鍵を知らなければトンネル内を覗くことはできず、ＨｏＴ／ＨｏＴｉ／ＣｏＴ／ＣｏＴｉ／ＢＵメッセージ、又は、パケットを識別できず、これらのパケットのヘッダ内のアドレスを置換することもできない。この場合、暗号鍵は、ＨＡからＡＲへ転送されるものとする（ＩＥＴＦは、現在ＡＲへのハンドオーバ用の鍵を安全に転送するプロトコルを策定中である。標準化されれば、これらのプロトコルを再使用してＩＰｓｅｃセキュリティアソシエーション（ＳＡ：Security Association）暗号鍵をＡＲへ転送することができる）。

セキュリティの考慮事項
ＭＮはＣＮのＡＲが表示通りにＭＮのロケーションを本当に秘匿している点についてＣＮのＡＲを信頼しなければならない。このことは大きな問題ではない。これは、今日のネットワークでは、ＭＮは、ある程度インフラストラクチャ内のルータを信頼しなければならないからである。ルータは、すべてのトラフィックを盗聴し（エンドツーエンドの暗号化を使用しない限り）、すべてのトラフィックを攻撃者へ再ルーティングし、すべてのトラフィックを破棄する可能性がある。

しかし、１つの関連する問題は、ＨｏＴ／ＨｏＴｉメッセージ内のフラグがパス上の攻撃者によって変更されないことを確保しなければならないということである。これができなければ、攻撃者は、実際はそうでないのにＣＮのＡＲが本発明をサポートしているふりをする。この場合、ＭＮはそれと知らずにＣＮに自分の位置を明らかにする。それゆえ、リンクが安全であると考えられなくても、メッセージ（特にＨｏＴ／ＨｏＴｉ／ＣｏＴ／ＣｏＴｉメッセージ）は暗号化されるべきである。これはリンク層又はＩＰ層のセキュリティを用いて達成できる。例えば、ＭＮ−ＨＡトンネルは、これらのメッセージにＩＰｓｅｃ ＥＳＰ暗号化を使用すべきである。インフラストラクチャは、普通、攻撃者に対する防護が十分であるため、一般に無線リンクが攻撃に最もさらされるロケーションである。攻撃者がインフラストラクチャの内部にいる場合、本発明を使用しなくてもほとんどすべてを実行することができる（上記参照）。

別の関連する問題では、ＡＲがＬＰＲＯＭをサポートしてはいないが悪意があるＭＮ自体は、「ＡＲサポートＬＰＲＯＭ」フラグをセットできないということを防止しなければならない。この問題の可能な解決方法は、ＡＲがＬＰＲＯＭサポートフラグをセットする際にメッセージに署名しなければならず、他のＡＲ又はＣＮは、メッセージの内容を信頼する前に最初にこの署名を検証しなければならないという方法である。しかし、異なる管理ドメインにわたるＰＫＩ又は事前共有の秘密が必要である。例えば、ＡＲがＨＡと秘密を共有し、ＡＲがメッセージに署名するのにこの秘密を使用する場合、ＨＡはメッセージの署名を検証でき、検証が失敗した場合、ＬＰＲＯＭサポートフラグでメッセージを破棄することができる。共有の秘密は、例えば、ネットワークアクセス認証の間にＨＡからＡＲへ鍵を転送することにより確立することができる。

別の問題は、ＨＡとは異なる管理ドメイン内に位置するＡＲがＭＡとＨＡとの間でトンネリングされ暗号化されるパケットにアクセスできるという前提が正しいか否かである（上記参照）。今日の通信ネットワーク内に類似の状況が存在するため、この前提は正しいと考えられている。この状況とは、ＧＰＲＳ（グローバルパケット無線システム：Global Packet Radio System）ネットワークの場合、ＡＲはＳＧＳＮ（サービングＧＰＲＳサポートノード：Serving GPRS Support Node）にマッピングすることができ、ＨＡはＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード：Gateway GPRS Support Node）にマッピングすることができるという状況である。ＧＧＳＮとＳＧＳＮとの間や、ＲＮＣ（無線ネットワーク制御装置：Radio Network Controller）とＵＥとの間のみでトラフィックが暗号化されるため、ＳＧＳＮはＵＥ（ユーザ装置：User Equipment）とＧＧＳＮとの間で交換されるパケットにアクセスすることができる（ローミングの場合であっても）。

固定（レガシ）コレスポンデントノードのサポート
ＣＮがモバイルＩＰｖ６モバイルノードでない場合、ＣＮの第１ホップルータは、ＡＲとして動作し、またＣＮに対してＭＮのロケーションを秘匿しなければならない。モバイルＣＮのケースとの唯一の相違点は、ＣＮに対してＨＡは存在しないことと、ＨＡ−ＣＮトンネルが存在することである。それゆえ、ＣＮのロケーションプライバシ要求に関するフラグをセットすることができるＨＡは存在しない。しかし、固定ノードは秘匿するＣｏＡがない（すなわち、ロケーションプライバシのサポートは不要である）ため、これは問題にならない。

本発明の別の実施の形態は、ハードウェア及びソフトウェアを用いた上記種々の実施の形態の実施に関する。上記種々の方法は、汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ：Digital Signal Processors）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuits）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Arrays）またはその他のプログラマブル論理装置などのコンピュータ装置（プロセッサ）を用いて実行することで実施されてもよいと考えられる。本発明の種々の実施の形態は、これらの装置の組み合わせによって実行又は具体化が可能である。

さらに、本発明の種々の実施の形態は、プロセッサによって実行されるソフトウェアによって、またはハードウェアで直接実施することができる。また、ソフトウェアモジュールとハードウェア実施の組み合わせも可能である。ソフトウェアモジュールは、ＲＡＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ可読記憶媒体内に格納することができる。

モバイルＩＰｖ６双方向トンネリング又は経路最適化モードを使用する場合のデータパスを示す図（従来技術） 本発明で定義する機構を使用する場合のデータパスを示す図。 ＭＮ実施態様を変更したリターンルータビリティプロトコルでのＣｏＡ置換を示す図 ＭＮ実施態様を変更していないリターンルータビリティプロトコルでのＣｏＡ置換を示す図 ＭＮ実施態様を変更したリターンルータビリティプロトコルでのケーパビリティ／要求ネゴシエーションとその使用を示す図 ＭＮ実施態様を変更していないリターンルータビリティプロトコルでのケーパビリティ／要求ネゴシエーションとその使用を示す図 ＣｏＡ置換のフローチャート

Claims (16)

1. 複数のアクセスネットワークを備えるモバイル通信システムの第１のモバイルノード（１００）と第２のモバイルノード（１０６）との間のパケット交換データ伝送の経路最適化方法であって、
   ａ）リターンルータビリティプロトコルパケット及びデータパケットを送信するステップ（２０４）と、
   ｂ）前記リターンルータビリティプロトコルパケット及びデータパケットを分析するステップと、
   ｃ）前記リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスであって、気付テスト開始メッセージ又はバインディング更新メッセージのインターネットプロトコルヘッダ内の気付けアドレスの少なくとも一部を取り除くステップ（３００）とを、
   有し、前記ステップｃ）が、
   ｄ）前記ヘッダに含まれる前記気付けアドレスからロケーション情報がない気付けアドレスを変換規則によって導出するステップと、
   ｅ）前記ヘッダに含まれる前記気付けアドレスをロケーション情報のない前記気付けアドレスに置換するステップ（７００）とを、
   更に有し、
   前記ステップｂ）及び前記ステップｃ）が、前記インターネットプロトコルヘッダのソースアドレスフィールドにおいて第１のアクセスルータ（２０２）によって実行される方法。
2. 前記ステップｂ）及びｃ）の後に、
   ｆ）前記気付アドレスを前記ヘッダ内に置換するステップを更に有する請求項１に記載の方法。
3. 前記変換規則が、前記気付アドレスにビットを付加することを含む請求項１に記載の方法。
4. ｇ）前記第１のモバイルノードが、ロケーション情報がない前記気付けアドレスを用いてバインディング更新メッセージ内の第１のオーセンティケータを計算するステップを更に有する請求項１に記載の方法。
5. ｈ）第２のアクセスルータ（２００）が、バインディング更新メッセージ内の第２のオーセンティケータを、ロケーション情報がない前記気付けアドレスを用いて計算される第１のオーセンティケータによって置換するステップを更に有する請求項１に記載の方法。
6. ｉ）ロケーションプライバシ要求を示す第１のフラグを前記第１のモバイルノードがホームテスト開始メッセージ内にセットするステップと、
   ｊ）前記第２のアクセスルータが、前記ステップｂ）及びｃ）を実行することができるか否かを示す第２のフラグを前記第２のアクセスルータが前記ホームテスト開始メッセージ内にセットするステップとを、
   さらに有する請求項１に記載の方法。
7. ｋ）前記ステップｃ）を実行することを示すプライバシフラグを前記第１のモバイルノードが気付テスト開始メッセージにセットするステップと、
   ｌ）気付アドレスをホームアドレスと置換する必要があるリターンルータビリティプロトコルパケット及びデータパケットを前記第１のアクセスルータが識別するステップとを、
   更に有する請求項６に記載の方法。
8. ｍ）前記第１及び第２のアクセスルータが、前記ステップｂ）及びｃ）を実行することができるか否かを示す第３のフラグを前記第１及び第２のアクセスルータがセットするステップと、
   ｎ）前記第１及び第２のアクセスルータが、それぞれ前記第２及び第１のアクセスルータのフラグの状態に関する情報を維持するステップと、
   ｏ）モバイルノードのホームエージェントが、ロケーションプライバシ要求を示す第４のフラグをホームテストメッセージ又はホームテスト開始メッセージ内にセットするステップとを、
   更に有する請求項１に記載の方法。
9. 前記第２のモバイルノードが、別のアクセスネットワークへ移動する場合に、
   ｐ）前記第２のモバイルノードに関する状態情報を前記第１のアクセスルータから第３のアクセスルータへ転送するステップと、
   ｑ）前記第２のモバイルノードが、前記第１のモバイルノードにバインディングリフレッシュ要求メッセージを送信するステップとを、
   更に有する請求項１に記載の方法。
10. 前記第１のモバイルノードと前記ホームエージェントとの間のデータパケットが暗号化される場合に、
    ｒ）前記ホームエージェント又は前記第１のモバイルノードから前記第１のアクセスルータへ暗号鍵を転送するステップを更に有する請求項１に記載の方法。
11. 前記第２のフラグがセットされたホームテスト開始メッセージの真正性を検証するために、
    ｓ）前記第２のアクセスルータが、前記第２のフラグを備える前記ホームテスト開始メッセージに署名するステップと、
    ｔ）前記第１のアクセスルータ又はホームエージェントまたは前記第２のモバイルノードが、前記ホームテスト開始メッセージの署名を検証するステップとを、
    更に有する請求項６に記載の方法。
12. ｕ）前記第２のモバイルノードが、リターンルータビリティプロトコルパケットを送信するステップと、
    ｖ）前記第２のモバイルノードによって送信される前記リターンルータビリティプロトコルパケットを分析するステップと、
    ｗ）前記第２のモバイルノードによって送信される前記リターンルータビリティプロトコルパケットのヘッダに含まれる気付けアドレスの少なくとも一部を取り除くステップとを、
    さらに有する請求項１に記載の方法。
13. 第１のモバイルノード（１００）と第２のモバイルノード（１０６）との間のパケット交換データ伝送の経路最適化のための複数のアクセスネットワークを備えるモバイル通信システムであって、
    前記第１のモバイルノード（１００）が、リターンルータビリティプロトコルパケットを送信することができ、
    第１のアクセスルータ（２０２）が、前記リターンルータビリティプロトコルパケット及びデータパケットを分析し、前記リターンルータビリティプロトコルパケット及びデータパケットのヘッダに含まれるアドレスであって、気付テスト開始メッセージ又はバインディング更新メッセージのインターネットプロトコルヘッダ内の気付けアドレスの少なくとも一部を取り除くことができ、
    さらに前記第１のアクセスルータ（２０２）が、
    前記ヘッダに含まれる前記気付けアドレスからロケーション情報がない気付けアドレスを変換規則によって導出し、
    前記ヘッダに含まれる前記気付けアドレスをロケーション情報のない前記気付けアドレスに置換することができるモバイル通信システム。
14. 複数のアクセスネットワークを備えるモバイル通信システムのアクセスルータ（２０２）であって、
    リターンルータビリティプロトコルパケット及びデータパケットを分析することができる分析手段と、
    前記リターンルータビリティパケット及びデータパケットのヘッダに含まれるアドレスであって、気付テスト開始メッセージ又はバインディング更新メッセージのインターネットプロトコルヘッダ内の気付けアドレスの少なくとも一部を取り除くことができる置換手段とを備え、
    前記置換手段が、前記ヘッダに含まれる前記気付けアドレスからロケーション情報がないアドレスを変換規則によって導出し、更に前記ヘッダに含まれる前記気付けアドレスをロケーション情報がないアドレスで更に置換することができ、
    前記分析手段及び置換手段が、分析し、取り除くことができる前記気付けアドレスの一部が、前記インターネットプロトコルのソースアドレスフィールドであるアクセスルータ（２０２）。
15. 前記置換手段が、前記気付アドレスを前記ヘッダ内に更に置換することができる請求項１４に記載のアクセスルータ。
16. 前記変換規則が、前記気付アドレスにビットを加えることを含む請求項１４に記載のアクセスルータ。