(57)【要約】  モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させる技術が開示され、その技術によればＣＮ３が、ＭＮ１の複数のインタフェースの各々から送信された複数のＣｏＴｉメッセージを受信して、複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数のＣｏＴメッセージの各々でＭＮに送信し、ＭＮが、複数のＣｏＴメッセージの各署名用トークンを用いて複数の気付けアドレスに対して共通の鍵を生成し、共通の鍵を用いて複数の気付けアドレスに対して共通の認証コードを生成し、複数の気付けアドレス及び共通の認証コードを含むバルク・バインディング・アップデートメッセージをＣＮに送信し、ＣＮはバルク・バインディング・アップデートメッセージ内の複数の気付けアドレスに対する共通の認証コードを認証する。また、ＣｏＴｉ、ＣｏＴをバルクメッセージで送信し、ＢＵメッセージをＣｏＡ毎に個別に送信する。
2008053955.tif 000002
【特許請求の範囲】
【請求項１】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信するステップと、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するステップとを、
有する通信方法。
【請求項２】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
有する通信システム。
【請求項３】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの各々からそれぞれ第１のメッセージを前記相手先の通信ノードに個々に送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で自身に送信した場合に、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するようにしたモバイルノード。
【請求項４】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを自身に送信した場合、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
有する通信ノード。
【請求項５】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信するステップと、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信するステップと、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するステップとを、
有する通信方法。
【請求項６】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
有する通信システム。
【請求項７】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで自身に送信した場合、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信した場合、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するようにしたモバイルノード。
【請求項８】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを自身に送信した場合、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを自身に送信した場合、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを自身に送信した場合、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
有する通信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のインタフェースを有し、複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法、通信システム、モバイルノード及び通信ノードに関する。
【背景技術】
【０００２】
標準のＭＩＰｖ６（非特許文献１）には、ルート最適化時におけるＣＮがＭＮを認証する手段としてＲＲ（Return Routability）手続が開示されている。ＭＩＰｖ６のＲＲは、ＨｏＡテストによる不正なリダイレクションからの保護と、ＣｏＡテストによるリーチャビリティの確認からなる。【０００３】
一方、Ｍｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）では、モバイルノード（ＭＮ）が複数のインタフェースを有する場合のために種々の提案が成されている。また、モバイルＩＰ（Internet Protocol）を利用するＭＮは、移動先のアドレスである気付けアドレス（ＣｏＡ）を、自身のホームアドレス（ＨｏＡ）を管理するホームエージェント（ＨＡ）に登録し、ＨｏＡあてパケットの転送を依頼する。ＭＮが、複数のＣｏＡを１つのＨｏＡに対して同時に関連付けて登録することができれば、複数のインタフェースを備えるＭＮは、それぞれのインタフェースに割り当てられたＣｏＡを登録することで、インタフェースの状態に応じて使用するＣｏＡを瞬時に切り替えることが可能となる。図６は従来のＭｏｎａｍｉ６におけるバルクＢＵ（バインディング・アップデート）を示す説明図である。非特許文献２には、図６に示すようにＭＮ１が複数のＣｏＡを１つのＨｏＡに関連付けてＨＡ２に登録（Bulk mCoA BU）する手法が記述されている。ルート最適化（ＲＯ：Route Optimazation）を行う手段については、Ｍｏｎａｍｉ６には、何らの記載はない。
【非特許文献１】D.Johnson, C.Perkins and J.Arkko, “Mobility Support in IPv6”, RFC3775, June 2004
【非特許文献２】R.Wakikawa, T.Ernst, K.Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 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）手続を行う場合のメッセージ数を減少させることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図
【図２】第１の実施の形態の通信シーケンスを示す説明図
【図３】本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図
【図４】第２の実施の形態の通信シーケンスを示す説明図
【図５】第１、第２の実施の形態を考察した説明図
【図６】従来のＭｏｎａｍｉ６におけるバルクＢＵを示す説明図
【図７】本発明が解決しようとする課題を示す説明図
【発明を実施するための最良の形態】
【００１９】
以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
図１は本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図、図２は第１の実施の形態の通信シーケンスを示す。第１の実施の形態では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴの各メッセージを送信し、ＢＵメッセージを複数のＣｏＡに対して一括（バルクＢＵ）で送信する。なお、図１では、ＭＮ１は２つのインタフェースを有し、ＣｏＡが２つである場合を示す。このため、ＣｏＴｉメッセージとＣｏＴメッセージも２つのみ（ＣｏＴｉ１、ＣｏＴｉ２）、（ＣｏＴ１、ＣｏＴ２）を示す。【００２０】
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、各クッキーＫ１[1]〜[n]を含むＣｏＴｉ[1]〜[n]メッセージを個別に、かつ直接送信する。ここで、ＭＮ１からＨＡ２あてのメッセージのパケットのアドレスについては、ＣＮあてパケットをＨＡあてパケットでカプセル化したものである。また、ＣｏＴｉ[1]〜[n]メッセージの各パケットの送信元アドレスは、それぞれＣｏＡ[1]〜[n]である。【００２１】
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、ＣｏＴｉ[1]〜[n]メッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０   ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、１））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、１））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、１））【００２２】
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むＣｏＴ[1]〜[n]メッセージを直接、かつ個別に送信する。
ＨｏＴ   ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ[1]：（Ｋ１[1]，Ｔ１[1]，ｊ・・・）
ＣｏＴ[2]：（Ｋ１[2]，Ｔ１[2]，ｊ・・・）
・・・・・
ＣｏＴ[n]：（Ｋ１[n]，Ｔ１[n]，ｊ・・・）【００２３】
＜課題＞
ここで、上記の（１）、（２）における個々のＣｏＡ毎の手順は、標準のＭＩＰｖ６のＲＲ手順（ＲＦＣ３７７５）に記載されており、公知である。また、このＢＵメッセージ送信手順では、ＣｏＡ[1]〜[n]個々のＢＵメッセージを送信するために、以下のようにトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成する。
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
また、このＫbm、ＣｏＡ、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名であるＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）【００２４】
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）【００２５】
ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成してＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージを個別にＭＮ１に返信する。このため、ＢＵメッセージの数がＣｏＡの数だけ必要になる。また、Ｍｏｎａｍｉ６では、ＢＵの認証という概念がない。【００２６】
＜第１の実施の形態の解決策＞
（３）これに対し、第１の実施の形態では、ＢＵメッセージの数を減少してバルクＢＵメッセージを生成するために、ＭＮ１はまず、以下のように全てのトークンのハッシュ値からＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、
Ｋbm(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
次いで、このＫbm(common)と、一例として全てのＣｏＡ[1]〜[n]などから以下のようにして、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成する。
ＭＡＣ(common)：ＨＭＡＣ＿ＳＨＡ１（Ｋbm(common)，（ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ＣＮアドレス，ＢＵ））
そして、ＭＮ１は、ＣＮ３に対するバルクＢＵメッセージとして、以下の内容を含むＣｏＡ[1]〜[n]に対して共通のメッセージを生成し、送信する。
Bulk ＢＵ（ＨｏＡ，ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ）【００２７】
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm(common)を生成し、次いでこのＫbm(common)などからＭＡＣ(common)をそれぞれ生成してバルクＢＵメッセージ内のＭＡＣ(common)と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージをバルクメッセージでＭＮ１に返信する。ここで、ＭＮ１がバルクＢＵメッセージを送信するインタフェースと、バルクＢＡメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。【００２８】
次に、第１の実施の形態により、個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）をＣＮ３が確認できることを説明する。
（１）では、ＭＮ１はＣｏＡ[1]〜[n]毎にユニークな各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成し、ＣＮ３に対し、各クッキーＫ１[1]〜[n]をそれぞれ含むＣｏＴｉ[1]〜[n]メッセージを個別に送信する。
（２）では、ＣＮ３はＣｏＴｉ[1]〜[n]メッセージを受け取ると、ＣｏＡ[1]〜[n]毎にユニークな各署名用トークンＴ１[1]〜[n]を生成し、ＭＮ１に対し、署名用トークンＴ１[1]〜[n]をそれぞれを含むＣｏＴ[1]〜[n]メッセージを個別に送信する。
（３）では、ＭＮ１はＣｏＴ[1]〜[n]メッセージを受け取ると、署名用トークンＴ１[1]〜[n]などからＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、このＫbm(common)と全てのＣｏＡ[1]〜[n]などから、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成し、ＣＮ３に対し、この共通のＭＡＣ(common)と全てのＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]を含むバルクＢＵメッセージを送信する。【００２９】
したがって、ＭＮ１がバルクＢＵメッセージをＣＮ３に送信しても、ＣＮ３は個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。なお、全てのＣｏＡについてreachableを問題にしない場合には、共通のＭＡＣ(common)を生成する際に用いるＣｏＡは全てではなく、１以上の代表ＣｏＡを用いてもよい。その例を以下に示す（代表ＣｏＡ＝ＣｏＡ[5]，ＣｏＡ[2]，ＣｏＡ[7]）。
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[5]，ＣＮアドレス，ＢＵ）
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣｏＡ[7]，ＣＮアドレス，ＢＵ）【００３０】
＜第２の実施の形態＞
次に、図３、図４を参照して第２の実施の形態について説明する。図３は、本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図、図４は第２の実施の形態の通信シーケンスを示す説明図である。第２の実施の形態では、ＣｏＴｉ、ＣｏＴをバルクメッセージで送信し、ＢＵメッセージをＣｏＡ毎に個別に送信する。
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]及びＣｏＡ[1]〜[n]を含むバルクＣｏＴｉメッセージを直接送信する。バルクＣｏＴｉメッセージのパケットの送信元アドレスは、ＣｏＡ[1]〜[n]の代表ＣｏＡである。【００３１】
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、バルクＣｏＴｉメッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０   ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、０））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、０））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、０））【００３２】
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むバルクＣｏＴメッセージを直接送信する。
ＨｏＴ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ：（Ｋ１[1]，Ｋ１[2]〜Ｔ１[n]，Ｔ１[1]，Ｔ１[2]〜Ｔ１[n]，ｊ・・・）
ここで、ＭＮ１がバルクＣｏＴｉメッセージを送信するインタフェースと、バルクＣｏＴメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。【００３３】
（３）ＭＮ１はトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
次いで、このＫbm[1]、Ｋbm[2]〜Ｋbm[n]、ＣｏＡ[1]、ＣｏＡ[2]〜[n]、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名用のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）【００３４】
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）【００３５】
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成して個々のＢＵメッセージ内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、個々のバインディング確認（ＢＡ）メッセージをＭＮ１に返信する。【００３６】
（５）ＭＮ１は個々のＢＵを受け取ると、ＣＮ３が個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）を確認できるように、ＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対して共通のreachableチェックキーＫrc(common)を生成し、ＣＮ３に対し、Ｋrc(common)を含むバルクＢＡackメッセージを送信する。
Ｋrc(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
ここで、このＫrc(common)は、第１の実施の形態において全てのトークンのハッシュ値から生成した、ＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)と同じである。このため、第２の実施の形態においても同様に、バルクＣｏＴｉメッセージ、バルクＣｏＴメッセージを送信しても、ＣＮ３は個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。【００３７】
＜第１、第２の実施の形態の考察＞
図５はＣｏＴｉ、ＣｏＴ、ＢＵメッセージと個別（Ind）、バルク（Bulk）の組み合わせを示す。まず、reachabilityとAmplificationについて考察する。ここでreachabilityとは、各ＣｏＡのインタフェースへパケットが到達することが確認できることを意味する。また、Amplificationとは、問い合わせなどのメッセージに対して、その応答のメッセージの方が多くなる（アンプリファイされる）ことを意味し、輻輳を引き起こしやすくするためアンプリファイされないことが望ましい。
・ケース１（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース２（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Ind：第２の実施の形態）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース３（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Bulk）は、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース４（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Ind）も、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース５（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース６（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Ind）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース７（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Bulk：第１の実施の形態）は、reachabilityが個別ＣｏＴ、バルクＢＵにより安全にチェックされるので、ＯＫである。
・ケース８（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Ind：図６，課題）は、ＯＫである。【００３８】
次に、上記のＯＫであったケース２、６、７、８のメッセージ数（及びメッセージのラウンドトリップ回数）について考察する。下記でｎはＣｏＡの数を示す。
・ケース８：
ｎＣｏＴｉ＋ｎＣｏＴ＋ｎＢＵ＝３ｎ messages, 1.5 round trips
・ケース２：
１ＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝２ｎ＋３ messages, 2.5 round trips
・ケース６：
ｎＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝３ｎ＋２ messages, 2.5 round trips
・ケース７：
ｎＣｏＴｉ＋ｎＣｏＴ＋１ＢＵ＝２ｎ＋１ messages, 1.5 round trips
以上により、ケース６のメッセージ数はケース８（図６，課題）より多くなるので良い解決策とは言えない。ケース７（第１の実施の形態）のメッセージ数は、ｎ＞２の場合、ケース８（図６，課題）より少なくなるので、最善の解決策である。ケース２（第２の実施の形態）は、ケース８（図６，課題）よりラウンドトリップの回数が多くはなるが、ｎ＞４の場合、メッセージ数が少なくなり改善されている。
【産業上の利用可能性】
【００３９】
本発明は、モバイルノードと相手先の通信ノードとの間で認証を行うＲＲ手続を行う場合のメッセージ数を減少させることができるという効果を有し、Ｍｏｎａｍｉ６などに利用することができる。
【図１】
2008053955.tif 000003
【図２】
2008053955.tif 000004
【図３】
2008053955.tif 000005
【図４】
2008053955.tif 000006
【図５】
2008053955.tif 000007
【図６】
2008053955.tif 000008
【図７】
2008053955.tif 000009
【手続補正書】
【提出日】平成21年4月15日(2009.4.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信するステップと、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するステップとを、
有する通信方法。
【請求項２】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
有する通信システム。
【請求項３】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの各々からそれぞれ第１のメッセージを前記相手先の通信ノードに個々に送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で自身に送信した場合に、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するようにしたモバイルノード。
【請求項４】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを自身に送信した場合、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
有する通信ノード。
【請求項５】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信するステップと、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信するステップと、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するステップとを、
有する通信方法。
【請求項６】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
有する通信システム。
【請求項７】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで自身に送信した場合、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信した場合、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するようにしたモバイルノード。
【請求項８】
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを自身に送信した場合、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを自身に送信した場合、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを自身に送信した場合、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
有する通信ノード。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のインタフェースを有し、複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法、通信システム、モバイルノード及び通信ノードに関する。
【背景技術】
【０００２】
標準のＭＩＰｖ６（非特許文献１）には、ルート最適化時におけるＣＮがＭＮを認証する手段としてＲＲ（Return Routability）手続が開示されている。ＭＩＰｖ６のＲＲは、ＨｏＡテストによる不正なリダイレクションからの保護と、ＣｏＡテストによるリーチャビリティの確認からなる。
【０００３】
一方、Ｍｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）では、モバイルノード（ＭＮ）が複数のインタフェースを有する場合のために種々の提案が成されている。また、モバイルＩＰ（Internet Protocol）を利用するＭＮは、移動先のアドレスである気付けアドレス（ＣｏＡ）を、自身のホームアドレス（ＨｏＡ）を管理するホームエージェント（ＨＡ）に登録し、ＨｏＡあてパケットの転送を依頼する。ＭＮが、複数のＣｏＡを１つのＨｏＡに対して同時に関連付けて登録することができれば、複数のインタフェースを備えるＭＮは、それぞれのインタフェースに割り当てられたＣｏＡを登録することで、インタフェースの状態に応じて使用するＣｏＡを瞬時に切り替えることが可能となる。図６は従来のＭｏｎａｍｉ６におけるバルクＢＵ（バインディング・アップデート）を示す説明図である。非特許文献２には、図６に示すようにＭＮ１が複数のＣｏＡを１つのＨｏＡに関連付けてＨＡ２に登録（Bulk mCoA BU）する手法が記述されている。ルート最適化（ＲＯ：Route Optimazation）を行う手段については、Ｍｏｎａｍｉ６には、何らの記載はない。
【非特許文献１】D.Johnson, C.Perkins and J.Arkko, "Mobility Support in IPv6", RFC3775, June 2004
【非特許文献２】R.Wakikawa, T.Ernst, K.Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 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）手続を行う場合のメッセージ数を減少させることができる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
図１は本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図、図２は第１の実施の形態の通信シーケンスを示す。第１の実施の形態では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴの各メッセージを送信し、ＢＵメッセージを複数のＣｏＡに対して一括（バルクＢＵ）で送信する。なお、図１では、ＭＮ１は２つのインタフェースを有し、ＣｏＡが２つである場合を示す。このため、ＣｏＴｉメッセージとＣｏＴメッセージも２つのみ（ＣｏＴｉ１、ＣｏＴｉ２）、（ＣｏＴ１、ＣｏＴ２）を示す。
【００１９】
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、各クッキーＫ１[1]〜[n]を含むＣｏＴｉ[1]〜[n]メッセージを個別に、かつ直接送信する。ここで、ＭＮ１からＨＡ２あてのメッセージのパケットのアドレスについては、ＣＮあてパケットをＨＡあてパケットでカプセル化したものである。また、ＣｏＴｉ[1]〜[n]メッセージの各パケットの送信元アドレスは、それぞれＣｏＡ[1]〜[n]である。
【００２０】
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、ＣｏＴｉ[1]〜[n]メッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０   ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、１））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、１））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、１））
【００２１】
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むＣｏＴ[1]〜[n]メッセージを直接、かつ個別に送信する。
ＨｏＴ   ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ[1]：（Ｋ１[1]，Ｔ１[1]，ｊ・・・）
ＣｏＴ[2]：（Ｋ１[2]，Ｔ１[2]，ｊ・・・）
・・・・・
ＣｏＴ[n]：（Ｋ１[n]，Ｔ１[n]，ｊ・・・）
【００２２】
＜課題＞
ここで、上記の（１）、（２）における個々のＣｏＡ毎の手順は、標準のＭＩＰｖ６のＲＲ手順（ＲＦＣ３７７５）に記載されており、公知である。また、このＢＵメッセージ送信手順では、ＣｏＡ[1]〜[n]個々のＢＵメッセージを送信するために、以下のようにトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成する。
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
また、このＫbm、ＣｏＡ、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名であるＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）
【００２３】
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）
【００２４】
ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成してＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージを個別にＭＮ１に返信する。このため、ＢＵメッセージの数がＣｏＡの数だけ必要になる。また、Ｍｏｎａｍｉ６では、ＢＵの認証という概念がない。
【００２５】
＜第１の実施の形態の解決策＞
（３）これに対し、第１の実施の形態では、ＢＵメッセージの数を減少してバルクＢＵメッセージを生成するために、ＭＮ１はまず、以下のように全てのトークンのハッシュ値からＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、
Ｋbm(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
次いで、このＫbm(common)と、一例として全てのＣｏＡ[1]〜[n]などから以下のようにして、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成する。
ＭＡＣ(common)：ＨＭＡＣ＿ＳＨＡ１（Ｋbm(common)，（ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ＣＮアドレス，ＢＵ））
そして、ＭＮ１は、ＣＮ３に対するバルクＢＵメッセージとして、以下の内容を含むＣｏＡ[1]〜[n]に対して共通のメッセージを生成し、送信する。
Bulk ＢＵ（ＨｏＡ，ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ）
【００２６】
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm(common)を生成し、次いでこのＫbm(common)などからＭＡＣ(common)をそれぞれ生成してバルクＢＵメッセージ内のＭＡＣ(common)と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージをバルクメッセージでＭＮ１に返信する。ここで、ＭＮ１がバルクＢＵメッセージを送信するインタフェースと、バルクＢＡメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。
【００２７】
次に、第１の実施の形態により、個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）をＣＮ３が確認できることを説明する。
（１）では、ＭＮ１はＣｏＡ[1]〜[n]毎にユニークな各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成し、ＣＮ３に対し、各クッキーＫ１[1]〜[n]をそれぞれ含むＣｏＴｉ[1]〜[n]メッセージを個別に送信する。
（２）では、ＣＮ３はＣｏＴｉ[1]〜[n]メッセージを受け取ると、ＣｏＡ[1]〜[n]毎にユニークな各署名用トークンＴ１[1]〜[n]を生成し、ＭＮ１に対し、署名用トークンＴ１[1]〜[n]をそれぞれを含むＣｏＴ[1]〜[n]メッセージを個別に送信する。
（３）では、ＭＮ１はＣｏＴ[1]〜[n]メッセージを受け取ると、署名用トークンＴ１[1]〜[n]などからＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、このＫbm(common)と全てのＣｏＡ[1]〜[n]などから、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成し、ＣＮ３に対し、この共通のＭＡＣ(common)と全てのＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]を含むバルクＢＵメッセージを送信する。
【００２８】
したがって、ＭＮ１がバルクＢＵメッセージをＣＮ３に送信しても、ＣＮ３は個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。なお、全てのＣｏＡについてreachableを問題にしない場合には、共通のＭＡＣ(common)を生成する際に用いるＣｏＡは全てではなく、１以上の代表ＣｏＡを用いてもよい。その例を以下に示す（代表ＣｏＡ＝ＣｏＡ[5]，ＣｏＡ[2]，ＣｏＡ[7]）。
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[5]，ＣＮアドレス，ＢＵ）
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣｏＡ[7]，ＣＮアドレス，ＢＵ）
【００２９】
＜第２の実施の形態＞
次に、図３、図４を参照して第２の実施の形態について説明する。図３は、本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図、図４は第２の実施の形態の通信シーケンスを示す説明図である。第２の実施の形態では、ＣｏＴｉ、ＣｏＴをバルクメッセージで送信し、ＢＵメッセージをＣｏＡ毎に個別に送信する。
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]及びＣｏＡ[1]〜[n]を含むバルクＣｏＴｉメッセージを直接送信する。バルクＣｏＴｉメッセージのパケットの送信元アドレスは、ＣｏＡ[1]〜[n]の代表ＣｏＡである。
【００３０】
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、バルクＣｏＴｉメッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０   ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、０））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、０））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、０））
【００３１】
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むバルクＣｏＴメッセージを直接送信する。
ＨｏＴ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ：（Ｋ１[1]，Ｋ１[2]〜Ｔ１[n]，Ｔ１[1]，Ｔ１[2]〜Ｔ１[n]，ｊ・・・）
ここで、ＭＮ１がバルクＣｏＴｉメッセージを送信するインタフェースと、バルクＣｏＴメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。
【００３２】
（３）ＭＮ１はトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
次いで、このＫbm[1]、Ｋbm[2]〜Ｋbm[n]、ＣｏＡ[1]、ＣｏＡ[2]〜[n]、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名用のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）
【００３３】
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）
【００３４】
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成して個々のＢＵメッセージ内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、個々のバインディング確認（ＢＡ）メッセージをＭＮ１に返信する。
【００３５】
（５）ＭＮ１は個々のＢＵを受け取ると、ＣＮ３が個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）を確認できるように、ＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対して共通のreachableチェックキーＫrc(common)を生成し、ＣＮ３に対し、Ｋrc(common)を含むバルクＢＡackメッセージを送信する。
Ｋrc(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
ここで、このＫrc(common)は、第１の実施の形態において全てのトークンのハッシュ値から生成した、ＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)と同じである。このため、第２の実施の形態においても同様に、バルクＣｏＴｉメッセージ、バルクＣｏＴメッセージを送信しても、ＣＮ３は個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。
【００３６】
＜第１、第２の実施の形態の考察＞
図５はＣｏＴｉ、ＣｏＴ、ＢＵメッセージと個別（Ind）、バルク（Bulk）の組み合わせを示す。まず、reachabilityとAmplificationについて考察する。ここでreachabilityとは、各ＣｏＡのインタフェースへパケットが到達することが確認できることを意味する。また、Amplificationとは、問い合わせなどのメッセージに対して、その応答のメッセージの方が多くなる（アンプリファイされる）ことを意味し、輻輳を引き起こしやすくするためアンプリファイされないことが望ましい。
・ケース１（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース２（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Ind：第２の実施の形態）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース３（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Bulk）は、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース４（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Ind）も、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース５（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース６（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Ind）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース７（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Bulk：第１の実施の形態）は、reachabilityが個別ＣｏＴ、バルクＢＵにより安全にチェックされるので、ＯＫである。
・ケース８（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Ind：図６，課題）は、ＯＫである。
【００３７】
次に、上記のＯＫであったケース２、６、７、８のメッセージ数（及びメッセージのラウンドトリップ回数）について考察する。下記でｎはＣｏＡの数を示す。
・ケース８：
ｎＣｏＴｉ＋ｎＣｏＴ＋ｎＢＵ＝３ｎ messages, 1.5 round trips
・ケース２：
１ＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝２ｎ＋３ messages, 2.5 round trips
・ケース６：
ｎＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝３ｎ＋２ messages, 2.5 round trips
・ケース７：
ｎＣｏＴｉ＋ｎＣｏＴ＋１ＢＵ＝２ｎ＋１ messages, 1.5 round trips
以上により、ケース６のメッセージ数はケース８（図６，課題）より多くなるので良い解決策とは言えない。ケース７（第１の実施の形態）のメッセージ数は、ｎ＞２の場合、ケース８（図６，課題）より少なくなるので、最善の解決策である。ケース２（第２の実施の形態）は、ケース８（図６，課題）よりラウンドトリップの回数が多くはなるが、ｎ＞４の場合、メッセージ数が少なくなり改善されている。
【産業上の利用可能性】
【００３８】
本発明は、モバイルノードと相手先の通信ノードとの間で認証を行うＲＲ手続を行う場合のメッセージ数を減少させることができるという効果を有し、Ｍｏｎａｍｉ６などに利用することができる。
【図面の簡単な説明】
【００３９】
【図１】本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図
【図２】第１の実施の形態の通信シーケンスを示す説明図
【図３】本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図
【図４】第２の実施の形態の通信シーケンスを示す説明図
【図５】第１、第２の実施の形態を考察した説明図
【図６】従来のＭｏｎａｍｉ６におけるバルクＢＵを示す説明図
【図７】本発明が解決しようとする課題を示す説明図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008053955.tif 000010
【図２】
2008053955.tif 000011
【図３】
2008053955.tif 000012
【図４】
2008053955.tif 000013
【図５】
2008053955.tif 000014
【図６】
2008053955.tif 000015
【図７】
2008053955.tif 000016
【国際調査報告】
2008053955.tif 000017
2008053955.tif 000018