(57)【要約】  モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させる技術が開示され、その技術によればＭＮ１が、１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージをＣＮ３に送信し、ＣＮ３が、１以上の第１のメッセージを受信して第１及び第２の気付けアドレス用の署名用トークンを生成し、生成した署名用トークンを含む１以上の第２のメッセージをＭＮ２の第２の気付けアドレスあてに送信する。
2009066439.tif 000002
【特許請求の範囲】
【請求項１】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法において、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信するステップと、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証するステップとを、
備えたことを特徴とする通信方法。
【請求項２】
前記モバイルノードが、前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項１に記載の通信方法。
【請求項３】
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項１に記載の通信方法。
【請求項４】
前記相手先の通信ノードが前記バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングし、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項１に記載の通信方法。
【請求項５】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおいて、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えたことを特徴とする通信システム。
【請求項６】
前記モバイルノードが、前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項５に記載の通信システム。
【請求項７】
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項５に記載の通信システム。
【請求項８】
前記相手先の通信ノードが前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングし、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項５に記載の通信システム。
【請求項９】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが１以上割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードから、前記１以上の第１のメッセージに基づき生成された前記第１及び第２の気付けアドレス用の署名用トークンを含む１以上の第２のメッセージを前記第２の気付けアドレスで受信した場合に、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段とを、
備えたモバイルノード。
【請求項１０】
前記第１のメッセージを送信する際に前記第１及び第２の気付けアドレスのペアリングを記憶し、前記第２の気付けアドレスあての前記第２のメッセージを受信した場合に前記記憶されているペアリングから前記第１の気付けアドレスを引き出すことを特徴とする請求項９に記載のモバイルノード。
【請求項１１】
前記第１のメッセージを送信する際に前記第１及び第２の気付けアドレスのペアリングを気付けアドレス用クッキーに埋め込み、前記第２の気付けアドレスあての前記第２のメッセージを受信した場合に前記気付けアドレス用クッキーに埋め込まれているペアリングから前記第１の気付けアドレスを引き出すことを特徴とする請求項９に記載のモバイルノード。
【請求項１２】
前記割り当てられている複数の気付けアドレスが奇数の場合、前記ペアリングにより余る第３の気付けアドレスを、以前にペアリングされた前記第１又は第２の気付アドレスとペアリングすることを特徴とする請求項９に記載のモバイルノード。
【請求項１３】
前記第３の気付けアドレスについては、以前にペアリングされた前記第１又は第２の気付アドレスとグループ化したバルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１２に記載のモバイルノード。
【請求項１４】
前記割り当てられている複数の気付けアドレスが奇数の場合、前記ペアリングにより余る第３の気付けアドレスについてはペアリングすることなく、標準のリターン・ルータビリティ手順を実行することを特徴とする請求項９に記載のモバイルノード。
【請求項１５】
前記第３の気付けアドレスについては、以前にペアリングされた前記第１又は第２の気付アドレスとグループ化したバルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１４に記載のモバイルノード。
【請求項１６】
前記第１の気付けアドレスは、前記モバイルノードが前記相手先の通信ノードに送信する場合にのみに使用する送信用気付けアドレスであり、前記第２の気付けアドレスは、前記モバイルノードが前記相手先の通信ノードから受信する場合にのみに使用する受信用気付けアドレスであることを特徴とする請求項９に記載のモバイルノード。
【請求項１７】
どの気付けアドレスが前記送信用気付けアドレスか又は前記受信用気付けアドレスかを前記バインディング・アップデートメッセージ内に記述することを特徴とする請求項１６に記載のモバイルノード。
【請求項１８】
信頼性の高いネットワークに接続しているインタフェースの気付けアドレスであって、前記相手先の通信ノードまで信頼性が維持されている場合に、その気付けアドレスをペアリングすると決定し、それ以外の場合にペアリングすることなく標準のリターン・ルータビリティ手順を実行することを特徴とする請求項９に記載のモバイルノード。
【請求項１９】
前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２０】
最初の前記第１のメッセージを送信して所定時間経過後までに前記第２のメッセージを受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１９に記載のモバイルノード。
【請求項２１】
最初の前記第１のメッセージを送信して、優先度の高い気付けアドレスの前記第２のメッセージを受信した場合に、受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１９に記載のモバイルノード。
【請求項２２】
前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２３】
最初の前記第１のメッセージを送信して所定時間経過後までに前記第２のメッセージを受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項２２に記載のモバイルノード。
【請求項２４】
最初の前記第１のメッセージを送信して、優先度の高い気付けアドレスの前記第２のメッセージを受信した場合に、受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項２２に記載のモバイルノード。
【請求項２５】
前記相手先の通信ノードにおいてバインディングされている前記気付けアドレスが変化した場合又は新しい気付けアドレスが割り当てられた場合、前記変化した気付けアドレス又は新しい気付けアドレスと、前記相手先の通信ノードにおいてバインディングされている他の前記気付けアドレスを含むバインディング・アップデートメッセージを送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２６】
前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項９に記載のモバイルノード。
【請求項２７】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードの前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスがペアリングされ、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含むよう送信された１以上の第１のメッセージを受信する手段と、
前記受信した１以上の第１のメッセージに基づいて前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードにより、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードが生成され、前記複数の気付けアドレス及び前記１以上の認証コードを含むよう送信された１以上のバインディング・アップデートメッセージを受信する手段と、
前記受信した１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えたことを特徴とする通信ノード。
【請求項２８】
前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成する場合に、前記第１及び第２の気付けアドレスに基づいてそれぞれ第１及び第２の署名用トークンを生成することを特徴とする請求項２７に記載の通信ノード。
【請求項２９】
前記第２のメッセージ内に前記第１の気付けアドレスを記述することを特徴とする請求項２７に記載の通信ノード。
【請求項３０】
前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵が生成され、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードが生成され、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むよう送信されたペアリング・バインディング・アップデートメッセージを受信する手段と、
前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証する手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【請求項３１】
前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵が生成され、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードが生成され、前記複数の気付けアドレス及び前記共通の認証コードを含むよう送信されたバルク・バインディング・アップデートメッセージを受信する手段と、
前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【請求項３２】
前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングする手段と、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むよう送信された前記第１のメッセージを受信する手段と、
前記第１のメッセージに基づいて前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングする手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法、通信システム、モバイルノード及び通信ノードに関する。
【背景技術】
【０００２】
現在、多くのモバイル装置がインタネット・プロトコル（ＩＰ）を用いてお互いに通信を行っている。ＩＰの例としては、ＩＥＴＦ（Internet Engineering Task Force）が下記の非特許文献１に示されるような「ＩＰｖ６におけるモビリティ・サポート」と、下記の非特許文献２に示されるような「ネットワーク・モビリティ・サポート」を提案している。モバイルＩＰでは、各モバイルノードは永久的なホームドメインを有する。このモバイルノードは、自身のホームネットワークに接続すると、ホームアドレス（ＨｏＡ）として知られるプライマリ・グローバルアドレスが割り当てられ、また、自身のホームネットワークの外に移動して他の外部ネットワークに接続すると、気付アドレス（ＣｏＡ）として知られる一時的なグローバルアドレスが割り当てられる。【０００３】
モビリティ・サポートの概念では、モバイルノードがホームネットワークと異なる他の外部ネットワークに接続していても、そのモバイルノードにはホームアドレスで到達することができる。これは、非特許文献１に示されるように、ホームエージェントと呼ばれるエンティティをホームネットワークに導入することにより実現される。モバイルノードは、バインディング・アップデート（ＢＵ）メッセージと呼ばれるメッセージを用いて、自身の気付アドレスをホームエージェントに登録する。この登録により、ホームエージェントはモバイルノードのホームアドレスと気付アドレスとのバインディングを生成する。ホームエージェントはモバイルノードのホームアドレスあてのメッセージをインタセプトして、そのメッセージをカプセル化したパケットをモバイルノードの気付アドレスあてに転送する。ここで、カプセル化とは、あるパケットを新しいパケットのペイロードにセットすることを言い、パケットトンネル化として知られている。【０００４】
しかし、この方法では、モビリティの問題を解決することができるが、準最適化経路が発生する。その理由は、モバイルノードが通信相手（correspondent node：ＣＮ）と通信を行っている場合に両者の間のパケットがホームエージェントを通らなければならないからである。このため、非特許文献１には、モバイルノードがＢＵメッセージをＣＮに送信できることが記載されている。ＣＮはモバイルノードのホームアドレスと気付アドレスとのバインディングを知得すると、両者の間のパケットは、ホームエージェントを通ることなく直接に、モバイルノードの気付アドレスで転送される。これが許されるのは、ＣＮがＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが同一のモバイルノードによって所有されていることを信じることができる場合のみである。これを実現するために、非特許文献１には、ＣＮがＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが本当に同一のモバイルノードによって所有されているかを確認するためのＲＲ（Return Routability）手順が示されている。【０００５】
このＲＲ手順では、モバイルノードがＢＵメッセージをＣＮに送信する前に、セキュアに生成された２つのトークンをＣＮから取得することを必要とする。ＲＲ手順を開始する前に、モバイルノードは最初に、ＣＮに対してＨｏＴｉメッセージとＣｏＴｉメッセージを送信する。ＨｏＴｉメッセージは、モバイルノードのホームアドレスをパケットの送信元アドレスとしてホームエージェントを経由して送信され、ＣｏＴｉメッセージは、モバイルノードの気付アドレスをパケットの送信元アドレスとして直接送信される。ＣＮはＨｏＴｉメッセージを受信するとＨｏＴメッセージで応答する。ＨｏＴメッセージは、モバイルノードのホームアドレスあてに送信され、また、秘密キーを使用してモバイルノードのホームアドレスに基づいて暗号化されたホーム・キージェン・トークン（Home keygen token：ＨｏＫ）と呼ばれるセキュリティ・トークンを含む。また、ＣＮはＣｏＴｉメッセージを受信すると、ＣｏＴメッセージで応答する。ＣｏＴメッセージは、モバイルノードの気付アドレスあてに送信され、また、秘密キーを使用してモバイルノードの気付アドレスに基づいて暗号化されたケアオブ・キージェン・トークン（Care-of keygen token：ＣｏＫ）と呼ばれるセキュリティ・トークンを含む。【０００６】
モバイルノードはＨｏＴメッセージとＣｏＴメッセージの両方を受信すると、ＣＮがモバイルノードを認証するための認証子を含むＢＵメッセージをＣＮに送信することができる。この認証子は、ＨｏＫとＣｏＫを連結したキーを使用して暗号化されたＢＵメッセージのチェックサムである。この方法により、ＣＮはＢＵメッセージを受信すると、ＢＵメッセージ内のチェックサムとは別にチェックサムを計算し、この計算したチェックサムと受信した認証子と同一か否かをチェックして、ＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが本当に同じ位置であるかを証明することができる。【０００７】
ところで、標準のＲＲ手順では、ＣＮは気付アドレス経由でモバイルノードのホームアドレスの到達性（reachability）を証明することができるが、未だ改良の余地がある。特にメッセージの数が増加した場合、例えば非特許文献２及び下記の非特許文献３に示されるようにモバイルノードが複数のインタフェースを有していて複数の気付アドレスを有する場合を考慮すると、この場合には、各気付アドレスについて２つのメッセージ（ＣｏＴｉメッセージとＣｏＴメッセージ）を交換して到達性と有効性を確立する必要がある。【０００８】
また、特許文献１、２、３には、気付アドレスの到達性と有効性を証明する他の方法として、暗号化アドレスをＢＵメッセージに使用する方法が提案されているが、これらの方法では、ＩＰｖ６においては使用可能なビット数が限られているので、暗号化アドレスのセキュリティの強さは疑問である。特に特許文献２は、セキュアなルータ広告（router advertisement）をＢＵメッセージ内に含ませて、ＣＮがこれらのルータ広告内のプリフィックスからアドレスの有効性を引き出すことを開示している。しかしながら、この方法は、現在ではまだ実現が容易ではない、インタネット程度に広範囲の証明システムを必要とする。また、特許文献３は、モバイルノードとＣＮがパブリックキーとプライベートキーを交換して信頼関係を確立することを提案している。しかしながら、この方法では、悪意のあるモバイルノードがＣＮに信頼関係を確立して、ＣＮが気付アドレスにより攻撃されることを防止できない。このため、これを防止するためには、標準のＲＲ手順と同様なメカニズムを採用しなければならない。【０００９】
すなわち、従来技術として、標準のＭＩＰｖ６（非特許文献１）には、ルート最適化時におけるＣＮがＭＮを認証する手段としてＲＲ（Return Routability）手続が開示されている。ＭＩＰｖ６のＲＲは、ＨｏＡテストによる不正なリダイレクションからの保護と、ＣｏＡテストによるリーチャビリティの確認からなる。【００１０】
一方、Ｍｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）では、モバイルノード（ＭＮ）が複数のインタフェースを有する場合のために種々の提案が成されている。また、モバイルＩＰ（Internet Protocol）を利用するＭＮは、移動先のアドレスである気付けアドレス（ＣｏＡ）を、自身のホームアドレス（ＨｏＡ）を管理するホームエージェント（ＨＡ）に登録し、ＨｏＡあてパケットの転送を依頼する。ＭＮが、複数のＣｏＡを１つのＨｏＡに対して同時に関連付けて登録することができれば、複数のインタフェースを備えるＭＮは、それぞれのインタフェースに割り当てられたＣｏＡを登録することで、インタフェースの状態に応じて使用するＣｏＡを瞬時に切り替えることが可能となる。図６は従来のＭｏｎａｍｉ６におけるバルクＢＵ（バインディング・アップデート）を示す説明図である。非特許文献２には、図６に示すようにＭＮ１が複数のＣｏＡを１つのＨｏＡに関連付けてＨＡ２に登録する際に一度にまとめて一つのＢＵを送信する方法（Bulk mCoA BU）する手法が記述されている。ルート最適化（ＲＯ：Route Optimazation）を行う手段（ＣＮに対して複数のＣｏＡを登録すること）については、Ｍｏｎａｍｉ６には、何らの記載はない。
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Wakikawa, R., et al., "Multiple Care-of Addresses Registration", Internet Draft: draft-wakikawa-mobileip-multiplecoa-03.txt, 19 June 2004.
【非特許文献３】Wakikawa, R., et al., "Multiple Care-of Addresses Registration", Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, 12 June 2006.
【特許文献１】[US Patent Application Publication 2003/0211842A1] Kempf, J., et. al., "Securing Binding Update Using Address Based Keys", 13 Nov 2003.
【特許文献２】[US Patent Application Publication 2005/0041634A1] Aura, A. T., "Verifying Location of a Mobile Node", 24 Feb 2005.
【特許文献３】[US Patent Application Publication 2006/0227971A1] Haddad, W., "Secret Authentication Key Setup in Mobile IPv6", 12 Oct 2006.
【００１１】
ところで、ＭＮが複数のＣｏＡをＨＡにバルクＢＵ（バインディング・アップデート）登録するＭｏｎａｍｉ６を、ＣＮがＭＮを認証するＭＩＰｖ６のＲＲ手順に単純に組み合わせ、この組み合わせたＲＲ手順において、ＭＮがＣＮに対して、複数のＣｏＡに関連するバインディング・メッセージを一括して行うバルクＢＵ（ここでは、ＣＮに対する複数ＣｏＡ登録に使用すること）が考えられる。しかしながら、図５に示すようなＭｏｎａｍｉ６のBulk mCoA BUでは、ＭＮ１−ＨＡ２間のセキュリティはＩＰｓｅｃにより保護されているという観点から、さらにバルクＢＵに対する認証を行うという概念がない。これに対し、ＣＮ３がＭＮ１を認証することを目的とするＭＩＰｖ６のＲＲ手順では、ＭＮ１−ＣＮ３間がＩＰＳｅｃでセキュアに保護されている前提を置くことができないため、ＢＵメッセージの内容が異なり、ＲＲ手順におけるＢＵメッセージでは、個々のＣｏＡ毎にバインディング管理キー（Ｋｂｍ）や署名（ＭＡＣ）が必要である（後述）。このため、Ｍｏｎａｍｉ６のＨＡあてのバルクＢＵをＭＮ１−ＣＮ３間のＲＲ手順に適用することができず、ＭＮ１−ＣＮ３間のＲＲ手順におけるＢＵメッセージは個々のＣｏＡ毎にＣＮあてに送る必要がある。【００１２】
図６はこの場合の動作、すなわち本発明が解決しようとする課題を示し、この図を参照しながらＭＩＰｖ６のＲＲ手順を説明する。まず、
（１）ＭＮ１はＨｏＡ、ＣｏＡ毎のクッキーを生成して、ＣＮ３あてのＨｏＴＩ（Home-Test-Init）メッセージをＨＡ２あてにカプセル化してホームネットワーク４及び外部ネットワーク５ａ経由で送信するとともに、複数（ｎ個）のＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのＣｏＴｉ（Care-of-Test-Init）[1]〜[n]メッセージを個別に外部ネットワーク５ａ、５ｂ経由でＨＡ２を介することなく直接ＣＮ３へ送信することにより、ＨｏＡ、および各ＣｏＡのクッキーをＣＮ３に送信する。
（２）ＣＮ３はこれに応答して、各クッキーなどからＨｏＡ、ＣｏＡ[1]〜[n]毎の署名用トークンを生成して、ＨＡ２経由のＭＮ１あてのＨｏＴ（Home-Test）メッセージを送信するとともに、ＣｏＡ[1]〜[n]についての直接ＭＮ１あてのＣｏＴ（Care-of-Test）[1]〜[n]メッセージを送信することにより署名用トークンを送信する。【００１３】
（３）次いで、ＭＮ１はこれに応答して、各署名用トークンなどからＣｏＡ[1]〜[n]毎のバインディング管理キーＫｂｍ[1]〜[n]を生成してそれぞれのメッセージ認証コードＭＡＣ[1]〜[n]（ＭＡＣ：Message Authentification Code）を生成し、ＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのバインディング・アップデート・メッセージＢＵ[1]〜[n]を個々に送信することにより、Ｋｂｍ[1]〜[n]及びＭＡＣ[1]〜[n]を送信する。ＣＮ３はＭＮ１とは別個に、かつＭＮ１と同様にＭＡＣ[1]〜[n]などを生成し、ＢＵ[1]〜[n]メッセージを認証する。
（４）オプションとして、ＣＮ３はＢＵ[1]〜[n]メッセージに応答してバインディング確認メッセージＢＡ[1]〜[n]を送信してもよい。つまり、ＭＩＰｖ６のＲＲ手順を複数のＣｏＡ登録に使用するためには，単にＢＵメッセージの宛先がＨＡであるかＣＮであるかの差異だけでなく、セキュリティ上のＭＮとの関係の際に起因する複数の手順に関する差異を考慮しなければならない。このため、（１）〜（３）では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴ、ＢＵの各メッセージを送信するので、非常に多く（３ｎ個）のメッセージを送信する必要があるという問題点がある。
【発明の開示】
【００１４】
本発明は上記の問題点に鑑み、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる通信方法、通信システム、モバイルノード及び通信ノードを提供することを目的とする。
【００１５】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法において、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信するステップと、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証するステップとを、
備えた。
【００１６】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおいて、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えた。
【００１７】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが１以上割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードから、前記１以上の第１のメッセージに基づき生成された前記第１及び第２の気付けアドレス用の署名用トークンを含む１以上の第２のメッセージを前記第２の気付けアドレスで受信した場合に、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段とを、
備えた。
【００１８】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードにより、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスがペアリングされ、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含むよう送信された１以上の第１のメッセージを受信する手段と、
前記受信した１以上の第１のメッセージに基づいて前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードにより、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードが生成され、前記複数の気付けアドレス及び前記１以上の認証コードを含むよう送信された１以上のバインディング・アップデートメッセージを受信する手段と、
前記受信した１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えた。
【００１９】
この構成により、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
【００２０】
本発明によれば、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施の形態の通信シーケンスを示す説明図
【図２】本発明の一実施の形態の他の通信シーケンスを示す説明図
【図３】本発明の一実施の形態のさらに他の通信シーケンスを示す説明図
【図４】図１、図２及び図３におけるモバイルノードと通信相手の構成を機能的に示すブロック図
【図５】従来のＭｏｎａｍｉ６におけるバルクＢＵを示す説明図
【図６】本発明が解決しようとする課題を示す説明図
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して本発明の実施の形態について説明する。
＜複数のＣｏＡをペアリング＞
この実施の形態では、モバイルノードとＣＮはともに、高い信頼関係のネットワーク構成内に位置していて、ＣＮが特定の送信元アドレスのパケットを受け取る場合に、その特定の送信元アドレスが存在（実在）し（到達でき）、そのパケットが本当にその特定の送信元アドレスから来たことが保証されているものとする。これは、通常のネットワークにおけるパケット転送保証であって、実在する送信元アドレスあてのパケットは転送され、実在しない送信元アドレスあてのパケットは破棄される。このような高い信頼関係のネットワークは、多くの方法で実現可能である。例えばネットワーク内の各ルータは、イングレス・フィルタリングを実行して、あるインタフェースでは受信すべきでない送信元アドレスのパケットをそのインタフェースでインタセプトしたときにはそのパケットを破棄する。このように、そのルータで構築されるネットワーク構成は、転送されてきたパケットの送信元アドレスが存在し、有効であることを保証することができる。この高い信頼関係のネットワーク構成の例としては、セルラ・オペレータやその関連するＷＬＡＮ（ワイヤレスＬＡＮ）に採用されている第３世代オールＩＰネットワークがある。【００２３】
このタイプのネットワークに対しては、１つのＣｏＴｉメッセージと１つのＣｏＴメッセージを用いて、１つの気付アドレスの到達性と有効性を証明すると、過剰なメッセージ数となる。その理由は、あるアドレスの到達性（転送保証）が確保できれば、そのアドレスの有効性（送信元アドレスの有効性）は確保されるからである。このため、この実施の形態では、複数の気付アドレスを１対の気付アドレス毎に分割（ペアリング）し、ＣｏＴｉメッセージがある第１の気付アドレスから送信されると、そのＣｏＴｉメッセージに対応するＣｏＴメッセージを、第１の気付アドレスと異なる第２の気付アドレスあてに送信する。【００２４】
図１は一実施の形態の通信シーケンスを示す。図１では、説明を簡略化するために、ＭＮ１は４つのインタフェース１１、１２、１３、１４を有し、インタフェース１１、１２、１３、１４にそれぞれ気付アドレスとしてＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４が割り当てられている。なお、当業者であれば、さらに多くの気付アドレスにも適用することができることは明白である。【００２５】
（１）ＣｏＴｉ（ＨｏＴｉ）
図１において、まず、標準のＲＲ手順に従って、ＭＮ１はＣＮ３に対し、ＨｏＴｉメッセージ８１０と、ＣｏＡ１、ＣｏＡ２をペアリングしたＣｏＴｉ[1]メッセージ８２１と、ＣｏＡ３、ＣｏＡ４をペアリングしたＣｏＴｉ[2]メッセージ８２２を送信する。ＨｏＴｉメッセージ８１０は、ＭＮ１のホームエージェントであるＨＡ２あてにトンネル化され、さらにＣＮ３に転送される。【００２６】
（２）ＣｏＴ（ＨｏＴ）
次に、ＣＮ３は標準のＲＲ手順に従って、ＨｏＴｉメッセージ８１０に対してＨｏＴメッセージ８３０で応答する。ＣｏＴｉ[1]メッセージ８２１の送信元アドレスはＭＮ１のＣｏＡ１である。ここで、通常のＲＲ手順では、ＣＮ３はＣｏＴｉ[1]メッセージ８２１を受信すると、ＣｏＡ１に対応する署名用トークンであるＣｏＫを生成してＣｏＡ１あてにＣｏＴメッセージを送信する。これに対し、この実施の形態では、ＭＮ１はモビリティヘッダ・オプションを用いて、ＣｏＴｉ[1]メッセージ８２１内にＣｏＡ２を記述する。そこで、ＣＮ３はＣｏＡ１、ＣｏＡ２の両方に対応するＣｏＫを生成して、ＣｏＡ１の代わりにＣｏＡ２あてにＣｏＴ[1]メッセージ８４１を送信する。同様に、ＣｏＴｉ[2]メッセージ８２２の送信元アドレスはＭＮ１のＣｏＡ３であり、ＭＮ１はモビリティヘッダ・オプションを用いて、ＣｏＴｉ[2]メッセージ８２２内にＣｏＡ４を記述する。そこで、ＣＮ３はＣｏＡ３、ＣｏＡ４の両方に対応するＣｏＫを生成して、ＣｏＡ４あてにＣｏＴ[2]メッセージ８４２を送信する。【００２７】
（３）ペアリングＢＵ
本発明においてはペアリングした２つのＣｏＡを効率的にＣＮに対して登録するために、ＢＵメッセージを送る際にもこれらをまとめて送信するペアリングＢＵという概念を用いる。複数のＣｏＡをまとめて登録すると言う点ではＣＮへのバルクＢＵと類似しているが、ペアリングに起因する鍵情報の扱い方や、認証情報の生成方法などは、後述のように変更する必要がある。また、本明細書では、より望ましい実施の方法としてペアリングが複数ある場合に、ペアリングＢＵを更にまとめてバルクＢＵしている例について説明している。なお、ペアリングＢＵ及び、ペアリングＢＵのバルクＢＵを用いる代わりに全て個別のＢＵメッセージを用いることも可能である。
ＭＮ１はＨｏＴメッセージ８３０と、ＣｏＴ[1]メッセージ８４１とＣｏＴ[2]メッセージ８４２を集合して、ペアリングＢＵメッセージ８５０をＣＮ３に送信することによりＣＮへの複数ＣｏＡ登録を行う。ペアリングＢＵメッセージ８５０はモビリティヘッダ・サブオプションとしてバインディングＩＤサブオプションを含み、すべてのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４のＣＮ３への複数ＣｏＡ登録を行う。ペアリングＢＵメッセージ８５０内の認証子は、以下のようにＣｏＴ[1]メッセージ８４１と、ＣｏＴ[2]メッセージ８４２とＨｏＴメッセージ８３０から引き出したパラメータに基づいて生成される。【００２８】
以下に、図１中のメッセージ内に含まれるパラメータの詳細を例示する。
＜ＨｏＴｉ＞
ＨｏＴｉメッセージ８１０は以下のパラメータを含む。
・送信元アドレス：ＭＮ１のホームアドレス
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Home Init Cookie
Home Init Cookieは、ＨｏＴｉメッセージに対応して、有効なＣＮからＨｏＴメッセージが送られたことを確保するために、ＭＮ１が生成した値である。【００２９】
＜ＨｏＴ＞
ＨｏＴｉメッセージ８１０に対応してＣＮ３から送られたＨｏＴメッセージ８３０は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＭＮ１のホームアドレス
・モビリティヘッダ
・Home Init Cookie
・Home Keygen Token（ＨｏＫ）
・Home Nonce Index【００３０】
Home Init Cookieは、ＨｏＴｉメッセージ８１０内の値と同じである。ＨｏＫは、ＭＮ１のホームアドレス（ＨｏＡ）と、ＣＮ３のみが知得している秘密のHome Nonce Indexに基づいて暗号化されて生成される。ＨｏＫは、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ｜nonce｜０））
但し、ＨＭＡＣ＿ＳＨＡ１（Ｋcn，ｍ）は、ＳＨＡ１ハッシュ・アルゴリズムにメッセージｍと秘密キーＫcnを用いて計算したメッセージ認証コード（ＭＡＣ）の関数、０は８ビットで値が０、｜は連結を表す。【００３１】
Home Nonce Indexは、ＨｏＫを生成するために使用する秘密ノンス値と一致するかを判定するためにＣＮ３が使用する。例えばＣＮ３は、６４個の異なるノンス値のアレイを有し、Nonce Index＝０はノンス値アレイの最初のノンス値と一致するかを判定し、Nonce Index＝１はノンス値アレイの最初の２番目のノンス値と一致するかを判定するというように使用する。【００３２】
＜ＣｏＴｉ[1]＞
ＣｏＴｉ[1]メッセージ８２１は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ１
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Care-of Init Cookie [1]
・追加のＣｏＡ２【００３３】
＜ＣｏＴｉ[2]＞
ＣｏＴｉ[2]メッセージ８２２は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ３
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Care-of Init Cookie [2]
・追加のＣｏＡ４【００３４】
Care-of Init Cookie は、ＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２にそれぞれ対応するＣｏＴメッセージ８４１、８４２が有効なＣＮ３から送られたことを確保するためにＭＮ１が生成した値である。ＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２におけるそれぞれの「追加のＣｏＡ２、ＣｏＡ４」は、この実施の形態において追加したＣｏＡである。【００３５】
ＣｏＴｉ[1]メッセージ８２１に応答してＣＮ３が送信するＣｏＴ[1]メッセージ８４１は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ） [1]
・Care-of Nonce Index [1]【００３６】
同様に、ＣｏＴｉ[2]メッセージ８２２に応答してＣＮ３が送信するＣｏＴ[2]メッセージ８４２は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ４
・モビリティヘッダ
・Care-of Init Cookie [2]
・Care-of Keygen Token（Ｃｏｋ）[2]
・Care-of Nonce Index [2]【００３７】
Care-of Init Cookie [1]、[2]はそれぞれ、対応するＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２内のものと同じである。Ｃｏｋ [1]、[2]はそれぞれ、ＭＮ１の両方の気付アドレス（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）と、ＣＮ３のみが知得している秘密ノンス値に基づいて暗号化されて生成されている。Ｃｏｋ [1]は以下のハッシュ値の最初の６４ビットであり、
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜ＣｏＡ２｜nonce｜１））
また、Ｃｏｋ [2]は以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ３｜ＣｏＡ４｜nonce｜１））
但し、「１」は、Ｃｏｋ [1]、[2]をＨｏＫと区別するためであって、８ビットで値が１である。ここで、当業者であれば、「１」は、標準のＲＲ手順で生成される通常のＣｏｋとＣｏｋ [1]、[2]を区別するために、他の８ビット、例えば「２」でもよい。Care-of Nonce Index [1]、[2]はそれぞれ、Ｃｏｋ [1]、[2]を生成するための使用する秘密ノンスを判別するためにＣＮ３が使用する。【００３８】
＜ペアリングＢＵ＞
ペアリングＢＵメッセージ８５０は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ１
・あて先アドレス：ＣＮ３のアドレス
・ホームアドレスあて先オプション
・ＭＮ１のホームアドレス
・モビリティヘッダ
・シーケンス番号
・Home Nonce Index
・Care-of Nonce Index [1]
・ＣｏＡ１、ＣｏＡ２のバインディング・ユニーク識別子サブオプション
・Care-of Nonce Index [2]
・ＣｏＡ３、ＣｏＡ４のバインディング・ユニーク識別子サブオプション
・認証子【００３９】
Home Nonce IndexとCare-of Nonce Index [1]、[2]はそれぞれ、ＣＮ３に対してどのノンス値がＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]を生成するのに使用されたかを通知するために、ＨｏＴメッセージ８３０、ＣｏＴ[1]メッセージ８４１、ＣｏＴ[2]メッセージ８４２内の値と同じである。バインディング・ユニーク識別子サブオプションは、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４を含み、それぞれユニークなバインディング識別子である。認証子は、ＨｏＴメッセージ８３０、ＣｏＴ[1]メッセージ８４１、ＣｏＴ[2]メッセージ８４２内のＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]と、モビリティヘッダそのものに基づいて暗号化して生成したものである。ここで、ＣＮ３は、ホームアドレスと、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４と、Home Nonce Indexと、Care-of Nonce Index [1]、[2]を知得しているので、ＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]を再現できる。【００４０】
認証子は、すべてのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４に対して共通の認証子であって、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ１｜ＣｏＡ２｜ＣｏＡ３｜ＣｏＡ４｜ＣＮアドレス｜ＭＨ））
但し、Ｋbmは、ＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]のハッシュ値から生成したバインディング管理キーであって、
Ｋbm＝ＳＨＡ１（ＨｏＫ｜Ｃｏｋ[1]｜Ｃｏｋ[2]）
である。ＣＮアドレスはＣＮ３のアドレスであり、ＭＨは、認証子の値で０にセットされるモビリティヘッダである。【００４１】
認証子の値は、ＣＮ３がペアリングＢＵメッセージ８５０内の情報を用いて独立して生成して証明することができる。ここで、注意すべき点は、ペアリングＢＵメッセージ８５０内には、Care-of Nonce Index [1]、 [2]と、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡのバインディング・ユニーク識別子サブオプションは、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４とその対応するノンスがグループ化されるように配列することが望ましいことである。また、４つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４の順番は、認証子を生成する際、バインディング・ユニーク識別子サブオプションの順番に従って引き出すことができることが望ましい。【００４２】
ここで、当業者であれば、ペアリングＢＵメッセージ８５０の送信元アドレスは、４つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４のいずれか１つを用いてもよいことは明らかである。また、上記説明では、１対の（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）に対して１つのＣｏＫを用いているが、この利点は、ＭＮ１とＣＮ３にとって必要な帯域と処理時間を短縮することができることにある。しかし、１対の（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）の１つが変更されたときには、ＣｏＫも変更されるので、両方のＣｏＡを登録する必要がある。例えばインタフェース１２、１３のハンドオーバによりＣｏＡ２、ＣｏＡ３が変更されると、ＣｏＡ１、ＣｏＡ４が変更されなくても、ＭＮ１はＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２の両方を再送信して、ＣｏＡ１、ＣｏＡ４の新しいＣｏＫを取得しなければならない。【００４３】
<<１つのＣｏＡに１つのＣｏＫ>>
ＣＮ３は１つのＣｏＡに対して１つのＣｏＫを生成して、同じＣｏＴメッセージ内に配置することも可能である。この場合、ＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ） [1a]
・Care-of Keygen Token（Ｃｏｋ） [1b]
・Care-of Nonce Index [1]【００４４】
Ｃｏｋ [1a]は、ＣｏＡ１（＝ＣｏＴｉ[1]メッセージ８２１の送信元アドレス）を用いて生成され、Ｃｏｋ [1b]は、ＣｏＡ２（＝ＣｏＴ[1]メッセージ８４１のあて先アドレス）を用いて生成される。すなわち、Ｃｏｋ [1a]は、以下のハッシュ値の最初の６４ビットであり、
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜nonce｜１））
Ｃｏｋ [1b]は、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ２｜nonce｜１））
２つのＣｏｋ [1a]、Ｃｏｋ [1b]は、この例では同じCare-of Nonce を使用し、また、ＭＮ１は、出現順に、ＣｏＡ１に対してＣｏｋ [1a]を、ＣｏＡ２に対してＣｏｋ [1b]を並べて配置する。【００４５】
各ＣｏＡに対して独立したＣｏｋを使用することにより、ＭＮ１は次の登録を実行するときに柔軟に対応することができる。例えば前述したようにインタフェース１２、１３のハンドオーバによりＣｏＡ２、ＣｏＡ３が変更される場合について説明すると、この場合には、ＭＮ１はＣｏＡ２、ＣｏＡ３を再ペアリングして１つのＣｏＴｉメッセージのみを送信すればよい。このＣｏＴｉメッセージは、新しいＣｏＡ２から送信され、また、ＣｏＡ３を追加のＣｏＡとして記述する。ＣＮ３はこれに応答して、ＣｏＡ２のＣｏｋとＣｏＡ３のＣｏｋを含むＣｏＴメッセージをＣｏＡ３あてに送信する。また、この方法は、ペアリングＢＵの代わりに個別のＢＵメッセージで登録を行なう場合にもより適していると言える。【００４６】
<<１つのＣｏＡに１つのCare-of Nonce>>
当業者であれば、他の変形例も可能であることは明らかである。例えば暗号化力を増大させるために、ＣＮ３は、１つのＣｏＴメッセージ内で個々のＣｏＡに対してそれぞれ異なるCare-of Nonceを使用することを選択してもよい。この場合、ＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ） [1a]
・Care-of Keygen Token（Ｃｏｋ） [1b]
・Care-of Nonce Index [1a]
・Care-of Nonce Index [1b]
ＭＮ１は、出現順に、ＣｏＡ１に対してＣｏｋ [1a]とCare-of Nonce Index [1a]を、ＣｏＡ２に対してＣｏｋ [1b]とCare-of Nonce Index [1b]を並べて配置する。【００４７】
<<メモリから第１のＣｏＡを引き出す>>
上記の説明では、ＣｏＴメッセージ８４１、８４２は、２つのＣｏＡに対して１つ又は２つのCare-of Keygen Tokenを含むが、変形例として１つのＣｏＡのみをＣｏＴメッセージ８４１、８４２内に記述する。ＭＮ１は望ましくは、ペアリングした２つのＣｏＡを記憶して、ＣｏＴメッセージ８４１、８４２に記述されていない他方のＣｏＡを引き出すことができる。例えばＭＮ１は、ＣｏＴｉ[1]メッセージ８２１を送信するときに、メモリ内にＣｏＡ１、ＣｏＡ２とCare-of Init Cookie [1]をストアすることができる。したがって、ＭＮ１は、ＣｏＴ[1]メッセージ８４１を受信すると、ＣｏＴ[1]メッセージ８４１内のCare-of Init Cookie [1]に基づいてメモリを参照することにより、ＣｏＴ[1]メッセージ８４１がＣｏＡ２のみを記述していても、ＣｏＴ[1]メッセージ８４１に関連するＣｏＡ１、ＣｏＡ２の両方を知得することができる。【００４８】
<<Care-of Init Cookieから第１のＣｏＡを引き出す>>
上記のようにメモリ内にＣｏＡ１、ＣｏＡ２とCare-of Init Cookie [1]などをストアする方法では、ＭＮ１はＲＲ手順に関するステート情報を維持するために多くのメモリ容量を必要とする不具合がある。そこで、変形例として、ハッシュ関数などを用いてＣｏＡ１、ＣｏＡ２をCare-of Init Cookie [1]に埋め込む。この方法によれば、ＭＮ１はCare-of Init Cookie [1]とは別のエリアにストアされているＣｏＡ１、ＣｏＡ２を参照することなく、ＣｏＡ１、ＣｏＡ２を引き出すことができる。【００４９】
<<ＣｏＴ内に第１のＣｏＡを記述>>
ＣＮ３にとって他の望ましい方法は、ＣｏＴメッセージ８４１、８４２内に他方のＣｏＡを記述することである。この方法におけるＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ） [1b]
・Care-of Nonce Index [1b]
・追加のＣｏＡ：ＣｏＡ２
・Care-of Keygen Token（Ｃｏｋ） [1a]
・Care-of Nonce Index [1a]【００５０】
この方法によれば、ＭＮ１は両方のＣｏＡに対して特別にアプローチしたり、メモリにストアすることなく両方のＣｏＡを引き出したりすることができる。但し、ＭＮ１はメモリには、Care-of Init CookieをＣｏＡとＣＮ３のアドレスとともに記録するステートをストアする必要がある。この方法により、ＭＮ１は、受信したＣｏＴメッセージの有効性をチェックすることができ、また、攻撃者が偽のＣｏＴメッセージをＭＮ１に送ることにより曝されるセキュリティ上のリスクから避けることができる。【００５１】
<<ＣｏＡの数が奇数>>
上記では、ＣｏＴｉメッセージ及びＣｏＴメッセージに対して異なるＣｏＡを使用することにより、ＢＵ登録に必要なメッセージ数を減少できるかを説明した。すなわち、上記説明では、ＣｏＴｉメッセージ及びＣｏＴメッセージを交換する際に２つのＣｏＡをペアリングしている。このため、ＣｏＡの数が奇数の場合、ペアリングする相手がない１つのＣｏＡが余る。この状態を取り扱う１つの方法として、余りの１つのＣｏＡを、以前に使用したＣｏＡとペアリングする。また、他の方法として、最後の１つのＣｏＡについては標準のＲＲ手順を使用し、ＣｏＴｉメッセージの送信元アドレスとＣｏＴメッセージのあて先アドレスを最後の１つのＣｏＡとする。【００５２】
さらに他の方法として、余りの１つのＣｏＡを、他の１対のＣｏＡとグループ化する。この方法では、基本的には余りの１つのＣｏＡの有効性と到達性を証明するためにペアリングＢＵメッセージを使用する。この方法によるシーケンスを図２に示す。図２では、説明を簡略化するために、ＭＮ１はインタフェース１１、１２、１３にそれぞれ割り当てられた３つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３を有する。当業者であれば、他の奇数のＣｏＡを取り扱う場合には、前述したペアリング方法と組み合わせることにより対応することができることは明らかである。【００５３】
まず、標準のＲＲ手順に従って、ＭＮ１はＨｏＴｉメッセージ９１０とＣｏＴｉメッセージ９２０をＣＮ３に送信する。ＨｏＴｉメッセージ９１０はＭＮ１のホームエージェントであるＨＡ２あてにトンネル化されて送信され、さらにＣＮ３に転送される。ＣＮ３は標準のＲＲ手順に従って、ＨｏＴｉメッセージ９１０に対してＨｏＴメッセージ９３０で応答する。ＣｏＴｉメッセージ９２０の送信元アドレスはＭＮ１のＣｏＡ１である。ここで、通常のＲＲ手順では、ＣＮ３はＣｏＴｉメッセージ９２０を受信すると、ＣｏＡ１に対応するＣｏＫを生成してＣｏＴメッセージをＣｏＡ１あてに送信するが、本実施の形態では、ＭＮ１はＨｏＴｉメッセージ９１０内の追加のモビリティヘッダ・オプションにより、ＣｏＡ２及びＣｏＡ３を指示する。そこで、ＣＮ３はＣｏＴｉメッセージ９２０を受信すると、ＣｏＡ１、ＣｏＡ２及びＣｏＡ３に対応するＣｏＫを生成してＣｏＴメッセージ９４０をＣｏＡ２あてに送信する。【００５４】
ＭＮ１はＨｏＴメッセージ９３０とＣｏＴメッセージ９４０を集めて、ペアリングＢＵメッセージ９５０をＣＮ３に送信することにより登録を完了する。ＣＮ３がＣｏＡ３の到達性と有効性を証明するために、ペアリングＢＵメッセージ９５０はＣｏＡ３を送信元アドレスとして送信される。ここで、前提として説明したように、この手順は、送信元アドレスがＣｏＡ３であるパケットを受信したということは、ＣｏＡ３が有効であって到達できることを意味するほど高い信頼性のネットワークに用いられる。ペアリングＢＵメッセージ９５０はＣｏＡ１、ＣｏＡ２及びＣｏＡ３のＣＮへの複数ＣｏＡ登録を完了するためのモビリティヘッダ・サブオプション（例えばバインディング・ユニーク識別子サブオプション）を含む。ペアリングＢＵメッセージ９５０内の認証子の値は、ＨｏＴメッセージ９３０とＣｏＴメッセージ９４０から引き出したパラメータに基づいて生成される。【００５５】
ここで、当業者であれば、ＣｏＫと認証子の計算は、前述した方法に第３のＣｏＡ３を追加した方法で可能であることを容易に理解できる。同様に、各ＣｏＡに対して独立したＣｏＫと、各ＣｏＡに対して独立したCare-of Nonceを用いた変形を適用することができる。さらに、ＣｏＡ１、ＣｏＡ３を含むＣｏＴｉメッセージを送信して、ＣｏＴメッセージをＣｏＡ２あてに送信してもよい。この説明は当業者にとって明白であるので、その詳細な説明は省略する。【００５６】
<<送信ＣｏＡと受信ＣｏＡ>>
図１、図２に示した実施の形態は、高信頼性ネットワークに適用する場合を説明したが、他のネットワークにも適用することができる。一例として、ＭＮがＣＮと通信を行う際に複数の異なるＣｏＡを異なる目的で使用する場合がある。例えばロード・バランシングの目的で、ある複数のＣｏＡを１セットとしてアップリンク（送信用）・トラフィックに使用し、他のある複数のＣｏＡを１セットとしてダウンリンク（受信用）・トラフィックに使用する場合が想定される。この想定例では、ある複数のＣｏＡがＭＮからＣＮへのパケット送信のみに使用され、他のある複数のＣｏＡがＣＮからＭＮへのパケット送信のみに使用される。この場合には、各ＣｏＡの到達性と有効性を標準のＲＲ手順を用いて証明する必要はない。【００５７】
したがって、ＭＮがある複数のＣｏＡを１セットとして送信のみに使用するので、これらの複数のＣｏＡ（以下、「アップリンクＣｏＡ」と言う。）は到達性をテストする必要はなく、有効性のみをテストすればよい。同様に、ＭＮが他のある複数のＣｏＡを１セットとして受信のみに使用するので、これらの複数のＣｏＡ（以下、「ダウンリンクＣｏＡ」と言う。）は有効性をテストする必要はなく、到達性のみをテストすればよい。なお、どのＣｏＡをアップリングＣｏＡあるいはダウンリンクＣｏＡとするかをＭＮからＣＮへ確認メッセージにより確認するようにしても良い。【００５８】
上記の高信頼性ネットワークに使用する方法をこの場合にも適用することができる。図１に示すシーケンス図を参照して一例を説明する。ここでは、ＣｏＡ１とＣｏＡ３をアップリンクＣｏＡ、また、ＣｏＡ２とＣｏＡ４をダウンリンクＣｏＡと仮定する。当業者であれば、図１に示すＲＲ手順を使用できることは明らかである。ＣｏＡ１、ＣｏＡ３は、ＣｏＴｉメッセージ８２１、８２２がそれぞれＣｏＡ１、ＣｏＡ３を送信元アドレスとして送信されるので、有効性がテストされる。ここで、ＭＮ１はＣｏＴｉ[1]メッセージ８２１にはダウンリンクＣｏＡ２を記述し、また、ＣｏＴｉ[2]メッセージ８２２にはダウンリンクＣｏＡ４を記述する。したがって、ＣｏＴ[1]メッセージ８４１はＣｏＡ２あてに送信されてＣｏＡ２の到達性がテストされ、また、ＣｏＴ[2]メッセージ８４２はＣｏＡ４あてに送信されてＣｏＡ４の到達性がテストされる。最後にペアリングＢＵメッセージ８５０が送信されて複数のＣｏＡ１〜ＣｏＡ４のＣＮへの複数ＣｏＡ登録が完了する。ペアリングＢＵメッセージ８５０は当然に、アップリンクＣｏＡを送信元アドレスとして送信される。【００５９】
悪意のある（あるいは誤った動作をする）任意のノード（モバイルノードも含む）がアップリンクＣｏＡをダウンリンク・トラフィックに、また、ダウンリンクＣｏＡをアップリンク・トラフィックに使用しようとする場合への対応方法として、ＭＮ１はペアリングＢＵメッセージ８５０内に、どのＣｏＡがアップリンクＣｏＡか、どのＣｏＡがダウンリンクＣｏＡかを明示することが望ましい。これは、例えば各ＣｏＡに関するバインディング・ユニーク識別子サブオプション内にフラグを使用することにより実現することができる。これにより、ペアリングＢＵメッセージ８５０を受け取ったＣＮ３は、アップリンクＣｏＡとダウンリンクＣｏＡを区別して管理する際の識別が簡単になり、実施したテストに対してＢＵメッセージ内のＣｏＡの使用方法が不整合であれば登録を拒絶したり、登録後であっても実際の使用方法が不整合である場合は、実際の通信を拒絶したり、ＣｏＡの使用方法が不整合である旨を通知したりできる。なお、別の方法として、ＣＮ３が、テストメッセージを送信する際に、後にＢＵメッセージで受け取るＣｏＡがアップリンクＣｏＡであるかダウンリンクＣｏＡであるかを識別できるように情報を付加したり、ＣｏＡの使用方法を記録したりしておいても良い。すなわち、ＣＮ３が、ＣｏＴｉメッセージ及びＣｏＴメッセージの送受信時に確認するＣｏＡ（の使用方法＝安全な使用が保証されている内容）と、モバイルノード１によるＢＵでのＣｏＡの申請もしくは実際の使用方法に矛盾がないことを確認できるようにすることが望ましい。【００６０】
さらなる対抗策として、ＣＮ３はアップリンクＣｏＡ及びダウンリンクＣｏＡの対に対するＣｏＫを生成する際に特定の順番を使用する。ＣｏＡ１をアップリンクＣｏＡ、ＣｏＡ２をダウンリンクＣｏＡとする場合を例に説明すると、ＣＮ３がＣｏＴ[1]メッセージ８４１内に含ませるＣｏＫを生成する場合に、このＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜ＣｏＡ２｜nonce｜１））
すなわち、アップリンクＣｏＡ１は常に、ダウンリンクＣｏＡ２の前に配置される。【００６１】
さらに、各ＣｏＡに対して異なるＣｏＫを生成する際に、ＣＮ３はハッシュ計算において異なる８ビットを使用する。この場合、アップリンクＣｏＡ１に対するＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜nonce｜３））
また、ダウンリンクＣｏＡ２に対するＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ２｜nonce｜４））【００６２】
ここで、８ビット値「３」、「４」は、アップリンクＣｏＡ１をダウンリンクＣｏＡ２と区別するために使用される。当業者であれば、アップリンクＣｏＡに対するＣｏＫをダウンリンクＣｏＡに対するＣｏＫと区別できれば、他の８ビット値でもよいことは明らかである。【００６３】
さらなる対抗策として、ＣＮ３はアップリンクＣｏＡとダウンリンクＣｏＡに対して異なるノンス値を使用してもよい。例えば特定のノンス・インデックス＝１に対して、ＣｏＡがアップリンクＣｏＡか、ダウンリンクＣｏＡか、通常のＣｏＡかに応じて異なるノンス・インデックスを使用する。ここで、通常のＣｏＡに対しては、標準のＲＲ手順に従って到達性と有効性の両方がテストされる。【００６４】
<<ＣｏＴの喪失>>
上記の実施の形態では、ペアリングＢＵメッセージ８５０はすべてのＣｏＡを登録すること（バルクＢＵすること）を仮定しているが、当業者であれば、必ずしも必要はないことは理解できる。例えばあるＣｏＴｉメッセージまたはＣｏＴメッセージがネットワークの輻輳のために破棄された場合、ＭＮ１はＣｏＴメッセージを受信しない。この場合、ＭＮ１はペアリングＢＵメッセージ８５０による登録を継続することを選択してもよい。これを実現する方法の１つとして、ＭＮ１はＲＲ手順を最初に開始した時にタイマをセットアップし、タイマが満了すると、ＭＮ１はそれまでに受信したＣｏＴメッセージに対するペアリングＢＵメッセージ８５０を送信する。その後に受信したＣｏＴメッセージに対しては、さらにＢＵメッセージまたはペアリングＢＵメッセージ８５０を送信することができる。もちろん、ペアリングＢＵメッセージ８５０を送信する前に、ＨｏＴメッセージ８３０は受信済みでなければならない。【００６５】
他の方法として、ＭＮ１はタイマの満了を待つことなく、ＨｏＴメッセージ８３０を受信すると、できるだけ早くペアリングＢＵメッセージ８５０を送信する。ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換は、ＭＮ１とＨＡ２の間では双方向トンネルを通らなければならないため、ＣｏＴｉメッセージ８２１、８２２とＣｏＴメッセージ８４１、８４２の交換より長くなるので、この方法はうまく動作する。したがって、通常では、ＭＮ１はＨｏＴメッセージ８３０を受信するまでに、ＣｏＴメッセージ８４１、８４２のうち、すべてではなくとも幾つかは受信する。ＭＮ１が複数のＣｏＡに対してプレファレンスが割り当てられている場合には、さらに他の方法を用いることができる。この場合には、ＭＮ１は、より多くの望ましい（優先性の高い）ＣｏＡに対するＣｏＴメッセージを受信すると、残りのＣｏＴメッセージを待つことなく、できるだけ早くペアリングＢＵメッセージ８５０を送信する。【００６６】
ＭＮ１は、あるＣｏＡのみに対するペアリングＢＵメッセージ８５０を送信するときには、前述したパラメータを調整する必要がある。望ましい方法は、ＭＮ１が受信に成功したＣｏＴメッセージに対するＣｏＡを選択し、選択したＣｏＡのみをペアリングＢＵメッセージ８５０内に含ませることである。このような部分的なペアリングＢＵメッセージ８５０内にＣｏＡなどのパラメータを構成する手順は、本実施の形態と同様であり、選択したＣｏＡがあたかもＭＮ１のすべてのＣｏＡかのようになる。【００６７】
本発明の目的は、複数のＣｏＡを登録する際のメッセージの削減をすることにある。このＣＮ３への複数ＣｏＡ登録は通常では３つの場合に起こる。１つの場合とは、ＭＮ１が最初にスタートアップし、同時にすべてのＣｏＡを取得したときである。このとき、ＭＮ１は同時にＣＮ３への複数ＣｏＡ登録を実行する。第２の場合とは、より一般的であるが、ＭＮ１が最初にＣＮ３と通信を確立したときである。このとき、ＣＮ３はＭＮ１のいずれのＣｏＡも知得していず、ＭＮ１がＣＮ３に複数ＣｏＡ登録を実行する。第３の場合とは、ＭＮ１が比較的長時間、移動しないで、すべてのバインディングの有効期間が満了しかかったときである。このとき、ＭＮ１はすべてのバインディングを同時に更新するためにＣＮ３への複数ＣｏＡ登録を実行する。【００６８】
ＣＮ３への複数ＣｏＡ登録が発生する他の場合として、ＭＮ１がハンドオーバして１つまたは少数のＣｏＡが変更されたときである。他の殆どのＣｏＡは同じである。このような場合、ＭＮ１はすべての複数ＣｏＡ登録済みのＣｏＡを含ませてＣＮへの複数ＣｏＡ登録を実行する必要があるかもしれないが、変更された新しいＣｏＡに対するＲＲ手順を実行するのみでよい。この種のバインディング・アップデートを実行する際、ＭＮ１は、有効期間が残っていればＨｏｋを再取得する必要はない。しかし、通常のＲＲ手順では、ＭＮ１にとって、以前に取得したＨｏｋが未だ有効か否かを知得する手段がないので、通常のＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換を実行する必要があるかもしれない。ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換は、ＭＮ１とＨＡ２との双方向トンネルを通る必要があるので、時間がかかる。これにより、ＣＮ３を最新のＣｏＡで更新させる潜在性を増加させることができる。【００６９】
この実施の形態において、複数のＣｏＡをＨｏＡにバインディングする更なる利点は、ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換による不必要な遅延を防止することにある。つまり、現在存在する有効な第１のＣｏＡを利用して、この有効な第１のＣｏＡに対して新しい第２のＣｏＡのバインディングを確立する。すなわち、ＨｏＡに対する第１のＣｏＡのバインディングが現在存在すると推定して、第１のＣｏＡに対する第２のＣｏＡのバインディングにより、ＨｏＡに対する第２のＣｏＡのバインディングを意味するようにする。【００７０】
図３を参照してこの実施の形態についてさらに説明する。ＭＮ１はインタフェース１１、１２、１３にそれぞれ割り当てられたＣｏＡ１、ＣｏＡ２、ＣｏＡ３を有する。ある時点１００で、ＭＮ１のＨｏＡに対するＣｏＡ１、ＣｏＡ２、ＣｏＡ３のＣＮ３への複数ＣｏＡ登録が完了していて、ＣＮ３が既に有効なバインディングを有するものと仮定する。その後の時点１１０でＭＮ１のインタフェース１３でハンドオーバが起こり、ＣｏＡ３が変化したものとする。図１、図２に示すＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換による遅延を防止するために代わりに、ＭＮ１は、現在有効な、ＨｏＡに対するＣｏＡ２のバインディングを利用して新しいＣｏＡ３のバインディングを確立する。【００７１】
図３では、ＭＮ１は、ＣｏＡ３、ＣｏＡ２をそれぞれ送信元アドレスとしてＣｏＴｉ[1]メッセージ１２１、ＣｏＴｉ[2]メッセージ１２２を送信する。ＭＮ１は、それぞれ対応する（ＣｏＡ３のＣｏＫを含む）ＣｏＴ[1]メッセージ１４１と、（ＣｏＡ２のＣｏＫを含む）ＣｏＴ[2]メッセージ１４２を受信すると、２つのＣｏＫを使用してＣｏＡ３をＣｏＡ２にバインディングする特別なＢＵメッセージ１５０を送信する。ＢＵメッセージ１５０は望ましくは、ＣＮ３に対してＣｏＡ３とＣｏＡ２のバインディングと、ＣｏＡ２とＨｏＡのバインディングと、ＣｏＡ３とＨｏＡの新しいバインディングを指示する特別な信号を含むべきである。【００７２】
当業者であれば、ハンドオーバがなくても、例えば新しいインタフェースの電源がオンになって新しいＣｏＡが追加された場合にも同じ手順を用いることができることは明らかである。さらに、ＭＮ１とＣＮ３が高信頼性ネットワークに存在する場合には、当業者であれば、前述した手順により、１つのＣｏＴｉ／ＣｏＴメッセージの交換を省略できることは明らかである。この場合、図３ではＣｏＴｉ[2]メッセージ１２２とＣｏＴ[1]メッセージ１４１を省略することができる。代わりに、ＣｏＴｉ[1]メッセージ１２１はＣｏＡ２を追加のＣｏＡとして記述して、ＣｏＴｉ[1]メッセージ１２１の応答であるＣｏＴ[2]メッセージ１４２は、ＣｏＡ２とＣｏＡ３のＣｏＫを含む。このＣｏＡ２とＣｏＡ３のＣｏＫは、ＢＵメッセージ１５０内においてＣｏＡ３とＣｏＡ２のバインディング、さらにはＣｏＡ３とＨｏＡのバインディングを確立するために使用される。この方法は同様に、高信頼性ネットワークに位置していなくても、ＣｏＡ３がアップリンクＣｏＡのみに使用され、ＣｏＡ２がダウンリンクＣｏＡのみに使用される場合にも適用することができる。【００７３】
ここで、当業者であれば、図３において、ＣｏＴｉ[2]メッセージ１２２とＣｏＴ[2]メッセージ１４２は、実際にはＣｏＴｉメッセージとＣｏＴメッセージでなく、事実上、ルート最適化を用いて、ＨｏＴｉメッセージとＨｏＴメッセージがＣｏＡ２のＨｏＡに対するバインディングで送信されたものであることは明らかである。すなわち、図３におけるＣｏＴｉ[2]メッセージ１２２は、実際にはホームアドレス・デスティネーション・オプションによる送信元アドレス＝ＣｏＡ２で送信されたＨｏＴｉメッセージであり、ＣｏＴ[2]メッセージ１４２は、実際にはＨｏＡを含むルーティングヘッダでＣｏＡ２あてに送信されたＨｏＴメッセージである。当業者であれば、上記の説明は、本発明の望ましい実施の形態であって、本発明を逸脱しない限り、種々の変形が可能であることは明らかである。【００７４】
＜端末のインタフェースの数について＞
明細書内では、ＭＮ１が複数インタフェース１１、１２、１３、１４を持ち、それぞれがＣｏＡを持つ場合を前提としているが、発明の内容を実施する意味では実際の物理インタフェースがいくつあるかは問題ではない。更にIPv6の仕様では、一つのインタフェースに複数のアドレスを割り振ることも可能となっているので、一つのインタフェースに複数のＣｏＡが割り振られることも考えられる。また、１つの無線部を複数の接続方式で共用し、ネットワーク・インタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続しているのと同等に動作できるよう構成されていてもよい。【００７５】
＜ペアを作るＣｏＡの選別について＞
明細書内では、ＣｏＡの数が奇数である場合にどのように処理するとより効率が良いかを記載しているが、それ以前に、必ずしもＭＮ１が持つ（持つであろう）全てのＣｏＡがペアリングに適しているとは限らないため、それを選別する必要がある。例えば、高信頼ネットワークでの実施例では、通信ネットワークの信頼性が高いことを元にペアリングを実施しているが、ＭＮ１の全てのインタフェース１１、１２、１３、１４がそういったネットワークに接続しているとは限らないし、全てのＣＮ３がそういったネットワークに属しているとも限らない。また、ハンドオーバ前後でＭＮ１の接続するネットワークの信頼性の状態が変化するかもしれない。このような場合は、信頼性の高いネットワークに接続しているＣｏＡのみをまず選び出し、ペアを作ったり、信頼性の高いネットワーク以外に接続しているＣＮ３に対しては通常のＲＲを行なうようにしたりできるよう事前に判定が必要である。また、片方向通信の実施例では、送信用のＣｏＡと受信用のＣｏＡをペアにしているが、一方のＣｏＡだけが多いというような場合は残りのＣｏＡのいくつか（残り全て）は通常のRRを行なわざるを得ないかもしれない。更に、双方向で使用するＣｏＡに関しては、ペアリングの候補から外しておかなければならない。また、高信頼ネットワークの場合と片方向通信の場合が混在する場合もあり、更にその他の（本発明が適用可能な）場合との混在もある。この場合も、まず適切なペアリングと、従来の方法でＲＲを行なう場合とを選別し動作しなければならない。【００７６】
＜その他＞
明細書内では、主にＣｏＡのペアが2つ（ＣｏＡが４つ）の場合を例として説明したが、1つのペア（ＣｏＡが２つ）でもよいし、たくさんあってもよい。また、主にペアリングＢＵをまとめてバルクＢＵしていることを前提として説明（図面も含む）しているが、ペアリング毎に行なうペアリングＢＵでも全く問題ない。さらに、前述のようにそれぞれのＣｏＡを個別にＢＵすることもでき、それらを組み合わせてもよい。また、ペアリングＢＵをまとめてバルクＢＵする際のバルクＢＵの構成方法は、本明細書の記載に関わらず、任意の方法を用いることができる。【００７７】
図４はＭＮ１及びＣＮ３において本発明のＲＲ手順を実現する機能ブロック１１００を示す。機能ブロック１１００は１以上のネットワーク・インタフェース１１１０と、ルーティング・ユニット１１２０と上位層１１３０を有する。ネットワーク・インタフェース１１１０は、他のノードと通信媒体を介して通信するために必要な全てのハードウエア及びソフトウエアを有する機能ブロックである。ネットワーク・インタフェース１１１０は通信装置、ファームウエア、ドライバ、及びレイヤ１（物理層）、レイヤ２（データリンク層）の通信プロトコルを表す。当業者であれば、機能ブロック１１００は１以上のネットワーク・インタフェース９００を含むことは明らかである。【００７８】
ルーティング・ユニット１１２０は、パケットを上位層１１３０のどのプログラムにルーティングさせるか、また、ネットワーク・インタフェース１１１０のどのインタフェースにルーティングさせるかを決定する。ルーティング・ユニット１１２０は、レイヤ３（ネットワーク層）プロトコル、例えばインタネット・プロトコル・バージョン４又は６を実行する。シグナル／データパス１１９２により、ルーティング・ユニット１１２０は、パケットをネットワーク・インタフェース１１１０に転送したり、ネットワーク・インタフェース１１１０からパケットを受け取ったりすることができる。同様に、シグナル／データパス１１９４により、ルーティング・ユニット１１２０は、パケットを上位層１１３０に転送したり、上位層１１３０からパケットを受け取ったりすることができる。【００７９】
上位層１１３０は、通信スタックにおけるネットワーク層の上位の全てのプロトコルとプログラムを実行する。このプロトコルとしては、トランスポート層やセッション層のプロトコルを含み、例えばＴＣＰ（Transmission Control Protocol）、ＳＣＴＰ（Stream Control Transport Protocol）を含む。また、上記のプログラムとしては、他のノードと通信するための必要なプログラムとソフトウエアを含む。シグナルパス１１９４により、ルーティング・ユニット１１２０と上位層１１３０の間でパケットを転送できる。【００８０】
ルーティング・ユニット１１２０内には、ルーティング・エントリを格納するルーティング・テーブル１１４０と、モビリティ・サポート・モジュール１１５０が設けられている。モビリティ・サポート・モジュール１１５０は、ＭＮ１のモビリティ・サポートを可能にしたり、ＣＮ３がＭＮ１との間でルート最適化された通信を可能にしたりする。ルーティング・テーブル１１４０の各エントリは、特定のプリフィックスのあて先にパケットをルーティングさせるための情報を含み、通常ではパケットを転送する次のホップのアドレス又はネットワーク・インタフェース識別子を含む。【００８１】
モビリティ・サポート・モジュール１１５０内のＲＲモジュール１１６０は、ＲＲ手順によりメッセージを交換し、本実施の形態では、複数ＣｏＡに関する情報を追跡する。この情報は、ＭＮ１にあってはバインディング・アップデート・リスト（ＢＵＬ）に、ＣＮ３にあってはバインディング・キャッシュ・エントリ（ＢＣＥ）に格納される。図４では、モビリティ・サポート・モジュール１１５０内にＢＵＬ／ＢＣＥ１１７０として示されている。この情報は、ＣｏＴｉ／ＣｏＴメッセージのＣｏＡと、関連するノンス及びクッキーを含む。【００８２】
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
【産業上の利用可能性】
【００８３】
本発明は、モバイルノードと相手先の通信ノードとの間で認証を行うＲＲ手続を行う場合のメッセージ数を減少させることができるという効果を有し、Ｍｏｎａｍｉ６などに利用することができる。
【図１】
2009066439.tif 000003
【図２】
2009066439.tif 000004
【図３】
2009066439.tif 000005
【図４】
2009066439.tif 000006
【図５】
2009066439.tif 000007
【図６】
2009066439.tif 000008
【手続補正書】
【提出日】平成22年5月19日(2010.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法において、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信するステップと、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証するステップとを、
備えたことを特徴とする通信方法。
【請求項２】
前記モバイルノードが、前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項１に記載の通信方法。
【請求項３】
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項１に記載の通信方法。
【請求項４】
前記相手先の通信ノードが前記バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングし、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項１に記載の通信方法。
【請求項５】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおいて、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えたことを特徴とする通信システム。
【請求項６】
前記モバイルノードが、前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項５に記載の通信システム。
【請求項７】
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証することを特徴とする請求項５に記載の通信システム。
【請求項８】
前記相手先の通信ノードが前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングし、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項５に記載の通信システム。
【請求項９】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが１以上割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードから、前記１以上の第１のメッセージに基づき生成された前記第１及び第２の気付けアドレス用の署名用トークンを含む１以上の第２のメッセージを前記第２の気付けアドレスで受信した場合に、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段とを、
備えたモバイルノード。
【請求項１０】
前記第１のメッセージを送信する際に前記第１及び第２の気付けアドレスのペアリングを記憶し、前記第２の気付けアドレスあての前記第２のメッセージを受信した場合に前記記憶されているペアリングから前記第１の気付けアドレスを引き出すことを特徴とする請求項９に記載のモバイルノード。
【請求項１１】
前記第１のメッセージを送信する際に前記第１及び第２の気付けアドレスのペアリングを気付けアドレス用クッキーに埋め込み、前記第２の気付けアドレスあての前記第２のメッセージを受信した場合に前記気付けアドレス用クッキーに埋め込まれているペアリングから前記第１の気付けアドレスを引き出すことを特徴とする請求項９に記載のモバイルノード。
【請求項１２】
前記割り当てられている複数の気付けアドレスが奇数の場合、前記ペアリングにより余る第３の気付けアドレスを、以前にペアリングされた前記第１又は第２の気付アドレスとペアリングすることを特徴とする請求項９に記載のモバイルノード。
【請求項１３】
前記第３の気付けアドレスについては、以前にペアリングされた前記第１又は第２の気付アドレスとグループ化したバルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１２に記載のモバイルノード。
【請求項１４】
前記割り当てられている複数の気付けアドレスが奇数の場合、前記ペアリングにより余る第３の気付けアドレスについてはペアリングすることなく、標準のリターン・ルータビリティ手順を実行することを特徴とする請求項９に記載のモバイルノード。
【請求項１５】
前記第３の気付けアドレスについては、以前にペアリングされた前記第１又は第２の気付アドレスとグループ化したバルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１４に記載のモバイルノード。
【請求項１６】
前記第１の気付けアドレスは、前記モバイルノードが前記相手先の通信ノードに送信する場合にのみに使用する送信用気付けアドレスであり、前記第２の気付けアドレスは、前記モバイルノードが前記相手先の通信ノードから受信する場合にのみに使用する受信用気付けアドレスであることを特徴とする請求項９に記載のモバイルノード。
【請求項１７】
どの気付けアドレスが前記送信用気付けアドレスか又は前記受信用気付けアドレスかを前記バインディング・アップデートメッセージ内に記述することを特徴とする請求項１６に記載のモバイルノード。
【請求項１８】
信頼性の高いネットワークに接続しているインタフェースの気付けアドレスであって、前記相手先の通信ノードまで信頼性が維持されている場合に、その気付けアドレスをペアリングすると決定し、それ以外の場合にペアリングすることなく標準のリターン・ルータビリティ手順を実行することを特徴とする請求項９に記載のモバイルノード。
【請求項１９】
前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードを生成し、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むペアリング・バインディング・アップデートメッセージを前記相手先の通信ノードに送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２０】
最初の前記第１のメッセージを送信して所定時間経過後までに前記第２のメッセージを受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１９に記載のモバイルノード。
【請求項２１】
最初の前記第１のメッセージを送信して、優先度の高い気付けアドレスの前記第２のメッセージを受信した場合に、受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項１９に記載のモバイルノード。
【請求項２２】
前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２３】
最初の前記第１のメッセージを送信して所定時間経過後までに前記第２のメッセージを受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項２２に記載のモバイルノード。
【請求項２４】
最初の前記第１のメッセージを送信して、優先度の高い気付けアドレスの前記第２のメッセージを受信した場合に、受信した分について前記ペアリング・バインディング・アップデートメッセージ又は前記バルク・バインディング・アップデートメッセージを送信することを特徴とする請求項２２に記載のモバイルノード。
【請求項２５】
前記相手先の通信ノードにおいてバインディングされている前記気付けアドレスが変化した場合又は新しい気付けアドレスが割り当てられた場合、前記変化した気付けアドレス又は新しい気付けアドレスと、前記相手先の通信ノードにおいてバインディングされている他の前記気付けアドレスを含むバインディング・アップデートメッセージを送信することを特徴とする請求項９に記載のモバイルノード。
【請求項２６】
前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記モバイルノードが前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むメッセージを前記第１のメッセージとして前記相手先の通信ノードに送信することにより、前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングすることを特徴とする請求項９に記載のモバイルノード。
【請求項２７】
１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードの前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスがペアリングされ、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含むよう送信された１以上の第１のメッセージを受信する手段と、
前記受信した１以上の第１のメッセージに基づいて前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードにより、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードが生成され、前記複数の気付けアドレス及び前記１以上の認証コードを含むよう送信された１以上のバインディング・アップデートメッセージを受信する手段と、
前記受信した１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えたことを特徴とする通信ノード。
【請求項２８】
前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成する場合に、前記第１及び第２の気付けアドレスに基づいてそれぞれ第１及び第２の署名用トークンを生成することを特徴とする請求項２７に記載の通信ノード。
【請求項２９】
前記第２のメッセージ内に前記第１の気付けアドレスを記述することを特徴とする請求項２７に記載の通信ノード。
【請求項３０】
前記第２のメッセージ内の前記第１及び第２の気付けアドレスの各署名用トークンを用いて前記第１及び第２の気付けアドレスに対して共通の鍵が生成され、前記共通の鍵を用いて前記第１及び第２の気付けアドレスに対して共通の認証コードが生成され、前記第１及び第２の気付けアドレス及び前記共通の認証コードを含むよう送信されたペアリング・バインディング・アップデートメッセージを受信する手段と、
前記ペアリング・バインディング・アップデートメッセージ内の前記第１及び第２の気付けアドレスに対する共通の認証コードを認証する手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【請求項３１】
前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵が生成され、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードが生成され、前記複数の気付けアドレス及び前記共通の認証コードを含むよう送信されたバルク・バインディング・アップデートメッセージを受信する手段と、
前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【請求項３２】
前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証して前記複数の気付けアドレスを前記モバイルノードのホームアドレスにバインディングする手段と、
前記モバイルノードの前記複数のインタフェースの各々に割り当てられている複数の気付けアドレスの１以上が変更された場合、または前記モバイルノードの他のインタフェースに気付けアドレスが新規に割り当てられた場合に、前記新しい気付けアドレスを前記送信元アドレスとし、既にバインディングされている気付けアドレスを含むよう送信された前記第１のメッセージを受信する手段と、
前記第１のメッセージに基づいて前記新しい気付けアドレスを前記モバイルノードのホームアドレスにバインディングする手段とを、
さらに備えたことを特徴とする請求項２７に記載の通信ノード。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法、通信システム、モバイルノード及び通信ノードに関する。
【背景技術】
【０００２】
現在、多くのモバイル装置がインタネット・プロトコル（ＩＰ）を用いてお互いに通信を行っている。ＩＰの例としては、ＩＥＴＦ（Internet Engineering Task Force）が下記の非特許文献１に示されるような「ＩＰｖ６におけるモビリティ・サポート」と、下記の非特許文献２に示されるような「ネットワーク・モビリティ・サポート」を提案している。モバイルＩＰでは、各モバイルノードは永久的なホームドメインを有する。このモバイルノードは、自身のホームネットワークに接続すると、ホームアドレス（ＨｏＡ）として知られるプライマリ・グローバルアドレスが割り当てられ、また、自身のホームネットワークの外に移動して他の外部ネットワークに接続すると、気付アドレス（ＣｏＡ）として知られる一時的なグローバルアドレスが割り当てられる。
【０００３】
モビリティ・サポートの概念では、モバイルノードがホームネットワークと異なる他の外部ネットワークに接続していても、そのモバイルノードにはホームアドレスで到達することができる。これは、非特許文献１に示されるように、ホームエージェントと呼ばれるエンティティをホームネットワークに導入することにより実現される。モバイルノードは、バインディング・アップデート（ＢＵ）メッセージと呼ばれるメッセージを用いて、自身の気付アドレスをホームエージェントに登録する。この登録により、ホームエージェントはモバイルノードのホームアドレスと気付アドレスとのバインディングを生成する。ホームエージェントはモバイルノードのホームアドレスあてのメッセージをインタセプトして、そのメッセージをカプセル化したパケットをモバイルノードの気付アドレスあてに転送する。ここで、カプセル化とは、あるパケットを新しいパケットのペイロードにセットすることを言い、パケットトンネル化として知られている。
【０００４】
しかし、この方法では、モビリティの問題を解決することができるが、準最適化経路が発生する。その理由は、モバイルノードが通信相手（correspondent node：ＣＮ）と通信を行っている場合に両者の間のパケットがホームエージェントを通らなければならないからである。このため、非特許文献１には、モバイルノードがＢＵメッセージをＣＮに送信できることが記載されている。ＣＮはモバイルノードのホームアドレスと気付アドレスとのバインディングを知得すると、両者の間のパケットは、ホームエージェントを通ることなく直接に、モバイルノードの気付アドレスで転送される。これが許されるのは、ＣＮがＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが同一のモバイルノードによって所有されていることを信じることができる場合のみである。これを実現するために、非特許文献１には、ＣＮがＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが本当に同一のモバイルノードによって所有されているかを確認するためのＲＲ（Return Routability）手順が示されている。
【０００５】
このＲＲ手順では、モバイルノードがＢＵメッセージをＣＮに送信する前に、セキュアに生成された２つのトークンをＣＮから取得することを必要とする。ＲＲ手順を開始する前に、モバイルノードは最初に、ＣＮに対してＨｏＴｉメッセージとＣｏＴｉメッセージを送信する。ＨｏＴｉメッセージは、モバイルノードのホームアドレスをパケットの送信元アドレスとしてホームエージェントを経由して送信され、ＣｏＴｉメッセージは、モバイルノードの気付アドレスをパケットの送信元アドレスとして直接送信される。ＣＮはＨｏＴｉメッセージを受信するとＨｏＴメッセージで応答する。ＨｏＴメッセージは、モバイルノードのホームアドレスあてに送信され、また、秘密キーを使用してモバイルノードのホームアドレスに基づいて暗号化されたホーム・キージェン・トークン（Home keygen token：ＨｏＫ）と呼ばれるセキュリティ・トークンを含む。また、ＣＮはＣｏＴｉメッセージを受信すると、ＣｏＴメッセージで応答する。ＣｏＴメッセージは、モバイルノードの気付アドレスあてに送信され、また、秘密キーを使用してモバイルノードの気付アドレスに基づいて暗号化されたケアオブ・キージェン・トークン（Care-of keygen token：ＣｏＫ）と呼ばれるセキュリティ・トークンを含む。
【０００６】
モバイルノードはＨｏＴメッセージとＣｏＴメッセージの両方を受信すると、ＣＮがモバイルノードを認証するための認証子を含むＢＵメッセージをＣＮに送信することができる。この認証子は、ＨｏＫとＣｏＫを連結したキーを使用して暗号化されたＢＵメッセージのチェックサムである。この方法により、ＣＮはＢＵメッセージを受信すると、ＢＵメッセージ内のチェックサムとは別にチェックサムを計算し、この計算したチェックサムと受信した認証子と同一か否かをチェックして、ＢＵメッセージ内におけるモバイルノードのホームアドレスと気付アドレスが本当に同じ位置であるかを証明することができる。
【０００７】
ところで、標準のＲＲ手順では、ＣＮは気付アドレス経由でモバイルノードのホームアドレスの到達性（reachability）を証明することができるが、未だ改良の余地がある。特にメッセージの数が増加した場合、例えば非特許文献２及び下記の非特許文献３に示されるようにモバイルノードが複数のインタフェースを有していて複数の気付アドレスを有する場合を考慮すると、この場合には、各気付アドレスについて２つのメッセージ（ＣｏＴｉメッセージとＣｏＴメッセージ）を交換して到達性と有効性を確立する必要がある。
【０００８】
また、特許文献１、２、３には、気付アドレスの到達性と有効性を証明する他の方法として、暗号化アドレスをＢＵメッセージに使用する方法が提案されているが、これらの方法では、ＩＰｖ６においては使用可能なビット数が限られているので、暗号化アドレスのセキュリティの強さは疑問である。特に特許文献２は、セキュアなルータ広告（router advertisement）をＢＵメッセージ内に含ませて、ＣＮがこれらのルータ広告内のプリフィックスからアドレスの有効性を引き出すことを開示している。しかしながら、この方法は、現在ではまだ実現が容易ではない、インタネット程度に広範囲の証明システムを必要とする。また、特許文献３は、モバイルノードとＣＮがパブリックキーとプライベートキーを交換して信頼関係を確立することを提案している。しかしながら、この方法では、悪意のあるモバイルノードがＣＮに信頼関係を確立して、ＣＮが気付アドレスにより攻撃されることを防止できない。このため、これを防止するためには、標準のＲＲ手順と同様なメカニズムを採用しなければならない。
【０００９】
すなわち、従来技術として、標準のＭＩＰｖ６（非特許文献１）には、ルート最適化時におけるＣＮがＭＮを認証する手段としてＲＲ（Return Routability）手続が開示されている。ＭＩＰｖ６のＲＲは、ＨｏＡテストによる不正なリダイレクションからの保護と、ＣｏＡテストによるリーチャビリティの確認からなる。
【００１０】
一方、Ｍｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）では、モバイルノード（ＭＮ）が複数のインタフェースを有する場合のために種々の提案が成されている。また、モバイルＩＰ（Internet Protocol）を利用するＭＮは、移動先のアドレスである気付けアドレス（ＣｏＡ）を、自身のホームアドレス（ＨｏＡ）を管理するホームエージェント（ＨＡ）に登録し、ＨｏＡあてパケットの転送を依頼する。ＭＮが、複数のＣｏＡを１つのＨｏＡに対して同時に関連付けて登録することができれば、複数のインタフェースを備えるＭＮは、それぞれのインタフェースに割り当てられたＣｏＡを登録することで、インタフェースの状態に応じて使用するＣｏＡを瞬時に切り替えることが可能となる。図６は従来のＭｏｎａｍｉ６におけるバルクＢＵ（バインディング・アップデート）を示す説明図である。非特許文献２には、図６に示すようにＭＮ１が複数のＣｏＡを１つのＨｏＡに関連付けてＨＡ２に登録する際に一度にまとめて一つのＢＵを送信する方法（Bulk mCoA BU）する手法が記述されている。ルート最適化（ＲＯ：Route Optimazation）を行う手段（ＣＮに対して複数のＣｏＡを登録すること）については、Ｍｏｎａｍｉ６には、何らの記載はない。
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Wakikawa, R., et al., "Multiple Care-of Addresses Registration", Internet Draft: draft-wakikawa-mobileip-multiplecoa-03.txt, 19 June 2004.
【非特許文献３】Wakikawa, R., et al., "Multiple Care-of Addresses Registration", Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, 12 June 2006.
【特許文献１】[US Patent Application Publication 2003/0211842A1] Kempf, J., et. al., "Securing Binding Update Using Address Based Keys", 13 Nov  2003.
【特許文献２】[US Patent Application Publication 2005/0041634A1] Aura, A. T., "Verifying Location of a MobileNode", 24 Feb 2005.
【特許文献３】[US Patent Application Publication 2006/0227971A1] Haddad, W., "Secret Authentication Key Setup in Mobile IPv6", 12 Oct 2006.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、ＭＮが複数のＣｏＡをＨＡにバルクＢＵ（バインディング・アップデート）登録するＭｏｎａｍｉ６を、ＣＮがＭＮを認証するＭＩＰｖ６のＲＲ手順に単純に組み合わせ、この組み合わせたＲＲ手順において、ＭＮがＣＮに対して、複数のＣｏＡに関連するバインディング・メッセージを一括して行うバルクＢＵ（ここでは、ＣＮに対する複数ＣｏＡ登録に使用すること）が考えられる。しかしながら、図５に示すようなＭｏｎａｍｉ６のBulk mCoA BUでは、ＭＮ１−ＨＡ２間のセキュリティはＩＰｓｅｃにより保護されているという観点から、さらにバルクＢＵに対する認証を行うという概念がない。これに対し、ＣＮ３がＭＮ１を認証することを目的とするＭＩＰｖ６のＲＲ手順では、ＭＮ１−ＣＮ３間がＩＰＳｅｃでセキュアに保護されている前提を置くことができないため、ＢＵメッセージの内容が異なり、ＲＲ手順におけるＢＵメッセージでは、個々のＣｏＡ毎にバインディング管理キー（Ｋｂｍ）や署名（ＭＡＣ）が必要である（後述）。このため、Ｍｏｎａｍｉ６のＨＡあてのバルクＢＵをＭＮ１−ＣＮ３間のＲＲ手順に適用することができず、ＭＮ１−ＣＮ３間のＲＲ手順におけるＢＵメッセージは個々のＣｏＡ毎にＣＮあてに送る必要がある。
【００１２】
図６はこの場合の動作、すなわち本発明が解決しようとする課題を示し、この図を参照しながらＭＩＰｖ６のＲＲ手順を説明する。まず、
（１）ＭＮ１はＨｏＡ、ＣｏＡ毎のクッキーを生成して、ＣＮ３あてのＨｏＴＩ（Home-Test-Init）メッセージをＨＡ２あてにカプセル化してホームネットワーク４及び外部ネットワーク５ａ経由で送信するとともに、複数（ｎ個）のＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのＣｏＴｉ（Care-of-Test-Init）[1]〜[n]メッセージを個別に外部ネットワーク５ａ、５ｂ経由でＨＡ２を介することなく直接ＣＮ３へ送信することにより、ＨｏＡ、および各ＣｏＡのクッキーをＣＮ３に送信する。
（２）ＣＮ３はこれに応答して、各クッキーなどからＨｏＡ、ＣｏＡ[1]〜[n]毎の署名用トークンを生成して、ＨＡ２経由のＭＮ１あてのＨｏＴ（Home-Test）メッセージを送信するとともに、ＣｏＡ[1]〜[n]についての直接ＭＮ１あてのＣｏＴ（Care-of-Test）[1]〜[n]メッセージを送信することにより署名用トークンを送信する。
【００１３】
（３）次いで、ＭＮ１はこれに応答して、各署名用トークンなどからＣｏＡ[1]〜[n]毎のバインディング管理キーＫｂｍ[1]〜[n]を生成してそれぞれのメッセージ認証コードＭＡＣ[1]〜[n]（ＭＡＣ：Message Authentification Code）を生成し、ＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのバインディング・アップデート・メッセージＢＵ[1]〜[n]を個々に送信することにより、Ｋｂｍ[1]〜[n]及びＭＡＣ[1]〜[n]を送信する。ＣＮ３はＭＮ１とは別個に、かつＭＮ１と同様にＭＡＣ[1]〜[n]などを生成し、ＢＵ[1]〜[n]メッセージを認証する。
（４）オプションとして、ＣＮ３はＢＵ[1]〜[n]メッセージに応答してバインディング確認メッセージＢＡ[1]〜[n]を送信してもよい。つまり、ＭＩＰｖ６のＲＲ手順を複数のＣｏＡ登録に使用するためには，単にＢＵメッセージの宛先がＨＡであるかＣＮであるかの差異だけでなく、セキュリティ上のＭＮとの関係の際に起因する複数の手順に関する差異を考慮しなければならない。このため、（１）〜（３）では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴ、ＢＵの各メッセージを送信するので、非常に多く（３ｎ個）のメッセージを送信する必要があるという問題点がある。
【００１４】
本発明は上記の問題点に鑑み、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる通信方法、通信システム、モバイルノード及び通信ノードを提供することを目的とする。
【課題を解決するための手段】
【００１５】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法において、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信するステップと、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証するステップとを、
備えた。
【００１６】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおいて、
前記モバイルノードが、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上の第１のメッセージを受信して前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードが、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記１以上の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えた。
【００１７】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが１以上割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスをペアリングし、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含む１以上の第１のメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードから、前記１以上の第１のメッセージに基づき生成された前記第１及び第２の気付けアドレス用の署名用トークンを含む１以上の第２のメッセージを前記第２の気付けアドレスで受信した場合に、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを１以上のバインディング・アップデートメッセージにより前記相手先の通信ノードに送信する手段とを、
備えた。
【００１８】
また本発明は上記目的を達成するために、１以上のインタフェースを有し、前記１以上のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードにより、前記１以上のインタフェースの各々に割り当てられている複数の気付けアドレスがペアリングされ、各対の気付けアドレスのうちの第１の気付けアドレスを送信元アドレスとして第２の気付けアドレスを含むよう送信された１以上の第１のメッセージを受信する手段と、
前記受信した１以上の第１のメッセージに基づいて前記第１及び第２の気付けアドレス用の署名用トークンを生成し、前記生成した署名用トークンを含む１以上の第２のメッセージを前記モバイルノードの前記第２の気付けアドレスあてに送信する手段と、
前記モバイルノードにより、前記１以上の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して１以上の認証コードが生成され、前記複数の気付けアドレス及び前記１以上の認証コードを含むよう送信された１以上のバインディング・アップデートメッセージを受信する手段と、
前記受信した１以上のバインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する１以上の認証コードを認証する手段とを、
備えた。
【００１９】
この構成により、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
【発明の効果】
【００２０】
本発明によれば、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して本発明の実施の形態について説明する。
＜複数のＣｏＡをペアリング＞
この実施の形態では、モバイルノードとＣＮはともに、高い信頼関係のネットワーク構成内に位置していて、ＣＮが特定の送信元アドレスのパケットを受け取る場合に、その特定の送信元アドレスが存在（実在）し（到達でき）、そのパケットが本当にその特定の送信元アドレスから来たことが保証されているものとする。これは、通常のネットワークにおけるパケット転送保証であって、実在する送信元アドレスあてのパケットは転送され、実在しない送信元アドレスあてのパケットは破棄される。このような高い信頼関係のネットワークは、多くの方法で実現可能である。例えばネットワーク内の各ルータは、イングレス・フィルタリングを実行して、あるインタフェースでは受信すべきでない送信元アドレスのパケットをそのインタフェースでインタセプトしたときにはそのパケットを破棄する。このように、そのルータで構築されるネットワーク構成は、転送されてきたパケットの送信元アドレスが存在し、有効であることを保証することができる。この高い信頼関係のネットワーク構成の例としては、セルラ・オペレータやその関連するＷＬＡＮ（ワイヤレスＬＡＮ）に採用されている第３世代オールＩＰネットワークがある。
【００２２】
このタイプのネットワークに対しては、１つのＣｏＴｉメッセージと１つのＣｏＴメッセージを用いて、１つの気付アドレスの到達性と有効性を証明すると、過剰なメッセージ数となる。その理由は、あるアドレスの到達性（転送保証）が確保できれば、そのアドレスの有効性（送信元アドレスの有効性）は確保されるからである。このため、この実施の形態では、複数の気付アドレスを１対の気付アドレス毎に分割（ペアリング）し、ＣｏＴｉメッセージがある第１の気付アドレスから送信されると、そのＣｏＴｉメッセージに対応するＣｏＴメッセージを、第１の気付アドレスと異なる第２の気付アドレスあてに送信する。
【００２３】
図１は一実施の形態の通信シーケンスを示す。図１では、説明を簡略化するために、ＭＮ１は４つのインタフェース１１、１２、１３、１４を有し、インタフェース１１、１２、１３、１４にそれぞれ気付アドレスとしてＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４が割り当てられている。なお、当業者であれば、さらに多くの気付アドレスにも適用することができることは明白である。
【００２４】
（１）ＣｏＴｉ（ＨｏＴｉ）
図１において、まず、標準のＲＲ手順に従って、ＭＮ１はＣＮ３に対し、ＨｏＴｉメッセージ８１０と、ＣｏＡ１、ＣｏＡ２をペアリングしたＣｏＴｉ[1]メッセージ８２１と、ＣｏＡ３、ＣｏＡ４をペアリングしたＣｏＴｉ[2]メッセージ８２２を送信する。ＨｏＴｉメッセージ８１０は、ＭＮ１のホームエージェントであるＨＡ２あてにトンネル化され、さらにＣＮ３に転送される。
【００２５】
（２）ＣｏＴ（ＨｏＴ）
次に、ＣＮ３は標準のＲＲ手順に従って、ＨｏＴｉメッセージ８１０に対してＨｏＴメッセージ８３０で応答する。ＣｏＴｉ[1]メッセージ８２１の送信元アドレスはＭＮ１のＣｏＡ１である。ここで、通常のＲＲ手順では、ＣＮ３はＣｏＴｉ[1]メッセージ８２１を受信すると、ＣｏＡ１に対応する署名用トークンであるＣｏＫを生成してＣｏＡ１あてにＣｏＴメッセージを送信する。これに対し、この実施の形態では、ＭＮ１はモビリティヘッダ・オプションを用いて、ＣｏＴｉ[1]メッセージ８２１内にＣｏＡ２を記述する。そこで、ＣＮ３はＣｏＡ１、ＣｏＡ２の両方に対応するＣｏＫを生成して、ＣｏＡ１の代わりにＣｏＡ２あてにＣｏＴ[1]メッセージ８４１を送信する。同様に、ＣｏＴｉ[2]メッセージ８２２の送信元アドレスはＭＮ１のＣｏＡ３であり、ＭＮ１はモビリティヘッダ・オプションを用いて、ＣｏＴｉ[2]メッセージ８２２内にＣｏＡ４を記述する。そこで、ＣＮ３はＣｏＡ３、ＣｏＡ４の両方に対応するＣｏＫを生成して、ＣｏＡ４あてにＣｏＴ[2]メッセージ８４２を送信する。
【００２６】
（３）ペアリングＢＵ
本発明においてはペアリングした２つのＣｏＡを効率的にＣＮに対して登録するために、ＢＵメッセージを送る際にもこれらをまとめて送信するペアリングＢＵという概念を用いる。複数のＣｏＡをまとめて登録すると言う点ではＣＮへのバルクＢＵと類似しているが、ペアリングに起因する鍵情報の扱い方や、認証情報の生成方法などは、後述のように変更する必要がある。また、本明細書では、より望ましい実施の方法としてペアリングが複数ある場合に、ペアリングＢＵを更にまとめてバルクＢＵしている例について説明している。なお、ペアリングＢＵ及び、ペアリングＢＵのバルクＢＵを用いる代わりに全て個別のＢＵメッセージを用いることも可能である。
ＭＮ１はＨｏＴメッセージ８３０と、ＣｏＴ[1]メッセージ８４１とＣｏＴ[2]メッセージ８４２を集合して、ペアリングＢＵメッセージ８５０をＣＮ３に送信することによりＣＮへの複数ＣｏＡ登録を行う。ペアリングＢＵメッセージ８５０はモビリティヘッダ・サブオプションとしてバインディングＩＤサブオプションを含み、すべてのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４のＣＮ３への複数ＣｏＡ登録を行う。ペアリングＢＵメッセージ８５０内の認証子は、以下のようにＣｏＴ[1]メッセージ８４１と、ＣｏＴ[2]メッセージ８４２とＨｏＴメッセージ８３０から引き出したパラメータに基づいて生成される。
【００２７】
以下に、図１中のメッセージ内に含まれるパラメータの詳細を例示する。
＜ＨｏＴｉ＞
ＨｏＴｉメッセージ８１０は以下のパラメータを含む。
・送信元アドレス：ＭＮ１のホームアドレス
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Home Init Cookie
Home Init Cookieは、ＨｏＴｉメッセージに対応して、有効なＣＮからＨｏＴメッセージが送られたことを確保するために、ＭＮ１が生成した値である。
【００２８】
＜ＨｏＴ＞
ＨｏＴｉメッセージ８１０に対応してＣＮ３から送られたＨｏＴメッセージ８３０は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＭＮ１のホームアドレス
・モビリティヘッダ
・Home Init Cookie
・Home Keygen Token（ＨｏＫ）
・Home Nonce Index
【００２９】
Home Init Cookieは、ＨｏＴｉメッセージ８１０内の値と同じである。ＨｏＫは、ＭＮ１のホームアドレス（ＨｏＡ）と、ＣＮ３のみが知得している秘密のHome Nonce Indexに基づいて暗号化されて生成される。ＨｏＫは、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ｜nonce｜０））
但し、ＨＭＡＣ＿ＳＨＡ１（Ｋcn，ｍ）は、ＳＨＡ１ハッシュ・アルゴリズムにメッセージｍと秘密キーＫcnを用いて計算したメッセージ認証コード（ＭＡＣ）の関数、０は８ビットで値が０、｜は連結を表す。
【００３０】
Home Nonce Indexは、ＨｏＫを生成するために使用する秘密ノンス値と一致するかを判定するためにＣＮ３が使用する。例えばＣＮ３は、６４個の異なるノンス値のアレイを有し、Nonce Index＝０はノンス値アレイの最初のノンス値と一致するかを判定し、Nonce Index＝１はノンス値アレイの最初の２番目のノンス値と一致するかを判定するというように使用する。
【００３１】
＜ＣｏＴｉ[1]＞
ＣｏＴｉ[1]メッセージ８２１は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ１
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Care-of Init Cookie [1]
・追加のＣｏＡ２
【００３２】
＜ＣｏＴｉ[2]＞
ＣｏＴｉ[2]メッセージ８２２は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ３
・あて先アドレス：ＣＮ３のアドレス
・モビリティヘッダ
・Care-of Init Cookie [2]
・追加のＣｏＡ４
【００３３】
Care-of Init Cookie は、ＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２にそれぞれ対応するＣｏＴメッセージ８４１、８４２が有効なＣＮ３から送られたことを確保するためにＭＮ１が生成した値である。ＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２におけるそれぞれの「追加のＣｏＡ２、ＣｏＡ４」は、この実施の形態において追加したＣｏＡである。
【００３４】
ＣｏＴｉ[1]メッセージ８２１に応答してＣＮ３が送信するＣｏＴ[1]メッセージ８４１は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ）[1]
・Care-of Nonce Index [1]
【００３５】
同様に、ＣｏＴｉ[2]メッセージ８２２に応答してＣＮ３が送信するＣｏＴ[2]メッセージ８４２は以下のパラメータを含む。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ４
・モビリティヘッダ
・Care-of Init Cookie [2]
・Care-of Keygen Token（Ｃｏｋ）[2]
・Care-of Nonce Index [2]
【００３６】
Care-of Init Cookie [1]、[2]はそれぞれ、対応するＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２内のものと同じである。Ｃｏｋ [1]、[2]はそれぞれ、ＭＮ１の両方の気付アドレス（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）と、ＣＮ３のみが知得している秘密ノンス値に基づいて暗号化されて生成されている。Ｃｏｋ [1]は以下のハッシュ値の最初の６４ビットであり、
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜ＣｏＡ２｜nonce｜１））
また、Ｃｏｋ [2]は以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ３｜ＣｏＡ４｜nonce｜１））
但し、「１」は、Ｃｏｋ [1]、[2]をＨｏＫと区別するためであって、８ビットで値が１である。ここで、当業者であれば、「１」は、標準のＲＲ手順で生成される通常のＣｏｋとＣｏｋ [1]、[2]を区別するために、他の８ビット、例えば「２」でもよい。Care-of Nonce Index [1]、[2]はそれぞれ、Ｃｏｋ [1]、[2]を生成するための使用する秘密ノンスを判別するためにＣＮ３が使用する。
【００３７】
＜ペアリングＢＵ＞
ペアリングＢＵメッセージ８５０は以下のパラメータを含む。
・送信元アドレス：ＣｏＡ１
・あて先アドレス：ＣＮ３のアドレス
・ホームアドレスあて先オプション
・ＭＮ１のホームアドレス
・モビリティヘッダ
・シーケンス番号
・Home Nonce Index
・Care-of Nonce Index [1]
・ＣｏＡ１、ＣｏＡ２のバインディング・ユニーク識別子サブオプション
・Care-of Nonce Index [2]
・ＣｏＡ３、ＣｏＡ４のバインディング・ユニーク識別子サブオプション
・認証子
【００３８】
Home Nonce IndexとCare-of Nonce Index [1]、[2]はそれぞれ、ＣＮ３に対してどのノンス値がＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]を生成するのに使用されたかを通知するために、ＨｏＴメッセージ８３０、ＣｏＴ[1]メッセージ８４１、ＣｏＴ[2]メッセージ８４２内の値と同じである。バインディング・ユニーク識別子サブオプションは、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４を含み、それぞれユニークなバインディング識別子である。認証子は、ＨｏＴメッセージ８３０、ＣｏＴ[1]メッセージ８４１、ＣｏＴ[2]メッセージ８４２内のＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]と、モビリティヘッダそのものに基づいて暗号化して生成したものである。ここで、ＣＮ３は、ホームアドレスと、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４と、Home Nonce Indexと、Care-of Nonce Index [1]、[2]を知得しているので、ＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]を再現できる。
【００３９】
認証子は、すべてのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４に対して共通の認証子であって、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ１｜ＣｏＡ２｜ＣｏＡ３｜ＣｏＡ４｜ＣＮアドレス｜ＭＨ））
但し、Ｋbmは、ＨｏＫ、Ｃｏｋ[1]、Ｃｏｋ[2]のハッシュ値から生成したバインディング管理キーであって、
Ｋbm＝ＳＨＡ１（ＨｏＫ｜Ｃｏｋ[1]｜Ｃｏｋ[2]）
である。ＣＮアドレスはＣＮ３のアドレスであり、ＭＨは、認証子の値で０にセットされるモビリティヘッダである。
【００４０】
認証子の値は、ＣＮ３がペアリングＢＵメッセージ８５０内の情報を用いて独立して生成して証明することができる。ここで、注意すべき点は、ペアリングＢＵメッセージ８５０内には、Care-of Nonce Index [1]、 [2]と、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡのバインディング・ユニーク識別子サブオプションは、ＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４とその対応するノンスがグループ化されるように配列することが望ましいことである。また、４つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４の順番は、認証子を生成する際、バインディング・ユニーク識別子サブオプションの順番に従って引き出すことができることが望ましい。
【００４１】
ここで、当業者であれば、ペアリングＢＵメッセージ８５０の送信元アドレスは、４つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３、ＣｏＡ４のいずれか１つを用いてもよいことは明らかである。また、上記説明では、１対の（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）に対して１つのＣｏＫを用いているが、この利点は、ＭＮ１とＣＮ３にとって必要な帯域と処理時間を短縮することができることにある。しかし、１対の（ＣｏＡ１、ＣｏＡ２）、（ＣｏＡ３、ＣｏＡ４）の１つが変更されたときには、ＣｏＫも変更されるので、両方のＣｏＡを登録する必要がある。例えばインタフェース１２、１３のハンドオーバによりＣｏＡ２、ＣｏＡ３が変更されると、ＣｏＡ１、ＣｏＡ４が変更されなくても、ＭＮ１はＣｏＴｉ[1]メッセージ８２１、ＣｏＴｉ[2]メッセージ８２２の両方を再送信して、ＣｏＡ１、ＣｏＡ４の新しいＣｏＫを取得しなければならない。
【００４２】
<<１つのＣｏＡに１つのＣｏＫ>>
ＣＮ３は１つのＣｏＡに対して１つのＣｏＫを生成して、同じＣｏＴメッセージ内に配置することも可能である。この場合、ＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ）[1a]
・Care-of Keygen Token（Ｃｏｋ）[1b]
・Care-of Nonce Index [1]
【００４３】
Ｃｏｋ [1a]は、ＣｏＡ１（＝ＣｏＴｉ[1]メッセージ８２１の送信元アドレス）を用いて生成され、Ｃｏｋ [1b]は、ＣｏＡ２（＝ＣｏＴ[1]メッセージ８４１のあて先アドレス）を用いて生成される。すなわち、Ｃｏｋ [1a]は、以下のハッシュ値の最初の６４ビットであり、
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜nonce｜１））
Ｃｏｋ [1b]は、以下のハッシュ値の最初の６４ビットである。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ２｜nonce｜１））
２つのＣｏｋ [1a]、Ｃｏｋ [1b]は、この例では同じCare-of Nonce を使用し、また、ＭＮ１は、出現順に、ＣｏＡ１に対してＣｏｋ[1a]を、ＣｏＡ２に対してＣｏｋ [1b]を並べて配置する。
【００４４】
各ＣｏＡに対して独立したＣｏｋを使用することにより、ＭＮ１は次の登録を実行するときに柔軟に対応することができる。例えば前述したようにインタフェース１２、１３のハンドオーバによりＣｏＡ２、ＣｏＡ３が変更される場合について説明すると、この場合には、ＭＮ１はＣｏＡ２、ＣｏＡ３を再ペアリングして１つのＣｏＴｉメッセージのみを送信すればよい。このＣｏＴｉメッセージは、新しいＣｏＡ２から送信され、また、ＣｏＡ３を追加のＣｏＡとして記述する。ＣＮ３はこれに応答して、ＣｏＡ２のＣｏｋとＣｏＡ３のＣｏｋを含むＣｏＴメッセージをＣｏＡ３あてに送信する。また、この方法は、ペアリングＢＵの代わりに個別のＢＵメッセージで登録を行なう場合にもより適していると言える。
【００４５】
<<１つのＣｏＡに１つのCare-of Nonce>>
当業者であれば、他の変形例も可能であることは明らかである。例えば暗号化力を増大させるために、ＣＮ３は、１つのＣｏＴメッセージ内で個々のＣｏＡに対してそれぞれ異なるCare-of Nonceを使用することを選択してもよい。この場合、ＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ）[1a]
・Care-of Keygen Token（Ｃｏｋ）[1b]
・Care-of Nonce Index [1a]
・Care-of Nonce Index [1b]
ＭＮ１は、出現順に、ＣｏＡ１に対してＣｏｋ [1a]とCare-of Nonce Index [1a]を、ＣｏＡ２に対してＣｏｋ [1b]とCare-of Nonce Index [1b]を並べて配置する。
【００４６】
<<メモリから第１のＣｏＡを引き出す>>
上記の説明では、ＣｏＴメッセージ８４１、８４２は、２つのＣｏＡに対して１つ又は２つのCare-of Keygen Tokenを含むが、変形例として１つのＣｏＡのみをＣｏＴメッセージ８４１、８４２内に記述する。ＭＮ１は望ましくは、ペアリングした２つのＣｏＡを記憶して、ＣｏＴメッセージ８４１、８４２に記述されていない他方のＣｏＡを引き出すことができる。例えばＭＮ１は、ＣｏＴｉ[1]メッセージ８２１を送信するときに、メモリ内にＣｏＡ１、ＣｏＡ２とCare-of Init Cookie [1]をストアすることができる。したがって、ＭＮ１は、ＣｏＴ[1]メッセージ８４１を受信すると、ＣｏＴ[1]メッセージ８４１内のCare-of Init Cookie [1]に基づいてメモリを参照することにより、ＣｏＴ[1]メッセージ８４１がＣｏＡ２のみを記述していても、ＣｏＴ[1]メッセージ８４１に関連するＣｏＡ１、ＣｏＡ２の両方を知得することができる。
【００４７】
<<Care-of Init Cookieから第１のＣｏＡを引き出す>>
上記のようにメモリ内にＣｏＡ１、ＣｏＡ２とCare-of Init Cookie [1]などをストアする方法では、ＭＮ１はＲＲ手順に関するステート情報を維持するために多くのメモリ容量を必要とする不具合がある。そこで、変形例として、ハッシュ関数などを用いてＣｏＡ１、ＣｏＡ２をCare-of Init Cookie [1]に埋め込む。この方法によれば、ＭＮ１はCare-of Init Cookie [1]とは別のエリアにストアされているＣｏＡ１、ＣｏＡ２を参照することなく、ＣｏＡ１、ＣｏＡ２を引き出すことができる。
【００４８】
<<ＣｏＴ内に第１のＣｏＡを記述>>
ＣＮ３にとって他の望ましい方法は、ＣｏＴメッセージ８４１、８４２内に他方のＣｏＡを記述することである。この方法におけるＣｏＴ[1]メッセージ８４１の中身は以下のように変更される。
・送信元アドレス：ＣＮ３のアドレス
・あて先アドレス：ＣｏＡ２
・モビリティヘッダ
・Care-of Init Cookie [1]
・Care-of Keygen Token（Ｃｏｋ）[1b]
・Care-of Nonce Index [1b]
・追加のＣｏＡ：ＣｏＡ２
・Care-of Keygen Token（Ｃｏｋ）[1a]
・Care-of Nonce Index [1a]
【００４９】
この方法によれば、ＭＮ１は両方のＣｏＡに対して特別にアプローチしたり、メモリにストアすることなく両方のＣｏＡを引き出したりすることができる。但し、ＭＮ１はメモリには、Care-of Init CookieをＣｏＡとＣＮ３のアドレスとともに記録するステートをストアする必要がある。この方法により、ＭＮ１は、受信したＣｏＴメッセージの有効性をチェックすることができ、また、攻撃者が偽のＣｏＴメッセージをＭＮ１に送ることにより曝されるセキュリティ上のリスクから避けることができる。
【００５０】
<<ＣｏＡの数が奇数>>
上記では、ＣｏＴｉメッセージ及びＣｏＴメッセージに対して異なるＣｏＡを使用することにより、ＢＵ登録に必要なメッセージ数を減少できるかを説明した。すなわち、上記説明では、ＣｏＴｉメッセージ及びＣｏＴメッセージを交換する際に２つのＣｏＡをペアリングしている。このため、ＣｏＡの数が奇数の場合、ペアリングする相手がない１つのＣｏＡが余る。この状態を取り扱う１つの方法として、余りの１つのＣｏＡを、以前に使用したＣｏＡとペアリングする。また、他の方法として、最後の１つのＣｏＡについては標準のＲＲ手順を使用し、ＣｏＴｉメッセージの送信元アドレスとＣｏＴメッセージのあて先アドレスを最後の１つのＣｏＡとする。
【００５１】
さらに他の方法として、余りの１つのＣｏＡを、他の１対のＣｏＡとグループ化する。この方法では、基本的には余りの１つのＣｏＡの有効性と到達性を証明するためにペアリングＢＵメッセージを使用する。この方法によるシーケンスを図２に示す。図２では、説明を簡略化するために、ＭＮ１はインタフェース１１、１２、１３にそれぞれ割り当てられた３つのＣｏＡ１、ＣｏＡ２、ＣｏＡ３を有する。当業者であれば、他の奇数のＣｏＡを取り扱う場合には、前述したペアリング方法と組み合わせることにより対応することができることは明らかである。
【００５２】
まず、標準のＲＲ手順に従って、ＭＮ１はＨｏＴｉメッセージ９１０とＣｏＴｉメッセージ９２０をＣＮ３に送信する。ＨｏＴｉメッセージ９１０はＭＮ１のホームエージェントであるＨＡ２あてにトンネル化されて送信され、さらにＣＮ３に転送される。ＣＮ３は標準のＲＲ手順に従って、ＨｏＴｉメッセージ９１０に対してＨｏＴメッセージ９３０で応答する。ＣｏＴｉメッセージ９２０の送信元アドレスはＭＮ１のＣｏＡ１である。ここで、通常のＲＲ手順では、ＣＮ３はＣｏＴｉメッセージ９２０を受信すると、ＣｏＡ１に対応するＣｏＫを生成してＣｏＴメッセージをＣｏＡ１あてに送信するが、本実施の形態では、ＭＮ１はＨｏＴｉメッセージ９１０内の追加のモビリティヘッダ・オプションにより、ＣｏＡ２及びＣｏＡ３を指示する。そこで、ＣＮ３はＣｏＴｉメッセージ９２０を受信すると、ＣｏＡ１、ＣｏＡ２及びＣｏＡ３に対応するＣｏＫを生成してＣｏＴメッセージ９４０をＣｏＡ２あてに送信する。
【００５３】
ＭＮ１はＨｏＴメッセージ９３０とＣｏＴメッセージ９４０を集めて、ペアリングＢＵメッセージ９５０をＣＮ３に送信することにより登録を完了する。ＣＮ３がＣｏＡ３の到達性と有効性を証明するために、ペアリングＢＵメッセージ９５０はＣｏＡ３を送信元アドレスとして送信される。ここで、前提として説明したように、この手順は、送信元アドレスがＣｏＡ３であるパケットを受信したということは、ＣｏＡ３が有効であって到達できることを意味するほど高い信頼性のネットワークに用いられる。ペアリングＢＵメッセージ９５０はＣｏＡ１、ＣｏＡ２及びＣｏＡ３のＣＮへの複数ＣｏＡ登録を完了するためのモビリティヘッダ・サブオプション（例えばバインディング・ユニーク識別子サブオプション）を含む。ペアリングＢＵメッセージ９５０内の認証子の値は、ＨｏＴメッセージ９３０とＣｏＴメッセージ９４０から引き出したパラメータに基づいて生成される。
【００５４】
ここで、当業者であれば、ＣｏＫと認証子の計算は、前述した方法に第３のＣｏＡ３を追加した方法で可能であることを容易に理解できる。同様に、各ＣｏＡに対して独立したＣｏＫと、各ＣｏＡに対して独立したCare-of Nonceを用いた変形を適用することができる。さらに、ＣｏＡ１、ＣｏＡ３を含むＣｏＴｉメッセージを送信して、ＣｏＴメッセージをＣｏＡ２あてに送信してもよい。この説明は当業者にとって明白であるので、その詳細な説明は省略する。
【００５５】
<<送信ＣｏＡと受信ＣｏＡ>>
図１、図２に示した実施の形態は、高信頼性ネットワークに適用する場合を説明したが、他のネットワークにも適用することができる。一例として、ＭＮがＣＮと通信を行う際に複数の異なるＣｏＡを異なる目的で使用する場合がある。例えばロード・バランシングの目的で、ある複数のＣｏＡを１セットとしてアップリンク（送信用）・トラフィックに使用し、他のある複数のＣｏＡを１セットとしてダウンリンク（受信用）・トラフィックに使用する場合が想定される。この想定例では、ある複数のＣｏＡがＭＮからＣＮへのパケット送信のみに使用され、他のある複数のＣｏＡがＣＮからＭＮへのパケット送信のみに使用される。この場合には、各ＣｏＡの到達性と有効性を標準のＲＲ手順を用いて証明する必要はない。
【００５６】
したがって、ＭＮがある複数のＣｏＡを１セットとして送信のみに使用するので、これらの複数のＣｏＡ（以下、「アップリンクＣｏＡ」と言う。）は到達性をテストする必要はなく、有効性のみをテストすればよい。同様に、ＭＮが他のある複数のＣｏＡを１セットとして受信のみに使用するので、これらの複数のＣｏＡ（以下、「ダウンリンクＣｏＡ」と言う。）は有効性をテストする必要はなく、到達性のみをテストすればよい。なお、どのＣｏＡをアップリングＣｏＡあるいはダウンリンクＣｏＡとするかをＭＮからＣＮへ確認メッセージにより確認するようにしても良い。
【００５７】
上記の高信頼性ネットワークに使用する方法をこの場合にも適用することができる。図１に示すシーケンス図を参照して一例を説明する。ここでは、ＣｏＡ１とＣｏＡ３をアップリンクＣｏＡ、また、ＣｏＡ２とＣｏＡ４をダウンリンクＣｏＡと仮定する。当業者であれば、図１に示すＲＲ手順を使用できることは明らかである。ＣｏＡ１、ＣｏＡ３は、ＣｏＴｉメッセージ８２１、８２２がそれぞれＣｏＡ１、ＣｏＡ３を送信元アドレスとして送信されるので、有効性がテストされる。ここで、ＭＮ１はＣｏＴｉ[1]メッセージ８２１にはダウンリンクＣｏＡ２を記述し、また、ＣｏＴｉ[2]メッセージ８２２にはダウンリンクＣｏＡ４を記述する。したがって、ＣｏＴ[1]メッセージ８４１はＣｏＡ２あてに送信されてＣｏＡ２の到達性がテストされ、また、ＣｏＴ[2]メッセージ８４２はＣｏＡ４あてに送信されてＣｏＡ４の到達性がテストされる。最後にペアリングＢＵメッセージ８５０が送信されて複数のＣｏＡ１〜ＣｏＡ４のＣＮへの複数ＣｏＡ登録が完了する。ペアリングＢＵメッセージ８５０は当然に、アップリンクＣｏＡを送信元アドレスとして送信される。
【００５８】
悪意のある（あるいは誤った動作をする）任意のノード（モバイルノードも含む）がアップリンクＣｏＡをダウンリンク・トラフィックに、また、ダウンリンクＣｏＡをアップリンク・トラフィックに使用しようとする場合への対応方法として、ＭＮ１はペアリングＢＵメッセージ８５０内に、どのＣｏＡがアップリンクＣｏＡか、どのＣｏＡがダウンリンクＣｏＡかを明示することが望ましい。これは、例えば各ＣｏＡに関するバインディング・ユニーク識別子サブオプション内にフラグを使用することにより実現することができる。これにより、ペアリングＢＵメッセージ８５０を受け取ったＣＮ３は、アップリンクＣｏＡとダウンリンクＣｏＡを区別して管理する際の識別が簡単になり、実施したテストに対してＢＵメッセージ内のＣｏＡの使用方法が不整合であれば登録を拒絶したり、登録後であっても実際の使用方法が不整合である場合は、実際の通信を拒絶したり、ＣｏＡの使用方法が不整合である旨を通知したりできる。なお、別の方法として、ＣＮ３が、テストメッセージを送信する際に、後にＢＵメッセージで受け取るＣｏＡがアップリンクＣｏＡであるかダウンリンクＣｏＡであるかを識別できるように情報を付加したり、ＣｏＡの使用方法を記録したりしておいても良い。すなわち、ＣＮ３が、ＣｏＴｉメッセージ及びＣｏＴメッセージの送受信時に確認するＣｏＡ（の使用方法＝安全な使用が保証されている内容）と、モバイルノード１によるＢＵでのＣｏＡの申請もしくは実際の使用方法に矛盾がないことを確認できるようにすることが望ましい。
【００５９】
さらなる対抗策として、ＣＮ３はアップリンクＣｏＡ及びダウンリンクＣｏＡの対に対するＣｏＫを生成する際に特定の順番を使用する。ＣｏＡ１をアップリンクＣｏＡ、ＣｏＡ２をダウンリンクＣｏＡとする場合を例に説明すると、ＣＮ３がＣｏＴ[1]メッセージ８４１内に含ませるＣｏＫを生成する場合に、このＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜ＣｏＡ２｜nonce｜１））
すなわち、アップリンクＣｏＡ１は常に、ダウンリンクＣｏＡ２の前に配置される。
【００６０】
さらに、各ＣｏＡに対して異なるＣｏＫを生成する際に、ＣＮ３はハッシュ計算において異なる８ビットを使用する。この場合、アップリンクＣｏＡ１に対するＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ１｜nonce｜３））
また、ダウンリンクＣｏＡ２に対するＣｏＫは、以下のハッシュ値の最初の６４ビットで生成される。
ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ２｜nonce｜４））
【００６１】
ここで、８ビット値「３」、「４」は、アップリンクＣｏＡ１をダウンリンクＣｏＡ２と区別するために使用される。当業者であれば、アップリンクＣｏＡに対するＣｏＫをダウンリンクＣｏＡに対するＣｏＫと区別できれば、他の８ビット値でもよいことは明らかである。
【００６２】
さらなる対抗策として、ＣＮ３はアップリンクＣｏＡとダウンリンクＣｏＡに対して異なるノンス値を使用してもよい。例えば特定のノンス・インデックス＝１に対して、ＣｏＡがアップリンクＣｏＡか、ダウンリンクＣｏＡか、通常のＣｏＡかに応じて異なるノンス・インデックスを使用する。ここで、通常のＣｏＡに対しては、標準のＲＲ手順に従って到達性と有効性の両方がテストされる。
【００６３】
<<ＣｏＴの喪失>>
上記の実施の形態では、ペアリングＢＵメッセージ８５０はすべてのＣｏＡを登録すること（バルクＢＵすること）を仮定しているが、当業者であれば、必ずしも必要はないことは理解できる。例えばあるＣｏＴｉメッセージまたはＣｏＴメッセージがネットワークの輻輳のために破棄された場合、ＭＮ１はＣｏＴメッセージを受信しない。この場合、ＭＮ１はペアリングＢＵメッセージ８５０による登録を継続することを選択してもよい。これを実現する方法の１つとして、ＭＮ１はＲＲ手順を最初に開始した時にタイマをセットアップし、タイマが満了すると、ＭＮ１はそれまでに受信したＣｏＴメッセージに対するペアリングＢＵメッセージ８５０を送信する。その後に受信したＣｏＴメッセージに対しては、さらにＢＵメッセージまたはペアリングＢＵメッセージ８５０を送信することができる。もちろん、ペアリングＢＵメッセージ８５０を送信する前に、ＨｏＴメッセージ８３０は受信済みでなければならない。
【００６４】
他の方法として、ＭＮ１はタイマの満了を待つことなく、ＨｏＴメッセージ８３０を受信すると、できるだけ早くペアリングＢＵメッセージ８５０を送信する。ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換は、ＭＮ１とＨＡ２の間では双方向トンネルを通らなければならないため、ＣｏＴｉメッセージ８２１、８２２とＣｏＴメッセージ８４１、８４２の交換より長くなるので、この方法はうまく動作する。したがって、通常では、ＭＮ１はＨｏＴメッセージ８３０を受信するまでに、ＣｏＴメッセージ８４１、８４２のうち、すべてではなくとも幾つかは受信する。ＭＮ１が複数のＣｏＡに対してプレファレンスが割り当てられている場合には、さらに他の方法を用いることができる。この場合には、ＭＮ１は、より多くの望ましい（優先性の高い）ＣｏＡに対するＣｏＴメッセージを受信すると、残りのＣｏＴメッセージを待つことなく、できるだけ早くペアリングＢＵメッセージ８５０を送信する。
【００６５】
ＭＮ１は、あるＣｏＡのみに対するペアリングＢＵメッセージ８５０を送信するときには、前述したパラメータを調整する必要がある。望ましい方法は、ＭＮ１が受信に成功したＣｏＴメッセージに対するＣｏＡを選択し、選択したＣｏＡのみをペアリングＢＵメッセージ８５０内に含ませることである。このような部分的なペアリングＢＵメッセージ８５０内にＣｏＡなどのパラメータを構成する手順は、本実施の形態と同様であり、選択したＣｏＡがあたかもＭＮ１のすべてのＣｏＡかのようになる。
【００６６】
本発明の目的は、複数のＣｏＡを登録する際のメッセージの削減をすることにある。このＣＮ３への複数ＣｏＡ登録は通常では３つの場合に起こる。１つの場合とは、ＭＮ１が最初にスタートアップし、同時にすべてのＣｏＡを取得したときである。このとき、ＭＮ１は同時にＣＮ３への複数ＣｏＡ登録を実行する。第２の場合とは、より一般的であるが、ＭＮ１が最初にＣＮ３と通信を確立したときである。このとき、ＣＮ３はＭＮ１のいずれのＣｏＡも知得していず、ＭＮ１がＣＮ３に複数ＣｏＡ登録を実行する。第３の場合とは、ＭＮ１が比較的長時間、移動しないで、すべてのバインディングの有効期間が満了しかかったときである。このとき、ＭＮ１はすべてのバインディングを同時に更新するためにＣＮ３への複数ＣｏＡ登録を実行する。
【００６７】
ＣＮ３への複数ＣｏＡ登録が発生する他の場合として、ＭＮ１がハンドオーバして１つまたは少数のＣｏＡが変更されたときである。他の殆どのＣｏＡは同じである。このような場合、ＭＮ１はすべての複数ＣｏＡ登録済みのＣｏＡを含ませてＣＮへの複数ＣｏＡ登録を実行する必要があるかもしれないが、変更された新しいＣｏＡに対するＲＲ手順を実行するのみでよい。この種のバインディング・アップデートを実行する際、ＭＮ１は、有効期間が残っていればＨｏｋを再取得する必要はない。しかし、通常のＲＲ手順では、ＭＮ１にとって、以前に取得したＨｏｋが未だ有効か否かを知得する手段がないので、通常のＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換を実行する必要があるかもしれない。ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換は、ＭＮ１とＨＡ２との双方向トンネルを通る必要があるので、時間がかかる。これにより、ＣＮ３を最新のＣｏＡで更新させる潜在性を増加させることができる。
【００６８】
この実施の形態において、複数のＣｏＡをＨｏＡにバインディングする更なる利点は、ＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換による不必要な遅延を防止することにある。つまり、現在存在する有効な第１のＣｏＡを利用して、この有効な第１のＣｏＡに対して新しい第２のＣｏＡのバインディングを確立する。すなわち、ＨｏＡに対する第１のＣｏＡのバインディングが現在存在すると推定して、第１のＣｏＡに対する第２のＣｏＡのバインディングにより、ＨｏＡに対する第２のＣｏＡのバインディングを意味するようにする。
【００６９】
図３を参照してこの実施の形態についてさらに説明する。ＭＮ１はインタフェース１１、１２、１３にそれぞれ割り当てられたＣｏＡ１、ＣｏＡ２、ＣｏＡ３を有する。ある時点１００で、ＭＮ１のＨｏＡに対するＣｏＡ１、ＣｏＡ２、ＣｏＡ３のＣＮ３への複数ＣｏＡ登録が完了していて、ＣＮ３が既に有効なバインディングを有するものと仮定する。その後の時点１１０でＭＮ１のインタフェース１３でハンドオーバが起こり、ＣｏＡ３が変化したものとする。図１、図２に示すＨｏＴｉメッセージ８１０とＨｏＴメッセージ８３０の交換による遅延を防止するために代わりに、ＭＮ１は、現在有効な、ＨｏＡに対するＣｏＡ２のバインディングを利用して新しいＣｏＡ３のバインディングを確立する。
【００７０】
図３では、ＭＮ１は、ＣｏＡ３、ＣｏＡ２をそれぞれ送信元アドレスとしてＣｏＴｉ[1]メッセージ１２１、ＣｏＴｉ[2]メッセージ１２２を送信する。ＭＮ１は、それぞれ対応する（ＣｏＡ３のＣｏＫを含む）ＣｏＴ[1]メッセージ１４１と、（ＣｏＡ２のＣｏＫを含む）ＣｏＴ[2]メッセージ１４２を受信すると、２つのＣｏＫを使用してＣｏＡ３をＣｏＡ２にバインディングする特別なＢＵメッセージ１５０を送信する。ＢＵメッセージ１５０は望ましくは、ＣＮ３に対してＣｏＡ３とＣｏＡ２のバインディングと、ＣｏＡ２とＨｏＡのバインディングと、ＣｏＡ３とＨｏＡの新しいバインディングを指示する特別な信号を含むべきである。
【００７１】
当業者であれば、ハンドオーバがなくても、例えば新しいインタフェースの電源がオンになって新しいＣｏＡが追加された場合にも同じ手順を用いることができることは明らかである。さらに、ＭＮ１とＣＮ３が高信頼性ネットワークに存在する場合には、当業者であれば、前述した手順により、１つのＣｏＴｉ／ＣｏＴメッセージの交換を省略できることは明らかである。この場合、図３ではＣｏＴｉ[2]メッセージ１２２とＣｏＴ[1]メッセージ１４１を省略することができる。代わりに、ＣｏＴｉ[1]メッセージ１２１はＣｏＡ２を追加のＣｏＡとして記述して、ＣｏＴｉ[1]メッセージ１２１の応答であるＣｏＴ[2]メッセージ１４２は、ＣｏＡ２とＣｏＡ３のＣｏＫを含む。このＣｏＡ２とＣｏＡ３のＣｏＫは、ＢＵメッセージ１５０内においてＣｏＡ３とＣｏＡ２のバインディング、さらにはＣｏＡ３とＨｏＡのバインディングを確立するために使用される。この方法は同様に、高信頼性ネットワークに位置していなくても、ＣｏＡ３がアップリンクＣｏＡのみに使用され、ＣｏＡ２がダウンリンクＣｏＡのみに使用される場合にも適用することができる。
【００７２】
ここで、当業者であれば、図３において、ＣｏＴｉ[2]メッセージ１２２とＣｏＴ[2]メッセージ１４２は、実際にはＣｏＴｉメッセージとＣｏＴメッセージでなく、事実上、ルート最適化を用いて、ＨｏＴｉメッセージとＨｏＴメッセージがＣｏＡ２のＨｏＡに対するバインディングで送信されたものであることは明らかである。すなわち、図３におけるＣｏＴｉ[2]メッセージ１２２は、実際にはホームアドレス・デスティネーション・オプションによる送信元アドレス＝ＣｏＡ２で送信されたＨｏＴｉメッセージであり、ＣｏＴ[2]メッセージ１４２は、実際にはＨｏＡを含むルーティングヘッダでＣｏＡ２あてに送信されたＨｏＴメッセージである。当業者であれば、上記の説明は、本発明の望ましい実施の形態であって、本発明を逸脱しない限り、種々の変形が可能であることは明らかである。
【００７３】
＜端末のインタフェースの数について＞
明細書内では、ＭＮ１が複数インタフェース１１、１２、１３、１４を持ち、それぞれがＣｏＡを持つ場合を前提としているが、発明の内容を実施する意味では実際の物理インタフェースがいくつあるかは問題ではない。更にIPv6の仕様では、一つのインタフェースに複数のアドレスを割り振ることも可能となっているので、一つのインタフェースに複数のＣｏＡが割り振られることも考えられる。また、１つの無線部を複数の接続方式で共用し、ネットワーク・インタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続しているのと同等に動作できるよう構成されていてもよい。
【００７４】
＜ペアを作るＣｏＡの選別について＞
明細書内では、ＣｏＡの数が奇数である場合にどのように処理するとより効率が良いかを記載しているが、それ以前に、必ずしもＭＮ１が持つ（持つであろう）全てのＣｏＡがペアリングに適しているとは限らないため、それを選別する必要がある。例えば、高信頼ネットワークでの実施例では、通信ネットワークの信頼性が高いことを元にペアリングを実施しているが、ＭＮ１の全てのインタフェース１１、１２、１３、１４がそういったネットワークに接続しているとは限らないし、全てのＣＮ３がそういったネットワークに属しているとも限らない。また、ハンドオーバ前後でＭＮ１の接続するネットワークの信頼性の状態が変化するかもしれない。このような場合は、信頼性の高いネットワークに接続しているＣｏＡのみをまず選び出し、ペアを作ったり、信頼性の高いネットワーク以外に接続しているＣＮ３に対しては通常のＲＲを行なうようにしたりできるよう事前に判定が必要である。また、片方向通信の実施例では、送信用のＣｏＡと受信用のＣｏＡをペアにしているが、一方のＣｏＡだけが多いというような場合は残りのＣｏＡのいくつか（残り全て）は通常のRRを行なわざるを得ないかもしれない。更に、双方向で使用するＣｏＡに関しては、ペアリングの候補から外しておかなければならない。また、高信頼ネットワークの場合と片方向通信の場合が混在する場合もあり、更にその他の（本発明が適用可能な）場合との混在もある。この場合も、まず適切なペアリングと、従来の方法でＲＲを行なう場合とを選別し動作しなければならない。
【００７５】
＜その他＞
明細書内では、主にＣｏＡのペアが2つ（ＣｏＡが４つ）の場合を例として説明したが、1つのペア（ＣｏＡが２つ）でもよいし、たくさんあってもよい。また、主にペアリングＢＵをまとめてバルクＢＵしていることを前提として説明（図面も含む）しているが、ペアリング毎に行なうペアリングＢＵでも全く問題ない。さらに、前述のようにそれぞれのＣｏＡを個別にＢＵすることもでき、それらを組み合わせてもよい。また、ペアリングＢＵをまとめてバルクＢＵする際のバルクＢＵの構成方法は、本明細書の記載に関わらず、任意の方法を用いることができる。
【００７６】
図４はＭＮ１及びＣＮ３において本発明のＲＲ手順を実現する機能ブロック１１００を示す。機能ブロック１１００は１以上のネットワーク・インタフェース１１１０と、ルーティング・ユニット１１２０と上位層１１３０を有する。ネットワーク・インタフェース１１１０は、他のノードと通信媒体を介して通信するために必要な全てのハードウエア及びソフトウエアを有する機能ブロックである。ネットワーク・インタフェース１１１０は通信装置、ファームウエア、ドライバ、及びレイヤ１（物理層）、レイヤ２（データリンク層）の通信プロトコルを表す。当業者であれば、機能ブロック１１００は１以上のネットワーク・インタフェース９００を含むことは明らかである。
【００７７】
ルーティング・ユニット１１２０は、パケットを上位層１１３０のどのプログラムにルーティングさせるか、また、ネットワーク・インタフェース１１１０のどのインタフェースにルーティングさせるかを決定する。ルーティング・ユニット１１２０は、レイヤ３（ネットワーク層）プロトコル、例えばインタネット・プロトコル・バージョン４又は６を実行する。シグナル／データパス１１９２により、ルーティング・ユニット１１２０は、パケットをネットワーク・インタフェース１１１０に転送したり、ネットワーク・インタフェース１１１０からパケットを受け取ったりすることができる。同様に、シグナル／データパス１１９４により、ルーティング・ユニット１１２０は、パケットを上位層１１３０に転送したり、上位層１１３０からパケットを受け取ったりすることができる。
【００７８】
上位層１１３０は、通信スタックにおけるネットワーク層の上位の全てのプロトコルとプログラムを実行する。このプロトコルとしては、トランスポート層やセッション層のプロトコルを含み、例えばＴＣＰ（Transmission Control Protocol）、ＳＣＴＰ（Stream Control Transport Protocol）を含む。また、上記のプログラムとしては、他のノードと通信するための必要なプログラムとソフトウエアを含む。シグナルパス１１９４により、ルーティング・ユニット１１２０と上位層１１３０の間でパケットを転送できる。
【００７９】
ルーティング・ユニット１１２０内には、ルーティング・エントリを格納するルーティング・テーブル１１４０と、モビリティ・サポート・モジュール１１５０が設けられている。モビリティ・サポート・モジュール１１５０は、ＭＮ１のモビリティ・サポートを可能にしたり、ＣＮ３がＭＮ１との間でルート最適化された通信を可能にしたりする。ルーティング・テーブル１１４０の各エントリは、特定のプリフィックスのあて先にパケットをルーティングさせるための情報を含み、通常ではパケットを転送する次のホップのアドレス又はネットワーク・インタフェース識別子を含む。
【００８０】
モビリティ・サポート・モジュール１１５０内のＲＲモジュール１１６０は、ＲＲ手順によりメッセージを交換し、本実施の形態では、複数ＣｏＡに関する情報を追跡する。この情報は、ＭＮ１にあってはバインディング・アップデート・リスト（ＢＵＬ）に、ＣＮ３にあってはバインディング・キャッシュ・エントリ（ＢＣＥ）に格納される。図４では、モビリティ・サポート・モジュール１１５０内にＢＵＬ／ＢＣＥ１１７０として示されている。この情報は、ＣｏＴｉ／ＣｏＴメッセージのＣｏＡと、関連するノンス及びクッキーを含む。
【００８１】
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
【産業上の利用可能性】
【００８２】
本発明は、モバイルノードと相手先の通信ノードとの間で認証を行うＲＲ手続を行う場合のメッセージ数を減少させることができるという効果を有し、Ｍｏｎａｍｉ６などに利用することができる。
【図面の簡単な説明】
【００８３】
【図１】本発明の一実施の形態の通信シーケンスを示す説明図
【図２】本発明の一実施の形態の他の通信シーケンスを示す説明図
【図３】本発明の一実施の形態のさらに他の通信シーケンスを示す説明図
【図４】図１、図２及び図３におけるモバイルノードと通信相手の構成を機能的に示すブロック図
【図５】従来のＭｏｎａｍｉ６におけるバルクＢＵを示す説明図
【図６】本発明が解決しようとする課題を示す説明図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2009066439.tif 000009
【図２】
2009066439.tif 000010
【図３】
2009066439.tif 000011
【図４】
2009066439.tif 000012
【図５】
2009066439.tif 000013
【図６】
2009066439.tif 000014
【国際調査報告】
2009066439.tif 000015
2009066439.tif 000016
2009066439.tif 000017
2009066439.tif 000018