(57)【要約】本発明の基本的な特徴は、訪問先ネットワークあるいはホームネットワークで「ローム」している移動ノード（１３０）に対して、ＨＭＩＰｖ６サービスを「ブートストラップ」するために、ＡＡＡインフラストラクチャを利用することである。本発明の実施形態では、ＨＭＩＰｖ６サービスのブートストラップは、ＡＡＡインフラストラクチャに基づいて、ＨＭＩＰｖ６サービスに対する移動ノード（１３０）の認証及び認可を含んでいる。重要な状況では、移動ノードが訪問先ネットワーク内をローミングしていて、ＡＡＡインフラストラクチャ（１１０、１２０、１２２）が、訪問先ネットワークと、移動ノードのホームネットワークとをリンクしている。また、本発明は、ホームネットワークあるいは、訪問先ネットワーク以外の他のネットワークに配置されるＭＡＰ（１２５）を持つ可能性をサポートしている。ＡＡＡインフラストラクチャの信頼性には、ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６サービスに対する移動ノードの認証及び認可に必要なＨＭＩＰｖ６関連情報を送信することが介在していることが好ましい。
2006527966.tif 000002
【特許請求の範囲】
【請求項１】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートする方法であって、ＡＡＡインフラストラクチャに基づいて、ＨＭＩＰｖ６サービスに対する前記移動ノードの認証及び認可を行う
ことを特徴とする方法。
【請求項２】
前記移動ノードは、訪問先ネットワークでローミングしていて、前記ＡＡＡインフラストラクチャは、前記訪問先ネットワークと前記移動ノードの前記ホームネットワークとをリンクしている
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６サービスに対する、前記移動ノードの認証及び認可を行うために必要なＨＭＩＰｖ６関連情報を送信する
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ＨＭＩＰｖ６関連情報は、ＨＭＩＰｖ６認証、認可及びコンフィグレーション情報のグループから選択される情報を備える
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記移動ノードと移動性アンカーポイント（ＭＡＰ）間のＨＭＩＰｖ６セキュリティアソシエーションを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信する
ことを特徴とする請求項３に記載の方法。
【請求項６】
前記移動ノードに対する、ＨＭＩＰｖ６バインディングを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信する
ことを特徴とする請求項５に記載の方法。
【請求項７】
ＨＭＩＰｖ６セキュリティアソシエーションに対するＨＭＩＰｖ６関連情報として、ＨＭＩＰｖ６バインディング用のＨＭＩＰｖ６関連情報を同一のラウンドトリップで送信する
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間のエンドツーエンド処理において、認証プロトコルでＨＭＩＰｖ６関連情報を送信する
ことを特徴とする請求項３に記載の方法。
【請求項９】
前記認証プロトコルは、拡張認証プロトコルである
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記拡張認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックの前記ＥＡＰメソッドレイヤにおける、ＥＡＰ属性として送信される
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックにおける汎用コンテナで送信される
ことを特徴とする請求項１０に記載の方法。
【請求項１３】
前記拡張されたＥＡＰプロトコルは、ＰＡＮＡ、ＰＰＰあるいはＩＥＥＥ８０２．１Ｘによって、前記移動ノードと前記訪問先ネットワーク内のＡＡＡクライアント間で搬送され、また、前記ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションによって搬送される
ことを特徴とする請求項１０に記載の方法。
【請求項１４】
ＭＡＰが前記ホームネットワーク内に配置され、ＨＭＩＰｖ６関連情報は、前記認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、ＨＭＩＰｖ６関連情報は、前記認証プロトコルの別のセッションで、あるいはＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記ＭＡＰ間を送信される
ことを特徴とする請求項８に記載の方法。
【請求項１５】
ＭＡＰが前記訪問先ネットワーク内に配置され、ＨＭＩＰｖ６関連情報は、前記認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記訪問先ネットワーク内の前記ＭＡＰ間を送信される
ことを特徴とする請求項８に記載の方法。
【請求項１６】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＨＭＩＰｖ６用に構成されるＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項３に記載の方法。
【請求項１８】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＨＭＩＰｖ６用に構成されるＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記ＡＡＡインフラストラクチャは、移動性アンカーポイント（ＭＡＰ）を前記移動ノードへ割り当てる
ことを特徴とする請求項１または２に記載の方法。
【請求項２０】
前記ホームネットワークのＡＡＡインフラストラクチャコンポーネントは、前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーションに対する信用関連データを生成し、その信用関連データを前記ＭＡＰへ送信し、
前記ＡＡＡインフラストラクチャコンポーネントは、前記セキュリティアソシエーションを完成するための情報を生成する、あるいは前記ＭＡＰは、前記セキュリティアソシエーションを完成するための情報で、前記ＡＡＡインフラストラクチャコンポーネントに応答する、ここで、前記ＭＡＰは、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６認可情報を前記移動ノードへ送信する
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記ＭＡＰは、前記移動ノードの前記ホームネットワーク内に配置され、
ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、ＭＡＰ割当を実行し、
前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーション用の信用関連データを生成し、かつ前記信用関連データを前記ＭＡＰへ送信し、
前記ＡＡＡｈは、前記セキュリティアソシエーションを完成するための情報を生成する、あるいは前記ＭＡＰは、前記セキュリティアソシエーションを完成するための情報で、前記ＡＡＡｈに応答し
前記ＡＡＡｈは、前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信する
ことを特徴とする請求項１９に記載の方法。
【請求項２２】
前記ＭＡＰは、前記訪問先ネットワーク内に配置され、
ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、ＭＡＰ割当を実行し、
前記移動ノードは、ＡＡＡインフラストラクチャを介して、ＭＡＰ割当リクエストをＡＡＡホームネットワークサーバ（ＡＡＡｈ）へ送信し、
前記ＡＡＡｈは、前記ＭＡＰ割当リクエストを前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ転送し、
前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーション用の信用関連データを生成し、
前記信用関連データは、前記ＡＡＡｖを介して前記ＡＡＡｈから前記ＭＡＰへ送信され、
前記ＡＡＡｈは、前記セキュリティアソシエーションを完成するための情報を生成する、あるいは前記ＭＡＰは、前記セキュリティアソシエーションを完成するための情報で、前記ＡＡＡｖを介して、前記ＡＡＡｈに応答し
前記ＡＡＡｈは、前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信する
ことを特徴とする請求項１９に記載の方法。
【請求項２３】
前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＨＭＩＰｖ６とＭＩＰｖ６の認証及び認可を同時に実行する
ことを特徴とする請求項１に記載の方法。
【請求項２４】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするシステムであって、ＡＡＡインフラストラクチャに基づいて、ＨＭＩＰｖ６サービスに対する前記移動ノードの認証及び認可を行う手段を備える
ことを特徴とするシステム。
【請求項２５】
前記移動ノードは、訪問先ネットワークでローミングしていて、前記ＡＡＡインフラストラクチャは、前記訪問先ネットワークと前記移動ノードのホームネットワークとをリンクしている
ことを特徴とする請求項２４に記載のシステム。
【請求項２６】
前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６サービスに対する、前記移動ノードの認証及び認可を行うために必要なＨＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項２４または２５に記載のシステム。
【請求項２７】
前記ＨＭＩＰｖ６関連情報は、ＨＭＩＰｖ６認証、認可及びコンフィグレーション情報のグループから選択される情報を備える
ことを特徴とする請求項２６に記載のシステム。
【請求項２８】
前記移動ノードと移動性アンカーポイント（ＭＡＰ）間のＨＭＩＰｖ６セキュリティアソシエーションを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項２６に記載のシステム。
【請求項２９】
前記移動ノードに対する、ＨＭＩＰｖ６バインディングを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信する
ことを特徴とする請求項２８に記載のシステム。
【請求項３０】
ＨＭＩＰｖ６セキュリティアソシエーションに対するＨＭＩＰｖ６関連情報として、ＨＭＩＰｖ６バインディング用のＨＭＩＰｖ６関連情報を同一のラウンドトリップで送信する手段を備える
ことを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間のエンドツーエンド処理において、認証プロトコルでＨＭＩＰｖ６関連情報が送信される
ことを特徴とする請求項２６に記載のシステム。
【請求項３２】
前記認証プロトコルは、拡張認証プロトコルである
ことを特徴とする請求項３１に記載のシステム。
【請求項３３】
前記拡張認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項３２に記載のシステム。
【請求項３４】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックの前記ＥＡＰメソッドレイヤにおける、ＥＡＰ属性として送信される
ことを特徴とする請求項３３に記載のシステム。
【請求項３５】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックにおける汎用コンテナで送信される
ことを特徴とする請求項３３に記載のシステム。
【請求項３６】
前記拡張されたＥＡＰプロトコルは、ＰＡＮＡ、ＰＰＰあるいはＩＥＥＥ８０２．１Ｘによって、前記移動ノードと前記訪問先ネットワーク内のＡＡＡクライアント間で搬送され、また、前記ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションによって搬送される
ことを特徴とする請求項３３に記載のシステム。
【請求項３７】
ＭＡＰが前記ホームネットワーク内に配置され、ＨＭＩＰｖ６関連情報は、前記認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、ＨＭＩＰｖ６関連情報は、前記認証プロトコルの別のセッションで、あるいはＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記ＭＡＰ間を送信される
ことを特徴とする請求項３１に記載のシステム。
【請求項３８】
ＭＡＰが前記訪問先ネットワーク内に配置され、ＨＭＩＰｖ６関連情報は、前記拡張認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記訪問先ネットワーク内の前記ＭＡＰ間を送信される
ことを特徴とする請求項３１に記載のシステム。
【請求項３９】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＨＭＩＰｖ６用に構成されるＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項３８に記載のシステム。
【請求項４０】
前記ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項２６に記載のシステム。
【請求項４１】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＨＭＩＰｖ６用に構成されるＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記ＡＡＡインフラストラクチャは、移動性アンカーポイント（ＭＡＰ）を前記移動ノードへ割り当てるように構成されている
ことを特徴とする請求項２４または２５に記載のシステム。
【請求項４３】
前記ホームネットワークのＡＡＡインフラストラクチャコンポーネントは、
前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーションに対する信用関連データを生成する手段と、
前記信用関連データを前記ＭＡＰへ送信し、前記セキュリティアソシエーションを完成するための情報を前記ＭＡＰから受信する手段と、
前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６認可情報を前記移動ノードへ送信する手段と
を備えることを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記ＭＡＰは、前記移動ノードの前記ホームネットワーク内に配置され、
ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、ＭＡＰ割当を実行するように構成され、
前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、更に、
前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記ＭＡＰへ送信し、前記セキュリティアソシエーションを完成し、かつアドレス情報をバインディングするための情報を前記ＭＡＰから受信する手段と、
前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信する手段と
を備えることを特徴とする請求項４２に記載のシステム。
【請求項４５】
前記ＭＡＰは、前記訪問先ネットワーク内に配置され、
ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、ＭＡＰ割当を実行するように構成され、
前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、更に、
前記ＡＡＡインフラストラクチャを介して受信されるＭＡＰ割当リクエストを、前記移動ノードから前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ転送する手段と、
前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーション用の信用関連データを生成する手段と、
前記ＡＡＡｖを介して、前記信用関連データを前記ＭＡＰへ送信し、前記ＡＡＡｖを介して前記ＭＡＰから、前記セキュリティアソシエーションを完成するための情報と、バインディングアドレス情報を受信する手段と、
前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信する手段と
を備えることを特徴とする請求項４２に記載のシステム。
【請求項４６】
前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＨＭＩＰｖ６とＭＩＰｖ６の認証及び認可を同時に実行する手段を備える
ことを特徴とする請求項２４に記載のシステム。
【請求項４７】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするＡＡＡホームネットワークサーバであって、
前記移動ノードと割当移動性アンカーポイント（ＭＡＰ）間のセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記ＭＡＰへ送信し、前記セキュリティアソシエーションを完成するための情報を前記ＭＡＰから受信する手段と、
セキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信する手段と
を備えることを特徴とするＡＡＡホームネットワークサーバ。
【請求項４８】
前記移動ノードは、訪問先ネットワークでローミングしていて、前記ＨＭＩＰｖ６認可情報を送信する手段は、前記訪問先ネットワークと前記移動ノードのホームネットワークとをリンクしているＡＡＡインフラストラクチャを介して情報を送信するために動作可能である
ことを特徴とする請求項４７に記載のＡＡＡホームネットワークサーバ。
【請求項４９】
前記ＡＡＡホームネットワークサーバは、前記セキュリティアソシエーションを完成するための情報と、バインディングアドレス情報を前記ＭＡＰから受信するように構成されていて、
前記ＨＭＩＰｖ６認可情報を送信する手段は、前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信するように構成されている
ことを特徴とする請求項４８に記載のＡＡＡホームネットワークサーバ。
【請求項５０】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートする移動性アンカーポイント（ＭＡＰ）ノードであって、
前記移動ノードと前記ＭＡＰ間のセキュリティアソシエーションの確立をサポートするＡＡＡホームネットワークサーバと対話する手段と、
信用関連データを前記ＡＡＡホームネットワークサーバから受信する手段と、
前記セキュリティアソシエーションを完成するための情報を前記ＡＡＡホームネットワークサーバへ送信する手段と
を備えることを特徴とするＭＡＰノード。
【請求項５１】
前記移動ノードからのバインディング更新に応答して、前記ＭＡＰ内のバインディングアドレスを割り当てる手段と、
前記割当バインディングアドレスと前記バインディング更新で受信されるアドレス情報に基づいて、前記ＭＡＰ内でＨＭＩＰｖ６バインディングを確立する手段と
を更に備えることを特徴とする請求項５０に記載のＭＡＰノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の技術分野
本発明は、一般的には、移動通信に関するものであり、より詳しくは、モバイルＩＰ（インターネットプロトコル）サービスをサポートし、特に、階層モバイルＩＰサービスバージョン６サービスに関するものである。
【０００２】
本発明の背景
モバイルＩＰ（ＭＩＰ）は、最小限のサービス中断（disruption）で、移動ノード（ＭＮ）に、インターネットとの自身の接続ポイントを変更することを可能にする。ＭＩＰ自身では、異なる管理ドメインに渡る移動性（mobility）について専用のサポートは提供しない。これは、大規模の商用配備において、ＭＩＰの適用性を制限するものである。
【０００３】
モバイルＩＰバージョン６（ＭＩＰｖ６）プロトコル［１］は、ノードにインターネットトポロジー内での移動を可能にしながら、到達可能性を維持し、かつ対応するノードとの接続を継続する。この状況では、各移動ノードは、ＩＰｖ６インターネットとの自身の現在の接続ポイントに関係なく、常に自身のホームアドレスによって識別される。自身のホームネットワークから離れる状況では、移動ノードは気付アドレス（ＣｏＡ：care-of address）にも関連付けられている。これは、移動ノードの現在の位置についての情報を提供する。移動ノードのホームアドレスにアドレス指定されているＩＰｖ６パケットは、自身の気付アドレスに対して、多かれ少なかれ透過的（トランスペアレント）に転送される。ＭＩＰｖ６プロトコルは、ＩＰｖ６ノードに、移動ノードのホームアドレスと自身の気付アドレスとのバインディング（binding）をキャッシュして、その後、その気付アドレスへ、移動ノード宛てのパケットを送信することを可能にする。つまり、移動ノードは、移動する毎に、いわゆるバインディング更新を自身のホームエージェント（ＨＡ）と、それと通信する対応するノードに送信する。バインディング更新の認証には、移動ノードと各対応するノード間でいくつかのラウンドトリップ（round trips：往復）を必要とする。加えて、１つのラウンドトリップではホームエージェントの更新を必要とするが、この更新は、対応するノードを更新しながら、同時に実行することができる。
【０００４】
これらのラウンドトリップによる遅延は、新規のアクセスルータへのハンドオフが実行される毎に、アクティブな接続が中断されることになる。
【０００５】
このこととまた別の理由により、階層モバイルＩＰｖ６（ＨＭＩＰｖ６）プロトコル［２］が、局所あるいは階層構造の移動性管理をサポートするために提案されている。モバイルＩＰｖ６用の階層移動性管理は、ＭＮ、自身の対応ノード（ＣＮ）、及び訪問先ネットワークに配置されているいわゆる移動性アンカーポイント（ＭＡＰ）の導入による自身のＨＡ間の信号送受信（signaling：シグナリング）量を削減する。ＭＡＰの導入は、ハンドオフ速度に関して、モバイルＩＰｖ６のパフォーマンスを改善するために使用することもできる。
【０００６】
図１は、訪問先ネットワーク内でＭＡＰを備える従来のＨＭＩＰｖ６ドメインの例を概要を示している。システム全体では、通常のホームエージェント（ＨＡ）１５を備えるホームネットワーク１０、ＭＡＰ２５を備える訪問先ネットワーク２０及びアクセスルータ（ＡＲ）２７を含んでいる。ＭＡＰドメインに進入する移動ノード（ＭＮ）３０は、１つ以上のローカルＭＡＰ上の情報を含む、いわゆる、ルータ広告（router advertisement）を受信することになる。ＭＮ３０は、自身の位置（オンリンク上の気付アドレスあるいはＬＣｏＡ）と、領域気付アドレス（ＲＣｏＡ：Regional Care-of Address）と呼ばれる、ＭＡＰのサブネット上のアドレスとをバインドすることができる。ローカルＨＡとして動作すると、ＭＡＰ２５は、サービスを受けているＭＮ３０に代って、すべてのパケットを受信し、それをカプセル化し、ＭＮのＬＣｏＡに直接転送する。
【０００７】
ＭＡＰは、移動ノードがアクセスルータ１（ＡＲ１）２７−１からアクセスルータ（ＡＲ２）２７−２へ移動する際に、その移動ノードのシームレスな移動性を提供しながら、対応ノード（ＣＮ）４０と通信することを支援することができる。訪問先ネットワーク内への到着時には、移動ノード３０は、ＭＡＰ２５のグローバルアドレスを探索する。このアドレスは、アクセスルータに記憶され、ルータ広告を介して移動ノードへ通信される。このプロセスはＭＡＰディスカバリ（discovery：探索）と呼ばれ、ＭＡＰの存在を、移動ノードに公表するために必要とされる。ＭＡＰドメインは、接続している移動ノードにＭＡＰ情報を公表するアクセスルータによって通常定義される。ＭＡＰディスカバリのプロセスは、移動ノードがあるサブネットから次のサブネットへ移動する際に継続する。移動体がＭＡＰドメイン内を移動している（roam）限りは、アクセスルータは、同一のＭＡＰアドレスあるいはアドレス群を公表するように構成されている。公表されるＭＡＰのアドレスで変更を受信すると、移動ノードは、移動検出を実行して、必要なバインディング更新を自身のホームエージェントと対応ノードへ送信しなければならない。
【０００８】
移動ノードがＨＭＩＰｖ６を認識するものではない場合、ＭＡＰディスカバリは決して実行されず、モバイルＩＰｖ６が移動性管理に対して使用されることになる。一方、移動ノードがＨＭＩＰｖ６を認識するものである場合、ＨＭＩＰｖ６を使用することが選択されるべきである。そのような場合、移動ノードは、自身のホームアドレスとＬＣｏＡアドレスを含むバインディング更新を送信することによって、ＭＡＰ２５に登録する。バインディング更新で使用されるホームアドレスはＲＣｏＡアドレスであり、ＭＡＰ２５は、自身のバインディングキャッシュにその情報を記憶する、これにより、対応ノード４０あるいはＨＡ１５から受信するパケットを、最終的な宛先へ転送することが可能になる。
【０００９】
ＭＩＰの場合では、ＨＭＩＰｖ６自身は、異なる管理ドメインに渡る移動性について専用のサポートを提供しない。これは、大規模の商用配備において、ＭＩＰの応用性を制限するものである。
【００１０】
ＨＭＩＰｖ６のサービスを使用することが認可される前に、ＭＮは、まず、認証されることを必要としていることを、通常は予定されている。移動ノードとＭＡＰ間のセキュリティリレーションは、それが強力な特性であることが重要であり、好ましくは、相互認証、完全性保護及びリプライアタックに対する保護を含むべきである。つまり、ＭＮとＭＡＰ間のセキュリティキーのような信用に関係するデータの配信は、現在のところ、公開鍵基盤（ＰＫＩ）と他の複雑なプロトコルに頼らなければならない。現在のＨＭＩＰｖ６草稿［２］も、訪問先ネットワークに対するＭＡＰの位置を制限している。
【００１１】
本発明の要約
本発明は、これらの欠点、及び従来の構成の他の欠点を解決するものである。
【００１２】
本発明の一般的な目的は、移動ノード用のＨＭＩＰｖ６サービスに対して改善されたサポートを提供することである。このソリューションは、ＨＭＩＰｖ６の配備を容易にするメカニズムを含んでいることが好ましい。
【００１３】
特に、ＨＭＩＰｖ６サービスの認証及び認可に対して、合理化されていて、そしてなお耐性のあるソリューションを提供することが好ましく、このＨＭＩＰｖ６サービスは、公開鍵基盤（ＰＫＩ）と他の複雑なプロトコルに依存する必要はない。
【００１４】
本発明の別の目的は、全体のＨＭＩＰｖ６のセットアップ回数を少なくすることを可能にすることである。
【００１５】
本発明の更なる別の目的は、ＨＭＩＰｖ６サービスをサポートする方法及びシステムを提供することである。
【００１６】
本発明の更なる別の目的は、独自のネットワークコンポーネントを提供することであり、これは、ＨＭＩＰｖ６サービスの合理化された認証及び認可の少なくとも一方をサポートする。
【００１７】
これら及び他の目的は、特許請求の範囲によって定義される本発明によって達成されるものである。
【００１８】
本発明の基本的な特徴は、移動ノード用のＨＭＩＰｖ６サービスを「ブートストラップ」するためのＡＡＡインフラストラクチャに依存することである。本発明の実施形態に従えば、ＨＭＩＰｖ６サービスのブートストラップには、ＡＡＡインフラストラクチャに基づいて、ＨＭＩＰｖ６サービスに対する移動ノードの認証及び認可を含んでいる。重要な状況では、移動ノードは、訪問先ネットワークでローミングしていて、ＡＡＡインフラストラクチャは、訪問先ネットワークとその移動ノードのホームネットワークとをリンクしている。しかしながら、本発明は、移動ノードがホームネットワークに実際に配置されている状況もサポートする。この場合、ホームネットワークのＡＡＡインフラストラクチャコンポーネントは、ホームネットワーク内で、ＭＡＰを用いるＨＭＩＰｖ６サービスに対して必要なサポートを提供しても良い。
【００１９】
ＡＡＡインフラストラクチャへの信頼性は、ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６サービスに対する、移動ノードの認可を行うために必要なＨＭＩＰｖ６関連情報を送信することに関係している。
【００２０】
ＨＭＩＰｖ６のブートストラップは、適切なＭＡＰと移動ノード間のセキュリティアソシエーションの確立に通常基づいていて、これにより、適正な通信を確実にする。例えば、認証されたＨＭＩＰｖ６バインディングを可能にする。
【００２１】
本発明の実施形態では、ＨＭＩＰｖ６セキュリティアソシエーション処理として、同一のラウンドトリップ内でのＨＭＩＰｖ６移動性処理のピギーバックが、共通の処理で認証、認可及び移動性を最適化することによって、全体のセットアップ回数をできる限り少なくすることを可能にする。
【００２２】
認可フェーズは、通常、明示的な認可を含んでいるが、介在するノードのコンフィグレーション（configuration：構成）を含んでいても良い。それゆえ、ＨＭＩＰｖ６に関連するコンフィグレーション、例えば、移動ノードのコンフィグレーションとＭＡＰのコンフィグレーションの少なくとも一方は、通常、全体の認可処理の一部とみなされる場合がある。このことは、通常、ＨＭＩＰｖ６関連情報が、ＨＭＩＰｖ６認証、認可及びコンフィグレーション情報の少なくとも１つであっても良いことを意味する。
【００２３】
従来のＭＡＰ探索プロセスに代えて、ＡＡＡインフラストラクチャは、移動ノードから開始されるＭＡＰ割当リクエスト（移動ノード始動ＭＡＰ割当）あるいはネットワーク始動再割当に応答して、適切なＭＡＰを移動ノードへ割り当てるために使用されることが好ましい。
【００２４】
ホームネットワークあるいは他のネットワーク内に配置されるＭＡＰを持っていることが有益である場合が存在することも理解される。これは、例えば、訪問先ネットワークがＭＡＰサポートを提供していない場合である。ホームネットワークに配置されるＭＡＰは、イントラＭＡＰドメインを移動中に、ＨＡへ渡るバインディング更新の数を削減することによって、ＨＡのスケーラビリティの問題、ＨＡを除去する（off-loading）ことを取り扱うために使用することができる。ＭＮの位置に幾何学的に近い位置にあるＭＡＰを選択することによって、高速ハンドオーバを実現することができる。
【００２５】
ＭＡＰがホームネットワークに配置されている場合、ＭＡＰ割当用の適切なＡＡＡインフラストラクチャコンポーネントとして、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）を使用することが適切である場合がある。一方、ＭＡＰが訪問先ネットワークに配置されている場合、ＭＡＰ割当用に、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）を使用することが適切である場合がある。実際、ＭＡＰの位置は、ホームネットワーク、訪問先ネットワーク、あるいは他のネットワークに存在し得る。予め定義されたＭＡＰドメイン内で、ＭＡＰ上の情報を含むルータ広告に対する、強制的な依存はもはや存在しない。
【００２６】
ＡＡＡインフラストラクチャの信頼性は、ＰＫＩインフラストラクチャを使用することに比べて、ＨＭＩＰｖ６サービスをブートストラップするための様々な可能性を提案する。例えば、ＡＡＡインフラストラクチャを介して搬送される汎用認証プロトコルの拡張を提供すること、ＡＡＡフレームワークプロトコルアプリケーションを拡張することの少なくとも一方を可能にする。
【００２７】
例えば、移動ノードとＡＡＡホームネットワークサーバ間のエンドツーエンド処理において、認証プロトコルで、ＨＭＩＰｖ６関連情報を送信することは極めて有益であることが証明されている。認証プロトコルは、既存のプロトコルあるいは新規のプロトコルに基づいて、拡張された認証プロトコルであっても良い。
【００２８】
ＨＭＩＰｖ６をブートストラップするための基準として使用される、取り得る認証プロトコルは、ＥＡＰ拡張を生成する拡張可能認証プロトコル（ＥＡＰ）であり、好ましくは、ＥＡＰの下位レイヤ（群）を維持する。このことは、通常、ＨＭＩＰｖ６関連情報がＥＡＰプロトコルスタックの追加のデータとして組み込まれること、あるいはあるいはＥＡＰレイヤあるいはＥＡＰメソッドレイヤ上の汎用コンテナで送信されることを意味する。追加のデータとは、例えば、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性である。
【００２９】
別の方法では、ＥＡＰ拡張の補部あるいは代替として使用することは、新規のあるいは拡張されたＡＡＡフレームワークプロトコルアプリケーションを生成するようなＥＡＰの「下位レイヤ（群）」を拡張することになる。このアプリケーションは、例えば、ＨＭＩＰｖ６用に構成されるＤｉａｍｅｔｅｒアプリケーション、あるいはＲａｄｉｕｓプロトコルに基づくアプリケーションがある。
【００３０】
ＭＡＰがホームネットワーク内に配置される場合、例えば、ＡＡＡインフラストラクチャを介して搬送される拡張認証プロトコル、あるいは拡張ＡＡＡフレームワークプロトコルアプリケーションを使用することが可能である。しかしながら、ＭＡＰが訪問先ネットワークに配置される場合、拡張ＥＡＰプロトコルが、拡張ＡＡＡフレームワークプロトコルアプリケーションと組み合わせて使用されることが好ましい。あるいは、選択的には、拡張ＡＡＡフレームワークプロトコルアプリケーションが、任意のＥＡＰ拡張のサポートなしで使用される。
【００３１】
例えば、拡張ＥＡＰプロトコルは、ＰＡＮＡ（ネットワークアクセス認証用搬送プロトコル）、ＰＰＰ（ポイント−ツー−ポイント（point-to-point）プロトコル）、ＩＥＥＥ８０２．１Ｘ、あるいはＧＰＲＳ／ＵＭＴＳのインタフェースによって、移動ノードと訪問先ネットワークのＡＡＡクライアント間で搬送されても良く、また、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションによって搬送されても良い。
【００３２】
特に、ＥＡＰ拡張に依存することは、合理化されたソリューションを提供し、これは、後方互換性の問題を最小限にして管理可能であり、かつ的確である。ＥＡＰの使用は、少なくとも、ＭＡＰがホームネットワークに配置される場合には、ＡＡＡクライアント（及びＡＡＡｖ）に、ＨＭＩＰｖ６処理について不可知（agnostic）とし、かつ、単なるパススルーエージェント（群）として動作することを可能にする。これは、ＥＡＰを使用することについての主要な利点の１つである。
【００３３】
拡張認証プロトコルスタックに、あるいは拡張ＡＡＡフレームワークプロトコルアプリケーションに、ＭＩＰｖ６関連情報を含めることによって、ＡＡＡインフラストラクチャを介して、同一のラウンドとリップで、ＨＭＩＰｖ６及びＭＩＰｖ６認証及び認可を同時に実行することが可能である。もちろん、特定の場合に特別に必要とするＭＮに依存して、例えば、ＭＩＰｖ６／ＨＭＩＰｖ６使用可能ネットワークを使用して、ＭＩＰｖ６に対応するものなしで、ＨＭＩＰｖ６のみの認証及び認可の少なくとも一方を実行することが可能であり、その逆も可能である。これは、単一の拡張認証プロトコル及び拡張フレームワークプロトコルアプリケーションの少なくとも一方に、様々な使用状況で使用される場合の柔軟性を与えることを可能にする。
【００３４】
本発明は、以下の効果を提供する：
・ＨＭＩＰｖ６サービスの効果的なブートストラップ
・ＨＭＩＰｖ６サービスを認可するためのＨＭＩＰｖ６関連情報の効果的な送信
・ＥＡＰ拡張に基づくＨＭＩＰｖ６サポートについて合理化されたソリューション、これは、後方互換性の問題を最小限にして管理可能であり、かつ的確である。
【００３５】
・全体のＨＭＩＰｖ６セットアップ回数の減縮
・共通の処理で、認証、認可及び移動性の最適化
・ＡＡＡベースのＭＡＰ割当
・訪問先ネットワークに制限されないＭＡＰ位置
・イントラＭＡＰドメインを移動中に、ＨＡへ渡るバインディング更新の数を削減することによって、ＨＡのスケーラビリティの問題、ＨＡを除去する（off-loading）ことを取り扱うために、ＭＡＰをホームネットワークに配置することができる。
【００３６】
・同一のラウンドトリップで、ＨＭＩＰｖ６とＭＩＰｖ６認証及び認可の同時実行
本発明によって提供される他の効果は、本発明の実施形態の以下の説明を読むことによって理解されるであろう。
【００３７】
本発明の実施形態の詳細説明
図面を通して、同一の参照文字は、対応するあるいは同様の要素に対して使用するものである。
【００３８】
本発明の基本的な概念は、ＨＭＩＰｖ６認証及び認可の目的のための複雑なＰＫＩインフラストラクチャを利用する代わりに、ＡＡＡインフラストラクチャに基づいて、移動ノードに対するＨＭＩＰｖ６サービスを「ブートストラップ（bootstrap：起動）」することである。ＨＭＩＰｖ６のブートストラップは、ホームネットワーク内で動作する移動ノードと、訪問先ネットワークでローミングする移動ノードの両方に対して有効である。これは、前者については、ホームネットワークＡＡＡインフラストラクチャを利用し、後者については、ホームネットワークと訪問先ネットワークとをリンクする全体（overall）ＡＡＡインフラストラクチャを利用する。
【００３９】
公開鍵基盤（ＰＫＩ）を利用することによって、ＭＮとＭＡＰ間で、セキュリティアソシエーション（security association）を確立し、セキュリティキーを配信する代わりに、ＨＭＩＰｖ６サービスの認証及び認可は、ＡＡＡインフラストラクチャに基づいて実行されることが好ましい。これは、例えば、ＨＭＩＰｖ６サービスに対して移動ノードを認証しかつ認可するために必要とされるＨＭＩＰｖ６関連情報を、ＡＡＡインフラストラクチャを介して送信することによって行う。
【００４０】
従来のＭＡＰディスカバリプロセスの代わりに、詳細については後述する、移動ノードから開始されるＭＡＰ割当リクエスト（移動ノードで開始されるＭＡＰ割当）、あるいはネットワークで開始される再割当に応じて、適切なＭＡＰを移動ノードに割り当てるためにもＡＡＡインフラストラクチャが使用されることが好ましい。予め定義されたＭＡＰドメイン内のＭＡＰ上の情報を含むルータ広告についての義務的な依存性はもはや存在しない。
【００４１】
ＡＡＡ  ＨＭＩＰｖ６のブートストラップは、セキュリティアソシエーションの確立、即ち、ＡＡＡインフラストラクチャを介する適切なＭＡＰと移動ノード間のセキュリティリレーションの確立に通常は基づいている。これにより、適正な通信を確実にする、例えば、認証されたＨＭＩＰｖ６  ＭＡＰ  バインディングを可能にする。
【００４２】
一実施形態では、バインディング更新を含むＨＭＩＰｖ６移動性処理は、ＨＭＩＰｖ６セキュリティアソシエーション処理と同一のラウンドトリップに抱き合わせられる（ピギーバックされる：piggyback）、これにより、共通の処理内で認証、認可及び移動性を最適化することによって、全体のセットアップ回数をできる限り少なくすることを可能にする。
【００４３】
用語「ＡＡＡ」は、インターネット草稿であるＲＦＣ及び他の標準化文献それ自身が通常意味するものに含まれるべきである。典型的には、ＡＡＡ（認可（authorization）、認証（authentication）、アカウンティング（accounting））インフラストラクチャの認証及びセキュリティキーアグリーメント（security key agreement）は、対称性暗号化に基づいている、これは、移動ノードと、ホームネットワークオペレータあるいは信用機関間で共有される初期シークレットの存在を意味するものである。いくつかの状況及び用途では、例えば、ＡＡＡインフラストラクチャのアカウンティング機能は無効にされる、あるいは実現されなくても良い。ＡＡＡインフラストラクチャは、通常は、ホームネットワーク、中間ネットワーク（もしあるのであれば）及び訪問先ネットワークの少なくとも１つのネットワーク内に１つ以上のＡＡＡサーバを含んでいて、また、１つ以上のＡＡＡクライアントを含んでいても良い。
【００４４】
一般的には、Ｄｉａｍｅｔｅｒ（Diameter）プロトコルのようなＡＡＡプロトコルは、移動体ユーザにネットワーク内でローミングをしてサービスを取得することを正確に可能にする。このネットワークは、自身のホームサービスプロバイダによって所有されている必要はない。それゆえ、商用ネットワーク内に配置されるモバイルＩＰについては、そのプロトコルについてのＡＡＡサポートが存在しなければならない。任意の階層移動性管理を持たないモバイルＩＰｖ６（ＭＩＰｖ６）の特殊な場合について、インターネット草稿［３］は、ホームオペレータによって管理されるネットワーク以外のネットワークで、ＭＩＰｖ６ローミングを可能にするＤｉａｍｅｔｅｒに新規のアプリケーションを指定することについてを提案している。２００３年６月１８日に出願された、本出願人の米国仮特許出願６０／４７９，１５６と、また、インターネット草稿［４］では、ＡＡＡインフラストラクチャに基づくモバイルＩＰｖ６認可及びコンフィグレーションを実行するためのアーキテクチャ及びそれに関連するプロトコルが示唆されている。ホームプロバイダのＡＡＡサーバと、ＭＩＰｖ６用の移動ノード間で必要とされる対話は、ＥＡＰ（拡張可能認証プロトコル）を使用して実現され、これは、モバイルＩＰｖ６ネゴシエーションに対する情報とともに、認証データを搬送する。
【００４５】
図２は、本発明の実施形態に従う、ＨＭＩＰｖ６に対する新規のアーキテクチャを示す概要図である。移動ノード１３０は、訪問先ネットワークにローミングしていて、ＨＭＩＰｖ６認証及び認可が、訪問先ネットワークと、移動ノードのホームネットワークとをリンクしているＡＡＡインフラストラクチャを使用して実行される。この例では、ＡＡＡインフラストラクチャは、基本的には、ＡＡＡホームネットワークサーバ１１０、ＡＡＡ訪問先ネットワークサーバ１２０及び訪問先ネットワーク内でＡＡＡクライアント１２２を介在している。
【００４６】
好ましくは、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）１２０は、ＭＡＰ割当用の適切なＡＡＡインフラストラクチャコンポーネントとして使用することもでき、これは、ＭＡＰの選択に、訪問先オペレータのポリシーを取り入れている。ＭＡＰの選択は、例えば、利用可能なＭＡＰの現在の負荷、移動ノードの位置及び、おそらくは、移動ノードによって与えられるプリファレンスの少なくとも１つに基づくことができる。
【００４７】
ＡＡＡインフラストラクチャのメインコンポーネントは、ＡＡＡｈサーバ１１０である。これは、移動ノードからＡＡＡｖサーバ１２０へＭＡＰ割当用のリクエストを送信し、更には、与えられる移動ノード１３０と割当ＭＡＰ１２５間の即時あるいは将来のセキュリティアソシエーション用のセキュリティキーあるいは同様の信用証明（credentials）を生成することが好ましい。次に、セキュリティキーは、典型的には、ＡＡＡｖ１２０を介して、ＡＡＡｈ１１０からＭＡＰ１２５へ送信され、ＭＡＰ１２５は、ＡＡＡｖ１２０を介してＡＡＡｈ１１０とのセキュリティアソシエーションを完成させるための情報で応答することが好ましい。そして、ＡＡＡｈサーバ１１０は、生成され、かつ収集されたＨＭＩＰｖ６認可情報をＡＡＡインフラストラクチャを介して移動ノード１３０へ送信する。ここで、ＡＡＡインフラストラクチャのセキュアトンネルあるいは、暗号化のような他のセキュリティ基準と、ソース完全性保護が、このセキュリティキー（群）のような機密情報の送信に対して利用されるものと想定する。
【００４８】
ＡＡＡインフラストラクチャの信頼性は、ＨＭＩＰｖ６サービスをブートストラップするための様々な可能性を提案する。例えば、図２に示されるように、新規の認証プロトコルを提供すること、ＡＡＡインフラストクチャを介して搬送される認証プロトコルへの拡張を提供すること、及びＨＭＩＰｖ６関連情報を搬送するためにＡＡＡフレームワークプロトコルアプリケーションを拡張（enhance）することの少なくともいずれかを可能にする。
【００４９】
好ましくは、ＨＭＩＰｖ６に対して適合する拡張ＥＡＰ（拡張可能認証プロトコル）のような拡張認証プロトコルが利用され、これに加えて、ＡＡＡｖサーバを介して、ＡＡＡｈサーバと訪問先ネットワークＭＡＰ間のインタフェース用のＨＭＩＰｖ６ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような、拡張ＡＡＡフレームワークプロトコルアプリケーションが利用される。
【００５０】
例えば、新規のあるいは拡張認証プロトコルは、ＰＡＮＡ（ネットワークアクセス認証用搬送プロトコル）、ＰＰＰ（ポイントツーポイントプロトコル）、ＩＥＥＥ８０２．１Ｘあるいは、移動ノードと訪問先ネットワーク内のＡＡＡクライアント間のＧＰＲＳ／ＵＭＴＳインタフェースを介することによって搬送されても良く、また、Ｄｉａｍｅｔｅｒあるいは同様のＡＡＡフレームワーク、あるいはＡＡＡインフラストラクチャ内の搬送プロトコルによって搬送されても良い。
【００５１】
選択的には、新規のあるいは拡張ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような、拡張ＡＡＡフレームワークプロトコルアプリケーションが、任意のＥＡＰ拡張のサポートなしに使用される。移動ノードとＡＡＡクライアント間の経路に対しては、ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションは、例えば、ＩＣＭＰ（インターネット制御メッセージプロトコル）によって搬送することができる。
【００５２】
ホームネットワークあるいは他のネットワーク内に配置されるＭＡＰを持つことが有益であるとされる場合、例えば、訪問先ネットワークがＭＡＰサポートを提供しない場合が存在することも認識されている。ホームネットワークに配置されるＭＡＰを有するＨＭＩＰｖ６サポートに対するアーキテクチャ例を、図３に示す。
【００５３】
ここでは、ＭＡＰ割当用に、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０を使用することは有益である。好ましくは、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０も、移動ノードと割当ＭＡＰ１２５間のセキュリティアソシエーション用のセキュリティキーあるいは同様のセキュリティパラメータ、あるいは信用証明を生成し、そのセキュリティキーをＭＡＰ１２５に送信する。ＭＡＰ１２５は、ＡＡＡｈ１１０とのセキュリティアソシエーションを完成するための情報で応答し、ＡＡＡｈ１１０は続いて、ＨＭＩＰｖ６認可情報をＡＡＡインフラストラクチャを介して移動ノード１３０へ送信する。
【００５４】
ＭＡＰ１２５はホームネットワークに配置されるので、ＡＡＡｖ１２０はトランザクションを確認する必要はない。つまり、このことは、ＨＭＩＰｖ６認証及び認可に対する「エンドツーエンド（end-to-end）処理」を持つことが可能となる。これは、ＨＭＩＰｖ６用に適合されている拡張ＥＡＰ（拡張可能認証プロトコル）プロトコルを使用することによって達成されることが好ましい。選択的には、ＨＭＩＰｖ６ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような、拡張ＡＡＡフレームワークプロトコルアプリケーションを利用することができる。ホームネットワークに配置されるＭＡＰ１２５を、ＨＡ拡張性の問題（issues）と、イントラＭＡＰドメイン移動中にＨＡ１１５へ渡るいくつかのバインディング更新を削減することによるＨＡ１１５のオフロード（off-loading）を扱うために使用することもできる。ＭＮの位置に幾何学的に近くにあるＭＡＰを選択することによって、高速ハンドオーバを実現することができる。
【００５５】
理解されるべきことは、本発明は、ＭＡＰ１２５が訪問先ネットワークに配置されなければならないという従来の制限を解消していることである。ここで、ＭＡＰの位置は、ホームネットワーク、訪問先ネットワークあるいは他のネットワークにすることができる。技術的には、ＭＮに対して任意のＭＡＰとバインドすることを可能にするだけでなく、ＭＡＰ上のＲＣｏＡを、オペレータが認可する場合には、ＡＡＡサポートで取得できることである。
【００５６】
以下の例の場合を実行中に、ＭＡＰの再割当が発生し得る：
・ＭＮとＭＡＰ間のセキュリティキーの期限満了、この場合、ＭＮはＨＭＩＰｖ６再認証／認可を開始し、また、ネットワークは、例えば、現在のＭＮの幾何学的位置に基づいてより適切な別のＭＡＰを割り当てることができる。
【００５７】
・移動ノードのリクエスト時（ＭＮが開始されている）、この場合、ＭＮは、ＭＡＰの再割当を要求とするＨＭＩＰｖ６再認証／認可を開始する。
【００５８】
・ネットワークのリクエスト時（ネットワークが開始されている）、この場合、ＡＡＡｈあるいはＡＡＡｖのどちらかが、ＭＡＰの再割当を開始し、かつ必要が生じる場合に、例えば、ＭＮが、新規のＭＡＰの範囲に良好に及んでいるＡＲへ移動する場合に、そのＭＡＰをＭＮへ「プッシュ」する。
【００５９】
図２及び図３を再度参照すると、セグメントＡＡＡクライアント−ＡＡＡｈと、ＡＡＡｈ−（ＡＡＡｖ）−ＭＡＰ間で、取り得るプロトコルの組み合わせの例を以下にまとめる。
【００６０】
2006527966.tif 000003
【００６１】
組み合わせ（ｉｉｉ）は、特に、ＭＡＰがホームネットワークに配置される場合に適用可能である。ＭＡＰが訪問先ネットワークに配置される場合、ＡＡＡｖは、訪問先ネットワークポリシーに基づくＭＡＰの選択に関わっても良い。
【００６２】
別の状況では、図４に示されるように、移動ノード１３０は、実際にはホームネットワークに配置されていて、ＡＡＡｈサーバ１１０のようなホームネットワークのＡＡＡインフラストラクチャコンポーネントは、ホームネットワーク内でＭＡＰ１２５でＨＭＩＰｖ６サービス用に必要なサポートを提供する。これは、拡張認証ＨＭＩＰｖ６プロトコルとＡＡＡ  ＨＭＩＰｖ６アプリケーションとの関連部分だけが、必要な認証及び認可情報の交換のために使用されなければならないことを意味する。
【００６３】
図５は、本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。この例では、ＡＡＡｈサーバ１１０は、基本的には、オプションのＭＡＰ割当モジュール１１１、セキュリティアソシエーションモジュール１１２、認可情報マネージャ１１３及び入力−出力（Ｉ／Ｏ）インタフェース１１４を備えている。ホームネットワーク内にＭＡＰがある場合、ＡＡＡｈサーバ１１０は、ＭＡＰ割当モジュール１１１を含み、これは、適切なＭＡＰの移動ノードへの割当／再割当に対して動作可能である。訪問先ネットワーク内にＭＡＰがある場合、ＡＡＡｈサーバ１１０は、典型的には、自身のＩ／Ｏインタフェース１１４で、必要なＭＡＰ割当情報を受信する。また、ＡＡＡｈサーバは、典型的には、キーシード（種）とバインディング更新（ＢＵ）を移動ノードから受信する。選択的には、ＡＡＡｈサーバは、自身でキーシードを生成し、それを移動ノードへ送信する。セキュリティアソシエーションモジュール１１２は、そのキーシードに応じて、必要なセキュリティキーを生成し、このキーを安全にＭＡＰ（ホームネットワーク内のＭＡＰへ直接、あるいはＡＡＡｖサーバを介して、訪問先ネットワーク内のＭＡＰ）へ送信することが好ましい。バインディング更新（ＢＵ）は、ＭＡＰへも転送される。ＡＡＡｈサーバ１１０は、ＭＡＰからＲＣｏＡアドレスを受信し、他の関連認可（及び／あるいはコンフィグレーション）情報に従って、このデータを認可情報マネージャ１１３へ記憶する。ＡＡＡｈサーバは、ＩＰＳｅｃ情報のような情報を、セキュリティアソシエーションを完成させるためのＭＡＰから受信することもできる。そして、収集された認可（及び／あるいはコンフィグレーション）情報は、移動ノードへ送信される。
【００６４】
ＡＡＡｈサーバは、ホームアドレス割当（ホームアドレスがＭＮ自身によって構成されない限り）及びホームエージェント割当の少なくとも一方に対して応答とすることもできる。
【００６５】
図６は、本発明の実施形態に従うＭＡＰノードのブロック図である。この例では、ＭＡＰ１２５は、基本的には、ＲＣｏＡ割当モジュール１２６、セキュリティアソシエーションモジュール１２７及び入力−出力（Ｉ／Ｏ）インタフェース１２８を備える。ＭＡＰは、移動ノードとのセキュリティアソシエーションの確立をサポートするためのＡＡＡホームネットワークサーバと対話することが好ましい。ＭＡＰは、セキュリティアソシエーションモジュール１２７内の安全な記憶のために、Ｉ／Ｏインタフェース１２８を介してＡＡＡホームネットワークサーバからセキュリティキーを受信する。ＭＡＰは、移動ノードとのセキュリティアソシエーションを完成するために必要な情報を準備して、ＡＡＡホームネットワークサーバへ返信する。ＡＡＡホームネットワークサーバは、更に、その情報をＡＡＡインフラストラクチャを介して移動ノードへ転送する。ＭＡＰでのバインディングに対して、ＲＣｏＡモジュール１２６は、移動ノードにＲＣｏＡアドレスを割り当て、移動ノードのＬＣｏＡアドレスとともにそのアドレスをＭＡＰのバインディングキャッシュ（不図示）に記憶し、更に、次の移動ノードへの転送のために、その割り当てられたＲＣｏＡアドレスをＡＡＡホームネットワークサーバへ送信する。
【００６６】
本発明をより理解するために、ＨＭＩＰｖ６用の拡張認証プロトコルとＨＭＩＰｖ６用に適合されているＡＡＡフレームワークプロトコルアプリケーションのより詳細な例を以下に説明する。
【００６７】
ＨＭＩＰｖ６用の拡張認証プロトコル
本実施形態では、ＨＭＩＰｖ６用の拡張認証プロトコルは、ここでは、新規のあるいは拡張ＥＡＰ認証プロトコルによって例示され（「ＨＭＩＰｖ６認証方法」あるいは「ＥＡＰ／ＨＭＩＰｖ６」と称する）、また、例えば、ＭＡＰのディスカバリ（探索）、ＭＡＰの動的割当、ＲＣｏＡの動的割当、ＭＮとＭＡＰ間のセキュリティキー（群）の配信及び、ＨＭＩＰｖ６移動性処理の取り得るピギーバックの少なくとも１つを容易にする、ＨＭＩＰｖ６関連情報を搬送することが定義される。
【００６８】
要求があれば、ＨＭＩＰｖ６とＭＩＰｖ６の両方の認証及び認可の少なくとも一方は、例えば、ＥＡＰ／ＭＩＰｖ６プロトコルのスーパーセットとしてＥＡＰ／ＨＭＩＰｖ６を定義する同一のプロトコルにまとめることができ、これに加えて、ＭＩＰｖ６専用タイプレングス値（Type-Length-Values）（ＴＬＶ）は、新規のＨＭＩＰ専用ＴＬＶ属性を定義する。ＥＡＰ／ＨＭＩＰｖ６の一部として、ＥＡＰ／ＭＩＰｖ６  ＴＬＶ属性を含めることによって、より少ないセットアップ回数を可能にする一方向の処理（single traversal）で、ＭＩＰｖ６とＨＭＩＰｖ６の両方の認証及び認可の少なくとも一方を同時に実行することが可能になる。特別な場合にＭＮで特別に必要なものに依存して、ＭＩＰｖ６に対するものなしで、ＨＭＩＰｖ６認証及び認可の少なくとも一方のみを実行することも可能になり、その逆も可能である。これは、単一のＥＡＰ認証プロトコルである、ＥＡＰ／ＨＭＩＰｖ６を、様々な使用状況に対して柔軟に使用させることを可能にする。
【００６９】
特に、ＥＡＰ拡張に依存することは、合理的な解決策を提供する。これは、後方互換性の問題を最小限にして、管理することができ、また、的確されたものである。ＥＡＰの使用は、ＡＡＡクライアント（及びＡＡＡｖ）に、ＨＭＩＰｖ６処理について不可知（agnostic）であることを可能にし（即ち、これは、訪問先ネットワークのＨＭＩＰｖ６サポートにおける依存性を解消する）、また、少なくともＭＡＰがホームネットワークに配置されている場合に、単なるパススルーエージェント（群）として動作することを可能にする。これは、ＥＡＰを使用することについての主要な利点の１つである。
【００７０】
上述したように、ＥＡＰ／ＨＭＩＰｖ６は、例えば、ＰＡＮＡ、ＰＰＰ、ＩＣＭＰ、ＩＥＥＥ８０２．Ｘ、あるいは、移動ノードと訪問先ネットワーク内のＡＡＡクライアント間のＧＰＲＳ／ＵＭＴＳインタフェースを介することによって搬送することができる。但し、ＰＡＮＡは、いくつかの場合に、他の搬送プロトコルとしても良い。この他の搬送プロトコルは、ＰＰＰ［６］のような、より下位の層での順序付けの保証についてのＥＡＰ要求事項を満足する。また、ＩＥＥＥ８０２．１Ｘ［７］は、ＭＮとＡＡＡクライアント間でＥＡＰ／ＨＭＩＰｖ６を搬送するために使用されても良い。具体的には、３ＧＰＰ２  ＣＤＭＡ２０００の場合では、ＥＡＰ［６］に対してＣ２２７（１６進数）に設定されているプロトコルフィールド値を有するＰＰＰデータリンクレイヤカプセル化を使用して、ＭＮとＡＡＡクライアント間で、ＥＡＰ／ＨＭＩＰｖ６を搬送することを可能にする。
【００７１】
本実施形態は、Ｄｉａｍｅｔｅｒ、Ｒａｄｉｕｓあるいは同様のＡＡＡフレームワーク、あるいは、ＡＡＡクライアントとＡＡＡｈサーバ間の通信用搬送プロトコルを使用する。例えば、ＡＡＡインフラストラクチャ向けで、かつその中のＡＡＡクライアントを越えて、ＤｉａｍｅｔｅｒＥＡＰアプリケーション［５］は、Ｄｉａｍｅｔｅｒ内、即ち、ＰＡＡ／ＡＡＡクライアントとＡＡＡｈ間で、ＥＡＰ／ＨＭＩＰｖ６をカプセル化するために使用することもできる。Ｄｉａｍｅｔｅｒプロトコルは、ＭＩＰフィルタルールを介する、ＭＩＰパケットフィルタのＰＡＡ／ＥＰとＨＡへのオプションの割当のために、ＡＡＡｈによって使用されても良く、これは、フィルタ実行（enforcement）ポイントに対応する。Ｄｉａｍｅｔｅｒプロトコルは、ＰＡＮＡセキュリティ用のセキュリティキーのＰＡＡへの配信のために、また、ＱｏＳパラメータのオプションのシグナリング（信号送受信）のために、ＡＡＡｈによって使用されても良い。
【００７２】
Ｄｉａｍｅｔｅｒは設計事項であるけれども、当業者の自明な変更として、Ｒａｄｉｕｓのような、別のＡＡＡプロトコルを代わりに使用することも時には適切なものとなることに注意すべきである。
【００７３】
また、ＥＡＰ／ＨＭＩＰｖ６での、ＨＭＩＰｖ６移動性処理のピギーバックは、共通の処理で、認証、認可及び移動性を最適化することによって、全体のセットアップ回数をできる限り少なくすることを可能にする。
【００７４】
ＥＡＰ／ＨＭＩＰｖ６プロトコルの詳細例
以下では、ＥＡＰ／ＨＭＩＰｖ６プロトコルの詳細例を提供することで、全体フロー及び概念の実行可能性を例示する。
【００７５】
ＥＡＰ／ＴＬＶ属性
第１の実現例では、新規のＥＡＰ  ＴＬＶ属性のセットは、ＥＡＰ／ＨＭＩＰｖ６の下で定義される。これらの属性によって、ＥＡＰプロトコルは、主要なＩＰｖ６認証情報に加えて、ＨＭＩＰｖ６関連情報及びオプションのＭＩＰｖ６関連情報を搬送することができる。
【００７６】
別の認証プロトコルを、ＥＡＰ／ＨＭＩＰｖ６に対して用いることも可能である。実施形態では、本発明は、ＭＤ５−チャレンジ認証を介して実現することを提案しているが、他のプロトコルも、本発明の範囲にある。
【００７７】
ＥＡＰ／ＨＭＩＰｖ６  ＴＬＶの抜粋の構成の例が、以下の表１で与えられる。
【００７８】
2006527966.tif 000004
2006527966.tif 000005
2006527966.tif 000006
【００７９】
注：ＩＫＥ  ＫｅｙＩＤは、どのようにして、ＨＡ−ＭＮ事前共有キー／ＭＡＰ−ＭＮ事前共有キーをＡＡＡｈから検索する（生成する）かについてをＨＡ／ＭＡＰに通知する、いくつかのオクテット（octet）を含んでいる。
【００８０】
以下のＥＡＰ−ＴＬＶ属性の例の１つ以上は、ＨＭＩＰｖ６用途のために定義されても良い：
・RCoA Request EAP-TLV属性：
これは、認証されたＭＮに対し、動的に割り当てられるＲＣｏＡアドレス用のリクエストを示している。これは、認証され、与えられるＨＭＩｐＶ６サービスをＭＮがリクエストする場合に、ＭＮによってＡＡＡｈへリクエストされる。
【００８１】
・RCoA Response EAP-TLV属性：
これは、認証されたＭＮに対し、動的に割り当てられるＲＣｏＡアドレスを示している。これは、あるものに対してリクエストしているＭＮが認証に成功している場合に、ＡＡＡｈからＭＮへ通知される。
【００８２】
・RCoA EAP-TLV属性：
これは、認証されたＭＮに対し、動的に割り当てられるＲＣｏＡアドレスを示している。これは、あるものに対してリクエストしているＭＮが認証に成功している場合に、ＭＡＰ内でＲＣｏＡアドレスを割り当てるために、ＡＡＡｈからＭＡＰへ通知される。
【００８３】
・MAP Address Request EAP-TLV属性：
これは、認証が成功している場合に、ＭＮに対し、動的に割り当てられるＭＡＰのアドレス用のリクエストを示している。これは、認証され、与えられるＨＭＩＰｖ６サービスをＭＮがリクエストする場合に、ＭＮによってＡＡＡｈへリクエストされる。ＨＭＩＰｖ６プロトコルは、ＭＡＰを割り当てるための動的ＭＡＰディスカバリ（探索）方法を持っているので、この属性はオプションである。
【００８４】
・MAP Address Response EAP-TLV属性：
これは、認証されたＭＮに対し、動的に割り当てられるＭＡＰのアドレスを示している。これは、認証され、与えられるＨＭＩＰｖ６サービスをＭＮがリクエストする場合に、ＡＡＡｈからＭＮへ通知される。ＨＭＩＰｖ６プロトコルは、ＭＡＰを割り当てるための動的ＭＡＰディスカバリ（探索）方法を持っているので、この属性はオプションである。
【００８５】
・MAP-MN Pre-shared Key Generation Nonce EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間の事前共有キーを生成するためのシードとする、ＭＮによってランダムに生成されるオクテットストリングを示している。ＭＮは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＭＡＰ−ＭＮ事前共有キーを生成することができる。この属性は、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合のオプションである。
【００８６】
・MAP-MN Pre-shared Key EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間で動的に生成される事前共有キーを示している。これは、認証され、与えられるＨＭＩＰｖ６サービスをＭＮが要求している場合に、ＡＡＡｈからＭＡＰへ通知される。ＡＡＡｈは、MAP-MN Pre-shared Key Generation Nonce EAP-TLV属性によって与えられるナンスと、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＭＡＰ−ＭＮ事前共有キーを生成することができる。この属性は、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合のオプションである。
【００８７】
・MAP IKE  KeyID EAP-TLV属性：
これは、［８］で定義されるＩＤペイロードを示している。ＫｅｙＩＤは、ＡＡＡｈによって生成され、そして、認証が成功しているＭＮに送信される。ＫｅｙＩＤは、いくつかのオクテットを含み、これは、どのようにしてＡＡＡｈから、ＭＡＰ−ＭＮ事前共有キーを検索（あるいは生成）するかについてを、ＭＡＰへ通知する。この属性は、オプションであり、かつ、ＭＮがＭＡＰ−ＭＮ事前共有キー生成ナンス（MAP-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、ＭＡＰ−ＭＮ事前共有キーがＡＡＡｈによってＭＡＰに搬送される場合にも必要とされない。
【００８８】
・MAP-MN  IPSec SPI EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間のＩＰＳｅｃに対するセキュリティパラメータインデックス（Security Parameter Index）を示している。これは、ＭＡＰによって生成され、かつ、ＭＡＰ−ＭＮ事前共有キーがＡＡＡｈによってＭＡＰに搬送される場合にＭＮに通知されることが好ましい。この属性は、オプションであり、かつ、ＭＮがＭＡＰ−ＭＮ事前共有キー生成ナンス（MAP-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００８９】
・MAP-MN IPSec Protocol EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間のＩＰＳｅｃプロトコル（例えば、ＥＳＰあるいはＡＨ）を示している。これは、ＭＡＰ−ＭＮ事前共有キーがＡＡＡｈによってＭＡＰに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＭＡＰ−ＭＮ事前共有キー生成ナンス（MAP-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００９０】
・MAP-MN IPSec Crypto EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間のＩＰＳｅｃに対する暗号アルゴリズムを示している。これは、ＭＡＰ−ＭＮ事前共有キーがＡＡＡｈによってＭＡＰに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＭＡＰ−ＭＮ事前共有キー生成ナンス（MAP-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００９１】
・MAP-MN IPSec Key Lifetime EAP-TLV属性：
これは、ＭＡＰ−ＭＮ間のＩＰＳｅｃに対するキー期限を示している。これは、ＭＡＰ−ＭＮ事前共有キーがＡＡＡｈによってＭＡＰに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＭＡＰ−ＭＮ事前共有キー生成ナンス（MAP-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＭＡＰ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００９２】
・HMIP-Binding-Update EAP-TLV属性：
これは、ＭＮによって生成されるＭＡＰバインディング更新パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＭＡＰからＭＮへ転送される。この属性は、オプションであり、かつ、ＭＮがＭＡＰバインディング更新パケットを直接ＭＡＰへ送信する場合には、通常必要とされない。
【００９３】
・HMIP-Binding-Acknowledgement EAP-TLV属性：
これは、ＭＡＰによって生成されるＭＡＰバインディング応答確認パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＭＮからＭＡＰへ転送される。この属性は、オプションであり、かつ、ＭＮがＭＡＰバインディング更新パケットを直接ＭＡＰへ送信する場合には、通常必要とされない。
【００９４】
以下のオプションのＥＡＰ−ＴＬＶ属性は、特定のＭＩＰｖ６用途に対して定義されても良い。
【００９５】
・MIPv6 Home Address EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスを示している。これは、あるものにリクエストを行っているＭＮが、認証に成功している場合に、ＨＡ内のＭＩＰｖ６ホームアドレスに割り当てるために、ＡＡＡｈからＨＡへ通知される。
【００９６】
・HA-MN Pre-shared Key EAP-TLV属性：
これは、ＨＡ−ＭＮ間で動的に生成される事前共有キーを示している。これは、認証され、与えられるＨＭＩＰｖ６サービスをＭＮがリクエストする場合に、ＡＡＡｈからＨＡへ通知される。ＡＡＡｈは、HA-MN Pre-shared Key Generation Nonce EAP-TLV属性によって与えられるナンスと、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＨＡ−ＭＮ事前共有キーを内部的に生成することができる。この属性は、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合のオプションである。
【００９７】
・HA-MN IPSec Protocol EAP-TLV属性：
これは、ＨＡ−ＭＮ間のＩＰＳｅｃプロトコル（例えば、ＥＳＰあるいはＡＨ）を示している。これは、ＨＡ−ＭＮ事前共有キーがＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００９８】
・HA-MN IPSec Crypto EAP-TLV属性：
これは、ＨＡ−ＭＮ間のＩＰＳｅｃに対する暗号アルゴリズムを示している。これは、ＨＡ−ＭＮ事前共有キーがＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００９９】
・MIP-Binding-Update EAP-TLV属性：
これは、ＭＮによって生成されるバインディング更新パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＭＮからＨＡへ転送される。この属性は、オプションであり、かつ、ＭＮがバインディング更新パケットを直接ＨＡへ送信する場合には、通常必要とされない。
【０１００】
・MIP-Binding-Acknowledgement EAP-TLV属性：
これは、ＨＡによって生成されるバインディング応答確認パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＨＡからＭＮへ転送される。この属性は、オプションであり、かつ、ＨＡがバインディング応答確認パケットを直接ＭＮへ送信する場合には、通常必要とされない。
【０１０１】
以下のＥＡＰ−ＴＬＶ属性は、ＨＭＩＰｖ６／ＭＩＰｖ６認証に対して定義されても良い。
【０１０２】
・MD5 Challenge EAP-TLV属性：
これは、ＡＡＡｈによってランダムに生成され、かつＭＤ５チャレンジ（Challenge）に対するＭＮへ送信されるオクテットストリングを示している。
【０１０３】
・MD5 Response EAP-TLV属性：
これは、ＡＡＡｈとＭＮ間の共有シークレットキーを用いるＭＤ５ハッシュ関数の結果として生成されるオクテットストリングを示している。
【０１０４】
以下のオプションのＥＡＰ−ＴＬＶ属性は、動的ＭＮホームアドレス割当に対して定義されても良い。
【０１０５】
・MIPv6 Home Address Request EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスに対するリクエストを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＭＮによってＡＡＡｈへリクエストされる。この属性は、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているホームアドレスを持っている場合のオプションである。
【０１０６】
・MIPv6 Home Address Response EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスを示している。これは、あるものにリクエストを行っているＭＮが、認証に成功している場合に、ＡＡＡｈからＨＡへ通知される。この属性は、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているホームアドレスを持っている場合のオプションである。
【０１０７】
以下のオプションのＥＡＰ−ＴＬＶ属性は、動的ＨＡ割当に対して定義されても良い。
【０１０８】
・MIPv6 Home Agent Address Request EAP-TLV属性：
これは、認証が成功している場合に、ＭＮに対して、動的に割り当てられるＨＡのアドレスに対するリクエストを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＭＮによってＡＡＡｈへリクエストされる。ＭＩＰｖ６プロトコルは、ＨＡを割り当てるための動的ＨＡディスカバリ（探索）方法を持っているので、この属性はオプションである。これは、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているＨＡを持っている場合も同様である。
【０１０９】
・MIPv6 Home Agent Address Response EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＨＡのアドレスを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＡＡＡｈからＭＮへ通知される。ＭＩＰｖ６プロトコルは、ホームエージェントを割り当てるための動的ホームエージェントディスカバリ（探索）方法を持っているので、この属性はオプションである。これは、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているＨＡを持っている場合も同様である。
【０１１０】
以下のオプションのＥＡＰ−ＴＬＶ属性は、ＨＡとＭＮ間でのセキュリティキーの配信に対して定義されても良い。
【０１１１】
・HA-MN Pre-shared Key Generation Nonce EAP-TLV属性：
ＨＡ−ＭＮ間の事前共有キーを生成するためのシードとする、ＭＮによってランダムに生成されるオクテットストリングを示している。ＭＮは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＨＡ−ＭＮ事前共有キーを生成することができる。この属性は、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合のオプションである。
【０１１２】
・IKE KeyID EAP-TLV属性：
これは、［８］で定義されるＩＤペイロードを示している。ＫｅｙＩＤは、ＡＡＡｈによって生成され、そして、認証が成功しているＭＮに送信される。ＫｅｙＩＤは、いくつかのオクテットを含み、これは、どのようにしてＡＡＡｈから、ＨＡ−ＭＮ事前共有キーを検索（あるいは生成）するかについてを、ＨＡへ通知する。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、ＨＡ−ＭＮ事前共有キーが、［９］で定義されるＡＡＡｈ−ＨＡインタフェースを介して、ＡＡＡｈによってＨＡに搬送される場合にも必要とされない。
【０１１３】
・HA-MN  IPSec SPI EAP-TLV属性：
これは、ＨＡとＭＮ間のＩＰＳｅｃに対するセキュリティパラメータインデックス（Security Parameter Index）を示している。これは、ＨＡによって生成され、かつ、ＨＡ−ＭＮ事前共有キーが、［９］で定義されるＡＡＡｈ−ＨＡインタフェースを介して、ＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、［９］で定義されるＡＡＡｈ−ＨＡインタフェースが使用されない場合も必要とされない。
【０１１４】
・HA-MN IPSec Key Lifetime EAP-TLV属性：
これは、ＨＡとＭＮ間のＩＰＳｅｃに対するキー期限を示している。これは、ＨＡ−ＭＮ事前共有キーが、［９］で定義されるＡＡＡｈ−ＨＡインタフェースを介して、ＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、［９］で定義されるＡＡＡｈ−ＨＡインタフェースが使用されない場合も必要とされない。
【０１１５】
最後に、以下のオプションのＥＡＰ−ＴＬＶ属性は、ＰＡＮＡセキュリティに対するＰＡＣとＰＡＡ間でのセキュリティキーの配信に対して定義されても良い。
【０１１６】
・PAC-PAA Pre-shared Key Generation Nonce EAP-TLV属性：
これは、ＰＡＣ−ＰＡＡ間の事前共有キーを生成するためのシードとする、ＭＮ／ＰＡＣによってランダムに生成されるオクテットストリングを示している。ＭＮ／ＰＡＣは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＰＡＣ−ＰＡＡ事前共有キーを生成することができる。この属性は、ＰＡＮＡセキュリティに対して必要とされる。
【０１１７】
選択的には、ＡＡＡｈサーバは、ＭＮ−ＭＡＰセキュリティキーを生成するだけでなく、セキュリティアソシエーションを完成するために必要とされる情報を生成するように構成されても良い。
【０１１８】
上述の例から確認できるように、ＨＭＩＰｖ６に関連するコンフィグレーション（構成）は、認可処理全体の一部として通常見なされる。
【０１１９】
EAP Generic Container Attribute(EAP GCA)（ＥＡＰ汎用コンテナ属性）
別のＥＡＰの実現では、ＥＡＰは、新規のいわゆるＥＡＰメソッド（EAP method）を生成することなく、ＨＭＩＰｖ６関連情報（オプションとしては、ＭＩＰｖ６情報）のキャリヤとして使用される。これは、ＥＡＰメソッドとともに使用することができる汎用コンテナＥＡＰ属性で情報を搬送することによるものではない。
【０１２０】
この例の実現では、アクセスネットワークでＡＡＡサポートを構築する、ＥＡＰは、汎用コンテナ属性で増やされる（augmented）。この汎用コンテナ属性は、任意の（当然のことのように、非ＥＡＰ関連）データ、例えば、ＨＭＩＰｖ６専用データと、オプションのＭＩＰｖ６専用データ（ＭＩＰｖ６のブートストラップも要求される場合）を搬送するために使用することができる。これは、ＭＮとＡＡＡｈに、アクセスネットワークを含む訪問先ドメインに対してトランスペアレントとなる方法で、ホームネットワークの場合には、少なくともＭＡＰに対する、ＡＡＡクライアントとＡＡＡｖと通信することを可能にする。ＥＡＰは、ＡＡＡプロトコルで、ＡＡＡクライアントとＡＡＡｈ間で搬送されることが好ましい。このＡＡＡプロトコルは、例えば、Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーションあるいはＲａｄｉｕｓ［１０］、［１１］がある。
【０１２１】
この新規の属性は、すべてのＥＡＰメソッドに対して利用可能であるとすべきことが好ましく、また、ＥＡＰ成功／失敗メッセージを含む任意のＥＡＰに含めることができる。このソリューションでは、新規の汎用コンテナ属性は、ＭＮとＡＡＡｈ間で、ＨＭＩＰｖ６専用データ（オプションとしては、ＭＩＰｖ６データ）を搬送するために使用される。このソリューションは、ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションを含んでいても良く、これらは、ＡＡＡｈとＨＡ間で、ＡＡＡとそれに関連するデータの交換のために使用される。
【０１２２】
以下では、汎用コンテナ属性（ＧＣＡ）の実現可能な実装について、現存のＥＡＰプロトコル［１２］に関して説明する。上述のように、汎用コンテナ属性は、あらゆる方法で利用可能とすべきことが好ましく、また、ＥＡＰ成功／失敗メッセージを含む任意のＥＡＰに含めることを可能とすべきである。これは、ＥＡＰメソッドレイヤ［１２］ではなく、ＥＡＰレイヤの一部とすべきであることを意味する。考慮するための重要な問題は、後方互換性1である。後方互換性1は、ＭＮ及びＥＡＰ認証器（authenticator）（典型的には、ＮＡＳに配置される）に関する後方互換性を示すものである。ＭＮ及びＥＡＰ認証サーバ（即ち、ＡＡＡｈ）は、常に互換性があると想定されている。与えられる例でのＧＣＡの使用は、通常、新規の属性が後方互換性のある方法でＥＡＰに導入され、かつＥＡＰ認証器に対してトランスペアレントであると想定する。これらの属性を伴うＧＣＡの導入は、以下に説明するように、いくつかの特別な配慮を必要とする場合がある。
【０１２３】
例えば、ＧＣＡのフォーマットは、ＧＣＡ受信インジケータとＧＣＡペイロードに続く２バイトのＧＣＡレングス（length：長）インジケータとすることができる。ＧＣＡ受信インジケータは、どの内部エンティティへ、受信ＧＣＡのペイロードをＥＡＰモジュールが送信するべきかについてを示す（即ち、このインジケータは、ＩＰヘッダ内のプロトコル／次のヘッダフィールド、あるいはＵＤＰ及びＴＣＰヘッダ内のポート番号に対応する）。ＧＣＡペイロードは、ＥＡＰレイヤによって解釈されないデータの汎用部分（generic chunk）となる。ＧＣＡの不在は、ゼロに設定されるＧＣＡレングスインジケータによって示されることが好ましい。
【０１２４】
後方互換性を提供することは、パススルー（pass-through）ＥＡＰ認証器に対してトランスペアレントとなる方法で、ＧＣＡをＥＡＰパケットに含ませるべきことが好ましい。パススルーＥＡＰ認証器は、ＥＡＰ認証器（ＮＡＳ内に存在し、典型的には、ＷＬＡＮ  ＡＰあるいはアクセスルータ）であり、これは、ＭＮとバックエンドＥＡＰ認証サーバ（ＡＡＡサーバ）間の（ほとんどの）ＥＡＰパケットを中継する。［１２］では、ＥＡＰ認証器のパスフルー動作は、ＥＡＰレイヤヘッダ、即ち、ＥＡＰパケットの最初にある、コード（Code）、識別子（Identifier）及び長（レングス（Length））フィールドに基づいてＥＡＰパケットを中継することであると説明している。これは、要求される透過性（トランスペアレンシー）（かつ、ここでは後方互換性）が、ＧＣＡがＥＡＰレイヤヘッダ（即ち、コード（Code）、識別子（Identifier）及び長（レングス（Length））フィールド）の後に配置される場合に可能であれば達成できることを意味している。
【０１２５】
しかしながら、ＡＡＡルーティングに対して必要とされるＮＡＩが抽出されるＥＡＰアイデンティティ応答パケットを識別するために、ＥＡＰ認証器は、通常は、ＥＡＰ応答パケットのタイプ（Type）フィールド（ＥＡＰレイヤヘッダの後に続く）のチェックもしなければならない。ＥＡＰ認証器がＥＡＰアイデンティティ応答パケットを識別する場合、これは、タイプフィールドに続くタイプ−データ（Type-Data）フィールドからＮＡＩを抽出する。ここで、ＥＡＰレイヤヘッダの直後にＧＣＡを配置することは（ＥＡＰ認証器に対してトランスペアレントとなる方法で）、ＥＡＰリクエストパケットについてのみ可能である。それゆえ、通常は、タイプフィールドの後、あるいは（可能であれば、ＮＵＬＬで終了されている）タイプデータフィールドの後にＧＣＡを配置することが好ましい。
【０１２６】
タイプフィールドの直後にＧＣＡを配置することは、ＥＡＰアイデンティティ応答パケットではなく、すべてのＥＡＰ応答パケット内でＧＣＡの使用を可能とする。ＥＡＰアイデンティティ応答パケット内でのＧＣＡの使用は禁止されている、これは、これらのパケットから、ＥＡＰ認証器がタイプ−データフィールドからＮＡＩを抽出する必要があるからであり、これは、元来のＥＡＰ認証器がタイプフィールドの直後で検出することを期待しているからである。これは、ＥＡＰが通常数回以上のラウンドトリップを持っていることを考慮するＧＣＡの使用の制約となり得る。場合によっては、他のＥＡＰパケット内のタイプフィールドの後にその位置を保持しながら、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内のＮＵＬＬで終了されているタイプデータフィールドの後に配置することができる。
【０１２７】
すべてのＥＡＰパケットで一貫して使用することができるＧＣＡの位置を用いることが通常望ましいとされている。上述の説明からは、後方互換性がある方法でＧＣＡをすべてのＥＡＰパケットに配置することができる位置は、多かれ少なかれトレーラー（trailer）とするパケットの最後であると思われる。しかしながら、ＧＣＡ位置は、ＥＡＰレイヤヘッダ内のレングスフィールドに依存するが、タイプ−データパラメータ（群）に対する明確なレングスインジケータを持っていないという、問題がこれらのＥＡＰパケットに対して生じる可能性がある。これらのパケットでは、タイプ−データフィールドからＧＣＡを区別することができないことになる。
【０１２８】
この問題を解決するために、ＧＣＡレングスインジケータ、ＧＣＡ受信インジケータ及びＧＣＡペイロードの順序は、ＧＣＡレングスインジケータが最後に現れるように入れ換えられるべきである。つまり、ＥＡＰパケットの最後にＧＣＡを配置する場合には、ＥＡＰパケットの最後の２つのオクテット（この長さは、ＥＡＰレイヤヘッダ内のレングスフィールドによって示される）は、常に、ＧＣＡレングスインジケータとなる。ＧＣＡレングスインジケータがゼロでない限り、ＧＣＡ受信インジケータは、ＧＣＡレングスインジケータの前に存在し、ＧＣＡペイロード（このサイズは、ＧＣＡレングスインジケータから判定される）は、ＧＣＡ受信インジケータの前に配置されることになる。この原理を通じて、ＥＡＰパケット内のＧＣＡを識別し、かつタイプ−データフィールドからＧＣＡを区別することが常に可能となる。それでもなお、ＧＣＡの使用は、パススルーＥＡＰ認証器に対してトランスペアレントとなる。
【０１２９】
ＧＣＡソリューションを用いる後方互換性は、更に、ＥＡＰが、ＥＡＰリクエスト／応答パケット（ＥＡＰレイヤヘッダとＮＡＩ以外）から情報を抽出することを試行しないこと、かつ成功／失敗パケット内のレングスフィールドが４より大きい値を示すことを受け入れることを必要とする。
【０１３０】
後方互換性の問題に対応する別の方法は、ＭＮがＧＣＡをサポートしているかどうかを判定するために、ＥＡＰ  ＧＣＡテストリクエスト／応答パケット（即ち、タイプフィールドで新規に定義される値を持つ新規のＥＡＰパケット）を使用することである。
【０１３１】
最初のＥＡＰアイデンティティリクエスト／応答パケット交換の前後で、ＧＣＡをサポートするＥＡＰ認証器は、ＥＡＰ  ＧＣＡテストリクエストパケット（即ち、専用タイプ値を有するＥＡＰリクエストパケット）をＭＮへ送信する（［１３］のＥＡＰ同位状態マシーン（peer state machine）は、２つの別々の送信回数が可能であることを示している）。ＭＮがＧＣＡをサポートしている場合、これは、ＥＡＰ  ＧＣＡテスト応答パケットで応答する。そうでない場合、ＭＮは、ＥＡＰ  ＧＣＡテストリクエストパケットを、未知のＥＡＰメソッドを使用するためのリクエストと解釈するので、ＭＮは、ＥＡＰ  Ｎａｋ  パケットで応答する。ＭＮからの応答からは、ＥＡＰ認証器は、ＭＮがＧＣＡをサポートしているかどうかを判定することができる。
【０１３２】
ＧＣＡをサポートするＭＮは、ＥＡＰ  ＧＣＡテストリクエストパケットの存在あるいは不在によって、ＥＡＰ認証器がＧＣＡをサポートしているかを判定することができる。ＥＡＰ  ＧＣＡテストリクエストパケットが受信される場合（即ち、ＥＡＰ  アイデンティティリクエスト／応答交換の前後）が予想される場合に、ＥＡＰ認証器はＧＣＡをサポートする。そうでない場合は、ＥＡＰ認証器はＧＣＡをサポートしない。
【０１３３】
ＭＮとＥＡＰ認証器の両方がＧＣＡをサポートしている場合、これは、すべての次のＥＡＰパケット内のＥＡＰレイヤヘッダの後に（ＧＣＡコンポーネントの本来の順序で）配置される。そうでない場合、ＧＣＡは、後方互換性のある方法（上述のように）で含ませることを可能にするＥＡＰパケットにいまだなお含められる。
【０１３４】
後方互換性の問題を扱う上述の別の方法には、いくつかの制限がある。１つには、あるＭＮ−ＥＡＰ認証器のラウンドトリップが無駄になる。また、最初のＥＡＰアイデンティティ／応答パケット交換の後に、ＥＡＰ  ＧＣＡテストリクエスト／応答パケットが交換される場合、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内で使用することはできない。この実施形態は、ＥＡＰ認証器（おそらくはＮＡＳ）がＥＡＰの修正版、例えば、ＥＡＰｖ２を使用することも必要とする可能性がある。従って、他の方法では可能であるが、ＥＡＰパケット内にＧＣＡを配置する好適な方法は、典型的には、ＧＣＡレングスインジケータ、それに続く、ＧＣＡペイロード及びＧＣＡ受信インジケータを有するパケットの最後を、トレーラーとすることである。
【０１３５】
ＥＡＰラウンドトリップの回数がＧＣＡ内で交換されるデータに対して十分でない場合には、ＡＡＡｈは、ＧＣＡの搬送目的のために、ＥＡＰ通知リクエスト／応答交換を介する、ＥＡＰラウンドトリップの回数の増加を考慮しても良い。
【０１３６】
別の変形では、実際には、ＥＡＰプロトコルスタックメソッドのレイヤ上のＥＡＰメソッドにＧＣＡを実際に導入している。ＧＣＡがＥＡＰメソッドの専用のものである場合、ＧＣＡは後方互換性の問題を導入することはない。これは、通常、タイプ−データフィールドの一部となるからである。
【０１３７】
ＥＡＰ／ＨＭＩＰｖ６に対するシグナリング（信号送受信）フロー例
図７は、ＭＡＰがホームネットワークに配置されている場合についての、ＥＡＰ／ＨＭＩＰｖ６（Ｄｉａｍｅｔｅｒ）の信号送受信フローの例を示している。
【０１３８】
ＡＡＡクライアントは、ＥＡＰ（リクエストアイデンティティ（Request Identity））を使用するＭＮ認証をリクエストして、ＭＮは、ＥＡＰ（応答アイデンティティ（Response Identity））で応答する。
【０１３９】
ＭＮ応答は、ＡＡＡインフラストラクチャを介してＡＡＡｈへ送信される。ＡＡＡｈは、ＭＮのアイデンティティから、かつ、ＥＡＰ／ＨＭＩＰｖ６メソッドがＭＮの認証及び認可に対して適切である（即ち、ＡＡＡｈは、ＭＮの能力を知っている）ことを示すオペレータポリシーに基づいて、判定を行う。ＡＡＡｈは、チャレンジ（challenge）に従って、提案されるＥＡＰメソッド（例えば、ＥＡＰ／ＨＭＩＰｖ６）の指示をＡＡＡインフラストラクチャを介してＭＮへ送信する。ＥＡＰメソッドあるいはスキームの指示は、拡張されたＥＡＰスキーム（例えば、ＥＡＰ／ＨＭＩＰｖ６）に対して新規のＥＡＰタイプ番号を割り当てることによって実現されても良い。この方法では、移動ノードは、ＡＡＡｈが提案しているＥＡＰスキームがどれであるかを知ることになる。選択的には、特別なフォーマット済のチャレンジが移動ノードに送信され、ここでは、そのチャレンジが、与えられるＥＡＰスキームを示していることを認識する。
【０１４０】
ＭＮは、ＨＭＩＰｖ６をブートストラップすることを要求し、かつ、チャレンジ応答と適切なＥＡＰ属性（ＴＬＶ）を用いて、ＡＡＡｈの提案とチャレンジにリプライする。ここで、適切なＥＡＰ属性（ＴＬＶ）は、割り当てられたＭＡＰとのセキュリティアソシエーションに対して必要な情報に従って適切なＭＡＰを割り当てるためのリクエストを搬送する。この処理では、ＭＮは、事前に実行されていない場合に、ＭＩＰｖ６をブートストラップすることも可能である。ＭＮ応答は、ＡＡＡインフラストラクチャを介してＡＡＡｈへ送信される。ＭＡＰ割当リクエストは実際には潜在的なものであるが、通常は、明示的なＭＡＰ割当リクエストを使用することが勧められる。移動ノードが既にＭＡＰアドレスに気付いていて、かつ例えば、ＭＡＰとのセキュリティアソシエーションを単純に更新している場合に対しては、これ以上ＭＡＰ割当リクエストは発生しないが、再認証及び再認可の少なくとも一方のみが発生することになる。
【０１４１】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味し、また、ＡＡＡｈはＭＮの別のリクエストの処理に進む。
【０１４２】
まず、ＡＡＡｈは、ホームネットワーク内のＭＡＰを選択して、例えば、セキュリティキー（群）を備える拡張ＥＡＰメッセージをＭＡＰへ送信する（ここで、これらの処理は、ＭＮとＡＡＡｈ間で既に進行中の処理以外は、別々のＥＡＰセッションであることに注意されたい）。また、必要であればあるいはそうでなければ適切であれば、ＭＮとのセキュリティアソシエーションを完成するために、好ましくは、情報を提供することによって、ＭＡＰはＡＡＡｈに応答する。例えば、ＩＰＳｅｃセキュリティアソシエーションに対しては、ＥＡＰ属性を使用することが必要となるかもしれない。このＥＡＰ属性は、例えば、上述の表１で定義される、ＩＰＳｅｃ  Ｐｒｏｔｏｃｏｌ、ＩＰＳｅｃ  Ｃｒｙｐｔｏ、ＩＰＳｅｃ  Ｋｅｙ  Ｌｉｆｅｔｉｍｅ  ＥＡＰ  ＴＬＶ属性がある。
【０１４３】
このことについて、また、以下に示す例では、移動ノード（ＭＮ）とＡＡＡｈは、共通の共有シークレットを持っていると想定する。これは、例えば、移動ノードにインストールされるアイデンティティモジュールとホームネットワークオペレータ間で共有される対称キーとすることができる。このアイデンティティモジュールは、従来より周知の不正開封防止アイデンティティモジュールとすることができ、これには、ＧＳＭ（移動通信用グローバルシステム）移動電話で使用される標準ＳＩＭカード、ユニバーサルＳＩＭ（ＵＳＩＭ）、ＷＡＰ（無線アプリケーションプロトコル）  ＳＩＭ、これは、ＷＩＭとしても知られる。また、  ＩＳＩＭ（ＩＰマルチメディアサブシステムアイデンティティモジュール）、また、より一般的には、ＵＩＣＣ（ユニバーサル集積化回路カード）モジュールがある。ＭＮ−ＭＡＰ（ＭＮ−ＨＡ）セキュリティアソシエーションに対しては、シードあるいはナンスは、ＭＮによってＡＡＡｈへ搬送することができる（あるいは、別の方法では、即ち、シードは、ＡＡＡｈによって生成されて、ＭＮへ搬送される）。このシードあるいはナンスから、ＡＡＡｈは、共有シークレットに基づいて、ＭＮ−ＭＡＰ（ＭＮ−ＨＡ）セキュリティキー（群）を生成することができる。移動ノードは、自身で、同一のセキュリティキー（群）を生成することができる。これは、この移動ノードが、シード／ナンスを元々生成して（あるいはＡＡＡｈからシードを受信して）いて、また、共有シークレットを持っているからである。選択的には、ＡＡＡｈは、自身でセキュリティ情報を生成して、そして、それを安全に関連するノードへ送信するようにしても良い。
【０１４４】
第２に、ＭＩＰｖ６のブートストラップがリクエストされる場合、ＡＡＡｈは、別の拡張ＥＡＰセッションを使用するＨＡを選択することによって、このＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。そして、ＨＡは、ＭＮとのセキュリティアソシエーションを生成するために必要な情報を提供することによってＡＡＡｈに応答する。オプションとしては、認証及び認可の交換時に、「ＭＡＰバインディング更新」と「ＨＡバインディング更新」とをピギーバックすることが可能である。これは、ＨＭＩＰｖ６バインディングが、ＭＮ−ＭＡＰセキュリティアソシエーション（ＬＣｏＡだけが移動ノードからのバインディング更新でリクエストされる）として、同一のラウンドトリップに統合されることを意味する。この場合に対しては、ＭＡＰとの最初の処理において、ＡＡＡｈによって取得されるＨＭＩＰｖ６  ＲＣｏＡは、自動的に、次の操作でＨＡで更新されるＭＩＰｖ６バインディングとなる。
【０１４５】
ＡＡＡｈが、上述のように、ＭＡＰとＨＡと通信した後、ＡＡＡｈは、認可（及び／あるいはコンフィグレーション（構成））情報を拡張ＥＡＰを介してＭＮへ返信する。ここで、この情報には、例えば、ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス、及び認証成功指示に従うセキュリティアソシエーション情報がある。図７の特別な最後のラウンドトリップの交換は、ＥＡＰプロトコルが、現在のＥＡＰプロトコル仕様に従って円滑に終了することを補償するためのものである。
【０１４６】
図８は、ＭＡＰが訪問先ネットワークに配置されている場合に対する、ＥＡＰ／ＨＭＩＰｖ６（Ｄｉａｍｅｔｅｒ）信号送受信フローの例を示している。
【０１４７】
ＡＡＡクライアントは、ＥＡＰ（リクエストアイデンティティ）を使用するＭＮ認証をリクエストし、また、ＭＮは、ＥＡＰ（応答アイデンティティ）で応答する。
【０１４８】
ＭＮ応答は、ＡＡＡインフラストラクチャを介してＡＡＡｈへ送信される。ＡＡＡｈは、ＭＮのアイデンティティから、かつ、ＥＡＰ／ＨＭＩＰｖ６メソッドがＭＮの認証及び認可に対して適切である（即ち、ＡＡＡｈは、ＭＮの能力を知っている）ことを示すオペレータポリシーに基づいて、判定を行う。ＡＡＡｈは、チャレンジ（challenge）に従って、提案されるＥＡＰメソッド（例えば、ＥＡＰ／ＨＭＩＰｖ６）の指示をＡＡＡインフラストラクチャを介してＭＮへ送信する。
【０１４９】
ＭＮは、ＨＭＩＰｖ６をブートストラップすることを要求し、かつ、チャレンジ応答と適切なＥＡＰ属性（例えば、ＴＬＶ）を用いて、ＡＡＡｈの提案とチャレンジにリプライする。ここで、適切なＥＡＰ属性（例えば、ＴＬＶ）は、割り当てられたＭＡＰとのセキュリティアソシエーションに対して必要な情報に従って適切なＭＡＰを割り当てるためのリクエストを搬送する。この処理では、ＭＮは、事前にまだ実行されていない場合に、ＭＩＰｖ６をブートストラップすることも可能である。ＭＮ応答は、ＡＡＡインフラストラクチャを介してＡＡＡｈへ送信される。
【０１５０】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味し、また、ＡＡＡｈはＭＮの別のリクエストの処理に進む。
【０１５１】
まず、ＡＡＡｈは、訪問先ネットワーク内のＭＡＰに対するリクエストを適切なＡＡＡｖへ送信する。これは、Ｄｉａｍｅｔｅｒアプリケーションを介して実行されることが好ましい。ここで、Ｄｉａｍｅｔｅｒアプリケーションは、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションを簡略化して称したものである。これについての理由は、訪問先オペレータのポリシーが、訪問先ネットワーク内のＭＡＰ選択を考慮に入れなければならないことであり、つまり、ＡＡＡｖは、トランザクションを確認できることを必要とする（ＥＡＰを用いると、交換はエンドツーエンドであり、これは不可能である）。ＡＡＡｖは、訪問先ネットワーク内のＭＡＰを選択して、例えば、セキュリティキー（群）を備えるＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションメッセージをＭＡＰへ送信する。必要であればあるいはそうでなければ適切であれば、ＭＮとのセキュリティアソシエーションを完成するために、好ましくは、情報を提供することによって、ＭＡＰはＡＡＡｖを介してＡＡＡｈに応答する。第２に、ＡＡＡｈは、別の拡張ＥＡＰセッションを使用するＨＡを選択することによって、ＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。これは、このようなリクエストが存在する場合である。そして、ＨＡは、ＭＮとのセキュリティアソシエーションを生成するために必要な情報を提供することによってＡＡＡｈに応答する。ここで、認証及び認可の交換時に、「ＭＡＰバインディング更新」と「ＨＡバインディング更新」とをピギーバックすることが可能であることに注意する。この場合に対しては、ＭＡＰとの最初の処理において、ＡＡＡｈによって取得されるＨＭＩＰｖ６  ＲＣｏＡは、自動的に、次の操作でＨＡで更新されるＭＩＰｖ６バインディングとなる。
【０１５２】
ＡＡＡｈが、上述のように、ＭＡＰとＨＡと通信した後、ＡＡＡｈは、認可（及び／あるいはコンフィグレーション（構成））情報を拡張ＥＡＰを介してＭＮへ返信する。ここで、この情報には、例えば、ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス、及び認証成功指示に従うセキュリティアソシエーション情報がある。図８の特別な最後のラウンドトリップの交換は、拡張ＥＡＰプロトコルが、現在のＥＡＰプロトコル仕様に従って円滑に終了することを補償するためのものである。
【０１５３】
いくつかの詳細な実施形態を、主として現在のＥＡＰバージョンを参照して説明しているが、他のＥＡＰバージョン、例えば、ＥＡＰｖ２や、上述の方法で拡張されるあるいは構成される他の認証プロトコルについても本発明を確実に適用できることが理解されるべきである。ＥＡＰは、取り得る実装の単なる例であり、本発明は、一般的にはそれに制限されるものではなく、また、選択的には、非ＥＡＰスキームを含んでいても良い。
【０１５４】
ＨＭＩＰｖ６用のＡＡＡフレームワークプロトコルアプリケーション
別の実施形態では、新規のＡＡＡフレームワークプロトコルアプリケーション、ここでは、ＨＭＩＰｖ６用に構成されているＤｉａｍｅｔｅｒアプリケーションによって例示される、が生成される。これは、例えば、ＭＡＰのディスカバリ（探索）、ＭＡＰの動的割当、ＲＣｏＡの動的割当、ＭＮとＭＡＰ間でのセキュリティキーの配信、ＨＭＩＰｖ６の移動性処理の取り得るピギーバックの少なくとも１つを容易にするＨＭＩＰｖ６情報を搬送する。以下では、Ｄｉａｍｅｔｅｒについて言及されるが、Ｒａｄｉｕｓあるいは他の同様のＡＡＡフレームワークプロトコルを新規のあるいは拡張ＨＭＩＰｖ６アプリケーションに対する基準として使用できることが理解されるべきである。
【０１５５】
要求される場合、ＨＭＩＰｖ６とＭＩＰｖ６の両方の認証及び認可の少なくとも一方は、同一のＡＡＡフレームワークプロトコルアプリケーションに統合することができる。これは、［３］に記載されるＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーションを採用し、これに加えて、新規のＨＭＩＰ専用コマンドコード、ＡＶＰ及びフラグの少なくとも１つを定義することによって達成することができる。ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションの一部として、ＤｉａｍｅｔｅｒＭＩＰｖ６のコマンドコード、ＡＶＰ及びフラグを含めることによって、より少ないセットアップ回数を可能とする単一の移動（single traversal）で、ＨＭＩＰｖ６とＭＩＰｖ６の両方の認証及び認可の少なくとも一方を同時に実行することが可能となる。特定の場合に特別に必要とするＭＮに依存して、ＭＩＰｖ６に対応するものなしで、ＨＭＩＰｖ６の認証及び認可の少なくとも一方を実行することが可能となり、その逆も可能である。これは、単一のアプリケーションである、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションに、様々な使用状況で使用される場合の柔軟性を与えることを可能にする。
【０１５６】
また、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーション内のＨＭＩＰｖ６の移動性処理のピギーバックは、共通の処理内で、認証、認可及び移動性を最適化することによって、全体のセットアップ回数をできる限り少なくすることを可能にする。
【０１５７】
ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションの詳細
以下では、例として、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションの詳細を、全体フロー及び実行可能性の概念の例示するために提供する。好ましくは、新規のＨＭＩＰｖ６−専用コマンドコード、ＡＶＰ、及びフラグの少なくとも１つが定義され、これは、例えば、ＭＡＰのディスカバリ（探索）、ＭＡＰの動的割当、ＲＣｏＡの動的割当、ＭＮとＭＡＰ間でのセキュリティキーの配信、ＨＭＩＰｖ６の移動性処理の取り得るピギーバックの少なくとも１つを容易にする情報を搬送することになる。ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーション［３］のコマンドコード、ＡＶＰ及びフラグは、オプションとして、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションの一部として含められても良い。
【０１５８】
ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコードとＡＶＰの抜粋の構成例が、以下の表２で与えられる。
【０１５９】
2006527966.tif 000007
2006527966.tif 000008
【０１６０】
追加の情報については、インターネットドラフト［５］は、ネットワークアクセスサーバ（ＮＡＳ）とバックエンド認証サーバ間でＥＡＰパケットを搬送するために必要なコマンドコードとＡＶＰを定義している。
【０１６１】
ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーション用のシグナリング（信号送受信）フロー例
図９は、ＭＡＰがホームネットワークに配置されている場合に対する、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションシグナリング（信号送受信）フローの例を示している。
【０１６２】
ＡＡＡクライアントは、例えば、インターネット制御メッセージプロトコル（ＩＣＭＰ）、ＰＡＮＡ等のプロトコルを介して、認証対象のＭＮに対してチャレンジを発行する。ＭＮは、ＨＭＩＰｖ６に従って、また、おそらくは、ＭＩＰｖ６ブートストラップリクエストにも従って、チャンレンジ応答で応答する。
【０１６３】
ＡＡＡクライアントは、ＨＭＩＰｖ６とＭＩＰｖ６ブートストラップリクエストを理解し、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＡＲＲ）を使用するＡＡＡインフラストラクチャを介して、ＭＮ応答をＡＡＡｈへ送信する。この処理では、ＡＡＡクライアントも、ＡＡＡｈにＭＮの認証を検証することを可能にするチャレンジを含んでいる。
【０１６４】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味し、また、ＡＡＡｈはＭＮの別のリクエストの処理に進む。
【０１６５】
まず、ＡＡＡｈは、ホームネットワーク内のＭＡＰを選択して、例えば、セキュリティキー群を備える適切なＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＭＡＲ）をＭＡＰへ送信する。また、必要であればあるいはそうでなければ適切であれば、コマンドコード（ＭＡＡ）を介してＭＮとのセキュリティアソシエーションを完成するために、好ましくは、情報を提供することによって、ＭＡＰはＡＡＡｈに応答する。第２に、ＭＩＰｖ６ブートストラップがリクエストされる場合に、ＡＡＡｈは、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＨＯＲ）を使用するＨＡを選択することによって、ＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。そして、ＨＡは、コマンドコード（ＨＯＡ）を介してＭＮとのセキュリティアソシエーションを生成するために必要な情報を提供することによってＡＡＡｈに応答する。ここで、認証及び認可の交換時に、「ＭＡＰバインディング更新」と「ＨＡバインディング更新」とをピギーバックすることが可能であることに注意する。この場合に対しては、ＭＡＰとの最初の処理において、ＡＡＡｈによって取得されるＨＭＩＰｖ６  ＲＣｏＡは、自動的に、次の操作でＨＡで更新されるＭＩＰｖ６バインディングとなる。
【０１６６】
ＡＡＡｈが、上述のように、ＭＡＰとＨＡと通信した後、ＡＡＡｈは、認可（及び／あるいはコンフィグレーション（構成））情報をＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＡＲＡ）と、例えば、ＩＣＭＰ、ＰＡＮＡ等を介してＭＮへ返信する。ここで、この情報には、例えば、ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス、及び認証成功指示に従うセキュリティアソシエーション情報がある。
【０１６７】
図１０は、ＭＡＰが訪問先ネットワークに配置されている場合に対する、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーション信号送受信フローの例を示している。
【０１６８】
ＡＡＡクライアントは、例えば、ＩＣＭＰあるいはＰＡＮＡを介して、認証対象のＭＮに対してチャレンジを発行する。ＭＮは、ＨＭＩＰｖ６に従って、また、おそらくは、ＭＩＰｖ６ブートストラップリクエストにも従って、チャンレンジ応答で応答する。
【０１６９】
ＡＡＡクライアントは、ＨＭＩＰｖ６とＭＩＰｖ６ブートストラップリクエストを理解し、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＡＲＲ）を使用するＡＡＡインフラストラクチャを介して、ＭＮ応答をＡＡＡｈへ送信する。この処理では、ＡＡＡクライアントも、ＡＡＡｈにＭＮの認証を検証することを可能にするチャレンジを含んでいる。
【０１７０】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味し、また、ＡＡＡｈはＭＮの別のリクエストの処理に進む。
【０１７１】
まず、ＡＡＡｈは、訪問先ネットワーク内のＭＡＰに対するリクエストを適切なＡＡＡｖへ送信する。これは、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＭＡＲ）を介して実行される。ＡＡＡｖは、訪問先ネットワーク内のＭＡＰを選択して、例えば、セキュリティキー（群）を含むコマンドコード（ＭＡＲ）をＭＡＰへ送信する。また、必要であればあるいはそうでなければ適切であれば、コマンドコード（ＭＡＡ）を使用するＭＮとのセキュリティアソシエーションを完成するための情報を提供することによって、ＭＡＰはＡＡＡｖを介してＡＡＡｈに応答する。第２に、必要である場合、ＡＡＡｈは、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＨＯＲ）を使用するＨＡを選択することによって、ＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。そして、ＨＡは、コマンドコード（ＨＯＡ）を介して、ＭＮとのセキュリティアソシエーションを生成するために必要な情報を提供することによってＡＡＡｈに応答する。ここで、認証及び認可の交換時に、「ＭＡＰバインディング更新」と「ＨＡバインディング更新」とをピギーバックすることが可能であることに注意する。この場合に対しては、ＭＡＰとの最初の処理において、ＡＡＡｈによって取得されるＨＭＩＰｖ６  ＲＣｏＡは、自動的に、次の操作でＨＡで更新されるＭＩＰｖ６バインディングとなる。
【０１７２】
ＡＡＡｈが、上述のように、ＭＡＰとＨＡと通信した後、ＡＡＡｈは、認可（及び／あるいはコンフィグレーション（構成））情報を、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションコマンドコード（ＡＲＡ）と、ＩＣＭＰあるいはＰＡＮＡのようなプロトコルを介してＭＮへ返信する。ここで、この情報には、例えば、ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス、及び認証成功指示に従うセキュリティアソシエーション情報がある。
【０１７３】
いくつかの上述の構成をまとめると、ＡＡＡインフラストラクチャにおける信用は、ＨＭＩＰｖ６サービスをブートストラップするためのいくつかの可能性を提案していることを確認することができる。例えば、ＡＡＡインフラストラクチャを介して搬送される現在のあるいは将来のＥＡＰバージョンのような汎用認証プロトコルへの拡張を提供することと、Ｄｉａｍｅｔｅｒ及びＲａｄｉｕｓアプリケーションのようなＡＡＡフレームワークプロトコルアプリケーションを拡張することの少なくとも一方を可能にする。
【０１７４】
図１１は、移動ノードに対してＨＭＩＰｖ６をサポートする方法の基本的な例のフロー図である。この例では、ステップＳ１〜Ｓ４で示される情報転送及び動作は、移動ノードの認証（Ｓ１）、ＭＮ−ＭＡＰセキュリティアソシエーションの確立（Ｓ２）、ＨＭＩＰｖ６コンフィグレーション（Ｓ３）、及びＨＭＩＰｖ６バインディング（Ｓ４）に関するものである。ステップＳ２〜Ｓ３は、通常、認可フェーズとして見なされる。ステップＳ１〜Ｓ４は、要求される場合、ほぼ平行して、ＨＭＩＰｖ６セキュリティアソシエーション処理として、同一のラウンドトリップ内でピギーバックとＨＭＩＰｖ６バインディングとが実行されても良く、これにより、全体のセットアップ回数を少なくすることができる。ステップＳ１では、ホームネットワーク側の移動ノードを認証するために、ＡＡＡインフラストラクチャを介して情報が送信される。ステップＳ２では、ＨＭＩＰｖ６関連情報が送信されて、直ちに確立する、あるいはＭＮとＭＡＰ間でのセキュリティアソシエーションの将来の確立を可能にする。ステップＳ３では、例えば、コンフィグレーションパラメータを、それを適切に記憶するための移動ノードへ送信することによって、追加のＨＭＩＰｖ６コンフィグレーションが実行される。ステップＳ４では、移動ノードは、バインディング更新を送信し、また、ＨＭＩＰｖ６バインディングがＭＡＰ内で確立される。
【０１７５】
他のアプリケーションの領域に渡って、本発明は、あらゆるアクセスネットワークに適用することが可能である。これには、ＷＬＡＮ、ＣＤＭＡ２０００、ＷＣＤＭＡ等がある。また、ＨＭＩＰｖ６と、オプションとしてＭＩＰｖ６も使用することができ、これは、次のような技術を含んでいる。この技術には、ＡＡＡとＩＰｖ６移動性、ＣＭＳ１１、ＷＣＤＭＡ及びＧＳＭシステムのようなシステム群と、サービス／アプリケーションサブシステム及び端末のようなサブシステム、ＡＡＡサーバ、ホームエージェントサーバ及び端末ノードのような製品がある。
【０１７６】
ＭＮ−ＨＡキー配信に対する上述の例の処理の代替として、ＭＮとＨＡに対して動的に事前共有されるキーを配信するために、ＩＫＥフレームワークとともに現在の３ＧＰＰ２ソリューションと同様のメカニズムを使用することができる。
【０１７７】
上述の実施形態は、単なる例として挙げられていて、本発明がそれに限定されるものではないことが理解されるべきである。本明細書で、開示され、かつ請求項で示される原理を根本とする基礎を維持する、更なる、変形、変更及び改良は、本発明の範囲にある。
【０１７８】
参考文献
［１］ＩＰｖ６における移動性のサポート、ディー．ジョンソン、シー．パーキンス、ジェイ．アルコ、２００３年６月３０日、＜ draft-ietf-mobileip-ipv6-24.txt ＞（Mobility Support inIPv6, D. Johnson, C. Perkins, J. Arkko, June 30,2003, ＜ draft-ietf-mobileip-ipv6-24.txt ＞）
［２］階層モバイルＩＰｖ６移動性管理（ＨＭＩＰｖ６）、ヘシャム  ソリマン、クラウド  カステルチア、カリム  エル−マルキ、ルドビック  ベリラー、２００３年６月、＜ draft-ietf-mobileip-hmipv6-08.txt ＞（Hierarchical MobileIPv6 mobility management (HMIPv6), Hesham Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier, June, 2003, ＜ draft-ietf-mobileip-hmipv6-08.txt ＞）
［３］ＤｉａｍｅｔｅｒモバイルＩＰｖ６アプリケーション、ステファノ  エム．ファッチン、フランク  レ、バサバラヤ  パチル、チャールズ  イー．ペルキンス、２００３年４月 ＜ draft-le-aaa-diameter-mobileipv6-03.txt ＞（Diameter MobileIPv6 Application, Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E. Perkins, April 2003, ＜ draft-le-aaa-diameter-mobileipv6-03.txt ＞）
［４］ＥＡＰに基づくＭＩＰｖ６認可及びコンフィグレーション、ジー．ジアレッタ、アイ．グアルディニ、イー．デマリア、２００４年２月、＜ draft-giaretta-mip6-authorization-eap-OO.txt ＞（MIPv6 Authorization and Configuration based on EAP, G. Giaretta, I.Guardini, E. Demaria, February 2004, ＜ draft-giaretta-mip6-authorization-eap-OO.txt ＞）
［５］Ｄｉａｍｅｔｅｒ拡張可能認証プロトコル（ＥＡＰ）アプリケーション、ピー．エロネン、ティー．ヒルラー、ジー．ゾルン、２００４年２月１６日、＜ draft-ietf-aaa-eap-04.txt ＞（Diameter Extensible Authentication Protocol (EAP) Application, P. Eronen, T. Hiller, G. Zorn, February 16,2004, ＜ draft-ietf-aaa-eap-04.txt ＞）
［６］ＰＰＰ拡張可能認証プロトコル（ＥＡＰ）、ＲＦＣ２２８４、エル．ブルンク、ジェイ．ボルブレッヒ、１９９８年３月（PPP Extensible Authentication Protocol (EAP),RFC2284, L. Blunk, J. Vollbrecht, March 1998）
［７］ＩＥＥＥ規格８０２．１Ｘ、ローカル及びメトロポリタンネットワーク−ポートベースのネットワークアクセス制御（IEEE Standard 802. 1X, Local and metropolitan area networks-Port-Based Network Access Control）
［８］インターネットセキュリティアソシエーション及びキー管理プロトコル（ＩＳＡＫＭＰ）、ＲＦＣ２４０８、ディー．マウガン、エム．シェルトラー、エム．シュナイダー、ジェイ．ターナー、１９９８年１１月（Internet Security Association and Key Management Protocol (ISAKMP),RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998）
［９］ＤｉａｍｅｔｅｒモバイルＩＰｖ４アプリケーション、ピー．カルホン、ティー、ジョアンソン、シー．ペルキンス、２００３年、＜ draft-ietf-aaa-diameter-mobileip-14.txt ＞（Diameter MobileIPv4 Application, P. Calhoun, T. Johansson, C. Perkins, 2003, ＜ draft-ietf-aaa-diameter-mobileip-14.txt ＞）
［１０］リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）−ＲＦＣ２８６５、シー．リギニー、エス．ウィレンス、エイ．ルーベンス、ダブリュ．シムプソン、２０００年６月（Remote Authentication Dial In User Service(RADIUS)-RFC2865, C. Rigney, S. Willens, A. Rubens, W. Simpson, June 2000）
［１１］ＲＡＤＩＵＳ拡張−ＲＦＣ２８６９、シー．リグニー、ダブリュ．ウィルラッツ、ピー．カルホウン、２０００年６月（RADIUS Extensions-RFC2869, C. Rigney, W. Willats, P. Calhoun, June 2000）
［１２］拡張可能認証プロトコル（ＥＡＰ）−ＲＦＣ２２８４、エル．ブランク、ジェイ．ボルブレッヒ、ビー．アボバ、ジェイ．カールソン、エイチ．レブコベッツ、２００３年７月、＜ draft-ietf-eap-rfc2284bis-06.txt ＞（Extensible Authentication Protocol(EAP)-RFC2284, L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, September 2003, ＜ draft-ietf-eap-rfc2284bis-06.txt ＞）
［１３］ＥＡＰ同位認証器用状態マシーン、ジェイ．ボルフレッヒ、ピー．エロネン、エヌ．ペトロニ、ワイ．オオバ、２００３年１０月、＜ draft-ietf-eap-statemachine-01.pdf ＞（State Machines for EAP Peer and Authenticator, J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, October 2003, ＜ draft-ietf-eap-statemachine-01.pdf ＞）
【図面の簡単な説明】
【０１７９】
【図１】訪問先ネットワーク内のＭＡＰを有する、従来のＨＭＩＰｖ６ドメインを示す図である。
【図２】本発明の実施形態に従う、訪問先ネットワークでローミングする移動ノードに対する、ＨＭＩＰｖ６サポート用の新規なアーキテクチャを示す図である。
【図３】本発明の別の実施形態に従う、訪問先ネットワークでローミングする移動ノードに対する、ＨＭＩＰｖ６サポート用の新規なアーキテクチャを示す図である。
【図４】本発明の実施形態に従う、自身のホームネットワークで動作する移動ノードに対する、ＨＭＩＰｖ６サポート用の新規なアーキテクチャを示す図である。
【図５】本発明の実施形態に従う、ＡＡＡホームネットワークサーバのブロック図である。
【図６】本発明の実施形態に従うＭＡＰノードのブロック図である。
【図７】ＭＡＰがホームネットワークに配置される場合において、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＨＭＩＰｖ６を使用するＨＭＩＰｖ６  ＡＡＡに対する信号送受信フローを示す図である。
【図８】ＭＡＰが訪問先ネットワークに配置される場合において、Ｄｉａｍｅｔｅｒ  ＨＭＩＰｖ６アプリケーションとともに、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＨＭＩＰｖ６を使用するＨＭＩＰｖ６  ＡＡＡに対する信号送受信フローを示す図である。
【図９】ＭＡＰがホームネットワークに配置される場合において、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションを使用するＨＭＩＰｖ６  ＡＡＡに対する信号送受信フローを示す図である。
【図１０】ＭＡＰが訪問先ネットワークに配置される場合において、ＤｉａｍｅｔｅｒＨＭＩＰｖ６アプリケーションを使用するＨＭＩＰｖ６  ＡＡＡに対する信号送受信フローを示す図である。
【図１１】移動ノードに対してＨＭＩＰｖ６サービスをサポートするための方法の例を示すフロー図である。
【図１】
2006527966.tif 000009
【図２】
2006527966.tif 000010
【図３】
2006527966.tif 000011
【図４】
2006527966.tif 000012
【図５】
2006527966.tif 000013
【図６】
2006527966.tif 000014
【図７】
2006527966.tif 000015
【図８】
2006527966.tif 000016
【図９】
2006527966.tif 000017
【図１０】
2006527966.tif 000018
【図１１】
2006527966.tif 000019
【手続補正書】
【提出日】平成18年2月16日(2006.2.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートする方法であって、
ＨＭＩＰｖ６サービスをブートストラップするためにＡＡＡインフラストラクチャを使用し、
前記ＡＡＡインフラストラクチャは、前記ＨＭＩＰｖ６サービスに対し、適切な移動性アンカーポイント（ＭＡＰ）を前記移動ノードへ割り当て、
前記ＡＡＡインフラストラクチャを介して、前記割り当てられたＭＡＰでの前記ＨＭＩＰｖ６サービスに対する前記移動ノードを認証し、かつ認可するために必要なＨＭＩＰｖ６関連情報を送信する
ことを特徴とする方法。
【請求項２】
前記インフラストラクチャのＡＡＡサーバは、前記ＨＭＩＰｖ６サービスに対し、適切なＭＡＰを前記移動ノードへ割り当てる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記移動ノードは、訪問先ネットワークでローミングしていて、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークのオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＭＡＰを前記移動ノードへ割り当てる
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ホームネットワークのＡＡＡインフラストラクチャコンポーネントは、前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーションに対する信用関連データを生成し、その信用関連データを前記ＭＡＰへ送信し、
前記ＡＡＡインフラストラクチャコンポーネントは、前記セキュリティアソシエーションを完成するための情報を生成する、あるいは前記ＭＡＰは、前記セキュリティアソシエーションを完成するための情報で、前記ＡＡＡインフラストラクチャコンポーネントに応答する、ここで、前記ＭＡＰは、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６認可情報を前記移動ノードへ送信する
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記移動ノードと前記割当ＭＡＰ間のＨＭＩＰｖ６セキュリティアソシエーションを確立し、かつ前記移動ノードに対するＨＭＩＰｖ６バインディングを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信し、
ＨＭＩＰｖ６バインディング用のＨＭＩＰｖ６関連情報は、ＨＭＩＰｖ６セキュリティアソシエーション用のＨＭＩＰｖ６関連情報として、同一のラウンドトリップで送信される
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記移動ノードは、訪問先ネットワーク内でローミングしていて、
ＨＭＩＰｖ６関連認証及び認可情報は、前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＨＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックにおける汎用コンテナで送信される
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記割当ＭＡＰは、前記訪問先ネットワーク内に配置されていて、
ＨＭＩＰｖ６関連情報は、前記認証プロトコルで、前記移動ノードと前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、
ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記訪問先ネットワーク内の前記割当ＭＡＰ間を送信される
ことを特徴とする請求項６に記載の方法。
【請求項１０】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするシステムであって、
前記ＨＭＩＰｖ６サービスに対し、適切な移動性アンカーポイント（ＭＡＰ）を前記移動ノードへ割り当るように動作可能なＡＡＡインフラストラクチャコンポーネントと、
前記ＡＡＡインフラストラクチャを介して、前記割り当てられたＭＡＰでの前記ＨＭＩＰｖ６サービスに対する前記移動ノードを認証し、かつ認可するために必要なＨＭＩＰｖ６関連情報を送信する手段と
を備えることを特徴とするシステム。
【請求項１１】
前記インフラストラクチャコンポーネントは、ＡＡＡサーバであり、これは、前記ＨＭＩＰｖ６サービスに対し、適切なＭＡＰを前記移動ノードへ割り当てるように動作可能である
ことを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記移動ノードは、訪問先ネットワークでローミングしていて、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークのオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＭＡＰを前記移動ノードへ割り当てるように動作可能である
ことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記ホームネットワークのＡＡＡインフラストラクチャコンポーネントは、
前記移動ノードと前記割当ＭＡＰ間のセキュリティアソシエーションに対する信用関連データを生成する手段と、
前記信用関連データを前記割当ＭＡＰへ送信する手段と、
前記セキュリティアソシエーションを完成するための情報を前記ＭＡＰから受信する手段と、
前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６認可情報を前記移動ノードへ送信する手段と
を備えることを特徴とする請求項１０に記載のシステム。
【請求項１４】
前記移動ノードと前記割当ＭＡＰ間のＨＭＩＰｖ６セキュリティアソシエーションを確立し、かつ前記移動ノードに対するＨＭＩＰｖ６バインディングを確立するために、前記ＡＡＡインフラストラクチャを介して、ＨＭＩＰｖ６関連情報を送信する手段とを備え、
ＨＭＩＰｖ６バインディング用のＨＭＩＰｖ６関連情報は、ＨＭＩＰｖ６セキュリティアソシエーション用のＨＭＩＰｖ６関連情報として、同一のラウンドトリップで送信される
ことを特徴とする請求項１０に記載のシステム。
【請求項１５】
前記移動ノードは、訪問先ネットワーク内でローミングしていて、
ＨＭＩＰｖ６関連認証及び認可情報は、前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１０に記載のシステム。
【請求項１６】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＨＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記ＨＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックにおける汎用コンテナで送信される
ことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記割当ＭＡＰは、前記訪問先ネットワーク内に配置され、
ＨＭＩＰｖ６関連情報は、前記認証プロトコルで、前記移動ノードとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、
ＨＭＩＰｖ６関連情報は、ＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記訪問先ネットワーク内の前記割当ＭＡＰ間を送信される
ことを特徴とする請求項１５に記載のシステム。
【請求項１９】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするＡＡＡサーバであって、
前記ＨＭＩＰｖ６サービスに対し、適切な移動性アンカーポイント（ＭＡＰ）を前記移動ノードへ割り当る手段を備える
ことを特徴とするＡＡＡサーバ。
【請求項２０】
前記移動ノードは、訪問先ネットワークでローミングしていて、
前記ＡＡＡサーバは、前記訪問先ネットワーク内のＭＡＰを割り当てるために動作可能なＡＡＡ訪問先ネットワークサーバである
ことを特徴とする請求項１９に記載のＡＡＡサーバ。
【請求項２１】
前記ＡＡＡサーバは、前記移動ノードの前記ホームネットワーク内のＭＡＰを割り当てるために動作可能なＡＡＡホームネットワークサーバ（ＡＡＡｈ）である
ことを特徴とする請求項１９に記載のＡＡＡサーバ。
【請求項２２】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするＡＡＡホームネットワークサーバ（ＡＡＡｈ）であって、
前記移動ノードと、ＡＡＡインフラストラクチャコンポーネントによって割り当てられる移動性アンカーポイント（ＭＡＰ）間のセキュリティアソシエーションに対する信用関連データを生成する手段と、
前記信用関連データを前記割当ＭＡＰへ送信する手段と、
前記セキュリティアソシエーションを完成するための情報を前記ＭＡＰから受信する手段と、
前記移動ノードへ、セキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を送信する手段と
を備えることを特徴とするＡＡＡホームネットワークサーバ。
【請求項２３】
前記移動ノードは、訪問先ネットワークでローミングしていて、
前記ＨＭＩＰｖ６認可情報を送信する手段は、前記訪問先ネットワークと、前記移動ノードの前記ホームネットワークとをリンクしているＡＡＡインフラストラクチャを介して、前記情報を送信するために動作可能である
ことを特徴とする請求項２２に記載のＡＡＡホームネットワークサーバ。
【請求項２４】
前記ＡＡＡホームネットワークサーバは、前記セキュリティアソシエーションを完成し、かつアドレス情報をバインディングするための情報を前記割当ＭＡＰから受信するように構成されていて、
前記ＨＭＩＰｖ６認可情報を送信する手段は、前記ＡＡＡインフラストラクチャを介して、ＭＡＰ割当情報、バインディングアドレス情報及びセキュリティアソシエーション情報を含むＨＭＩＰｖ６認可情報を前記移動ノードへ送信するように構成されている
ことを特徴とする請求項２３に記載のＡＡＡホームネットワークサーバ。
【請求項２５】
移動ノード用の階層モバイルＩＰバージョン６（ＨＭＩＰｖ６）サービスをサポートするシステムであって、
ＨＭＩＰｖ６サービスに対し、前記移動ノードを認証し、かつ認可するために、ＡＡＡインフラストラクチャを介して、拡張可能認証プロトコル（ＥＡＰ）で、前記移動ノードとＡＡＡホームネットワークサーバ間を、ＨＭＩＰｖ６関連認証及び認可情報を送信する手段とを備え、
前記ＨＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とするシステム。
【国際調査報告】
2006527966.tif 000020
2006527966.tif 000021
2006527966.tif 000022