(57)【要約】  モバイルルータが実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにする技術が開示され、その技術によればＭＲ（モバイルルータ２０）からＣＮ３０（コレスポンデントノード）に対して、モバイルネットワークプレフィックスの登録が行われる際に、例えばＨＡ（ホームエージェント）１０が、この登録に係るシグナリングを介入して、誤ったプレフィックス情報の登録が行われないようにする。ＨＡは、例えばプロセス１５０において、ＭＲがプレフィックス情報を通知してＣＮからＭＲに送信されるテストメッセージ１２０を検出し、そのあて先アドレスに使用されているプレフィックス情報が有効なものであるか否かを確認する。そして、プレフィックス情報が無効なものである場合には、このパケットの破棄を行う。
2008155888.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークプレフィックス情報が割り当てられている通信装置と、前記通信装置又は前記ネットワークプレフィックス情報で特定されるネットワークに接続されているノードと通信を行うコレスポンデントノードとの間で伝送されるパケットを特定するパケット特定手段と、
前記パケット特定手段で特定された前記パケットを参照して、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して有効な値が使用されているか否かを判断するプレフィックス情報判断手段とを、
有するプレフィックス情報確認装置。
【請求項２】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると前記プレフィックス情報確認手段によって判断された場合に、その判断対象となった前記パケット特定手段で特定された前記パケットを破棄するパケット破棄手段を有する請求項１に記載のプレフィックス情報確認装置。
【請求項３】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると判断されて、その判断対象となった前記パケットが前記パケット破棄手段で破棄された場合には、その旨を前記通信装置に通知するパケット破棄通知手段を有する請求項２に記載のプレフィックス情報確認装置。
【請求項４】
前記プレフィックス情報判断手段における判断結果を前記コレスポンデントノードに通知する判断結果通知手段を有する請求項１に記載のプレフィックス情報確認装置。
【請求項５】
前記パケット特定手段が、前記ネットワークプレフィックス情報が前記通信装置から前記コレスポンデントノードに通知される際に交換されるパケットを特定するように構成されている請求項１に記載のプレフィックス情報確認装置。
【請求項６】
前記パケット特定手段が、前記コレスポンデントノードから前記通信装置に送信される前記パケットを特定するように構成されている請求項５に記載のプレフィックス情報確認装置。
【請求項７】
前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている請求項６に記載のプレフィックス情報確認装置。
【請求項８】
前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が、抽出された前記プレフィックス情報を参照して判断を行うように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項９】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記パケット特定手段が、前記プレフィックス情報の末尾の１の値を特定することによって前記プレフィックス情報を抽出するように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項１０】
前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報の長さを示す情報を抽出して、前記プレフィックス情報の長さに基づいて前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項１１】
前記パケット特定手段が、前記パケットのあて先アドレスに特定のビットパターンが含まれている前記パケットを特定するように構成されている請求項６に記載のプレフィックス情報確認装置。
【請求項１２】
前記特定のビットパターンを定めるビットパターン設定手段と、
前記特定のビットパターンが前記パケットのあて先アドレスに設定されるように、前記通信装置又は前記コレスポンデントノードに前記特定のビットパターンを通知するビットパターン通知手段とを、
有する請求項１１に記載のプレフィックス情報確認装置。
【請求項１３】
前記パケット特定手段が、前記通信装置から前記コレスポンデントノードからに送信される前記パケットを特定するように構成されている請求項５に記載のプレフィックス情報確認装置。
【請求項１４】
前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値か否かを判断するように構成されている請求項１３に記載のプレフィックス情報確認装置。
【請求項１５】
前記通信装置が、モバイルネットワークを有するモバイルルータであり、前記ネットワークプレフィックス情報が、前記モバイルネットワークを特定するモバイルネットワークプレフィックスである請求項１に記載のプレフィックス情報確認装置。
【請求項１６】
前記通信装置が、ネットワークベースでモビリティサポートを行うローカルモビリティ管理ドメイン内を移動している移動端末であり、前記ネットワークプレフィックス情報が、前記ローカルモビリティ管理ドメインから前記移動端末にユニークに割り当てられたネットワークプレフィックスである請求項１に記載のプレフィックス情報確認装置。
【請求項１７】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームアドレスと関連付けて登録する気付プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項１８】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームプレフィックスと関連付けて登録する気付プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項１９】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記ネットワークプレフィックス情報が、前記ホームドメインから割り当てられるホームプレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項２０】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記通信装置が、前記ネットワークプレフィックス情報が、前記ホームアドレスから割り当てられるホームプレフィックスとして使用する第１プレフィックス、及び、前記ホームプレフィックスに関連付けて登録する気付プレフィックスとして使用する第２プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項２１】
前記第１プレフィックス及び前記第２プレフィックスが第３プレフィックスとして結合可能なように構成されており、前記第３プレフィックスに関して処理を行うことで前記ホームプレフィックス及び前記気付プレフィックスの両方に関して有効な値が使用されているか否かの確認をまとめて行う請求項２０に記載のプレフィックス情報確認装置。
【請求項２２】
ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記ネットワークプレフィックス情報の長さを示す情報を含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２３】
ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記テストメッセージであることを示す特定のビットパターンを含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２４】
前記テストメッセージであることを示すために使用可能な前記特定のビットパターンの通知を受けるビットパターン受信手段と、
前記ビットパターン受信手段で受信した前記特定のビットパターンの真正性を確認するビットパターン真正性確認手段とを、
有する請求項２３に記載の通信装置。
【請求項２５】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記通信装置から、前記通信装置に対して割り当てられているネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報の末尾の値が１であることを確認するように構成されている通信装置。
【請求項２６】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられているネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに、前記アドレスプレフィックスの後続のビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２７】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに末尾のビットが１に設定され、残りのビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークなどのパケット交換型データ通信ネットワークにおけるネットワークを特定するプレフィックス情報の確認を行うプレフィックス情報確認装置及び通信装置に関し、特に、モバイルネットワークを有するモバイルルータが有しているモバイルネットワークのプレフィックス（モバイルネットワークプレフィックス）の確認を行うプレフィックス情報確認装置及び通信装置に関する。
【背景技術】
【０００２】
現在、多数のデバイスが、インターネットプロトコルを使用して、互いに通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、下記の非特許文献１において、ＩＰｖ６におけるモビリティサポートが規定されている。モバイルＩＰでは、各モバイルノードは、不変のホームドメインを持っている。モバイルノードが、自身のホームネットワークに接続している場合、モバイルノードには、ホームアドレス（ＨｏＡ：Home Address）として知られるプライマリグローバルアドレスが割り当てられる。一方、モバイルノードがホームネットワークから離れている場合、すなわち、他のフォーリンネットワークに接続している場合には、通常、モバイルノードには、気付アドレス（ＣｏＡ：Care-of Address）として知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートの考えは、モバイルノードが他のフォーリンネットワークに接続している場合でも、自身のホームアドレスで、そのモバイルノードまで到達可能となるようにするものである。【０００３】
このような考えは、非特許文献１において、ホームエージェント（ＨＡ：Home Agent）と呼ばれるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）メッセージを使用して、ホームエージェントへの気付アドレスの登録を行う。これにより、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスに向けられたメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。【０００４】
一方、個々のホストに関連したモビリティサポートの概念を、ノードを含むネットワーク用のモビリティサポートに拡張するネットワークモビリティ（ＮＥＭＯ：Network Mobility）サポートの考え方が存在している。このネットワークモビリティサポートは、モバイルネットワークがインターネットに対してどの接続ポイントで接続している場合でも、プライマリグローバルアドレスによってモバイルネットワーク内のノードに到達可能となる機構の提供を目的としている。【０００５】
また、下記の非特許文献２ではネットワークモビリティに対する解決策が提案されている。ここでは、モバイルルータがホームエージェントに対してＢＵメッセージを送信する際に、モバイルルータによって、モバイルネットワーク内のノードが使用しているネットワークプレフィックスが指定される。このネットワークプリフィックスは、ＢＵに挿入されるネットワークプリフィックスオプションとして知られる特別なオプションを使用して指定される。これにより、ホームエージェントは、プレフィックスに基づくルーティングテーブルを構築し、その結果、ホームエージェントは、こうしたプレフィックスを有するあて先に送信されるパケットを、モバイルルータの気付アドレスとの間で確立されたトンネルに転送することが可能となる。【０００６】
上記の技術によれば、モバイルルータが接続されている接続ポイントの位置にかかわらず、モバイルネットワークはインターネットに対して到達可能な状態となる。しかしながら、この際、モバイルネットワークから送受信されるパケットは、モバイルルータとそのホームエージェントとの間のトンネルを経由するため、ルーティングは完全に最適化された状態ではない。【０００７】
この状態に対処するためには、例えば、ＮＥＭＯベーシック仕様を拡張して、コレスポンデントノード（ＣＮ：Correspondent Node）に、モバイルネットワークのネットワークプレフィックス（モバイルネットワークプレフィックス）が通知されるようにすればよい。モバイルネットワークプレフィックスの通知は、例えば、モバイルルータからコレスポンデントノードに送信されるＢＵメッセージに、モバイルネットワークプレフィックスの挿入が可能なネットワークプレフィックスオプションを追加することによって実現される。【０００８】
しかしながら、ＢＵメッセージにネットワークプレフィックスオプションを追加するだけではセキュリティに問題が生じる。すなわち、モバイルＩＰｖ６では、モバイルノードは、経路最適化を行う際にコレスポンデントメッセージにＢＵメッセージを送信するために、事前にリターンルータビリティ（ＲＲ：Return Routability）処理を行って、ＢＵメッセージに記載するホームアドレス及び気付アドレスの正当な所有者であることを立証しなければならない。しかしながら、リターンルータビリティ処理では、ネットワークプレフィックスオプションに記載されるプレフィックスを所有している旨を立証することができない。【０００９】
一方、これに対して、例えば下記の特許文献１には、ＸＲＲＰ（Extended Return Routability Procedure：拡張リターンルータビリティ処理）が開示されている。このＸＲＲＰでは、コレスポンデントノードにＭＮＴＩ（Mobile Network Test Init：モバイルネットワークテストイニット）メッセージが送信され、コレスポンデントノードがこのメッセージに対して暗号化トークンを返信する。そして、モバイルルータは、この暗号化トークンを取得し、この暗号化トークンに基づいて、ＢＵメッセージのトークンを拡張した情報を作成し、送信することによって、このモバイルルータによってモバイルネットワークプレフィックスが所有されていることが立証される。【００１０】
また、下記の特許文献２には、ＲＲＮＰ（Return Routability for Network Prefix：ネットワークプレフィックスに対応したリターンルータビリティ処理）と呼ばれる方法が開示されている。このＲＲＮＰでは、コレスポンデントノードから、特定のモバイルネットワークプレフィックスに属するアドレスに暗号化トークンが送信される。そして、モバイルルータは、この暗号化トークンを受信（intercept）し、ＢＵメッセージにこの暗号化トークン（あるいは、暗号化トークンから得られる情報）を挿入する。
【特許文献１】米国特許公開２００６／１２０３１５
【特許文献２】国際公開公報ＷＯ２００６／００６７０６
【特許文献３】国際公開公報ＷＯ２００６／１１８３４２
【特許文献４】国際公開公報ＷＯ２００８／０２３８４５
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Devarapalli, V., et. al., "NEMO Basic Support Protocol", Internet Engineering Task Force Request For Comments 3963, January 2005.
【００１１】
しかしながら、特許文献１や特許文献２に開示されている方法は、ネットワークのプレフィックスの所有を検証するためにモバイルＩＰｖ６のリターンルータビリティ処理を拡張したものであるが、必ずしも十分な検証とは言えない。【００１２】
ここでは、モバイルルータがその所有を主張しているネットワークプレフィックスから選択されたアドレス（１つ又はいくつかのアドレス）に対してのみ、暗号化トークンの送信が行われることになる。すなわち、ネットワークプレフィックスに属するすべてのアドレスに関して検証されるわけではない。【００１３】
例えば、６４ビット長のプレフィックスＰが割り当てられているモバイルルータが、コレスポンデントノードに対して、少し短い長さ（例えば、６０ビット長）のプレフィックス（すなわち、プレフィックスＰの６０ビットまでの部分）を所有していると主張（申告）することが可能である。このとき、コレスポンデントノードは、モバイルルータがその所有を主張しているプレフィックス（６０ビット長）からアドレスを選択して暗号化トークンの送信を行うが、ここで選択されるアドレスが、モバイルルータに実際に割り当てられているプレフィックスＰ（６４ビット長）を含んでしまう可能性はゼロではない。【００１４】
そして、コレスポンデントノードが、モバイルルータに実際に割り当てられているプレフィックスＰ（６４ビット長）を含むアドレスを選択して送信を行った場合には、モバイルルータは暗号化トークンを取得して、プレフィックス（６０ビット長）を登録することができてしまい、モバイルルータが実際に所有しているプレフィックスＰ（６４ビット長）よりも大きいアドレス範囲を有するプレフィックス（６０ビット長）がモバイルルータに乗っ取られてしまうことになる。【００１５】
一方、特許文献３に開示されている技術によれば、モバイルネットワークプレフィックスの所有に関して、完全な検証を行うことが可能である。しかしながら、この技術では、プレフィックスの所有権を認定する証明書を配布することが可能な信頼できる装置（アンカ）を、モバイルネットワークが存在するすべてのドメインに配置しなければならず、システムを大幅に拡張しなければならないという問題がある。【００１６】
また、気付アドレスが送信元アドレスに存在していないバインディングアップデートをホームエージェントへ送信する場合に関しても、ホームエージェントが気付アドレスを検証する技術（例えば、特許文献４に開示されているような技術）が存在している。しかしながら、こうした処理においても、ネットワークプレフィックスオプションに記載されたプレフィックスの所有権は十分に立証されない。
【発明の開示】
【００１７】
上記の問題に鑑み、本発明は、ネットワークプレフィックス情報を所有している通信装置（モバイルルータや移動端末など）が実際には管理していないプレフィックス情報（ネットワークプレフィックス、あるいはモバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることを目的とする。
【００１８】
上記の目的を達成するため、本発明のプレフィックス情報確認装置は、ネットワークプレフィックス情報が割り当てられている通信装置と、前記通信装置又は前記ネットワークプレフィックス情報で特定されるネットワークに接続されているノードと通信を行うコレスポンデントノードとの間で伝送されるパケットを特定するパケット特定手段と、
前記パケット特定手段で特定された前記パケットを参照して、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して有効な値が使用されているか否かを判断するプレフィックス情報判断手段とを、
有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置（モバイルルータや移動端末など）が実際には管理していないプレフィックス情報（ネットワークプレフィックス、あるいはモバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００１９】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると前記プレフィックス情報確認手段によって判断された場合に、その判断対象となった前記パケット特定手段で特定された前記パケットを破棄するパケット破棄手段を有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録に係るパケットが伝送されないようにすることが可能となる。
【００２０】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると判断されて、その判断対象となった前記パケットが前記パケット破棄手段で破棄された場合には、その旨を前記通信装置に通知するパケット破棄通知手段を有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置は、有効ではないプレフィックス情報が利用されている理由でパケットが破棄された旨を明確に把握することが可能となる。
【００２１】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段における判断結果を前記コレスポンデントノードに通知する判断結果通知手段を有する。
この構成により、有効なプレフィックス情報が使用されている旨、又は有効ではないプレフィックス情報が使用されている旨をコレスポンデントノードに明確に通知することが可能となる。
【００２２】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記ネットワークプレフィックス情報が前記通信装置から前記コレスポンデントノードに通知される際に交換されるパケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２３】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記コレスポンデントノードから前記通信装置に送信される前記パケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２４】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２５】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットのあて先アドレスに含まれているプレフィックス情報に基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２６】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記パケット特定手段が、前記プレフィックス情報の末尾の１の値を特定することによって前記プレフィックス情報を抽出するように構成されている。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００２７】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報の長さを示す情報を抽出して、前記プレフィックス情報の長さに基づいて前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００２８】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに特定のビットパターンが含まれている前記パケットを特定するように構成されている。
この構成により、あて先アドレスに基づいて、プレフィックス情報が含まれているパケットが容易に特定できるようになる。
【００２９】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記特定のビットパターンを定めるビットパターン設定手段と、
前記特定のビットパターンが前記パケットのあて先アドレスに設定されるように、前記通信装置又は前記コレスポンデントノードに前記特定のビットパターンを通知するビットパターン通知手段とを、
有する。
この構成により、プレフィックス情報確認装置が、動的に特定のビットパターンを設定することが可能となる。
【００３０】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記通信装置から前記コレスポンデントノードからに送信される前記パケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３１】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が、前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００３２】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記通信装置が、モバイルネットワークを有するモバイルルータであり、前記ネットワークプレフィックス情報が、前記モバイルネットワークを特定するモバイルネットワークプレフィックスである。
この構成により、モバイルルータが実際には管理していないプレフィックス情報（モバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３３】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記通信装置が、ネットワークベースでモビリティサポートを行うローカルモビリティ管理ドメイン内を移動している移動端末であり、前記ネットワークプレフィックス情報が、前記ローカルモビリティ管理ドメインから前記移動端末にユニークに割り当てられたネットワークプレフィックスである。
この構成により、ネットワークベースのローカルモビリティ管理によってネットワークプレフィックス情報が割り当てられている移動端末が、実際には管理していないプレフィックス情報（ネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３４】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームアドレスと関連付けて登録する気付プレフィックスである。
この構成により、移動端末が外部（ホームではない）のローカルモビリティ管理ドメインから取得したプレフィックスを気付プレフィックスとしてホームアドレスに関連付ける場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３５】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームプレフィックスと関連付けて登録する気付プレフィックスである。
この構成により、移動端末が外部（ホームではない）のローカルモビリティ管理ドメインから取得したプレフィックスを気付プレフィックスとしてホームプレフィックスに関連付ける場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３６】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記ネットワークプレフィックス情報が、前記ホームドメインから割り当てられるホームプレフィックスである。
この構成により、移動端末がホームのローカルモビリティ管理ドメインから取得したプレフィックスをホームプレフィックスとして使用する場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３７】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記通信装置が、前記ネットワークプレフィックス情報が、前記ホームアドレスから割り当てられるホームプレフィックスとして使用する第１プレフィックス、及び、前記ホームプレフィックスに関連付けて登録する気付プレフィックスとして使用する第２プレフィックスである。
この構成により、移動端末がホームのローカルモビリティ管理ドメインから取得した２つのプレフィックスをそれぞれホームプレフィックス及び気付プレフィックスとして関連付けて使用する場合に、これらのプレフィックスの真正性を確認することが可能となる。
【００３８】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記第１プレフィックス及び前記第２プレフィックスが第３プレフィックスとして結合可能なように構成されており、前記第３プレフィックスに関して処理を行うことで前記ホームプレフィックス及び前記気付プレフィックスの両方に関して有効な値が使用されているか否かの確認をまとめて行う。
この構成により、例えば、連続した値を有するプレフィックスをホームプレフィックス及び気付プレフィックスとすることで、プレフィックスの真正性の確認の際には、これらのプレフィックスをまとめて１つのプレフィックスとして取り扱えるようになり、メッセージ数の削減やネットワークトラフィックの低減、各ノードにおける処理負荷の軽減などが実現されるようになる。
【００３９】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記ネットワークプレフィックス情報の長さを示す情報を含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００４０】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記テストメッセージであることを示す特定のビットパターンを含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスに基づいて、プレフィックス情報が含まれているパケットが容易に特定できるようになる。
【００４１】
さらに、本発明の通信装置は、上記の構成に加えて、前記テストメッセージであることを示すために使用可能な前記特定のビットパターンの通知を受けるビットパターン受信手段と、
前記ビットパターン受信手段で受信した前記特定のビットパターンの真正性を確認するビットパターン真正性確認手段とを、
有する。
この構成により、テストメッセージに使用するために通知された特定のビットパターンが正当なものであるか否かを確認することができるようになる。
【００４２】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報の末尾の値が１であることを確認するように構成されている。
この構成により、プレフィックス情報が、ネットワークプレフィックス情報を所有している通信装置が本当に所有しているネットワークに割り当てられているプレフィックス情報か否かを識別できるようになる。
【００４３】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに、前記アドレスプレフィックスの後続のビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００４４】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに末尾のビットが１に設定され、残りのビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになるとともに、ルータエニキャストアドレスとの重複を避けることが可能となる。
【００４５】
本発明は、上記の構成を有しており、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにするという効果を有している。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施の形態において、モバイルルータとコレスポンデントノードとの間で行われる一般的な経路最適化シグナリング処理の一例を示すシーケンスチャート
【図２】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第１の例を示すフローチャート
【図３Ａ】本発明の実施の形態において使用されるあて先アドレスの第１の例を示す図
【図３Ｂ】本発明の実施の形態において使用されるあて先アドレスの第２の例を示す図
【図４】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第２の例を示すフローチャート
【図５】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第３の例を示すフローチャート
【図６】本発明の実施の形態において、ホームエージェントがテストパケットに挿入される特別なビットパターンを動的に設定する場合の処理の一例を示すシーケンスチャート
【図７】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第４の例を示すフローチャート
【図８】本発明の実施の形態において使用されるあて先アドレスの第３の例を示す図
【図９】本発明の実施の形態におけるホームエージェントの機能アーキテクチャの一例を示す図
【図１０】本発明の実施の形態において、ローカルモビリティ管理に適用する場合の一例を示すネットワーク構成図
【図１１】本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをホームエージェントへ送信する際の処理の一例を示すシーケンスチャート
【図１２】本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをコレスポンデントノードへ送信する際の処理の一例を示すシーケンスチャート
【図１３】本発明の実施の形態において、ローカルモビリティ管理に適用する場合の別の一例を示すネットワーク構成図
【図１４】本発明の実施の形態において、ローカルモビリティ管理に適用する場合のさらに別の一例を示すネットワーク構成図
【図１５】本発明の実施の形態において、モバイルノードがセルラネットワークにおいてハンドオーバを行う場合の一例を示すネットワーク構成図
【発明を実施するための最良の形態】
【００４７】
以下、図面を参照しながら、本発明の実施の形態について説明する。【００４８】
本発明によれば、ホームエージェント（あるいは、ホームドメイン内の任意のノード）が、ホームエージェントに登録されているモバイルルータと、このモバイルルータ（あるいは、モバイルルータによって管理されているモバイルネットワークのモバイルネットワークノード）との通信を行っているコレスポンデントノードとの間のプレフィックス情報の交換におけるシグナリング処理に介入（intervene）することが可能となる。【００４９】
このホームエージェントの介入によって、コレスポンデントノードは、有効なプレフィックス情報を確実に取得できるようになり、モバイルルータが実際には管理していないプレフィックス情報（モバイルネットワークプレフィックス）の管理を行っていると、コレスポンデントノードが誤って認識しないようにすることが可能となる。【００５０】
ホームエージェントがシグナリングに介入する動作（本発明の目的を実現するための動作）は複数存在しており、以下、本発明に係る基本的な動作例について説明する。なお、これらの基本的な動作例から想到可能な技術に関しても、本発明の範囲であることは明らかである。また、本明細書におけるプレフィックス情報は、アドレスプレフィックスを形成する実際のビットパターンやビットパターンの長さ（プレフィックスレングスとも呼ばれる）を含むものであるが、これに限定されるものではないことは明らかである。【００５１】
本発明の基本的な動作によれば、ホームエージェントが、プレフィックス情報判断部において、モバイルルータとコレスポンデントノードとの間で交換されるシグナリングパケット（パケット特定部において特定された、モバイルルータ又はその配下のモバイルノードとコレスポンデントノードとの間で伝送されるパケット）を精査することが可能である。そして、モバイルルータが実際には管理していないプレフィックスを管理しているようかのようにコレスポンデントノードが思い込んでしまうような情報（例えば、無効な値が使用されていると判断されたモバイルネットワークプレフィックス情報）がシグナリングパケットに含まれており、このシグナリングパケットの伝送が行われてしまうとコレスポンデントノードが誤って認識することになってしまう場合には、ホームエージェントのパケット破棄部は、このシグナリングパケットの破棄を行う。【００５２】
図１には、本発明の実施の形態において、モバイルルータとコレスポンデントノードとの間でやり取りされるシグナリングを示すシーケンスチャートが図示されている。【００５３】
図１には、モバイルルータ（ＭＲ）２０とコレスポンデントノード（ＣＮ）３０との間において、ＭＲ２０があるモバイルネットワークプレフィックスを管理している旨を示すバインディングをＣＮ３０に登録するために行われるシグナリングを示すシーケンスチャートの一例が図示されている。【００５４】
なお、図１には、経路最適化が行われる際に一般的に利用される処理が図示されている。この処理によって経路最適化が実現され、ＣＮ３０がこのモバイルネットワークプレフィックスに属するアドレスあてにパケットを送信する場合に、ＭＲ２０の現在位置あてに直接パケットを転送できるようになる。なお、経路最適化におけるパケット転送では、例えばパケットのカプセル化が行われるが、他の技術を用いて経路最適化パケットの転送が行われてもよい。また、ＭＲ２０の現在位置としては、例えば、ＭＲ２０の気付アドレス（ＣｏＡ）を用いることが可能であるが、これに限定されるものではない。【００５５】
なお、このようなシグナリング処理では、通常、ＭＲ２０がまず経路最適化開始メッセージをＣＮ３０に送信し、ＣＮ３０が暗号化によって生成されたトークンを含むテストメッセージによる応答を行う。そして、ＭＲ２０は、暗号化トークン（あるいは、例えばハッシュなどのような暗号化トークンから得られる情報）を含むバインディングアップデートメッセージを送信して、経路最適化処理が完了する。【００５６】
例えば、リターンルータビリティ（ＲＲ：Return Routability）処理では、ホームテストイニット（ＨｏＴＩ：Home Test Init）メッセージ及び気付テストイニット（ＣｏＴＩ：Care-of Test Init）メッセージの２つの開始（イニット）メッセージが送信される。そして、これらに対応して、ホームテスト（ＨｏＴ：Home Test）メッセージ及び気付テスト（ＣｏＴ：Care-of Test）メッセージの２つの応答が行われる。【００５７】
また、ＲＲＮＰ（特許文献２参照）では、モバイルネットワークのプレフィックス情報がＨｏＴＩメッセージによって通知され、受信者は、ネットワークプレフィックステスト（ＮＰＴ）メッセージによって応答を行う。このＮＰＴメッセージは、ホームエージェントを通じて転送される。【００５８】
また、ＸＲＲＰ（特許文献１参照）では、モバイルネットワークのプレフィックス情報は、ホームエージェントを通じて転送されるモバイルネットワークノードテストイニット（ＭＮＮＴＩ）メッセージによって伝送され、受信者はモバイルネットワークノードテスト（ＭＮＮＴ）メッセージで応答を行う。【００５９】
図１には、イニット（Ｉｎｉｔ：開始）メッセージ１１５及びテストメッセージ１２０のみを使用した一般的なメッセージシーケンスが図示されている。なお、開始メッセージ１１５は、ＲＲＮＰにおけるＨｏＴＩメッセージ、ＸＲＲＰにおけるＭＮＮＴＩメッセージや、その他の同様のシグナリング処理で使用される任意のテスト開始メッセージを表している。また、テストメッセージ１２０は、ＲＲＮＰにおけるＮＰＴメッセージ、ＸＲＲＰにおけるＭＮＮＴメッセージや、その他の同様のシグナリング処理で使用される任意のテスト応答メッセージを表している。また、シグナリング処理において通常存在するメッセージのいくつかに関しては、図面を簡単にするため、図１では図示省略されている。【００６０】
図１に示される一般的なメッセージシーケンスにおいては、ＭＲ２０は、まず、トンネルパケット１１０によってイニットメッセージをホームエージェント（ＨＡ）１０にトンネルする。そして、ＨＡ１０はインナパケット（実際のイニットメッセージ１１５）をＣＮ３０に送信する。なお、イニットメッセージ１１５には、ＭＲ２０がその管理を主張するモバイルネットワークのプレフィックスに関する情報が含まれている。【００６１】
一方、ＣＮ３０はテストメッセージ１２０によって応答を行う。このテストメッセージ１２０は、ＨＡ１０によって受信（intercept）されて、トンネルパケット１２５にカプセル化され、ＭＲ２０に転送される。そして、ＭＲ２０がＢＵメッセージ１３０をＣＮ３０に送信することによって、プレフィックス情報の通知が完了となる。【００６２】
なお、ＢＵメッセージ１３０には、ＣＮ３０がＭＲ２０の実際の位置との関連付けを行うプレフィックス情報が含まれている。すなわち、以降、ＣＮ３０から、そのプレフィックスに存在する任意のあて先に送信されるパケットは、通常のルーティング機構を用いて転送される代わりに、実際の位置（例えば、ＭＲ２０の気付アドレス）に転送される。【００６３】
さらに、テストメッセージ１２０には、ＭＲ２０によるテストメッセージの受信が成功したことをＣＮ３０が検証できるように、ＢＵメッセージ１３０に挿入されるべき任意の暗号化トークンが含まれている場合がある。【００６４】
図１では、ホームエージェント（ＨＡ）１０が介入（干渉）して、ＭＲ２０とＣＮ３０との間で交換されているプレフィックス情報が有効であることを確認できる機会が２回存在する。これらの機会は図１のプロセス１５０及びプロセス１６０で示されている。【００６５】
本発明の好適な実施の形態では、これらの一方又は両方の処理（図１のプロセス１５０、１６０）において、ＨＡ１０が、図２に図示されているアルゴリズムを使用して、有効なプレフィックス情報がＣＮ３０に送信されているか否かを確認することが可能である。【００６６】
まず、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（イニットメッセージやテストメッセージなど）をチェックする。【００６７】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ２５０において、ＨＡ１０は、そのパケットに含まれているプレフィックス情報が有効か否かをチェックする。【００６８】
プレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。【００６９】
図２に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むパケットを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。【００７０】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。【００７１】
なお、伝送されているプレフィックス情報が有効か否かをホームエージェントがチェックする際に、伝送されているプレフィックス情報がモバイルルータに割り当てられているモバイルネットワークプレフィックスに同一か否かをチェックすることのみで、プレフィックス情報の有効性のチェックが行われたとみなさないほうがよい。モバイルルータは、様々な使用目的に応じて、自身に割り当てられているプレフィックスを様々な異なるセグメントに分割している可能性がある。したがって、ホームエージェントは、モバイルルータに割り当てられているモバイルネットワークプレフィックスの範囲に含まれているプレフィックス情報に関しても、そのプレフィックス情報を有効なものとみなす必要がある。【００７２】
上述のように、ＨＡ１０は、プロセス１６０（ＭＲ２０からトンネルされたパケットの転送の際）又はプロセス１５０（ＭＲ２０へパケットをトンネルする前）の２回の機会において、図２に示されているアルゴリズムを実行することが可能である。【００７３】
以下、本発明の実施の形態において、上述の各プロセス１５０、１６０でアルゴリズムを実行する場合における様々な好適な動作について説明する。なお、以下では、様々な好適な動作に関して説明を行うが、これらの様々な好適な動作は任意に組み合わせて行われてもよく、また、プロセス１５０、１６０の両方でプレフィックス情報のチェックが行われてもよい。【００７４】
例えば、本発明の実施の形態における好適な動作において、ホームエージェント（ＨＡ）１０は、プロセス１５０においてシグナリングを介入することが可能である。すなわち、ホームエージェント（ＨＡ）１０はＭＲ２０に転送されるべきパケットのチェックを行う。【００７５】
このチェックによって、パケットにプレフィックス情報が含まれているか否かの判断が行われ、さらに、プレフィックス情報が含まれている場合には、そのプレフィックス情報が有効か無効かのチェックが行われる。そして、プレフィックス情報が無効なものである場合には、パケットは破棄される。【００７６】
例えば、ＲＲＮＰでは、ＣＮ３０は、ＮＰＴメッセージをモバイルネットワーク内のあて先に送信する必要がある。ＨＡ１０は、このＮＰＴメッセージが有効か否かをチェックし、必要に応じて（すなわち、無効なプレフィックス情報が含まれている場合には）ＮＰＴメッセージの破棄を行う。【００７７】
また、ＸＲＲＰでは、ＣＮ３０がＭＮＮＴメッセージを送信する必要がある。ＨＡ１０は、ＭＮＮＴメッセージが有効か否かをチェックして、必要に応じて（すなわち、無効なプレフィックス情報が含まれている場合には）ＭＮＮＴメッセージの破棄を行う。【００７８】
しかしながら、通常、ホームエージェントはルータであり、ルータは多数のパケットの処理を行う。一方、通常、プレフィックス情報交換メッセージは、ホームエージェントが発送しなければならないパケットのうちのほんの少数に過ぎない。したがって、すべてのパケットに関してプレフィックス情報が含まれているか否かのチェックがホームエージェントによって行われた場合には、ホームエージェントの処理に過剰な負荷がかかることになる。【００７９】
以下、本発明の実施の形態における好適な動作において、ホームエージェントの負荷を減少させる方法について説明する。この本発明に係る動作では、ホームエージェントは、もしパケットが通常の処理に従って転送されてしまった場合には、モバイルルータが実際には所有していないプレフィックスを所有しているかのように送信者（例えばＣＮ３０）が思い込んでしまうような、特定のあて先アドレスに送信されるパケットを破棄する。例えば、ホームエージェントは、有効ではないプレフィックス情報を含むアドレスあてに送信されるパケットを検出して、そのパケットの破棄を行う。【００８０】
図３Ａには、この動作が起こり得る場合の特定のアドレスの一例が図示されている。あて先アドレス３００には、プレフィックス部３１０、長さ部３２０、そして、残りの部分３５０が含まれている。【００８１】
プレフィックス部３１０には、モバイルルータによって所有されていると送信者が思っているプレフィックスが含まれる。また、長さ部３２０には、モバイルルータによって所有されていると送信者が思っているプレフィックスの長さの値が含まれる。また、残りの部分３５０はどんな値でもよいが、例えば、すべての値がゼロにセットされ、ホームエージェントがこの残りの部分３５０を容易に把握できるようにすることが望ましい。【００８２】
なお、アドレスは固定長（例えば、ＩＰｖ６では１２８ビット）なので、長さ部３２０のサイズは固定され、あらかじめ周知であってもよい。例えば、ＩＰｖ６では、長さ部３２０の最大値は１２７であり、長さ部３２０は７ビット長あればよい。【００８３】
したがって、この好適な動作によれば、ＭＲ２０がプレフィックスを管理していることを主張するイニットメッセージをＣＮ３０がＭＲ２０から受信した場合、ＣＮ３０は、テストメッセージ生成部においてテストメッセージを生成するとともに、あて先アドレス設定部において、プレフィックス部３１０がＰ１にセットされ、長さ部３２０がＬ１にセットされたアドレスをテストメッセージのあて先アドレス３００として設定して、テストメッセージの送信を行う。【００８４】
ホームエージェント（ＨＡ）１０は、この場合、図４に図示されているアルゴリズムを使用することが可能である。なお、図４に図示されているフローチャートは、図２に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。【００８５】
まず、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（イニットメッセージやテストメッセージなど）をチェックする。【００８６】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ４２０において、ＨＡ１０は、あて先アドレスからプレフィックス情報を抽出する。この処理は、プレフィックス部３１０及び長さ部３２０を抽出することによって行われる。【００８７】
次に、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。【００８８】
図４に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるテストメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。【００８９】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。【００９０】
なお、上述の長さ部は送信アドレスなどによってプレフィックス情報の有効性を確認する場合の一例であり、このプレフィックスの長さの情報を、テストメッセージの別のオプションとして付加することも可能であり、別のメッセージとして送信するようにしてもよい。また、プレフィックス情報を別のメッセージとして通知してもよく、この場合は、テストメッセージとは独立に動作可能（バインディンクアップデートメッセージで経路最適化処理が完了するまでに確定すればよい）であるため、ＭＲがＨＡに対してＣＮへの通知を依頼して、ＨＡがＣＮに有効なプレフィックス情報を通知するようにしたり、ＣＮが確認のためにＨＡに問い合わせを行い、ＨＡがその問い合わせに対して有効なプレフィックス情報の応答を行ったりすることも可能である。【００９１】
また、無効なプレフィックス情報を発見したことにより、テストメッセージを破棄した場合には、パケット破棄部においてパケットが破棄されたことを通知するＨＡのパケット破棄通知部は、ＭＲに対し、その旨を伝えることが望ましい。これにより、ＭＲは、ＣＮが経路最適化の機能を持っていない場合、若しくはイニットメッセージ、テストメッセージのいずれかが不着となってしまった場合と、プレフィックス情報が無効であった場合とを区別することができるようになる。その結果、ＭＲは、タイムアウトまで受信を待ち続けたり、無効なプレフィックス情報を含むイニットメッセージを繰り返し送信したりする無駄な処理を行わないようにすることが可能となり、また、実際は経路最適化可能なＣＮであるのに経路最適化を行わない（行えない）という誤った判断を防ぐことが可能となる。【００９２】
上述の好適な動作では、ホームエージェントがテストメッセージに関する内容からプレフィックス情報を抽出する処理を行う必要がないという利点を有し、ホームエージェントにおける処理負荷が減少される。しかしながら、ホームエージェントは、依然として、モバイルルータにトンネルされるすべての受信パケットを精査して、パケットがテストメッセージか否かをチェックする必要がある。この処理は、ホームエージェントに大きな負荷を与える。【００９３】
以下、下記の好適な動作に基づいて、ホームエージェントの負荷を更に減少させる方法について説明する。【００９４】
この本発明に係る好適な動作では、ホームエージェントは、特定のあて先アドレスに送信されたパケットか否かのチェックを行い、あて先アドレスにあるビットパターンが含まれている場合のみ、そのパケットがテストメッセージか否かのチェックを行う。【００９５】
図３Ｂには、この動作が起こり得る場合の特定のアドレスの一例が図示されている。図３Ｂでは、あて先アドレス３００には、プレフィックス部３１０、長さ部３２０に加えて、ビットパターン部３３０が含まれている。【００９６】
上述のように、プレフィックス部３１０には、モバイルルータによって所有されていると送信者が思っているプレフィックスが含まれる。また、長さ部３２０には、モバイルルータによって所有されていると送信者が思っているプレフィックスの長さの値が含まれる。【００９７】
また、ビットパターン部３３０には、特定のビットパターンが含まれており、ホームエージェントは、この特定のビットパターンを認識して、必要なチェックを行うことが可能である。このビットパターン部３３０の特定のビットパターンによって、ホームエージェントは、テストメッセージである可能性が高いパケットを選別することが可能となる。【００９８】
また、残りの部分３５０はどんな値でもよいが、例えば、すべての値がゼロにセットされ、ホームエージェントがこの残りの部分３５０を容易に把握できるようにすることが望ましい。【００９９】
なお、アドレスは固定長（例えば、ＩＰｖ６では１２８ビット）なので、長さ部３２０のサイズは固定され、あらかじめ周知であってもよい。例えば、ＩＰｖ６では、長さ部３２０の最大値は１２７であり、長さ部３２０は７ビット長あればよい。【０１００】
また、ビットパターン部３３０は任意のサイズであってよい。ただし、ビットパターン部３３０が長ければ長いほど、許容されるプレフィックス長の最大値は小さくなる。一方、ビットパターン部３３０が短ければ短いほど、そのビットパターンを偶然に含んでいるあて先アドレスに送信された通常のパケット（すなわち、テストメッセージではないパケット）が検出される可能性が大きくなる。これにより、パケットをチェックするホームエージェントのリソースが余分に消費され、ホームエージェントの処理負荷は高くなる。したがって、ビットパターン部３３０は、プレフィックス長の大きさを考慮しながら、なるべく大きなサイズに設定されることが望ましい。【０１０１】
この動作では、ＣＮ３０は、ＭＲ２０がプレフィックス（プレフィックスＰ１及びプレフィックス長Ｌ１）を管理している旨を主張するイニットメッセージをＭＲ２０から受信すると、テストメッセージ生成部においてテストメッセージを生成するとともに、プレフィックス部３１０がＰ１にセットされ、長さ部３２０がＬ１にセットされ、ビットパターン部３３０が、このパケットがテストメッセージであることを示す周知の値にセットされたアドレスをテストメッセージのあて先アドレス３００として設定して、テストメッセージの送信を行う。【０１０２】
ホームエージェント（ＨＡ）１０は、この場合、図５に図示されているアルゴリズムを使用することが可能である。なお、図５に図示されているフローチャートは、図４に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。【０１０３】
まず、ステップＳ５００において、ＨＡ１０は、受信パケットのあて先アドレスのビットパターン部３３０に、テストメッセージであることを示す周知の値が含まれているか否かをチェックする。【０１０４】
このような値がビットパターン部３３０に含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、テストメッセージであることを示す値がビットパターン部３３０に含まれている場合には、ステップＳ４２０において、ＨＡ１０は、あて先アドレスからプレフィックス情報を抽出する。この処理は、プレフィックス部３１０及び長さ部３２０を抽出することによって行われる。【０１０５】
次に、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。【０１０６】
図５に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるテストメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。【０１０７】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。【０１０８】
上述の好適な動作では、ホームエージェントは、パケットがテストメッセージであるか否かをチェックするために、すべての受信パケットの精査を行う必要がないという利点を有し、ホームエージェントにおける処理負荷がかなり減少される。【０１０９】
上述の好適な動作では、ビットパターン部３３０に固定かつ周知の値を使用して、パケットがテストメッセージであることがホームエージェントに分かるようにすることによって、ホームエージェントの処理負荷を抑えている。しかしながら、ビットパターン部３３０に含まれる値は固定又は周知の値ではなく、動的にセットされてもよい。【０１１０】
以下、ビットパターン部３３０に含まれる値を動的にセットする場合の好適な動作について説明する。【０１１１】
この本発明に係る好適な動作では、ホームエージェントは、そのビットパターン設定部において、ビットパターン部３３０に関する設定を自ら行い、ビットパターン通知部からモバイルルータやコレスポンデントノードに対して、設定されたビットパターンを通知することが可能である。すなわち、ホームエージェントは、あて先アドレスのビットパターン部３３０にセットされる値を設定することが可能である。さらに、ホームエージェントは、ビットパターン部３３０が配置されるあて先アドレス内の位置を指定することも可能である。さらには、ホームエージェントは、ビットパターン部３３０のサイズを指定することも可能である。これにより、各ホームエージェントが、モバイルルータによって使用されているモバイルネットワークプレフィックスを考慮して、ビットパターン部３３０のサイズを決定することが可能となる。【０１１２】
例えば、プレフィックス部３１０が非常に長いホームネットワークドメインでは、ホームエージェントは、小さなビットパターン部３３０を選択（設定）することで、長いモバイルネットワークプレフィックスを収容することが可能となる。【０１１３】
逆に、プレフィックス部３１０が比較的短いホームネットワークドメインでは、ホームエージェントは、大きなビットパターン部３３０を選択（設定）することで、ビットパターン部３３０に一致するあて先ではあるが、テストメッセージではないパケットを誤認してしまう可能性を減らすことが可能となる。【０１１４】
また、図６には、本発明の好適な実施の形態における好適な動作を実行するための方法を示すメッセージシーケンスチャートが図示されている。モバイルルータ（ＭＲ）２０が、ホームエージェント（ＨＡ）１０にＢＵメッセージ６１０を送信してＭＲ２０の気付アドレスを登録した後、ＨＡ１０は、ＢＡ（Binding Acknowledgement：バインディングアクノレッジメント）メッセージ６１５で応答を行う。【０１１５】
ＨＡ１０のビットパターン通知部は、このＢＡメッセージ６１５に、コレスポンデントノードによって使用される特別なビットパターン（Ｓビット）に関する情報を挿入する。なお、この情報には、ビットパターン部の値、ビットパターン部のサイズ、アドレス内のビットパターンの位置などが含まれることが望ましい。【０１１６】
ＭＲ２０は、気付アドレスに関連付けて自身のモバイルネットワークプレフィックスをコレスポンデントノード（ＣＮ３０）に登録しようとした場合には、ＣＮ３０にイニットメッセージを送信する。このイニットメッセージは、まず、ＨＡ２０に送信されるトンネルパケット６２０によってカプセル化される。【０１１７】
次に、ＨＡ１０は、パケットのデカプセル化を行って、ＣＮ３０にイニットメッセージ６２５を転送する。イニットメッセージ６２５には、特別なビットパターンに関する情報が含まれている。これにより、ＣＮ３０は、プレフィックス部３１０、長さ部３２０、ビットパターン部３３０に適切な値がセットされたあて先アドレスに、テストメッセージ６３０を送信することが可能である。【０１１８】
このとき、ＨＡ１０は、プロセス１５０において、テストメッセージ６３０のあて先アドレスに埋め込まれているプレフィックス情報の検証を行うことが可能である。さらに、ＨＡ１０は、プレフィックス情報が有効な場合には、テストメッセージをトンネルパケット６３５によってＭＲ２０に転送することが可能である。そして、ＭＲ２０は、ＢＵメッセージ６４０をＣＮ３０に送信して処理が完了となる。【０１１９】
また、本発明に係る別の動作では、モバイルルータによって情報は使用されず、ホームエージェントやコレスポンデントノードでのみ使用されるので、モバイルルータ（ＭＲ）２０は、ビットパターンで使用されている実際の情報を知る必要はない。【０１２０】
この動作では、ＭＲ２０は、トンネルパケット６２０によってカプセル化されるイニットメッセージ内にビットパターンの情報を挿入しない。その代わりに、ＭＲ２０は、トンネルパケット６２０内のイニットメッセージに空のフィールドをいくつか挿入し、ＨＡ１０がパケットをデカプセル化する際、ＣＮ３０へイニットメッセージ６２５を送信する前に、挿入された空のフィールドにビットパターン情報を記入する。このように、ビットパターン情報がＢＡメッセージ６１５でＭＲ２０に伝えられる必要はなく、ＭＲ２０がビットパターン情報を格納（記憶）する必要はない。【０１２１】
また、ホームエージェントの処理負荷を低減させるため、ＭＲ２０は、例えば、ルータアラートオプションやあて先オプションの形式で、トンネルパケット６２０のアウタパケットのヘッダに任意の信号を挿入することが可能である。これによって、トンネルパケット６２０でカプセル化されているインナパケットにビットパターン情報を記入する必要があることがＨＡ１０に通知される。【０１２２】
なお、ＨＡのビットパターン設定部において定めたビットパターンを使っていることを示す情報をＣＮに通知できることが望ましい。例えば、ＭＲが示すビットパターンを含むパケットに少なくともビットパターンが正しいことを示す暗号化署名をオプションとして付加したり（ＣＮはこの暗号化署名を確認する）、ビットパターンを記入する場合にはその真正性を示す暗号化署名も付加したり（ＣＮはこの暗号化署名を確認する）、ＭＲは単に特定のＣＮに対してビットパターンを通知するように依頼し、ＨＡがビットパターンをＣＮに通知したりしてもよい。これにより、ＣＮは、ビットパターン真正性確認部において、通知されたビットパターンの真正性を確認することが可能となり、ＭＲが恣意的にＨＡのチェックをすり抜ける目的でＨＡの意図しないビットパターンを挿入しないようにすることが可能となる。【０１２３】
上述の好適な実施の形態では、ホームエージェント（ＨＡ）１０が図１に示すプロセス１５０でチェックを実行する場合について説明されている。なお、上述の説明のように、ホームエージェントは、図１に示すアルゴリズムのプロセス１６０を使用することも可能である。【０１２４】
以下では、プロセス１６０でチェックが行われる場合の動作について説明する。この本発明に係る好適な動作では、ホームエージェントは、モバイルルータからトンネルされるパケットをチェックして、このパケットが配送されるとモバイルルータが実際には管理していないプレフィックスを管理しているとコレスポンデントノードが誤って信じてしまうような場合には、パケットの破棄を行う。【０１２５】
図７には、本発明の実施の形態におけるホームエージェントがＭＲからトンネルパケットに関する処理を行うための好適なアルゴリズムが図示されている。【０１２６】
図７に図示されているフローチャートは、図２に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。【０１２７】
まず、ステップＳ７００において、ＨＡ１０は、受信パケットがモバイルルータからトンネルされたものであるか否かをチェックする。受信パケットがモバイルルータからトンネルされたものではない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。【０１２８】
一方、受信パケットがモバイルルータからトンネルされたものである場合には、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（例えばイニットメッセージなど）をチェックする。【０１２９】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。【０１３０】
抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。【０１３１】
図７に図示されているアルゴリズムを用いて、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるイニットメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。【０１３２】
したがって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理していることをＣＮ３０が誤って信じないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。【０１３３】
上述の好適な動作では、コレスポンデントノードが、特定のあて先アドレスにテストメッセージを送信するように構成される必要はなく、コレスポンデントノードの機能を変更する必要がないという利点がある。【０１３４】
例えば、ＲＲＮＰが使用されている場合には、モバイルネットワークのプレフィックス情報はＨｏＴＩメッセージに挿入される。ホームエージェントは、モバイルルータから送信されるメッセージを精査して、無効なモバイルネットワークのプレフィックス情報が含まれているメッセージを破棄する。【０１３５】
なお、ＨＡがプレフィックス情報の確認を行ったことを示す情報をＣＮに通知できることが望ましい。例えば、ＭＲが示すプレフィックス情報を含むパケット（イニットメッセージなど）に少なくともプレフィックス情報が正しいことを示す暗号化署名をオプションとして付加したり（ＣＮはこの暗号化署名を確認する）、ＭＲは単に特定のＣＮに対してプレフィックス情報を通知するように依頼し、ＨＡがプレフィックス情報をＣＮに通知したりしてもよい。これにより、ＣＮはこのプレフィックス情報がＨＡによりチェックされたものであるか否かを容易に確認することが可能となる。【０１３６】
また、ＸＲＲＰが使用されている場合には、モバイルネットワークのプレフィックス情報はＭＮＮＴＩメッセージに挿入される。ホームエージェントは、モバイルルータからのメッセージを精査して、無効なモバイルネットワークのプレフィックス情報が含まれるメッセージを破棄する。【０１３７】
なお、これらのＨｏＴＩメッセージやＭＮＮＴＩメッセージなどを破棄する際には、ホームエージェントは、モバイルルータに対してＩＣＭＰエラーメッセージによって警告を送信することが望ましい。【０１３８】
上述の好適な動作では、有効なプレフィックス情報が確実に送信されるようにするために、ホームエージェントが、モバイルルータとコレスポンデントノードとの間でやり取りされるプレフィックス情報のシグナリングに対して動作を行う場合について説明されているが、さらにホームエージェントが、シグナリングが開始される前に、有効なプレフィックス情報が確実に送信されるようにするための動作を積極的に開始することも可能である。【０１３９】
以下、ホームエージェントが、シグナリングが開始される前に有効なプレフィックス情報が確実に送信されるようにする場合の好適な動作について説明する。【０１４０】
この本発明に係る好適な動作では、ホームエージェントは、正しいプレフィックス情報か否かをホームエージェントやその他のコレスポンデントノードが簡単に検証できるようにするとともに、悪意あるモバイルルータが実際には管理していないモバイルネットワークプレフィックスを所有している旨を主張することが難しくなるように、ホームドメイン内のモバイルルータに対してモバイルネットワークプレフィックスを割り当てる。【０１４１】
好適な例では、ホームエージェントはモバイルルータに対して、最右端のビット（モバイルネットワークプレフィックスの末尾のビット）を常に１とするモバイルネットワークプレフィックスを割り当てるようにする。この場合、コレスポンデントノードは、モバイルルータが所有していると主張するモバイルネットワークプレフィックスのプレフィックス情報を含むイニットメッセージを検証する際に、このプレフィックス情報を含むとともに残りのビットがすべてゼロに設定されたあて先アドレスに対してテストメッセージの送信を行う。【０１４２】
モバイルルータには、最右端のビットが１にセットされたモバイルネットワークプレフィックスが常に割り当てられているので、モバイルルータがより小さなプレフィックス（すなわち、より広いアドレス範囲）の所有を主張しようとしている場合には、主張されたプレフィックス及び残りがすべてゼロにセットされたあて先アドレスは、正しいモバイルネットワークプレフィックスの値を含むことはできず、このあて先アドレスに送信されるテストメッセージは、モバイルルータに到達不能となる。したがって、シグナリング処理は失敗に終わり、モバイルルータが試みたより小さなプレフィックスの所有を主張も失敗に終わる。【０１４３】
図８には、この動作が行われる場合に、コレスポンデントノードがテストメッセージを送信する際に使用することが望ましいあて先アドレス８００が図示されている。【０１４４】
プレフィックス部８１０には、モバイルルータによって所有されていると送信者が思っているプレフィックス（モバイルルータがイニットメッセージでその所有を主張したプレフィックス）が含まれる。なお、コレスポンデントノードは、テストメッセージを送信する前に、プレフィックス部８１０の最右端のビット８１５が１であることをチェックすることが望ましい。【０１４５】
また、残りの部分８２０は、例えばすべてゼロにセットされることが望ましいが、プレフィックスの長さがアドレスと同一にはなり得ないので、コレスポンデントノードは、例えば、末尾のビット８３０の値を１にセットしてもよい。これにより、サブネットワークがすべてゼロに設定されたアドレス（オールゼロアドレス）は特別な目的（サブネットルータエニキャストアドレスなど）で使用される可能性があるが、こうした特別な意味を持つアドレスと重複しないあて先アドレスを実現することが可能となる。【０１４６】
すなわち、コレスポンデントノードは、テストメッセージ生成部においてテストメッセージを生成するとともに、モバイルルータによって所有されていると思われるプレフィックスがプレフィックス部８１０にセットされ、残りの部分８２０がすべて０（あるいは末尾のビットのみ１）にセットされたアドレスをテストメッセージのあて先アドレス８００として設定して、テストメッセージの送信を行う。【０１４７】
ここでは、プレフィックス部８１０の直後のビット配列がゼロにセットされていることが重要である。ゼロにセットされているビット配列の範囲が広いほど（すなわち、残りの部分８２０のサイズが大きいほど）、プレフィックス部８１０の範囲は狭くなり、モバイルルータは、実際に割り当てられているプレフィックスよりも小さなプレフィックスを主張することはより困難となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。【０１４８】
この好適な動作では、例えば、ホームエージェントは転送パケットの内容をチェックする必要はなく、ホームエージェントに更なる処理負荷が発生しないという利点がある。しかしながら、この動作では、ホームドメインが主にモバイルネットワークで構成されている場合には、ドメインのネットワークリソースが無駄になってしまう（使えなくなってしまう）可能性がある。すなわち、モバイルネットワークプレフィックスはすべて１にセットされたビットで終わるので、最後がゼロにセットされたプレフィックスはモバイルネットワークプレフィックスとしては使用不可能となる。【０１４９】
以下、このようなプレフィックスのリソースの無駄を抑えることが可能なプレフィックス割り当て方法について説明する。【０１５０】
ゼロビットで終わるプレフィックスは、更に小さな２つのプレフィックスに分割可能である。すなわち、ゼロビットで終わるプレフィックスは、さらに１ビット長いプレフィックス長のプレフィックスの末尾のビットが１で終わるものと、末尾のビットが０で終わるものに分割可能である。そして、末尾のビットが１で終わるものに関しては、モバイルネットワークプレフィックスとして割り当て可能である。一方、末尾のビットが０で終わるものは、更に１ビット長いプレフィックス（同様に、その末尾のビットが０のものと１のもの）に分割される。【０１５１】
例えば、ホームエージェントが、６４ビット長で最後のビットが１にセットされたプレフィックスを割り当てたと仮定する。このとき、６４ビット長で最後のビットが０のプレフィックスは、６５ビット長の２つのプレフィックスに分割可能である。そして、６４ビット長で最後のビットが０であっても、６５ビット目が１であるプレフィックスに関しては、６５ビット長のモバイルネットワークプレフィックスとして割り当て可能である。一方、６５ビット長で末尾のビットが０で終わるプレフィックスは、更に６６ビット長の２つのプレフィックスに分割可能であり、同様にその半分（６６ビット目のビットが１のプレフィックス）がモバイルネットワークプレフィックスとして割り当て可能である。【０１５２】
例えば１２８ビット長のＩＰｖ６アドレスの場合には、理論的には、この処理は１２７ビットのプレフィックス長まで続き、無駄なアドレス（使用不可能なアドレス）は、１つのみとなる。なお、１２６ビットのプレフィックス長のプレフィックスや、その他の非常に長いプレフィックス長のプレフィックスは、実際にはほとんど使用されることはない。【０１５３】
なお、上述の動作を組み合わせて、あて先アドレスの選択の際に、このような末尾が１にセットされるモバイルネットワークプレフィックスを選択してもよい。例えば、このような組み合わせの一例として、図３Ａに図示されているあて先アドレスが図８に図示されているあて先アドレスに組み合わされた場合には、図３Ａにおいて、モバイルネットワークプレフィックスの末尾のビットは常に１にセットされる。このとき、コレスポンデントノードは、プレフィックス部にそのプレフィックス（末尾のビットが１のモバイルネットワークプレフィックス）がセットされたあて先アドレスを選択し、プレフィックス部の最右端のビットが１にセットされていることをチェックし、プレフィックス長の値を含む長さ部をアドレスの最右端のビットにセットして、残りの部分をゼロにセットする。【０１５４】
また、別の組み合わせの一例として、図３Ｂに図示されているあて先アドレスが図８に図示されているアドレスに組み合わされてもよい。このとき、コレスポンデントノードは、プレフィックス部にそのプレフィックス（最右端のビットが１のモバイルネットワークプレフィックス）がセットされたあて先アドレスを選択し、プレフィックス部の最右端のビットが１にセットされていることをチェックし、プレフィックス長の値を含む長さ部をアドレスの最右端のビットにセットし、長さ部の直前にビットパターンを挿入してビットパターン部をセットし、残りの部分をゼロにセットする。【０１５５】
また、図９には、本発明の実施の形態におけるホームエージェントの機能アーキテクチャの一例が図示されている。本発明に係るホームエージェントは、有効なプレフィックス情報が確実に送信されるようにする機能を有している。【０１５６】
図９に図示されているホームエージェントは、パケットの送受信を行うための１つ又は複数のネットワークインタフェース９１０、パケットの発送方法や転送方法を決定するためのルーティングモジュール９２０、モバイルネットワークプレフィックスに関連したパケットのチェックを実行するためのモバイルネットワークプレフィックス（ＭＮＰ）チェック部９２５、ルーティングレイヤより上位に存在するすべてのプロトコル及びプログラムを包含する１つ又は複数のアプリケーション９３０、モバイルルータやモバイルネットワークプレフィックスの割り当てに関する構成情報を格納するデータベース９４０を有している。【０１５７】
ネットワークインタフェース９１０は、このホームエージェントが任意の通信媒体を通じて別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。なお、関連する技術分野で周知の用語を用いると、ネットワークインタフェース９１０は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ及び通信プロトコルを表している。なお、図９に図示されているホームエージェントは、１つ又は複数のネットワークインタフェース９１０を有していてもよい。【０１５８】
また、ルーティングモジュール９２０は、パケットの発送方法の決定処理を行う機能を有している。なお、関連する技術分野で周知の用語を用いると、ルーティングモジュール９２０は、ＩＰｖ４やＩＰｖ６などのレイヤ３（ネットワーク層）プロトコルの実装を表している。また、シグナル／データパス９５０を通じて、ルーティングモジュール９２０は、適切なネットワークインタフェース９１０との間で、パケットの送受信を行うことが可能である。【０１５９】
また、ルーティングモジュール９２０内には、本発明の主要な機能を有するＭＮＰチェック部９２５が存在している。なお、ＭＮＰチェック部９２５は、例えば図２、４、５、７のいずれかに図示されているアルゴリズムを実行することが望ましい。パケットを発送する前に、ルーティングモジュール９２０はＭＮＰチェック部９２５にパケットを渡し、ＭＮＰチェック部９２５は、本発明に係るアルゴリズムに基づいてパケットの解析を行う。なお、上述のように、ＭＮＰチェック部９２５は、パケットの解析結果に基づいて、パケットの破棄を行う場合もある。また、本発明によって提供されるプレフィックス情報確認装置の主要な機能（パケット特定部、プレフィックス判断部、パケット破棄部、パケット破棄通知部、プレフィックス判断部による判断結果を通知する判断結果通知部、ビットパターン設定部の各構成要素によって実現される機能）は、主に、ＭＮＰチェック部９２５によって実行される。【０１６０】
また、アプリケーション９３０は、通信プロトコルスタックのルーティングレイヤより上位に存在するすべてのプロトコルやプログラムを包含する機能ブロックである。このアプリケーション９３０には、例えば、ＴＣＰ（Transmission Control Protocol：送信制御プロトコル）、ＳＴＣＰ（Stream Control Transport Protocol ：ストリーム制御トランスポートプロトコル）、ＵＤＰ（User Datagram Protocol：ユーザデータグラムプロトコル）などのトランスポートレイヤプロトコルやセッションレイヤプロトコル、あるいは、他のノードとの通信に必要なプログラムやソフトウェアなどが含まれる。また、シグナルパス９５２を通じて、ルーティングモジュール９２０とアプリケーション９３０との間でパケット伝送が可能である。【０１６１】
また、ＭＮＰチェック部９２５がパケットに記載されているモバイルネットワークプレフィックスが有効か否かを判断できるように、ＭＮＰチェック部９２５は、モバイルネットワークプレフィックスの割り当て方法に関する情報にアクセスできる必要がある。【０１６２】
このような情報は例えばデータベース９４０に格納されており、ＭＮＰチェック部９２５は、シグナルパス９５４を通じて、データベース９４０に格納されている情報にアクセスすることが可能である。【０１６３】
なお、モバイルルータは、割り当てられているプレフィックスを様々な目的（すなわち、モバイルネットワークプレフィックスとしての使用以外の目的も含まれる）に従って、異なるセグメントに分割している場合がある。したがって、ＭＮＰチェック部９２５は、送信されるプレフィックス情報が有効か否かをチェックする際に、送信されるプレフィックス情報がモバイルルータによって割り当てられたモバイルネットワークプレフィックスと同一であるか否かをチェックするだけではなく、モバイルネットワークプレフィックスとして使用されているプレフィックスの範囲に含まれているか否かをチェックし、モバイルネットワークプレフィックスの範囲に含まれるプレフィックス情報に関しても有効なプレフィックス情報とみなす必要がある。【０１６４】
なお、シグナルパス９５０、９５２、９５４は、単に論理的なコネクションを表すものであり、物理的な配線がなされている必要はない。これらのシグナルパスは、例えば、関数又はサブルーチンの呼び出しを表している。【０１６５】
さらに、データベース９４０は、図９では単一ユニットとして図示されているが、物理的なメモリバッファを使用して実装されてもよく、副次的なメモリにファイルとして格納されてもよい。さらに、データベース９４０は、単なるサブルーチンとして存在可能であり、実際の情報は、ホームエージェントとは物理的に異なるリモートサーバ（例えば、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ）に格納されており、そこから必要な情報のみが取得されるようにしてもよい。【０１６６】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、様々な構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。例えば、上述の実施の形態では、モバイルルータとコレスポンデントノードとの間で交換されるパケットのチェックがホームエージェントによって実行されているが、ホームドメイン内の別のエンティティによって実行されてもよい。このようなチェックを実行する別のエンティティとしては、例えば、ホームドメインに導入されているファイアウォール（パケットをスキャンして伝送された場合に悪影響を及ぼす可能性のあるパケットを破棄する機能を有する）などが挙げられる。【０１６７】
また、本発明のモバイルルータの機能は実体としてのモバイルルータだけでなく、論理的なエンティティとしてネットワーク内を移動する（移動下に相当する状態を配下のモバイルネットワークノードに提供する）場合にも適用可能である。これは接続ポイントを変更した場合であっても、配下のモバイルノードに対して通知するネットワークプレフィックスを変更しないようにするためにコンテキストトランスファ（Context Transfer）を行う場合などに相当する。【０１６８】
さらに、本発明は必ずしもモバイルルータ及びモバイルネットワーク（モバイルネットワークプレフィックスの所有権の検証）への適用に限定されるものではなく、ネットワークプレフィックスの所有権の検証を行うための任意の状況において使用可能であることが当業者であれば分かるであろう。【０１６９】
例えばネットワークベースのローカルモビリティ管理（ＮｅｔＬＭＭ：Network-based Local mobility management）プロトコルなどの動作において、モバイルノード（あるいは、移動端末又はＵＥ（User Equipment））に対してネットワークアクセス用のプレフィックスを割り当てることが可能である。【０１７０】
例えば、モバイルノードがローカルモビリティ管理ドメイン（ＮｅｔＬＭＭドメイン）内を移動している際に、モバイルノードに対してユニークなプレフィックスが割り当てられるとする。このとき、モバイルノードは、このネットワークプレフィックスを使用して、モビリティサポートを受けたいと望むかもしれない。このような場合の具体例について、以下に説明する。【０１７１】
図１０には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合の一例が図示されている。図１０において、ローカルネットワークドメイン１０１０はローカルモビリティ管理ドメインであり、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）１０２０、モバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）１０３０、１０３２、１０３４を有している。【０１７２】
また、モバイルノード（ＭＮ：Mobile Node）１０４０がローカルネットワークドメイン１０１０内を移動している。また、ＭＮ１０４０は、インターネット１０００などのＬＭＡ１０２０から見て外側のネットワーク（ローカルモビリティサポートのドメイン外ではあるが、オペレータの専用ネットワークなどであって、一般的なインターネットとは異なるネットワークの場合もあり得る、以下では、こうした場合を含む総称としてインターネット１０００と記載する）を通じて、ホームエージェント（ＨＡ：Home Agent）１０５０やコレスポンデントノード（ＣＮ：Correspondent Node）１０６０と通信を行うことが可能である。【０１７３】
ネットワークベースのローカルモビリティ管理の概念では、例えば、ＭＮ１０４０に対してユニークなプレフィックス（例えば、Ｐ１）が割り当てられる。このユニークなプレフィックスＰ１は、ＭＮ１０４０がローカルネットワークドメイン１０１０内を移動している限り、ＭＮ１０４０がどのＭＡＧ１０３０、１０３２、１０３４に接続しているかにかかわらず、ＭＮ１０４０に到達可能である。【０１７４】
ＭＮ１０４０は、ＨＡ１０５０やＣＮ１０６０へ送信するバインディングアップデートにおける気付アドレスとして、このプレフィックスＰ１の使用を望む場合がある。バインディングアップデートによるプレフィックスＰ１の登録は、ＭＮ１０４０がプレフィックスＰ１の範囲内のアドレスすべてを気付アドレスとしてホームアドレスに関連付けることを意味する。【０１７５】
このバインディングアップデートには、ＭＮ１０４０のホームアドレス、気付プレフィックス（Care-of Prefix）Ｐ１、気付プレフィックスＰ１のプレフィックス長が含まれている。このバインディングアップデートを受信した受信者は、プレフィックスＰ１を気付プレフィックスとして、ＭＮ１０４０のホームアドレスと関連付けて登録する。この登録により、バインディングアップデートの受信者はＭＮ１０４０のホームアドレスあてにパケットの転送又は送信を行おうとした場合、ホームアドレスの代わりに、気付プレフィックスＰ１の範囲内のアドレスの１つあてにパケットを発送することが可能となる。【０１７６】
なお、プレフィックスＰ１のうちのどのアドレスを選択するかは、例えばバインディングアップデートの受信者（ＭＮ１０４０へパケットを発送する発送者、以下、パケット発送者と呼ぶ）によって決定される。例えば、パケット発送者は、ＭＮ１０４０へのアドレス（パケットの発送先アドレス）をランダムに選択してもよく、あるいは、何らかのフィルタルールに基づいてアドレスを選択してもよい（すなわち、プレフィックスＰ１の範囲内の各気付アドレスに対して異なるフローが送信される）。なお、ＭＮ１０４０が使用すべき特定のアドレス（あるいは、特定のアドレスと特定のフローとの組み合わせ）を指定してもよい。【０１７７】
また、パケット発送者は、一連のパケット（ＭＮ１０４０へ発送されるパケット）が何らかの暗号化機能を使用してプレフィックスＰ１の範囲内のアドレスへ送信されるようにしてもよい。例えば、パケット発送者は、擬似ランダムのシーケンスナンバーを使用して、プレフィックスＰ１の範囲内から次に使用するアドレスを選択してもよい。これは、サービス不能攻撃（ＤｏＳ攻撃：Denial of service）への防御策としてスペクトラム拡散法を用いる方法と似ている。この場合、ＭＮ１０４０は、あて先アドレスがこの擬似ランダムのシーケンスナンバーに従わない受信パケットを無視する。【０１７８】
また、別の例として、パケット発送者はパケットの暗号化のハッシュ値としてプレフィックスＰ１の範囲内のアドレスを選択してもよい。これにより、ＭＮ１０４０は、パケットの真正性を検証することが可能となる。【０１７９】
一方、パケット発送者が、検証を行わずに、バインディングアップデート内に記載されている気付プレフィックスを真正のものとしてそのまま受け入れてしまう場合には、セキュリティの問題が生じる可能性がある。例えば、悪意のあるノードが、ＨＡ１０５０又はＣＮ１０６０に対して気付プレフィックスとしてプレフィックスＰ１の登録を行うことで、ＨＡ１０５０又はＣＮ１０６０からＭＮ１０４０（プレフィックスＰ１の実際の所有者）に対して、ＤｏＳ攻撃のように不要なデータが送信されるよう仕向けることが可能となり得る。【０１８０】
このようなセキュリティの問題に対処するため、本発明に係る処理を拡張して、プレフィックスの所有に係る検証を行えるようにしてもよい。【０１８１】
図１１及び図１２には、このようなセキュリティの問題に対処するための本発明の好適な適用例が示されている。図１１は、本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをホームエージェントへ送信する際の処理の一例を示すシーケンスチャートである。【０１８２】
図１１において、まずＭＮ１０４０は、開始（イニット）メッセージ１１００をＨＡ１０５０へ送信する。このイニットメッセージ１１００は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１１０５にカプセル化され、最終的にイニットメッセージ１１１０として、ＨＡ１０５０に到達する。なお、イニットメッセージ１１１０では、ＭＮ１０４０が、あるプレフィックス長（例えば、Ｌ１）を有するプレフィックスＰ１を所有していることが示されている。【０１８３】
そして、ＨＡ１０５０は、プレフィックスＰ１の範囲内のテストアドレスへテストメッセージ１１２０を送信する。このテストアドレスは、上述の実施の形態で挙げた任意の形式（例えば、プレフィックスＰ１及びそのプレフィックスＰ１の長さＬ１を含むアドレス）を用いることが可能である。例えばテストアドレスとして、最下位ビット（ＬＳＢ：least significant bit）にプレフィックスＰ１の長さＬ１の値を有するアドレスを用いることが可能であり、さらにテストアドレスであることを周知のビット（あるいはビットパターン）を有するようにしてもよい。【０１８４】
ＬＭＡ１０２０は、テストメッセージ１１２０のテストアドレス内の周知のビットパターンを認識して、プロセス１１６５に示されるチェックを実行する。このチェックでは、ＬＭＡ１０２０は、図４又は図５に示すアルゴリズムを用いて、テストメッセージ１１２０を転送するかあるいは廃棄するかを決定する。【０１８５】
テストアドレス内のプレフィックス情報が有効な場合には、テストメッセージ１１２０はトンネル化されてＭＡＧ１０３０へ転送される。そして、ＭＡＧ１０３０において、トンネル化されたテストメッセージ１１２５はデカプセル化され、最終的にテストメッセージ１１３０としてモバイルノードＭＮ１０４０に到達する。なお、このテストメッセージ１１２０には、ＭＮ１０４０がバインディングアップデート（ＢＵ）メッセージ１１４０に挿入可能な暗号化トークンが含まれていてもよい。【０１８６】
このＢＵメッセージ１１４０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１１４５にカプセル化され、最終的に、ＢＵメッセージ１１５０としてＨＡ１０５０に到達する。ＨＡ１０５０は、バインディングアップデートの真正性をチェックしてから、気付プレフィックスＰ１をＭＮ１０４０のホームアドレスへ関連付けるバインディングを受け入れることが可能である。【０１８７】
なお、図１１に示す動作の一例では、ＬＭＡ１０２０が、テストメッセージのチェック及び検証（すなわち、プロセス１１６５）を行っているが、ＬＭＡ１０２０の代わりにＭＡＧ１０３０が同一の処理（すなわち、プロセス１１７５）を実行してもよい。ＭＡＧ１０３０でこの処理が行われた場合には、ＬＭＡ１０２０の処理負荷が軽減されるという利点がある。【０１８８】
さらに、上述のモバイルネットワークプレフィックスの検証を行う場合とは異なり、ローカルモビリティ管理ドメイン内に割り当てられているプレフィックスの所有権を検証する際に送信されるイニットメッセージは、プレフィックス情報確認装置（ＭＡＧ１０３０やＬＭＡ１０２０）を通過する。したがって、例えばプロセス１１７０やプロセス１１６０において、ＭＡＧ１０３０又はＬＭＡ１０２０が、ＭＮ１０４０から送信されたイニットメッセージのチェックを実行してもよい。【０１８９】
この場合、テストアドレス内のプレフィックス情報が有効ではない場合には、ＬＭＡ１０２０又はＭＡＧ１０３０はイニットメッセージを破棄することが可能である。しかしながら、ＬＭＡ１０２０又はＭＡＧ１０３０はパケットの内容を精査せずにイニットメッセージを識別することができないため（特定のテストアドレス（あるいは特定のビットパターンを含むテストアドレス）をあて先とするテストメッセージとは異なり、アドレスによる判別は不可能）、ＬＭＡ１０２０又はＭＡＧ１０３０がイニットメッセージのチェックを実行する場合、ＬＭＡ１０２０又はＭＡＧ１０３０の処理負荷はかなり増大することになる。このため、特定のアドレス、ビットパターンなどをＨＡ１０５０から取得するなどして、イニットメッセージの識別を容易にできるようになっていることが望ましい。【０１９０】
また、図１２は、本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをコレスポンデントノードへ送信する際の処理の一例を示すシーケンスチャートである。【０１９１】
図１２に図示されている処理は、リターンルータビリティ処理を変更したものであり、ＣｏＴＩメッセージ及びＣｏＴメッセージをＣＰＴＩ（気付プレフィックステストイニット）メッセージ及びＣＰＴ（気付プレフィックステスト）メッセージで置き換えたものである。ＣＰＴＩメッセージは、本発明に係るイニットメッセージに対応するものであり、プレフィックスの所有権の検証処理を開始する際に使用される。一方、ＣＰＴメッセージは、本発明に係るテストメッセージに対応するものであり、プレフィックスの所有権の検証のためのイニットメッセージへの応答として使用される。【０１９２】
図１２において、本発明に係るリターンルータビリティ処理を変更した処理を開始するために、モバイルノードＭＮ１０４０は、まず、ＨｏＴＩメッセージ１２００及びＣＰＴＩメッセージ１２４０をＣＮ１０６０へ送信する。ＨｏＴＩメッセージ１２００は、ＨＡ１０５０へのトンネルでカプセル化されて送信される。このＨｏＴＩメッセージ１２００は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２０３にカプセル化され、最終的に、トンネル化されたＨｏＴＩメッセージ（トンネルパケット）１２０５としてＨＡ１０５０に到達する。【０１９３】
ＨＡ１０５０は、トンネルパケット１２０５をデカプセル化し、ＨｏＴＩメッセージ１２１０をＣＮ１０６０へ転送する。ＣＮ１０６０は、ＨｏＴＩメッセージ１２１０を受信すると、ＭＮ１０４０のホームアドレスから生成されたホーム鍵生成トークン（home keygen token）を含むＨｏＴメッセージ１２２０で応答を行う。【０１９４】
ＨｏＴメッセージ１２２０は、まず、ＨＡ１０５０においてトンネルパケット１２２５にカプセル化され、さらに、ＬＭＡ１０２０においてトンネルパケット１２２８に更にカプセル化される。ＭＡＧ１０３０は、外部トンネルをデカプセル化してＭＮ１０４０に転送することで、ＭＮ１０４０は、ＨｏＴメッセージを含むトンネルパケットをＨＡ１０５０から受信する。【０１９５】
ＣＰＴＩメッセージ１２４０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２４５にカプセル化され、最終的に、ＣＰＴＩメッセージ１２５０としてＣＮ１０６０に到達する。ＣＰＴＩメッセージ１２５０では、ＭＮ１０４０が、あるプレフィックス長（例えば、Ｌ１）を有するプレフィックスＰ１を所有していることが示されている。【０１９６】
ＣＮ１０６０は、プレフィックスＰ１の範囲内のテストアドレスへＣＰＴメッセージ１２６０を送信する。このテストアドレスは、上述の実施の形態で挙げた任意の形式（例えば、プレフィックスＰ１及びそのプレフィックスＰ１の長さＬ１を含むアドレス）を用いることが可能である。例えばテストアドレスとして、最下位ビット（ＬＳＢ）にプレフィックスＰ１の長さＬ１の値を有するアドレスを用いることが可能であり、さらにテストアドレスであることを周知のビット（あるいはビットパターン）を有するようにしてもよい。【０１９７】
ＬＭＡ１０２０は、ＣＰＴメッセージ１２６０のテストアドレス内の周知のビット（ビットパターン）を認識して、プロセス１２６３に示されるチェックを実行する。このチェックでは、ＬＭＡ１０２０は、図４又は図５に示すアルゴリズムを用いて、ＣＰＴメッセージ１２６０を転送するかあるいは破棄するかを決定する。【０１９８】
テストアドレス内のプレフィックス情報が有効な場合には、ＣＰＴメッセージ１２６０はトンネル化されてＭＡＧ１０３０へ転送される。そして、ＭＡＧ１０３０において、トンネル化されたＣＰＴメッセージ１２６５はデカプセル化され、最終的にＣＰＴメッセージ１２７０としてモバイルノードＭＮ１０４０に到達する。なお、このＣＰＴメッセージ１２６０には、ホーム鍵生成トークンと同じような、ＣＰＴＩメッセージ１２５０に記載されている気付プレフィックスから得られる暗号化トークン（気付鍵生成トークン：care-of keygen token）が含まれていることが望ましい。【０１９９】
ＭＮ１０４０は、ＨｏＴメッセージ１２３０及びＣＰＴメッセージ１２７０を受信すると、これらのメッセージに含まれるホーム鍵生成トークン及び気付鍵生成トークンを使用して、ＢＵメッセージ１２８０内で使用されるべきモビリティ管理鍵を生成することが可能である。このＢＵメッセージ１２８０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２８５にカプセル化され、最終的に、ＢＵメッセージ１２９０としてＣＮ１０６０に到達する。【０２００】
ＣＮ１０６０は、バインディングアップデートの真正性をチェックしてから、気付プレフィックスＰ１をＭＮ１０４０のホームアドレスへ関連付けるバインディングを受け入れることが可能である。【０２０１】
図１０〜１２には、ＭＮ１０４０が、外部ローカルモビリティ管理ドメインから割り当てられたプレフィックスを気付プレフィックスとして使用するため、ホームアドレスと関連付けるシナリオが示されている。一方、ＭＮ１０４０のホームドメインがローカルモビリティ管理ドメインであってもよい。この場合、ＭＮ１０４０のホームアドレスに代わって、ＭＮ１０４０のみが使用するホームプレフィックス（ＭＮ１０４０に対してユニークに割り当てられているホームプレフィックス）を用いてもよい。以下、このようなシナリオに関して、図１３及び図１４を参照しながら説明する。【０２０２】
図１３には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合の別の一例を示すネットワーク構成が図示されている。図１３において、ホームネットワークドメイン１３００はＭＮ１０４０のホームネットワークであり、ＨＡ１０５０、ＭＡＧ１３３０、１３３２を有している。一方、外部ネットワークドメイン１３１０はＭＮ１０４０にとって外部ネットワークであり、ＬＭＡ１０２０、ＭＡＧ１３３４、１３３６を有している。【０２０３】
また、モバイルノード１０４０は、２つの異なるローカルモビリティ管理ドメイン（ホームネットワークドメイン１３００及び外部ネットワークドメイン１３１０）への２つの接続１３４０、１３４２を有しており、インターネット１０００を通じて、ＣＮ１０６０と通信を行うことが可能である。なお、接続１３４０は、ホームネットワークドメイン１３００のＭＡＧ１３３０へ接続されており、接続１３４２は、外部ネットワークドメイン１３１０のＭＡＧ１３３６へ接続されている。また、ホームネットワークドメイン１３００及び外部ネットワークドメイン１３１０もインターネット１０００によって接続されており、インターネット１０００を介して相互のネットワーク間で通信を行うことが可能である。【０２０４】
この場合、ＭＮ１０４０は、接続１３４２から得られるプレフィックス（例えばＰ２とする）を気付プレフィックスとして関連付けて、ＨＡ１０５０へ登録することを望むかもしれない。このとき、ＭＮ１０４０が実際にプレフィックスＰ２を所有しているかどうかをＬＭＡ１０２０が検証できるようにするために、本発明を用いることが可能である。【０２０５】
また、ＭＮ１０４０に対して、ホームネットワークドメイン（ローカルモビリティ管理ドメイン）１３００からプレフィックス（例えばＰ１とする）が割り当てられてもよく、この場合、プレフィックスＰ１から得られる任意のアドレスが、ホームアドレスとして取り扱われてもよい。したがって、ＭＮ１０４０がＣＮ１０６０との間で経路最適化を実行しようとした場合には、ＭＮ１０４０は、ホームプレフィックスＰ１から得られる単一のホームアドレスの代わりに、ホームプレフィックスＰ１そのものを記載してもよい。このようにホームプレフィックスＰ１そのものを登録することで、ＭＮ１０４０は、ＣＮ１０６０と通信を行う際に、プレフィックスＰ１の範囲内のアドレスをホームアドレスとして使用することが可能である。【０２０６】
このためには、ＭＮ１０４０は、ホームアドレスに関連して送信されるＨｏＴＩメッセージを、ホームプレフィックス及びそのプレフィックス長が記載されたホームプレフィックステストイニット（ＨＰＴＩ）メッセージに置き換えればよい。ＣＮ１０６０は、ＨＰＴＩメッセージを受信すると、ホームプレフィックステスト（ＨＰＴ）メッセージで応答を行う。ＭＮ１０４０のホームエージェント（すなわち、ＨＡ１０５０）は、本発明を使用して、無効なホームプレフィックスを含むＨＰＴアドレスを含むＨＰＴメッセージを破棄する。【０２０７】
また、ＭＮ１０４０は、外部ネットワークドメイン１３１０から割り当てられたプレフィックスＰ２を気付プレフィックスとして、ホームドメイン１２００から割り当てられたホームプレフィックスＰ１に関連付けるバインディングアップデートをＣＮ１０６０へ登録することが可能である。この登録のため、本発明に係るリターンルータビリティ処理において、ＭＮ１０４０は、ホームプレフィックスＰ１を含むＨＰＴＩメッセージにＨｏＴＩメッセージを置き換え、気付プレフィックスＰ２を含むＣＰＴＩメッセージにＣｏＴＩメッセージを置き換える。【０２０８】
ＣＮ１０６０は、ＨＰＴＩメッセージを受信すると、本発明に従って特定のテストアドレスへＨＰＴメッセージを送信する。ＨＡ１０５０は、テストアドレスに示されているプレフィックスが無効なものである場合にはＨＰＴメッセージを破棄し、テストアドレスに示されているプレフィックスが有効なものである場合にはＨＰＴメッセージを転送する。【０２０９】
また、ＣＮ１０６０は、ＣＰＴＩメッセージを受信すると、本発明に従って特定のテストアドレスへＣＰＴメッセージを送信する。ＬＭＡ１０２０は、テストアドレスに示されているプレフィックスが無効なものである場合にはＣＰＴメッセージを破棄し、テストアドレスに示されているプレフィックスが有効なものである場合にはＣＰＴメッセージを転送する。【０２１０】
また、図１４には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合のさらに別の一例を示すネットワーク構成が図示されている。なお、図１４は、ＭＮ１０４０が、ホームネットワークドメイン１４１０内の異なるＭＡＧ１４３０、１４３２とそれぞれ接続１４４０、１４４２を有する場合を示すものである。【０２１１】
図１４において、ホームネットワークドメイン１４１０はローカルモビリティ管理ドメインであり、ホームネットワークドメイン１４１０のＬＭＡとして機能するとともにＭＮ１０４０のホームエージェントとしても機能しているＬＭＡ／ＨＡ１４２０、ＭＡＧ１４３０、１４３２、１４３４を有している。また、ＬＭＡ／ＨＡ１４２０はインターネット１０００に接続されており、ＭＮ１０４０は、インターネット１０００を通じて、ＣＮ１０６０と通信を行うことが可能である。【０２１２】
ＭＮ１０４０は、ローカルモビリティ管理の動作に従って、それぞれの接続１４４０、１４４２に関連して２つの異なるプレフィックスを受信する。ここでは一例として、接続１４４０はプレフィックスＰ１を受信し、接続１４４２はプレフィックスＰ２を受信すると仮定する。この場合、ＭＮ１０４０はホームプレフィックスとしてプレフィックスを１つ選ぶことが可能であり、ＭＮ１０４０がホームプレフィックスとしてプレフィックスＰ１を選択すると仮定する。なお、プレフィックスＰ２は例えば気付プレフィックスとして使用されてもよい。【０２１３】
このような場合に、ＭＮ１０４０は、上述の図１３を参照しながら説明した処理と同一の処理を用いて、プレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１に関連付けてＬＭＡ／ＨＡ１４２０へ登録することが可能である。なお、プレフィックスＰ１及びプレフィックスＰ２は両方共、ＬＭＡ／ＨＡ１４２０によって割り当てられているので、ＬＭＡ／ＨＡ１４２０はその有効性を検証する必要はない。【０２１４】
また同様に、ＭＮ１０４０は、図１３を参照しながら説明した処理と同一の処理を用いて、プレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１に関連付けてＣＮ１０６０へ登録することも可能である。ＣＮ１０６０への登録の場合には、プレフィックスＰ１及びプレフィックスＰ２の所有権のテストを行うためにＣＮ１０６０から送信されたＨＰＴメッセージ及びＣＰＴメッセージは両方共、ＬＭＡ／ＨＡ１４２０によって検証される。【０２１５】
図１４に示されているシナリオにおいて、プレフィックスＰ１及びプレフィックスＰ２が隣接しており、より短いプレフィックスＰ０として扱えるような場合には、プレフィックスの検証が一括して行えることがある。例えば、プレフィックスＰ１が2201:ff00:1121:0200::/64、プレフィックスＰ２が2201:ff00:1121:0201::/64であるとした場合、実際に、これらのプレフィックスは、プレフィックスＰ０（2201:ff00:1121:0200::/63）として扱うことが可能である。【０２１６】
ＭＮ１０４０がプレフィックスＰ０を所有していると立証可能であれば、ＭＮ１０４０はプレフィックスＰ１及びプレフィックスＰ２の両方を所有していることが自動的に示される。ＭＮ１０４０がプレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１へ関連付けてＣＮ１０６０に登録を試みる場合には、ＭＮ１０４０は、プレフィックスＰ１及びプレフィックスＰ２のそれぞれに関して別々にプレフィックスの所有を宣言してもよいが、プレフィックスＰ１及びプレフィックスＰ２を包含するプレフィックスＰ０の所有を宣言してもよい。すなわち、ＭＮ１０４０は、ＣＰＴＩメッセージとＨＰＴＩメッセージを結合して、ＭＮ１０４０がプレフィックスＰ０を所有している旨を宣言する単一のホーム及び気付プレフィックステストイニット（ＨＣＰＴＩ）メッセージを送信してもよい。【０２１７】
ＣＮ１０６０は、このＨＣＰＴＩメッセージを受信すると、本発明に従ってテストアドレスをあて先アドレスとするホーム及び気付プレフィックステスト（ＨＣＰＴ）メッセージで応答を行う。ＨＡ１４２０は、テストアドレスに示されるプレフィックスが無効なものである場合にはこのＨＣＰＴメッセージを破棄し、テストアドレスに示されるプレフィックスが有効なものである場合にはＨＣＰＴメッセージを転送する。【０２１８】
ＭＮ１０４０は、ＨＣＰＴメッセージからトークンを抽出し、このトークンを用いて、ＣＮ１０６０へ送信されるＢＵメッセージ内のオーセンティケータ（認証情報）を生成する。このＢＵメッセージにより、ホームプレフィックスＰ１及び気付プレフィックスＰ２を所有していることが示される。【０２１９】
また、上述の図１３を用いて示した例のようなＭＮ１０４０がホームネットワークドメイン１３００と、外部ネットワークドメイン１３１０の両方に接続しているような場合だけでなく、ＭＮ１０４０がハンドオーバを行った場合（例えば、接続１３４０から接続１３４２への切り替えた場合）においても本発明を適用することが可能である。単に、異なるネットワークドメイン間での接続切り替えであれば、各ネットワークドメインへの接続時において、図１０に示した接続状況（特に外部ネットワークドメインへの接続中）に相当する動作を行えばよい。一方、ハンドオーバ前後のネットワークドメインにおいて、セルラネットワークのオペレータ間のような高度なローミング関係がある場合は、たとえＭＮ１０４０とネットワークドメインとの接続が１カ所であっても、プレフィックスの登録により、効率的な通信が可能となることがある。【０２２０】
このような場合としては、例えば、ハンドオーバ前後のネットワークドメインがホームであるか外部であるかにかかわらず（外部から外部という場合もあり得る）、ネットワークドメイン間の高度なローミング関係に基づいて、ハンドオーバ前に割り当てられていたプレフィックスをハンドオーバ後のネットワークドメインでも使用し続けることが可能な場合が挙げられる。このような場合にハンドオーバ後のネットワークドメインにおいても新たにそのネットワークドメインにおけるプレフィックスを取得すると、結果的に、ＭＮ１０４０は、複数のプレフィックスを割り当てられることになり、図１３の例で示したような、外部ネットワークプレフィックスの登録（及びその検証）を行うことが可能となる。また、ローミング関係によっては、ホームネットワークプレフィックスを外部ネットワークドメインのＨＡ相当の装置に登録（及びその検証）することも可能である。【０２２１】
さらに、上述の図１４を用いて示した例においても同様のことが言える。すなわち、ＭＮ１０４０の接続が１つであっても（例えば、接続１４４０のみ）ホームネットワークドメイン１４１０から、複数のプレフィックスを割り当てられるような場合である。例えば、異なる接続要件（接続先のネットワーク、遅延などの伝送パラメータの必要条件）に応じて異なるプレフィックス（ローカルモビリティドメインにおいてのトンネルなどに対応付けられる）を割り当てる場合、ＭＮ１０４０には複数のプレフィックスが割り当てられることになり、図１４の例で示したような気付プレフィックスの登録（及びその検証）を行うことが可能となる。【０２２２】
さらに、上述の状況を合わせたような環境においても、プレフィックスの登録を行う場合が考えられ、本発明の検証方法を用いることができる。図１５には、このような場合の例として、セルラネットワークにおいてＭＮ１０４０がハンドオーバを行う際に本発明を適用する場合について示されている。なお、この図１５では、Ｍ１０４０がホームネットワークドメイン１５００から外部ネットワークドメイン１５１０へハンドオーバを行う場合が一例として図示されているが、ハンドオーバの方向が逆の場合や外部ネットワークドメイン間のハンドオーバである場合についても同様に本発明の適用が可能である。【０２２３】
また、ホームネットワークドメイン１５００は、それぞれ異なるサービスを提供するためのサービスネットワーク（ここでは、サービスネットワーク（１Ｈ）１５２１、サービスネットワーク（２Ｈ）１５２２、サービスネットワーク（３Ｈ）１５２３が図示されている）を有しており、外部ネットワークドメイン１５１０は、それぞれ異なるサービスを提供するためのサービスネットワーク（ここでは、サービスネットワーク（１Ｖ）１５３１、サービスネットワーク（２Ｖ）１５３２、サービスネットワーク（４Ｖ）１５３４が図示されている）を有している。また、ホームネットワークドメイン１５００及び外部ネットワークドメイン１５１０はインターネット１０００によって接続されており、インターネット１０００を介して相互のネットワーク間で通信を行うことが可能である。【０２２４】
また、ＭＮ１０４０は、２つの異なるローカルモビリティ管理ドメイン（ホームネットワークドメイン１５００及び外部ネットワークドメイン１５１０）のいずれか一方へ接続することが可能である。ここでは、ＭＮ１０４０は、初めにホームネットワークドメイン１５００に接続しており、ハンドオーバを行って外部ネットワークドメイン１５１０への接続に切り替えるものとする。【０２２５】
ＭＮ１０４０は、初めにホームネットワークドメイン１５００に接続している状態において、ＬＭＡに相当するネットワーク内のエンティティ（ここでは例えば、Ｐ−ＧＷ（Ｈ）１５２０とする）から複数のネットワークプレフィックスを割り当てられ、これらのプレフィックスを用途に応じて使い分けているとする。このような場合としては、例えば、ＭＮ１０４０が、ホームネットワークドメイン１５００においてＰ−ＧＷ（Ｈ）１５２０を介して接続している各サービスネットワークやそのサービスごとに異なるプレフィックス（プレフィックスＰ１ｈ、Ｐ２ｈ、Ｐ３ｈ）を使用し、随時個別に状態の変更を行えるようになっている場合などが挙げられる。【０２２６】
ここで、ＭＮ１０４０が、ホームネットワークドメイン１５００から外部ネットワークドメイン１５１０にハンドオーバしたとする。ＭＮ１０４０は、外部ネットワークドメイン１５１０において、ローミング先のＰ−ＧＷ（Ｖ）１５３０から、用途（例えばサービスごと）に応じて複数のネットワークプレフィックスを割り当てられる（プレフィックスＰ１ｖ、Ｐ２ｖ、Ｐ４ｖ）。このとき、通常の接続状態においては、ＭＮ１０４０はホームネットワークドメイン１５００のサービスネットワークに接続できないか、若しくはそれぞれのドメイン外のネットワークを経由してしか接続できないかもしれない。つまり、ＭＮ１０４０は、プレフィックスＰ１ｈ、Ｐ２ｈ、Ｐ３ｈのパケットを受信することができないか、それぞれのオペレータ間をつなぐ、異なるネットワーク（図１５ではインターネット１０００）を通るトンネリング経路を介してしか受信できない。【０２２７】
このような場合においても、それぞれのオペレータにおけるサービスの性質が似ており、それぞれのサービスネットワークが高度なローミング関係により直接的に接続可能かもしれない。例えば、サービスネットワーク（１ｈ）とサービスネットワーク（１ｖ）、サービスネットワーク（２ｈ）とサービスネットワーク（２ｖ）がそれぞれ接続されている場合、これらのサービスネットワーク間における直接的な接続は、オペレータ外のネットワーク（例えば、インターネット１０００）を介して接続する場合に比べて、通信品質の管理や安全性が高いことが期待できる。このような場合、プレフィックスＰ１ｈにプレフィックスＰ１ｖを、プレフィックスＰ２ｈにプレフィックスＰ２ｖをそれぞれ気付プレフィックスとして登録すると、このようなサービスネットワークのパケットを相互に関連付けて扱うことが可能となる。また、その他の関連性に基づいて、例えば、プレフィックスＰ３ｈとプレフィックスＰ４ｖとの関連付けを行うことも可能である。【０２２８】
上述のようなネットワークプレフィックスの関連付けの登録においても気付プレフィックスの正当性（ここではＰ−ＧＷ（Ｖ）１５３０が割り当てたプレフィックスが正しくＰ−ＧＷ（Ｈ）１５２０に登録されるかどうか）を確認する必要があり、Ｐ−ＧＷ（Ｖ）１５３０がＬＭＡ、Ｐ−ＧＷ（Ｈ）１５２０がＨＡに相当するように本発明を適用することが可能である。【０２２９】
また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、ＭＡＧがモバイルノードの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。【０２３０】
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０２３１】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０２３２】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０２３３】
本発明は、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにするという効果を有しており、モバイルルータの情報を他のノードに登録するためのバインディングアップデートに係る技術や、ネットワークベースのローカルモビリティ管理ドメインに接続する移動端末に対するネットワークプレフィックスの割り当て及び検証に関連した技術、パケットが正確かつ所望の相手に確実に伝送されるようにするセキュリティに関連した技術などに適用可能である。
【図１】
2008155888.tif 000003
【図２】
2008155888.tif 000004
【図３Ａ】
2008155888.tif 000005
【図３Ｂ】
2008155888.tif 000006
【図４】
2008155888.tif 000007
【図５】
2008155888.tif 000008
【図６】
2008155888.tif 000009
【図７】
2008155888.tif 000010
【図８】
2008155888.tif 000011
【図９】
2008155888.tif 000012
【図１０】
2008155888.tif 000013
【図１１】
2008155888.tif 000014
【図１２】
2008155888.tif 000015
【図１３】
2008155888.tif 000016
【図１４】
2008155888.tif 000017
【図１５】
2008155888.tif 000018
【手続補正書】
【提出日】平成21年12月3日(2009.12.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークプレフィックス情報が割り当てられている通信装置と、前記通信装置又は前記ネットワークプレフィックス情報で特定されるネットワークに接続されているノードと通信を行うコレスポンデントノードとの間で伝送されるパケットを特定するパケット特定手段と、
前記パケット特定手段で特定された前記パケットを参照して、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して有効な値が使用されているか否かを判断するプレフィックス情報判断手段とを、
有するプレフィックス情報確認装置。
【請求項２】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると前記プレフィックス情報確認手段によって判断された場合に、その判断対象となった前記パケット特定手段で特定された前記パケットを破棄するパケット破棄手段を有する請求項１に記載のプレフィックス情報確認装置。
【請求項３】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると判断されて、その判断対象となった前記パケットが前記パケット破棄手段で破棄された場合には、その旨を前記通信装置に通知するパケット破棄通知手段を有する請求項２に記載のプレフィックス情報確認装置。
【請求項４】
前記プレフィックス情報判断手段における判断結果を前記コレスポンデントノードに通知する判断結果通知手段を有する請求項１に記載のプレフィックス情報確認装置。
【請求項５】
前記パケット特定手段が、前記ネットワークプレフィックス情報が前記通信装置から前記コレスポンデントノードに通知される際に交換されるパケットを特定するように構成されている請求項１に記載のプレフィックス情報確認装置。
【請求項６】
前記パケット特定手段が、前記コレスポンデントノードから前記通信装置に送信される前記パケットを特定するように構成されている請求項５に記載のプレフィックス情報確認装置。
【請求項７】
前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている請求項６に記載のプレフィックス情報確認装置。
【請求項８】
前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が、抽出された前記プレフィックス情報を参照して判断を行うように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項９】
前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記パケット特定手段が、前記プレフィックス情報の末尾の１の値を特定することによって前記プレフィックス情報を抽出するように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項１０】
前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報の長さを示す情報を抽出して、前記プレフィックス情報の長さに基づいて前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている請求項７に記載のプレフィックス情報確認装置。
【請求項１１】
前記パケット特定手段が、前記パケットのあて先アドレスに特定のビットパターンが含まれている前記パケットを特定するように構成されている請求項６に記載のプレフィックス情報確認装置。
【請求項１２】
前記特定のビットパターンを定めるビットパターン設定手段と、
前記特定のビットパターンが前記パケットのあて先アドレスに設定されるように、前記通信装置又は前記コレスポンデントノードに前記特定のビットパターンを通知するビットパターン通知手段とを、
有する請求項１１に記載のプレフィックス情報確認装置。
【請求項１３】
前記パケット特定手段が、前記通信装置から前記コレスポンデントノードからに送信される前記パケットを特定するように構成されている請求項５に記載のプレフィックス情報確認装置。
【請求項１４】
前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値か否かを判断するように構成されている請求項１３に記載のプレフィックス情報確認装置。
【請求項１５】
前記通信装置が、モバイルネットワークを有するモバイルルータであり、前記ネットワークプレフィックス情報が、前記モバイルネットワークを特定するモバイルネットワークプレフィックスである請求項１に記載のプレフィックス情報確認装置。
【請求項１６】
前記通信装置が、ネットワークベースでモビリティサポートを行うローカルモビリティ管理ドメイン内を移動している移動端末であり、前記ネットワークプレフィックス情報が、前記ローカルモビリティ管理ドメインから前記移動端末にユニークに割り当てられたネットワークプレフィックスである請求項１に記載のプレフィックス情報確認装置。
【請求項１７】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームアドレスと関連付けて登録する気付プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項１８】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームプレフィックスと関連付けて登録する気付プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項１９】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記ネットワークプレフィックス情報が、前記ホームドメインから割り当てられるホームプレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項２０】
前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記通信装置が、前記ネットワークプレフィックス情報が、前記ホームアドレスから割り当てられるホームプレフィックスとして使用する第１プレフィックス、及び、前記ホームプレフィックスに関連付けて登録する気付プレフィックスとして使用する第２プレフィックスである請求項１６に記載のプレフィックス情報確認装置。
【請求項２１】
前記第１プレフィックス及び前記第２プレフィックスが第３プレフィックスとして結合可能なように構成されており、前記第３プレフィックスに関して処理を行うことで前記ホームプレフィックス及び前記気付プレフィックスの両方に関して有効な値が使用されているか否かの確認をまとめて行う請求項２０に記載のプレフィックス情報確認装置。
【請求項２２】
ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記ネットワークプレフィックス情報の長さを示す情報を含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２３】
ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記テストメッセージであることを示す特定のビットパターンを含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２４】
前記テストメッセージであることを示すために使用可能な前記特定のビットパターンの通知を受けるビットパターン受信手段と、
前記ビットパターン受信手段で受信した前記特定のビットパターンの真正性を確認するビットパターン真正性確認手段とを、
有する請求項２３に記載の通信装置。
【請求項２５】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記通信装置から、前記通信装置に対して割り当てられているネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報の末尾の値が１であることを確認するように構成されている通信装置。
【請求項２６】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられているネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに、前記アドレスプレフィックスの後続のビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【請求項２７】
ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに末尾のビットが１に設定され、残りのビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する通信装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークなどのパケット交換型データ通信ネットワークにおけるネットワークを特定するプレフィックス情報の確認を行うプレフィックス情報確認装置及び通信装置に関し、特に、モバイルネットワークを有するモバイルルータが有しているモバイルネットワークのプレフィックス（モバイルネットワークプレフィックス）の確認を行うプレフィックス情報確認装置及び通信装置に関する。
【背景技術】
【０００２】
現在、多数のデバイスが、インターネットプロトコルを使用して、互いに通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、下記の非特許文献１において、ＩＰｖ６におけるモビリティサポートが規定されている。モバイルＩＰでは、各モバイルノードは、不変のホームドメインを持っている。モバイルノードが、自身のホームネットワークに接続している場合、モバイルノードには、ホームアドレス（ＨｏＡ：Home Address）として知られるプライマリグローバルアドレスが割り当てられる。一方、モバイルノードがホームネットワークから離れている場合、すなわち、他のフォーリンネットワークに接続している場合には、通常、モバイルノードには、気付アドレス（ＣｏＡ：Care-of Address）として知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートの考えは、モバイルノードが他のフォーリンネットワークに接続している場合でも、自身のホームアドレスで、そのモバイルノードまで到達可能となるようにするものである。
【０００３】
このような考えは、非特許文献１において、ホームエージェント（ＨＡ：Home Agent）と呼ばれるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）メッセージを使用して、ホームエージェントへの気付アドレスの登録を行う。これにより、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスに向けられたメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。
【０００４】
一方、個々のホストに関連したモビリティサポートの概念を、ノードを含むネットワーク用のモビリティサポートに拡張するネットワークモビリティ（ＮＥＭＯ：Network Mobility）サポートの考え方が存在している。このネットワークモビリティサポートは、モバイルネットワークがインターネットに対してどの接続ポイントで接続している場合でも、プライマリグローバルアドレスによってモバイルネットワーク内のノードに到達可能となる機構の提供を目的としている。
【０００５】
また、下記の非特許文献２ではネットワークモビリティに対する解決策が提案されている。ここでは、モバイルルータがホームエージェントに対してＢＵメッセージを送信する際に、モバイルルータによって、モバイルネットワーク内のノードが使用しているネットワークプレフィックスが指定される。このネットワークプリフィックスは、ＢＵに挿入されるネットワークプリフィックスオプションとして知られる特別なオプションを使用して指定される。これにより、ホームエージェントは、プレフィックスに基づくルーティングテーブルを構築し、その結果、ホームエージェントは、こうしたプレフィックスを有するあて先に送信されるパケットを、モバイルルータの気付アドレスとの間で確立されたトンネルに転送することが可能となる。
【０００６】
上記の技術によれば、モバイルルータが接続されている接続ポイントの位置にかかわらず、モバイルネットワークはインターネットに対して到達可能な状態となる。しかしながら、この際、モバイルネットワークから送受信されるパケットは、モバイルルータとそのホームエージェントとの間のトンネルを経由するため、ルーティングは完全に最適化された状態ではない。
【０００７】
この状態に対処するためには、例えば、ＮＥＭＯベーシック仕様を拡張して、コレスポンデントノード（ＣＮ：Correspondent Node）に、モバイルネットワークのネットワークプレフィックス（モバイルネットワークプレフィックス）が通知されるようにすればよい。モバイルネットワークプレフィックスの通知は、例えば、モバイルルータからコレスポンデントノードに送信されるＢＵメッセージに、モバイルネットワークプレフィックスの挿入が可能なネットワークプレフィックスオプションを追加することによって実現される。
【０００８】
しかしながら、ＢＵメッセージにネットワークプレフィックスオプションを追加するだけではセキュリティに問題が生じる。すなわち、モバイルＩＰｖ６では、モバイルノードは、経路最適化を行う際にコレスポンデントメッセージにＢＵメッセージを送信するために、事前にリターンルータビリティ（ＲＲ：Return Routability）処理を行って、ＢＵメッセージに記載するホームアドレス及び気付アドレスの正当な所有者であることを立証しなければならない。しかしながら、リターンルータビリティ処理では、ネットワークプレフィックスオプションに記載されるプレフィックスを所有している旨を立証することができない。
【０００９】
一方、これに対して、例えば下記の特許文献１には、ＸＲＲＰ（Extended Return Routability Procedure：拡張リターンルータビリティ処理）が開示されている。このＸＲＲＰでは、コレスポンデントノードにＭＮＴＩ（Mobile Network Test Init：モバイルネットワークテストイニット）メッセージが送信され、コレスポンデントノードがこのメッセージに対して暗号化トークンを返信する。そして、モバイルルータは、この暗号化トークンを取得し、この暗号化トークンに基づいて、ＢＵメッセージのトークンを拡張した情報を作成し、送信することによって、このモバイルルータによってモバイルネットワークプレフィックスが所有されていることが立証される。
【００１０】
また、下記の特許文献２には、ＲＲＮＰ（Return Routability for Network Prefix：ネットワークプレフィックスに対応したリターンルータビリティ処理）と呼ばれる方法が開示されている。このＲＲＮＰでは、コレスポンデントノードから、特定のモバイルネットワークプレフィックスに属するアドレスに暗号化トークンが送信される。そして、モバイルルータは、この暗号化トークンを受信（intercept）し、ＢＵメッセージにこの暗号化トークン（あるいは、暗号化トークンから得られる情報）を挿入する。
【特許文献１】米国特許公開２００６／１２０３１５
【特許文献２】国際公開公報ＷＯ２００６／００６７０６
【特許文献３】国際公開公報ＷＯ２００６／１１８３４２
【特許文献４】国際公開公報ＷＯ２００８／０２３８４５
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Devarapalli, V., et. al., "NEMO Basic Support Protocol", Internet Engineering Task Force Request For Comments 3963, January 2005.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、特許文献１や特許文献２に開示されている方法は、ネットワークのプレフィックスの所有を検証するためにモバイルＩＰｖ６のリターンルータビリティ処理を拡張したものであるが、必ずしも十分な検証とは言えない。
【００１２】
ここでは、モバイルルータがその所有を主張しているネットワークプレフィックスから選択されたアドレス（１つ又はいくつかのアドレス）に対してのみ、暗号化トークンの送信が行われることになる。すなわち、ネットワークプレフィックスに属するすべてのアドレスに関して検証されるわけではない。
【００１３】
例えば、６４ビット長のプレフィックスＰが割り当てられているモバイルルータが、コレスポンデントノードに対して、少し短い長さ（例えば、６０ビット長）のプレフィックス（すなわち、プレフィックスＰの６０ビットまでの部分）を所有していると主張（申告）することが可能である。このとき、コレスポンデントノードは、モバイルルータがその所有を主張しているプレフィックス（６０ビット長）からアドレスを選択して暗号化トークンの送信を行うが、ここで選択されるアドレスが、モバイルルータに実際に割り当てられているプレフィックスＰ（６４ビット長）を含んでしまう可能性はゼロではない。
【００１４】
そして、コレスポンデントノードが、モバイルルータに実際に割り当てられているプレフィックスＰ（６４ビット長）を含むアドレスを選択して送信を行った場合には、モバイルルータは暗号化トークンを取得して、プレフィックス（６０ビット長）を登録することができてしまい、モバイルルータが実際に所有しているプレフィックスＰ（６４ビット長）よりも大きいアドレス範囲を有するプレフィックス（６０ビット長）がモバイルルータに乗っ取られてしまうことになる。
【００１５】
一方、特許文献３に開示されている技術によれば、モバイルネットワークプレフィックスの所有に関して、完全な検証を行うことが可能である。しかしながら、この技術では、プレフィックスの所有権を認定する証明書を配布することが可能な信頼できる装置（アンカ）を、モバイルネットワークが存在するすべてのドメインに配置しなければならず、システムを大幅に拡張しなければならないという問題がある。
【００１６】
また、気付アドレスが送信元アドレスに存在していないバインディングアップデートをホームエージェントへ送信する場合に関しても、ホームエージェントが気付アドレスを検証する技術（例えば、特許文献４に開示されているような技術）が存在している。しかしながら、こうした処理においても、ネットワークプレフィックスオプションに記載されたプレフィックスの所有権は十分に立証されない。
【００１７】
上記の問題に鑑み、本発明は、ネットワークプレフィックス情報を所有している通信装置（モバイルルータや移動端末など）が実際には管理していないプレフィックス情報（ネットワークプレフィックス、あるいはモバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることを目的とする。
【課題を解決するための手段】
【００１８】
上記の目的を達成するため、本発明のプレフィックス情報確認装置は、ネットワークプレフィックス情報が割り当てられている通信装置と、前記通信装置又は前記ネットワークプレフィックス情報で特定されるネットワークに接続されているノードと通信を行うコレスポンデントノードとの間で伝送されるパケットを特定するパケット特定手段と、
前記パケット特定手段で特定された前記パケットを参照して、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して有効な値が使用されているか否かを判断するプレフィックス情報判断手段とを、
有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置（モバイルルータや移動端末など）が実際には管理していないプレフィックス情報（ネットワークプレフィックス、あるいはモバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００１９】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると前記プレフィックス情報確認手段によって判断された場合に、その判断対象となった前記パケット特定手段で特定された前記パケットを破棄するパケット破棄手段を有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録に係るパケットが伝送されないようにすることが可能となる。
【００２０】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報に関して無効な値が使用されていると判断されて、その判断対象となった前記パケットが前記パケット破棄手段で破棄された場合には、その旨を前記通信装置に通知するパケット破棄通知手段を有する。
この構成により、ネットワークプレフィックス情報を所有している通信装置は、有効ではないプレフィックス情報が利用されている理由でパケットが破棄された旨を明確に把握することが可能となる。
【００２１】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段における判断結果を前記コレスポンデントノードに通知する判断結果通知手段を有する。
この構成により、有効なプレフィックス情報が使用されている旨、又は有効ではないプレフィックス情報が使用されている旨をコレスポンデントノードに明確に通知することが可能となる。
【００２２】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記ネットワークプレフィックス情報が前記通信装置から前記コレスポンデントノードに通知される際に交換されるパケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２３】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記コレスポンデントノードから前記通信装置に送信される前記パケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２４】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２５】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットのあて先アドレスに含まれているプレフィックス情報に基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００２６】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記パケット特定手段が、前記プレフィックス情報の末尾の１の値を特定することによって前記プレフィックス情報を抽出するように構成されている。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００２７】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに含まれている前記プレフィックス情報の長さを示す情報を抽出して、前記プレフィックス情報の長さに基づいて前記パケットのあて先アドレスに含まれている前記プレフィックス情報を抽出し、前記プレフィックス情報判断手段が抽出された前記プレフィックス情報を参照して判断を行うように構成されている。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００２８】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記パケットのあて先アドレスに特定のビットパターンが含まれている前記パケットを特定するように構成されている。
この構成により、あて先アドレスに基づいて、プレフィックス情報が含まれているパケットが容易に特定できるようになる。
【００２９】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記特定のビットパターンを定めるビットパターン設定手段と、
前記特定のビットパターンが前記パケットのあて先アドレスに設定されるように、前記通信装置又は前記コレスポンデントノードに前記特定のビットパターンを通知するビットパターン通知手段とを、
有する。
この構成により、プレフィックス情報確認装置が、動的に特定のビットパターンを設定することが可能となる。
【００３０】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記パケット特定手段が、前記通信装置から前記コレスポンデントノードからに送信される前記パケットを特定するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３１】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記プレフィックス情報判断手段が、前記パケット特定手段で特定された前記パケットに含まれているプレフィックス情報が、前記通信装置に対して割り当てられている前記モバイルネットワークプレフィックス情報の有効な値か否かを判断するように構成されている。
この構成により、プレフィックス情報の登録に係る処理が行われる際に、コレスポンデントノードからネットワークプレフィックス情報を所有している通信装置に送信されるパケットに基づいて、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにすることが可能となる。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００３２】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記通信装置が、モバイルネットワークを有するモバイルルータであり、前記ネットワークプレフィックス情報が、前記モバイルネットワークを特定するモバイルネットワークプレフィックスである。
この構成により、モバイルルータが実際には管理していないプレフィックス情報（モバイルネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３３】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記通信装置が、ネットワークベースでモビリティサポートを行うローカルモビリティ管理ドメイン内を移動している移動端末であり、前記ネットワークプレフィックス情報が、前記ローカルモビリティ管理ドメインから前記移動端末にユニークに割り当てられたネットワークプレフィックスである。
この構成により、ネットワークベースのローカルモビリティ管理によってネットワークプレフィックス情報が割り当てられている移動端末が、実際には管理していないプレフィックス情報（ネットワークプレフィックス）の管理を行っているという誤った登録が行われないようにすることが可能となる。
【００３４】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームアドレスと関連付けて登録する気付プレフィックスである。
この構成により、移動端末が外部（ホームではない）のローカルモビリティ管理ドメインから取得したプレフィックスを気付プレフィックスとしてホームアドレスに関連付ける場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３５】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインとは異なる外部ドメインであり、前記ネットワークプレフィックス情報が、前記通信装置のホームプレフィックスと関連付けて登録する気付プレフィックスである。
この構成により、移動端末が外部（ホームではない）のローカルモビリティ管理ドメインから取得したプレフィックスを気付プレフィックスとしてホームプレフィックスに関連付ける場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３６】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記ネットワークプレフィックス情報が、前記ホームドメインから割り当てられるホームプレフィックスである。
この構成により、移動端末がホームのローカルモビリティ管理ドメインから取得したプレフィックスをホームプレフィックスとして使用する場合に、そのプレフィックスの真正性を確認することが可能となる。
【００３７】
さらに、本発明のプレフィックス情報確認装置では、上記の構成に加えて、前記ローカルモビリティ管理ドメインが、前記通信装置のホームドメインであり、前記通信装置が、前記ネットワークプレフィックス情報が、前記ホームアドレスから割り当てられるホームプレフィックスとして使用する第１プレフィックス、及び、前記ホームプレフィックスに関連付けて登録する気付プレフィックスとして使用する第２プレフィックスである。
この構成により、移動端末がホームのローカルモビリティ管理ドメインから取得した２つのプレフィックスをそれぞれホームプレフィックス及び気付プレフィックスとして関連付けて使用する場合に、これらのプレフィックスの真正性を確認することが可能となる。
【００３８】
さらに、本発明のプレフィックス情報確認装置は、上記の構成に加えて、前記第１プレフィックス及び前記第２プレフィックスが第３プレフィックスとして結合可能なように構成されており、前記第３プレフィックスに関して処理を行うことで前記ホームプレフィックス及び前記気付プレフィックスの両方に関して有効な値が使用されているか否かの確認をまとめて行う。
この構成により、例えば、連続した値を有するプレフィックスをホームプレフィックス及び気付プレフィックスとすることで、プレフィックスの真正性の確認の際には、これらのプレフィックスをまとめて１つのプレフィックスとして取り扱えるようになり、メッセージ数の削減やネットワークトラフィックの低減、各ノードにおける処理負荷の軽減などが実現されるようになる。
【００３９】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記ネットワークプレフィックス情報の長さを示す情報を含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００４０】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに前記テストメッセージであることを示す特定のビットパターンを含むアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスに基づいて、プレフィックス情報が含まれているパケットが容易に特定できるようになる。
【００４１】
さらに、本発明の通信装置は、上記の構成に加えて、前記テストメッセージであることを示すために使用可能な前記特定のビットパターンの通知を受けるビットパターン受信手段と、
前記ビットパターン受信手段で受信した前記特定のビットパターンの真正性を確認するビットパターン真正性確認手段とを、
有する。
この構成により、テストメッセージに使用するために通知された特定のビットパターンが正当なものであるか否かを確認することができるようになる。
【００４２】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報の末尾の値が１であることを確認するように構成されている。
この構成により、プレフィックス情報が、ネットワークプレフィックス情報を所有している通信装置が本当に所有しているネットワークに割り当てられているプレフィックス情報か否かを識別できるようになる。
【００４３】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに、前記アドレスプレフィックスの後続のビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになる。
【００４４】
また、上記の目的を達成するため、本発明の通信装置は、ネットワークプレフィックス情報が割り当てられている通信装置に対して割り当てられている前記ネットワークプレフィックス情報の有効な値は末尾が１に設定される旨が定められており、
前記通信装置から、前記通信装置に対して割り当てられている前記ネットワークプレフィックス情報の通知を受けた場合、通知された前記ネットワークプレフィックス情報に有効な値が使用されているか否かを確認するためのテストメッセージを生成するテストメッセージ生成手段と、
通知された前記ネットワークプレフィックス情報をアドレスプレフィックスとして含むとともに末尾のビットが１に設定され、残りのビット列がすべて０に設定されたアドレスを生成し、前記テストメッセージのあて先アドレスとして設定するあて先アドレス設定手段とを、
有する。
この構成により、あて先アドレスからプレフィックス情報の抽出が行えるようになるとともに、ルータエニキャストアドレスとの重複を避けることが可能となる。
【発明の効果】
【００４５】
本発明は、上記の構成を有しており、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにするという効果を有している。
【発明を実施するための最良の形態】
【００４６】
以下、図面を参照しながら、本発明の実施の形態について説明する。
【００４７】
本発明によれば、ホームエージェント（あるいは、ホームドメイン内の任意のノード）が、ホームエージェントに登録されているモバイルルータと、このモバイルルータ（あるいは、モバイルルータによって管理されているモバイルネットワークのモバイルネットワークノード）との通信を行っているコレスポンデントノードとの間のプレフィックス情報の交換におけるシグナリング処理に介入（intervene）することが可能となる。
【００４８】
このホームエージェントの介入によって、コレスポンデントノードは、有効なプレフィックス情報を確実に取得できるようになり、モバイルルータが実際には管理していないプレフィックス情報（モバイルネットワークプレフィックス）の管理を行っていると、コレスポンデントノードが誤って認識しないようにすることが可能となる。
【００４９】
ホームエージェントがシグナリングに介入する動作（本発明の目的を実現するための動作）は複数存在しており、以下、本発明に係る基本的な動作例について説明する。なお、これらの基本的な動作例から想到可能な技術に関しても、本発明の範囲であることは明らかである。また、本明細書におけるプレフィックス情報は、アドレスプレフィックスを形成する実際のビットパターンやビットパターンの長さ（プレフィックスレングスとも呼ばれる）を含むものであるが、これに限定されるものではないことは明らかである。
【００５０】
本発明の基本的な動作によれば、ホームエージェントが、プレフィックス情報判断部において、モバイルルータとコレスポンデントノードとの間で交換されるシグナリングパケット（パケット特定部において特定された、モバイルルータ又はその配下のモバイルノードとコレスポンデントノードとの間で伝送されるパケット）を精査することが可能である。そして、モバイルルータが実際には管理していないプレフィックスを管理しているようかのようにコレスポンデントノードが思い込んでしまうような情報（例えば、無効な値が使用されていると判断されたモバイルネットワークプレフィックス情報）がシグナリングパケットに含まれており、このシグナリングパケットの伝送が行われてしまうとコレスポンデントノードが誤って認識することになってしまう場合には、ホームエージェントのパケット破棄部は、このシグナリングパケットの破棄を行う。
【００５１】
図１には、本発明の実施の形態において、モバイルルータとコレスポンデントノードとの間でやり取りされるシグナリングを示すシーケンスチャートが図示されている。
【００５２】
図１には、モバイルルータ（ＭＲ）２０とコレスポンデントノード（ＣＮ）３０との間において、ＭＲ２０があるモバイルネットワークプレフィックスを管理している旨を示すバインディングをＣＮ３０に登録するために行われるシグナリングを示すシーケンスチャートの一例が図示されている。
【００５３】
なお、図１には、経路最適化が行われる際に一般的に利用される処理が図示されている。この処理によって経路最適化が実現され、ＣＮ３０がこのモバイルネットワークプレフィックスに属するアドレスあてにパケットを送信する場合に、ＭＲ２０の現在位置あてに直接パケットを転送できるようになる。なお、経路最適化におけるパケット転送では、例えばパケットのカプセル化が行われるが、他の技術を用いて経路最適化パケットの転送が行われてもよい。また、ＭＲ２０の現在位置としては、例えば、ＭＲ２０の気付アドレス（ＣｏＡ）を用いることが可能であるが、これに限定されるものではない。
【００５４】
なお、このようなシグナリング処理では、通常、ＭＲ２０がまず経路最適化開始メッセージをＣＮ３０に送信し、ＣＮ３０が暗号化によって生成されたトークンを含むテストメッセージによる応答を行う。そして、ＭＲ２０は、暗号化トークン（あるいは、例えばハッシュなどのような暗号化トークンから得られる情報）を含むバインディングアップデートメッセージを送信して、経路最適化処理が完了する。
【００５５】
例えば、リターンルータビリティ（ＲＲ：Return Routability）処理では、ホームテストイニット（ＨｏＴＩ：Home Test Init）メッセージ及び気付テストイニット（ＣｏＴＩ：Care-of Test Init）メッセージの２つの開始（イニット）メッセージが送信される。そして、これらに対応して、ホームテスト（ＨｏＴ：Home Test）メッセージ及び気付テスト（ＣｏＴ：Care-of Test）メッセージの２つの応答が行われる。
【００５６】
また、ＲＲＮＰ（特許文献２参照）では、モバイルネットワークのプレフィックス情報がＨｏＴＩメッセージによって通知され、受信者は、ネットワークプレフィックステスト（ＮＰＴ）メッセージによって応答を行う。このＮＰＴメッセージは、ホームエージェントを通じて転送される。
【００５７】
また、ＸＲＲＰ（特許文献１参照）では、モバイルネットワークのプレフィックス情報は、ホームエージェントを通じて転送されるモバイルネットワークノードテストイニット（ＭＮＮＴＩ）メッセージによって伝送され、受信者はモバイルネットワークノードテスト（ＭＮＮＴ）メッセージで応答を行う。
【００５８】
図１には、イニット（Ｉｎｉｔ：開始）メッセージ１１５及びテストメッセージ１２０のみを使用した一般的なメッセージシーケンスが図示されている。なお、開始メッセージ１１５は、ＲＲＮＰにおけるＨｏＴＩメッセージ、ＸＲＲＰにおけるＭＮＮＴＩメッセージや、その他の同様のシグナリング処理で使用される任意のテスト開始メッセージを表している。また、テストメッセージ１２０は、ＲＲＮＰにおけるＮＰＴメッセージ、ＸＲＲＰにおけるＭＮＮＴメッセージや、その他の同様のシグナリング処理で使用される任意のテスト応答メッセージを表している。また、シグナリング処理において通常存在するメッセージのいくつかに関しては、図面を簡単にするため、図１では図示省略されている。
【００５９】
図１に示される一般的なメッセージシーケンスにおいては、ＭＲ２０は、まず、トンネルパケット１１０によってイニットメッセージをホームエージェント（ＨＡ）１０にトンネルする。そして、ＨＡ１０はインナパケット（実際のイニットメッセージ１１５）をＣＮ３０に送信する。なお、イニットメッセージ１１５には、ＭＲ２０がその管理を主張するモバイルネットワークのプレフィックスに関する情報が含まれている。
【００６０】
一方、ＣＮ３０はテストメッセージ１２０によって応答を行う。このテストメッセージ１２０は、ＨＡ１０によって受信（intercept）されて、トンネルパケット１２５にカプセル化され、ＭＲ２０に転送される。そして、ＭＲ２０がＢＵメッセージ１３０をＣＮ３０に送信することによって、プレフィックス情報の通知が完了となる。
【００６１】
なお、ＢＵメッセージ１３０には、ＣＮ３０がＭＲ２０の実際の位置との関連付けを行うプレフィックス情報が含まれている。すなわち、以降、ＣＮ３０から、そのプレフィックスに存在する任意のあて先に送信されるパケットは、通常のルーティング機構を用いて転送される代わりに、実際の位置（例えば、ＭＲ２０の気付アドレス）に転送される。
【００６２】
さらに、テストメッセージ１２０には、ＭＲ２０によるテストメッセージの受信が成功したことをＣＮ３０が検証できるように、ＢＵメッセージ１３０に挿入されるべき任意の暗号化トークンが含まれている場合がある。
【００６３】
図１では、ホームエージェント（ＨＡ）１０が介入（干渉）して、ＭＲ２０とＣＮ３０との間で交換されているプレフィックス情報が有効であることを確認できる機会が２回存在する。これらの機会は図１のプロセス１５０及びプロセス１６０で示されている。
【００６４】
本発明の好適な実施の形態では、これらの一方又は両方の処理（図１のプロセス１５０、１６０）において、ＨＡ１０が、図２に図示されているアルゴリズムを使用して、有効なプレフィックス情報がＣＮ３０に送信されているか否かを確認することが可能である。
【００６５】
まず、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（イニットメッセージやテストメッセージなど）をチェックする。
【００６６】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ２５０において、ＨＡ１０は、そのパケットに含まれているプレフィックス情報が有効か否かをチェックする。
【００６７】
プレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。
【００６８】
図２に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むパケットを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。
【００６９】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。
【００７０】
なお、伝送されているプレフィックス情報が有効か否かをホームエージェントがチェックする際に、伝送されているプレフィックス情報がモバイルルータに割り当てられているモバイルネットワークプレフィックスに同一か否かをチェックすることのみで、プレフィックス情報の有効性のチェックが行われたとみなさないほうがよい。モバイルルータは、様々な使用目的に応じて、自身に割り当てられているプレフィックスを様々な異なるセグメントに分割している可能性がある。したがって、ホームエージェントは、モバイルルータに割り当てられているモバイルネットワークプレフィックスの範囲に含まれているプレフィックス情報に関しても、そのプレフィックス情報を有効なものとみなす必要がある。
【００７１】
上述のように、ＨＡ１０は、プロセス１６０（ＭＲ２０からトンネルされたパケットの転送の際）又はプロセス１５０（ＭＲ２０へパケットをトンネルする前）の２回の機会において、図２に示されているアルゴリズムを実行することが可能である。
【００７２】
以下、本発明の実施の形態において、上述の各プロセス１５０、１６０でアルゴリズムを実行する場合における様々な好適な動作について説明する。なお、以下では、様々な好適な動作に関して説明を行うが、これらの様々な好適な動作は任意に組み合わせて行われてもよく、また、プロセス１５０、１６０の両方でプレフィックス情報のチェックが行われてもよい。
【００７３】
例えば、本発明の実施の形態における好適な動作において、ホームエージェント（ＨＡ）１０は、プロセス１５０においてシグナリングを介入することが可能である。すなわち、ホームエージェント（ＨＡ）１０はＭＲ２０に転送されるべきパケットのチェックを行う。
【００７４】
このチェックによって、パケットにプレフィックス情報が含まれているか否かの判断が行われ、さらに、プレフィックス情報が含まれている場合には、そのプレフィックス情報が有効か無効かのチェックが行われる。そして、プレフィックス情報が無効なものである場合には、パケットは破棄される。
【００７５】
例えば、ＲＲＮＰでは、ＣＮ３０は、ＮＰＴメッセージをモバイルネットワーク内のあて先に送信する必要がある。ＨＡ１０は、このＮＰＴメッセージが有効か否かをチェックし、必要に応じて（すなわち、無効なプレフィックス情報が含まれている場合には）ＮＰＴメッセージの破棄を行う。
【００７６】
また、ＸＲＲＰでは、ＣＮ３０がＭＮＮＴメッセージを送信する必要がある。ＨＡ１０は、ＭＮＮＴメッセージが有効か否かをチェックして、必要に応じて（すなわち、無効なプレフィックス情報が含まれている場合には）ＭＮＮＴメッセージの破棄を行う。
【００７７】
しかしながら、通常、ホームエージェントはルータであり、ルータは多数のパケットの処理を行う。一方、通常、プレフィックス情報交換メッセージは、ホームエージェントが発送しなければならないパケットのうちのほんの少数に過ぎない。したがって、すべてのパケットに関してプレフィックス情報が含まれているか否かのチェックがホームエージェントによって行われた場合には、ホームエージェントの処理に過剰な負荷がかかることになる。
【００７８】
以下、本発明の実施の形態における好適な動作において、ホームエージェントの負荷を減少させる方法について説明する。この本発明に係る動作では、ホームエージェントは、もしパケットが通常の処理に従って転送されてしまった場合には、モバイルルータが実際には所有していないプレフィックスを所有しているかのように送信者（例えばＣＮ３０）が思い込んでしまうような、特定のあて先アドレスに送信されるパケットを破棄する。例えば、ホームエージェントは、有効ではないプレフィックス情報を含むアドレスあてに送信されるパケットを検出して、そのパケットの破棄を行う。
【００７９】
図３Ａには、この動作が起こり得る場合の特定のアドレスの一例が図示されている。あて先アドレス３００には、プレフィックス部３１０、長さ部３２０、そして、残りの部分３５０が含まれている。
【００８０】
プレフィックス部３１０には、モバイルルータによって所有されていると送信者が思っているプレフィックスが含まれる。また、長さ部３２０には、モバイルルータによって所有されていると送信者が思っているプレフィックスの長さの値が含まれる。また、残りの部分３５０はどんな値でもよいが、例えば、すべての値がゼロにセットされ、ホームエージェントがこの残りの部分３５０を容易に把握できるようにすることが望ましい。
【００８１】
なお、アドレスは固定長（例えば、ＩＰｖ６では１２８ビット）なので、長さ部３２０のサイズは固定され、あらかじめ周知であってもよい。例えば、ＩＰｖ６では、長さ部３２０の最大値は１２７であり、長さ部３２０は７ビット長あればよい。
【００８２】
したがって、この好適な動作によれば、ＭＲ２０がプレフィックスを管理していることを主張するイニットメッセージをＣＮ３０がＭＲ２０から受信した場合、ＣＮ３０は、テストメッセージ生成部においてテストメッセージを生成するとともに、あて先アドレス設定部において、プレフィックス部３１０がＰ１にセットされ、長さ部３２０がＬ１にセットされたアドレスをテストメッセージのあて先アドレス３００として設定して、テストメッセージの送信を行う。
【００８３】
ホームエージェント（ＨＡ）１０は、この場合、図４に図示されているアルゴリズムを使用することが可能である。なお、図４に図示されているフローチャートは、図２に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。
【００８４】
まず、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（イニットメッセージやテストメッセージなど）をチェックする。
【００８５】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ４２０において、ＨＡ１０は、あて先アドレスからプレフィックス情報を抽出する。この処理は、プレフィックス部３１０及び長さ部３２０を抽出することによって行われる。
【００８６】
次に、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。
【００８７】
図４に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるテストメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。
【００８８】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。
【００８９】
なお、上述の長さ部は送信アドレスなどによってプレフィックス情報の有効性を確認する場合の一例であり、このプレフィックスの長さの情報を、テストメッセージの別のオプションとして付加することも可能であり、別のメッセージとして送信するようにしてもよい。また、プレフィックス情報を別のメッセージとして通知してもよく、この場合は、テストメッセージとは独立に動作可能（バインディンクアップデートメッセージで経路最適化処理が完了するまでに確定すればよい）であるため、ＭＲがＨＡに対してＣＮへの通知を依頼して、ＨＡがＣＮに有効なプレフィックス情報を通知するようにしたり、ＣＮが確認のためにＨＡに問い合わせを行い、ＨＡがその問い合わせに対して有効なプレフィックス情報の応答を行ったりすることも可能である。
【００９０】
また、無効なプレフィックス情報を発見したことにより、テストメッセージを破棄した場合には、パケット破棄部においてパケットが破棄されたことを通知するＨＡのパケット破棄通知部は、ＭＲに対し、その旨を伝えることが望ましい。これにより、ＭＲは、ＣＮが経路最適化の機能を持っていない場合、若しくはイニットメッセージ、テストメッセージのいずれかが不着となってしまった場合と、プレフィックス情報が無効であった場合とを区別することができるようになる。その結果、ＭＲは、タイムアウトまで受信を待ち続けたり、無効なプレフィックス情報を含むイニットメッセージを繰り返し送信したりする無駄な処理を行わないようにすることが可能となり、また、実際は経路最適化可能なＣＮであるのに経路最適化を行わない（行えない）という誤った判断を防ぐことが可能となる。
【００９１】
上述の好適な動作では、ホームエージェントがテストメッセージに関する内容からプレフィックス情報を抽出する処理を行う必要がないという利点を有し、ホームエージェントにおける処理負荷が減少される。しかしながら、ホームエージェントは、依然として、モバイルルータにトンネルされるすべての受信パケットを精査して、パケットがテストメッセージか否かをチェックする必要がある。この処理は、ホームエージェントに大きな負荷を与える。
【００９２】
以下、下記の好適な動作に基づいて、ホームエージェントの負荷を更に減少させる方法について説明する。
【００９３】
この本発明に係る好適な動作では、ホームエージェントは、特定のあて先アドレスに送信されたパケットか否かのチェックを行い、あて先アドレスにあるビットパターンが含まれている場合のみ、そのパケットがテストメッセージか否かのチェックを行う。
【００９４】
図３Ｂには、この動作が起こり得る場合の特定のアドレスの一例が図示されている。図３Ｂでは、あて先アドレス３００には、プレフィックス部３１０、長さ部３２０に加えて、ビットパターン部３３０が含まれている。
【００９５】
上述のように、プレフィックス部３１０には、モバイルルータによって所有されていると送信者が思っているプレフィックスが含まれる。また、長さ部３２０には、モバイルルータによって所有されていると送信者が思っているプレフィックスの長さの値が含まれる。
【００９６】
また、ビットパターン部３３０には、特定のビットパターンが含まれており、ホームエージェントは、この特定のビットパターンを認識して、必要なチェックを行うことが可能である。このビットパターン部３３０の特定のビットパターンによって、ホームエージェントは、テストメッセージである可能性が高いパケットを選別することが可能となる。
【００９７】
また、残りの部分３５０はどんな値でもよいが、例えば、すべての値がゼロにセットされ、ホームエージェントがこの残りの部分３５０を容易に把握できるようにすることが望ましい。
【００９８】
なお、アドレスは固定長（例えば、ＩＰｖ６では１２８ビット）なので、長さ部３２０のサイズは固定され、あらかじめ周知であってもよい。例えば、ＩＰｖ６では、長さ部３２０の最大値は１２７であり、長さ部３２０は７ビット長あればよい。
【００９９】
また、ビットパターン部３３０は任意のサイズであってよい。ただし、ビットパターン部３３０が長ければ長いほど、許容されるプレフィックス長の最大値は小さくなる。一方、ビットパターン部３３０が短ければ短いほど、そのビットパターンを偶然に含んでいるあて先アドレスに送信された通常のパケット（すなわち、テストメッセージではないパケット）が検出される可能性が大きくなる。これにより、パケットをチェックするホームエージェントのリソースが余分に消費され、ホームエージェントの処理負荷は高くなる。したがって、ビットパターン部３３０は、プレフィックス長の大きさを考慮しながら、なるべく大きなサイズに設定されることが望ましい。
【０１００】
この動作では、ＣＮ３０は、ＭＲ２０がプレフィックス（プレフィックスＰ１及びプレフィックス長Ｌ１）を管理している旨を主張するイニットメッセージをＭＲ２０から受信すると、テストメッセージ生成部においてテストメッセージを生成するとともに、プレフィックス部３１０がＰ１にセットされ、長さ部３２０がＬ１にセットされ、ビットパターン部３３０が、このパケットがテストメッセージであることを示す周知の値にセットされたアドレスをテストメッセージのあて先アドレス３００として設定して、テストメッセージの送信を行う。
【０１０１】
ホームエージェント（ＨＡ）１０は、この場合、図５に図示されているアルゴリズムを使用することが可能である。なお、図５に図示されているフローチャートは、図４に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。
【０１０２】
まず、ステップＳ５００において、ＨＡ１０は、受信パケットのあて先アドレスのビットパターン部３３０に、テストメッセージであることを示す周知の値が含まれているか否かをチェックする。
【０１０３】
このような値がビットパターン部３３０に含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、テストメッセージであることを示す値がビットパターン部３３０に含まれている場合には、ステップＳ４２０において、ＨＡ１０は、あて先アドレスからプレフィックス情報を抽出する。この処理は、プレフィックス部３１０及び長さ部３２０を抽出することによって行われる。
【０１０４】
次に、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。
【０１０５】
図５に図示されているアルゴリズムを使用することで、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるテストメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。
【０１０６】
これによって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理しているとＣＮ３０が誤って思い込んでしまわないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。
【０１０７】
上述の好適な動作では、ホームエージェントは、パケットがテストメッセージであるか否かをチェックするために、すべての受信パケットの精査を行う必要がないという利点を有し、ホームエージェントにおける処理負荷がかなり減少される。
【０１０８】
上述の好適な動作では、ビットパターン部３３０に固定かつ周知の値を使用して、パケットがテストメッセージであることがホームエージェントに分かるようにすることによって、ホームエージェントの処理負荷を抑えている。しかしながら、ビットパターン部３３０に含まれる値は固定又は周知の値ではなく、動的にセットされてもよい。
【０１０９】
以下、ビットパターン部３３０に含まれる値を動的にセットする場合の好適な動作について説明する。
【０１１０】
この本発明に係る好適な動作では、ホームエージェントは、そのビットパターン設定部において、ビットパターン部３３０に関する設定を自ら行い、ビットパターン通知部からモバイルルータやコレスポンデントノードに対して、設定されたビットパターンを通知することが可能である。すなわち、ホームエージェントは、あて先アドレスのビットパターン部３３０にセットされる値を設定することが可能である。さらに、ホームエージェントは、ビットパターン部３３０が配置されるあて先アドレス内の位置を指定することも可能である。さらには、ホームエージェントは、ビットパターン部３３０のサイズを指定することも可能である。これにより、各ホームエージェントが、モバイルルータによって使用されているモバイルネットワークプレフィックスを考慮して、ビットパターン部３３０のサイズを決定することが可能となる。
【０１１１】
例えば、プレフィックス部３１０が非常に長いホームネットワークドメインでは、ホームエージェントは、小さなビットパターン部３３０を選択（設定）することで、長いモバイルネットワークプレフィックスを収容することが可能となる。
【０１１２】
逆に、プレフィックス部３１０が比較的短いホームネットワークドメインでは、ホームエージェントは、大きなビットパターン部３３０を選択（設定）することで、ビットパターン部３３０に一致するあて先ではあるが、テストメッセージではないパケットを誤認してしまう可能性を減らすことが可能となる。
【０１１３】
また、図６には、本発明の好適な実施の形態における好適な動作を実行するための方法を示すメッセージシーケンスチャートが図示されている。モバイルルータ（ＭＲ）２０が、ホームエージェント（ＨＡ）１０にＢＵメッセージ６１０を送信してＭＲ２０の気付アドレスを登録した後、ＨＡ１０は、ＢＡ（Binding Acknowledgement：バインディングアクノレッジメント）メッセージ６１５で応答を行う。
【０１１４】
ＨＡ１０のビットパターン通知部は、このＢＡメッセージ６１５に、コレスポンデントノードによって使用される特別なビットパターン（Ｓビット）に関する情報を挿入する。なお、この情報には、ビットパターン部の値、ビットパターン部のサイズ、アドレス内のビットパターンの位置などが含まれることが望ましい。
【０１１５】
ＭＲ２０は、気付アドレスに関連付けて自身のモバイルネットワークプレフィックスをコレスポンデントノード（ＣＮ３０）に登録しようとした場合には、ＣＮ３０にイニットメッセージを送信する。このイニットメッセージは、まず、ＨＡ２０に送信されるトンネルパケット６２０によってカプセル化される。
【０１１６】
次に、ＨＡ１０は、パケットのデカプセル化を行って、ＣＮ３０にイニットメッセージ６２５を転送する。イニットメッセージ６２５には、特別なビットパターンに関する情報が含まれている。これにより、ＣＮ３０は、プレフィックス部３１０、長さ部３２０、ビットパターン部３３０に適切な値がセットされたあて先アドレスに、テストメッセージ６３０を送信することが可能である。
【０１１７】
このとき、ＨＡ１０は、プロセス１５０において、テストメッセージ６３０のあて先アドレスに埋め込まれているプレフィックス情報の検証を行うことが可能である。さらに、ＨＡ１０は、プレフィックス情報が有効な場合には、テストメッセージをトンネルパケット６３５によってＭＲ２０に転送することが可能である。そして、ＭＲ２０は、ＢＵメッセージ６４０をＣＮ３０に送信して処理が完了となる。
【０１１８】
また、本発明に係る別の動作では、モバイルルータによって情報は使用されず、ホームエージェントやコレスポンデントノードでのみ使用されるので、モバイルルータ（ＭＲ）２０は、ビットパターンで使用されている実際の情報を知る必要はない。
【０１１９】
この動作では、ＭＲ２０は、トンネルパケット６２０によってカプセル化されるイニットメッセージ内にビットパターンの情報を挿入しない。その代わりに、ＭＲ２０は、トンネルパケット６２０内のイニットメッセージに空のフィールドをいくつか挿入し、ＨＡ１０がパケットをデカプセル化する際、ＣＮ３０へイニットメッセージ６２５を送信する前に、挿入された空のフィールドにビットパターン情報を記入する。このように、ビットパターン情報がＢＡメッセージ６１５でＭＲ２０に伝えられる必要はなく、ＭＲ２０がビットパターン情報を格納（記憶）する必要はない。
【０１２０】
また、ホームエージェントの処理負荷を低減させるため、ＭＲ２０は、例えば、ルータアラートオプションやあて先オプションの形式で、トンネルパケット６２０のアウタパケットのヘッダに任意の信号を挿入することが可能である。これによって、トンネルパケット６２０でカプセル化されているインナパケットにビットパターン情報を記入する必要があることがＨＡ１０に通知される。
【０１２１】
なお、ＨＡのビットパターン設定部において定めたビットパターンを使っていることを示す情報をＣＮに通知できることが望ましい。例えば、ＭＲが示すビットパターンを含むパケットに少なくともビットパターンが正しいことを示す暗号化署名をオプションとして付加したり（ＣＮはこの暗号化署名を確認する）、ビットパターンを記入する場合にはその真正性を示す暗号化署名も付加したり（ＣＮはこの暗号化署名を確認する）、ＭＲは単に特定のＣＮに対してビットパターンを通知するように依頼し、ＨＡがビットパターンをＣＮに通知したりしてもよい。これにより、ＣＮは、ビットパターン真正性確認部において、通知されたビットパターンの真正性を確認することが可能となり、ＭＲが恣意的にＨＡのチェックをすり抜ける目的でＨＡの意図しないビットパターンを挿入しないようにすることが可能となる。
【０１２２】
上述の好適な実施の形態では、ホームエージェント（ＨＡ）１０が図１に示すプロセス１５０でチェックを実行する場合について説明されている。なお、上述の説明のように、ホームエージェントは、図１に示すアルゴリズムのプロセス１６０を使用することも可能である。
【０１２３】
以下では、プロセス１６０でチェックが行われる場合の動作について説明する。この本発明に係る好適な動作では、ホームエージェントは、モバイルルータからトンネルされるパケットをチェックして、このパケットが配送されるとモバイルルータが実際には管理していないプレフィックスを管理しているとコレスポンデントノードが誤って信じてしまうような場合には、パケットの破棄を行う。
【０１２４】
図７には、本発明の実施の形態におけるホームエージェントがＭＲからトンネルパケットに関する処理を行うための好適なアルゴリズムが図示されている。
【０１２５】
図７に図示されているフローチャートは、図２に図示されているアルゴリズムを一部変更したものであり、両方のアルゴリズムにおいて同一のステップには、同一の参照符号が付されている。
【０１２６】
まず、ステップＳ７００において、ＨＡ１０は、受信パケットがモバイルルータからトンネルされたものであるか否かをチェックする。受信パケットがモバイルルータからトンネルされたものではない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。
【０１２７】
一方、受信パケットがモバイルルータからトンネルされたものである場合には、ステップＳ２１０において、ＨＡ１０は、転送されるべきパケットにプレフィックス情報を交換する信号（プレフィックス情報交換信号）が含まれているか否か（例えばイニットメッセージなど）をチェックする。
【０１２８】
このような信号がパケットに含まれていない場合には、ステップＳ２９０において、パケットは通常通り処理される（例えば、通常のＩＰパケットのルーティングルールに従って発送される）。一方、パケットにプレフィックス情報交換信号が含まれている場合には、ステップＳ２５０において、ＨＡ１０は、抽出されたプレフィックス情報が有効か否かをチェックする。
【０１２９】
抽出されたプレフィックス情報が有効な場合には、ステップＳ２９０において、パケットに関して通常のパケット処理（通常のパケット転送処理）が行われる。一方、プレフィックス情報が無効である場合には、ステップＳ２８０において、パケットは破棄される。
【０１３０】
図７に図示されているアルゴリズムを用いて、ＨＡ１０は、無効なプレフィックス情報を含むあて先アドレスに送信されるイニットメッセージを破棄し、図１に図示されているようなプレフィックス情報の交換処理が完遂しないように中止させることが可能となる。
【０１３１】
したがって、ＭＲ２０が実際には管理していないモバイルネットワークプレフィックスを管理していることをＣＮ３０が誤って信じないようにすることが可能となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。
【０１３２】
上述の好適な動作では、コレスポンデントノードが、特定のあて先アドレスにテストメッセージを送信するように構成される必要はなく、コレスポンデントノードの機能を変更する必要がないという利点がある。
【０１３３】
例えば、ＲＲＮＰが使用されている場合には、モバイルネットワークのプレフィックス情報はＨｏＴＩメッセージに挿入される。ホームエージェントは、モバイルルータから送信されるメッセージを精査して、無効なモバイルネットワークのプレフィックス情報が含まれているメッセージを破棄する。
【０１３４】
なお、ＨＡがプレフィックス情報の確認を行ったことを示す情報をＣＮに通知できることが望ましい。例えば、ＭＲが示すプレフィックス情報を含むパケット（イニットメッセージなど）に少なくともプレフィックス情報が正しいことを示す暗号化署名をオプションとして付加したり（ＣＮはこの暗号化署名を確認する）、ＭＲは単に特定のＣＮに対してプレフィックス情報を通知するように依頼し、ＨＡがプレフィックス情報をＣＮに通知したりしてもよい。これにより、ＣＮはこのプレフィックス情報がＨＡによりチェックされたものであるか否かを容易に確認することが可能となる。
【０１３５】
また、ＸＲＲＰが使用されている場合には、モバイルネットワークのプレフィックス情報はＭＮＮＴＩメッセージに挿入される。ホームエージェントは、モバイルルータからのメッセージを精査して、無効なモバイルネットワークのプレフィックス情報が含まれるメッセージを破棄する。
【０１３６】
なお、これらのＨｏＴＩメッセージやＭＮＮＴＩメッセージなどを破棄する際には、ホームエージェントは、モバイルルータに対してＩＣＭＰエラーメッセージによって警告を送信することが望ましい。
【０１３７】
上述の好適な動作では、有効なプレフィックス情報が確実に送信されるようにするために、ホームエージェントが、モバイルルータとコレスポンデントノードとの間でやり取りされるプレフィックス情報のシグナリングに対して動作を行う場合について説明されているが、さらにホームエージェントが、シグナリングが開始される前に、有効なプレフィックス情報が確実に送信されるようにするための動作を積極的に開始することも可能である。
【０１３８】
以下、ホームエージェントが、シグナリングが開始される前に有効なプレフィックス情報が確実に送信されるようにする場合の好適な動作について説明する。
【０１３９】
この本発明に係る好適な動作では、ホームエージェントは、正しいプレフィックス情報か否かをホームエージェントやその他のコレスポンデントノードが簡単に検証できるようにするとともに、悪意あるモバイルルータが実際には管理していないモバイルネットワークプレフィックスを所有している旨を主張することが難しくなるように、ホームドメイン内のモバイルルータに対してモバイルネットワークプレフィックスを割り当てる。
【０１４０】
好適な例では、ホームエージェントはモバイルルータに対して、最右端のビット（モバイルネットワークプレフィックスの末尾のビット）を常に１とするモバイルネットワークプレフィックスを割り当てるようにする。この場合、コレスポンデントノードは、モバイルルータが所有していると主張するモバイルネットワークプレフィックスのプレフィックス情報を含むイニットメッセージを検証する際に、このプレフィックス情報を含むとともに残りのビットがすべてゼロに設定されたあて先アドレスに対してテストメッセージの送信を行う。
【０１４１】
モバイルルータには、最右端のビットが１にセットされたモバイルネットワークプレフィックスが常に割り当てられているので、モバイルルータがより小さなプレフィックス（すなわち、より広いアドレス範囲）の所有を主張しようとしている場合には、主張されたプレフィックス及び残りがすべてゼロにセットされたあて先アドレスは、正しいモバイルネットワークプレフィックスの値を含むことはできず、このあて先アドレスに送信されるテストメッセージは、モバイルルータに到達不能となる。したがって、シグナリング処理は失敗に終わり、モバイルルータが試みたより小さなプレフィックスの所有を主張も失敗に終わる。
【０１４２】
図８には、この動作が行われる場合に、コレスポンデントノードがテストメッセージを送信する際に使用することが望ましいあて先アドレス８００が図示されている。
【０１４３】
プレフィックス部８１０には、モバイルルータによって所有されていると送信者が思っているプレフィックス（モバイルルータがイニットメッセージでその所有を主張したプレフィックス）が含まれる。なお、コレスポンデントノードは、テストメッセージを送信する前に、プレフィックス部８１０の最右端のビット８１５が１であることをチェックすることが望ましい。
【０１４４】
また、残りの部分８２０は、例えばすべてゼロにセットされることが望ましいが、プレフィックスの長さがアドレスと同一にはなり得ないので、コレスポンデントノードは、例えば、末尾のビット８３０の値を１にセットしてもよい。これにより、サブネットワークがすべてゼロに設定されたアドレス（オールゼロアドレス）は特別な目的（サブネットルータエニキャストアドレスなど）で使用される可能性があるが、こうした特別な意味を持つアドレスと重複しないあて先アドレスを実現することが可能となる。
【０１４５】
すなわち、コレスポンデントノードは、テストメッセージ生成部においてテストメッセージを生成するとともに、モバイルルータによって所有されていると思われるプレフィックスがプレフィックス部８１０にセットされ、残りの部分８２０がすべて０（あるいは末尾のビットのみ１）にセットされたアドレスをテストメッセージのあて先アドレス８００として設定して、テストメッセージの送信を行う。
【０１４６】
ここでは、プレフィックス部８１０の直後のビット配列がゼロにセットされていることが重要である。ゼロにセットされているビット配列の範囲が広いほど（すなわち、残りの部分８２０のサイズが大きいほど）、プレフィックス部８１０の範囲は狭くなり、モバイルルータは、実際に割り当てられているプレフィックスよりも小さなプレフィックスを主張することはより困難となる。以上のように、上述の本発明の好適な実施の形態によれば、本発明の目的は達成される。
【０１４７】
この好適な動作では、例えば、ホームエージェントは転送パケットの内容をチェックする必要はなく、ホームエージェントに更なる処理負荷が発生しないという利点がある。しかしながら、この動作では、ホームドメインが主にモバイルネットワークで構成されている場合には、ドメインのネットワークリソースが無駄になってしまう（使えなくなってしまう）可能性がある。すなわち、モバイルネットワークプレフィックスはすべて１にセットされたビットで終わるので、最後がゼロにセットされたプレフィックスはモバイルネットワークプレフィックスとしては使用不可能となる。
【０１４８】
以下、このようなプレフィックスのリソースの無駄を抑えることが可能なプレフィックス割り当て方法について説明する。
【０１４９】
ゼロビットで終わるプレフィックスは、更に小さな２つのプレフィックスに分割可能である。すなわち、ゼロビットで終わるプレフィックスは、さらに１ビット長いプレフィックス長のプレフィックスの末尾のビットが１で終わるものと、末尾のビットが０で終わるものに分割可能である。そして、末尾のビットが１で終わるものに関しては、モバイルネットワークプレフィックスとして割り当て可能である。一方、末尾のビットが０で終わるものは、更に１ビット長いプレフィックス（同様に、その末尾のビットが０のものと１のもの）に分割される。
【０１５０】
例えば、ホームエージェントが、６４ビット長で最後のビットが１にセットされたプレフィックスを割り当てたと仮定する。このとき、６４ビット長で最後のビットが０のプレフィックスは、６５ビット長の２つのプレフィックスに分割可能である。そして、６４ビット長で最後のビットが０であっても、６５ビット目が１であるプレフィックスに関しては、６５ビット長のモバイルネットワークプレフィックスとして割り当て可能である。一方、６５ビット長で末尾のビットが０で終わるプレフィックスは、更に６６ビット長の２つのプレフィックスに分割可能であり、同様にその半分（６６ビット目のビットが１のプレフィックス）がモバイルネットワークプレフィックスとして割り当て可能である。
【０１５１】
例えば１２８ビット長のＩＰｖ６アドレスの場合には、理論的には、この処理は１２７ビットのプレフィックス長まで続き、無駄なアドレス（使用不可能なアドレス）は、１つのみとなる。なお、１２６ビットのプレフィックス長のプレフィックスや、その他の非常に長いプレフィックス長のプレフィックスは、実際にはほとんど使用されることはない。
【０１５２】
なお、上述の動作を組み合わせて、あて先アドレスの選択の際に、このような末尾が１にセットされるモバイルネットワークプレフィックスを選択してもよい。例えば、このような組み合わせの一例として、図３Ａに図示されているあて先アドレスが図８に図示されているあて先アドレスに組み合わされた場合には、図３Ａにおいて、モバイルネットワークプレフィックスの末尾のビットは常に１にセットされる。このとき、コレスポンデントノードは、プレフィックス部にそのプレフィックス（末尾のビットが１のモバイルネットワークプレフィックス）がセットされたあて先アドレスを選択し、プレフィックス部の最右端のビットが１にセットされていることをチェックし、プレフィックス長の値を含む長さ部をアドレスの最右端のビットにセットして、残りの部分をゼロにセットする。
【０１５３】
また、別の組み合わせの一例として、図３Ｂに図示されているあて先アドレスが図８に図示されているアドレスに組み合わされてもよい。このとき、コレスポンデントノードは、プレフィックス部にそのプレフィックス（最右端のビットが１のモバイルネットワークプレフィックス）がセットされたあて先アドレスを選択し、プレフィックス部の最右端のビットが１にセットされていることをチェックし、プレフィックス長の値を含む長さ部をアドレスの最右端のビットにセットし、長さ部の直前にビットパターンを挿入してビットパターン部をセットし、残りの部分をゼロにセットする。
【０１５４】
また、図９には、本発明の実施の形態におけるホームエージェントの機能アーキテクチャの一例が図示されている。本発明に係るホームエージェントは、有効なプレフィックス情報が確実に送信されるようにする機能を有している。
【０１５５】
図９に図示されているホームエージェントは、パケットの送受信を行うための１つ又は複数のネットワークインタフェース９１０、パケットの発送方法や転送方法を決定するためのルーティングモジュール９２０、モバイルネットワークプレフィックスに関連したパケットのチェックを実行するためのモバイルネットワークプレフィックス（ＭＮＰ）チェック部９２５、ルーティングレイヤより上位に存在するすべてのプロトコル及びプログラムを包含する１つ又は複数のアプリケーション９３０、モバイルルータやモバイルネットワークプレフィックスの割り当てに関する構成情報を格納するデータベース９４０を有している。
【０１５６】
ネットワークインタフェース９１０は、このホームエージェントが任意の通信媒体を通じて別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。なお、関連する技術分野で周知の用語を用いると、ネットワークインタフェース９１０は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ及び通信プロトコルを表している。なお、図９に図示されているホームエージェントは、１つ又は複数のネットワークインタフェース９１０を有していてもよい。
【０１５７】
また、ルーティングモジュール９２０は、パケットの発送方法の決定処理を行う機能を有している。なお、関連する技術分野で周知の用語を用いると、ルーティングモジュール９２０は、ＩＰｖ４やＩＰｖ６などのレイヤ３（ネットワーク層）プロトコルの実装を表している。また、シグナル／データパス９５０を通じて、ルーティングモジュール９２０は、適切なネットワークインタフェース９１０との間で、パケットの送受信を行うことが可能である。
【０１５８】
また、ルーティングモジュール９２０内には、本発明の主要な機能を有するＭＮＰチェック部９２５が存在している。なお、ＭＮＰチェック部９２５は、例えば図２、４、５、７のいずれかに図示されているアルゴリズムを実行することが望ましい。パケットを発送する前に、ルーティングモジュール９２０はＭＮＰチェック部９２５にパケットを渡し、ＭＮＰチェック部９２５は、本発明に係るアルゴリズムに基づいてパケットの解析を行う。なお、上述のように、ＭＮＰチェック部９２５は、パケットの解析結果に基づいて、パケットの破棄を行う場合もある。また、本発明によって提供されるプレフィックス情報確認装置の主要な機能（パケット特定部、プレフィックス判断部、パケット破棄部、パケット破棄通知部、プレフィックス判断部による判断結果を通知する判断結果通知部、ビットパターン設定部の各構成要素によって実現される機能）は、主に、ＭＮＰチェック部９２５によって実行される。
【０１５９】
また、アプリケーション９３０は、通信プロトコルスタックのルーティングレイヤより上位に存在するすべてのプロトコルやプログラムを包含する機能ブロックである。このアプリケーション９３０には、例えば、ＴＣＰ（Transmission Control Protocol：送信制御プロトコル）、ＳＴＣＰ（Stream Control Transport Protocol ：ストリーム制御トランスポートプロトコル）、ＵＤＰ（User Datagram Protocol：ユーザデータグラムプロトコル）などのトランスポートレイヤプロトコルやセッションレイヤプロトコル、あるいは、他のノードとの通信に必要なプログラムやソフトウェアなどが含まれる。また、シグナルパス９５２を通じて、ルーティングモジュール９２０とアプリケーション９３０との間でパケット伝送が可能である。
【０１６０】
また、ＭＮＰチェック部９２５がパケットに記載されているモバイルネットワークプレフィックスが有効か否かを判断できるように、ＭＮＰチェック部９２５は、モバイルネットワークプレフィックスの割り当て方法に関する情報にアクセスできる必要がある。
【０１６１】
このような情報は例えばデータベース９４０に格納されており、ＭＮＰチェック部９２５は、シグナルパス９５４を通じて、データベース９４０に格納されている情報にアクセスすることが可能である。
【０１６２】
なお、モバイルルータは、割り当てられているプレフィックスを様々な目的（すなわち、モバイルネットワークプレフィックスとしての使用以外の目的も含まれる）に従って、異なるセグメントに分割している場合がある。したがって、ＭＮＰチェック部９２５は、送信されるプレフィックス情報が有効か否かをチェックする際に、送信されるプレフィックス情報がモバイルルータによって割り当てられたモバイルネットワークプレフィックスと同一であるか否かをチェックするだけではなく、モバイルネットワークプレフィックスとして使用されているプレフィックスの範囲に含まれているか否かをチェックし、モバイルネットワークプレフィックスの範囲に含まれるプレフィックス情報に関しても有効なプレフィックス情報とみなす必要がある。
【０１６３】
なお、シグナルパス９５０、９５２、９５４は、単に論理的なコネクションを表すものであり、物理的な配線がなされている必要はない。これらのシグナルパスは、例えば、関数又はサブルーチンの呼び出しを表している。
【０１６４】
さらに、データベース９４０は、図９では単一ユニットとして図示されているが、物理的なメモリバッファを使用して実装されてもよく、副次的なメモリにファイルとして格納されてもよい。さらに、データベース９４０は、単なるサブルーチンとして存在可能であり、実際の情報は、ホームエージェントとは物理的に異なるリモートサーバ（例えば、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ）に格納されており、そこから必要な情報のみが取得されるようにしてもよい。
【０１６５】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、様々な構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。例えば、上述の実施の形態では、モバイルルータとコレスポンデントノードとの間で交換されるパケットのチェックがホームエージェントによって実行されているが、ホームドメイン内の別のエンティティによって実行されてもよい。このようなチェックを実行する別のエンティティとしては、例えば、ホームドメインに導入されているファイアウォール（パケットをスキャンして伝送された場合に悪影響を及ぼす可能性のあるパケットを破棄する機能を有する）などが挙げられる。
【０１６６】
また、本発明のモバイルルータの機能は実体としてのモバイルルータだけでなく、論理的なエンティティとしてネットワーク内を移動する（移動下に相当する状態を配下のモバイルネットワークノードに提供する）場合にも適用可能である。これは接続ポイントを変更した場合であっても、配下のモバイルノードに対して通知するネットワークプレフィックスを変更しないようにするためにコンテキストトランスファ（Context Transfer）を行う場合などに相当する。
【０１６７】
さらに、本発明は必ずしもモバイルルータ及びモバイルネットワーク（モバイルネットワークプレフィックスの所有権の検証）への適用に限定されるものではなく、ネットワークプレフィックスの所有権の検証を行うための任意の状況において使用可能であることが当業者であれば分かるであろう。
【０１６８】
例えばネットワークベースのローカルモビリティ管理（ＮｅｔＬＭＭ：Network-based Local mobility management）プロトコルなどの動作において、モバイルノード（あるいは、移動端末又はＵＥ（User Equipment））に対してネットワークアクセス用のプレフィックスを割り当てることが可能である。
【０１６９】
例えば、モバイルノードがローカルモビリティ管理ドメイン（ＮｅｔＬＭＭドメイン）内を移動している際に、モバイルノードに対してユニークなプレフィックスが割り当てられるとする。このとき、モバイルノードは、このネットワークプレフィックスを使用して、モビリティサポートを受けたいと望むかもしれない。このような場合の具体例について、以下に説明する。
【０１７０】
図１０には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合の一例が図示されている。図１０において、ローカルネットワークドメイン１０１０はローカルモビリティ管理ドメインであり、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）１０２０、モバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）１０３０、１０３２、１０３４を有している。
【０１７１】
また、モバイルノード（ＭＮ：Mobile Node）１０４０がローカルネットワークドメイン１０１０内を移動している。また、ＭＮ１０４０は、インターネット１０００などのＬＭＡ１０２０から見て外側のネットワーク（ローカルモビリティサポートのドメイン外ではあるが、オペレータの専用ネットワークなどであって、一般的なインターネットとは異なるネットワークの場合もあり得る、以下では、こうした場合を含む総称としてインターネット１０００と記載する）を通じて、ホームエージェント（ＨＡ：Home Agent）１０５０やコレスポンデントノード（ＣＮ：Correspondent Node）１０６０と通信を行うことが可能である。
【０１７２】
ネットワークベースのローカルモビリティ管理の概念では、例えば、ＭＮ１０４０に対してユニークなプレフィックス（例えば、Ｐ１）が割り当てられる。このユニークなプレフィックスＰ１は、ＭＮ１０４０がローカルネットワークドメイン１０１０内を移動している限り、ＭＮ１０４０がどのＭＡＧ１０３０、１０３２、１０３４に接続しているかにかかわらず、ＭＮ１０４０に到達可能である。
【０１７３】
ＭＮ１０４０は、ＨＡ１０５０やＣＮ１０６０へ送信するバインディングアップデートにおける気付アドレスとして、このプレフィックスＰ１の使用を望む場合がある。バインディングアップデートによるプレフィックスＰ１の登録は、ＭＮ１０４０がプレフィックスＰ１の範囲内のアドレスすべてを気付アドレスとしてホームアドレスに関連付けることを意味する。
【０１７４】
このバインディングアップデートには、ＭＮ１０４０のホームアドレス、気付プレフィックス（Care-of Prefix）Ｐ１、気付プレフィックスＰ１のプレフィックス長が含まれている。このバインディングアップデートを受信した受信者は、プレフィックスＰ１を気付プレフィックスとして、ＭＮ１０４０のホームアドレスと関連付けて登録する。この登録により、バインディングアップデートの受信者はＭＮ１０４０のホームアドレスあてにパケットの転送又は送信を行おうとした場合、ホームアドレスの代わりに、気付プレフィックスＰ１の範囲内のアドレスの１つあてにパケットを発送することが可能となる。
【０１７５】
なお、プレフィックスＰ１のうちのどのアドレスを選択するかは、例えばバインディングアップデートの受信者（ＭＮ１０４０へパケットを発送する発送者、以下、パケット発送者と呼ぶ）によって決定される。例えば、パケット発送者は、ＭＮ１０４０へのアドレス（パケットの発送先アドレス）をランダムに選択してもよく、あるいは、何らかのフィルタルールに基づいてアドレスを選択してもよい（すなわち、プレフィックスＰ１の範囲内の各気付アドレスに対して異なるフローが送信される）。なお、ＭＮ１０４０が使用すべき特定のアドレス（あるいは、特定のアドレスと特定のフローとの組み合わせ）を指定してもよい。
【０１７６】
また、パケット発送者は、一連のパケット（ＭＮ１０４０へ発送されるパケット）が何らかの暗号化機能を使用してプレフィックスＰ１の範囲内のアドレスへ送信されるようにしてもよい。例えば、パケット発送者は、擬似ランダムのシーケンスナンバーを使用して、プレフィックスＰ１の範囲内から次に使用するアドレスを選択してもよい。これは、サービス不能攻撃（ＤｏＳ攻撃：Denial of service）への防御策としてスペクトラム拡散法を用いる方法と似ている。この場合、ＭＮ１０４０は、あて先アドレスがこの擬似ランダムのシーケンスナンバーに従わない受信パケットを無視する。
【０１７７】
また、別の例として、パケット発送者はパケットの暗号化のハッシュ値としてプレフィックスＰ１の範囲内のアドレスを選択してもよい。これにより、ＭＮ１０４０は、パケットの真正性を検証することが可能となる。
【０１７８】
一方、パケット発送者が、検証を行わずに、バインディングアップデート内に記載されている気付プレフィックスを真正のものとしてそのまま受け入れてしまう場合には、セキュリティの問題が生じる可能性がある。例えば、悪意のあるノードが、ＨＡ１０５０又はＣＮ１０６０に対して気付プレフィックスとしてプレフィックスＰ１の登録を行うことで、ＨＡ１０５０又はＣＮ１０６０からＭＮ１０４０（プレフィックスＰ１の実際の所有者）に対して、ＤｏＳ攻撃のように不要なデータが送信されるよう仕向けることが可能となり得る。
【０１７９】
このようなセキュリティの問題に対処するため、本発明に係る処理を拡張して、プレフィックスの所有に係る検証を行えるようにしてもよい。
【０１８０】
図１１及び図１２には、このようなセキュリティの問題に対処するための本発明の好適な適用例が示されている。図１１は、本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをホームエージェントへ送信する際の処理の一例を示すシーケンスチャートである。
【０１８１】
図１１において、まずＭＮ１０４０は、開始（イニット）メッセージ１１００をＨＡ１０５０へ送信する。このイニットメッセージ１１００は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１１０５にカプセル化され、最終的にイニットメッセージ１１１０として、ＨＡ１０５０に到達する。なお、イニットメッセージ１１１０では、ＭＮ１０４０が、あるプレフィックス長（例えば、Ｌ１）を有するプレフィックスＰ１を所有していることが示されている。
【０１８２】
そして、ＨＡ１０５０は、プレフィックスＰ１の範囲内のテストアドレスへテストメッセージ１１２０を送信する。このテストアドレスは、上述の実施の形態で挙げた任意の形式（例えば、プレフィックスＰ１及びそのプレフィックスＰ１の長さＬ１を含むアドレス）を用いることが可能である。例えばテストアドレスとして、最下位ビット（ＬＳＢ：least significant bit）にプレフィックスＰ１の長さＬ１の値を有するアドレスを用いることが可能であり、さらにテストアドレスであることを周知のビット（あるいはビットパターン）を有するようにしてもよい。
【０１８３】
ＬＭＡ１０２０は、テストメッセージ１１２０のテストアドレス内の周知のビットパターンを認識して、プロセス１１６５に示されるチェックを実行する。このチェックでは、ＬＭＡ１０２０は、図４又は図５に示すアルゴリズムを用いて、テストメッセージ１１２０を転送するかあるいは廃棄するかを決定する。
【０１８４】
テストアドレス内のプレフィックス情報が有効な場合には、テストメッセージ１１２０はトンネル化されてＭＡＧ１０３０へ転送される。そして、ＭＡＧ１０３０において、トンネル化されたテストメッセージ１１２５はデカプセル化され、最終的にテストメッセージ１１３０としてモバイルノードＭＮ１０４０に到達する。なお、このテストメッセージ１１２０には、ＭＮ１０４０がバインディングアップデート（ＢＵ）メッセージ１１４０に挿入可能な暗号化トークンが含まれていてもよい。
【０１８５】
このＢＵメッセージ１１４０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１１４５にカプセル化され、最終的に、ＢＵメッセージ１１５０としてＨＡ１０５０に到達する。ＨＡ１０５０は、バインディングアップデートの真正性をチェックしてから、気付プレフィックスＰ１をＭＮ１０４０のホームアドレスへ関連付けるバインディングを受け入れることが可能である。
【０１８６】
なお、図１１に示す動作の一例では、ＬＭＡ１０２０が、テストメッセージのチェック及び検証（すなわち、プロセス１１６５）を行っているが、ＬＭＡ１０２０の代わりにＭＡＧ１０３０が同一の処理（すなわち、プロセス１１７５）を実行してもよい。ＭＡＧ１０３０でこの処理が行われた場合には、ＬＭＡ１０２０の処理負荷が軽減されるという利点がある。
【０１８７】
さらに、上述のモバイルネットワークプレフィックスの検証を行う場合とは異なり、ローカルモビリティ管理ドメイン内に割り当てられているプレフィックスの所有権を検証する際に送信されるイニットメッセージは、プレフィックス情報確認装置（ＭＡＧ１０３０やＬＭＡ１０２０）を通過する。したがって、例えばプロセス１１７０やプロセス１１６０において、ＭＡＧ１０３０又はＬＭＡ１０２０が、ＭＮ１０４０から送信されたイニットメッセージのチェックを実行してもよい。
【０１８８】
この場合、テストアドレス内のプレフィックス情報が有効ではない場合には、ＬＭＡ１０２０又はＭＡＧ１０３０はイニットメッセージを破棄することが可能である。しかしながら、ＬＭＡ１０２０又はＭＡＧ１０３０はパケットの内容を精査せずにイニットメッセージを識別することができないため（特定のテストアドレス（あるいは特定のビットパターンを含むテストアドレス）をあて先とするテストメッセージとは異なり、アドレスによる判別は不可能）、ＬＭＡ１０２０又はＭＡＧ１０３０がイニットメッセージのチェックを実行する場合、ＬＭＡ１０２０又はＭＡＧ１０３０の処理負荷はかなり増大することになる。このため、特定のアドレス、ビットパターンなどをＨＡ１０５０から取得するなどして、イニットメッセージの識別を容易にできるようになっていることが望ましい。
【０１８９】
また、図１２は、本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをコレスポンデントノードへ送信する際の処理の一例を示すシーケンスチャートである。
【０１９０】
図１２に図示されている処理は、リターンルータビリティ処理を変更したものであり、ＣｏＴＩメッセージ及びＣｏＴメッセージをＣＰＴＩ（気付プレフィックステストイニット）メッセージ及びＣＰＴ（気付プレフィックステスト）メッセージで置き換えたものである。ＣＰＴＩメッセージは、本発明に係るイニットメッセージに対応するものであり、プレフィックスの所有権の検証処理を開始する際に使用される。一方、ＣＰＴメッセージは、本発明に係るテストメッセージに対応するものであり、プレフィックスの所有権の検証のためのイニットメッセージへの応答として使用される。
【０１９１】
図１２において、本発明に係るリターンルータビリティ処理を変更した処理を開始するために、モバイルノードＭＮ１０４０は、まず、ＨｏＴＩメッセージ１２００及びＣＰＴＩメッセージ１２４０をＣＮ１０６０へ送信する。ＨｏＴＩメッセージ１２００は、ＨＡ１０５０へのトンネルでカプセル化されて送信される。このＨｏＴＩメッセージ１２００は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２０３にカプセル化され、最終的に、トンネル化されたＨｏＴＩメッセージ（トンネルパケット）１２０５としてＨＡ１０５０に到達する。
【０１９２】
ＨＡ１０５０は、トンネルパケット１２０５をデカプセル化し、ＨｏＴＩメッセージ１２１０をＣＮ１０６０へ転送する。ＣＮ１０６０は、ＨｏＴＩメッセージ１２１０を受信すると、ＭＮ１０４０のホームアドレスから生成されたホーム鍵生成トークン（home keygen token）を含むＨｏＴメッセージ１２２０で応答を行う。
【０１９３】
ＨｏＴメッセージ１２２０は、まず、ＨＡ１０５０においてトンネルパケット１２２５にカプセル化され、さらに、ＬＭＡ１０２０においてトンネルパケット１２２８に更にカプセル化される。ＭＡＧ１０３０は、外部トンネルをデカプセル化してＭＮ１０４０に転送することで、ＭＮ１０４０は、ＨｏＴメッセージを含むトンネルパケットをＨＡ１０５０から受信する。
【０１９４】
ＣＰＴＩメッセージ１２４０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２４５にカプセル化され、最終的に、ＣＰＴＩメッセージ１２５０としてＣＮ１０６０に到達する。ＣＰＴＩメッセージ１２５０では、ＭＮ１０４０が、あるプレフィックス長（例えば、Ｌ１）を有するプレフィックスＰ１を所有していることが示されている。
【０１９５】
ＣＮ１０６０は、プレフィックスＰ１の範囲内のテストアドレスへＣＰＴメッセージ１２６０を送信する。このテストアドレスは、上述の実施の形態で挙げた任意の形式（例えば、プレフィックスＰ１及びそのプレフィックスＰ１の長さＬ１を含むアドレス）を用いることが可能である。例えばテストアドレスとして、最下位ビット（ＬＳＢ）にプレフィックスＰ１の長さＬ１の値を有するアドレスを用いることが可能であり、さらにテストアドレスであることを周知のビット（あるいはビットパターン）を有するようにしてもよい。
【０１９６】
ＬＭＡ１０２０は、ＣＰＴメッセージ１２６０のテストアドレス内の周知のビット（ビットパターン）を認識して、プロセス１２６３に示されるチェックを実行する。このチェックでは、ＬＭＡ１０２０は、図４又は図５に示すアルゴリズムを用いて、ＣＰＴメッセージ１２６０を転送するかあるいは破棄するかを決定する。
【０１９７】
テストアドレス内のプレフィックス情報が有効な場合には、ＣＰＴメッセージ１２６０はトンネル化されてＭＡＧ１０３０へ転送される。そして、ＭＡＧ１０３０において、トンネル化されたＣＰＴメッセージ１２６５はデカプセル化され、最終的にＣＰＴメッセージ１２７０としてモバイルノードＭＮ１０４０に到達する。なお、このＣＰＴメッセージ１２６０には、ホーム鍵生成トークンと同じような、ＣＰＴＩメッセージ１２５０に記載されている気付プレフィックスから得られる暗号化トークン（気付鍵生成トークン：care-of keygen token）が含まれていることが望ましい。
【０１９８】
ＭＮ１０４０は、ＨｏＴメッセージ１２３０及びＣＰＴメッセージ１２７０を受信すると、これらのメッセージに含まれるホーム鍵生成トークン及び気付鍵生成トークンを使用して、ＢＵメッセージ１２８０内で使用されるべきモビリティ管理鍵を生成することが可能である。このＢＵメッセージ１２８０は、必要に応じてローカルモビリティ管理プロトコルによってＭＡＧ１０３０からＬＭＡ１０２０へのトンネルパケット１２８５にカプセル化され、最終的に、ＢＵメッセージ１２９０としてＣＮ１０６０に到達する。
【０１９９】
ＣＮ１０６０は、バインディングアップデートの真正性をチェックしてから、気付プレフィックスＰ１をＭＮ１０４０のホームアドレスへ関連付けるバインディングを受け入れることが可能である。
【０２００】
図１０〜１２には、ＭＮ１０４０が、外部ローカルモビリティ管理ドメインから割り当てられたプレフィックスを気付プレフィックスとして使用するため、ホームアドレスと関連付けるシナリオが示されている。一方、ＭＮ１０４０のホームドメインがローカルモビリティ管理ドメインであってもよい。この場合、ＭＮ１０４０のホームアドレスに代わって、ＭＮ１０４０のみが使用するホームプレフィックス（ＭＮ１０４０に対してユニークに割り当てられているホームプレフィックス）を用いてもよい。以下、このようなシナリオに関して、図１３及び図１４を参照しながら説明する。
【０２０１】
図１３には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合の別の一例を示すネットワーク構成が図示されている。図１３において、ホームネットワークドメイン１３００はＭＮ１０４０のホームネットワークであり、ＨＡ１０５０、ＭＡＧ１３３０、１３３２を有している。一方、外部ネットワークドメイン１３１０はＭＮ１０４０にとって外部ネットワークであり、ＬＭＡ１０２０、ＭＡＧ１３３４、１３３６を有している。
【０２０２】
また、モバイルノード１０４０は、２つの異なるローカルモビリティ管理ドメイン（ホームネットワークドメイン１３００及び外部ネットワークドメイン１３１０）への２つの接続１３４０、１３４２を有しており、インターネット１０００を通じて、ＣＮ１０６０と通信を行うことが可能である。なお、接続１３４０は、ホームネットワークドメイン１３００のＭＡＧ１３３０へ接続されており、接続１３４２は、外部ネットワークドメイン１３１０のＭＡＧ１３３６へ接続されている。また、ホームネットワークドメイン１３００及び外部ネットワークドメイン１３１０もインターネット１０００によって接続されており、インターネット１０００を介して相互のネットワーク間で通信を行うことが可能である。
【０２０３】
この場合、ＭＮ１０４０は、接続１３４２から得られるプレフィックス（例えばＰ２とする）を気付プレフィックスとして関連付けて、ＨＡ１０５０へ登録することを望むかもしれない。このとき、ＭＮ１０４０が実際にプレフィックスＰ２を所有しているかどうかをＬＭＡ１０２０が検証できるようにするために、本発明を用いることが可能である。
【０２０４】
また、ＭＮ１０４０に対して、ホームネットワークドメイン（ローカルモビリティ管理ドメイン）１３００からプレフィックス（例えばＰ１とする）が割り当てられてもよく、この場合、プレフィックスＰ１から得られる任意のアドレスが、ホームアドレスとして取り扱われてもよい。したがって、ＭＮ１０４０がＣＮ１０６０との間で経路最適化を実行しようとした場合には、ＭＮ１０４０は、ホームプレフィックスＰ１から得られる単一のホームアドレスの代わりに、ホームプレフィックスＰ１そのものを記載してもよい。このようにホームプレフィックスＰ１そのものを登録することで、ＭＮ１０４０は、ＣＮ１０６０と通信を行う際に、プレフィックスＰ１の範囲内のアドレスをホームアドレスとして使用することが可能である。
【０２０５】
このためには、ＭＮ１０４０は、ホームアドレスに関連して送信されるＨｏＴＩメッセージを、ホームプレフィックス及びそのプレフィックス長が記載されたホームプレフィックステストイニット（ＨＰＴＩ）メッセージに置き換えればよい。ＣＮ１０６０は、ＨＰＴＩメッセージを受信すると、ホームプレフィックステスト（ＨＰＴ）メッセージで応答を行う。ＭＮ１０４０のホームエージェント（すなわち、ＨＡ１０５０）は、本発明を使用して、無効なホームプレフィックスを含むＨＰＴアドレスを含むＨＰＴメッセージを破棄する。
【０２０６】
また、ＭＮ１０４０は、外部ネットワークドメイン１３１０から割り当てられたプレフィックスＰ２を気付プレフィックスとして、ホームドメイン１２００から割り当てられたホームプレフィックスＰ１に関連付けるバインディングアップデートをＣＮ１０６０へ登録することが可能である。この登録のため、本発明に係るリターンルータビリティ処理において、ＭＮ１０４０は、ホームプレフィックスＰ１を含むＨＰＴＩメッセージにＨｏＴＩメッセージを置き換え、気付プレフィックスＰ２を含むＣＰＴＩメッセージにＣｏＴＩメッセージを置き換える。
【０２０７】
ＣＮ１０６０は、ＨＰＴＩメッセージを受信すると、本発明に従って特定のテストアドレスへＨＰＴメッセージを送信する。ＨＡ１０５０は、テストアドレスに示されているプレフィックスが無効なものである場合にはＨＰＴメッセージを破棄し、テストアドレスに示されているプレフィックスが有効なものである場合にはＨＰＴメッセージを転送する。
【０２０８】
また、ＣＮ１０６０は、ＣＰＴＩメッセージを受信すると、本発明に従って特定のテストアドレスへＣＰＴメッセージを送信する。ＬＭＡ１０２０は、テストアドレスに示されているプレフィックスが無効なものである場合にはＣＰＴメッセージを破棄し、テストアドレスに示されているプレフィックスが有効なものである場合にはＣＰＴメッセージを転送する。
【０２０９】
また、図１４には、本発明の実施の形態において、ローカルモビリティ管理に適用する場合のさらに別の一例を示すネットワーク構成が図示されている。なお、図１４は、ＭＮ１０４０が、ホームネットワークドメイン１４１０内の異なるＭＡＧ１４３０、１４３２とそれぞれ接続１４４０、１４４２を有する場合を示すものである。
【０２１０】
図１４において、ホームネットワークドメイン１４１０はローカルモビリティ管理ドメインであり、ホームネットワークドメイン１４１０のＬＭＡとして機能するとともにＭＮ１０４０のホームエージェントとしても機能しているＬＭＡ／ＨＡ１４２０、ＭＡＧ１４３０、１４３２、１４３４を有している。また、ＬＭＡ／ＨＡ１４２０はインターネット１０００に接続されており、ＭＮ１０４０は、インターネット１０００を通じて、ＣＮ１０６０と通信を行うことが可能である。
【０２１１】
ＭＮ１０４０は、ローカルモビリティ管理の動作に従って、それぞれの接続１４４０、１４４２に関連して２つの異なるプレフィックスを受信する。ここでは一例として、接続１４４０はプレフィックスＰ１を受信し、接続１４４２はプレフィックスＰ２を受信すると仮定する。この場合、ＭＮ１０４０はホームプレフィックスとしてプレフィックスを１つ選ぶことが可能であり、ＭＮ１０４０がホームプレフィックスとしてプレフィックスＰ１を選択すると仮定する。なお、プレフィックスＰ２は例えば気付プレフィックスとして使用されてもよい。
【０２１２】
このような場合に、ＭＮ１０４０は、上述の図１３を参照しながら説明した処理と同一の処理を用いて、プレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１に関連付けてＬＭＡ／ＨＡ１４２０へ登録することが可能である。なお、プレフィックスＰ１及びプレフィックスＰ２は両方共、ＬＭＡ／ＨＡ１４２０によって割り当てられているので、ＬＭＡ／ＨＡ１４２０はその有効性を検証する必要はない。
【０２１３】
また同様に、ＭＮ１０４０は、図１３を参照しながら説明した処理と同一の処理を用いて、プレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１に関連付けてＣＮ１０６０へ登録することも可能である。ＣＮ１０６０への登録の場合には、プレフィックスＰ１及びプレフィックスＰ２の所有権のテストを行うためにＣＮ１０６０から送信されたＨＰＴメッセージ及びＣＰＴメッセージは両方共、ＬＭＡ／ＨＡ１４２０によって検証される。
【０２１４】
図１４に示されているシナリオにおいて、プレフィックスＰ１及びプレフィックスＰ２が隣接しており、より短いプレフィックスＰ０として扱えるような場合には、プレフィックスの検証が一括して行えることがある。例えば、プレフィックスＰ１が2201:ff00:1121:0200::/64、プレフィックスＰ２が2201:ff00:1121:0201::/64であるとした場合、実際に、これらのプレフィックスは、プレフィックスＰ０（2201:ff00:1121:0200::/63）として扱うことが可能である。
【０２１５】
ＭＮ１０４０がプレフィックスＰ０を所有していると立証可能であれば、ＭＮ１０４０はプレフィックスＰ１及びプレフィックスＰ２の両方を所有していることが自動的に示される。ＭＮ１０４０がプレフィックスＰ２を気付プレフィックスとしてホームプレフィックスであるプレフィックスＰ１へ関連付けてＣＮ１０６０に登録を試みる場合には、ＭＮ１０４０は、プレフィックスＰ１及びプレフィックスＰ２のそれぞれに関して別々にプレフィックスの所有を宣言してもよいが、プレフィックスＰ１及びプレフィックスＰ２を包含するプレフィックスＰ０の所有を宣言してもよい。すなわち、ＭＮ１０４０は、ＣＰＴＩメッセージとＨＰＴＩメッセージを結合して、ＭＮ１０４０がプレフィックスＰ０を所有している旨を宣言する単一のホーム及び気付プレフィックステストイニット（ＨＣＰＴＩ）メッセージを送信してもよい。
【０２１６】
ＣＮ１０６０は、このＨＣＰＴＩメッセージを受信すると、本発明に従ってテストアドレスをあて先アドレスとするホーム及び気付プレフィックステスト（ＨＣＰＴ）メッセージで応答を行う。ＨＡ１４２０は、テストアドレスに示されるプレフィックスが無効なものである場合にはこのＨＣＰＴメッセージを破棄し、テストアドレスに示されるプレフィックスが有効なものである場合にはＨＣＰＴメッセージを転送する。
【０２１７】
ＭＮ１０４０は、ＨＣＰＴメッセージからトークンを抽出し、このトークンを用いて、ＣＮ１０６０へ送信されるＢＵメッセージ内のオーセンティケータ（認証情報）を生成する。このＢＵメッセージにより、ホームプレフィックスＰ１及び気付プレフィックスＰ２を所有していることが示される。
【０２１８】
また、上述の図１３を用いて示した例のようなＭＮ１０４０がホームネットワークドメイン１３００と、外部ネットワークドメイン１３１０の両方に接続しているような場合だけでなく、ＭＮ１０４０がハンドオーバを行った場合（例えば、接続１３４０から接続１３４２への切り替えた場合）においても本発明を適用することが可能である。単に、異なるネットワークドメイン間での接続切り替えであれば、各ネットワークドメインへの接続時において、図１０に示した接続状況（特に外部ネットワークドメインへの接続中）に相当する動作を行えばよい。一方、ハンドオーバ前後のネットワークドメインにおいて、セルラネットワークのオペレータ間のような高度なローミング関係がある場合は、たとえＭＮ１０４０とネットワークドメインとの接続が１カ所であっても、プレフィックスの登録により、効率的な通信が可能となることがある。
【０２１９】
このような場合としては、例えば、ハンドオーバ前後のネットワークドメインがホームであるか外部であるかにかかわらず（外部から外部という場合もあり得る）、ネットワークドメイン間の高度なローミング関係に基づいて、ハンドオーバ前に割り当てられていたプレフィックスをハンドオーバ後のネットワークドメインでも使用し続けることが可能な場合が挙げられる。このような場合にハンドオーバ後のネットワークドメインにおいても新たにそのネットワークドメインにおけるプレフィックスを取得すると、結果的に、ＭＮ１０４０は、複数のプレフィックスを割り当てられることになり、図１３の例で示したような、外部ネットワークプレフィックスの登録（及びその検証）を行うことが可能となる。また、ローミング関係によっては、ホームネットワークプレフィックスを外部ネットワークドメインのＨＡ相当の装置に登録（及びその検証）することも可能である。
【０２２０】
さらに、上述の図１４を用いて示した例においても同様のことが言える。すなわち、ＭＮ１０４０の接続が１つであっても（例えば、接続１４４０のみ）ホームネットワークドメイン１４１０から、複数のプレフィックスを割り当てられるような場合である。例えば、異なる接続要件（接続先のネットワーク、遅延などの伝送パラメータの必要条件）に応じて異なるプレフィックス（ローカルモビリティドメインにおいてのトンネルなどに対応付けられる）を割り当てる場合、ＭＮ１０４０には複数のプレフィックスが割り当てられることになり、図１４の例で示したような気付プレフィックスの登録（及びその検証）を行うことが可能となる。
【０２２１】
さらに、上述の状況を合わせたような環境においても、プレフィックスの登録を行う場合が考えられ、本発明の検証方法を用いることができる。図１５には、このような場合の例として、セルラネットワークにおいてＭＮ１０４０がハンドオーバを行う際に本発明を適用する場合について示されている。なお、この図１５では、Ｍ１０４０がホームネットワークドメイン１５００から外部ネットワークドメイン１５１０へハンドオーバを行う場合が一例として図示されているが、ハンドオーバの方向が逆の場合や外部ネットワークドメイン間のハンドオーバである場合についても同様に本発明の適用が可能である。
【０２２２】
また、ホームネットワークドメイン１５００は、それぞれ異なるサービスを提供するためのサービスネットワーク（ここでは、サービスネットワーク（１Ｈ）１５２１、サービスネットワーク（２Ｈ）１５２２、サービスネットワーク（３Ｈ）１５２３が図示されている）を有しており、外部ネットワークドメイン１５１０は、それぞれ異なるサービスを提供するためのサービスネットワーク（ここでは、サービスネットワーク（１Ｖ）１５３１、サービスネットワーク（２Ｖ）１５３２、サービスネットワーク（４Ｖ）１５３４が図示されている）を有している。また、ホームネットワークドメイン１５００及び外部ネットワークドメイン１５１０はインターネット１０００によって接続されており、インターネット１０００を介して相互のネットワーク間で通信を行うことが可能である。
【０２２３】
また、ＭＮ１０４０は、２つの異なるローカルモビリティ管理ドメイン（ホームネットワークドメイン１５００及び外部ネットワークドメイン１５１０）のいずれか一方へ接続することが可能である。ここでは、ＭＮ１０４０は、初めにホームネットワークドメイン１５００に接続しており、ハンドオーバを行って外部ネットワークドメイン１５１０への接続に切り替えるものとする。
【０２２４】
ＭＮ１０４０は、初めにホームネットワークドメイン１５００に接続している状態において、ＬＭＡに相当するネットワーク内のエンティティ（ここでは例えば、Ｐ−ＧＷ（Ｈ）１５２０とする）から複数のネットワークプレフィックスを割り当てられ、これらのプレフィックスを用途に応じて使い分けているとする。このような場合としては、例えば、ＭＮ１０４０が、ホームネットワークドメイン１５００においてＰ−ＧＷ（Ｈ）１５２０を介して接続している各サービスネットワークやそのサービスごとに異なるプレフィックス（プレフィックスＰ１ｈ、Ｐ２ｈ、Ｐ３ｈ）を使用し、随時個別に状態の変更を行えるようになっている場合などが挙げられる。
【０２２５】
ここで、ＭＮ１０４０が、ホームネットワークドメイン１５００から外部ネットワークドメイン１５１０にハンドオーバしたとする。ＭＮ１０４０は、外部ネットワークドメイン１５１０において、ローミング先のＰ−ＧＷ（Ｖ）１５３０から、用途（例えばサービスごと）に応じて複数のネットワークプレフィックスを割り当てられる（プレフィックスＰ１ｖ、Ｐ２ｖ、Ｐ４ｖ）。このとき、通常の接続状態においては、ＭＮ１０４０はホームネットワークドメイン１５００のサービスネットワークに接続できないか、若しくはそれぞれのドメイン外のネットワークを経由してしか接続できないかもしれない。つまり、ＭＮ１０４０は、プレフィックスＰ１ｈ、Ｐ２ｈ、Ｐ３ｈのパケットを受信することができないか、それぞれのオペレータ間をつなぐ、異なるネットワーク（図１５ではインターネット１０００）を通るトンネリング経路を介してしか受信できない。
【０２２６】
このような場合においても、それぞれのオペレータにおけるサービスの性質が似ており、それぞれのサービスネットワークが高度なローミング関係により直接的に接続可能かもしれない。例えば、サービスネットワーク（１ｈ）とサービスネットワーク（１ｖ）、サービスネットワーク（２ｈ）とサービスネットワーク（２ｖ）がそれぞれ接続されている場合、これらのサービスネットワーク間における直接的な接続は、オペレータ外のネットワーク（例えば、インターネット１０００）を介して接続する場合に比べて、通信品質の管理や安全性が高いことが期待できる。このような場合、プレフィックスＰ１ｈにプレフィックスＰ１ｖを、プレフィックスＰ２ｈにプレフィックスＰ２ｖをそれぞれ気付プレフィックスとして登録すると、このようなサービスネットワークのパケットを相互に関連付けて扱うことが可能となる。また、その他の関連性に基づいて、例えば、プレフィックスＰ３ｈとプレフィックスＰ４ｖとの関連付けを行うことも可能である。
【０２２７】
上述のようなネットワークプレフィックスの関連付けの登録においても気付プレフィックスの正当性（ここではＰ−ＧＷ（Ｖ）１５３０が割り当てたプレフィックスが正しくＰ−ＧＷ（Ｈ）１５２０に登録されるかどうか）を確認する必要があり、Ｐ−ＧＷ（Ｖ）１５３０がＬＭＡ、Ｐ−ＧＷ（Ｈ）１５２０がＨＡに相当するように本発明を適用することが可能である。
【０２２８】
また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、ＭＡＧがモバイルノードの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。
【０２２９】
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０２３０】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０２３１】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０２３２】
本発明は、ネットワークプレフィックス情報を所有している通信装置が実際には管理していないプレフィックス情報の管理を行っているという誤った登録が行われないようにするという効果を有しており、モバイルルータの情報を他のノードに登録するためのバインディングアップデートに係る技術や、ネットワークベースのローカルモビリティ管理ドメインに接続する移動端末に対するネットワークプレフィックスの割り当て及び検証に関連した技術、パケットが正確かつ所望の相手に確実に伝送されるようにするセキュリティに関連した技術などに適用可能である。
【図面の簡単な説明】
【０２３３】
【図１】本発明の実施の形態において、モバイルルータとコレスポンデントノードとの間で行われる一般的な経路最適化シグナリング処理の一例を示すシーケンスチャート
【図２】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第１の例を示すフローチャート
【図３Ａ】本発明の実施の形態において使用されるあて先アドレスの第１の例を示す図
【図３Ｂ】本発明の実施の形態において使用されるあて先アドレスの第２の例を示す図
【図４】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第２の例を示すフローチャート
【図５】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第３の例を示すフローチャート
【図６】本発明の実施の形態において、ホームエージェントがテストパケットに挿入される特別なビットパターンを動的に設定する場合の処理の一例を示すシーケンスチャート
【図７】本発明の実施の形態におけるホームエージェント（プレフィックス情報確認装置）で実行されるアルゴリズムの第４の例を示すフローチャート
【図８】本発明の実施の形態において使用されるあて先アドレスの第３の例を示す図
【図９】本発明の実施の形態におけるホームエージェントの機能アーキテクチャの一例を示す図
【図１０】本発明の実施の形態において、ローカルモビリティ管理に適用する場合の一例を示すネットワーク構成図
【図１１】本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをホームエージェントへ送信する際の処理の一例を示すシーケンスチャート
【図１２】本発明の実施の形態において、モバイルノードが気付プレフィックスを含むバインディングアップデートをコレスポンデントノードへ送信する際の処理の一例を示すシーケンスチャート
【図１３】本発明の実施の形態において、ローカルモビリティ管理に適用する場合の別の一例を示すネットワーク構成図
【図１４】本発明の実施の形態において、ローカルモビリティ管理に適用する場合のさらに別の一例を示すネットワーク構成図
【図１５】本発明の実施の形態において、モバイルノードがセルラネットワークにおいてハンドオーバを行う場合の一例を示すネットワーク構成図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008155888.tif 000019
【図２】
2008155888.tif 000020
【図３Ａ】
2008155888.tif 000021
【図３Ｂ】
2008155888.tif 000022
【図４】
2008155888.tif 000023
【図５】
2008155888.tif 000024
【図６】
2008155888.tif 000025
【図７】
2008155888.tif 000026
【図８】
2008155888.tif 000027
【図９】
2008155888.tif 000028
【図１０】
2008155888.tif 000029
【図１１】
2008155888.tif 000030
【図１２】
2008155888.tif 000031
【図１３】
2008155888.tif 000032
【図１４】
2008155888.tif 000033
【図１５】
2008155888.tif 000034
【国際調査報告】
2008155888.tif 000035
2008155888.tif 000036
2008155888.tif 000037
2008155888.tif 000038
2008155888.tif 000039
2008155888.tif 000040
2008155888.tif 000041