(57)【要約】【課題】モバイル・ノードがプライベートＨｏＡを有して構成されることが可能であるように、プロキシ・モバイルＩＰネットワーク内のローカル・モビリティ・アンカ（ＬＭＡ）がネットワーク・アドレス変換と協力してモバイル・ノードのためにアドレス割当を行うことができる方法を提供すること。【解決手段】一実施形態では、ＬＭＡは、（ｉ）ＩＰｖ４ホストとして動作しており、（ｉｉ）自分のホーム・ネットワークとしてのネットワークに入ろうとしているモバイル・ノード（ＭＮ）のＮＡＩを取得する。ＬＭＡは、ネットワーク内に配置されており、少なくとも１つのＮＡＴにサービスしているＤＨＣＰサーバを識別し、そのＤＨＣＰサーバに、ＣｌｉｅｎｔＩｄがモバイル・ノードのＮＡＩと等しく設定されている要求メッセージを送信する。ＬＭＡは、プライベートＨｏＡをＤＨＣＰサーバから受信し、そのプライベートＨｏＡをＰＢＡメッセージに入れて、ＭＮに接続されているモバイル・アクセス・ゲートウェイ（ＭＡＧ）に転送する。【選択図】図３
2010263622.tif 000002
【特許請求の範囲】
【請求項１】
プロキシ・モバイルＩＰネットワークに属するＬＭＡにより実行される方法であって、
（ｉ）ＩＰｖ４ホストとして動作し、（ｉｉ）自分のホーム・ネットワークとしてのネットワークに入ることを求める、モバイル・ノード（ＭＮ）のＮＡＩを取得するステップと、
（ｉ）前記ネットワーク内に配置され、（ｉｉ）少なくとも１つのＮＡＴにサービスする、ＤＨＣＰサーバに、ＤＨＣＰ要求を送信するステップを含み、前記ＤＨＣＰ要求は、ＣｌｉｅｎｔＩＤフィールドを含み、前記ＣｌｉｅｎｔＩＤフィールドは前記ＮＡＩと等しく設定され、さらに、
ＤＨＣＰ  Ａｃｋメッセージに入っているプライベートＨｏＡを前記ＤＨＣＰサーバから受信するステップと、
前記プライベートＨｏＡをプロキシ・バインディング確認応答（ＰＢＡ）メッセージに入れて、前記ＭＮに接続されているモバイル・アクセス・ゲートウェイ（ＭＡＧ）に送信するステップとを備える方法。
【請求項２】
前記ＬＭＡは、プロキシ・バインディング更新（ＰＢＵ）メッセージに入っている前記モバイル・ノード（ＭＮ）の前記ＮＡＩを前記ＭＡＧから取得する、請求項１に記載の方法。
【請求項３】
前記モバイル・ノード（ＭＮ）との間でパケットを転送するために前記ＭＡＧとＩＰｖ４  ＧＲＥトンネルを確立するステップをさらに備える、請求項１に記載の方法。
【請求項４】
前記モバイル・ノード（ＭＮ）との間でパケットを転送するために前記ＭＡＧとＩＰｖ６内ＩＰｖ４トンネルを確立するステップをさらに備える、請求項１に記載の方法。
【請求項５】
前記ＤＨＣＰサーバは、前記ＮＡＩによって判定された特定のＮＡＴにサービスする、請求項１に記載の方法。
【請求項６】
前記プライベートＨｏＡは、プライベート・ホーム・ネットワーク・プレフィックスである、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット・プロトコル（ＩＰ）ネットワークに関し、より具体的には、モバイルＩＰ（ＭＩＰ）をサポートするネットワークに関する。さらに具体的には、本発明は、プロキシＭＩＰネットワークにおいてモバイル・ノード（ＭＮ）を構成するための方法に関する。
【背景技術】
【０００２】
パケット交換ネットワークは、それぞれのホスト・アドレスだけに基づくアドレッシング構造を使用して発信元ホストから宛先ホストにパケットを配送するためにインターネット・プロトコル（ＩＰ）を使用する。現在最も広く使用されているアドレッシング構造は、ＩＰバージョン４（ＩＰｖ４）、およびその後継バージョン、つまりＩＰバージョン６（ＩＰｖ６）である。ＩＰｖ４は３２ビットのアドレスを使用するが、ＩＰｖ６は、６４ビットのプレフィックスと６４ビットのサフィックスに分割された１２８ビットのアドレスを使用する。ＩＰはリンク・レイヤ実装のための様々な技術を有するネットワークにまたがって使用するのに十分フレキシブルであるように設計されているので、ＩＰアドレスをデータ・リンク・アドレスに変換するためのプロトコルが提供される。このプロトコルは、ＩＰｖ４ネットワークにおいてはアドレス変換プロトコル（ＡＲＰ）であり、ＩＰｖ６ネットワークにおいては近隣発見プロトコル（ＮＤＰ）である。
【０００３】
初期のＩＰネットワークには固定ノードが関係していたが、移動している間ずっと、および実際には異なるサブネットまたは異なる無線システム間でローミングしている間ずっと、自分のインターネット接続を維持したいと思うユーザをサポートする必要性が増大している。モバイルＩＰは、モバイル・ノード（ＭＮ）がそのインターネットへの接続点を変えても変わらないホームＩＰアドレス（ＨｏＡ）を維持することができるようにするプロトコルである。モバイルＩＰでは、ＭＮが外部ネットワークに接続されている間ずっと、ＭＮのホーム・ネットワーク上のルータがＭＮの代理を引き受ける。
【０００４】
ＭＮは、外部ネットワークに接続する場合、気付アドレス（ＣｏＡ）を割り当てられる。ＭＮは、ＣｏＡをバインディング更新メッセージに入れて自分のホーム・エージェントに通知する。その結果、ホーム・エージェントと（自分のＣｏＡにある）ＭＮとの間に双方向トンネルがセットアップされる。次に、通信相手ノード（すなわち、議論中のＭＮ以外の任意のノード）がＭＮにパケットを送信したいと思う場合は、パケットをＨｏＡに宛てて送る。これらのパケットはホーム・エージェントに配送され、このホーム・エージェントはそれらのパケットをカプセル化し、双方向トンネルを介して自分のＣｏＡにあるＭＮに転送する。逆に、ＭＮが双方向トンネルを使用して通信相手ノードにパケットを送信することもできる。代替として、ＭＮは通信相手ノードに直接パケットを送信することもできるが、そうするための細かい手順がモバイルＩＰｖ４とモバイルＩＰｖ６との間で異なる。
【０００５】
プロキシ・モバイルＩＰ（ＰＭＩＰｖ６）は、モバイルＩＰと同様の機能を提供する比較的最近の規格であるが、これは、ＭＮに実装されているホストが、モビリティをサポートするように適応されるプロトコル変更を含む必要性をすべて取り除く。つまり、ＭＮの位置を追跡することを含めて、すべてのモビリティ・サポートはネットワークの固定側で実施される。具体的には、ＭＮは自分のＨｏＡを保持することが可能であり、追加のＣｏＡを有して構成される必要がない。（しかし、ＣｏＡは、以下で説明されるように、ネットワークの他の場所で使用される。）
【０００６】
ＰＭＩＰｖ６は、モビリティ・サポートのために２つの特別な機能を導入している。それらは、モビリティ・アクセス・ゲートウェイ（ＭＡＧ）およびローカル・モビリティ・アンカ（ＬＭＡ）である。アクセス・ルータ上でサポートされているモビリティ・アクセス・ゲートウェイ（ＭＡＧ）は、自分のアクセス・リンクに接続されているＭＮのためのモビリティ関連シグナリングを管理する。ＭＡＧは、ＭＮのアクセス・リンクへの出入りを追跡し、ＭＮのローカル・モビリティ・アンカ（ＬＭＡ）とシグナリング・メッセージを交換することによりＭＮのモビリティをサポートする。ＬＭＡは、プロキシ・モバイルＩＰｖ６領域内の、すなわち、ＰＭＩＰｖ６プロトコルを実装しているネットワーク内のＭＮのためのホーム・エージェントである。
【０００７】
ＰＭＩＰｖ６プロトコルは、ＭＮ内で実行しているモバイル・ホストがＰＭＩＰ領域に入り、アクセス・リンクに接続したときに開始される。それに続くトランザクションの簡単な要約が以下に提示されている。さらに詳細な説明は、S. Gundavalli, Ed., RFC 5213、「Proxy Mobile IPv6」、IETF Network Working Group（２００８年８月）、http://tools.ietf.org/html/rfc5213、特にセクション３、「Proxy Mobile IPv6 Protocol Overview」、９〜１５頁において見ることができる。
【０００８】
ＭＮがアクセス・リンクに接続した後に、アクセス・リンク上のＭＡＧはＭＮの識別を取得し、ＭＮがエントリを認可されているかどうか、すなわち、適切なネットワーク・ベースのモビリティ管理サービスを認可されているかどうかを判定する。認可が確認された場合は、ＭＮは、接続されたインターフェース上でアドレス構成を取得することが可能である。続いて、ネットワークによるサポートは、ＰＭＩＰ領域全体がＭＮには単一のリンクのように見えることを保証する。
【０００９】
ＭＮによって取得されたアドレス構成は、少なくとも１つのホーム・アドレス（ＨｏＡ）および接続されたリンク上のデフォルト・ルータ・アドレスを含む。ホーム・ネットワーク・プレフィックスは、ＭＮとＭＡＧとの間のリンクに割り当てられたプレフィックスである。ＨｏＡは、ＭＮのホーム・ネットワーク・プレフィックスからのアドレスである。ＭＮは、ＰＭＩＰ領域の範囲内にあるアクセス・ネットワークに接続されている限りこのアドレスを使用することが可能である。
【００１０】
モバイルＩＰｖ６とＰＭＩＰｖ６との間の１つの違いは、モバイルＩＰｖ６では、ホーム・エージェントがＭＮのホーム・アドレスを通知されることである。ＰＭＩＰでは、それとは対照的に、モビリティ・エンティティは、ＭＮのホーム・ネットワーク・プレフィックスを知ることを必要とされるが、必ずしも、ＭＮが自分のホーム・ネットワーク・プレフィックスから自分のインターフェース上で構成した正確なアドレスを知るわけではない。しかし、ＰＭＩＰモビリティ・エンティティが取得することができ、ＭＮを識別するために使用することができる、モバイル・ノード識別子（ＭＮ識別子）と呼ばれるＭＮの安定した識別子がある。ＭＮ識別子は、通常、ネットワーク・アクセス識別子（ＮＡＩ）、またはメディア・アクセス制御（ＭＡＣ）アドレスなどの他の何らかの識別子である。
【００１１】
普通のＩＰの場合およびモバイルＩＰの場合と同様に、アドレス構成情報を取得するために使用されるプロトコルは、ダイナミック・ホスト構成プロトコル（ＤＨＣＰ）である。ＤＨＣＰクライアントとして働くネットワーク・デバイスは、ＤＨＣＰサーバから、アドレスを含めて、ネットワークパラメータを取得する。したがって、例えば、ＭＮにあるＤＨＣＰクライアントは、ＭＡＧに実装されたＤＨＣＰサーバからアドレス情報を取得することが可能であり、あるいは代替として、ＬＭＡに実装されたＤＨＣＰサーバからアドレス情報を取得することも可能であり、ＬＭＡはＭＡＧに実装されたＤＨＣＰリレーを介してその情報を転送する。
【００１２】
ＰＭＩＰ領域に接続するモバイル・ノードは、ＩＰｖ４ノードでもＩＰｖ６ノードでもよく、あるいは二重機能を有してもよい。どのＩＰバージョンが適用可能かによって、ＭＮは、ＩＰｖ４アドレスまたはＩＰｖ６アドレス（あるいはさらに二重アドレス）を有して構成される。ＩＰｖ６トランスポート・ネットワークでは、ＩＰｖ４トラフィックを配送するためにＩＰｖ６内ＩＰｖ４トンネリングが提供されることが可能である。ＭＡＧとＬＭＡとの間でＩＰｖ４トランスポート・ネットワークが使用されている場合は、ＩＰｖ４内ＩＰｖ６トンネリングが実施される。
【００１３】
モバイルＩＰの場合と同様に、ＰＭＩＰネットワークもＬＭＡとＭＡＧとの間に双方向トンネルを確立する。ＬＭＡアドレス（ＬＭＡＡ）と呼ばれるグローバル・アドレスがトンネルの１つのトランスポート・エンドポイントとしてＬＭＡのインターフェース上で構成される。これは、ＭＡＧが、以下で論じられるプロキシ・バインディング更新（ＰＢＵ）メッセージを送信するアドレスである。
【００１４】
プロキシ気付アドレス（プロキシＣｏＡ）と呼ばれる他のグローバル・アドレスは、ＭＡＧの出口インターフェース上で構成される。このアドレスは、ＬＭＡとＭＡＧとの間の他方のトランスポート・エンドポイントである。ＬＭＡにとっては、これはＭＮの気付アドレスである。ＬＭＡは、このアドレスをＭＮのためのバインディング・キャッシュ・エントリに登録する。
【００１５】
この点に関して、「バインディング」は、（ＭＮの所与のインターフェースに割り当てられた）ＭＮのホーム・ネットワーク・プレフィックスをＭＮの現行のプロキシＣｏＡと関連付ける。そのような関連付けは、通常、限られたライフタイムを有する。所与のそのような関連付けの残りのライフタイムは、「バインディング」と呼ばれる情報に含まれることが可能である。バインディングは、ＭＡＧとＬＭＡとの間で交換されるプロキシ・バインディング・メッセージを介して確立される。より詳細には、ＭＡＧは、ＰＢＵをＬＭＡに送信することによりバインディングの確立を要求する。ＬＭＡは、プロキシ・バインディング確認応答（ＰＢＡ）をＭＡＧに送信することにより応答する。
【００１６】
上記のように、ＩＰｖ６は１２８ビットのアドレスを使用するが、一方、ＩＰｖ４は３２ビットのアドレスを使用する。ＩＰアドレスに対する高い需要のために、可能なパブリックＩＰｖ４アドレスの総空間は枯渇する傾向がある。この問題を軽減するための１つのやり方は、パブリックＩＰｖ４アドレスをローカルに共用することである。すなわち、例えば、プライベート・ネットワークの中の複数のノードは、外界に見える単一のパブリックＩＰアドレスを共用することができるが、そのプライベート・ネットワークの中では、インターネット上でグローバルにルーティング可能ではないプライベートＩＰアドレスを使用する。そのような構成では、パブリックＩＰアドレスは混乱なしに共用されることが可能である。プライベート・ネットワークとパブリック・ネットワークとの間のインターフェースにおいては、ネットワーク・アドレス変換（ＮＡＴ）ボックスまたはゲートウェイなどのネットワーク・エンティティは、プライベート・アドレス空間とパブリック・アドレス空間との間で変わる。
【００１７】
上記の理由で、とりわけ、プロキシ・モバイルＩＰｖ６ネットワークに接続するＩＰｖ４モバイル・ノードに１つまたは複数のプライベート・ホーム・アドレスを割り当てることが少なくともときどき望ましいであろう。ＰＭＩＰｖ６の仕様書ＲＦＣ５２１３は、そのようなアドレス割当を行うための手順を規定していない。しかし、この手順はいくつかの開発シナリオによって要求されることがある。
【先行技術文献】
【非特許文献】
【００１８】
【非特許文献１】S. Gundavalli, Ed., RFC 5213、「Proxy Mobile IPv6」、IETF Network Working Group（２００８年８月）、http://tools.ietf.org/html/rfc5213、特にセクション３、「Proxy Mobile IPv6 Protocol Overview」、９〜１５頁
【発明の概要】
【発明が解決しようとする課題】
【００１９】
我々は、モバイル・ノードがプライベートＨｏＡを有して構成されることが可能であるように、ＬＭＡがネットワーク・アドレス変換と協力してモバイル・ノードのためにアドレス割当を行うことができる方法を開発した。
【課題を解決するための手段】
【００２０】
一実施形態では、本発明は、プロキシ・モバイルＩＰネットワークに属するＬＭＡが、（ｉ）ＩＰｖ４ホストとして動作しており、（ｉｉ）自分のホーム・ネットワークとしてのネットワークに入ろうとしているモバイル・ノード（ＭＮ）のＮＡＩを取得する方法を提供する。ＬＭＡは、（ｉ）ネットワーク内に配置されており、（ｉｉ）少なくとも１つのＮＡＴにサービスしているＤＨＣＰサーバにＤＨＣＰ要求を送信し、ＤＨＣＰ要求は、ＣｌｉｅｎｔＩＤフィールドを含み、ＣｌｉｅｎｔＩＤフィールドは、ＮＡＩに等しく設定される。ＬＭＡは、ＤＨＣＰ  Ａｃｋメッセージに入っているプライベートＨｏＡをＤＨＣＰサーバから受信し、次いで、そのプライベートＨｏＡをプロキシ・バインディング確認応答（ＰＢＡ）メッセージに入れて、ＭＮに接続されているＭＡＧに送信する。
【図面の簡単な説明】
【００２１】
【図１】ＰＭＩＰｖ６がサポートされている例示的ネットワークの概略図である。図１のネットワークでは、ＭＡＧはＤＨＣＰサーバを実装している。
【図２】ＰＭＩＰｖ６がサポートされている代替ネットワークの概略図である。図２のネットワークでは、ＭＡＧはＤＨＣＰリレーを実装している。図１と共通の要素は、同様の参照数字が付けられている。
【図３】一実施形態において本発明を例示するメッセージ・フロー図である。図３に例示されている方法は、例えば図１に例示されているように、ＤＨＣＰサーバがＭＡＧ内に配置されているネットワークにおいて実施される。図１および図２と共通の要素は、たとえ異なるグラフィカル表示を有していても、同様の参照数字を付けられている。
【発明を実施するための形態】
【００２２】
ＲＦＣ５２１３に定義されているＰＭＩＰｖ６プロトコルは、モバイル端末が、ホスト変更なしに、自分のＩＰアドレスを保持し、中断されない継続したＩＰセッションを維持しながら、アクセス・ネットワークへのそれらの接続点をシームレスに変更することができるようにする。上記で説明されたように、ＰＭＩＰｖ６は、２つの機能ブロック、つまりモバイル・アクセス・ゲートウェイ（ＭＡＧ）およびローカル・モビリティ・アンカ（ＬＭＡ）を導入している。ＭＡＧは、ＭＮが接続される第１のルーティング・ホップである。ＭＡＧは、アドレス構成、およびＭＮからの／ＭＮへのデータ配送を支援する。ＭＡＧは、ＭＮとＬＭＡとの間でパケットをトンネリングし、ＭＩＰｖ４／６（ＲＦＣ３７７５）で規定されているホーム・エージェントの役割と同様の役割を果たす。ＬＭＡは、モビリティ・アンカである。ＬＭＡは、ホームＩＰアドレスをＭＮに割り当て、ＭＮと通信している通信相手ノードから送信されたインバウンド・トラフィックのためのエントリ・ポイントである。
【００２３】
ＰＭＩＰｖ６は、「モバイル・ノードごとのプレフィックス」と呼ばれる特定のプレフィックス・デリゲーション・モデルを使用する。すなわち、ＰＭＩＰｖ６領域に接続する各ＭＮは、モビリティ・セッションのライフタイムの間ずっと同じである一意のプレフィックスを割り当てられる。ＭＮは、（ＬＭＡにおいて）ホーム・リンク上で事実上接続されている。ＭＮの現在の位置へのデータグラムの適切な配送は、ＬＭＡとＭＡＧとの間のトンネリング（例えば、ＩＰｖ６内ＩＰｖ６）を介して達成される。ＬＭＡはまた、ＩＰｖ４  ＨｏＡをＭＮに配送することができる。ＩＰｖ６を介してのＩＰｖ４データグラムのトンネリングも可能である。
【００２４】
したがって、変更されていないＩＰｖ４ホストは、ＰＭＩＰｖ６領域に接続し、モビリティ・サポートを得ることができる。しかし、既存の規格では、特にオペレータがＬＭＡをキャリア・グレードＮＡＴ（ＣＧＮ）の背後に配備する場合、ＩＰｖ４モバイル・ホストにＨｏＡ（ホーム・アドレス）がどのように割り当てられるかに関する規定はなされていない。ＣＧＮは、顧客構内機器（ＣＰＥ）のプライベートＩＰアドレス、ポート、および識別子を、外部ＩＰアドレス、ポート、および識別子に変換するために、通常、ＣＰＥとパブリック・インターネットとの間にネットワーク・オペレータによって配置されるＮＡＴデバイスである。ＬＭＡがＣＧＮの背後にある場合には、ＣＧＮは、オペレータがＭＮにプライベートＨｏＡを割り当て、複数のモバイル加入者間でパブリックＩＰアドレスを共用することができるようにする。したがって、ＣＧＮが配備されているＰＭＩＰｖ６領域に接続するＩＰｖ４  ＭＮに適切なプライベートＨｏＡを割り当てる方法の必要性が依然として残っている。
【００２５】
次に、図１を参照すると、例示的ネットワークは、ホーム接続サービス・ネットワーク（ＨＣＳＮ）４０にリンクＲ３によって接続されたアクセス・サービス・ネットワーク（ＡＳＮ）３０にリンクＲ１によって接続されたモバイル・ノード１０を含む。破線として示されているリンクＲ２は、ＭＮとＨ＿ＡＡＡ（ホーム認証オーソリティ）との間の認証関係を構成するために使用される論理リンクである。これはネットワーク・エントリ中に使用される。ＮＡＴボックス１００の外で、ＨＣＳＮ４０は外部インターネットに接続される。
【００２６】
モバイル・ノードにおいては、ＭＡＧに向けられたＤＨＣＰクライアント２０が実装されており、これは、とりわけ、自分のＨｏＡを有するＭＮの構成を可能にする。
【００２７】
ＡＳＮ３０は、リンクＲ６によってＭＡＧ７０に接続された基地局６０を含む。図示されているように、ＭＡＧは、アクセス・ルータ（ＡＲ）、およびモバイル・ノードにあるＤＨＣＰクライアントに向けられたＤＨＣＰサーバ８０と一緒に配置されている。
【００２８】
ＨＣＳＮ４０は、ＬＭＡ９０、ＮＡＴボックス１００、およびＡＡＡサーバ１３０を含む。ＬＭＡは、ＮＡＴボックスに向けられたＤＨＣＰクライアント１１０と一緒に配置され、ＮＡＴボックスは、ＤＨＣＰクライアント１１０に向けられたＤＨＣＰサーバ１２０と一緒に配置されている。
【００２９】
次に、図２を参照すると、そこに示されているネットワークは、（ＤＨＣＰサーバの代わりに）ＤＨＣＰリレーがＭＡＧと一緒に配置され、ＬＭＡが、ＮＡＴボックスに向けられたＤＨＣＰクライアントおよびＡＳＮ内のＤＨＣＰリレーに向けられたＤＨＣＰサーバの両方と一緒に配置されていること以外は、図１のネットワークと同様である。
【００３０】
我々の新規の方法は、ＬＭＡ９０がＮＡＴトポロジに応じてＭＮ１０のためのアドレス割当を行うことを可能にする。ＬＭＡ９０がＭＡＧ７０からＰＢＵを受信した場合、ＬＭＡはＭＮに割り当てられるべきＨｏＡを選択する（ＬＭＡは、実際には、ホーム・ネットワーク・プレフィックスしか選択することができない）。この点に関して使用された場合、用語ＨｏＡは、本明細書では、フルＨｏＡまたはホーム・ネットワーク・プレフィックスのどちらかを意味するものとする。このＨｏＡは、上記のようにＤＨＣＰサーバ１２０に向いているＬＭＡ内のＤＨＣＰクライアント１１０を介して取り出される。ＤＨＣＰサーバ１２０は、ＮＡＴボックス１００内に実装されてもよい。
【００３１】
ＬＭＡ９０は、ＤＨＣＰ要求に含まれるべきＣｌｉｅｎｔＩＤの値としてＭＮ１０のＮＡＩを使用する。ＬＭＡ９０が複数のＮＡＴに接続されている場合は、ＬＭＡ９０は、アドレス要求にサービスするのに最も適したＮＡＴを選択するために、ＰＢＵで受信されたＮＡＩを使用することができる。以下の要因のいずれか、とりわけ、ＭＮプロフィール、サービス要件、およびそれぞれの利用可能なＮＡＴボックスの現在の負荷に基づいて、異なるＮＡＴボックスが選択されることが可能である。適用可能な選択要因を条件として、ＬＭＡは、例えば、特定の種類のアプリケーションを可能にするＮＡＴボックスにアドレスを要求することができる。
【００３２】
図１のネットワークでは、（上記のように、ＭＡＧ７０と一緒に配置され、ＭＮにあるＤＨＣＰクライアントに向いている）ＤＨＣＰサーバ８０が、ＬＭＡ９０とのＰＢＵ／ＰＢＡ交換に従事することによりモバイル・ノードのＮＡＩに関連するプライベート・ホーム・アドレス（ＨｏＡ−ｐｒｉｖ）を取得する。ＤＨＣＰサーバ８０は、ＮＡＩによって識別されたモバイル・ノードとの次に続くＤＨＣＰ交換中にＨｏＡ−ｐｒｉｖを返す。
【００３３】
それとは対照的に、図２のネットワークでは、（上記のように、ＭＡＧ７０と一緒に配置され、ＭＮにあるＤＨＣＰクライアント２０およびＬＭＡにあるＤＨＣＰサーバ１１５に向いている）ＤＨＣＰリレー８５がモバイルとのＤＨＣＰ交換をＬＭＡ９０に向けて中継する。次に、ＬＭＡがモバイル・ノードのＮＡＩに基づいてＰＢＵ／ＰＢＡ交換によってＨｏＡ−ｐｒｉｖ割当を行う。
【００３４】
次に、図３を参照しながら、図１のネットワークなどのネットワークにおいて実行される我々の発明の一実施形態によるメッセージ・フローを説明する。当業者は理解するであろうように、とりわけ、ＷｉＭａｘネットワークおよびＷｉＦｉネットワークは、この点に関して有用であり得るネットワークのタイプの例である。
【００３５】
要素２００において、ＭＮ１０がネットワーク・インターフェース上でパワーオンされ、ネットワーク・エントリを行う。要素２１０において、レイヤ２接続およびＭＮ検出が行われ、ＭＡＧ７０がモバイル・ノード識別子としてのＮＡＩを含むＰＢＵメッセージをＬＭＡ９０に送信する。上記ＰＢＵメッセージは、ＭＮリンク・レイヤ識別子、ハンドオーバ指示、およびアクセス技術タイプを含む。
【００３６】
ＬＭＡは、ＰＢＵを受信するとすぐ、ＭＮ１０がＰＭＩＰｖ６サービスを取得することができるようにされていることを検証し、ＨｏＡを割り当てる。
【００３７】
より詳細には、ＬＭＡ９０は、ホーム・ネットワーク内に配置されているサーバ１２０などのＤＨＣＰサーバに問い合わせることによりプライベートＨｏＡ（ＨｏＡ−ｐｒｉｖ）を取得し、１つまたは複数のＮＡＴにサービスする。ＤＨＣＰハンドシェイク（図の要素２２１〜２２４）のために使用されるＣｌｉｅｎｔＩＤは、ＮＡＩである。（ＮＡＩは、単独に使用されてもよく、または、例えば、リンク・レイヤ識別子およびアクセス技術タイプなどのパラメータと併せて使用されてもよい。）
【００３８】
ＮＡＩのための標準的なシンタックスは、「ｕｓｅｒ＠ｒｅａｌｍ」である。したがって、ＮＡＩに含まれる特定の領域は、ＤＨＣＰ要求を特定のＤＨＣＰサーバに送信するために使用されることが可能である。その結果として、ＮＡＴ選択は、ＮＡＩの特定の値に応答するやり方で行われることが可能である。
【００３９】
要素２２１（ＤＨＣＰ発見）および要素２２２（ＤＨＣＰオファ）として図に示されているＤＨＣＰ発見フェーズは、ＤＨＣＰサーバ・アドレスが知られていない場合に実施される。そうでなければ、ＤＨＣＰハンドシェイクは、要素２２３（モバイル・ノードのＮＡＩに等しく設定されたＣｌｉｅｎｔＩＤを含むＤＨＣＰ要求）、および要素２２４（ＨｏＡ−ｐｒｉｖを含むＤＨＣＰ  ａｃｋ）から成る。
【００４０】
要素２３０において、ＬＭＡ９０がＤＨＣＰサーバ１２０からＤＨＣＰ  ａｃｋに入っているＨｏＡ−ｐｒｉｖを受信し、次に、ＬＭＡがＰＢＡメッセージをＭＡＧ７０に送信する。このＰＢＡメッセージは、ＬＭＡにおいてアンカされ、正規のＡＲＰプロキシ機構を使用して正しいＣＧＮを介してルーティングされるＨｏＡ−ｐｒｉｖを含む。言い換えれば、ＬＭＡ９０は、アドレス・ペア（ＨｏＡ−ｐｒｉｖ、ＬＭＡｍａｃ＠）のためのＡＲＰ−ｐｒｏｘｙの役割を実行する。ＣＧＮの観点から、モバイルＩＰアドレス（ＨｏＡ−ｐｒｉｖ）は、ＬＭＡ  ＭＡＣアドレス（ＬＭＡｍａｃ＠）にバインディングされる。ＬＭＡによるこのプロキシ動作の結果は、ＣＧＮにとって、モバイルが自分のホーム・ネットワーク上にあるように見えることであり、他方、モバイル向けパケットは、ＣＧＮによってＬＭＡのＭＡＣアドレスに転送される。次いで、ＬＭＡは、パケットをＭＡＧに向けてトンネリングする。ＩＰ外部ネットワークに対しては、ＭＮは、所与の時間にＣＧＮによって割り当てられたパブリックＩＰアドレスを使用して表示される。
【００４１】
再度図３を参照すると、要素２４１〜２４４において、ＨｏＡ−ｐｒｉｖを含むＰＢＡがＭＡＧ７０によって受信された後に、モバイル・ノードは、無線インターフェース上でＩＰｖ４アドレスを構成するために標準的ＤＨＣＰメッセージ交換を行うことが分かる。このメッセージ交換は、ＤＨＣＰ発見（要素２４１）メッセージおよびオファ（要素２４２）メッセージを含んでもよく、要求（要素２４３）メッセージおよびａｃｋ（要素２４４）メッセージを常に含む。図に示されているように、オファ・メッセージ、要求メッセージ、およびａｃｋメッセージは、引数としてＨｏＡ−ｐｒｉｖを含む。
【００４２】
設定されたプロトコルによって、図３の要素２２４においてＬＭＡに配送されるＨｏＡ−ｐｒｉｖは、リース時間と呼ばれる定義された時間の長さのために割り当てられることに留意されたい。時間の長さは、有限でも無限（すなわち、非限定的）でもよい。図の要素２３０において、ＬＭＡ９０によってＭＡＧ７０にＰＢＡに入れて送信されたバインディングは、ホーム・アドレスのリース時間と等しく設定されたライフタイムを有する。次いで、モバイル・ノードにおいてホーム・アドレスが構成される場合、ホーム・アドレスは上記リース時間を有して構成される。
【００４３】
図３の下部に示されているように、上記で説明された動作によって、ＭＡＧ７０とＬＭＡ９０との間にトンネル２６０が設定されることになる。基礎となるネットワークのアドレッシング構造に応じて、このトンネル内のトランスポートは、例えば、ＩＰｖ４  ＧＲＥでも、またはＩＰｖ６内ＩＰｖ４でもよい。しかし、モバイル・ノードとＭＡＧとの間の最後のリンク上のパケットはトンネリングされない。（本明細書に記載されている場合、これらはネイティブＩＰｖ４パケットである。）その代わりに、それらは、要素２５０において示されているように、ＭＡＧとＭＮとの間のアクセス・ネットワークによって実装された普通のレイヤ２機構を使用して配送される。図の要素２８０において示されているように、ＮＡＴボックス（例えば、ＣＧＮでよい）は、ネットワークのパブリック側２９０とプライベート側２７０との間でアドレス変換を行う。
【００４４】
ＭＮはネットワークにおいて生じているいかなるＰＭＩＰｖ６／ＮＡＴ動作にも気づいていないことに留意されたい。必要な場合は、ＭＮはＮＡＴ発見のための標準的な動作（ＳＴＵＮなど）を行うことができる。すなわち、データ交換においてＩＰアドレスを使用するいくつかのアプリケーションがあるので、ＭＮは、いくつかの場合には、アプリケーション・レベルで自分のＩＰアドレスを処理する必要があることもある。ＩＰアドレスがプライベートの類のものである場合は、そのようなアプリケーションは、自給自足ではなく、ＣＧＮによってプライベート・アドレスに現在マッピングされているパブリックＩＰアドレスを発見するためにインターネット上の他のパブリック・サーバに依拠する。例えば、ＳＴＵＮサーバおよびプロトコルは、その目的のためにしばしば有用である。本明細書に記載している手法は、そのようなプロトコルの使用にとって明瞭であり、したがって、そのようなアプリケーションにも適合する。
【図１】
2010263622.tif 000003
【図２】
2010263622.tif 000004
【図３】
2010263622.tif 000005
【外国語明細書】
2010263622.tif 000006
2010263622.tif 000007
2010263622.tif 000008
2010263622.tif 000009
2010263622.tif 000010
2010263622.tif 000011
2010263622.tif 000012
2010263622.tif 000013
2010263622.tif 000014
2010263622.tif 000015
2010263622.tif 000016
2010263622.tif 000017
2010263622.tif 000018
2010263622.tif 000019
2010263622.tif 000020