JPWO2010055630A1 - アドレス登録方法、アドレス登録システム、移動装置及び移動管理装置 - Google Patents

Abstract

移動装置の複数のインタフェースの各アドレスを移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止する技術が開示され、その技術によればＭＮ１００がＩＦ１０００、１００１に関連付けられたアドレスのそれぞれを送信元アドレスとして、送信元アドレスを個別に登録するための個別登録ＢＵメッセージＳ３０、Ｓ３１をＨＡ１０１に送信し、ＨＡ１０１が個別登録ＢＵメッセージＳ３０、Ｓ３１を受信した場合に、その送信元アドレスが外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより検証されたものとみなして登録するとともに、各アドレスを一括して更新するバルク登録を許可するＢＡメッセージＳ３２、Ｓ３３をＭＮ１００に送信する。

Description

本発明は、移動装置の複数のインタフェースの各アドレスを、移動装置の移動を管理する移動管理装置に登録するアドレス登録方法及びアドレス登録システムに関する。
また本発明は、上記のアドレス登録システムにおける移動装置及び移動管理装置に関する。

下記の非特許文献１におけるモバイルＩＰｖ６（ＭＩＰｖ６）によれば、モバイルノードは、インターネットに対する接続点（point-of-attachment）を変更しても、１つのＩＰアドレスを永久的に維持することができる。ＭＩＰｖ６におけるこの永久的なＩＰアドレスとは、モバイルノードのホームネットワーク・ドメイン内のアドレスであって、ホームアドレスとして知られている。また、モバイルノードは、外部ネットワーク・ドメインに接続（attach）すると、その外部ネットワーク・ドメインで使用するＩＰアドレスを、その外部ネットワーク・ドメインにより広告されるサブネット・プリフィックスからも構成することができる。このように構成されたＩＰアドレスは気付アドレス（Care-of Address）と呼ばれ、気付アドレスをモバイルノードのあて先とすることもできる。

モバイルノードがその位置に関係なく到達性（reachability）を維持するためには、モバイルノードは、自身の移動管理装置であるホームエージェントにおいて現在の気付アドレスをホームアドレスにバインドする。ＭＩＰｖ６では、ホームエージェントとは、モバイルノードのホームネットワーク・ドメイン内においてモバイルノードの気付アドレスを登録するルータである。この登録は、モバイルノードがバインディング・アップデート（ＢＵ）メッセージをホームエージェントに送信することにより実現される。モバイルノードがホームネットワーク・ドメインからアウェイに位置する間は、ホームエージェントは、モバイルノードのホームアドレスあてのパケットをインタセプトして、モバイルノードの気付アドレスあてにトンネル化する。ＭＩＰｖ６では、ホストがモビリティ管理に含まれるので、ＭＩＰｖ６は、ホストベースのモビリティ管理プロトコルとも呼ばれている。

ところで、複数のネットワーク・インタフェースが集積された携帯型の電子周辺機器が導入されると、モバイルノード及びルータは、複数の気付アドレスを１つのホームアドレスに登録することができる（例えば下記の非特許文献２）。非特許文献２に記載されている方法では、１つのホームアドレスに対する複数のバインディングを区別するために、バインディング・ユニーク識別子（ＢＩＤ）番号と呼ばれる識別子番号が使用される。このＢＩＤは、インタフェース又は、モバイルノード及びルータの１つのホームアドレスにバインドされる気付けアドレスに割り当てられる。このため、ホームアドレスがモバイルノード及びルータに関連付けられるのに対し、ＢＩＤは、モバイルノードにより同時に登録される複数のバインディングの各々を識別する。モバイルノード及びルータは、ＢＵメッセージを用いてＢＩＤをホームエージェントに通知し、ホームエージェントは、このＢＩＤをバインディング・キャッシュに記録する。

図１は、ホストベースのモビリティ管理が使用されるシステムの想定例を示す。図１において、２つのインタフェース（ＩＦ）１０００、１００１を有するＭＮ１００は、元々はホームネットワーク・ドメイン１０に位置していて、ホームアドレス（ＨｏＡ）を用いて通信相手（ＣＮ：Correspondent Node）３００と通信を行っていたものとする。ＭＮ１００はホームネットワーク・ドメイン１０外に移動して、グローバル通信ドメイン１２を跨がって外部ネットワーク・ドメイン１１をローミングするときにＭＩＰｖ６を使用して、ＣＮ３００と継続して通信を行うものとする。このために、ＭＮ１００は、外部ネットワーク・ドメイン１１をローミングするときに、ホームネットワーク・ドメイン１０内のＨＡ１０１に対し、現在の気付アドレス（ＣｏＡ）をＨｏＡにバインドする。

ＭＮ１００は、３Ｇセルラ・ネットワーク１１０と通信可能なインタフェース（ＩＦ）１０００と、ワイヤレス・ローカルエリアネットワーク（ＷＬＡＮ）１１１と通信可能なＩＦ１００１を有し、外部ネットワーク・ドメイン１１においてＩＦ１０００、１００１を同時に接続するものとする。ＭＮ１００は、非特許文献２を採用して、ＩＦ１０００について構成したＩＰアドレス（ＣｏＡ１とする）と、ＩＦ１００１について構成したＩＰアドレス（ＣｏＡ２とする）をＨＡ１０１においてＨｏＡにバインドする。

通常では、ＭＮ１００は、各ＩＰアドレスＣｏＡ１、ＣｏＡ２をそれぞれバインドする個々のＢＵメッセージ（以下では、個別登録ＢＵメッセージ）をＨＡ１０１に送信するが、ＭＮ１００とＨＡ１０１の間のシグナリングを最適化する方法として、非特許文献２では、複数の個別登録ＢＵメッセージを１つのＢＵメッセージ（以下では、バルク登録ＢＵメッセージ）に集合することが提案されている。この技術は、バルク登録として知られ、ＭＮ１００とＨＡ１０１の間のシグナリング・メッセージ数を減少するという利点を有する。シグナリング・メッセージの数が減少するということは、メッセージのパケットのオーバヘッドが非常に減少することを黙示している。例えばＭＮ１００が２つの個別登録ＢＵメッセージの代わりに１つのバルク登録ＢＵメッセージを送信すると、パケットのオーバヘッドを４５％セーブすることができる場合がある。パケットのオーバヘッドのセーブについては下記の非特許文献３に詳しく説明されている。

さらに、このシステムが３ＧＰＰオペレータにより設けられている場合、ネットワークを悪意のある行動から保護するために、何らかのセキュリティ対策が設けられる。考えられるセキュリティ対策としては、下記の非特許文献４に記載されているようなイングレス・フィルタリングがある。ネットワーク側はイングレス・フィルタリングにより、意図する送信元から特定のパケットが来たことを知得することができる。各ネットワークのゲートウェイ・ルータは、パケットの送信元ＩＰアドレスをチェックして、特定のルータが取り扱うＩＰアドレスのリストとマッチングすることを確保することができる。ゲートウェイ・ルータは、パケットの送信元ＩＰアドレスが上記のＩＰアドレスのリスト内に存在しない場合には、そのパケットに悪意があると疑って破棄する。したがって、外部ネットワーク・ドメイン１１内のゲートウェイ・ルータがイングレス・フィルタリングによりパケットの送信元ＩＰアドレスをチェックするので、ＨＡ１０１は、ＭＮ１００が外部ネットワーク・ドメイン１１において送信されるパケットが真であると確信することができる。

しかしながら、バルク登録ＢＵメッセージの送信元アドレスには、複数の気付アドレス（ＣｏＡ）のうちの１つのみが記述され、残りの気付アドレスは、暗号化されたバルク登録ＢＵメッセージ内に伝送されるので、ゲートウェイ・ルータは、上記の残りの気付アドレスが偽か否かをチェックすることができない。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００がバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信する場合、バルク登録ＢＵメッセージの送信元アドレスは気付アドレス3G.Addrであるので、ＨＡ１０１にとっては、気付アドレス3G.Addrは、外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより検証（verify）される。

他方、バルク登録ＢＵメッセージ内の気付アドレスWLAN.Addrは、ＨＡ１０１に登録するためにオプションで伝送される。このため、外部ネットワーク・ドメイン１１によるイングレス・フィルタリングでは、ＨＡ１０１は、気付アドレスWLAN.Addrが外部ネットワーク・ドメイン１１内で使用されるＩＰアドレスであることを確信できないので、ＨＡ１０１は、ＭＮ１００との間で確立した信頼関係に頼るしかなく、ＭＮ１００が気付アドレスWLAN.Addrを使用しているものと仮定するしかない。ところで、ＭＮ１００に悪意があり、ＭＮ１００がＨＡ１０１との信頼関係を乱用して、あるＩＰアドレスをバルク登録ＢＵメッセージ内に記述した場合を考える。もし、このＩＰアドレスが他のモバイルノードにより使用されている場合、ＭＮ１００はＨＡ１０１に対し、他のモバイルノードのＩＰアドレスにパケットを転送するよう指示できることになる。この意味は、ＭＮ１００が犠牲となるモバイルノードに対し、ＨＡ１０１に無意味なパケットを洪水のごとく転送させてリ・ダイレクション攻撃できるということであり、このため、犠牲となるモバイルノードの本来のパケット送受信を輻輳させることができるということである。

このため、３ＧＰＰオペレータは、バルク登録による悪意のある攻撃を防止するために、別のセキュリティ対策を採用するかもしれない。また、ＨＡ１０１にとって簡単かつ明白な方法は、バルク登録ＢＵメッセージ内に記述されている各アドレス（送信元アドレスを除く）を検証することである。この場合、ＨＡ１０１は、バルク登録ＢＵメッセージ内に記述されている各アドレスあてに暗号化メッセージを送信して、ＭＮ１００に復号化メッセージを送り返すよう依頼することができる。ＨＡ１０１がＭＮ１００から送り返された復号化メッセージを受信できるということは、ＨＡ１０１にとって、ＭＮ１００がバルク登録ＢＵメッセージ内に記述されている各アドレスを使用しているものと検証できる。この方法の詳細は、下記の非特許文献５、特許文献１、特許文献２、特許文献３に示されている。

同様に、ＭＮ１００が複数のインタフェースを有する場合には、ＨＡ１０１が１つのインタフェース経由で暗号化メッセージを送信して、ＭＮ１００に別のインタフェース経由で復号化メッセージを送り返すよう依頼することにより、検証プロセスを最適化できる。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００が気付アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録するためのバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信したものとする。この場合、ＨＡ１０１は、気付アドレスWLAN.Addrを検証するために、ＩＦ１０００に暗号化メッセージを送信して、ＭＮ１００にＩＦ１００１経由で復号化メッセージを送り返すよう依頼する。このように、ネットワークにより既に検証（＝外部ネットワーク・ドメイン１１によりイングレス・フィルタリング）されているアドレス（3G.Addr）あてに暗号化メッセージを送信する利点は、未だ検証されていないアドレス（WLAN.Addr）あてにＨＡ１０１がパケットを送信してリ・ダイレクション(redirection)攻撃を意図的に開始しないようにすることにある。この方法の詳細は、下記の特許文献４に示されている。

以上説明した従来技術では、ＨＡ１０１が、送信元アドレス以外のＩＰアドレスを検証するためにＭＮ１００とメッセージ交換を行うので、ＭＮ１００が実際のパケット・ルーティング目的で、送信元アドレス以外のＩＰアドレスを使用する時点が遅れるという問題がある。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００が気付アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録するためのバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信し、ＨＡ１０１は、気付アドレスWLAN.Addrを検証するために、ＩＦ１０００に暗号化メッセージを送信したものとすると、この場合には、ＨＡ１０１は、ＭＮ１００からの復号化メッセージを受信するまでは、パケットをＭＮ１００に転送するために気付アドレスWLAN.Addrを使用すべきでない。これにより、ＨＡ１０１がリ・ダイレクション攻撃を意図的でなく仕掛けないことを保証することができる。しかしながら、以上説明した方法では、ＨＡ１０１がパケットをＭＮ１００に転送するために気付アドレスWLAN.Addrを使用するためには、ＨＡ１０１は、３つのメッセージ交換の時間を必要とする。

上記の遅延の問題を解決する明白な方法として、ＨＡ１０１との間に信頼関係が確立されているプロキシ・エンティティがＭＮ１００のＩＰアドレスをＨＡ１０１に登録する方法がある。例えばホームネットワーク・ドメイン１０の３ＧＰＰオペレータが外部ネットワーク・ドメイン１１の３ＧＰＰオペレータと何らかのサービス契約を締結しているかもしれない。このサービス契約では、ＨＡ１０１と、外部ネットワーク・ドメイン１１のプロキシ・エンティティ（例えばＡＡＡ（Authentication, Authorization and Accounting）サーバ）の間に相互の信頼関係が確立される。ＨＡ１０１は、このような相互の信頼関係を確立しておくことにより、プロキシ・エンティティがＭＮ１００のために登録するＩＰアドレスを信頼する。この方法の詳細は、下記の特許文献５、特許文献６に示されている。また、特許文献７には、プロキシ・エンティティが、ＨＡ１０１あての登録メッセージ内に記述されているＭＮ１００のＩＰアドレスが真であることを登録メッセージのパケットヘッダ内に記述することが記載されている。

しかしながら、以上説明した従来技術では、パケット転送を目的とするＩＰアドレス使用の遅延を減少するために、ＩＰアドレスを検証する第３のエンティティをシステム内に導入している。さらに、従来技術の方法を用いる前に、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１の間で何らかの信頼関係を確立しなければならない。しかしながら、すべての３ＧＰＰオペレータがお互いにこのような信頼関係を確立して維持することは困難である。

上記の遅延の問題を解決する明白な他の方法として、ＭＮ１００が暗号化を用いて、ＨＡ１０１に登録するＩＰアドレスを生成する方法がある。この方法の詳細は、下記の非特許文献６に示されている。しかしながら、暗号化して生成したＩＰアドレスでは、ＭＮ１００は、自身が保持していないＩＰアドレスをバインドすることができない。また、暗号化して生成したＩＰアドレスを使用する場合には、ＭＮ１００は、ＩＰアドレスを得るために複雑なハッシュ関数を動作させる必要があるので、構成がより複雑になり、より高い処理能力を必要とする。加えて、ＭＮ１００は、ＩＰアドレスを生成するのに使用したパラメータをＨＡ１０１あてのＢＵメッセージ内に含ませる必要がある。なお、このパラメータは、ＩＰアドレスが真であることを検証する際にＨＡ１０１により使用される。また、ＩＰアドレスを生成するのに使用したパラメータをバルク登録ＢＵメッセージ内に付加すると、メッセージサイズが非常に増大する。例えば下記の非特許文献７には、各パラメータ・オプションが２５５バイトまでに限定され、１つのメッセージが複数のパラメータ・オプションを含むであろうことが記載されている。

P. Danny, T. Daniel C., and B. Richard, "Link discovery and verification procedure using loopback", US Patent No. 6,834,139 B1, December 21, 2004. S. John A., "Methods and apparatus for determining, verifying, and rediscovering network IP addresses", US Patent No. 6,195,706 B1, February 27, 2001. C. Josep, D. Scott N. and V. Theodore B., "Apparatus, system, and method for automatically verifying access to a mulitipathed target at boot time", US Patent Application Publication No. 2007/0143583 A1, June 21, 2007. J. Hirano, B. Lim, C-W. Ng, B. Koh and P-Y. Tan, "Method and apparatus for address verification during multiple address registration", WO Patent Application Publication No. 2008/023845 A1, February 28, 2008. K. Leung and G. Dommety, "Methods and apparatus for providing mobility of a node that does not support mobility", US Patent No. 6,466,964 B1, October 15, 2002. H. Guan, J. Wang and Y. Huang, "Method and System for Authorizing and Charging Host with Multiple Addresses in IPv6 Network", US Patent Application Publication No.2007/0169180 A1, July 19, 2007. P-A. Son, "System and method for carrying trusted network provided access network information in session initiation protocol", US Patent Application Publication No. 2008/0039085 A1, February 14, 2008.

D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. M. Kuparinen, H. Mahkonen and T. Kauppinen, "Multiple CoA Performance Analysis", draft-kuparinen-monami6-mcoa-performance-00.txt, April 20, 2006. F. Baker and P. Savola, "Ingress Filtering for Multihomed Networks", Internet Engineering Task Force Request For Comments 3704, March 2004. F. Dupont, and J-M. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-00.txt, January 10, 2005. T. Aura, "Cryptographically Generated Addresses (CGA)", Internet Engineering Task Force Request For Comments 3972, March, 2005. J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", Internet Engineering Task Force Request For Comments 4866, May, 2007.

以上説明したように、モバイルノードの複数のインタフェースに関連付けられた各アドレスを、モバイルノードの移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信に遅延が発生するという問題点がある。

本発明は上記の問題点に鑑み、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができるアドレス登録方法、アドレス登録システム、移動装置及び移動管理装置を提供することを目的とする。

本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録方法であって、
前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１のステップと、
前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２のステップと、
前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３のステップとを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムであって、
前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１の手段と、
前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２の手段と、
前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３の手段とを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動装置であって、
前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する手段と、
前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動管理装置から受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する手段とを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動管理装置であって、
前記移動装置から、前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する手段と、
前記応答メッセージを送信した後に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動装置から受信した場合に、前記複数のアドレスを一括して更新する手段とを、
有する構成とした。

この構成により、移動装置の複数のインタフェースに割り当てられた複数のアドレスを最初に移動管理装置に登録する場合には、個別登録メッセージを使用して各アドレスをネットワークのイングレス・フィルタリングなどにより認証し、この登録後には複数のアドレスを一括して更新する場合にバルク登録メッセージを使用するので、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができる。

本発明によれば、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができる。

本発明のアドレス登録方法が適用されるシステムの想定例を示すブロック図 本発明の第１の実施の形態におけるモバイルノードの構成を機能的に示すブロック図 本発明の第１の実施の形態におけるホームエージェントの構成を機能的に示すブロック図 本発明の第１の実施の形態における通信シーケンスを示す説明図 本発明の第１の実施の形態の通知メッセージのフォーマットを示す説明図 本発明の第１の実施の形態におけるモバイルノードがバルク登録の可否を判断する処理を説明するためのフローチャート 本発明の第１の実施の形態におけるホームエージェントがバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャート 本発明の第２の実施の形態の通信シーケンスを示す説明図 本発明の第２の実施の形態における個別登録ＢＵメッセージのフォーマット を示す説明図 本発明の第２の実施の形態におけるモバイルノードがバルク登録の可否を判断する処理を示すフローチャート 本発明の第２の実施の形態におけるホームエージェントがバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャート 本発明の第３の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態におけるバルク登録ＢＵメッセージのフォーマットを示す説明図 本発明の第３の実施の形態におけるプロキシがバルク登録ＢＵメッセージ内のＩＰアドレス検証を援助する処理を示すフローチャート 本発明の第６の実施の形態におけるバルク登録ＢＡメッセージのフォーマットを示す説明図 本発明の第６の実施の形態におけるモバイルノードがバルク登録ＢＡメッセージを受信した場合の処理を示すフローチャート 本発明の第８の実施の形態におけるシステムの想定例を示すブロック図 本発明の第８の実施の形態におけるメッセージシーケンスを示す説明図 本発明の第８の実施の形態における個別登録ＢＡメッセージのフォーマットを示す説明図 本発明の第８の実施の形態における個別登録ＢＵメッセージのフォーマットを示す説明図

以下、図面を参照して本発明の実施の形態について説明する。以下に記載されている特定の数字、時間、構造、プロトコル名及び他のパラメータは、本発明を理解するための説明であって、当業者であれば、本発明は、これらに限定されることなく実現可能なことは明らかである。また、ブロック図に示されている名称は、本発明を不必要に不明瞭にしないように用いられている。

図１は、本発明のアドレス登録方法が使用されるシステムの想定例を示す。図１におけるシステムの概略的な構成は、「背景技術」において説明したので、ここでは詳細な説明を省略する。なお、このシステムは、３ＧＰＰ−ＬＴＥ（Third Generation Partnership Project Long Term Evolution）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）と関連付けることができる。このシステムとＳＡＥの関係について説明すると、ホームエージェント（ＨＡ）１０１は、ＳＡＥのパケットデータ・ネットワーク・ゲートウェイ（ＰＤＮ−ＧＷ：Packet Data Network Gateway）と関連付けることができ、同様に、モバイルノード（ＭＮ）１００は、ＳＡＥのユーザ機器（ＵＥ：User Equipment）と関連付けることができる。なお、ネットワーク１１１はＮｏｎ−３ＧＰＰネットワークであり、ＷＬＡＮに限らず、ＷｉＭＡＸなどの他のアクセスネットワークであってもよい。

本発明では、２つのインタフェース（ＩＦ）１０００（３ＧＰＰインタフェース）、１００１（Ｎｏｎ−３ＧＰＰインタフェース）を有するＭＮ１００は、外部ネットワーク・ドメイン１１においてＩＦ１０００、１００１に割り当てられたＩＰアドレス（気付アドレス：ＣｏＡ）をＨＡ１０１に登録してさらに更新するために、最初は、ＭＮ１００は、ＩＦ１０００、１００１のそれぞれを送信元アドレスとして、送信元アドレスを個別に登録するための複数の個別登録ＢＵメッセージをＨＡ１０１に送信する。ＨＡ１０１は、複数の個別登録メッセージを受信した場合に、その送信元アドレスが外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより検証されたものとみなして登録するとともに、ＭＮ１００による今後のＢＵメッセージの送信を効率化するために、どのようにＢＵメッセージを送信するべきかを示す情報を含む応答メッセージ（ＢＡメッセージ）をＭＮ１００に送信する。その情報には、バルク登録ＢＵメッセージの送信方法を指示する情報（バルクパターン情報）が含まれており、ＭＮ１００はその情報に従って、以降のＢＵメッセージを送信する。

＜ＭＮの構成＞
図２はＭＮ１００の構成を機能的に示すブロック図である。なお、図２に示す構成は、ＭＮ１００以外のノード、例えばモバイル・ルータなどにも適用することができる。ＭＮ１００は、ネットワーク・インタフェース・モジュール２１と、モビリティ・バインディング・エンジン２２と、データベース・モジュール２３と、バルク登録可否判断エンジン２４を有する。ネットワーク・インタフェース・モジュール２１は、通信メディアを介して他のノードと通信するために必要なプログラム及びソフトウエアを実行する機能ブロックである。関連する技術分野において用いられている用語を使用すれば、ネットワーク・インタフェース・モジュール２１は、レイヤ１（物理層）とレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ及び通信プロトコルを表す。当業者であれば、ネットワーク・インタフェース・モジュール２１は１以上設けられることは明らかである（例えば図１のＩＦ１０００、１００１）。

ネットワーク・インタフェース・モジュール２１とモビリティ・バインディング・エンジン２２は、シグナル／データパスＳ２１を介してトリガ信号及びパケットを相互に伝送することができる。例えばネットワーク・インタフェース・モジュール２１は、他のノードから受信したモビリティ・シグナリング・メッセージ（例えばＨＡ１０１から受信したＢＡメッセージ）をモビリティ・バインディング・エンジン２２に転送して処理させる。同様に、モビリティ・バインディング・エンジン２２は、モビリティ・シグナリング・メッセージ（例えばＢＵメッセージ）をネットワーク・インタフェース・モジュール２１に転送して他のノード（例えばＨＡ１０１）に送信させる。

モビリティ・バインディング・エンジン２２はＭＮ１００のモビリティを管理する。関連する技術分野において用いられている用語を使用すれば、モビリティ・バインディング・エンジン２２はレイヤ３（ネットワーク層）プロトコル、例えばＭＩＰｖ４又はＭＩＰｖ６（Mobile Internet Protocol version 4 or 6）の機能を表す。モビリティ・バインディング・エンジン２２とデータベース・モジュール２３は、シグナル／データパスＳ２２を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２２はモビリティ管理機能を実行するために、データベース・モジュール２３内の情報（例えば気付アドレス）をアップデートしたり、データベース・モジュール２３から情報を引き出したりする。

同様に、モビリティ・バインディング・エンジン２２とバルク登録可否判断エンジン２４は、シグナル／データパスＳ２３を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２２は、ＨＡ１０１に登録されているＭＮ１００のアドレスのバインディングをリフレッシュする前にバルク登録可否判断エンジン２４をトリガして、どのアドレスがバルク登録に使用可能かを識別することができる。

データベース・モジュール２３は、ＭＮ１００に必要な情報を蓄積し、この望ましい実施の形態ではバインディング・アップデートリスト２３０と、バルク登録有効期間２３１と、アドレス検証情報２３２を蓄積している。バインディング・アップデートリスト２３０は、あて先ノード（例えばＨＡ１０１、ＣＮ３００）に登録しているＭＮ１００の現在の気付アドレスに関する１以上のエントリを含む。加えて、第１の実施の形態では、バルク登録に使用する１又は複数の気付アドレスに対してバルク登録有効期間２３１を導入している。アドレス検証情報２３２は、バルク登録可否判断エンジン２４が判断を実行するのに関連するデータ（例えばバルク登録に使用される１又は複数の気付アドレス、公開鍵及び秘密鍵）を含む。

本発明では、バルク登録可否判断エンジン２４を導入して、特定の気付アドレスがバルク登録に使用可能か否か（ＨＡ１０１によりバルク登録が許可されているか否か）を判断している。例えばバルク登録可否判断エンジン２４の目的は、データベース・モジュール２３内のバルク登録有効期間２３１を使用して、特定の気付アドレスがバルク登録可能か否かを判断することにある。

＜ＨＡの構成＞
図３はＨＡ１０１の構成を機能的に示すブロック図である。なお、図３に示す構成は、ＨＡ１０１以外のノード、例えばＣＮ３００などにも適用することができる。ＨＡ１０１は、ネットワーク・インタフェース・モジュール２５と、モビリティ・バインディング・エンジン２６と、データベース・モジュール２７と、バルク登録検証エンジン２８を有する。ネットワーク・インタフェース・モジュール２５は、図２と同様に、通信メディアを介して他のノードと通信するために必要なプログラム及びソフトウエアを実行する機能ブロックであるので、詳細な説明を省略する。当業者であれば、ネットワーク・インタフェース・モジュール２５は１以上設けられることは明らかである。

また、図２と同様に、ネットワーク・インタフェース・モジュール２５とモビリティ・バインディング・エンジン２６は、シグナル／データパスＳ２５を介してトリガ信号及びパケットを相互に伝送することができる。ネットワーク・インタフェース・モジュール２５は、他のノードから受信したモビリティ・シグナリング・メッセージとして、例えばＭＮ１００から受信したＢＵメッセージ（個別登録ＢＵメッセージ、バルク登録ＢＵメッセージ）をモビリティ・バインディング・エンジン２６に転送して処理させる。同様に、モビリティ・バインディング・エンジン２６は、モビリティ・シグナリング・メッセージをネットワーク・インタフェース・モジュール２１に転送して他のノードに送信させ、例えばＢＡメッセージ（個別登録ＢＡメッセージ、バルク登録ＢＡメッセージ）をＭＮ１００に送信させる。

モビリティ・バインディング・エンジン２６はＨＡ１０１のモビリティを管理する。図２と同様に、関連する技術分野において用いられている用語を使用すれば、モビリティ・バインディング・エンジン２６はレイヤ３（ネットワーク層）プロトコル、例えばＭＩＰｖ４又はＭＩＰｖ６（Mobile Internet Protocol version 4 or 6）の機能を表す。モビリティ・バインディング・エンジン２６とデータベース・モジュール２７は、シグナル／データパスＳ２６を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２６はモビリティ管理機能を実行するために、データベース・モジュール２７内の情報（例えば気付アドレス）をアップデートしたり、データベース・モジュール２７から情報を引き出したりする。

同様に、モビリティ・バインディング・エンジン２６とバルク登録検証エンジン２８は、シグナル／データパスＳ２７を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２７は、ＨＡ１０１に登録されているＭＮ１００のアドレスのバインディングをリフレッシュする前にバルク登録検証エンジン２８をトリガして、どのアドレスがバルク登録に使用可能か（バルク登録を許可しているか）を識別することができる。

データベース・モジュール２７は、ＨＡ１０１に必要な情報を蓄積し、この望ましい実施の形態ではバインディング・キャッシュ２７０と、バルク登録有効期間２７１と、アドレス検証情報２７２を蓄積している。バインディング・キャッシュ２７０は、あて先ノード（例えばＭＮ１００）の現在の気付アドレスに関する１以上のエントリを含む。加えて、第１の実施の形態では、ＭＮ１００がバルク登録に使用する１又は複数の気付アドレスに対してバルク登録有効期間２７１を導入している。アドレス検証情報２７２は、バルク登録検証エンジン２８が実行するのに関連するデータ（例えばバルク登録に使用される１又は複数の気付アドレス、公開鍵及び秘密鍵）を含む。本発明では、バルク登録検証エンジン２８を導入している。バルク登録検証エンジン２８の目的は、バルク登録ＢＵメッセージ内の気付アドレスがバルク登録可能か否かを検証することにある。この検証については、後述する他の実施の形態では、ＨＡ１０１が検証するのをプロキシが援助する。

＜第１の実施の形態：ＨＡがＭＮにバルク登録可否を通知＞
図４は第１の実施の形態の通信シーケンスを示す。ここで、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用している。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外の外部ネットワーク・ドメイン１１内をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。

このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ３０をＨＡ１０１に送信する。同様に、ＭＮ１００は、アドレスWLAN.AddrをＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ３１（図では単に、個別ＢＵ）をＨＡ１０１に送信する。ＨＡ１０１では、外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより、アドレス3G.Addrが、そのアドレスが割り当てられている送信元から来たと検証することが保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrが登録されたことを個別に通知（図では、ＢＮＤ−ＯＫ）するためのバインディング確認（個別登録ＢＡ）メッセージＳ３２（図では単に、個別ＢＡ）をＭＮ１００に送り返す。

同様に、アドレスWLAN.Addrに関しても、外部ネットワーク・ドメイン１１によるイングレス・フィルタリングに基づいて、同様の手順で処理が行われる。ここでは、ＨＡ１０１は、ＭＮ１００が複数の気付アドレスを登録していることを検出して、バインディング確認（ＢＮＤ−ＯＫ）の通知と共に、アドレスWLAN.Addrがバルク登録可能であること（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に送り返す。個別登録ＢＡメッセージＳ３３ではまた、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間をＭＮ１００に通知する。

ＭＮ１００は、次のＢＵメッセージをＨＡ１０１に送信しようとするときには、アドレスWLAN.Addrのバルク登録有効期間が未だ満了していないか否かをチェックする。バルク登録有効期間が未だ満了していない場合には、ＭＮ１００は、アドレス3G.Addr、WLAN.Addrをバルク登録でＨＡ１０１に登録するためにバルク登録ＢＵメッセージＳ３４ａ（図では単に、バルクＢＵ）を継続して使用してＨＡ１０１に送信する。ＨＡ１０１はバルク登録ＢＵメッセージＳ３４に対する応答として、２つの個別登録ＢＡメッセージＳ３４ｂ（3G.Addr宛の個別登録ＢＡメッセージとWLAN.Addr宛の個別登録ＢＡメッセージ）又は１つのバルク登録ＢＡメッセージＳ３４ｃを送り返す。

ＭＮ１００は、バルク登録有効期間が満了した場合には（図のＳ３５）、個別登録ＢＵメッセージＳ３６、Ｓ３７をＨＡ１０１に送信して、それぞれアドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録する。個別登録ＢＵメッセージＳ３６、Ｓ３７により、ＨＡ１０１は再びイングレス・フィルタリングにより送信元アドレスが検証されたとして、ＭＮ１００が登録しようとしている気付アドレス3G.Addr、WLAN.Addrが真であると検証することができる。

ＭＮ１００は、アドレス3G.Addr、WLAN.Addrが変更された場合には、そのアドレスはバルク登録ＢＵメッセージ内には含ませない。その理由は、新しいＩＰアドレスは、ＨＡ１０１によりイングレス・フィルタリングを使用して検証されていないからである。もしＭＮ１００が新しいＩＰアドレスを登録するためにバルク登録を使用した場合、ＨＡ１０１は、新しいＩＰアドレスを使用する前に、何らかのアドレス検証メカニズムをトリガして新しいＩＰアドレスを検証する。なお、アドレスの検証をした後に、そのアドレスがバルク登録可能であること（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に返してもよい。例えばＭＮ１００がＷＬＡＮインタフェース１００１の新しいＩＰアドレスとしてアドレスWLAN.Addr2を構成した場合、アドレスWLAN.Addr2がＨＡ１０１により未だ検証されていないので、ＭＮ１００は、個別登録ＢＵメッセージを使用してアドレスWLAN.Addr2をＨＡ１０１に登録する。この手法により、ＨＡ１０１はイングレス・フィルタリングを使用して、ＭＮ１００が本当にアドレスWLAN.Addr2を使用していることを検証できる。他方、ＭＮ１００が個別登録ＢＵメッセージをＨＡ１０１に送信する前に、バルク登録を使用してアドレスWLAN.Addr2をＨＡ１０１に登録しようとした場合、ＨＡ１０１は、アドレスWLAN.Addr2がバインディング・キャッシュ２７０に存在しないことを検知して、アドレスWLAN.Addr2がバルク登録不可であることを知得し、アドレス検証を実行する。

なお、ＨＡ１０１は、バルク登録が不可であるアドレスに対してアドレス検証処理を実行する代わりに、ＭＮ１００に対してバルク登録が拒否されたことのみを通知するＢＡメッセージを送信してもよい。これにより、個別登録ＢＵメッセージでの再送をするか否かをＭＮ１００の判断に委ねることができる。ＭＮ１００は、バルク登録ではなく個別登録ＢＵメッセージを送信するべきであることを認識し、自ら個別登録ＢＵメッセージで再送を開始することができるため、検証処理の実行に伴う負荷をＨＡ１０１から取り除くことができる。

また、ＨＡ１０１は、バルク登録ＢＵメッセージに含まれるアドレスが、バインディング・キャッシュ２７０に全く存在しないアドレスである場合に、前述のバルク登録が拒否されたことを通知するＢＡメッセージを送信し、一方、バインディング・キャッシュ２７０に存在するが、バルク登録有効期間が満了している場合にアドレスの検証処理を実行するようにしてもよい。これにより、ＨＡ１０１によるアドレス検証を特定の場合に限定することができるため、アドレス検証に伴う負荷を軽減することができる。例えば、個別ＢＵメッセージの再送に伴うＭＮ１００の負荷の方が、アドレス検証処理に伴うＨＡ１０１の負荷よりも大きい場合には、ＭＮ１００は自身の負荷を軽減するために、最初からバルク登録ＢＵメッセージで送信することを選択するかもしれない。これに伴うＨＡ１０１の負荷が増大することは、ネットワークオペレータにとって望ましいものではない。そのため、上記のようにＨＡ１０１がアドレス検証を実行する機会をできるだけ制限することで、このようなＭＮ１００の行為を防ぐことができる。

＜通知メッセージのフォーマット＞
図５は望ましい第１の実施の形態の通知メッセージのフォーマットを示す。この通知メッセージは、パケットヘッダ４０とモビリティ・オプション４１を有する。パケットヘッダ４０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション４１は、ステータス・オプション４１０と通知オプション４１１を有する。ステータス・オプション４１０は、このメッセージが個別登録ＢＡメッセージＳ３２、Ｓ３３の場合、個別登録ＢＵメッセージＳ３０、Ｓ３１により要求された気付アドレスの登録が完了したか否か（ＢＮＤ−ＯＫ／ＮＯ）を示す。また、通知オプション４１１は、このメッセージがアドレスWLAN.Addrの個別登録ＢＡメッセージＳ３３であってバルク登録可（ＢＬＫ−ＯＫ）の場合、バルク登録有効期間を含む。

ステータス・オプション４１０と通知オプション４１１について、図４に示す例を参照して詳しく説明すると、ＭＮ１００がアドレス3G.Addrを個別にＨＡ１０１に登録するために、３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ３０をＨＡ１０１に送信すると、ＨＡ１０１はＭＮ１００に対し、アドレス3G.Addrの登録が完了したこと（ＢＮＤ−ＯＫ）を示すステータス・オプション４１０を含む個別登録ＢＡメッセージＳ３２を送り返す。さらに、ＭＮ１００がアドレスWLAN.Addrを個別にＨＡ１０１に登録するために、ＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ３１をＨＡ１０１に送信すると、ＨＡ１０１はＭＮ１００に対し、アドレスWLAN.Addrの登録が完了したこと（ＢＮＤ−ＯＫ）を記述したステータス・オプション４１０と、アドレスWLAN.Addrのバルク登録有効期間（例えば７分）を記述した通知オプション４１１を含む個別登録ＢＡメッセージＳ３３を送り返す。このため、次の７分間は、ＭＮ１００は、アドレスWLAN.Addrをリフレッシュするために、３Ｇセルラ・インタフェース１０００からバルク登録ＢＵメッセージＳ３４ａを送信することができる。

＜バルク登録有効期間＞
通知オプション４１１に記述する「バルク登録有効期間」は、外部ネットワーク・ドメイン１１によりＭＮ１００の通信のために割り当てられているＩＰアドレスの存続期間（以下、「アドレス存続期間」）に対応しており、バルク登録有効期間が、アドレス存続期間と同等か、それ以下とすることが望ましい。外部ネットワーク・ドメイン１１に位置する不図示のＤＨＣＰ（Dynamic Host Control Protocol）サーバにより、アドレスWLAN.Addrのアドレス存続期間が割り当てられている場合を例にして説明する。ＤＨＣＰサーバは、アドレスWLAN.AddrをＭＮ１００に割り当てるときに、アドレスWLAN.Addrのアドレス存続期間（例えば７分）を指示する。このアドレス存続期間の間は、ＤＨＣＰサーバは、ＭＮ１００がアドレスWLAN.Addrを使用しなくても、アドレスWLAN.Addrを他のモバイルノードに割り当てない。

このようにＤＨＣＰサーバが動作する理由は、ＭＮ１００が予期しない接続ロスにあうかもしれないからである。ＭＮ１００は、アドレスWLAN.Addrの接続ロスの後に再接続すると、ＣＮ３００との間で継続しているセッションを変更しないためにアドレスWLAN.Addrを要求する。ＭＮ１００がアドレスWLAN.Addrの接続を失った時点から再接続するまでの間に、もしＤＨＣＰサーバがアドレスWLAN.Addrを他のモバイルノードに割り当てると、ＭＮ１００はアドレスWLAN.Addrを再び使用できなくなる。ＭＮ１００がアドレスWLAN.Addrを再び使用できなくなるということは、ＭＮ１００が新しいＩＰアドレスをＣＮ３００に通知する必要があるので、ＭＮ１００とＣＮ３００との間のセッションに対する通信サービスが崩壊することを黙示している。さらに、アドレスWLAN.Addrが他のモバイルノードに割り当てられたことをＣＮ３００が知得していないので、他のモバイルノードは、アドレスWLAN.Addrを使用すると、無用なパケットをＣＮ３００から受信する。この行為は、ＭＮ１００が悪意のあるノードである場合にはリ・ダイレクション攻撃とみなされる。

ＤＨＣＰサーバから割り当て中のアドレス存続期間にバルク登録有効期間が関連付けされていない場合に、悪意のあるＭＮ１００がＤＨＣＰサーバを利用してリ・ダイレクション攻撃を行う方法について説明する。ＭＮ１００がＤＨＣＰサーバから外部ネットワーク・ドメイン１１で使用するアドレスWLAN.Addrを割り当てられた場合、ＭＮ１００は、アドレスWLAN.Addrを使用してＣＮ３００とセッションを開始し、アドレスWLAN.Addrあてのパケット送信を開始して１分間、継続する。次に、ＭＮ１００は、アドレスWLAN.Addrの接続を意図的に失い、ＤＨＣＰサーバを欺いてアドレスWLAN.Addrを他のモバイルノードに割り当てさせる。一旦、他のモバイルノード（すなわち犠牲者）がアドレスWLAN.Addrを取得すると、ＣＮ３００からのパケットは、犠牲となるモバイルノードに到達を開始して無用なパケットを大量に受信させることができる。

このため、この望ましい第１の実施の形態では、ＨＡ１０１からＭＮ１００に対して通知するＩＰアドレスのバルク登録有効期間を、外部ネットワーク・ドメイン１１内のＤＨＣＰサーバから割り当てるアドレス存続期間と同じ、またはそれ以下としている。さらに、バルク登録有効期間がアドレス存続期間よりも短い場合、アドレス存続期間が終了するタイミングと、バルク登録有効期間が終了するタイミングが一致していることが望ましい。これにより、アドレス存続期間が終了した時点で、バルク登録有効期間がまだ有効である期間が生じてしまうことを防ぐことができる。このようにバルク登録有効期間を導入することにより、前述したようなリ・ダイレクション攻撃を防止することができる。変形例として、バルク登録有効期間は、すべてのエンティティが知得している周知の期間でもよい。さらに他の変形例として、バルク登録有効期間は、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１の間で交渉した期間でもよい。

加えて、バルク登録有効期間は、ＭＮ１００がこのＩＰアドレスを既に使用していないときに、ＭＮ１００がこのＩＰアドレスの使用を誤って申し立てる可能性を低減することができる。例えばＭＮ１００がＷＬＡＮインタフェース１００１をシャットダウンしたとき、ＭＮ１００は悪意で、アドレスWLAN.Addrをリフレッシュするために３Ｇセルラ・インタフェース１０００からバルク登録ＢＵメッセージを送信することにより、アドレスWLAN.Addrの使用を申し立てることができる。しかしながら、ＤＨＣＰサーバがアドレスWLAN.Addrを、そのアドレス存続期間が満了するまで割り当てないので、ＭＮ１００は、リ・ダイレクション攻撃を、犠牲となるモバイルノードに仕掛けることができない。また、バルク登録有効期間が満了すると、ＨＡ１０１は、ＭＮ１００がＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージを送信して、ＭＮ１００が未だアドレスWLAN.Addrを使用していることをイングレス・フィルタリングで検証することを必要とする。したがって、バルク登録有効期間を導入することにより、ＭＮ１００が悪意のある行動をとる可能性を低減することができる。

＜ＭＮの処理＞
図６はＭＮ１００がバルク登録の可否を判断する処理を説明するためのフローチャートである。この処理は、ＢＵメッセージをＨＡ１０１に送信する必要がある場合に、バルク登録可否判断エンジン２４がモビリティ・バインディング・エンジン２２からトリガ信号を受信したときにスタートし（ステップＳ５０のＢＵ受信トリガ）、データベース・モジュール２３から関連情報（例えばバインディング・アップデートリスト２３０のエントリとバルク登録有効期間２３１）を引き出す（ステップＳ５１）。次いで、バルク登録有効期間２３１に基づいてそのＩＰアドレスのバルク登録有効期間が満了しているか否かをチェックする（ステップＳ５２）。そして、バルク登録有効期間が満了している場合にはステップＳ５３に進んでバインディング・アップデートリスト２３０におけるそのＩＰアドレスに対して「バルク登録不可」をマークしてステップＳ５５に進む。他方、バルク登録有効期間が満了していない場合にはステップＳ５４に進んでバインディング・アップデートリスト２３０におけるそのＩＰアドレスに対して「バルク登録可」をマークしてステップＳ５５に進む。ステップＳ５５では、バインディング・アップデートリストにおけるすべてのエントリをチェックした場合に、その結果（バルク登録不可／バルク登録可）をリスト化してモビリティ・バインディング・エンジン２２に転送する。モビリティ・バインディング・エンジン２２はこのリストに基づいて個別登録ＢＵメッセージ又はバルク登録ＢＵメッセージを選択的に生成する。

上記の処理の例を説明する。ＭＮ１００は既に、アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録しているものとする。また、ＨＡ１０１はＭＮ１００に対して、アドレスWLAN.Addrが７分間、バルク登録可能な旨を通知している。その４分後、ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要があるものとする。ＭＮ１００は、未だアドレス3G.Addr、WLAN.Addrの両方を使用しており、アドレスWLAN.Addrのバルク登録有効期間が満了していないので、アドレス3G.Addr、WLAN.Addrの両方をリフレッシュするためのバルク登録ＢＵメッセージをＨＡ１０１に送信する。さらにその４分後、ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要があるものとする。ＭＮ１００は、未だアドレス3G.Addr、WLAN.Addrの両方を使用しているが、アドレスWLAN.Addrのバルク登録有効期間が満了しているので、アドレス3G.Addr、WLAN.Addrを個別にリフレッシュするための個別登録ＢＵメッセージをＨＡ１０１に送信する。

＜ＨＡの処理＞
図７はＨＡ１０１がＭＮ１００からのバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャートである。この処理は、モビリティ・バインディング・エンジン２６がＭＮ１００からバルク登録ＢＵメッセージを受信して、バルク登録検証エンジン２８がモビリティ・バインディング・エンジン２６からトリガ信号を受信したときにスタートし（ステップＳ６０のバルクＢＵ受信）、データベース・モジュール２７から関連情報（すなわちバインディング・キャッシュ２７０とバルク登録有効期間２７１）を引き出す（ステップＳ６１）。次いで、取得したバインディング・キャッシュ２７０とバルク登録有効期間２７１内に、バルク登録ＢＵメッセージ内に記述されているＩＰアドレスが有るか否かをチェックし（ステップＳ６２）、ある場合にはステップＳ６３に進み、他方、ない場合にはステップＳ６５に進む。

ステップＳ６３では、バルク登録有効期間２７１を参照してそのＩＰアドレスのバルク登録有効期間が満了しているか否かをチェックする。そして、そのＩＰアドレスのバルク登録有効期間が満了していない場合にはステップＳ６４に進み、他方、満了している場合にはステップＳ６５に進む。ステップＳ６４では、バインディング・キャッシュ２７０におけるそのＩＰアドレスに対して、パケット転送前のアドレス検証が不要である旨（アドレス検証不要）をマークしてステップＳ６６に進む。ステップＳ６５では、バインディング・キャッシュ２７０におけるそのＩＰアドレスに対して、パケット転送前のアドレス検証が必要である旨（アドレス検証要）をマークしてステップＳ６６に進む。ステップＳ６６では、その結果をリスト化してモビリティ・バインディング・エンジン２６に転送する。モビリティ・バインディング・エンジン２６はこのリストに基づいてそのバルク登録ＢＵメッセージを処理（アクセプト又は拒絶など）する。

上記の処理の例を説明する。ＨＡ１０１は現在、ＭＮ１００からのアドレス3G.Addr、WLAN.Addrのアクティブなバインディングを有する。さらに、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録が７分間、許可されていることを了解している。その４分後、ＨＡ１０１は、ＭＮ１００からアドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信したものとする。アドレスWLAN.Addrのバルク登録有効期間が満了していないので、ＨＡ１０１は、そのバインディング・リフレッシュ要求をアクセプトする。さらにその４分後、ＨＡ１０１は、ＭＮ１００からアドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信したものとする。アドレスWLAN.Addrのバルク登録有効期間が満了しているので、ＨＡ１０１は、アドレスWLAN.Addrあてにパケットを送信する前に、アドレスWLAN.Addrを検証する手順に移行する。

また、ＭＮ１００が新しいアドレスWLAN.Addr2を登録するためのバルク登録ＢＵメッセージを送信した場合、ＨＡ１０１は、アドレスWLAN.Addr2がバインディング・キャッシュ２７０内に存在しないので、アドレス検証プロセスをトリガする。アドレスWLAN.Addr2のアドレス検証が成功すると、ＨＡ１０１は、アドレスWLAN.Addr2が関連するバインディング・エントリをアップデートする。このように、ＨＡ１０１がアドレスWLAN.Addrのバルク登録有効期間をＭＮ１００に通知するので、ＭＮ１００はアドレスWLAN.Addrに対して、どのタイプのＢＵメッセージを送信すべきかを知得できる。この意味は、ＭＮ１００にとって、アドレスWLAN.Addrを使用したパケット転送が遅れることがないということである。

＜第２の実施の形態：ＭＮがバルク登録可否をＨＡに問い合わせる＞
第２の実施の形態では、ＭＮ１００がＨＡ１０１に対して、バルク登録を希望する特定のＩＰアドレスがバルク登録可能か否かを問い合わせる。図８は第２の実施の形態の通信シーケンスを示す。まず、第１の実施の形態と同様に、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用しているものとする。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。

このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ７０をＨＡ１０１に送信する。同様に、ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ７１をＨＡ１０１に送信する。第２の実施の形態では、個別登録ＢＵメッセージＳ７１はさらに、アドレスWLAN.Addrがバルク登録可能か否かを問い合わせるバルク登録許可要求を含む。

ＨＡ１０１では、アドレス3G.Addrが目的の送信元から来たと検証されることがイングレス・フィルタリングにより保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrを個別にバインディング確認（ＯＫ）するための個別登録ＢＡメッセージＳ３２をＭＮ１００に送り返す。同様に、アドレスWLAN.Addrに関してもイングレス・フィルタリングされるので、ＨＡ１０１は、アドレスWLAN.Addrを個別にバインディング確認（ＯＫ）するとともに、ＭＮ１００が複数の気付アドレスを登録していることを検出して、アドレスWLAN.Addrのバルク登録を許可する応答（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に送り返す。

ここで、第１の実施の形態と異なり、ＭＮ１００がバルク登録許可を要求する利点として、ＨＡ１０１は、特定のＩＰアドレスに対してバルク登録を使用しようとしているか否かを推測する必要がない。この意味は、ＨＡ１０１がＭＮ１００からバルク登録許可要求を受信しない場合に、ＭＮ１００がバルク登録を必要としていないものと推測できるということである。

＜バルク登録許可要求メッセージ＞
図９は、第２の実施の形態においてアドレスWLAN.Addrがバルク登録可能か否かを問い合わせるバルク登録許可要求を含む個別登録ＢＵメッセージＳ７１のフォーマットを示す。メッセージ７１は、パケットヘッダ８０とモビリティ・オプション８１を有する。パケットヘッダ８０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション８１は、バインディング識別子（ＢＩＤ）オプション８１０とフラグ８１１を含む。ＢＩＤオプション８１０は通常、ＭＮ１００とＨＡ１０１が自身のバインディング・キャッシュをルックアップするための識別子を示し、関連するバインディング・エントリをより早く発見するのに使用される。第２の実施の形態におけるフラグ８１１は、モビリティ・オプション８１内に１ビットとして設けられて、デフォルト値（＝０）のときに、パケットヘッダ８０内の送信元アドレスに対してバルク登録許可を要求しないことを示し、他方、フラグ８１１＝１のときには、パケットヘッダ８０内の送信元アドレスに対してバルク登録許可を要求することを示す。

当業者であれば、フラグ８１１は、オプションタイプとして設けることができることは明らかである。但し、本発明はこれにも限定されない。オプションタイプとして設ける場合には、ＭＮ１００は、複数の個別登録ＢＵメッセージによるパケットオーバヘッドを最適化することを希望するときには、１つの個別登録ＢＵメッセージのみにこのオプションを添付することもできる。このオプションは、複数のＩＰアドレスに対してバルク登録許可を要求していることを示す。同様に、変形例として、フラグ８１１は、ＢＩＤオプション８１０内に設けられたフラグであってもよい。また、このオプションは、ＭＮ１００がＨＡ１０１に送信する他の形態のメッセージに添付することもできる。

フラグ８１１の使用例を説明する。ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ７１をＨＡ１０１に送信する際に、フラグ８１１を１にセットしてアドレスWLAN.Addrがバルク登録可能か否かをＨＡ１０１に問い合わせる。ＨＡ１０１では、何らかのチェック機能により、アドレスWLAN.Addrがバルク登録可能か否かを決定する。このチェック機能としては、ＨＡ１０１がＨＳＳサーバやＡＡＡサーバへ問い合わせ、ＭＮ１００がバルク登録サービスに加入しているか、又はアドレスWLAN.Addrが信頼できる外部の３ＧＰＰオペレータから来たものかをチェックする。但し、これには限定されない。チェックが成功すると、ＨＡ１０１は、アドレスWLAN.Addrがバルク登録可能であること（ＢＬＫ−ＯＫ）を示す個別登録ＢＡメッセージをＭＮ１００に送り返す。また、変形例として、ＨＡ１０１はＭＮ１００に対し、アドレスWLAN.Addrのバルク登録有効期間（例えば７分間）も通知する。

＜ＭＮの動作＞
図１０は、ＭＮ１００がバルク登録の可否を判断する処理を示す。この処理は、ＢＵメッセージをＨＡ５０に送信する必要がある場合に、バルク登録可否判断エンジン２４がモビリティ・バインディング・エンジン２２からトリガ信号を受信したときにスタートし（ステップＳ９０のＢＵ送信トリガ）、データベース・モジュール２３のバインディング・アップデートリスト２３０から１つのエントリを引き出す（ステップＳ９１）。次いで、取得したエントリにおけるＩＰアドレスがバルク登録を許可されているか否かをチェックし（ステップＳ９２）、許可されていない場合にはステップＳ９３に進み、他方、許可されている場合にはステップＳ９４に進む。ステップＳ９３では、そのエントリのＩＰアドレスに対して、個別登録しなければならない旨（個別登録＝バルク登録不可）をマークしてステップＳ９５に進む。ステップＳ９４では、そのエントリのＩＰアドレスに対して、バルク登録できる旨（バルク登録可）をマークしてステップＳ９５に進む。ステップＳ９５では、バインディング・アップデートリスト２３０におけるすべてのエントリをチェックしたか否かを判定し、チェックしていなければステップＳ９１に戻り、他方、チェック済みであれば結果をリスト化してモビリティ・バインディング・エンジン２２に転送する。モビリティ・バインディング・エンジン２２はこのリストに基づいて個別登録ＢＵメッセージ又はバルク登録ＢＵメッセージを選択的に生成する。

上記の処理の例を説明する。ＭＮ１００は既に、アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録しているものとする。またＭＮ１００は、アドレスWLAN.Addrがバルク登録可能な旨を通知されている。すなわち、ＭＮ１００におけるアドレス検証情報２３２では、アドレスWLAN.Addrがバルク登録を許可されている。ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要がある場合、アドレスWLAN.Addrのバルク登録が許可されているか否かをチェックする。このチェックは、アドレス検証情報２３２がアドレスWLAN.Addrを含むか否かをチェックすることにより可能である。含むということは、ＭＮ１００がアドレスWLAN.Addrをバルク登録ＢＵメッセージに使用できることを意味する。

また、ＨＡ１０１は、ＭＮ１００がＩＰアドレスをバルク登録に使用可能か否かをアップデートすることができる。変形例として、ＨＡ１０１は、図９に示すメッセージを使用して、ＭＮ１００のバルク登録可否ステータスをアップデートすることができる。例えばＨＡ１０１は、アドレスWLAN.Addrが既にバルク登録に使用できないことを決定すると、アドレスWLAN.AddrのＢＩＤオプション８１０とフラグ８１１＝０を含むＢＡメッセージを送信する。ＨＡ１０１はこのＢＡメッセージにより、ＭＮ１００に対し、アドレスWLAN.Addrが既にバルク登録に使用できないことを通知する。なお、メッセージの種類はＢＡメッセージに限らず、Binding Revocationメッセージや、Binding Errorメッセージなどを使用してもよい。

＜ＨＡの処理＞
図１１は、ＨＡ１０１がＭＮ１００からのバルク登録ＢＵメッセージを検証する処理を示す。この処理は、ＭＮ１００からのバルク登録ＢＵメッセージを受信して、バルク登録検証エンジン２８がモビリティ・バインディング・エンジン２６からトリガ信号を受信したときにスタートし（ステップＳ１００のバルクＢＵ受信トリガ）、まず、バインディング・キャッシュ２７０から、受信したバルク登録ＢＵメッセージ内のＩＰアドレスに関連する情報（１つのエントリ）を引き出す（ステップＳ１０１）。次いで、取得したエントリにおけるＩＰアドレスがバルク登録を許可されているか否かをチェックし（ステップＳ１０２）、許可されていない場合にはステップＳ１０３に進み、そのエントリのＩＰアドレスに対して、受信したバルク登録ＢＵメッセージ内のＩＰアドレスが「間違った形式のＢＵメッセージで送信された旨」をマークする。他方、許可されている場合にはステップＳ１０４に進む、受信したバルク登録ＢＵメッセージ内のＩＰアドレスが「正しい形式のＢＵメッセージで送信された旨」をマークする。次いで、キャッシュ２７０において関連エントリをすべてチェックしたか否かを判定し、チェックしていなければステップＳ１０１に戻り、他方、チェック済みであれば結果をリスト化してモビリティ・バインディング・エンジン２６に転送する。ＨＡ１０１は、「間違った形式のＢＵメッセージで送信されたＩＰアドレス」に対してアドレス検証を実行するか、またはバルク登録が許可されていないことを示すレスポンスメッセージを返す。

上記の処理の例を説明する。ＨＡ１０１は現在、ＭＮ１００のアドレス3G.Addr、WLAN.Addrのアクティブなバインディングを有しているものとする。またＨＡ１０１は、アドレスWLAN.Addrがバルク登録可能な旨を了解している。ＨＡ１０１はＭＮ１００から、アドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信すると、データベース・モジュール２７により、アドレスWLAN.Addrのバルク登録が許可されているか否かをチェックする。このチェックは、アドレスWLAN.Addrがアドレス検証情報２７２内に存在するか否かを識別することにより可能である。すなわち、存在する場合には、アドレスWLAN.Addrのバルク登録が許可されていることを示し、存在しない場合には、アドレスWLAN.Addrのバルク登録が許可されていないことを示す。このステータスにより、ＨＡ１０１は、アドレスWLAN.Addrのリフレッシュ要求をアクセプトするか、又は拒絶する。その結果、拒絶する場合には、ＨＡ１０１は、アドレスWLAN.Addrあてにパケットを転送する前にアドレスWLAN.Addrを検証する。

このように、ＭＮ１００が、バルク登録ＢＵメッセージ内にバルク登録許可要求を付加することにより、ＨＡ１０１がＭＮ１００に対して、特定のアドレスに対してバルク登録をするつもりであるか否かを推測する必要性を除去することができる。また、ＨＡ１０１の負荷を減少することができ、特定のアドレスあてのパケット転送が遅延することを防止することができる。

＜第３の実施の形態：プロキシがアドレス検証を援助＞
第３の実施の形態では、ＭＮ１００のＩＰアドレスの検証を助けるためにプロキシ・エンティティ（代理ノード）が用いられている。プロキシ・エンティティは、望ましくはプロキシ・モバイルＩＰ（ＰＭＩＰ）プロトコルを採用しているローカル・モビリティ・アンカー（ＬＭＡ）である。図１２は、プロキシ１１００を用いた第３の実施の形態の通信シーケンスを示す。まず、第１、第２の実施の形態の同様に、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用している。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ１１０をＨＡ１１０に送信する。同様に、ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ１１１をＨＡ１０１に送信する。

ＨＡ１０１では、アドレス3G.Addrが目的の送信元から来たことが検証されることがイングレス・フィルタリングにより保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrを個別にバインディング確認（ＯＫ）するための個別登録ＢＡメッセージＳ１１２をＭＮ１００に送り返す。同様に、アドレスWLAN.Addrに関してもイングレス・フィルタリングされるため、個別登録ＢＡメッセージＳ１１３をＭＮ１００に送り返す。ＨＡ１０１は、ＭＮ１００が複数の気付アドレスを登録していることを検出するが、第３の実施の形態では、アドレスWLAN.Addrを個別にバインディング確認（ＯＫ）するとともに、バルク登録ＢＵメッセージを検証するプロキシ１１００が外部ネットワーク・ドメイン１１に存在すること（図のproxy）を記述した個別登録ＢＡメッセージＳ１１３をＭＮ１００に送り返す。ＭＮ１００がプロキシ１１００の配下に位置することをＨＡ１０１が知得する方法としては、アドレスWLAN.AddrのプリフィックスからＭＮ１００が信頼できる外部３ＧＰＰオペレータ・ネットワークに属していることを識別する方法がある。但し、これには限定されない。

ＭＮ１００は、個別登録ＢＡメッセージＳ１１３を受信すると、プロキシ１１００のＩＰアドレスをクエリ・メッセージＳ１１４で外部ネットワーク・ドメイン１１に問い合わせる（図のQuery proxy Addr）。クエリ・メッセージＳ１１４により、プロキシ１１００は自身のＩＰアドレスを応答メッセージＳ１１５でＭＮ１００に送り返す（図のResponse proxy Addr）。第３の実施の形態では、クエリ・メッセージＳ１１４と応答メッセージＳ１１５は、ＤＮＳ（domain name service）プロトコルを用いることができるが、本発明はこれには限定されない。ＭＮ１００は、プロキシ１１００のＩＰアドレスを知得すると、アドレスWLAN.Addrの検証を要求するためのバルク登録ＢＵメッセージＳ１１６を３Ｇセルラ・インタフェース１０００からプロキシ１１００に送信する。

バルク登録ＢＵメッセージＳ１１６はプロキシ１１００に対し、メッセージＳ１１６内に検証要求するＩＰアドレス（すなわちアドレスWLAN.Addr）が記述されていることを指示する。プロキシ１１００にアドレスWLAN.Addrを通知する理由は、メッセージＳ１１６がＭＮ１００とＨＡ１０１との間で暗号化されているからである。この意味は、プロキシ１１００がメッセージＳ１１６を解読してアドレスWLAN.Addrが真か否かを検証できないということである。そこで、プロキシ１１００は一旦、メッセージＳ１１６内で検証要求されているＩＰアドレスがＭＮ１００に属するものとみなして、メッセージＳ１１６に署名したバルク登録ＢＵメッセージＳ１１７をＨＡ１０１に送信する。この署名は、ＣＧＡ（cryptographically generated addresses）プロトコルを用いることができるが、本発明はこれには限定されない。ＣＧＡプロトコルの場合、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１７をプロキシ１１００の秘密キーで署名し、ＨＡ１０１は、受信したバルク登録ＢＵメッセージＳ１１７をプロキシ１１００の公開鍵を使用して検証する。

ＭＮ１００のバルク登録ＢＵメッセージを検証するためにプロキシ１１００を使用する利点は、ＭＮ１００がＩＰアドレスを暗号化する必要があるという複雑さを除去することにある。ＭＮ１００が暗号化する必要性をプロキシ１１００（例えばサーバ）にシフトすることにより、ＭＮ１００の処理する負担を軽減することができる。なお、サーバであるプロキシ１１００は、ＭＮ１００より計算能力が高い。

＜バルク登録ＢＵメッセージ＞
図１３は第３の実施の形態におけるバルク登録ＢＵメッセージＳ１１６、Ｓ１１７のフォーマットを示す。メッセージＳ１１６、Ｓ１１７は、パケットヘッダ１２０と、モビリティ・オプション１２１と、モバイルノード識別子１２２と、検証オプション１２３を含む。パケットヘッダ８０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション１２１は、バインディング識別子（ＢＩＤ）オプション１２１０とＩＰアドレス・オプション１２１１を含む。ＢＩＤオプション１２１０は通常、ＭＮ１００とＨＡ１０１がそれぞれ自身のバインディング・アップデートリスト２３０、バインディング・キャッシュ２７０をルックアップするための識別子を示し、関連するバインディング・エントリをより早く発見するのに使用される。

ＩＰアドレス・オプション１２１１は、パケットヘッダ１２０内の送信元アドレスに加えて、ＭＮ１００がＨＡ１０１に登録を希望する１つの追加のＩＰアドレスを含む。この追加のＩＰアドレスは、ＢＩＤオプション１２１０内のＢＩＤに関連している。バルク登録ＢＵメッセージＳ１１６、Ｓ１１７は、１を超えるＩＰアドレス・オプション１２１１を含んでもよい。これは、バルク登録ＢＵメッセージＳ１１６、Ｓ１１７が複数のＢＩＤオプション１２１０と複数のＩＰアドレス・オプション１２１１を含むことを意味する。モバイルノード識別子１２２には、このバルク登録ＢＵメッセージＳ１１６、Ｓ１１７を送信したＭＮ１００の識別子を記述する。モバイルノード識別子１２２により、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を検証するときに、追加のＩＰアドレスがＭＮ１００に属するかを知得することができる。

検証オプション１２３は、ＩＰアドレス・オプション１２３０と、パラメータ・オプション１２３１と、署名オプション１２３２を含む。ＩＰアドレス・オプション１２３０には、ＭＮ１００がプロキシ１１００に検証させる追加のＩＰアドレスを記述する。ＩＰアドレス・オプション１２３０におけるＩＰアドレスとＩＰアドレス・オプション１２１１におけるＩＰアドレスは、望ましくは同じである。パラメータ・オプション１２３１は、ＨＡ１０１に対して、プロキシ１１００がバルク登録ＢＵメッセージＳ１１６を検証するために使用するセキュリティ・パラメータを指示する。望ましくは、パラメータ・オプション１２３１内の情報は、プロキシ１１００の公開鍵か、又はプロキシ１１００がＣＧＡで使用する偶数のパラメータであるが、本発明ではこれには限定されない。

最後に、署名オプション１２３２は、一般的にはプロキシ１１００の署名を含む。この署名はＨＡ１０１に対し、バルク登録ＢＵメッセージＳ１１７内のＩＰアドレスが真であることをプロキシ１１００が検証したことを示す。この署名は望ましくは、バルク登録ＢＵメッセージＳ１１７の全体とプロキシ１１００の秘密鍵の連結である。オプションとして、パケットサイズを低減するために、この署名は、バルク登録ＢＵメッセージＳ１１７の全体とプロキシ１１００の秘密鍵の連結の一部でもよい。

プロキシ１１００がバルク登録ＢＵメッセージＳ１１６に署名する理由は、悪意のあるノードがリプレイ・アタックを仕掛けることを防止するためである。リプレイ・アタックとは、悪意のあるノードがバルク登録ＢＵメッセージＳ１１６、Ｓ１１７を盗み見て改変し、後でＨＡ１０１に送信することを言う。例えばプロキシ１１００がアドレスWLAN.Addr用のバルク登録ＢＵメッセージＳ１１６を検証する場合、プロキシ１１００は、検証オプション１２３のみにアドレスWLAN.Addrを記述して署名する。ＨＡ１０１は、この署名が正しいと確認すると、アドレスWLAN.Addrをアクセプトしてバインディング・キャッシュ２３０に登録する。

さて、悪意のあるノードがバルク登録ＢＵメッセージＳ１１７を盗み見て、ＩＰアドレス・オプション１２１１内のＩＰアドレスを他のＩＰアドレスに改変し、この改変したバルク登録ＢＵメッセージＳ１１７をＨＡ１０１に送信したとする。上記のように署名が正しいと確認したＨＡ１０１は、検証オプション１２３内のアドレスWLAN.AddrがＩＰアドレス・オプション１２１１内のＩＰアドレスと異なることに気付く。このため、ＨＡ１０１は、送信元が悪意のあるノードであるとして、バインディング・キャッシュ２３０からアドレスWLAN.Addrを削除する。このような動作により、悪意のあるノードがアドレスWLAN.Addrを悪用して通信サービスが崩壊することを防止することができる。悪意のある行為を防止するためには、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１７の全体に署名すべきである。この方法により、悪意のあるノードがバルク登録ＢＵメッセージＳ１１７を改変することを困難にすることができる。

＜プロキシの処理＞
図１４は、プロキシ１１００がバルク登録ＢＵメッセージＳ１１６内のＩＰアドレス検証を援助する処理を示す。この処理は、バルク登録ＢＵメッセージＳ１１６を受信したときにスタートし（ステップＳ１３０）、メッセージＳ１１６の検証オプション１２３内から１つのＩＰアドレスを引き出して（ステップＳ１３１）、そのＩＰアドレスをＭＮ１００が実際に使用しているか否か、すなわちそのＩＰアドレスがＭＮ１００に属するか否かをチェックする（ステップＳ１３２）。このチェック方法の１つとして、プロキシ１１００のデータベースにおいてそのＩＰアドレスがバルク登録ＢＵメッセージＳ１１６内のモバイルノード識別子に対応しているかを識別する。そのＩＰアドレスがＭＮ１００に属しないと判定した場合には、バルク登録ＢＵメッセージＳ１１６を拒絶して検証オプション１２３内の他のＩＰアドレスをチェックせず（ステップＳ１３３）、次いでアイドルモードに戻る（ステップＳ１３６）。

他方、ステップＳ１３２においてそのＩＰアドレスがＭＮ１００に属すると判定した場合には、検証オプション１２３内に残りのＩＰアドレスが存在するか否かをチェックし（ステップＳ１３４）、存在する場合にはステップＳ１３１に戻る。ステップＳ１３４において検証オプション１２３内に残りのＩＰアドレスが存在しない場合には、バルク登録ＢＵメッセージＳ１１６の全体に署名してＨＡ１０１に転送し（ステップＳ１３５）、次いでアイドルモードに戻る（ステップＳ１３６）。

プロキシ１１００の処理をさらに詳しく説明する。プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を受信すると、モバイルノード識別子１２２に基づいてバルク登録ＢＵメッセージＳ１１６がＭＮ１００から来たことを確認する。また、検証オプション１２３内のＩＰアドレス・オプション１２３０により、プロキシ１１００は、ＭＮ１００がアドレスWLAN.AddrをＨＡ１０１に登録したいことを知得する。プロキシ１１００は自身のデータベースをチェックして、アドレスWLAN.Addrが外部ネットワーク・ドメイン１１でＭＮ１００に割り当てられたものかを識別する。望ましくは、プロキシ１１００は、ＤＣＨＰサーバに問い合わせて、アドレスWLAN.AddrがＭＮ１００に割り当てられたものかを検証する。ＤＣＨＰサーバからの応答が肯定である場合、プロキシ１１００は、署名を署名オプション１２３２に添付し、バルク登録ＢＵメッセージＳ１１７をＭＮ１００のＨＡ１０１に転送する。逆に、ＤＣＨＰサーバからの応答が否定である場合、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を拒絶する。その結果、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６の送信元が悪意のあるノードの疑いがあるとして今後のチェックのためにマークすることができる。

プロキシ１１００を使用すると、ＨＡ１０１がＭＮ１００のＩＰアドレスを検証するために通信するエンティティの数を減少することができる。例えばＨＡ１０１は、グローバル通信ドメイン１２配下の数千のモバイルノードではなく、グローバル通信ドメイン１２内の選択されたアンカーポイントと通信するのみでよい。また、通信チャネルが減少すると、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第４の実施の形態：ＭＮ／ＨＡがバルク登録可否を外部ネットワークに応じて決定＞
第４の実施の形態では、例えばＭＮ１００は、バルク登録を行うか否かの判断を、外部ネットワーク・ドメイン１１において初期起動したときに、以前にＨＡ１０１により通知されていた情報に基づいて行う。望ましくは、その情報は、どのアクセスネットワークのＩＰアドレスがバルク登録可能か（バルク登録として使用されているか）の情報である。但し、本発明はこれには限定されない。例えばＨＡ１０１は、ＭＮ１００が接続（connect）しているアクセスネットワークに基づいてＭＮ１００のバルク登録動作をアップデートしている。ＨＡ１０１は、ＭＮ１００が全世界的に相互に動作可能なマイクロ波アクセス・ネットワーク（ＷｉＭＡＸネットワーク）に接続（connect）していることを了解すると、ＭＮ１００のどのＷｉＭＡＸアドレスもバルク登録可能であること（ＢＬＫ−ＯＫ）を通知する。望ましくは、ＭＮ１００が接続（connect）しているどのアクセスネットワークがバルク登録可能かをＨＡ１０１がいかに知得するかは、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１との間の交渉次第である。ＭＮ１００は、ＷｉＭＡＸアドレスについてＨＡ１０１をアップデートしたいときにはいつでも、ＷｉＭＡＸアドレスをバルク登録するためのバルク登録ＢＵメッセージをＨＡ１０１に送信する。

変形例として、どのタイプのＩＰアドレスがバルク登録可能かを示す情報を予めＭＮ１００に設定しておく。この手法によれば、この情報をＭＮ１００とＨＡ１０１との間で通信する必要性を除去することができる。ＭＮ１００は、どのタイプのアクセスネットワークがＨＡ１０１にとって信頼できるかを知得していると、ＨＡ１０１に送信すべきＢＵメッセージのタイプがわかる、したがって、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第５の実施の形態：ＭＮが送信元アドレスを切り換えてバルク登録有効期間を延長＞
第５の実施の形態では、ＭＮ１００がバルク登録ＢＵメッセージを使用して個々のアドレスのバルク登録有効期間を延長する。この手法を実現するために、ＭＮ１００は、ＨＡ１０１におけるＩＰアドレスを更新するときに、インタフェース１０００、１００１を交互に使用する。この手法により、バルク登録ＢＵメッセージの送信元アドレスで送信されるＩＰアドレスが交互にイングレス・フィルタリングにより検証される。

以下に具体例を説明する。ＭＮ１００がアドレス3G.Addr、WLAN.Addrの両方をＨＡ１０１に登録する場合、ＷＬＡＮアクセスネットワーク１１１が不安定であるので、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間として５分間を割り当てる。また、３Ｇセルラ・アクセスネットワーク１１が安定しているので、ＨＡ１０１は、アドレス3G.Addrのバルク登録有効期間として７分間を割り当てる。５分後、ＭＮ１００は、ＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrの登録をリフレッシュする必要がある場合、アドレス3G.Addrのバルク登録有効期間が未だアクティブであるので、送信元アドレスをアドレスWLAN.Addrとし、追加のＩＰアドレスをアドレス3G.Addrとしたバルク登録ＢＵメッセージを送信する。この手法により、イングレス・フィルタリングによりアドレスWLAN.Addrが検証されるのみならず、アドレス3G.Addr用の個別登録ＢＵメッセージを送信する必要性を除去することができる。イングレス・フィルタリングによりアドレスWLAN.Addrが検証されると、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間を延長する。

変形例として、ＭＮ１００のすべてのＩＰアドレスのバルク登録有効期間を同じとする。このため、送信元アドレスを順番に入れ換えるか、２つのＩＰアドレスをペアリングし（一方を送信元アドレスとする）、バルク登録ＢＵメッセージを使用して各ＩＰアドレスのバルク登録有効期間を延長することができる。

ＭＮ１００がＨＡ１０１におけるＩＰアドレスの登録を更新するときに、インタフェース１０００、１００１を交互に使用できるということは、特定のＩＰアドレスのバルク登録有効期間を、ＨＡ１０１と素早く交渉して延長することができるということである。このＨＡ１０１との効率的な交渉により、ＭＮ１００がパケット転送のための気付アドレス使用が遅れることを防止できる。

＜第６の実施の形態：バルクＢＡ＞
第６の実施の形態では、図４において、ＨＡ１０１は個別登録ＢＵメッセージＳ３０、Ｓ３１、バルク登録ＢＵメッセージ３４ａの応答として、ＭＮ１００に複数の個別登録ＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂを送り返す代わりに、１つのＢＡメッセージ（以下、バルク登録ＢＡメッセージ３４ｃ）を送り返す。図１５はバルク登録ＢＡメッセージ３４ｃのフォーマットを示す。バルク登録ＢＡメッセージ３４ｃは、パケットヘッダ１４０と、フラグ１４１と、モビリティ・オプション１４２を含む。パケットヘッダ１４０は、メッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。フラグ１４１は、ＨＡ１０１がＭＮ１００に対し、このバルク登録ＢＡメッセージ３４ｃが各ＩＰアドレスに関するバルク登録についての複数の異なる通知を含むか否かを通知する。フラグ１４１は１ビットでよく、デフォルト値（＝０）は、このバルク登録ＢＡメッセージ３４ｃ内のすべての通知が同じであることを示す。他方、フラグ１４１＝１の場合、このバルク登録ＢＡメッセージ３４ｃ内の通知が異なることを示す。この場合、ＭＮ１００は、モビリティ・オプション１４２内の個々の通知を検査する必要がある。

モビリティ・オプション１４２は、ＢＩＤオプション１４２０と、シーケンス番号オプション１４２１と、ステータス・オプション１４２２と、通知オプション１４２３を含む。ＢＩＤオプション１４２０は、ＭＮ１００がＨＡ１０１に登録するＩＰアドレスに割り当てられたＢＩＤを示す。望ましくは、ＢＩＤオプション１４２０に記述されているＢＩＤは、ＭＮ１００がＨＡ１０１に送信したバルク登録ＢＵメッセージ３４ａに記述されているＢＩＤである。シーケンス番号オプション１４２１は典型的には、ＨＡ１０１が受信したバルク登録ＢＵメッセージ３４ａで伝送されたシーケンス番号を示す。シーケンス番号により、ＭＮ１００は、ＭＮ１００が送信したバルク登録ＢＵメッセージ３４ａにこのバルク登録ＢＡメッセージ３４ｃが対応しているかを識別することができる。

ステータス・オプション１４２２はＭＮ１００に対して、特定のＩＰアドレスの登録がＨＡ１０１において成功したか否かを通知する。ステータス・オプション１４２２はさらに、典型的にはＭＮ１００に対してＨＡ１０１が登録を拒否した理由も通知する。最後の通知オプション１４２３は、特定のＩＰアドレスがバルク登録可能か否かのＨＡ１０１の意図を示す。望ましくは、通知オプション１４２３はさらに、バルク登録有効期間を示す。このバルク登録ＢＡメッセージは、１を超えるモビリティ・オプション１４２を含むことができる。すなわち、バルク登録ＢＡメッセージ３４ｃは、個別登録ＢＵメッセージＳ３０、Ｓ３１、バルク登録ＢＵメッセージ３４ａで登録が要求された個々のアドレスそれぞれに対応する複数のＢＩＤオプション１４２０と、複数のシーケンス番号オプション１４２１と、複数のステータス・オプション１４２２と、複数の通知オプション１４２３を含むことができる。

変形例として、このバルク登録ＢＡメッセージ３４ｃは、同じシーケンス番号を含んでもよい。例えば、もしＭＮ１００が１つのバルク登録ＢＵメッセージ３４ａをＨＡ１０１に送信した場合、１つのシーケンス番号によりこのバルク登録ＢＵメッセージ３４ａを識別する。この場合、バルク登録ＢＡメッセージ３４ｃのパケットサイズを最適化するために、ＨＡ１０１は、すべての登録されたＩＰアドレスに対して１つのシーケンス番号オプション１４２１を使用することができる。

他の変形例として、バルク登録ＢＡメッセージ３４ｃは、同じステータスを含んでもよい。例えばＨＡ１０１は、もしバルク登録ＢＵメッセージ３４ａ内のすべてのＩＰアドレス登録をアクセプトする場合、１つのステータス・オプション１４２２を使用してすべてのＩＰアドレスのステータスを示すことができる。さらに他の変形例として、このバルクＢＡメッセージは、同じ通知を含んでもよい。例えばＨＡ１０１は、もしすべての登録されたＩＰアドレスに対して同じバルク登録有効期間を割り当てる場合、バルク登録ＢＡメッセージ３４ｃのパケットサイズを最適化するために、１つの通知オプション１４２３を使用して共通のバルク登録有効期間を示すことができる。

さらには、登録されたすべてのＩＰアドレスのそれぞれに対するモビリティ・オプション１４２を含めるのではなく、１つのモビリティ・オプション１４２を含めて、すべてのＩＰアドレスが登録されたことを示してもよい。この場合、バルク登録ＢＡメッセージ３４ｃに含まれている１つのモビリティ・オプション１４２の中のＢＩＤオプション１４２０の値や、ステータス・オプション１４２２の値として、すべてのＩＰアドレスが登録されたことを示す特別な値を指定することが望ましい。

図１６は、ＭＮ１００がバルク登録ＢＡメッセージ３４ｃを受信した場合の処理を示す。この処理は、バルク登録ＢＡメッセージ３４ｃをＨＡ１０１から受信した場合にスタートし（ステップＳ１５０）、受信したメッセージ３４ｃから１つのモビリティ・オプション１４２を引き出す（ステップＳ１５１）。１つのモビリティ・オプション１４２を引き出すと、モビリティ・オプション１４２内のステータス・オプション１４２２に基づいて１つのＩＰアドレス登録要求がアクセプトされたか否かをチェックする（ステップＳ１５２）。アクセプトされなかった場合にはそのＩＰアドレスに対して「拒絶」をマークし（ステップＳ１５３）、次いでステップＳ１５７に進む。

ステップＳ１５２においてアクセプトされた場合には、そのＩＰアドレスがバルク登録されたか否かをチェックする（ステップＳ１５４）。バルク登録されなかった場合には、そのＩＰアドレスに対して「アクセプト」と「バルク登録不可」をマークし（ステップＳ１５５）、次いでステップＳ１５７に進む。ステップＳ１５４においてバルク登録された場合には、そのＩＰアドレスに対して「アクセプト」と「バルク登録可」をマークし（ステップＳ１５６）、次いでステップＳ１５７に進む。ステップＳ１５７では、受信したメッセージ３４ｃ内に次のモビリティ・オプション１４２があるか否かをチェックし、もしあればステップＳ１５１に戻り、他方、最後のモビリティ・オプション１４２であれば、バインディング・アップデートリスト２３０をアップデートするために、処理結果をリスト化してモビリティ・バインディング・エンジン２２に転送する（ステップＳ１５８）。

具体例を説明する。ＭＮ１００は現在、ＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrをリフレッシュするためにバルク登録を使用しているものとする。ＭＮ１００は、許可されているアドレス3G.Addr、WLAN.Addrのバルク登録有効期間に基づいて、アドレス3G.Addr、WLAN.Addrのバルク登録有効期間がまもなく満了することを知得している。このことは、ＭＮ１００がアドレス3G.Addr、WLAN.Addrを個別にリフレッシュするために個別登録ＢＵメッセージを送信する必要があることを黙示している。ＨＡ１０１は、これらの個別登録ＢＵメッセージを受信すると、アドレス3G.Addr、WLAN.Addrそれぞれの新しいバルク登録有効期間をＭＮ１００に通知する必要がある。そこで、ＨＡ１０１は、個別登録ＢＡメッセージ３４ｂを送信する代わりに、バルク登録ＢＡメッセージ３４ｃを使用してアドレス3G.Addr、WLAN.Addrの各バルク登録有効期間をＭＮ１００に通知する。この手法により、ＨＡ１０１がＭＮ１００に送信しなければならないメッセージ数を最適化することができる。

バルク登録ＢＡメッセージ３４ｃを使用することにより、ＨＡ１０１がＭＮ１００に対して、ＭＮ１００のＩＰアドレスのバルク登録サポートのステータスを通知する方法を効率化することができる。したがって、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第７の実施の形態：ＨＡがバルクＢＵ送信ＩＦを指示＞
第７の実施の形態では、ＨＡ１０１がＭＮ１００に対し、ＩＦ１０００、１００１のうち、バルク登録ＢＵメッセージ３４ａを送信すべきＩＦを指示する。図８を参照して第７の実施の形態について説明する。ＨＡ１０１からＭＮ１００に送信されるアドレスWLAN.Addrの個別登録ＢＡメッセージＳ７３は、バルク登録ＢＵメッセージ３４ａを送信すべきＩＦを指示する。例えば、ＨＡ１０１は、ＭＮ１００がＩＦ１００１（アドレスWLAN.Addr）からバルク登録ＢＵメッセージ３４ａを送信することを希望するものと仮定する。この場合、ＭＮ１００がＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrの両方の登録を更新するためのバルク登録ＢＵメッセージ３４ａを送信する必要があるときには、ＭＮ１００は、ＨＡ１０１により指示されたＩＦ１００１（アドレスWLAN.Addr）からバルク登録ＢＵメッセージ３４ａを送信する。つまりこの場合、3G.Addrがバルク登録されるアドレスとなる。なお、バルク登録ＢＵメッセージを送信するべきＩＦを指示する代わりに、バルク登録を許可するアドレスを指示してもよい。例えば、ＨＡ１０１は、ＭＮ１００のアドレス3G.Addrを、アドレスWLAN.Addrの登録ＢＵメッセージに挿入してバルク登録メッセージとして送信してもよいと判断した場合には、個別登録ＢＡメッセージＳ７２に、バルク登録を指示する情報が含まれる。また、ＨＡ１０１は、ＭＮ１００のアドレスWLAN.Addrを、アドレス3G.Addrの登録ＢＵメッセージに挿入してバルク登録メッセージとして送信してもよいと判断した場合には、個別登録ＢＡメッセージＳ７３に、バルク登録を指示する情報が含まれる。

＜第８の実施の形態：ＵＥのＩＦ１０００がホームネットワーク・ドメイン１０に直接接続＞
第８の実施の形態では、図１７に示すように、ＵＥ１００のＩＦ１０００が３Ｇセルラ１１０を介してＵＥ１００のホームネットワーク・ドメイン１０に直接接続し、ＩＦ１００１がＷＬＡＮ１１１（又はＷｉＭＡＸ、ＨＲＰＤ：High Rate Packet Data）などのＮｏｎ−３ＧＰＰネットワーク（Ｎｏｎ−３ＧＰＰ Ｎｅｔｗｏｒｋ）を介してホームネットワーク・ドメイン１０へ接続している場合に、ＨＡ１０１は、ＷＬＡＮ１１１から取得したＩＰアドレスをＣｏＡとして通知・登録するための個別登録ＢＵメッセージ送信するべきＩＦを指示する。本発明の第７の実施の形態との違いは、ＩＦ１０００（３Ｇインタフェース、３Ｇ−ＩＦ）が接続しているネットワークが外部ネットワーク・ドメインではなく、ホームネットワーク・ドメイン１０であるため、ＨＡ１０１によって指定されたＩＦから送信されるメッセージが、バルク登録ＢＵメッセージではなく、ＩＦ１００１（ＷＬＡＮインタフェース、ＷＬＡＮ−ＩＦ）に関するＣｏＡを含む個別登録ＢＵメッセージである点である。つまり、ＨＡ１０１はＢＵメッセージを送信するＩＦを指定するが、それを受けたＵＥ１００が送信するＢＵメッセージは、バルク登録ＢＵメッセージに限らず、図１７に示す接続形態の場合には、個別登録ＢＵメッセージを指定されたＩＦから送信する。

本実施の形態で述べるように、ＵＥ１００が、バルクＢＵメッセージだけでなく、個別登録ＢＵメッセージをＩＦ１０００から送信することができれば、３Ｇセルラ１１０が提供する様々な利点（安定した帯域（ＱｏＳ）や接続状態、強固なセキュリティ、ＨＡ１０１への最短パス）を使用してＢＵメッセージを送信することができるという利点をＵＥ１００及びホームネットワーク・ドメイン１０の双方で得られる。

通常３Ｇセルラ１１０への接続は、ＰＭＩＰやＧＴＰ（GPRS Tunneling Protocol）などのネットワークベースの移動制御プロトコルによって管理されるため、ＵＥ１００は、ＩＦ１０００に割り当てられたアドレスを個別登録ＢＵメッセージで通知する必要はなく、割り当てられたアドレスをホームアドレス（ＨｏＡ）として直接使用することができる。一方、Ｎｏｎ−３ＧＰＰネットワークへの接続ではＵＥ１００はＭＩＰｖ６（又はＭＩＰｖ４）を使用するため、ＷＬＡＮ１１１から割り当てられたアドレスをＨｏＡに対するＣｏＡとしてＨＡ１０１へ登録する。

図１８は、本実施の形態におけるメッセージシーケンスを表したものである。ＵＥ１００は、Ｎｏｎ−３ＧＰＰネットワークへ接続しているＩＦ１００１のＩＰアドレスをＨＡ１０１へ登録するために、個別登録ＢＵメッセージを送信する。ＵＥ１００からの個別登録ＢＵメッセージを受けたＨＡ１０１は、ＵＥ１００が登録済みのバインディング・キャッシュを更新するための個別登録ＢＵメッセージを送信する際に、ＩＦ１０００を使用することを許可するか否かを判断する。この判断は、例えば、通知されたＣｏＡを割り当てたネットワーク（ＷＬＡＮ１１１）が、ホームネットワーク・ドメイン１０にとって信頼できるネットワークであるか否かを確認することによって行うことができるが、これに限定されない。また、Ｎｏｎ−３ＧＰＰネットワークが、ＨＡ１０１が属するオペレータによって管理されているネットワークである場合に、ＩＦ１０００の使用を許可すると判断してもよい。さらにまた、ＩＦ１００１から送信されたＢＵメッセージを一定回数受信した場合に、それ以降のＢＵメッセージをＩＦ１０００から送信するよう指示してもよい。さらにまた、ＵＥが同一のＮｏｎ−３ＧＰＰネットワークに一定時間以上接続している場合に、それ以降のＢＵメッセージをＩＦ１０００から送信するよう指示してもよい。

ＨＡ１０１が、ＩＦ１０００を使用した個別登録ＢＵメッセージの送信を許可する場合は、ＵＥ１００に対し、ＩＦ１００１の使用が許可されたこと（ＩＦ１０００を使用すること）を示すステータスを含む個別登録ＢＡメッセージをレスポンスとして返す。なお、ＨＡ１０１は、ＩＦ１０００の使用が許可されている期間を示す３Ｇ−ＩＦ有効期間を通知してもよい。

個別登録ＢＡメッセージを受けたＵＥ１００は、ＩＦ１００１のＩＰアドレスに関するバインディング・アップデートリストエントリの中に、ＩＦ１０００の使用が可能であることを示す情報を格納する。そして、バインディング・キャッシュを更新するために個別登録ＢＵメッセージを送信する際に、バインディング・アップデートリストエントリを参照し、ＩＦ１０００の使用が可能であるか否かを確認する。確認の結果、可能であった場合には、ＩＦ１００１のＩＰアドレスを登録するための個別登録ＢＵメッセージを、ＩＦ１０００を使用して送信する。なお、３Ｇ−ＩＦ有効期間が通知されている場合は、３Ｇ−ＩＦ有効期間が経過した時点で、バインディング・アップデートリストエントリ内のＩＦ１０００使用可能情報は無効化される。無効化された後に個別登録ＢＵメッセージを送信する場合には、ＩＦ１００１が使用される。

図１９は、個別登録ＢＡメッセージのフォーマット例である。モビリティ・オプションには、登録対象のＣｏＡに対応するＢＩＤを含むＢＩＤオプションと、ＣｏＡの登録結果を示すステータスと、次回以降の送信にＩＦ１０００を使用することが可能であるか否か（３Ｇ−ＩＦ使用許可情報）を示す通知オプションが含まれている。３Ｇ−ＩＦ使用許可情報は、ステータスがＯＫの場合に許可または不許可が示される。なお、ステータス、及び３Ｇ−ＩＦ使用許可情報は、ＢＩＤオプションの中に含まれていてもよいし、ＢＡヘッダ（不図示）の中に含まれていてもよい。

図２０は、ＩＦ１０００を使用して送信する場合の個別登録ＢＵメッセージのフォーマット例である。パケットヘッダの送信元アドレスにはＩＦ１０００に割り当てられているＩＰアドレス（ホームアドレス）が設定され、宛先アドレスにはＨＡ１０１のアドレスが設定される。また、パケットヘッダには、ＢＵヘッダも含まれている。さらに、モビリティ・オプションとして、ホームアドレスを含むＨｏＡオプションや、登録対象のＣｏＡ及び対応するＢＩＤが含まれる。また、個別登録ＢＵメッセージが３Ｇ−ＩＦを使用して送信されたメッセージであり、通常の個別登録ＢＵメッセージと区別ができるように、３Ｇ−ＩＦ使用情報が含まれる。３Ｇ−ＩＦ使用情報は、ＢＩＤオプションの中にフラグ（３Ｇ−ＩＦ使用許可フラグ）として含まれていてもよい。またＣｏＡもＢＩＤオプションに含まれていてもよい。なお、ＩＦ１０００を使用して送信する場合の個別登録ＢＵメッセージとしては、ＩＦ１００１から送信する場合の個別登録ＢＵメッセージをＩＦ１０００のアドレスでカプセル化して送信する方法を用いてもよい。また、カプセル化の代わりに、ＣｏＡを含むルーティングヘッダを付加して送信してもよい。

図２を用いてＵＥ１００の構成を説明すると、バルク登録可否判断エンジン２４は、本実施の形態では、３Ｇ−ＩＦ使用可否判断エンジンとして機能する。つまり、モビリティ・バインディング・エンジン２２によって、バインディング・キャッシュの更新がトリガされると、３Ｇ−ＩＦ使用可否判断エンジンは、ＩＦ１００１のＩＰアドレスを登録する際に、データベース・モジュール２３内のバインディング・アップデートリスト２３０を参照し、ＩＦ１０００を使用することが許可されているか否か、または、ＩＦ１０００を使用することが指定されているか否かを確認する。確認の結果、ＩＦ１０００の使用が許可されている場合には、図２０に示されている個別登録ＢＵメッセージを生成し、ＩＦ１００１を用いて送信する。

図３を用いてＨＡ１０１の構成を説明する。第７の実施の形態において、バルク登録検証エンジン２８が許可するバルク登録は、ＵＥ１００はＩＦ１００１のＣｏＡをＩＦ１０００から送信するＢＵメッセージに含めてもよいということを意味する。したがって、本実施の形態のＨＡ１０１は、第７の実施の形態におけるバルク登録の可否判断と同様の判断を行うと定義することができる。一方、本実施の形態のＨＡ１０１は、３Ｇ−ＩＦを使用して個別登録ＢＵメッセージの送信の可否を判断すると定義することもできる。この場合、バルク登録検証エンジン２８は、３Ｇ−ＩＦ使用検証エンジンとして機能する。つまり、モビリティ・バインディング・エンジン２６によって受信された個別登録ＢＵメッセージについて、ＵＥ１００がＩＦ１０００を使用して送信することを許可するか否かを判断する。許可すると判断した場合には、バインディング・キャッシュ２７０に、許可を示す情報を格納するとともに、許可を示すステータスを含む個別登録ＢＡメッセージを返す。

本発明の第８の実施の形態によって、ＵＥ１００は、Ｎｏｎ−３ＧＰＰネットワークに接続しているＩＦに割り当てられたＩＰアドレスを登録するＢＵメッセージを、３Ｇネットワークに接続するＩＦから送信することができることを知得することができ、不安定なＮｏｎ−３ＧＰＰネットワークではなく、安定した信頼性のある３ＧＰＰネットワークを使用してＢＵメッセージを送信することが可能となる。

以上、本発明の望ましい実施の形態について説明したが、当業者であれば、本発明の範囲を逸脱しない範囲で、種々の変形が可能であることは明らかである。例えば、ＭＮ１００については、当業者であれば、ネットワーク・モビリティ（ＮＥＭＯ）プロトコルを採用したモバイル・ルータにも適用することができることは明らかである。この場合、モバイル・ルータは、バルク登録ＢＵメッセージ３４ａを使用してプリフィックスをＨＡ１０１に登録する。このことは、プリフィックスの範囲内で構成されたＩＰアドレスがモバイル・ルータに属することを目視している。

また、本発明は、プロキシ・モバイルＩＰ（ＰＭＩＰ）プロトコルを採用したモバイル・アクセス・ゲートウェイ（ＭＡＧ）にも適用することができる。ここで、ＭＡＧは、前述した実施の形態におけるプロキシ１１００であって、ローカル・モビリティ・アンカー（ＬＭＡ）がＩＰアドレスを検証するのを助ける。このため、ＭＡＧは、バルク登録ＢＵメッセージ３４ａを使用して多くのモバイル装置（モバイルノードやモバイル・ルータ）のＩＰアドレスをＬＭＡに登録する。

加えて、本発明は、ＭＩＰｖ４（mobile IP version 4）を採用した外部エージェントにも適用することができる。この場合、外部エージェントはバルク登録ＢＵメッセージ３４ａを使用して、ＭＮ１００が複数のＩＰアドレスをＨＡ１０１に登録するのを助ける。さらに、外部エージェントは、前述した実施の形態におけるプロキシ１１００であって、ＨＡ１０１がＩＰアドレスを検証するのを助けることも可能である。

最後に、上記の実施の形態では、ＨＡ１０１がＭＮ１００からのＢＵメッセージＳ３０、Ｓ３１、Ｓ３４ａ等の受信側であって、ＭＮ１００へのＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂ、Ｓ３４ｃ等の送信側である場合について説明したが、当業者であれば、ＨＡ１０１は、他のエンティティ（例えば通信相手のノード、通信相手のルータ、ＬＭＡ）に置き換えても、ＭＮ１００からのＢＵメッセージＳ３０、Ｓ３１、Ｓ３４ａ等を受信してＭＮ１００へのＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂ、Ｓ３４ｃ等を送信することも可能である。

なお、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明によれば、特許請求の範囲に記載した発明の他に、以下のような発明が提供される。
（１）前記第２の手段は、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスがネットワークのイングレス・フィルタリングにより検証されたものとみなして登録するとともに、その送信元アドレスあてに前記バルク登録を許可する応答メッセージを送信し、
前記第３の手段は、前記移動装置が前記バルク登録メッセージを送信する場合に、前記バルク登録を許可されたアドレス以外のインタフェースを送信元として、前記バルク登録を許可された送信元アドレスを送信元アドレスフィールド外に含む前記バルク登録メッセージを送信することを特徴とする請求項１０に記載のアドレス登録システム。

（２）前記第２の手段は、前記移動管理装置が前記応答メッセージによりバルク登録有効期間を前記移動装置に通知し、
前記第３の手段は、前記移動装置が前記バルク登録メッセージを前記バルク登録有効期間内に送信することを特徴とする請求項１０又は上記の（１）に記載のアドレス登録システム。

（３）前記第１の手段は、前記移動装置が前記バルク登録を希望するアドレスを送信元アドレスとする前記個別登録メッセージにより、バルク登録許可を前記移動管理装置に要求し、
前記第３の手段は、前記移動装置が前記バルク登録を許可されたアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１０、上記の（１）及び（２）のいずれか１つに記載のアドレス登録システム。

（４）前記第２の手段は、前記移動管理装置が前記応答メッセージにより代理ノードを移動装置に通知し、
前記第３の手段は、移動装置が前記バルク登録メッセージを前記応答メッセージにより通知された代理ノードに送信し、前記代理ノードが前記バルク登録メッセージに署名して前記移動管理装置に送信することを特徴とする請求項１０に記載のアドレス登録システム。

（５）前記第２の手段は、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスを有するインタフェースの接続するネットワークに応じて前記バルク登録を許可するか否かを決定することを特徴とする請求項１０に記載のアドレス登録システム。

（６）前記第２の手段は、前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、個々の送信元アドレスのバルク登録有効期間を前記移動装置に通知し、
前記第３の手段は、前記移動装置が、前記個々の送信元アドレスのバルク登録有効期間に応じて送信元アドレスを前記個々の送信元アドレス間で変更して前記バルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１０に記載のアドレス登録システム。

（７）前記第２の手段は、前記移動管理装置が前記バルク登録を許可する応答メッセージとして、前記複数の個別登録メッセージの各送信元アドレスの登録を一括して確認するバルク登録確認メッセージを、前記移動装置の複数のインタフェースのいずれかあてに送信することを特徴とする請求項１０、上記の（１）から（６）までのいずれか１つに記載のアドレス登録システム。

（８）前記第２の手段は、前記移動管理装置が前記バルク登録を許可する応答メッセージにより、前記バルク登録メッセージを送信するインタフェースを前記移動装置に指示することを特徴とする請求項１０、上記の（１）、（２）、（４）（５）及び（７）のいずれか１つに記載のアドレス登録システム。

（９）前記個別登録メッセージを受信した場合に、その送信元アドレスがネットワークのイングレス・フィルタリングにより検証されたものとみなして登録するとともに、その送信元アドレスあてに前記バルク登録を許可する応答メッセージを送信することを特徴とする請求項１７に記載の移動管理装置。

（１０）前記応答メッセージによりバルク登録有効期間を前記移動装置に通知することを特徴とする請求項１７又は上記の（９）に記載の移動管理装置。

（１１）前記応答メッセージにより、前記移動装置が前記バルク登録メッセージを送信する代理ノードを前記移動装置に通知することを特徴とする請求項１７又は上記の（９）に記載の移動管理装置。

（１２）前記個別登録メッセージを受信した場合に、その送信元アドレスを有するインタフェースの接続するネットワークに応じて前記バルク登録を許可するか否かを決定することを特徴とする請求項１７に記載の移動管理装置。

（１３）前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、個々の送信元アドレスのバルク登録有効期間を前記移動装置に通知することを特徴とする請求項１７に記載の移動管理装置。

（１４）前記バルク登録を許可する応答メッセージとして、前記複数の個別登録メッセージの各送信元アドレスの登録を一括して確認するバルク登録確認メッセージを、前記移動装置の複数のインタフェースのいずれかあてに送信することを特徴とする請求項１７、及び上記の（９）から（１３）のいずれか１つに記載の移動管理装置。

（１５）前記バルク登録を許可する応答メッセージにより、前記バルク登録メッセージを送信するインタフェースを前記移動装置に指示することを特徴とする請求項１７、及び上記の（９）から（１４）のいずれか１つに記載の移動管理装置。

本発明は、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができるという効果を有し、３ＧＰＰ−ＬＴＥ（Third Generation Partnership Project Long Term Evolution）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）などに利用することができる。

本発明は、移動装置の複数のインタフェースの各アドレスを、移動装置の移動を管理する移動管理装置に登録するアドレス登録方法及びアドレス登録システムに関する。
また本発明は、上記のアドレス登録システムにおける移動装置及び移動管理装置に関する。

下記の非特許文献１におけるモバイルＩＰｖ６（ＭＩＰｖ６）によれば、モバイルノードは、インターネットに対する接続点（point-of-attachment）を変更しても、１つのＩＰアドレスを永久的に維持することができる。ＭＩＰｖ６におけるこの永久的なＩＰアドレスとは、モバイルノードのホームネットワーク・ドメイン内のアドレスであって、ホームアドレスとして知られている。また、モバイルノードは、外部ネットワーク・ドメインに接続（attach）すると、その外部ネットワーク・ドメインで使用するＩＰアドレスを、その外部ネットワーク・ドメインにより広告されるサブネット・プリフィックスからも構成することができる。このように構成されたＩＰアドレスは気付アドレス（Care-of Address）と呼ばれ、気付アドレスをモバイルノードのあて先とすることもできる。

モバイルノードがその位置に関係なく到達性（reachability）を維持するためには、モバイルノードは、自身の移動管理装置であるホームエージェントにおいて現在の気付アドレスをホームアドレスにバインドする。ＭＩＰｖ６では、ホームエージェントとは、モバイルノードのホームネットワーク・ドメイン内においてモバイルノードの気付アドレスを登録するルータである。この登録は、モバイルノードがバインディング・アップデート（ＢＵ）メッセージをホームエージェントに送信することにより実現される。モバイルノードがホームネットワーク・ドメインからアウェイに位置する間は、ホームエージェントは、モバイルノードのホームアドレスあてのパケットをインタセプトして、モバイルノードの気付アドレスあてにトンネル化する。ＭＩＰｖ６では、ホストがモビリティ管理に含まれるので、ＭＩＰｖ６は、ホストベースのモビリティ管理プロトコルとも呼ばれている。

ところで、複数のネットワーク・インタフェースが集積された携帯型の電子周辺機器が導入されると、モバイルノード及びルータは、複数の気付アドレスを１つのホームアドレスに登録することができる（例えば下記の非特許文献２）。非特許文献２に記載されている方法では、１つのホームアドレスに対する複数のバインディングを区別するために、バインディング・ユニーク識別子（ＢＩＤ）番号と呼ばれる識別子番号が使用される。このＢＩＤは、インタフェース又は、モバイルノード及びルータの１つのホームアドレスにバインドされる気付けアドレスに割り当てられる。このため、ホームアドレスがモバイルノード及びルータに関連付けられるのに対し、ＢＩＤは、モバイルノードにより同時に登録される複数のバインディングの各々を識別する。モバイルノード及びルータは、ＢＵメッセージを用いてＢＩＤをホームエージェントに通知し、ホームエージェントは、このＢＩＤをバインディング・キャッシュに記録する。

図１は、ホストベースのモビリティ管理が使用されるシステムの想定例を示す。図１において、２つのインタフェース（ＩＦ）１０００、１００１を有するＭＮ１００は、元々はホームネットワーク・ドメイン１０に位置していて、ホームアドレス（ＨｏＡ）を用いて通信相手（ＣＮ：Correspondent Node）３００と通信を行っていたものとする。ＭＮ１００はホームネットワーク・ドメイン１０外に移動して、グローバル通信ドメイン１２を跨がって外部ネットワーク・ドメイン１１をローミングするときにＭＩＰｖ６を使用して、ＣＮ３００と継続して通信を行うものとする。このために、ＭＮ１００は、外部ネットワーク・ドメイン１１をローミングするときに、ホームネットワーク・ドメイン１０内のＨＡ１０１に対し、現在の気付アドレス（ＣｏＡ）をＨｏＡにバインドする。

ＭＮ１００は、３Ｇセルラ・ネットワーク１１０と通信可能なインタフェース（ＩＦ）１０００と、ワイヤレス・ローカルエリアネットワーク（ＷＬＡＮ）１１１と通信可能なＩＦ１００１を有し、外部ネットワーク・ドメイン１１においてＩＦ１０００、１００１を同時に接続するものとする。ＭＮ１００は、非特許文献２を採用して、ＩＦ１０００について構成したＩＰアドレス（ＣｏＡ１とする）と、ＩＦ１００１について構成したＩＰアドレス（ＣｏＡ２とする）をＨＡ１０１においてＨｏＡにバインドする。

通常では、ＭＮ１００は、各ＩＰアドレスＣｏＡ１、ＣｏＡ２をそれぞれバインドする個々のＢＵメッセージ（以下では、個別登録ＢＵメッセージ）をＨＡ１０１に送信するが、ＭＮ１００とＨＡ１０１の間のシグナリングを最適化する方法として、非特許文献２では、複数の個別登録ＢＵメッセージを１つのＢＵメッセージ（以下では、バルク登録ＢＵメッセージ）に集合することが提案されている。この技術は、バルク登録として知られ、ＭＮ１００とＨＡ１０１の間のシグナリング・メッセージ数を減少するという利点を有する。シグナリング・メッセージの数が減少するということは、メッセージのパケットのオーバヘッドが非常に減少することを黙示している。例えばＭＮ１００が２つの個別登録ＢＵメッセージの代わりに１つのバルク登録ＢＵメッセージを送信すると、パケットのオーバヘッドを４５％セーブすることができる場合がある。パケットのオーバヘッドのセーブについては下記の非特許文献３に詳しく説明されている。

さらに、このシステムが３ＧＰＰオペレータにより設けられている場合、ネットワークを悪意のある行動から保護するために、何らかのセキュリティ対策が設けられる。考えられるセキュリティ対策としては、下記の非特許文献４に記載されているようなイングレス・フィルタリングがある。ネットワーク側はイングレス・フィルタリングにより、意図する送信元から特定のパケットが来たことを知得することができる。各ネットワークのゲートウェイ・ルータは、パケットの送信元ＩＰアドレスをチェックして、特定のルータが取り扱うＩＰアドレスのリストとマッチングすることを確保することができる。ゲートウェイ・ルータは、パケットの送信元ＩＰアドレスが上記のＩＰアドレスのリスト内に存在しない場合には、そのパケットに悪意があると疑って破棄する。したがって、外部ネットワーク・ドメイン１１内のゲートウェイ・ルータがイングレス・フィルタリングによりパケットの送信元ＩＰアドレスをチェックするので、ＨＡ１０１は、ＭＮ１００が外部ネットワーク・ドメイン１１において送信されるパケットが真であると確信することができる。

しかしながら、バルク登録ＢＵメッセージの送信元アドレスには、複数の気付アドレス（ＣｏＡ）のうちの１つのみが記述され、残りの気付アドレスは、暗号化されたバルク登録ＢＵメッセージ内に伝送されるので、ゲートウェイ・ルータは、上記の残りの気付アドレスが偽か否かをチェックすることができない。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００がバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信する場合、バルク登録ＢＵメッセージの送信元アドレスは気付アドレス3G.Addrであるので、ＨＡ１０１にとっては、気付アドレス3G.Addrは、外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより検証（verify）される。

他方、バルク登録ＢＵメッセージ内の気付アドレスWLAN.Addrは、ＨＡ１０１に登録するためにオプションで伝送される。このため、外部ネットワーク・ドメイン１１によるイングレス・フィルタリングでは、ＨＡ１０１は、気付アドレスWLAN.Addrが外部ネットワーク・ドメイン１１内で使用されるＩＰアドレスであることを確信できないので、ＨＡ１０１は、ＭＮ１００との間で確立した信頼関係に頼るしかなく、ＭＮ１００が気付アドレスWLAN.Addrを使用しているものと仮定するしかない。ところで、ＭＮ１００に悪意があり、ＭＮ１００がＨＡ１０１との信頼関係を乱用して、あるＩＰアドレスをバルク登録ＢＵメッセージ内に記述した場合を考える。もし、このＩＰアドレスが他のモバイルノードにより使用されている場合、ＭＮ１００はＨＡ１０１に対し、他のモバイルノードのＩＰアドレスにパケットを転送するよう指示できることになる。この意味は、ＭＮ１００が犠牲となるモバイルノードに対し、ＨＡ１０１に無意味なパケットを洪水のごとく転送させてリ・ダイレクション攻撃できるということであり、このため、犠牲となるモバイルノードの本来のパケット送受信を輻輳させることができるということである。

このため、３ＧＰＰオペレータは、バルク登録による悪意のある攻撃を防止するために、別のセキュリティ対策を採用するかもしれない。また、ＨＡ１０１にとって簡単かつ明白な方法は、バルク登録ＢＵメッセージ内に記述されている各アドレス（送信元アドレスを除く）を検証することである。この場合、ＨＡ１０１は、バルク登録ＢＵメッセージ内に記述されている各アドレスあてに暗号化メッセージを送信して、ＭＮ１００に復号化メッセージを送り返すよう依頼することができる。ＨＡ１０１がＭＮ１００から送り返された復号化メッセージを受信できるということは、ＨＡ１０１にとって、ＭＮ１００がバルク登録ＢＵメッセージ内に記述されている各アドレスを使用しているものと検証できる。この方法の詳細は、下記の非特許文献５、特許文献１、特許文献２、特許文献３に示されている。

同様に、ＭＮ１００が複数のインタフェースを有する場合には、ＨＡ１０１が１つのインタフェース経由で暗号化メッセージを送信して、ＭＮ１００に別のインタフェース経由で復号化メッセージを送り返すよう依頼することにより、検証プロセスを最適化できる。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００が気付アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録するためのバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信したものとする。この場合、ＨＡ１０１は、気付アドレスWLAN.Addrを検証するために、ＩＦ１０００に暗号化メッセージを送信して、ＭＮ１００にＩＦ１００１経由で復号化メッセージを送り返すよう依頼する。このように、ネットワークにより既に検証（＝外部ネットワーク・ドメイン１１によりイングレス・フィルタリング）されているアドレス（3G.Addr）あてに暗号化メッセージを送信する利点は、未だ検証されていないアドレス（WLAN.Addr）あてにＨＡ１０１がパケットを送信してリ・ダイレクション(redirection)攻撃を意図的に開始しないようにすることにある。この方法の詳細は、下記の特許文献４に示されている。

以上説明した従来技術では、ＨＡ１０１が、送信元アドレス以外のＩＰアドレスを検証するためにＭＮ１００とメッセージ交換を行うので、ＭＮ１００が実際のパケット・ルーティング目的で、送信元アドレス以外のＩＰアドレスを使用する時点が遅れるという問題がある。例えばＩＦ１０００が気付アドレス3G.Addrを使用し、ＩＦ１００１が気付アドレスWLAN.Addrを使用して通信を行うものとして、ＭＮ１００が気付アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録するためのバルク登録ＢＵメッセージをＩＦ１０００からＨＡ１０１に送信し、ＨＡ１０１は、気付アドレスWLAN.Addrを検証するために、ＩＦ１０００に暗号化メッセージを送信したものとすると、この場合には、ＨＡ１０１は、ＭＮ１００からの復号化メッセージを受信するまでは、パケットをＭＮ１００に転送するために気付アドレスWLAN.Addrを使用すべきでない。これにより、ＨＡ１０１がリ・ダイレクション攻撃を意図的でなく仕掛けないことを保証することができる。しかしながら、以上説明した方法では、ＨＡ１０１がパケットをＭＮ１００に転送するために気付アドレスWLAN.Addrを使用するためには、ＨＡ１０１は、３つのメッセージ交換の時間を必要とする。

上記の遅延の問題を解決する明白な方法として、ＨＡ１０１との間に信頼関係が確立されているプロキシ・エンティティがＭＮ１００のＩＰアドレスをＨＡ１０１に登録する方法がある。例えばホームネットワーク・ドメイン１０の３ＧＰＰオペレータが外部ネットワーク・ドメイン１１の３ＧＰＰオペレータと何らかのサービス契約を締結しているかもしれない。このサービス契約では、ＨＡ１０１と、外部ネットワーク・ドメイン１１のプロキシ・エンティティ（例えばＡＡＡ（Authentication, Authorization and Accounting）サーバ）の間に相互の信頼関係が確立される。ＨＡ１０１は、このような相互の信頼関係を確立しておくことにより、プロキシ・エンティティがＭＮ１００のために登録するＩＰアドレスを信頼する。この方法の詳細は、下記の特許文献５、特許文献６に示されている。また、特許文献７には、プロキシ・エンティティが、ＨＡ１０１あての登録メッセージ内に記述されているＭＮ１００のＩＰアドレスが真であることを登録メッセージのパケットヘッダ内に記述することが記載されている。

しかしながら、以上説明した従来技術では、パケット転送を目的とするＩＰアドレス使用の遅延を減少するために、ＩＰアドレスを検証する第３のエンティティをシステム内に導入している。さらに、従来技術の方法を用いる前に、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１の間で何らかの信頼関係を確立しなければならない。しかしながら、すべての３ＧＰＰオペレータがお互いにこのような信頼関係を確立して維持することは困難である。

上記の遅延の問題を解決する明白な他の方法として、ＭＮ１００が暗号化を用いて、ＨＡ１０１に登録するＩＰアドレスを生成する方法がある。この方法の詳細は、下記の非特許文献６に示されている。しかしながら、暗号化して生成したＩＰアドレスでは、ＭＮ１００は、自身が保持していないＩＰアドレスをバインドすることができない。また、暗号化して生成したＩＰアドレスを使用する場合には、ＭＮ１００は、ＩＰアドレスを得るために複雑なハッシュ関数を動作させる必要があるので、構成がより複雑になり、より高い処理能力を必要とする。加えて、ＭＮ１００は、ＩＰアドレスを生成するのに使用したパラメータをＨＡ１０１あてのＢＵメッセージ内に含ませる必要がある。なお、このパラメータは、ＩＰアドレスが真であることを検証する際にＨＡ１０１により使用される。また、ＩＰアドレスを生成するのに使用したパラメータをバルク登録ＢＵメッセージ内に付加すると、メッセージサイズが非常に増大する。例えば下記の非特許文献７には、各パラメータ・オプションが２５５バイトまでに限定され、１つのメッセージが複数のパラメータ・オプションを含むであろうことが記載されている。

P. Danny, T. Daniel C., and B. Richard, "Link discovery and verification procedure using loopback", US Patent No. 6,834,139 B1, December 21, 2004. S. John A., "Methods and apparatus for determining, verifying, and rediscovering network IP addresses", US Patent No. 6,195,706 B1, February 27, 2001. C. Josep, D. Scott N. and V. Theodore B., "Apparatus, system, and method for automatically verifying access to a mulitipathed target at boot time", US Patent Application Publication No. 2007/0143583 A1, June 21, 2007. J. Hirano, B. Lim, C-W. Ng, B. Koh and P-Y. Tan, "Method and apparatus for address verification during multiple address registration", WO Patent Application Publication No. 2008/023845 A1, February 28, 2008. K. Leung and G. Dommety, "Methods and apparatus for providing mobility of a node that does not support mobility", US Patent No. 6,466,964 B1, October 15, 2002. H. Guan, J. Wang and Y. Huang, "Method and System for Authorizing and Charging Host with Multiple Addresses in IPv6 Network", US Patent Application Publication No.2007/0169180 A1, July 19, 2007. P-A. Son, "System and method for carrying trusted network provided access network information in session initiation protocol", US Patent Application Publication No. 2008/0039085 A1, February 14, 2008.

D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. M. Kuparinen, H. Mahkonen and T. Kauppinen, "Multiple CoA Performance Analysis", draft-kuparinen-monami6-mcoa-performance-00.txt, April 20, 2006. F. Baker and P. Savola, "Ingress Filtering for Multihomed Networks", Internet Engineering Task Force Request For Comments 3704, March 2004. F. Dupont, and J-M. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-00.txt, January 10, 2005. T. Aura, "Cryptographically Generated Addresses (CGA)", Internet Engineering Task Force Request For Comments 3972, March, 2005. J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", Internet Engineering Task Force Request For Comments 4866, May, 2007.

以上説明したように、モバイルノードの複数のインタフェースに関連付けられた各アドレスを、モバイルノードの移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信に遅延が発生するという問題点がある。

本発明は上記の問題点に鑑み、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができるアドレス登録方法、アドレス登録システム、移動装置及び移動管理装置を提供することを目的とする。

本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録方法であって、
前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１のステップと、
前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２のステップと、
前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３のステップとを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムであって、
前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１の手段と、
前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２の手段と、
前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３の手段とを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動装置であって、
前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する手段と、
前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動管理装置から受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する手段とを、
有する構成とした。

また本発明は上記目的を達成するために、移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動管理装置であって、
前記移動装置から、前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する手段と、
前記応答メッセージを送信した後に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動装置から受信した場合に、前記複数のアドレスを一括して更新する手段とを、
有する構成とした。

この構成により、移動装置の複数のインタフェースに割り当てられた複数のアドレスを最初に移動管理装置に登録する場合には、個別登録メッセージを使用して各アドレスをネットワークのイングレス・フィルタリングなどにより認証し、この登録後には複数のアドレスを一括して更新する場合にバルク登録メッセージを使用するので、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができる。

本発明によれば、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができる。

本発明のアドレス登録方法が適用されるシステムの想定例を示すブロック図 本発明の第１の実施の形態におけるモバイルノードの構成を機能的に示すブロック図 本発明の第１の実施の形態におけるホームエージェントの構成を機能的に示すブロック図 本発明の第１の実施の形態における通信シーケンスを示す説明図 本発明の第１の実施の形態の通知メッセージのフォーマットを示す説明図 本発明の第１の実施の形態におけるモバイルノードがバルク登録の可否を判断する処理を説明するためのフローチャート 本発明の第１の実施の形態におけるホームエージェントがバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャート 本発明の第２の実施の形態の通信シーケンスを示す説明図 本発明の第２の実施の形態における個別登録ＢＵメッセージのフォーマット を示す説明図 本発明の第２の実施の形態におけるモバイルノードがバルク登録の可否を判断する処理を示すフローチャート 本発明の第２の実施の形態におけるホームエージェントがバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャート 本発明の第３の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態におけるバルク登録ＢＵメッセージのフォーマットを示す説明図 本発明の第３の実施の形態におけるプロキシがバルク登録ＢＵメッセージ内のＩＰアドレス検証を援助する処理を示すフローチャート 本発明の第６の実施の形態におけるバルク登録ＢＡメッセージのフォーマットを示す説明図 本発明の第６の実施の形態におけるモバイルノードがバルク登録ＢＡメッセージを受信した場合の処理を示すフローチャート 本発明の第８の実施の形態におけるシステムの想定例を示すブロック図 本発明の第８の実施の形態におけるメッセージシーケンスを示す説明図 本発明の第８の実施の形態における個別登録ＢＡメッセージのフォーマットを示す説明図 本発明の第８の実施の形態における個別登録ＢＵメッセージのフォーマットを示す説明図

以下、図面を参照して本発明の実施の形態について説明する。以下に記載されている特定の数字、時間、構造、プロトコル名及び他のパラメータは、本発明を理解するための説明であって、当業者であれば、本発明は、これらに限定されることなく実現可能なことは明らかである。また、ブロック図に示されている名称は、本発明を不必要に不明瞭にしないように用いられている。

図１は、本発明のアドレス登録方法が使用されるシステムの想定例を示す。図１におけるシステムの概略的な構成は、「背景技術」において説明したので、ここでは詳細な説明を省略する。なお、このシステムは、３ＧＰＰ−ＬＴＥ（Third Generation Partnership Project Long Term Evolution）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）と関連付けることができる。このシステムとＳＡＥの関係について説明すると、ホームエージェント（ＨＡ）１０１は、ＳＡＥのパケットデータ・ネットワーク・ゲートウェイ（ＰＤＮ−ＧＷ：Packet Data Network Gateway）と関連付けることができ、同様に、モバイルノード（ＭＮ）１００は、ＳＡＥのユーザ機器（ＵＥ：User Equipment）と関連付けることができる。なお、ネットワーク１１１はＮｏｎ−３ＧＰＰネットワークであり、ＷＬＡＮに限らず、ＷｉＭＡＸなどの他のアクセスネットワークであってもよい。

本発明では、２つのインタフェース（ＩＦ）１０００（３ＧＰＰインタフェース）、１００１（Ｎｏｎ−３ＧＰＰインタフェース）を有するＭＮ１００は、外部ネットワーク・ドメイン１１においてＩＦ１０００、１００１に割り当てられたＩＰアドレス（気付アドレス：ＣｏＡ）をＨＡ１０１に登録してさらに更新するために、最初は、ＭＮ１００は、ＩＦ１０００、１００１のそれぞれを送信元アドレスとして、送信元アドレスを個別に登録するための複数の個別登録ＢＵメッセージをＨＡ１０１に送信する。ＨＡ１０１は、複数の個別登録メッセージを受信した場合に、その送信元アドレスが外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより検証されたものとみなして登録するとともに、ＭＮ１００による今後のＢＵメッセージの送信を効率化するために、どのようにＢＵメッセージを送信するべきかを示す情報を含む応答メッセージ（ＢＡメッセージ）をＭＮ１００に送信する。その情報には、バルク登録ＢＵメッセージの送信方法を指示する情報（バルクパターン情報）が含まれており、ＭＮ１００はその情報に従って、以降のＢＵメッセージを送信する。

＜ＭＮの構成＞
図２はＭＮ１００の構成を機能的に示すブロック図である。なお、図２に示す構成は、ＭＮ１００以外のノード、例えばモバイル・ルータなどにも適用することができる。ＭＮ１００は、ネットワーク・インタフェース・モジュール２１と、モビリティ・バインディング・エンジン２２と、データベース・モジュール２３と、バルク登録可否判断エンジン２４を有する。ネットワーク・インタフェース・モジュール２１は、通信メディアを介して他のノードと通信するために必要なプログラム及びソフトウエアを実行する機能ブロックである。関連する技術分野において用いられている用語を使用すれば、ネットワーク・インタフェース・モジュール２１は、レイヤ１（物理層）とレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ及び通信プロトコルを表す。当業者であれば、ネットワーク・インタフェース・モジュール２１は１以上設けられることは明らかである（例えば図１のＩＦ１０００、１００１）。

ネットワーク・インタフェース・モジュール２１とモビリティ・バインディング・エンジン２２は、シグナル／データパスＳ２１を介してトリガ信号及びパケットを相互に伝送することができる。例えばネットワーク・インタフェース・モジュール２１は、他のノードから受信したモビリティ・シグナリング・メッセージ（例えばＨＡ１０１から受信したＢＡメッセージ）をモビリティ・バインディング・エンジン２２に転送して処理させる。同様に、モビリティ・バインディング・エンジン２２は、モビリティ・シグナリング・メッセージ（例えばＢＵメッセージ）をネットワーク・インタフェース・モジュール２１に転送して他のノード（例えばＨＡ１０１）に送信させる。

モビリティ・バインディング・エンジン２２はＭＮ１００のモビリティを管理する。関連する技術分野において用いられている用語を使用すれば、モビリティ・バインディング・エンジン２２はレイヤ３（ネットワーク層）プロトコル、例えばＭＩＰｖ４又はＭＩＰｖ６（Mobile Internet Protocol version 4 or 6）の機能を表す。モビリティ・バインディング・エンジン２２とデータベース・モジュール２３は、シグナル／データパスＳ２２を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２２はモビリティ管理機能を実行するために、データベース・モジュール２３内の情報（例えば気付アドレス）をアップデートしたり、データベース・モジュール２３から情報を引き出したりする。

同様に、モビリティ・バインディング・エンジン２２とバルク登録可否判断エンジン２４は、シグナル／データパスＳ２３を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２２は、ＨＡ１０１に登録されているＭＮ１００のアドレスのバインディングをリフレッシュする前にバルク登録可否判断エンジン２４をトリガして、どのアドレスがバルク登録に使用可能かを識別することができる。

データベース・モジュール２３は、ＭＮ１００に必要な情報を蓄積し、この望ましい実施の形態ではバインディング・アップデートリスト２３０と、バルク登録有効期間２３１と、アドレス検証情報２３２を蓄積している。バインディング・アップデートリスト２３０は、あて先ノード（例えばＨＡ１０１、ＣＮ３００）に登録しているＭＮ１００の現在の気付アドレスに関する１以上のエントリを含む。加えて、第１の実施の形態では、バルク登録に使用する１又は複数の気付アドレスに対してバルク登録有効期間２３１を導入している。アドレス検証情報２３２は、バルク登録可否判断エンジン２４が判断を実行するのに関連するデータ（例えばバルク登録に使用される１又は複数の気付アドレス、公開鍵及び秘密鍵）を含む。

本発明では、バルク登録可否判断エンジン２４を導入して、特定の気付アドレスがバルク登録に使用可能か否か（ＨＡ１０１によりバルク登録が許可されているか否か）を判断している。例えばバルク登録可否判断エンジン２４の目的は、データベース・モジュール２３内のバルク登録有効期間２３１を使用して、特定の気付アドレスがバルク登録可能か否かを判断することにある。

＜ＨＡの構成＞
図３はＨＡ１０１の構成を機能的に示すブロック図である。なお、図３に示す構成は、ＨＡ１０１以外のノード、例えばＣＮ３００などにも適用することができる。ＨＡ１０１は、ネットワーク・インタフェース・モジュール２５と、モビリティ・バインディング・エンジン２６と、データベース・モジュール２７と、バルク登録検証エンジン２８を有する。ネットワーク・インタフェース・モジュール２５は、図２と同様に、通信メディアを介して他のノードと通信するために必要なプログラム及びソフトウエアを実行する機能ブロックであるので、詳細な説明を省略する。当業者であれば、ネットワーク・インタフェース・モジュール２５は１以上設けられることは明らかである。

また、図２と同様に、ネットワーク・インタフェース・モジュール２５とモビリティ・バインディング・エンジン２６は、シグナル／データパスＳ２５を介してトリガ信号及びパケットを相互に伝送することができる。ネットワーク・インタフェース・モジュール２５は、他のノードから受信したモビリティ・シグナリング・メッセージとして、例えばＭＮ１００から受信したＢＵメッセージ（個別登録ＢＵメッセージ、バルク登録ＢＵメッセージ）をモビリティ・バインディング・エンジン２６に転送して処理させる。同様に、モビリティ・バインディング・エンジン２６は、モビリティ・シグナリング・メッセージをネットワーク・インタフェース・モジュール２１に転送して他のノードに送信させ、例えばＢＡメッセージ（個別登録ＢＡメッセージ、バルク登録ＢＡメッセージ）をＭＮ１００に送信させる。

モビリティ・バインディング・エンジン２６はＨＡ１０１のモビリティを管理する。図２と同様に、関連する技術分野において用いられている用語を使用すれば、モビリティ・バインディング・エンジン２６はレイヤ３（ネットワーク層）プロトコル、例えばＭＩＰｖ４又はＭＩＰｖ６（Mobile Internet Protocol version 4 or 6）の機能を表す。モビリティ・バインディング・エンジン２６とデータベース・モジュール２７は、シグナル／データパスＳ２６を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２６はモビリティ管理機能を実行するために、データベース・モジュール２７内の情報（例えば気付アドレス）をアップデートしたり、データベース・モジュール２７から情報を引き出したりする。

同様に、モビリティ・バインディング・エンジン２６とバルク登録検証エンジン２８は、シグナル／データパスＳ２７を介してトリガ信号及びパケットを相互に伝送することができる。例えばモビリティ・バインディング・エンジン２７は、ＨＡ１０１に登録されているＭＮ１００のアドレスのバインディングをリフレッシュする前にバルク登録検証エンジン２８をトリガして、どのアドレスがバルク登録に使用可能か（バルク登録を許可しているか）を識別することができる。

データベース・モジュール２７は、ＨＡ１０１に必要な情報を蓄積し、この望ましい実施の形態ではバインディング・キャッシュ２７０と、バルク登録有効期間２７１と、アドレス検証情報２７２を蓄積している。バインディング・キャッシュ２７０は、あて先ノード（例えばＭＮ１００）の現在の気付アドレスに関する１以上のエントリを含む。加えて、第１の実施の形態では、ＭＮ１００がバルク登録に使用する１又は複数の気付アドレスに対してバルク登録有効期間２７１を導入している。アドレス検証情報２７２は、バルク登録検証エンジン２８が実行するのに関連するデータ（例えばバルク登録に使用される１又は複数の気付アドレス、公開鍵及び秘密鍵）を含む。本発明では、バルク登録検証エンジン２８を導入している。バルク登録検証エンジン２８の目的は、バルク登録ＢＵメッセージ内の気付アドレスがバルク登録可能か否かを検証することにある。この検証については、後述する他の実施の形態では、ＨＡ１０１が検証するのをプロキシが援助する。

＜第１の実施の形態：ＨＡがＭＮにバルク登録可否を通知＞
図４は第１の実施の形態の通信シーケンスを示す。ここで、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用している。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外の外部ネットワーク・ドメイン１１内をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。

このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ３０をＨＡ１０１に送信する。同様に、ＭＮ１００は、アドレスWLAN.AddrをＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ３１（図では単に、個別ＢＵ）をＨＡ１０１に送信する。ＨＡ１０１では、外部ネットワーク・ドメイン１１のイングレス・フィルタリングにより、アドレス3G.Addrが、そのアドレスが割り当てられている送信元から来たと検証することが保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrが登録されたことを個別に通知（図では、ＢＮＤ−ＯＫ）するためのバインディング確認（個別登録ＢＡ）メッセージＳ３２（図では単に、個別ＢＡ）をＭＮ１００に送り返す。

同様に、アドレスWLAN.Addrに関しても、外部ネットワーク・ドメイン１１によるイングレス・フィルタリングに基づいて、同様の手順で処理が行われる。ここでは、ＨＡ１０１は、ＭＮ１００が複数の気付アドレスを登録していることを検出して、バインディング確認（ＢＮＤ−ＯＫ）の通知と共に、アドレスWLAN.Addrがバルク登録可能であること（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に送り返す。個別登録ＢＡメッセージＳ３３ではまた、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間をＭＮ１００に通知する。

ＭＮ１００は、次のＢＵメッセージをＨＡ１０１に送信しようとするときには、アドレスWLAN.Addrのバルク登録有効期間が未だ満了していないか否かをチェックする。バルク登録有効期間が未だ満了していない場合には、ＭＮ１００は、アドレス3G.Addr、WLAN.Addrをバルク登録でＨＡ１０１に登録するためにバルク登録ＢＵメッセージＳ３４ａ（図では単に、バルクＢＵ）を継続して使用してＨＡ１０１に送信する。ＨＡ１０１はバルク登録ＢＵメッセージＳ３４に対する応答として、２つの個別登録ＢＡメッセージＳ３４ｂ（3G.Addr宛の個別登録ＢＡメッセージとWLAN.Addr宛の個別登録ＢＡメッセージ）又は１つのバルク登録ＢＡメッセージＳ３４ｃを送り返す。

ＭＮ１００は、バルク登録有効期間が満了した場合には（図のＳ３５）、個別登録ＢＵメッセージＳ３６、Ｓ３７をＨＡ１０１に送信して、それぞれアドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録する。個別登録ＢＵメッセージＳ３６、Ｓ３７により、ＨＡ１０１は再びイングレス・フィルタリングにより送信元アドレスが検証されたとして、ＭＮ１００が登録しようとしている気付アドレス3G.Addr、WLAN.Addrが真であると検証することができる。

ＭＮ１００は、アドレス3G.Addr、WLAN.Addrが変更された場合には、そのアドレスはバルク登録ＢＵメッセージ内には含ませない。その理由は、新しいＩＰアドレスは、ＨＡ１０１によりイングレス・フィルタリングを使用して検証されていないからである。もしＭＮ１００が新しいＩＰアドレスを登録するためにバルク登録を使用した場合、ＨＡ１０１は、新しいＩＰアドレスを使用する前に、何らかのアドレス検証メカニズムをトリガして新しいＩＰアドレスを検証する。なお、アドレスの検証をした後に、そのアドレスがバルク登録可能であること（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に返してもよい。例えばＭＮ１００がＷＬＡＮインタフェース１００１の新しいＩＰアドレスとしてアドレスWLAN.Addr2を構成した場合、アドレスWLAN.Addr2がＨＡ１０１により未だ検証されていないので、ＭＮ１００は、個別登録ＢＵメッセージを使用してアドレスWLAN.Addr2をＨＡ１０１に登録する。この手法により、ＨＡ１０１はイングレス・フィルタリングを使用して、ＭＮ１００が本当にアドレスWLAN.Addr2を使用していることを検証できる。他方、ＭＮ１００が個別登録ＢＵメッセージをＨＡ１０１に送信する前に、バルク登録を使用してアドレスWLAN.Addr2をＨＡ１０１に登録しようとした場合、ＨＡ１０１は、アドレスWLAN.Addr2がバインディング・キャッシュ２７０に存在しないことを検知して、アドレスWLAN.Addr2がバルク登録不可であることを知得し、アドレス検証を実行する。

なお、ＨＡ１０１は、バルク登録が不可であるアドレスに対してアドレス検証処理を実行する代わりに、ＭＮ１００に対してバルク登録が拒否されたことのみを通知するＢＡメッセージを送信してもよい。これにより、個別登録ＢＵメッセージでの再送をするか否かをＭＮ１００の判断に委ねることができる。ＭＮ１００は、バルク登録ではなく個別登録ＢＵメッセージを送信するべきであることを認識し、自ら個別登録ＢＵメッセージで再送を開始することができるため、検証処理の実行に伴う負荷をＨＡ１０１から取り除くことができる。

また、ＨＡ１０１は、バルク登録ＢＵメッセージに含まれるアドレスが、バインディング・キャッシュ２７０に全く存在しないアドレスである場合に、前述のバルク登録が拒否されたことを通知するＢＡメッセージを送信し、一方、バインディング・キャッシュ２７０に存在するが、バルク登録有効期間が満了している場合にアドレスの検証処理を実行するようにしてもよい。これにより、ＨＡ１０１によるアドレス検証を特定の場合に限定することができるため、アドレス検証に伴う負荷を軽減することができる。例えば、個別ＢＵメッセージの再送に伴うＭＮ１００の負荷の方が、アドレス検証処理に伴うＨＡ１０１の負荷よりも大きい場合には、ＭＮ１００は自身の負荷を軽減するために、最初からバルク登録ＢＵメッセージで送信することを選択するかもしれない。これに伴うＨＡ１０１の負荷が増大することは、ネットワークオペレータにとって望ましいものではない。そのため、上記のようにＨＡ１０１がアドレス検証を実行する機会をできるだけ制限することで、このようなＭＮ１００の行為を防ぐことができる。

＜通知メッセージのフォーマット＞
図５は望ましい第１の実施の形態の通知メッセージのフォーマットを示す。この通知メッセージは、パケットヘッダ４０とモビリティ・オプション４１を有する。パケットヘッダ４０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション４１は、ステータス・オプション４１０と通知オプション４１１を有する。ステータス・オプション４１０は、このメッセージが個別登録ＢＡメッセージＳ３２、Ｓ３３の場合、個別登録ＢＵメッセージＳ３０、Ｓ３１により要求された気付アドレスの登録が完了したか否か（ＢＮＤ−ＯＫ／ＮＯ）を示す。また、通知オプション４１１は、このメッセージがアドレスWLAN.Addrの個別登録ＢＡメッセージＳ３３であってバルク登録可（ＢＬＫ−ＯＫ）の場合、バルク登録有効期間を含む。

ステータス・オプション４１０と通知オプション４１１について、図４に示す例を参照して詳しく説明すると、ＭＮ１００がアドレス3G.Addrを個別にＨＡ１０１に登録するために、３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ３０をＨＡ１０１に送信すると、ＨＡ１０１はＭＮ１００に対し、アドレス3G.Addrの登録が完了したこと（ＢＮＤ−ＯＫ）を示すステータス・オプション４１０を含む個別登録ＢＡメッセージＳ３２を送り返す。さらに、ＭＮ１００がアドレスWLAN.Addrを個別にＨＡ１０１に登録するために、ＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ３１をＨＡ１０１に送信すると、ＨＡ１０１はＭＮ１００に対し、アドレスWLAN.Addrの登録が完了したこと（ＢＮＤ−ＯＫ）を記述したステータス・オプション４１０と、アドレスWLAN.Addrのバルク登録有効期間（例えば７分）を記述した通知オプション４１１を含む個別登録ＢＡメッセージＳ３３を送り返す。このため、次の７分間は、ＭＮ１００は、アドレスWLAN.Addrをリフレッシュするために、３Ｇセルラ・インタフェース１０００からバルク登録ＢＵメッセージＳ３４ａを送信することができる。

＜バルク登録有効期間＞
通知オプション４１１に記述する「バルク登録有効期間」は、外部ネットワーク・ドメイン１１によりＭＮ１００の通信のために割り当てられているＩＰアドレスの存続期間（以下、「アドレス存続期間」）に対応しており、バルク登録有効期間が、アドレス存続期間と同等か、それ以下とすることが望ましい。外部ネットワーク・ドメイン１１に位置する不図示のＤＨＣＰ（Dynamic Host Control Protocol）サーバにより、アドレスWLAN.Addrのアドレス存続期間が割り当てられている場合を例にして説明する。ＤＨＣＰサーバは、アドレスWLAN.AddrをＭＮ１００に割り当てるときに、アドレスWLAN.Addrのアドレス存続期間（例えば７分）を指示する。このアドレス存続期間の間は、ＤＨＣＰサーバは、ＭＮ１００がアドレスWLAN.Addrを使用しなくても、アドレスWLAN.Addrを他のモバイルノードに割り当てない。

このようにＤＨＣＰサーバが動作する理由は、ＭＮ１００が予期しない接続ロスにあうかもしれないからである。ＭＮ１００は、アドレスWLAN.Addrの接続ロスの後に再接続すると、ＣＮ３００との間で継続しているセッションを変更しないためにアドレスWLAN.Addrを要求する。ＭＮ１００がアドレスWLAN.Addrの接続を失った時点から再接続するまでの間に、もしＤＨＣＰサーバがアドレスWLAN.Addrを他のモバイルノードに割り当てると、ＭＮ１００はアドレスWLAN.Addrを再び使用できなくなる。ＭＮ１００がアドレスWLAN.Addrを再び使用できなくなるということは、ＭＮ１００が新しいＩＰアドレスをＣＮ３００に通知する必要があるので、ＭＮ１００とＣＮ３００との間のセッションに対する通信サービスが崩壊することを黙示している。さらに、アドレスWLAN.Addrが他のモバイルノードに割り当てられたことをＣＮ３００が知得していないので、他のモバイルノードは、アドレスWLAN.Addrを使用すると、無用なパケットをＣＮ３００から受信する。この行為は、ＭＮ１００が悪意のあるノードである場合にはリ・ダイレクション攻撃とみなされる。

ＤＨＣＰサーバから割り当て中のアドレス存続期間にバルク登録有効期間が関連付けされていない場合に、悪意のあるＭＮ１００がＤＨＣＰサーバを利用してリ・ダイレクション攻撃を行う方法について説明する。ＭＮ１００がＤＨＣＰサーバから外部ネットワーク・ドメイン１１で使用するアドレスWLAN.Addrを割り当てられた場合、ＭＮ１００は、アドレスWLAN.Addrを使用してＣＮ３００とセッションを開始し、アドレスWLAN.Addrあてのパケット送信を開始して１分間、継続する。次に、ＭＮ１００は、アドレスWLAN.Addrの接続を意図的に失い、ＤＨＣＰサーバを欺いてアドレスWLAN.Addrを他のモバイルノードに割り当てさせる。一旦、他のモバイルノード（すなわち犠牲者）がアドレスWLAN.Addrを取得すると、ＣＮ３００からのパケットは、犠牲となるモバイルノードに到達を開始して無用なパケットを大量に受信させることができる。

このため、この望ましい第１の実施の形態では、ＨＡ１０１からＭＮ１００に対して通知するＩＰアドレスのバルク登録有効期間を、外部ネットワーク・ドメイン１１内のＤＨＣＰサーバから割り当てるアドレス存続期間と同じ、またはそれ以下としている。さらに、バルク登録有効期間がアドレス存続期間よりも短い場合、アドレス存続期間が終了するタイミングと、バルク登録有効期間が終了するタイミングが一致していることが望ましい。これにより、アドレス存続期間が終了した時点で、バルク登録有効期間がまだ有効である期間が生じてしまうことを防ぐことができる。このようにバルク登録有効期間を導入することにより、前述したようなリ・ダイレクション攻撃を防止することができる。変形例として、バルク登録有効期間は、すべてのエンティティが知得している周知の期間でもよい。さらに他の変形例として、バルク登録有効期間は、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１の間で交渉した期間でもよい。

加えて、バルク登録有効期間は、ＭＮ１００がこのＩＰアドレスを既に使用していないときに、ＭＮ１００がこのＩＰアドレスの使用を誤って申し立てる可能性を低減することができる。例えばＭＮ１００がＷＬＡＮインタフェース１００１をシャットダウンしたとき、ＭＮ１００は悪意で、アドレスWLAN.Addrをリフレッシュするために３Ｇセルラ・インタフェース１０００からバルク登録ＢＵメッセージを送信することにより、アドレスWLAN.Addrの使用を申し立てることができる。しかしながら、ＤＨＣＰサーバがアドレスWLAN.Addrを、そのアドレス存続期間が満了するまで割り当てないので、ＭＮ１００は、リ・ダイレクション攻撃を、犠牲となるモバイルノードに仕掛けることができない。また、バルク登録有効期間が満了すると、ＨＡ１０１は、ＭＮ１００がＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージを送信して、ＭＮ１００が未だアドレスWLAN.Addrを使用していることをイングレス・フィルタリングで検証することを必要とする。したがって、バルク登録有効期間を導入することにより、ＭＮ１００が悪意のある行動をとる可能性を低減することができる。

＜ＭＮの処理＞
図６はＭＮ１００がバルク登録の可否を判断する処理を説明するためのフローチャートである。この処理は、ＢＵメッセージをＨＡ１０１に送信する必要がある場合に、バルク登録可否判断エンジン２４がモビリティ・バインディング・エンジン２２からトリガ信号を受信したときにスタートし（ステップＳ５０のＢＵ受信トリガ）、データベース・モジュール２３から関連情報（例えばバインディング・アップデートリスト２３０のエントリとバルク登録有効期間２３１）を引き出す（ステップＳ５１）。次いで、バルク登録有効期間２３１に基づいてそのＩＰアドレスのバルク登録有効期間が満了しているか否かをチェックする（ステップＳ５２）。そして、バルク登録有効期間が満了している場合にはステップＳ５３に進んでバインディング・アップデートリスト２３０におけるそのＩＰアドレスに対して「バルク登録不可」をマークしてステップＳ５５に進む。他方、バルク登録有効期間が満了していない場合にはステップＳ５４に進んでバインディング・アップデートリスト２３０におけるそのＩＰアドレスに対して「バルク登録可」をマークしてステップＳ５５に進む。ステップＳ５５では、バインディング・アップデートリストにおけるすべてのエントリをチェックした場合に、その結果（バルク登録不可／バルク登録可）をリスト化してモビリティ・バインディング・エンジン２２に転送する。モビリティ・バインディング・エンジン２２はこのリストに基づいて個別登録ＢＵメッセージ又はバルク登録ＢＵメッセージを選択的に生成する。

上記の処理の例を説明する。ＭＮ１００は既に、アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録しているものとする。また、ＨＡ１０１はＭＮ１００に対して、アドレスWLAN.Addrが７分間、バルク登録可能な旨を通知している。その４分後、ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要があるものとする。ＭＮ１００は、未だアドレス3G.Addr、WLAN.Addrの両方を使用しており、アドレスWLAN.Addrのバルク登録有効期間が満了していないので、アドレス3G.Addr、WLAN.Addrの両方をリフレッシュするためのバルク登録ＢＵメッセージをＨＡ１０１に送信する。さらにその４分後、ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要があるものとする。ＭＮ１００は、未だアドレス3G.Addr、WLAN.Addrの両方を使用しているが、アドレスWLAN.Addrのバルク登録有効期間が満了しているので、アドレス3G.Addr、WLAN.Addrを個別にリフレッシュするための個別登録ＢＵメッセージをＨＡ１０１に送信する。

＜ＨＡの処理＞
図７はＨＡ１０１がＭＮ１００からのバルク登録ＢＵメッセージを検証する処理を説明するためのフローチャートである。この処理は、モビリティ・バインディング・エンジン２６がＭＮ１００からバルク登録ＢＵメッセージを受信して、バルク登録検証エンジン２８がモビリティ・バインディング・エンジン２６からトリガ信号を受信したときにスタートし（ステップＳ６０のバルクＢＵ受信）、データベース・モジュール２７から関連情報（すなわちバインディング・キャッシュ２７０とバルク登録有効期間２７１）を引き出す（ステップＳ６１）。次いで、取得したバインディング・キャッシュ２７０とバルク登録有効期間２７１内に、バルク登録ＢＵメッセージ内に記述されているＩＰアドレスが有るか否かをチェックし（ステップＳ６２）、ある場合にはステップＳ６３に進み、他方、ない場合にはステップＳ６５に進む。

ステップＳ６３では、バルク登録有効期間２７１を参照してそのＩＰアドレスのバルク登録有効期間が満了しているか否かをチェックする。そして、そのＩＰアドレスのバルク登録有効期間が満了していない場合にはステップＳ６４に進み、他方、満了している場合にはステップＳ６５に進む。ステップＳ６４では、バインディング・キャッシュ２７０におけるそのＩＰアドレスに対して、パケット転送前のアドレス検証が不要である旨（アドレス検証不要）をマークしてステップＳ６６に進む。ステップＳ６５では、バインディング・キャッシュ２７０におけるそのＩＰアドレスに対して、パケット転送前のアドレス検証が必要である旨（アドレス検証要）をマークしてステップＳ６６に進む。ステップＳ６６では、その結果をリスト化してモビリティ・バインディング・エンジン２６に転送する。モビリティ・バインディング・エンジン２６はこのリストに基づいてそのバルク登録ＢＵメッセージを処理（アクセプト又は拒絶など）する。

上記の処理の例を説明する。ＨＡ１０１は現在、ＭＮ１００からのアドレス3G.Addr、WLAN.Addrのアクティブなバインディングを有する。さらに、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録が７分間、許可されていることを了解している。その４分後、ＨＡ１０１は、ＭＮ１００からアドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信したものとする。アドレスWLAN.Addrのバルク登録有効期間が満了していないので、ＨＡ１０１は、そのバインディング・リフレッシュ要求をアクセプトする。さらにその４分後、ＨＡ１０１は、ＭＮ１００からアドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信したものとする。アドレスWLAN.Addrのバルク登録有効期間が満了しているので、ＨＡ１０１は、アドレスWLAN.Addrあてにパケットを送信する前に、アドレスWLAN.Addrを検証する手順に移行する。

また、ＭＮ１００が新しいアドレスWLAN.Addr2を登録するためのバルク登録ＢＵメッセージを送信した場合、ＨＡ１０１は、アドレスWLAN.Addr2がバインディング・キャッシュ２７０内に存在しないので、アドレス検証プロセスをトリガする。アドレスWLAN.Addr2のアドレス検証が成功すると、ＨＡ１０１は、アドレスWLAN.Addr2が関連するバインディング・エントリをアップデートする。このように、ＨＡ１０１がアドレスWLAN.Addrのバルク登録有効期間をＭＮ１００に通知するので、ＭＮ１００はアドレスWLAN.Addrに対して、どのタイプのＢＵメッセージを送信すべきかを知得できる。この意味は、ＭＮ１００にとって、アドレスWLAN.Addrを使用したパケット転送が遅れることがないということである。

＜第２の実施の形態：ＭＮがバルク登録可否をＨＡに問い合わせる＞
第２の実施の形態では、ＭＮ１００がＨＡ１０１に対して、バルク登録を希望する特定のＩＰアドレスがバルク登録可能か否かを問い合わせる。図８は第２の実施の形態の通信シーケンスを示す。まず、第１の実施の形態と同様に、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用しているものとする。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。

このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ７０をＨＡ１０１に送信する。同様に、ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ７１をＨＡ１０１に送信する。第２の実施の形態では、個別登録ＢＵメッセージＳ７１はさらに、アドレスWLAN.Addrがバルク登録可能か否かを問い合わせるバルク登録許可要求を含む。

ＨＡ１０１では、アドレス3G.Addrが目的の送信元から来たと検証されることがイングレス・フィルタリングにより保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrを個別にバインディング確認（ＯＫ）するための個別登録ＢＡメッセージＳ３２をＭＮ１００に送り返す。同様に、アドレスWLAN.Addrに関してもイングレス・フィルタリングされるので、ＨＡ１０１は、アドレスWLAN.Addrを個別にバインディング確認（ＯＫ）するとともに、ＭＮ１００が複数の気付アドレスを登録していることを検出して、アドレスWLAN.Addrのバルク登録を許可する応答（ＢＬＫ−ＯＫ）を記述した個別登録ＢＡメッセージＳ３３をＭＮ１００に送り返す。

ここで、第１の実施の形態と異なり、ＭＮ１００がバルク登録許可を要求する利点として、ＨＡ１０１は、特定のＩＰアドレスに対してバルク登録を使用しようとしているか否かを推測する必要がない。この意味は、ＨＡ１０１がＭＮ１００からバルク登録許可要求を受信しない場合に、ＭＮ１００がバルク登録を必要としていないものと推測できるということである。

＜バルク登録許可要求メッセージ＞
図９は、第２の実施の形態においてアドレスWLAN.Addrがバルク登録可能か否かを問い合わせるバルク登録許可要求を含む個別登録ＢＵメッセージＳ７１のフォーマットを示す。メッセージ７１は、パケットヘッダ８０とモビリティ・オプション８１を有する。パケットヘッダ８０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション８１は、バインディング識別子（ＢＩＤ）オプション８１０とフラグ８１１を含む。ＢＩＤオプション８１０は通常、ＭＮ１００とＨＡ１０１が自身のバインディング・キャッシュをルックアップするための識別子を示し、関連するバインディング・エントリをより早く発見するのに使用される。第２の実施の形態におけるフラグ８１１は、モビリティ・オプション８１内に１ビットとして設けられて、デフォルト値（＝０）のときに、パケットヘッダ８０内の送信元アドレスに対してバルク登録許可を要求しないことを示し、他方、フラグ８１１＝１のときには、パケットヘッダ８０内の送信元アドレスに対してバルク登録許可を要求することを示す。

当業者であれば、フラグ８１１は、オプションタイプとして設けることができることは明らかである。但し、本発明はこれにも限定されない。オプションタイプとして設ける場合には、ＭＮ１００は、複数の個別登録ＢＵメッセージによるパケットオーバヘッドを最適化することを希望するときには、１つの個別登録ＢＵメッセージのみにこのオプションを添付することもできる。このオプションは、複数のＩＰアドレスに対してバルク登録許可を要求していることを示す。同様に、変形例として、フラグ８１１は、ＢＩＤオプション８１０内に設けられたフラグであってもよい。また、このオプションは、ＭＮ１００がＨＡ１０１に送信する他の形態のメッセージに添付することもできる。

フラグ８１１の使用例を説明する。ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ７１をＨＡ１０１に送信する際に、フラグ８１１を１にセットしてアドレスWLAN.Addrがバルク登録可能か否かをＨＡ１０１に問い合わせる。ＨＡ１０１では、何らかのチェック機能により、アドレスWLAN.Addrがバルク登録可能か否かを決定する。このチェック機能としては、ＨＡ１０１がＨＳＳサーバやＡＡＡサーバへ問い合わせ、ＭＮ１００がバルク登録サービスに加入しているか、又はアドレスWLAN.Addrが信頼できる外部の３ＧＰＰオペレータから来たものかをチェックする。但し、これには限定されない。チェックが成功すると、ＨＡ１０１は、アドレスWLAN.Addrがバルク登録可能であること（ＢＬＫ−ＯＫ）を示す個別登録ＢＡメッセージをＭＮ１００に送り返す。また、変形例として、ＨＡ１０１はＭＮ１００に対し、アドレスWLAN.Addrのバルク登録有効期間（例えば７分間）も通知する。

＜ＭＮの動作＞
図１０は、ＭＮ１００がバルク登録の可否を判断する処理を示す。この処理は、ＢＵメッセージをＨＡ１０１に送信する必要がある場合に、バルク登録可否判断エンジン２４がモビリティ・バインディング・エンジン２２からトリガ信号を受信したときにスタートし（ステップＳ９０のＢＵ送信トリガ）、データベース・モジュール２３のバインディング・アップデートリスト２３０から１つのエントリを引き出す（ステップＳ９１）。次いで、取得したエントリにおけるＩＰアドレスがバルク登録を許可されているか否かをチェックし（ステップＳ９２）、許可されていない場合にはステップＳ９３に進み、他方、許可されている場合にはステップＳ９４に進む。ステップＳ９３では、そのエントリのＩＰアドレスに対して、個別登録しなければならない旨（個別登録＝バルク登録不可）をマークしてステップＳ９５に進む。ステップＳ９４では、そのエントリのＩＰアドレスに対して、バルク登録できる旨（バルク登録可）をマークしてステップＳ９５に進む。ステップＳ９５では、バインディング・アップデートリスト２３０におけるすべてのエントリをチェックしたか否かを判定し、チェックしていなければステップＳ９１に戻り、他方、チェック済みであれば結果をリスト化してモビリティ・バインディング・エンジン２２に転送する。モビリティ・バインディング・エンジン２２はこのリストに基づいて個別登録ＢＵメッセージ又はバルク登録ＢＵメッセージを選択的に生成する。

上記の処理の例を説明する。ＭＮ１００は既に、アドレス3G.Addr、WLAN.AddrをＨＡ１０１に登録しているものとする。またＭＮ１００は、アドレスWLAN.Addrがバルク登録可能な旨を通知されている。すなわち、ＭＮ１００におけるアドレス検証情報２３２では、アドレスWLAN.Addrがバルク登録を許可されている。ＭＮ１００は、ＨＡ１０１における現在のバインディングをリフレッシュする必要がある場合、アドレスWLAN.Addrのバルク登録が許可されているか否かをチェックする。このチェックは、アドレス検証情報２３２がアドレスWLAN.Addrを含むか否かをチェックすることにより可能である。含むということは、ＭＮ１００がアドレスWLAN.Addrをバルク登録ＢＵメッセージに使用できることを意味する。

また、ＨＡ１０１は、ＭＮ１００がＩＰアドレスをバルク登録に使用可能か否かをアップデートすることができる。変形例として、ＨＡ１０１は、図９に示すメッセージを使用して、ＭＮ１００のバルク登録可否ステータスをアップデートすることができる。例えばＨＡ１０１は、アドレスWLAN.Addrが既にバルク登録に使用できないことを決定すると、アドレスWLAN.AddrのＢＩＤオプション８１０とフラグ８１１＝０を含むＢＡメッセージを送信する。ＨＡ１０１はこのＢＡメッセージにより、ＭＮ１００に対し、アドレスWLAN.Addrが既にバルク登録に使用できないことを通知する。なお、メッセージの種類はＢＡメッセージに限らず、Binding Revocationメッセージや、Binding Errorメッセージなどを使用してもよい。

＜ＨＡの処理＞
図１１は、ＨＡ１０１がＭＮ１００からのバルク登録ＢＵメッセージを検証する処理を示す。この処理は、ＭＮ１００からのバルク登録ＢＵメッセージを受信して、バルク登録検証エンジン２８がモビリティ・バインディング・エンジン２６からトリガ信号を受信したときにスタートし（ステップＳ１００のバルクＢＵ受信トリガ）、まず、バインディング・キャッシュ２７０から、受信したバルク登録ＢＵメッセージ内のＩＰアドレスに関連する情報（１つのエントリ）を引き出す（ステップＳ１０１）。次いで、取得したエントリにおけるＩＰアドレスがバルク登録を許可されているか否かをチェックし（ステップＳ１０２）、許可されていない場合にはステップＳ１０３に進み、そのエントリのＩＰアドレスに対して、受信したバルク登録ＢＵメッセージ内のＩＰアドレスが「間違った形式のＢＵメッセージで送信された旨」をマークする。他方、許可されている場合にはステップＳ１０４に進む、受信したバルク登録ＢＵメッセージ内のＩＰアドレスが「正しい形式のＢＵメッセージで送信された旨」をマークする。次いで、キャッシュ２７０において関連エントリをすべてチェックしたか否かを判定し、チェックしていなければステップＳ１０１に戻り、他方、チェック済みであれば結果をリスト化してモビリティ・バインディング・エンジン２６に転送する。ＨＡ１０１は、「間違った形式のＢＵメッセージで送信されたＩＰアドレス」に対してアドレス検証を実行するか、またはバルク登録が許可されていないことを示すレスポンスメッセージを返す。

上記の処理の例を説明する。ＨＡ１０１は現在、ＭＮ１００のアドレス3G.Addr、WLAN.Addrのアクティブなバインディングを有しているものとする。またＨＡ１０１は、アドレスWLAN.Addrがバルク登録可能な旨を了解している。ＨＡ１０１はＭＮ１００から、アドレスWLAN.Addrをリフレッシュするためのバルク登録ＢＵメッセージを受信すると、データベース・モジュール２７により、アドレスWLAN.Addrのバルク登録が許可されているか否かをチェックする。このチェックは、アドレスWLAN.Addrがアドレス検証情報２７２内に存在するか否かを識別することにより可能である。すなわち、存在する場合には、アドレスWLAN.Addrのバルク登録が許可されていることを示し、存在しない場合には、アドレスWLAN.Addrのバルク登録が許可されていないことを示す。このステータスにより、ＨＡ１０１は、アドレスWLAN.Addrのリフレッシュ要求をアクセプトするか、又は拒絶する。その結果、拒絶する場合には、ＨＡ１０１は、アドレスWLAN.Addrあてにパケットを転送する前にアドレスWLAN.Addrを検証する。

このように、ＭＮ１００が、バルク登録ＢＵメッセージ内にバルク登録許可要求を付加することにより、ＨＡ１０１がＭＮ１００に対して、特定のアドレスに対してバルク登録をするつもりであるか否かを推測する必要性を除去することができる。また、ＨＡ１０１の負荷を減少することができ、特定のアドレスあてのパケット転送が遅延することを防止することができる。

＜第３の実施の形態：プロキシがアドレス検証を援助＞
第３の実施の形態では、ＭＮ１００のＩＰアドレスの検証を助けるためにプロキシ・エンティティ（代理ノード）が用いられている。プロキシ・エンティティは、望ましくはプロキシ・モバイルＩＰ（ＰＭＩＰ）プロトコルを採用しているローカル・モビリティ・アンカー（ＬＭＡ）である。図１２は、プロキシ１１００を用いた第３の実施の形態の通信シーケンスを示す。まず、第１、第２の実施の形態の同様に、ＭＮ１００は３Ｇセルラ・インタフェース１０００とＷＬＡＮインタフェース１００１を有し、３Ｇセルラ・インタフェース１０００、ＷＬＡＮインタフェース１００１はそれぞれ、アドレス3G.Addr、WLAN.Addrを使用している。また、ＭＮ１００は図１に示すように、ホームネットワーク・ドメイン１０外をローミングしており、ＭＮ１００が現在使用している気付アドレスに関してＨＡ１０１をアップデートするものとする。このため、ＭＮ１００は、アドレス3G.Addrを個別にＨＡ１０１に登録するために３Ｇセルラ・インタフェース１０００から個別登録ＢＵメッセージＳ１１０をＨＡ１１０に送信する。同様に、ＭＮ１００は、アドレスWLAN.Addrを個別にＨＡ１０１に登録するためにＷＬＡＮインタフェース１００１から個別登録ＢＵメッセージＳ１１１をＨＡ１０１に送信する。

ＨＡ１０１では、アドレス3G.Addrが目的の送信元から来たことが検証されることがイングレス・フィルタリングにより保証されるので、ＨＡ１０１は個別登録ＢＵメッセージＳ３０をアクセプトして、アドレス3G.Addrを個別にバインディング確認（ＯＫ）するための個別登録ＢＡメッセージＳ１１２をＭＮ１００に送り返す。同様に、アドレスWLAN.Addrに関してもイングレス・フィルタリングされるため、個別登録ＢＡメッセージＳ１１３をＭＮ１００に送り返す。ＨＡ１０１は、ＭＮ１００が複数の気付アドレスを登録していることを検出するが、第３の実施の形態では、アドレスWLAN.Addrを個別にバインディング確認（ＯＫ）するとともに、バルク登録ＢＵメッセージを検証するプロキシ１１００が外部ネットワーク・ドメイン１１に存在すること（図のproxy）を記述した個別登録ＢＡメッセージＳ１１３をＭＮ１００に送り返す。ＭＮ１００がプロキシ１１００の配下に位置することをＨＡ１０１が知得する方法としては、アドレスWLAN.AddrのプリフィックスからＭＮ１００が信頼できる外部３ＧＰＰオペレータ・ネットワークに属していることを識別する方法がある。但し、これには限定されない。

ＭＮ１００は、個別登録ＢＡメッセージＳ１１３を受信すると、プロキシ１１００のＩＰアドレスをクエリ・メッセージＳ１１４で外部ネットワーク・ドメイン１１に問い合わせる（図のQuery proxy Addr）。クエリ・メッセージＳ１１４により、プロキシ１１００は自身のＩＰアドレスを応答メッセージＳ１１５でＭＮ１００に送り返す（図のResponse proxy Addr）。第３の実施の形態では、クエリ・メッセージＳ１１４と応答メッセージＳ１１５は、ＤＮＳ（domain name service）プロトコルを用いることができるが、本発明はこれには限定されない。ＭＮ１００は、プロキシ１１００のＩＰアドレスを知得すると、アドレスWLAN.Addrの検証を要求するためのバルク登録ＢＵメッセージＳ１１６を３Ｇセルラ・インタフェース１０００からプロキシ１１００に送信する。

バルク登録ＢＵメッセージＳ１１６はプロキシ１１００に対し、メッセージＳ１１６内に検証要求するＩＰアドレス（すなわちアドレスWLAN.Addr）が記述されていることを指示する。プロキシ１１００にアドレスWLAN.Addrを通知する理由は、メッセージＳ１１６がＭＮ１００とＨＡ１０１との間で暗号化されているからである。この意味は、プロキシ１１００がメッセージＳ１１６を解読してアドレスWLAN.Addrが真か否かを検証できないということである。そこで、プロキシ１１００は一旦、メッセージＳ１１６内で検証要求されているＩＰアドレスがＭＮ１００に属するものとみなして、メッセージＳ１１６に署名したバルク登録ＢＵメッセージＳ１１７をＨＡ１０１に送信する。この署名は、ＣＧＡ（cryptographically generated addresses）プロトコルを用いることができるが、本発明はこれには限定されない。ＣＧＡプロトコルの場合、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１７をプロキシ１１００の秘密キーで署名し、ＨＡ１０１は、受信したバルク登録ＢＵメッセージＳ１１７をプロキシ１１００の公開鍵を使用して検証する。

ＭＮ１００のバルク登録ＢＵメッセージを検証するためにプロキシ１１００を使用する利点は、ＭＮ１００がＩＰアドレスを暗号化する必要があるという複雑さを除去することにある。ＭＮ１００が暗号化する必要性をプロキシ１１００（例えばサーバ）にシフトすることにより、ＭＮ１００の処理する負担を軽減することができる。なお、サーバであるプロキシ１１００は、ＭＮ１００より計算能力が高い。

＜バルク登録ＢＵメッセージ＞
図１３は第３の実施の形態におけるバルク登録ＢＵメッセージＳ１１６、Ｓ１１７のフォーマットを示す。メッセージＳ１１６、Ｓ１１７は、パケットヘッダ１２０と、モビリティ・オプション１２１と、モバイルノード識別子１２２と、検証オプション１２３を含む。パケットヘッダ８０はメッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。モビリティ・オプション１２１は、バインディング識別子（ＢＩＤ）オプション１２１０とＩＰアドレス・オプション１２１１を含む。ＢＩＤオプション１２１０は通常、ＭＮ１００とＨＡ１０１がそれぞれ自身のバインディング・アップデートリスト２３０、バインディング・キャッシュ２７０をルックアップするための識別子を示し、関連するバインディング・エントリをより早く発見するのに使用される。

ＩＰアドレス・オプション１２１１は、パケットヘッダ１２０内の送信元アドレスに加えて、ＭＮ１００がＨＡ１０１に登録を希望する１つの追加のＩＰアドレスを含む。この追加のＩＰアドレスは、ＢＩＤオプション１２１０内のＢＩＤに関連している。バルク登録ＢＵメッセージＳ１１６、Ｓ１１７は、１を超えるＩＰアドレス・オプション１２１１を含んでもよい。これは、バルク登録ＢＵメッセージＳ１１６、Ｓ１１７が複数のＢＩＤオプション１２１０と複数のＩＰアドレス・オプション１２１１を含むことを意味する。モバイルノード識別子１２２には、このバルク登録ＢＵメッセージＳ１１６、Ｓ１１７を送信したＭＮ１００の識別子を記述する。モバイルノード識別子１２２により、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を検証するときに、追加のＩＰアドレスがＭＮ１００に属するかを知得することができる。

検証オプション１２３は、ＩＰアドレス・オプション１２３０と、パラメータ・オプション１２３１と、署名オプション１２３２を含む。ＩＰアドレス・オプション１２３０には、ＭＮ１００がプロキシ１１００に検証させる追加のＩＰアドレスを記述する。ＩＰアドレス・オプション１２３０におけるＩＰアドレスとＩＰアドレス・オプション１２１１におけるＩＰアドレスは、望ましくは同じである。パラメータ・オプション１２３１は、ＨＡ１０１に対して、プロキシ１１００がバルク登録ＢＵメッセージＳ１１６を検証するために使用するセキュリティ・パラメータを指示する。望ましくは、パラメータ・オプション１２３１内の情報は、プロキシ１１００の公開鍵か、又はプロキシ１１００がＣＧＡで使用する偶数のパラメータであるが、本発明ではこれには限定されない。

最後に、署名オプション１２３２は、一般的にはプロキシ１１００の署名を含む。この署名はＨＡ１０１に対し、バルク登録ＢＵメッセージＳ１１７内のＩＰアドレスが真であることをプロキシ１１００が検証したことを示す。この署名は望ましくは、バルク登録ＢＵメッセージＳ１１７の全体とプロキシ１１００の秘密鍵の連結である。オプションとして、パケットサイズを低減するために、この署名は、バルク登録ＢＵメッセージＳ１１７の全体とプロキシ１１００の秘密鍵の連結の一部でもよい。

プロキシ１１００がバルク登録ＢＵメッセージＳ１１６に署名する理由は、悪意のあるノードがリプレイ・アタックを仕掛けることを防止するためである。リプレイ・アタックとは、悪意のあるノードがバルク登録ＢＵメッセージＳ１１６、Ｓ１１７を盗み見て改変し、後でＨＡ１０１に送信することを言う。例えばプロキシ１１００がアドレスWLAN.Addr用のバルク登録ＢＵメッセージＳ１１６を検証する場合、プロキシ１１００は、検証オプション１２３のみにアドレスWLAN.Addrを記述して署名する。ＨＡ１０１は、この署名が正しいと確認すると、アドレスWLAN.Addrをアクセプトしてバインディング・キャッシュ２３０に登録する。

さて、悪意のあるノードがバルク登録ＢＵメッセージＳ１１７を盗み見て、ＩＰアドレス・オプション１２１１内のＩＰアドレスを他のＩＰアドレスに改変し、この改変したバルク登録ＢＵメッセージＳ１１７をＨＡ１０１に送信したとする。上記のように署名が正しいと確認したＨＡ１０１は、検証オプション１２３内のアドレスWLAN.AddrがＩＰアドレス・オプション１２１１内のＩＰアドレスと異なることに気付く。このため、ＨＡ１０１は、送信元が悪意のあるノードであるとして、バインディング・キャッシュ２３０からアドレスWLAN.Addrを削除する。このような動作により、悪意のあるノードがアドレスWLAN.Addrを悪用して通信サービスが崩壊することを防止することができる。悪意のある行為を防止するためには、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１７の全体に署名すべきである。この方法により、悪意のあるノードがバルク登録ＢＵメッセージＳ１１７を改変することを困難にすることができる。

＜プロキシの処理＞
図１４は、プロキシ１１００がバルク登録ＢＵメッセージＳ１１６内のＩＰアドレス検証を援助する処理を示す。この処理は、バルク登録ＢＵメッセージＳ１１６を受信したときにスタートし（ステップＳ１３０）、メッセージＳ１１６の検証オプション１２３内から１つのＩＰアドレスを引き出して（ステップＳ１３１）、そのＩＰアドレスをＭＮ１００が実際に使用しているか否か、すなわちそのＩＰアドレスがＭＮ１００に属するか否かをチェックする（ステップＳ１３２）。このチェック方法の１つとして、プロキシ１１００のデータベースにおいてそのＩＰアドレスがバルク登録ＢＵメッセージＳ１１６内のモバイルノード識別子に対応しているかを識別する。そのＩＰアドレスがＭＮ１００に属しないと判定した場合には、バルク登録ＢＵメッセージＳ１１６を拒絶して検証オプション１２３内の他のＩＰアドレスをチェックせず（ステップＳ１３３）、次いでアイドルモードに戻る（ステップＳ１３６）。

他方、ステップＳ１３２においてそのＩＰアドレスがＭＮ１００に属すると判定した場合には、検証オプション１２３内に残りのＩＰアドレスが存在するか否かをチェックし（ステップＳ１３４）、存在する場合にはステップＳ１３１に戻る。ステップＳ１３４において検証オプション１２３内に残りのＩＰアドレスが存在しない場合には、バルク登録ＢＵメッセージＳ１１６の全体に署名してＨＡ１０１に転送し（ステップＳ１３５）、次いでアイドルモードに戻る（ステップＳ１３６）。

プロキシ１１００の処理をさらに詳しく説明する。プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を受信すると、モバイルノード識別子１２２に基づいてバルク登録ＢＵメッセージＳ１１６がＭＮ１００から来たことを確認する。また、検証オプション１２３内のＩＰアドレス・オプション１２３０により、プロキシ１１００は、ＭＮ１００がアドレスWLAN.AddrをＨＡ１０１に登録したいことを知得する。プロキシ１１００は自身のデータベースをチェックして、アドレスWLAN.Addrが外部ネットワーク・ドメイン１１でＭＮ１００に割り当てられたものかを識別する。望ましくは、プロキシ１１００は、ＤＣＨＰサーバに問い合わせて、アドレスWLAN.AddrがＭＮ１００に割り当てられたものかを検証する。ＤＣＨＰサーバからの応答が肯定である場合、プロキシ１１００は、署名を署名オプション１２３２に添付し、バルク登録ＢＵメッセージＳ１１７をＭＮ１００のＨＡ１０１に転送する。逆に、ＤＣＨＰサーバからの応答が否定である場合、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６を拒絶する。その結果、プロキシ１１００は、バルク登録ＢＵメッセージＳ１１６の送信元が悪意のあるノードの疑いがあるとして今後のチェックのためにマークすることができる。

プロキシ１１００を使用すると、ＨＡ１０１がＭＮ１００のＩＰアドレスを検証するために通信するエンティティの数を減少することができる。例えばＨＡ１０１は、グローバル通信ドメイン１２配下の数千のモバイルノードではなく、グローバル通信ドメイン１２内の選択されたアンカーポイントと通信するのみでよい。また、通信チャネルが減少すると、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第４の実施の形態：ＭＮ／ＨＡがバルク登録可否を外部ネットワークに応じて決定＞
第４の実施の形態では、例えばＭＮ１００は、バルク登録を行うか否かの判断を、外部ネットワーク・ドメイン１１において初期起動したときに、以前にＨＡ１０１により通知されていた情報に基づいて行う。望ましくは、その情報は、どのアクセスネットワークのＩＰアドレスがバルク登録可能か（バルク登録として使用されているか）の情報である。但し、本発明はこれには限定されない。例えばＨＡ１０１は、ＭＮ１００が接続（connect）しているアクセスネットワークに基づいてＭＮ１００のバルク登録動作をアップデートしている。ＨＡ１０１は、ＭＮ１００が全世界的に相互に動作可能なマイクロ波アクセス・ネットワーク（ＷｉＭＡＸネットワーク）に接続（connect）していることを了解すると、ＭＮ１００のどのＷｉＭＡＸアドレスもバルク登録可能であること（ＢＬＫ−ＯＫ）を通知する。望ましくは、ＭＮ１００が接続（connect）しているどのアクセスネットワークがバルク登録可能かをＨＡ１０１がいかに知得するかは、ホームネットワーク・ドメイン１０と外部ネットワーク・ドメイン１１との間の交渉次第である。ＭＮ１００は、ＷｉＭＡＸアドレスについてＨＡ１０１をアップデートしたいときにはいつでも、ＷｉＭＡＸアドレスをバルク登録するためのバルク登録ＢＵメッセージをＨＡ１０１に送信する。

変形例として、どのタイプのＩＰアドレスがバルク登録可能かを示す情報を予めＭＮ１００に設定しておく。この手法によれば、この情報をＭＮ１００とＨＡ１０１との間で通信する必要性を除去することができる。ＭＮ１００は、どのタイプのアクセスネットワークがＨＡ１０１にとって信頼できるかを知得していると、ＨＡ１０１に送信すべきＢＵメッセージのタイプがわかる、したがって、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第５の実施の形態：ＭＮが送信元アドレスを切り換えてバルク登録有効期間を延長＞
第５の実施の形態では、ＭＮ１００がバルク登録ＢＵメッセージを使用して個々のアドレスのバルク登録有効期間を延長する。この手法を実現するために、ＭＮ１００は、ＨＡ１０１におけるＩＰアドレスを更新するときに、インタフェース１０００、１００１を交互に使用する。この手法により、バルク登録ＢＵメッセージの送信元アドレスで送信されるＩＰアドレスが交互にイングレス・フィルタリングにより検証される。

以下に具体例を説明する。ＭＮ１００がアドレス3G.Addr、WLAN.Addrの両方をＨＡ１０１に登録する場合、ＷＬＡＮアクセスネットワーク１１１が不安定であるので、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間として５分間を割り当てる。また、３Ｇセルラ・アクセスネットワーク１１が安定しているので、ＨＡ１０１は、アドレス3G.Addrのバルク登録有効期間として７分間を割り当てる。５分後、ＭＮ１００は、ＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrの登録をリフレッシュする必要がある場合、アドレス3G.Addrのバルク登録有効期間が未だアクティブであるので、送信元アドレスをアドレスWLAN.Addrとし、追加のＩＰアドレスをアドレス3G.Addrとしたバルク登録ＢＵメッセージを送信する。この手法により、イングレス・フィルタリングによりアドレスWLAN.Addrが検証されるのみならず、アドレス3G.Addr用の個別登録ＢＵメッセージを送信する必要性を除去することができる。イングレス・フィルタリングによりアドレスWLAN.Addrが検証されると、ＨＡ１０１は、アドレスWLAN.Addrのバルク登録有効期間を延長する。

変形例として、ＭＮ１００のすべてのＩＰアドレスのバルク登録有効期間を同じとする。このため、送信元アドレスを順番に入れ換えるか、２つのＩＰアドレスをペアリングし（一方を送信元アドレスとする）、バルク登録ＢＵメッセージを使用して各ＩＰアドレスのバルク登録有効期間を延長することができる。

ＭＮ１００がＨＡ１０１におけるＩＰアドレスの登録を更新するときに、インタフェース１０００、１００１を交互に使用できるということは、特定のＩＰアドレスのバルク登録有効期間を、ＨＡ１０１と素早く交渉して延長することができるということである。このＨＡ１０１との効率的な交渉により、ＭＮ１００がパケット転送のための気付アドレス使用が遅れることを防止できる。

＜第６の実施の形態：バルクＢＡ＞
第６の実施の形態では、図４において、ＨＡ１０１は個別登録ＢＵメッセージＳ３０、Ｓ３１、バルク登録ＢＵメッセージ３４ａの応答として、ＭＮ１００に複数の個別登録ＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂを送り返す代わりに、１つのＢＡメッセージ（以下、バルク登録ＢＡメッセージ３４ｃ）を送り返す。図１５はバルク登録ＢＡメッセージ３４ｃのフォーマットを示す。バルク登録ＢＡメッセージ３４ｃは、パケットヘッダ１４０と、フラグ１４１と、モビリティ・オプション１４２を含む。パケットヘッダ１４０は、メッセージ送信元と、メッセージタイプとメッセージ長の各フィールドを有し、メッセージ送信元は、ＩＰｖ４又はＩＰｖ６のアドレスであるが、これには限定されない。フラグ１４１は、ＨＡ１０１がＭＮ１００に対し、このバルク登録ＢＡメッセージ３４ｃが各ＩＰアドレスに関するバルク登録についての複数の異なる通知を含むか否かを通知する。フラグ１４１は１ビットでよく、デフォルト値（＝０）は、このバルク登録ＢＡメッセージ３４ｃ内のすべての通知が同じであることを示す。他方、フラグ１４１＝１の場合、このバルク登録ＢＡメッセージ３４ｃ内の通知が異なることを示す。この場合、ＭＮ１００は、モビリティ・オプション１４２内の個々の通知を検査する必要がある。

モビリティ・オプション１４２は、ＢＩＤオプション１４２０と、シーケンス番号オプション１４２１と、ステータス・オプション１４２２と、通知オプション１４２３を含む。ＢＩＤオプション１４２０は、ＭＮ１００がＨＡ１０１に登録するＩＰアドレスに割り当てられたＢＩＤを示す。望ましくは、ＢＩＤオプション１４２０に記述されているＢＩＤは、ＭＮ１００がＨＡ１０１に送信したバルク登録ＢＵメッセージ３４ａに記述されているＢＩＤである。シーケンス番号オプション１４２１は典型的には、ＨＡ１０１が受信したバルク登録ＢＵメッセージ３４ａで伝送されたシーケンス番号を示す。シーケンス番号により、ＭＮ１００は、ＭＮ１００が送信したバルク登録ＢＵメッセージ３４ａにこのバルク登録ＢＡメッセージ３４ｃが対応しているかを識別することができる。

ステータス・オプション１４２２はＭＮ１００に対して、特定のＩＰアドレスの登録がＨＡ１０１において成功したか否かを通知する。ステータス・オプション１４２２はさらに、典型的にはＭＮ１００に対してＨＡ１０１が登録を拒否した理由も通知する。最後の通知オプション１４２３は、特定のＩＰアドレスがバルク登録可能か否かのＨＡ１０１の意図を示す。望ましくは、通知オプション１４２３はさらに、バルク登録有効期間を示す。このバルク登録ＢＡメッセージは、１を超えるモビリティ・オプション１４２を含むことができる。すなわち、バルク登録ＢＡメッセージ３４ｃは、個別登録ＢＵメッセージＳ３０、Ｓ３１、バルク登録ＢＵメッセージ３４ａで登録が要求された個々のアドレスそれぞれに対応する複数のＢＩＤオプション１４２０と、複数のシーケンス番号オプション１４２１と、複数のステータス・オプション１４２２と、複数の通知オプション１４２３を含むことができる。

変形例として、このバルク登録ＢＡメッセージ３４ｃは、同じシーケンス番号を含んでもよい。例えば、もしＭＮ１００が１つのバルク登録ＢＵメッセージ３４ａをＨＡ１０１に送信した場合、１つのシーケンス番号によりこのバルク登録ＢＵメッセージ３４ａを識別する。この場合、バルク登録ＢＡメッセージ３４ｃのパケットサイズを最適化するために、ＨＡ１０１は、すべての登録されたＩＰアドレスに対して１つのシーケンス番号オプション１４２１を使用することができる。

他の変形例として、バルク登録ＢＡメッセージ３４ｃは、同じステータスを含んでもよい。例えばＨＡ１０１は、もしバルク登録ＢＵメッセージ３４ａ内のすべてのＩＰアドレス登録をアクセプトする場合、１つのステータス・オプション１４２２を使用してすべてのＩＰアドレスのステータスを示すことができる。さらに他の変形例として、このバルクＢＡメッセージは、同じ通知を含んでもよい。例えばＨＡ１０１は、もしすべての登録されたＩＰアドレスに対して同じバルク登録有効期間を割り当てる場合、バルク登録ＢＡメッセージ３４ｃのパケットサイズを最適化するために、１つの通知オプション１４２３を使用して共通のバルク登録有効期間を示すことができる。

さらには、登録されたすべてのＩＰアドレスのそれぞれに対するモビリティ・オプション１４２を含めるのではなく、１つのモビリティ・オプション１４２を含めて、すべてのＩＰアドレスが登録されたことを示してもよい。
この場合、バルク登録ＢＡメッセージ３４ｃに含まれている１つのモビリティ・オプション１４２の中のＢＩＤオプション１４２０の値や、ステータス・オプション１４２２の値として、すべてのＩＰアドレスが登録されたことを示す特別な値を指定することが望ましい。

図１６は、ＭＮ１００がバルク登録ＢＡメッセージ３４ｃを受信した場合の処理を示す。この処理は、バルク登録ＢＡメッセージ３４ｃをＨＡ１０１から受信した場合にスタートし（ステップＳ１５０）、受信したメッセージ３４ｃから１つのモビリティ・オプション１４２を引き出す（ステップＳ１５１）。１つのモビリティ・オプション１４２を引き出すと、モビリティ・オプション１４２内のステータス・オプション１４２２に基づいて１つのＩＰアドレス登録要求がアクセプトされたか否かをチェックする（ステップＳ１５２）。アクセプトされなかった場合にはそのＩＰアドレスに対して「拒絶」をマークし（ステップＳ１５３）、次いでステップＳ１５７に進む。

ステップＳ１５２においてアクセプトされた場合には、そのＩＰアドレスがバルク登録されたか否かをチェックする（ステップＳ１５４）。バルク登録されなかった場合には、そのＩＰアドレスに対して「アクセプト」と「バルク登録不可」をマークし（ステップＳ１５５）、次いでステップＳ１５７に進む。ステップＳ１５４においてバルク登録された場合には、そのＩＰアドレスに対して「アクセプト」と「バルク登録可」をマークし（ステップＳ１５６）、次いでステップＳ１５７に進む。ステップＳ１５７では、受信したメッセージ３４ｃ内に次のモビリティ・オプション１４２があるか否かをチェックし、もしあればステップＳ１５１に戻り、他方、最後のモビリティ・オプション１４２であれば、バインディング・アップデートリスト２３０をアップデートするために、処理結果をリスト化してモビリティ・バインディング・エンジン２２に転送する（ステップＳ１５８）。

具体例を説明する。ＭＮ１００は現在、ＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrをリフレッシュするためにバルク登録を使用しているものとする。ＭＮ１００は、許可されているアドレス3G.Addr、WLAN.Addrのバルク登録有効期間に基づいて、アドレス3G.Addr、WLAN.Addrのバルク登録有効期間がまもなく満了することを知得している。このことは、ＭＮ１００がアドレス3G.Addr、WLAN.Addrを個別にリフレッシュするために個別登録ＢＵメッセージを送信する必要があることを黙示している。ＨＡ１０１は、これらの個別登録ＢＵメッセージを受信すると、アドレス3G.Addr、WLAN.Addrそれぞれの新しいバルク登録有効期間をＭＮ１００に通知する必要がある。そこで、ＨＡ１０１は、個別登録ＢＡメッセージ３４ｂを送信する代わりに、バルク登録ＢＡメッセージ３４ｃを使用してアドレス3G.Addr、WLAN.Addrの各バルク登録有効期間をＭＮ１００に通知する。この手法により、ＨＡ１０１がＭＮ１００に送信しなければならないメッセージ数を最適化することができる。

バルク登録ＢＡメッセージ３４ｃを使用することにより、ＨＡ１０１がＭＮ１００に対して、ＭＮ１００のＩＰアドレスのバルク登録サポートのステータスを通知する方法を効率化することができる。したがって、ＭＮ１００がパケット転送のために気付アドレスを使用するのが遅れることを防止できる。

＜第７の実施の形態：ＨＡがバルクＢＵ送信ＩＦを指示＞
第７の実施の形態では、ＨＡ１０１がＭＮ１００に対し、ＩＦ１０００、１００１のうち、バルク登録ＢＵメッセージ３４ａを送信すべきＩＦを指示する。図８を参照して第７の実施の形態について説明する。ＨＡ１０１からＭＮ１００に送信されるアドレスWLAN.Addrの個別登録ＢＡメッセージＳ７３は、バルク登録ＢＵメッセージ３４ａを送信すべきＩＦを指示する。例えば、ＨＡ１０１は、ＭＮ１００がＩＦ１００１（アドレスWLAN.Addr）からバルク登録ＢＵメッセージ３４ａを送信することを希望するものと仮定する。この場合、ＭＮ１００がＨＡ１０１におけるアドレス3G.Addr、WLAN.Addrの両方の登録を更新するためのバルク登録ＢＵメッセージ３４ａを送信する必要があるときには、ＭＮ１００は、ＨＡ１０１により指示されたＩＦ１００１（アドレスWLAN.Addr）からバルク登録ＢＵメッセージ３４ａを送信する。つまりこの場合、3G.Addrがバルク登録されるアドレスとなる。なお、バルク登録ＢＵメッセージを送信するべきＩＦを指示する代わりに、バルク登録を許可するアドレスを指示してもよい。例えば、ＨＡ１０１は、ＭＮ１００のアドレス3G.Addrを、アドレスWLAN.Addrの登録ＢＵメッセージに挿入してバルク登録メッセージとして送信してもよいと判断した場合には、個別登録ＢＡメッセージＳ７２に、バルク登録を指示する情報が含まれる。また、ＨＡ１０１は、ＭＮ１００のアドレスWLAN.Addrを、アドレス3G.Addrの登録ＢＵメッセージに挿入してバルク登録メッセージとして送信してもよいと判断した場合には、個別登録ＢＡメッセージＳ７３に、バルク登録を指示する情報が含まれる。

＜第８の実施の形態：ＵＥのＩＦ１０００がホームネットワーク・ドメイン１０に直接接続＞
第８の実施の形態では、図１７に示すように、ＵＥ１００のＩＦ１０００が３Ｇセルラ１１０を介してＵＥ１００のホームネットワーク・ドメイン１０に直接接続し、ＩＦ１００１がＷＬＡＮ１１１（又はＷｉＭＡＸ、ＨＲＰＤ：High Rate Packet Data）などのＮｏｎ−３ＧＰＰネットワーク（Ｎｏｎ−３ＧＰＰ Ｎｅｔｗｏｒｋ）を介してホームネットワーク・ドメイン１０へ接続している場合に、ＨＡ１０１は、ＷＬＡＮ１１１から取得したＩＰアドレスをＣｏＡとして通知・登録するための個別登録ＢＵメッセージ送信するべきＩＦを指示する。本発明の第７の実施の形態との違いは、ＩＦ１０００（３Ｇインタフェース、３Ｇ−ＩＦ）が接続しているネットワークが外部ネットワーク・ドメインではなく、ホームネットワーク・ドメイン１０であるため、ＨＡ１０１によって指定されたＩＦから送信されるメッセージが、バルク登録ＢＵメッセージではなく、ＩＦ１００１（ＷＬＡＮインタフェース、ＷＬＡＮ−ＩＦ）に関するＣｏＡを含む個別登録ＢＵメッセージである点である。つまり、ＨＡ１０１はＢＵメッセージを送信するＩＦを指定するが、それを受けたＵＥ１００が送信するＢＵメッセージは、バルク登録ＢＵメッセージに限らず、図１７に示す接続形態の場合には、個別登録ＢＵメッセージを指定されたＩＦから送信する。

本実施の形態で述べるように、ＵＥ１００が、バルクＢＵメッセージだけでなく、個別登録ＢＵメッセージをＩＦ１０００から送信することができれば、３Ｇセルラ１１０が提供する様々な利点（安定した帯域（ＱｏＳ）や接続状態、強固なセキュリティ、ＨＡ１０１への最短パス）を使用してＢＵメッセージを送信することができるという利点をＵＥ１００及びホームネットワーク・ドメイン１０の双方で得られる。

通常３Ｇセルラ１１０への接続は、ＰＭＩＰやＧＴＰ（GPRS Tunneling Protocol）などのネットワークベースの移動制御プロトコルによって管理されるため、ＵＥ１００は、ＩＦ１０００に割り当てられたアドレスを個別登録ＢＵメッセージで通知する必要はなく、割り当てられたアドレスをホームアドレス（ＨｏＡ）として直接使用することができる。一方、Ｎｏｎ−３ＧＰＰネットワークへの接続ではＵＥ１００はＭＩＰｖ６（又はＭＩＰｖ４）を使用するため、ＷＬＡＮ１１１から割り当てられたアドレスをＨｏＡに対するＣｏＡとしてＨＡ１０１へ登録する。

図１８は、本実施の形態におけるメッセージシーケンスを表したものである。ＵＥ１００は、Ｎｏｎ−３ＧＰＰネットワークへ接続しているＩＦ１００１のＩＰアドレスをＨＡ１０１へ登録するために、個別登録ＢＵメッセージを送信する。ＵＥ１００からの個別登録ＢＵメッセージを受けたＨＡ１０１は、ＵＥ１００が登録済みのバインディング・キャッシュを更新するための個別登録ＢＵメッセージを送信する際に、ＩＦ１０００を使用することを許可するか否かを判断する。この判断は、例えば、通知されたＣｏＡを割り当てたネットワーク（ＷＬＡＮ１１１）が、ホームネットワーク・ドメイン１０にとって信頼できるネットワークであるか否かを確認することによって行うことができるが、これに限定されない。また、Ｎｏｎ−３ＧＰＰネットワークが、ＨＡ１０１が属するオペレータによって管理されているネットワークである場合に、ＩＦ１０００の使用を許可すると判断してもよい。さらにまた、ＩＦ１００１から送信されたＢＵメッセージを一定回数受信した場合に、それ以降のＢＵメッセージをＩＦ１０００から送信するよう指示してもよい。さらにまた、ＵＥが同一のＮｏｎ−３ＧＰＰネットワークに一定時間以上接続している場合に、それ以降のＢＵメッセージをＩＦ１０００から送信するよう指示してもよい。

ＨＡ１０１が、ＩＦ１０００を使用した個別登録ＢＵメッセージの送信を許可する場合は、ＵＥ１００に対し、ＩＦ１００１の使用が許可されたこと（ＩＦ１０００を使用すること）を示すステータスを含む個別登録ＢＡメッセージをレスポンスとして返す。なお、ＨＡ１０１は、ＩＦ１０００の使用が許可されている期間を示す３Ｇ−ＩＦ有効期間を通知してもよい。

個別登録ＢＡメッセージを受けたＵＥ１００は、ＩＦ１００１のＩＰアドレスに関するバインディング・アップデートリストエントリの中に、ＩＦ１０００の使用が可能であることを示す情報を格納する。そして、バインディング・キャッシュを更新するために個別登録ＢＵメッセージを送信する際に、バインディング・アップデートリストエントリを参照し、ＩＦ１０００の使用が可能であるか否かを確認する。確認の結果、可能であった場合には、ＩＦ１００１のＩＰアドレスを登録するための個別登録ＢＵメッセージを、ＩＦ１０００を使用して送信する。なお、３Ｇ−ＩＦ有効期間が通知されている場合は、３Ｇ−ＩＦ有効期間が経過した時点で、バインディング・アップデートリストエントリ内のＩＦ１０００使用可能情報は無効化される。無効化された後に個別登録ＢＵメッセージを送信する場合には、ＩＦ１００１が使用される。

図１９は、個別登録ＢＡメッセージのフォーマット例である。モビリティ・オプションには、登録対象のＣｏＡに対応するＢＩＤを含むＢＩＤオプションと、ＣｏＡの登録結果を示すステータスと、次回以降の送信にＩＦ１０００を使用することが可能であるか否か（３Ｇ−ＩＦ使用許可情報）を示す通知オプションが含まれている。３Ｇ−ＩＦ使用許可情報は、ステータスがＯＫの場合に許可または不許可が示される。なお、ステータス、及び３Ｇ−ＩＦ使用許可情報は、ＢＩＤオプションの中に含まれていてもよいし、ＢＡヘッダ（不図示）の中に含まれていてもよい。

図２０は、ＩＦ１０００を使用して送信する場合の個別登録ＢＵメッセージのフォーマット例である。パケットヘッダの送信元アドレスにはＩＦ１０００に割り当てられているＩＰアドレス（ホームアドレス）が設定され、宛先アドレスにはＨＡ１０１のアドレスが設定される。また、パケットヘッダには、ＢＵヘッダも含まれている。さらに、モビリティ・オプションとして、ホームアドレスを含むＨｏＡオプションや、登録対象のＣｏＡ及び対応するＢＩＤが含まれる。また、個別登録ＢＵメッセージが３Ｇ−ＩＦを使用して送信されたメッセージであり、通常の個別登録ＢＵメッセージと区別ができるように、３Ｇ−ＩＦ使用情報が含まれる。３Ｇ−ＩＦ使用情報は、ＢＩＤオプションの中にフラグ（３Ｇ−ＩＦ使用許可フラグ）として含まれていてもよい。またＣｏＡもＢＩＤオプションに含まれていてもよい。なお、ＩＦ１０００を使用して送信する場合の個別登録ＢＵメッセージとしては、ＩＦ１００１から送信する場合の個別登録ＢＵメッセージをＩＦ１０００のアドレスでカプセル化して送信する方法を用いてもよい。また、カプセル化の代わりに、ＣｏＡを含むルーティングヘッダを付加して送信してもよい。

図２を用いてＵＥ１００の構成を説明すると、バルク登録可否判断エンジン２４は、本実施の形態では、３Ｇ−ＩＦ使用可否判断エンジンとして機能する。つまり、モビリティ・バインディング・エンジン２２によって、バインディング・キャッシュの更新がトリガされると、３Ｇ−ＩＦ使用可否判断エンジンは、ＩＦ１００１のＩＰアドレスを登録する際に、データベース・モジュール２３内のバインディング・アップデートリスト２３０を参照し、ＩＦ１０００を使用することが許可されているか否か、または、ＩＦ１０００を使用することが指定されているか否かを確認する。確認の結果、ＩＦ１０００の使用が許可されている場合には、図２０に示されている個別登録ＢＵメッセージを生成し、ＩＦ１００１を用いて送信する。

図３を用いてＨＡ１０１の構成を説明する。第７の実施の形態において、バルク登録検証エンジン２８が許可するバルク登録は、ＵＥ１００はＩＦ１００１のＣｏＡをＩＦ１０００から送信するＢＵメッセージに含めてもよいということを意味する。したがって、本実施の形態のＨＡ１０１は、第７の実施の形態におけるバルク登録の可否判断と同様の判断を行うと定義することができる。一方、本実施の形態のＨＡ１０１は、３Ｇ−ＩＦを使用して個別登録ＢＵメッセージの送信の可否を判断すると定義することもできる。この場合、バルク登録検証エンジン２８は、３Ｇ−ＩＦ使用検証エンジンとして機能する。つまり、モビリティ・バインディング・エンジン２６によって受信された個別登録ＢＵメッセージについて、ＵＥ１００がＩＦ１０００を使用して送信することを許可するか否かを判断する。許可すると判断した場合には、バインディング・キャッシュ２７０に、許可を示す情報を格納するとともに、許可を示すステータスを含む個別登録ＢＡメッセージを返す。

本発明の第８の実施の形態によって、ＵＥ１００は、Ｎｏｎ−３ＧＰＰネットワークに接続しているＩＦに割り当てられたＩＰアドレスを登録するＢＵメッセージを、３Ｇネットワークに接続するＩＦから送信することができることを知得することができ、不安定なＮｏｎ−３ＧＰＰネットワークではなく、安定した信頼性のある３ＧＰＰネットワークを使用してＢＵメッセージを送信することが可能となる。

以上、本発明の望ましい実施の形態について説明したが、当業者であれば、本発明の範囲を逸脱しない範囲で、種々の変形が可能であることは明らかである。例えば、ＭＮ１００については、当業者であれば、ネットワーク・モビリティ（ＮＥＭＯ）プロトコルを採用したモバイル・ルータにも適用することができることは明らかである。この場合、モバイル・ルータは、バルク登録ＢＵメッセージ３４ａを使用してプリフィックスをＨＡ１０１に登録する。このことは、プリフィックスの範囲内で構成されたＩＰアドレスがモバイル・ルータに属することを目視している。

また、本発明は、プロキシ・モバイルＩＰ（ＰＭＩＰ）プロトコルを採用したモバイル・アクセス・ゲートウェイ（ＭＡＧ）にも適用することができる。ここで、ＭＡＧは、前述した実施の形態におけるプロキシ１１００であって、ローカル・モビリティ・アンカー（ＬＭＡ）がＩＰアドレスを検証するのを助ける。このため、ＭＡＧは、バルク登録ＢＵメッセージ３４ａを使用して多くのモバイル装置（モバイルノードやモバイル・ルータ）のＩＰアドレスをＬＭＡに登録する。

加えて、本発明は、ＭＩＰｖ４（mobile IP version 4）を採用した外部エージェントにも適用することができる。この場合、外部エージェントはバルク登録ＢＵメッセージ３４ａを使用して、ＭＮ１００が複数のＩＰアドレスをＨＡ１０１に登録するのを助ける。さらに、外部エージェントは、前述した実施の形態におけるプロキシ１１００であって、ＨＡ１０１がＩＰアドレスを検証するのを助けることも可能である。

最後に、上記の実施の形態では、ＨＡ１０１がＭＮ１００からのＢＵメッセージＳ３０、Ｓ３１、Ｓ３４ａ等の受信側であって、ＭＮ１００へのＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂ、Ｓ３４ｃ等の送信側である場合について説明したが、当業者であれば、ＨＡ１０１は、他のエンティティ（例えば通信相手のノード、通信相手のルータ、ＬＭＡ）に置き換えても、ＭＮ１００からのＢＵメッセージＳ３０、Ｓ３１、Ｓ３４ａ等を受信してＭＮ１００へのＢＡメッセージＳ３２、Ｓ３３、Ｓ３４ｂ、Ｓ３４ｃ等を送信することも可能である。

なお、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明によれば、特許請求の範囲に記載した発明の他に、以下のような発明が提供される。
（１）前記第２の手段は、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスがネットワークのイングレス・フィルタリングにより検証されたものとみなして登録するとともに、その送信元アドレスあてに前記バルク登録を許可する応答メッセージを送信し、
前記第３の手段は、前記移動装置が前記バルク登録メッセージを送信する場合に、前記バルク登録を許可されたアドレス以外のインタフェースを送信元として、前記バルク登録を許可された送信元アドレスを送信元アドレスフィールド外に含む前記バルク登録メッセージを送信することを特徴とする請求項１０に記載のアドレス登録システム。

（２）前記第２の手段は、前記移動管理装置が前記応答メッセージによりバルク登録有効期間を前記移動装置に通知し、
前記第３の手段は、前記移動装置が前記バルク登録メッセージを前記バルク登録有効期間内に送信することを特徴とする請求項１０又は上記の（１）に記載のアドレス登録システム。

（３）前記第１の手段は、前記移動装置が前記バルク登録を希望するアドレスを送信元アドレスとする前記個別登録メッセージにより、バルク登録許可を前記移動管理装置に要求し、
前記第３の手段は、前記移動装置が前記バルク登録を許可されたアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１０、上記の（１）及び（２）のいずれか１つに記載のアドレス登録システム。

（４）前記第２の手段は、前記移動管理装置が前記応答メッセージにより代理ノードを移動装置に通知し、
前記第３の手段は、移動装置が前記バルク登録メッセージを前記応答メッセージにより通知された代理ノードに送信し、前記代理ノードが前記バルク登録メッセージに署名して前記移動管理装置に送信することを特徴とする請求項１０に記載のアドレス登録システム。

（５）前記第２の手段は、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスを有するインタフェースの接続するネットワークに応じて前記バルク登録を許可するか否かを決定することを特徴とする請求項１０に記載のアドレス登録システム。

（６）前記第２の手段は、前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、個々の送信元アドレスのバルク登録有効期間を前記移動装置に通知し、
前記第３の手段は、前記移動装置が、前記個々の送信元アドレスのバルク登録有効期間に応じて送信元アドレスを前記個々の送信元アドレス間で変更して前記バルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１０に記載のアドレス登録システム。

（７）前記第２の手段は、前記移動管理装置が前記バルク登録を許可する応答メッセージとして、前記複数の個別登録メッセージの各送信元アドレスの登録を一括して確認するバルク登録確認メッセージを、前記移動装置の複数のインタフェースのいずれかあてに送信することを特徴とする請求項１０、上記の（１）から（６）までのいずれか１つに記載のアドレス登録システム。

（８）前記第２の手段は、前記移動管理装置が前記バルク登録を許可する応答メッセージにより、前記バルク登録メッセージを送信するインタフェースを前記移動装置に指示することを特徴とする請求項１０、上記の（１）、（２）、（４）（５）及び（７）のいずれか１つに記載のアドレス登録システム。

（９）前記個別登録メッセージを受信した場合に、その送信元アドレスがネットワークのイングレス・フィルタリングにより検証されたものとみなして登録するとともに、その送信元アドレスあてに前記バルク登録を許可する応答メッセージを送信することを特徴とする請求項１７に記載の移動管理装置。

（１０）前記応答メッセージによりバルク登録有効期間を前記移動装置に通知することを特徴とする請求項１７又は上記の（９）に記載の移動管理装置。

（１１）前記応答メッセージにより、前記移動装置が前記バルク登録メッセージを送信する代理ノードを前記移動装置に通知することを特徴とする請求項１７又は上記の（９）に記載の移動管理装置。

（１２）前記個別登録メッセージを受信した場合に、その送信元アドレスを有するインタフェースの接続するネットワークに応じて前記バルク登録を許可するか否かを決定することを特徴とする請求項１７に記載の移動管理装置。

（１３）前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、個々の送信元アドレスのバルク登録有効期間を前記移動装置に通知することを特徴とする請求項１７に記載の移動管理装置。

（１４）前記バルク登録を許可する応答メッセージとして、前記複数の個別登録メッセージの各送信元アドレスの登録を一括して確認するバルク登録確認メッセージを、前記移動装置の複数のインタフェースのいずれかあてに送信することを特徴とする請求項１７、及び上記の（９）から（１３）のいずれか１つに記載の移動管理装置。

（１５）前記バルク登録を許可する応答メッセージにより、前記バルク登録メッセージを送信するインタフェースを前記移動装置に指示することを特徴とする請求項１７、及び上記の（９）から（１４）のいずれか１つに記載の移動管理装置。

本発明は、移動装置の複数のインタフェースに関連付けられた各アドレスを、移動装置の移動を管理する移動管理装置に登録する場合に、バルク登録メッセージの送信元アドレス以外のアドレスあてのパケット送信の遅延を防止することができるという効果を有し、３ＧＰＰ−ＬＴＥ（Third Generation Partnership Project Long Term Evolution）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）などに利用することができる。

Claims (17)

1. 移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録方法であって、
   前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１のステップと、
   前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２のステップと、
   前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３のステップとを、
   有するアドレス登録方法。
2. 前記第２のステップは、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスがネットワークのイングレス・フィルタリングにより検証されたものとみなして登録するとともに、その送信元アドレスあてに前記バルク登録を許可する応答メッセージを送信し、
   前記第３のステップは、前記移動装置が前記バルク登録メッセージを送信する場合に、前記バルク登録を許可されたアドレス以外のインタフェースを送信元として前記バルク登録を許可されたアドレスを送信元アドレスフィールド外に含む前記バルク登録メッセージを送信することを特徴とする請求項１に記載のアドレス登録方法。
3. 前記第２のステップは、前記移動管理装置が前記応答メッセージによりバルク登録有効期間を前記移動装置に通知し、
   前記第３のステップは、前記移動装置が前記バルク登録メッセージを前記バルク登録有効期間内に送信することを特徴とする請求項１又は２に記載のアドレス登録方法。
4. 前記第１のステップは、前記移動装置が前記バルク登録を希望するアドレスを送信元アドレスとする前記個別登録メッセージにより、バルク登録許可を前記移動管理装置に要求し、
   前記第３のステップは、前記移動装置が前記バルク登録を許可されたアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１に記載のアドレス登録方法。
5. 前記第２のステップは、前記移動管理装置が前記応答メッセージにより代理ノードを前記移動装置に通知し、
   前記第３のステップは、移動装置が前記バルク登録メッセージを前記応答メッセージにより通知された代理ノードに送信し、前記代理ノードが前記バルク登録メッセージに署名して前記移動管理装置に送信することを特徴とする請求項１に記載のアドレス登録方法。
6. 前記第２のステップは、前記移動管理装置が前記個別登録メッセージを受信した場合に、その送信元アドレスを有するインタフェースの接続するネットワークに応じて前記バルク登録を許可するか否かを決定することを特徴とする請求項１に記載のアドレス登録方法。
7. 前記第２のステップは、前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、個々の送信元アドレスのバルク登録有効期間を前記移動装置に通知し、
   前記第３のステップは、前記移動装置が、前記個々の送信元アドレスのバルク登録有効期間に応じて送信元アドレスを前記個々の送信元アドレス間で変更して前記バルク登録メッセージを送信することを特徴とする請求項１に記載のアドレス登録方法。
8. 前記第２のステップは、前記バルク登録を許可する応答メッセージとして、前記複数の個別登録メッセージの各送信元アドレスの登録を一括して確認するバルク登録確認メッセージを、前記移動装置の複数のインタフェースのいずれかあてに送信することを特徴とする請求項１に記載のアドレス登録方法。
9. 前記第２のステップは、前記移動管理装置が前記バルク登録を許可する応答メッセージにより、前記バルク登録メッセージを送信するインタフェースを前記移動装置に指示することを特徴とする請求項１に記載のアドレス登録方法。
10. 移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムであって、
    前記移動装置が前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する第１の手段と、
    前記移動管理装置が前記複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する第２の手段と、
    前記移動装置が前記応答メッセージを受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する第３の手段とを、
    有するアドレス登録システム。
11. 移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動装置であって、
    前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを前記移動管理装置に送信する手段と、
    前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動管理装置から受信した後に前記複数のアドレスを一括して更新する場合に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信する手段とを、
    有する移動装置。
12. 前記バルク登録メッセージを送信する場合に、前記バルク登録を許可された送信元アドレス以外のインタフェースを送信元アドレスとして、前記バルク登録を許可された送信元アドレスを送信元アドレスフィールド外に含む前記バルク登録メッセージを送信することを特徴とする請求項１１に記載の移動装置。
13. 前記移動管理装置から前記応答メッセージにより通知されたバルク登録有効期間に前記バルク登録メッセージを送信することを特徴とする請求項１１又は１２に記載の移動装置。
14. 前記バルク登録を希望するアドレスを送信元アドレスとする前記個別登録メッセージにより、バルク登録許可を前記移動管理装置に要求し、
    前記バルク登録を許可されたアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１１に記載の移動装置。
15. 前記バルク登録メッセージを前記応答メッセージにより通知された代理ノードに送信することを特徴とする請求項１１に記載の移動装置。
16. 個々の送信元アドレスのバルク登録有効期間に応じて送信元アドレスを前記個々の送信元アドレス間で変更して前記バルク登録メッセージを前記移動管理装置に送信することを特徴とする請求項１１に記載の移動装置。
17. 移動装置の複数のインタフェースに割り当てられた複数のアドレスを前記移動装置の移動管理装置に登録するアドレス登録システムにおける前記移動管理装置であって、
    前記移動装置から、前記複数のインタフェースに関連付けられたアドレスのそれぞれを送信元アドレスとして、前記送信元アドレスを個別に登録するための複数の個別登録メッセージを受信した場合に、その送信元アドレスを登録するとともに、前記複数のアドレスを一括して更新するバルク登録を許可する応答メッセージを前記移動装置に送信する手段と、
    前記応答メッセージを送信した後に、前記複数のインタフェースの１つを送信元として他のインタフェースのアドレスを送信元アドレスフィールド外に含むバルク登録メッセージを前記移動装置から受信した場合に、前記複数のアドレスを一括して更新する手段とを、
    有する移動管理装置。