(57)【要約】  基本概念は、適切なＤＨＣＰサーバを、ＤＨＣＰサービスに対するＤＨＣＰクライアントへ割り当て（Ｓ３）、割り当てられたＤＨＣＰサーバを用いて、ＤＨＣＰサービスに対するＤＨＣＰクライアントを認証（Ｓ１）及び認可（Ｓ４）するために、ＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信することである。従来から知られているより複雑なＤＨＣＰサーバディスカバリープロセスに代えて、より詳しくは、適切なＡＡＡサーバあるいはそれに等価なＡＡＡコンポーネントが、適切なＤＨＣＰサーバをＤＨＣＰクライアントに割り当てるために使用される。その結果、ＤＨＣＰディスカバリー関連メッセージのこれ以上の強制的な依存性はなくなる。本発明は、好ましくは、ＤＨＣＰ認証拡張（ＲＦＣ３１１８）のブートストラップを容易にするＤＨＣＰ関連情報を搬送することによって、適切なＤＨＣＰサーバの割当を容易にし、かつＤＨＣＰクライアントとサーバに対する帯域外キーアグリーメントプロトコルを提供するＡＡＡプロトコルサポートを提供する。
2007534267.tif 000002
【特許請求の範囲】
【請求項１】
ＤＨＣＰクライアント用の動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートする方法であって、
ＡＡＡインフラストラクチャコンポーネントで、適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てる工程と、
前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するための前記ＡＡＡインフラストラクチャコンポーネントを介して、ＤＨＣＰ関連情報を送信する工程と
を備えることを特徴とする請求項１に記載の方法。
【請求項２】
前記送信する工程は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信することを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＡＡＡインフラストラクチャのＡＡＡサーバは、適切なＤＨＣＰサーバを前記ＤＨＣＰクライアントに割り当てる
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てる
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＡＡＡｖサーバは、前記訪問先ネットワークオペレータのポリシーに基づいて、ＤＨＣＰサーバを割り当てる
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記モバイルホストは、前記ＡＡＡインフラストラクチャを介して、ＤＨＣＰ割当リクエストをＡＡＡホームネットワークサーバ（ＡＡＡｈ）へ送信し、
前記ＡＡＡｈは、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ転送し、
前記ＡＡＡホームネットワークサーバは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データは、前記ＡＡＡｖを介して、前記ＡＡＡｈから前記ＤＨＣＰサーバへ転送され、
前記ＡＡＡｈは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ＡＡＡｖを介して前記ＡＡＡｈへ応答し、
前記ＡＡＡｈは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
ことを特徴とする請求項４に記載の方法。
【請求項７】
前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記ＤＨＣＰクライアントへ割り当てる
ことを特徴とする請求項３に記載の方法。
【請求項８】
前記ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データを、前記割り当てられたＤＨＣＰサーバへ送信し、
前記ＡＡＡｈは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ＡＡＡｈへ応答し、
前記ＡＡＡｈは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記ＤＨＣＰ関連情報は、認証プロトコルで、前記モバイルホストと前記ホームネットワークサーバ（ＡＡＡｈ）間を送信され、
ＤＨＣＰ関連情報は、前記認証プロトコルの別セッションで、あるいはＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記割り当てられたＤＨＣＰサーバ間を送信される
ことを特徴とする請求項７に記載の方法。
【請求項１０】
前記ＤＨＣＰクライアントはモバイルホストであり、
前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データを、前記ＤＨＣＰサーバへ送信し、
前記ホームネットワークのＡＡＡコンポーネントは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ホームネットワークのＡＡＡコンポーネントへ応答し、
前記ホームネットワークのＡＡＡコンポーネントは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記送信する工程は、前記ＤＨＣＰクライアントと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記ＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信する工程を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記割り当てられたＤＨＣＰサーバは前記訪問先ネットワークに配置され、
ＡＡＡフレームワークプロトコルアプリケーションで、ＤＨＣＰ関連情報は、前記ＡＡＡｈと前記訪問先ネットワーク内の前記割り当てられたＤＨＣＰサーバ間を送信される
ことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項１に記載の方法。
【請求項１６】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＤＨＣＰ用に適合されているＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行する
ことを特徴とする請求項１に記載の方法。
【請求項１８】
ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするシステムであって、
適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てるように動作可能なＡＡＡインフラストラクチャコンポーネントと、
前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するための前記ＡＡＡインフラストラクチャコンポーネントを介して、ＤＨＣＰ関連情報を送信する手段と
を備えることを特徴とするシステム。
【請求項１９】
前記送信する手段は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信する手段を含む
ことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記ＡＡＡインフラストラクチャコンポーネントは、適切なＤＨＣＰサーバを前記ＤＨＣＰクライアントに割り当てるように動作可能なＡＡＡサーバである
ことを特徴とする請求項１８に記載のシステム。
【請求項２１】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てるように動作可能である
ことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記ＡＡＡｖサーバは、前記訪問先ネットワークオペレータのポリシーに基づいて、ＤＨＣＰサーバを割り当てるように動作可能である
ことを特徴とする請求項２１に記載のシステム。
【請求項２３】
ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、
前記モバイルホストから、ＤＨＣＰ割当リクエストを受信し、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ送信する手段と、
前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記ＡＡＡｖを介して前記割り当てられたＤＨＣＰサーバへ送信し、かつ前記ＡＡＡｖを介して前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
を備えることを特徴とする請求項２１に記載のシステム。
【請求項２４】
前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記モバイルホストへ割り当てるように動作可能である
ことを特徴とする請求項２０に記載のシステム。
【請求項２５】
ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、
前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記割り当てられたＤＨＣＰサーバへ送信する手段と、
前記ＤＨＣＰサーバから、前記セキュリティアソシエーションを成立させるための情報を受信する手段と、
ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
を備えることを特徴とする請求項２４に記載のシステム。
【請求項２６】
前記ＤＨＣＰ関連情報は、認証プロトコルで、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信され、
ＤＨＣＰ関連情報は、前記認証プロトコルの別セッションで、あるいはＡＡＡフレームワークプロトコルアプリケーションで、前記ＡＡＡｈと前記割り当てられたＤＨＣＰサーバ間を送信される
ことを特徴とする請求項２４に記載のシステム。
【請求項２７】
前記ＤＨＣＰクライアントはモバイルホストであり、
前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、
前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを、前記割り当てられたＤＨＣＰサーバへ送信する手段と、
前記セキュリティアソシエーションを成立させるための情報を前記ＤＨＣＰサーバから受信する手段と、
ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
を備えることを特徴とする請求項１８に記載のシステム。
【請求項２８】
前記送信する手段は、前記ＤＨＣＰクライアントと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記ＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信する手段を含んでいる
ことを特徴とする請求項１８に記載のシステム。
【請求項２９】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１８に記載のシステム。
【請求項３０】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記割り当てられたＤＨＣＰサーバは前記訪問先ネットワークに配置され、
ＡＡＡフレームワークプロトコルアプリケーションで、ＤＨＣＰ関連情報が、前記ＡＡＡｈと前記訪問先ネットワーク内の前記割り当てられたＤＨＣＰサーバ間で送信される
ことを特徴とする請求項２９に記載のシステム。
【請求項３２】
前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項１８に記載のシステム。
【請求項３３】
前記ＡＡＡフレームワークプロトコルアプリケーションは、ＤＨＣＰ用に適合されているＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションである
ことを特徴とする請求項３２に記載のシステム。
【請求項３４】
前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行する手段を更に備える
ことを特徴とする請求項１８に記載のシステム。
【請求項３５】
ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡサーバであって、
前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ、適切なＤＨＣＰサーバを割り当てる手段を備える
ことを特徴とするＡＡＡサーバ。
【請求項３６】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、前記ＡＡＡサーバは、前記訪問先ネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）である
ことを特徴とする請求項３５に記載のＡＡＡサーバ。
【請求項３７】
前記ＡＡＡｖサーバは、前記訪問先ネットワークオペレータのポリシーに基づいて、ＤＨＣＰサーバを割り当てるように動作可能である
ことを特徴とする請求項３６に記載のＡＡＡサーバ。
【請求項３８】
前記ＤＨＣＰクライアントはモバイルホストであり、前記ＡＡＡサーバは、前記モバイルホストの前記ホームネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡホームネットワークサーバ（ＡＡＡｈ）である
ことを特徴とする請求項３５に記載のＡＡＡサーバ。
【請求項３９】
前記ＤＨＣＰサーバを割り当てる手段は、前記モバイルホストから開始されるＤＨＣＰ割当リクエストに応答して動作する
ことを特徴とする請求項３５に記載のＡＡＡサーバ。
【請求項４０】
前記ＤＨＣＰサーバを割り当てる手段は、ネットワークから開始されるＤＨＣＰサーバ割当を実行するように動作可能である
ことを特徴とする請求項３５に記載のＡＡＡサーバ。
【請求項４１】
モバイルホストに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡホームネットワークサーバであって、
前記モバイルホストとＡＡＡインフラストラクチャコンポーネントによって割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記割り当てられたＤＨＣＰサーバへ送信する手段と、
前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
前記モバイルホストへ、ＤＨＣＰセキュリティアソシエーション情報を含むＤＨＣＰ認可情報を送信する手段と
を備えることを特徴とするＡＡＡホームネットワークサーバ。
【請求項４２】
前記ＤＨＣＰ認可情報を送信する手段は、ＤＨＣＰサーバ割当情報を前記モバイルホストへ送信するように動作可能である
ことを特徴とする請求項４１に記載のＡＡＡホームネットワークサーバ。
【請求項４３】
当該ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記モバイルホストへの更なる送信のために、前記ＡＡＡインフラストラクチャコンポーネントから前記ＤＨＣＰサーバ割当情報を受信するように動作可能である
ことを特徴とする請求項４２に記載のＡＡＡホームネットワークサーバ。
【請求項４４】
前記モバイルホストは、訪問先ネットワーク内をローミングするホストであり、
前記ＤＨＣＰ認可情報を送信する手段は、前記モバイルホストの前記ホームネットワークと前記訪問先ネットワークとをリンクするＡＡＡインフラストラクチャを介して、前記情報を送信するように動作可能である
ことを特徴とする請求項４２に記載のＡＡＡホームネットワークサーバ。
【請求項４５】
前記ＡＡＡホームネットワークサーバは、前記割り当てられたＤＨＣＰサーバから、ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信するように構成され、
前記ＤＨＣＰ認可情報を送信する手段は、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記モバイルホストへ送信するように構成されている
ことを特徴とする請求項４４に記載のＡＡＡホームネットワークサーバ。
【請求項４６】
モバイルホストに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするシステムであって、
ＤＨＣＰサービスに対する前記モバイルホストを認証し、かつ認可するＡＡＡインフラストラクチャを介して、訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報を、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間で送信する手段を備える
ことを特徴とするシステム。
【請求項４７】
前記ＤＨＣＰ関連認証及び認可情報は、拡張可能認証プロトコル（ＥＡＰ）で、前記モバイルホストとＡＡＡホームネットワークサーバ間を送信され、
前記ＤＨＣＰ関連情報は、ＥＡＰプロトコルスタックに追加データとして組み込まれる
ことを特徴とする請求項４６に記載のシステム。
【請求項４８】
前記送信する手段は、同一のＥＡＰラウンドトリップで、ＤＨＣＰ関連認可情報と認可情報を同時に送信するように構成されている
ことを特徴とする請求項４７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の技術分野
本発明は、一般的には、ネットワーク通信の分野に関するものであり、より詳しくは、ＤＨＣＰ（動的ホストコンフィグレーション（設定）プロトコル）用のＡＡＡ（認証、認可、課金（アカウンティング））サポートに関するものである。
【０００２】
本発明の背景
ＤＨＣＰプロトコル（ＲＦＣ２１３１）［１］は、インターネット及び、モバイルネットワークを含む同様のネットワーク上のホストへコンフィグレーションパラメータを提供するためのフレームワークを提供する。ＤＨＣＰは、基本的には、クライアント−サーバモデルで構築される。このクライアント−サーバモデルでは、指定されたＤＨＣＰサーバホストがネットワークアドレスを割り当て、そのようなコンフィグレーションパラメータを、動的に構成されたＤＨＣＰクライアントに配信する。つまり、ＤＨＣＰクライアントは、ネットワークアドレスのようなコンフィグレーションパラメータを取得するためにＤＨＣＰを使用するホストであり、また、ＤＨＣＰサーバは、コンフィグレーションパラメータをＤＨＣＰクライアントへ返信するホストである。ＤＨＣＰサーバは、通常は、システム管理者によって構成される。基本的なＤＨＣＰプロトコルは、アドレス割当用に３つのメカニズムをサポートしている。自動割当では、ＤＣＨＰは、固定アドレスをＤＨＣＰクライアントへ割り当てる。動的割当では、アドレスは、期限が設定されてクライアントに割り当てられる（あるいは、クライアントがそのアドレスを解放するまで）。手動割当では、アドレスはネットワーク管理者によって割り当てられ、また、ＤＨＣＰは単に割り当てられたアドレスをＤＨＣＰクライアントへ搬送するために使用される。ＤＨＣＰを介してパラメータ（例えば、ＴＣＰ／ＩＰスタックパラメータ）を取得した後は、ＤＨＣＰクライアントは、考慮されているネットワーク内の任意の他のホストとパケット交換することが可能とならなければならない。
【０００３】
ＲＦＣ２１３１のＤＨＣＰプロトコルに従えば、ＤＨＣＰコンフィグレーションを必要とするクライアント１３０は、ＤＨＣＰ  ＤＩＳＣＯＶＥＲ（ディスカバー：探索）メッセージをブロードキャストする。ＤＨＣＰサーバ群１２５は、ＤＨＣＰ  ＯＦＦＥＲ（オファー：申出）を用いてそれぞれ応答することができ、このメッセージには、利用可能なネットワークアドレスと他のオプションのコンフィグレーションパラメータを含んでいる（図１）。クライアント１３０は、ＤＨＣＰサーバ群１２５からＤＨＣＰ  ＯＦＦＥＲメッセージを受信し、実際のＤＨＣＰコンフィグレーションに対して使用すべきＤＨＣＰサーバ群の１つを選択する。次に、クライアントは、選択したＤＨＣＰサーバを示すＤＨＣＰ  ＲＥＱＵＥＳＴメッセージをブロードキャストする。選択されたサーバは、コンフィグレーションをコミットし、最終的には、そのリクエストしているクライアントに対するコンフィグレーションパラメータを含むＤＨＣＰ  ＡＣＫメッセージで応答する。図１に示されるＤＨＣＰサーバディスカバーフェーズ（ＤＨＣＰ  ＤＩＳＣＯＶＥＲ及びＤＨＣＰ  ＯＦＦＥＲ）は、ＤＨＣＰコンフィグレーション用のサービスを行うことができるＤＨＣＰサーバ群のＤＨＣＰクライアントへ通知することが必要とされ、これは、かなり繁雑な処理である。
【０００４】
また、基本的なＤＨＣＰプロトコル（ＲＦＣ２１３１）は、明確なセキュリティメカリズムを含んでおらず、また、一般的には、かなり不安定なものとされている。
【０００５】
ＤＨＣＰ認証拡張（ＲＦＣ３１１８）［２］には、セキュリティを向上するために様々なＤＨＣＰメッセージをどのようにして認証するかを定義するＤＨＣＰ認証プロトコルがある。残念なことに、ＤＨＣＰ認証拡張（ＲＦＣ３１１８）は、ローミングするクライアントをサポートしておらず、また、ＤＨＣＰクライアントとサーバに対する帯域外キーアグリーメントプロトコル（an out-of-band key agreement protocol）の欠如のために、広範囲に展開することができない。
【０００６】
今日までには、局所的な信頼関係を確立し、かつＲＦＣ３１１８とともに使用することができるキーを生成するために、ＥＡＰベースのネットワークアクセス認証メカニズムをどのように使用できるかについてのアウトラインが、ＩＥＴＦで提案されている。
【０００７】
例えば、文献［３］は、セッションキーを生成するＥＡＰ認証方法を利用することによって、ＤＨＣＰクライアントがネットワークアクセスを獲得することを提案している。ネットワークアクセスプロセスの一部として、ＤＨＣＰクライアントと認証エージェント（ＮＡＳ；ＡＡＡクライアント）は互いの意図を通信して、ＤＨＣＰセキュリティアソシエーション（ＳＡ）を生成し、かつ必要とされるパラメータ（例えば、ナンス（nonce）、キーＩＤ等）を交換する。必要とされる情報交換は、ＥＡＰも搬送するＥＡＰ下位レイヤによって取り扱われる。
【０００８】
このことに従って、文献［４］は、ＲＦＣ３１１８をブートストラップ（bootstrap：起動）するために、ＰＡＮＡ内で必要とされる追加のペイロードを提案している。この文献［４］は、ＰＡＮＡ認証の成功後、ＤＨＣＰ  ＳＡがＰＡＮＡ  ＳＡに基づいて生成されることも提案している。
【０００９】
ＥＡＰ下位レイヤが、ＲＦＣ３１１８をブートストラップするために必要とされる情報交換をサポートできないことになる場合が存在する。例えば、ＥＡＰ下位レイヤが、ＰＰＰ、ＩＥＥＥ８０２．１ＸあるいはレガシーＰＡＮＡプロトコルである場合である。必要とするＥＡＰ下位レイヤのサポートを必要とすることは、ＡＡＡクライアントがＲＦＣ３１１８ブートストラップの要件を理解しなければならず、また、ＤＨＣＰクライアントとサーバ間で交換される内容を知っていなければならないことを意味する。
【００１０】
このように、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスに対する潜在的なサポートを改善する必要が存在している。
【００１１】
本発明の要約
本発明は、従来技術の構成のこれらの欠点及び他の欠点を解消するものである。
【００１２】
本発明の一般的な目的は、ＤＨＣＰコンフィグレーションを必要とするモバイルホストのようなＤＨＣＰクライアント用のＤＨＣＰサービスに対して改善されたサポートを提供することである。
【００１３】
このソリューションは、ＤＨＣＰの配備を容易にするメカニズムを含んでいることが好ましい。
【００１４】
特に、ＤＨＣＰサービスの認証及び認可に対して、合理化されていて、そしてなお耐性のあるソリューションを提供することが好ましい。
【００１５】
本発明の特別な目的は、ＤＨＣＰサービスをサポートする方法及びシステムを提供することである。
【００１６】
本発明の更なる目的は、ＤＨＣＰサービスの認証及び認可をサポートする固有のネットワークコンポーネントを提供することである。
【００１７】
これらの及び他の目的は、特許請求の範囲によって定義される本発明によって達成されるものである。
【００１８】
本発明の基本的な特徴は、ＤＨＣＰクライアント用のＤＨＣＰサポートを「ブートストラップ（bootstrap）」するためのＡＡＡインフラストラクチャに依存することである。この概念は、ＡＡＡインフラストラクチャを使用して、適切なＤＨＣＰサーバを、ＤＨＣＰサービスに対するＤＨＣＰクライアントへ割り当て、かつその割り当てられたＤＨＣＰサーバを用いて、ＤＨＣＰサービスに対するＤＨＣＰクライアントを認証及び認可するためのＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信することである。
【００１９】
従来の繁雑なＤＨＣＰサーバディスカバリープロセスに代えて、ＡＡＡインフラストラクチャ、より詳しくは、適切なＡＡＡサーバが、適切なＤＣＨＰサーバをＤＨＣＰクライアントへ割り当てるために使用される。その結果、ＤＨＣＰディスカバリー関連メッセージのこれ以上の強制的な依存性はなくなる。この割当は、典型的には、クライアントホストから開始されるＤＨＣＰサーバ割当リクエストに応答する、あるいはネットワークから開始される（network-initiated）再割当で行われる。
【００２０】
また、割り当てられたＤＨＣＰサーバを用いて、ＤＨＣＰサービスに対するＤＨＣＰクライアントの認証だけではなく認可が、必要なＤＨＣＰ関連認証及び認可情報の送信用のＡＡＡインフラストラクチャを使用することによってサポートされる。ＤＨＣＰブートストラップは、通常、割り当てられたＤＨＣＰサーバとモバイルホスト間のセキュリティアソシエーションの確立に基づいていて、これは、クライアントホストの次のＤＨＣＰコンフィグレーションに関係する通信を安全にする。そのため、ＤＨＣＰ関連情報の送信には、ＤＨＣＰサーバ割当情報（例えば、割り当てられたＤＨＣＰサーバのネットワークアドレス）とＤＨＣＰセキュリティ関連情報のＤＨＣＰクライアントへの送信を含んでいることが好ましい。
【００２１】
重要な状況の例では、ＤＨＣＰクライアントは訪問先ネットワークをローミングするモバイルホストである。訪問先ネットワーク内のＡＡＡサーバ、いわゆる、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、適切なＤＨＣＰサーバをクライアントへ割り当てることを担当することが好ましい。ＤＨＣＰサーバ割当は、例えば、訪問先ネットワークオペレータによって決定されるいくつかのポリシーに基づいていても良い。
【００２２】
ホームネットワークあるいは他のネットワーク内に配置されるＤＨＣＰサーバを構成することが有益である場合が存在することも理解されるであろう。これには、例えば、訪問先ネットワークがＤＣＨＰサーバサポートを提供しない場合がある。ＤＨＣＰサーバがモバイルホストのホームネットワークに配置される場合では、いわゆるＡＡＡホームネットワークサーバ（ＡＡＡｈ）を、ＤＨＣＰサーバ割当用の適切なＡＡＡインフラストラクチャコンポーネントとして使用することが適切な場合がある。
【００２３】
事実、本発明を用いると、ＤＨＣＰサーバの位置は、ホームネットワーク、訪問先ネットワークあるいは他のネットワークにさえも配置することができる。
【００２４】
ＡＡＡインフラストラクチャの信頼性は、ＤＨＣＰ認証及び認可サポートをブートストラップするための様々な可能性を提案する。例えば、ＤＨＣＰクライアントが訪問先ネットワークをローミングするモバイルホストである場合、訪問先ドメインに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、モバイルホストとＡＡＡホームネットワークサーバ間をＤＣＨＰ関連認証及び認可情報（好ましくは、同時に）を送信することはかなり有益であることが証明されている。これは、好ましくは、アクセスネットワークノードのようなノード、ＡＡＡクライアント及び訪問先ネットワーク内のＡＡＡサーバ、更には、他の介在し得る中間ＡＡＡサーバの透過性（transparency）を含んでいる。このことは、訪問先ネットワークのＡＡＡノードを単なるパススルーエージェントとすることを可能にする。これは、重要な効果である。また、モバイルホストとＡＡＡｈ間で事前暗号化を適用することも可能である。これは、エアインタフェースを介する交換を不可視にすることができる。
【００２５】
認証プロトコルは、既存プロトコルあるいは新規なプロトコルに基づく、拡張された認証プロトコルであっても良い。ＤＨＣＰ認証及び認可をブートストラップするための基礎として使用することが可能な認証プロトコルには、拡張可能認証プロトコル（ＥＡＰ）がある。これは、ＥＡＰ拡張を生成するとともに、好ましくは、ＥＡＰ下位レイヤ（群）をそのまま維持する。このことは、通常は、ＤＣＨＰ関連情報が追加データとして、例えば、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性として、ＥＡＰプロトコルスタックに組み込まれることを意味する。あるいは、ＤＣＨＰ関連情報がＥＡＰレイヤあるいはＥＡＰメソッドレイヤ上の汎用コンテナで送信されることを意味する。
【００２６】
別の方法では、補完として使用する、あるいはＥＡＰ拡張の代替として使用することは、ＤＨＣＰに適合されているＤｉａｍｅｔｅｒアプリケーション、あるいはＲａｄｉｕｓプロトコルに基づく対応アプリケーションのような、新規のあるいは拡張されたＡＡＡフレームワークプロトコルアプリケーションを生成するようなＥＡＰ「下位レイヤ（群）」を拡張することになる。
【００２７】
ＤＨＣＰサーバが訪問先ネットワークに配置される場合、新規のあるいは拡張されたＥＡＰ形式のプロトコルは、拡張されたＡＡＡフレームワークプロトコルアプリケーションと組み合わせて使用されることが好ましい。あるいは、選択的には、拡張されたＡＡＡフレームワークプロトコルアプリケーションは、ＥＡＰ形式の拡張のサポートなしで使用される。
【００２８】
ＤＨＣＰサーバがホームネットワークに配置される場合、例えば、新規のあるいは拡張された認証プロトコル、あるいは拡張されたＡＡＡフレームワークプロトコルアプリケーションを使用することが可能である。
【００２９】
例えば、拡張されたＥＡＰあるいはＥＡＰ形式プロトコルは、例えば、ＰＡＮＡ（ネットワークアクセス用認証搬送プロトコル）、ＰＰＰ（ポイントツーポイントプロトコル）、ＩＥＥＥ８０２．１Ｘ、あるいは、モバイルホストと訪問先ネットワーク内のＡＡＡクライアント間のＧＰＲＳ／ＵＭＴＳインタフェースを介して搬送されても良い。また、拡張されたＥＡＰあるいはＥＡＰ形式プロトコルは、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓによって搬送されても良い。
【００３０】
ＤＨＣＰ認証及び認可情報の両方を搬送するためのＥＡＰ拡張のような認証プロトコル拡張の類の、カスタマイズされた認証プロトコルに依存することは、合理化されたソリューションを提供する。このことは、後方互換性の問題を最小限にして管理可能であり、かつ的確である。
【００３１】
拡張認証プロトコルスタックあるいは拡張ＡＡＡフレームワークプロトコルアプリケーションに、ＨＭＩＰｖ６関連情報あるいはＭＩＰｖ６関連情報を含めることによって、ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行することが可能である。もちろん、特定の場合に特別に必要とするモバイルホストに依存して、例えば、ＤＨＣＰ／ＨＭＩＰｖ６／ＭＩＰｖ６使用可能ネットワークを使用して、ＨＭＩＰｖ６／ＭＩＰｖ６に対応するものなしで、ＤＨＣＰ認証及び認可のみを実行することが可能であり、その逆も可能である。これは、単一の拡張認証プロトコル及び拡張フレームワークプロトコルアプリケーションの少なくとも一方に、様々な使用状況で使用される場合の柔軟性を与えることを可能にする。
【００３２】
本発明は、以下の効果を提供する：
・ＡＡＡベースのＤＨＣＰサーバ割当
・ＤＨＣＰサポートの効果的なブートストラップ
・ＤＨＣＰサービスを認可するためのＤＨＣＰ関連情報の効果的な送信
・ＥＡＰ形式の拡張に基づくＤＨＣＰ認証及び認可サポートについて合理化されたソリューション、これは、後方互換性の問題を最小限にして管理可能であり、かつ的確である
・共通の処理で、認証及び認可の最適化
・訪問先ネットワークに制限されないＤＨＣＰサーバ位置
・ＤＨＣＰサーバをホームネットワーク内に配置することができる
・同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６とＭＩＰｖ６認証及び認可の同時実行
本発明によって提供される他の効果は、本発明の実施形態の以下の説明を読むことによって理解されるであろう。
【００３３】
本発明の実施形態の詳細説明
図面全体を通して、同一の参照文字は、対応する要素あるいはそれに類する要素に対して使用している。
【００３４】
基本的な概念は、ＡＡＡインフラストラクチャを使用して、ＤＨＣＰサービスに対するＤＨＣＰクライアントに適切なＤＨＣＰサーバを割り当てることであり、また、その割り当てられたＤＨＣＰサーバを用いてＤＨＣＰサービスに対するＤＨＣＰクライアントを認証し、かつ認可するためのＡＡＡインフラストラクチャを介してＤＨＣＰ関連情報を送信することである。
【００３５】
従来より知られている、かなりより複雑なＤＨＣＰサーバディスカバリープロセスに代えて、ＡＡＡインストラクチャ、より詳しくは適切なＡＡＡサーバあるいはそれと等価のＡＡＡコンポーネントが、適切なＤＨＣＰサーバをＤＨＣＰクライアントに対して割り当てるために使用される。その結果、ＤＨＣＰディスカバリー関連メッセージにおける依存性はもはや必須ではない。
【００３６】
例えば、ＤＨＣＰクライアントをモバイルホストとすることができ、また、本発明は、ローミングするホストに対するサポートさえも提供する。モバイルホストが訪問先ネットワーク内でローミングしている場合、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、クライアントに適切なＤＨＣＰサーバを割り当てることを担当することが好ましい。ＤＨＣＰサーバ割当は、例えば、訪問先ネットワークオペレータによって決定されるいくつかのポリシーに基づいても良い。ＤＨＣＰサーバの選択は、例えば、利用可能なＤＨＣＰサーバ群の現在の負荷、モバイルホストの位置、モバイルホストによって与えられるプリファレンスの少なくともいずれかに基づくことができる。
【００３７】
しかしながら、ホームネットワークあるいは他のネットワークに配置されるＤＨＣＰサーバを持つことが有益な場合も存在する。これは、例えば、訪問先ネットワークがＤＨＣＰサーバサポートを提供しない場合である。このような場合は、ＤＨＣＰサーバ割当用の適切なＡＡＡインフラストラクチャとして、いわゆる、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）を使用することが適切であるからである。
【００３８】
事実、本発明を用いると、ＤＨＣＰサーバの位置を、ホームネットワーク、訪問先ネットワーク、あるいは他のネットワーク内さえにもすることができる。
【００３９】
ＡＡＡ  ＤＨＣＰのブートストラップは、通常、セキュリティアソシエーションの確立、即ち、ＡＡＡインフラストラクチャを介する、割当られたＤＨＣＰサーバと認証されたＤＨＣＰクライアント（例えば、モバイルホスト）間のセキュリティ関係に基づいていて、これにより、クライアントのＤＨＣＰコンフィグレーション用に、そのＤＨＣＰサーバとクライアント間の通信を安全（セキュア）にする。ＤＨＣＰセキュリティアソシエーション情報とＤＨＣＰサーバ割当情報は、ＤＨＣＰコンフィグレーションサービスに対するＤＨＣＰクライアントを認可するためのＡＡＡインフラストラクチャを介してＤＨＣＰクライアントへ送信される。本発明は、適切なＤＨＣＰサーバの割当を容易にすること、及びＤＨＣＰ認証拡張（ＲＦＣ３１１８）のブートストラップを容易にするＤＨＣＰ関連情報を搬送することによってＤＨＣＰクライアントとサーバに対して帯域外キーアグリーメントプロトコルを提供することの少なくとも一方を行うために、ＡＡＡプロトコルサポートを提供することが好ましい。
【００４０】
以下の実施形態では、ＤＣＨＰクライアントは、基本的には、モバイルホストあるいはモバイルノードによって示される。しかしながら、本発明はこれに限定されないことが理解されるべきである。
【００４１】
図２は、クライアントホストに対してＤＨＣＰサービスをサポートする方法の例を示すフロー図である。ステップＳ１では、モバイルＤＨＣＰクライアントホストは、典型的には、ＡＡＡインフラストラクチャを介するチャレンジ−応答（challenge-response）処理に基づいて、そのモバイルホストのホームネットワーク内のＡＡＡサーバのような適切なネットワークコンポーネントによって認証される。ステップＳ２Ａで示されるように、ＤＨＣＰクライアントは、ＤＨＣＰサーバ割当をリクエストすることができる。このリクエストは、必要とされるラウンドトリップ回数を削減するために、認証応答とともに、ＡＡＡインフラストラクチャを介して送信されることが好ましい。実際には、このことは、クライアントが最終的に認証される前に、クライアントで開始されるＤＨＣＰリクエストが実行されても良いことを意味する。別のクライアントで開始されるＤＨＣＰサーバ割当としては、ＤＨＣＰサーバの割当は、ステップＳ２Ｂで示されるように、ネットワークによって開始されても良い。ステップＳ３では、ＡＡＡインフラストラクチャは、適切なＤＨＣＰサーバを、リクエストしているクライアントホストへ割り当てるために使用される。このＡＡＡインフラストラクチャは、ＤＨＣＰセキュリティアソシエーション情報を生成するためにも使用されることが好ましい。ステップＳ４では、ＡＡＡインフラストラクチャを介して、割り当てられたＤＨＣＰサーバにおける情報を含むＤＨＣＰ認可情報とＤＨＣＰセキュリティアソシエーション情報をＤＨＣＰクライアントへ送信することによって、ＤＨＣＰサービスに対して、ＤＨＣＰクライアントが認可される。これは、ＤＨＣＰクライアントが、割り当てられたＤＨＣＰサーバからネットワークアドレス（例えば、ＩＰアドレス）と他のオプションのＤＨＣＰコンフィグレーションパラメータを安全に受信することに備えることを意味するものである。
【００４２】
用語「ＡＡＡ」は、インターネットドラフト（草稿）、ＲＦＣ及び他の標準化文献におけるそれ自身の汎用的な意味の範囲とされるべきである。典型的には、ＡＡＡ（認証、認可、アカウンティング）インフラストラクチャの認証及びセキュリティキーアグリーメントは、ＤＨＣＰクライアント（例えば、モバイルホスト）と、そのクライアントのホームネットワークオペレータあるいは信用機関との間で共有されるイニシャルシークレット（initial secret：初期秘密鍵）の存在を示唆する、対称暗号方法に基づいている。いくつかの状況及びアプリケーションでは、例えば、ＡＡＡインフラストラクチャのアカウンティング特性は、無効にされても良く、あるいは実現されなくても良い。統合ＡＡＡインフラストラクチャは、一般的には、ホームネットワーク、中間ネットワーク（存在する場合）及び訪問先ネットワークの少なくともいずれかに、１つ以上のＡＡＡサーバを含んでいて、また、１つ以上のＡＡＡクライアントを含んでいても良い。
【００４３】
一般的には、ＤｉａｍｅｔｅｒプロトコルのようなＡＡＡプロトコルは、モバイルユーザに、ネットワーク内を移動して、ネットワーク内のサービスを取得することを正確に可能にする。ここで、このネットワークは、モバイルユーザ自身のホームサービスプロバイダによって所有されている必要はない。商用ネットワークで展開されるモバイルＩＰに対しては、このプロトコルに対するＡＡＡサポートを持っているべきである。特殊な場合として、モバイルＩＰｖ６（ＭＩＰｖ６）に対しては、ホームオペレータによって管理されるネットワーク以外のネットワークでのＭＩＰｖ６ローミングを可能にするＤｉａｍｅｔｅｒへの新規のアプリケーションを説明するインターネットドラフト［５］が提案されている。２００３年６月１８日に出願された本出願人の米国仮特許出願６０／４７９，１５６と、後述するインターネットドラフト［６］では、ＡＡＡインフラストラクチャに基づいてモバイルＩＰｖ６認可及びコンフィグレーションを実行するためのアーキテクチャ及び関連プロトコルが示唆されている。ホームプロバイダのＡＡＡサーバと、ＭＩＰｖ６用のモバイルホスト間で必要な対話は、ＥＡＰ（Extensible Authentication Protocol：拡張可能認証プロトコル）を使用して実現され、これは、認証データとともにモバイルＩＰｖ６ネゴシエーション用の情報を搬送する。
【００４４】
図３は本発明の実施形態に従うＤＨＣＰサポート用の新規のアーキテクチャを示す図である。モバイルホスト１３０（モバイルノードＭＮとも参照する）の形式でのＤＨＣＰクライアントは訪問先ネットワークでローミングしていて、また、ＤＨＣＰ認証及び認可は、訪問先ネットワークとモバイルホストのホームネットワークとをリンクしているＡＡＡインフラストラクチャを使用することによって実行される。この例では、ＡＡＡインフラストラクチャは、基本的には、ＡＡＡホームネットワークサーバ１１０、ＡＡＡ訪問先ネットワークサーバ１２０及び訪問先ネットワーク内のＡＡＡクライアント１２２を含んでいる。
【００４５】
好ましくは、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）１２０は、適切なＤＨＣＰサーバの割当用の適切なＡＡＡインフラストラクチャコンポーネントして使用され、これは、ＤＨＣＰサーバの選択においては、訪問先オペレータのポリシーを考慮する。
【００４６】
ＡＡＡインフラストラクチャのメインコンポーネントはＡＡＡサーバ１１０であり、これは、好ましくは、ＤＨＣＰサーバ割当用のリクエストをモバイルＤＨＣＰクライアントからＡＡＡｖサーバ１２０へ転送し、また、所与のモバイルＤＨＣＰクライアントホスト１３０と割り当てられたＤＨＣＰサーバ１２５間の即時あるいは将来のセキュリティアソシエーション用のセキュリティキーあるいは同様の信用証明を生成する。このセキュリティキーは、典型的には、ＡＡＡｖ１２０を介してＡＡＡｈ１００からＤＨＣＰサーバ１２５へ転送され、また、ＤＨＣＰサーバ１２５は、好ましくは、ＡＡＡｖ１２０を介してＡＡＡｈ１００とのＤＨＣＰセキュリティアソシエーションを成立させるための情報で応答する。そして、ＡＡＡｈサーバ１１０は、ＤＨＣＰサーバアドレスを含む、生成されかつ収集されたＤＨＣＰ認可情報とＤＨＣＰ  ＳＡ情報をＡＡＡインフラストラクチャを介してモバイルホスト１３０へ送信する。ここで、ＡＡＡインフラストラクチャのセキュアトンネルあるいは、暗号化及びソース完全性保護のような他のセキュリティ対策は、セキュリティキー（群）のような機密情報の転送用に採用される。
【００４７】
ＡＡＡインフラストラクチャにおける信頼性は、ＤＨＣＰ認証及び認可サポートをブートストラップするための様々な可能性を提案する。例えば、図３に示されるように、新規に拡張された認証プロトコルを提供すること、ＡＡＡインフラストラクチャを介して搬送される既存の認証プロトコルへの拡張を提供すること、及びＤＨＣＰ認可情報を含むＤＨＣＰ関連情報を搬送するためにＡＡＡフレームワークプロトコルアプリケーションを拡張することの少なくともいずれかを行うことを可能にする。好ましくは、必要とされる認証及び認可情報は、同一のラウンドトリップで同時に送信される。
【００４８】
ＤＨＣＰクライアントが訪問先ネットワークでローミングするモバイルホストである場合、例えば、ＤＨＣＰ関連認証及び認可情報は、訪問先ドメインに対してトランスペアレントなエンドツーエンド処理で、認証プロトコル内のモバイルホストとＡＡＡホームネットワークサーバ間を送信されても良い。これは、訪問先ネットワークのＡＡＡノードに単なるパススルーエージェントとして動作することを可能にする。これは、重要な利点である。
【００４９】
好ましくは、ＤＨＣＰ用に適合されている拡張ＥＡＰ（拡張可能認証プロトコル）のような拡張認証プロトコルは、ＡＡＡｈサーバと、ＡＡＡｖサーバを介する訪問先ネットワークＤＨＣＰサーバ間のインタフェース用に、ＤＨＣＰ  ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような拡張ＡＡＡフレームワークプロトコルアプリケーションとともに利用される。
【００５０】
例えば、拡張認証プロトコルは、ＰＡＮＡ（ネットワークアクセス認証搬送用プロトコル）、ＰＰＰ（ポイント−ツー−ポイント（point-to-point）プロトコル）、ＩＥＥＥ８０２．１Ｘ、あるいはＧＰＲＳ／ＵＭＴＳのインタフェースによって、モバイルホストと訪問先ネットワークのＡＡＡクライアント間で搬送されても良く、また、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいは同様のＡＡＡフレームワーク、あるいは搬送プロトコルによって搬送されても良い。
【００５１】
選択的には、新規のあるいは拡張ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような、拡張ＡＡＡフレームワークプロトコルアプリケーションが、任意のＥＡＰあるいはＥＡＰ形式の拡張のサポートなしに使用される。モバイルホストとＡＡＡクライアント間の経路に対しては、ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションは、例えば、ＩＣＭＰ（インターネット制御メッセージプロトコル）によって搬送することができる。
【００５２】
ＭＩＰｖ６用に、ＭＮ１３０は、オプションのホームエージェント（ＨＡ）１５０に関連付けられていても良い。また、ＨＭＩＰｖ６用に、ＭＮ１３０は、オプションのモビリティアンカーポイント（不図示）に関連付けられていても良い。
【００５３】
ホームネットワークあるいは他のネットワーク内に配置されているＤＨＣＰサーバを持つことが有益な場合も存在することが認識される。これは、例えば、訪問先ネットワークがＤＨＣＰサーバのサポートを提供しない場合である。ホームネットワーク内に配置されている割り当てられたＤＨＣＰサーバを用いてＤＨＣＰをサポートするためのアーキテクチャの例を、図４に示す。
【００５４】
ＤＨＣＰサーバ割当用のＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０を使用することは有益である。好ましくは、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０は、モバイルホストと割り当てられたＤＨＣＰサーバ１２５間のセキュリティアソシエーション用のセキュリティキー、あるいは同様のセキュリティパラメータあるいは信用証明書を生成し、また、そのセキュリティキーをＤＨＣＰサーバ１２５を送信する。ＤＨＣＰサーバ１２５は、セキュリティアソシエーションを成立させるための情報でＡＡＡｈ１１０に応答し、ＡＡＡｈ１１０は、次に、ＤＨＣＰサーバアドレスを含むＤＨＣＰ認可情報とＤＨＣＰ  ＳＡ情報を、ＡＡＡインフラストラクチャを介してモバイルホスト１３０へ送信する。
【００５５】
ＤＨＣＰサーバ１２５はホームネットワークに配置されていて、また、ＤＨＣＰ用に適合されている拡張ＥＡＰ（拡張可能認証プロトコル）のような拡張認証プロトコルが採用される場合、ＡＡＡｖ１２０はＤＨＣＰトランザクションを監視する必要はなく、また、（ＭＮとＡＡＡｈ間だけでない）ＤＨＣＰ認証及び認可用の完全な「エンドツーエンド処理」を持つことが可能である。
【００５６】
選択的には、ＤＨＣＰ  ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような拡張フレームワークプロトコルアプリケーションを利用することができる。
【００５７】
理解されるべきことは、本発明は、ＤＨＣＰサーバ１２５が訪問先ネットワーク内に配置されていなければならないという従来技術の制約を解消していることである。ここで、ＤＨＣＰサーバの位置は、ホームネットワーク、訪問先ネットワークあるいは他のネットワークでさえにも配置することができる。
【００５８】
ＤＨＣＰサーバの再割当は、以下の例の場合の間に発生する可能性がある。
【００５９】
・ＤＨＣＰクライアント（ＭＮ）とＤＨＣＰサーバ間のセキュリティキーの満了、この場合に対しては、ＭＮは、ＤＨＣＰ再認証／認可を開始しても良く、また、ネットワークは、例えば、ＭＮの現在のトポロジー的な位置に基づいてより適切となる異なるＤＨＣＰを割り当てても良い。
【００６０】
・モバイルＤＨＣＰクライアントのリクエスト（ＭＮからの開始）で、この場合に対しては、ＭＮはＤＣＨＰサーバの再割当をリクエストするＤＨＣＰ再認証／認可を開始する。
【００６１】
・ネットワーク（ネットワークからの開始）のリクエストで、この場合に対しては、ＡＡＡｈあるいはＡＡＡｖは、ＤＨＣＰサーバの再割当を開始することができ、また、必要が発生する場合、例えば、ＭＮは、新規のＤＨＣＰサーバによってより良好にカバーされるアクセスルータ（ＡＲ）へＭＮが移動する場合に、これをＭＮへ「プッシュ」する。
【００６２】
図３及び図４を再度参照すると、セグメントＡＡＡクライアント−ＡＡＡｈ、ＡＡＡｈ−（ＡＡＡｖ）−ＤＨＣＰサーバ間の異なるプロトコルの取り得る組み合わせの例を以下にまとめる。
【００６３】
【表１】
2007534267.tif 000003
【００６４】
組み合わせ（ｉｉｉ）は、特に、ＤＨＣＰサーバがホームネットワークに配置されている場合に適用可能である。ＤＨＣＰサーバが訪問先ネットワークに配置されている場合、ＡＡＡｖは、訪問先ネットワークポリシーに基づいて、ＤＨＣＰサーバの選択に関与しても良い。
【００６５】
ＥＡＰのような拡張認証プロトコルに対しては、ＤＨＣＰ関連認証及び認可情報は、同一のＥＡＰラウンドトリップで同時に送信されることが好ましい。
【００６６】
別の状況では、図５に示されるように、モバイルＤＨＣＰクライアント１３０は実際にホームネットワークに配置されていて、また、ＡＡＡｈサーバ１１０のようなホームネットワークのＡＡＡインフラストラクチャコンポーネントは、ホームネットワーク内のＤＨＣＰサーバ１２５でのＤＨＣＰサービスに対して必要なサポートを提供する。これは、拡張認証ＤＨＣＰプロトコル及びＡＡＡ  ＤＨＣＰアプリケーションの少なくとも一方の関連部分のみが、必要な認証及び認可情報の交換に対して使用されなければならないことを意味する。
【００６７】
図６は、本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。この例では、ＡＡＡｈサーバ１１０は、基本的には、オプションのＤＨＣＰサーバ割当モジュール１１１、ＤＨＣＰセキュリティアソシエーションモジュール１１２、ＤＨＣＰ認可情報マネージャ１１３及び入力−出力（Ｉ／Ｏ）インタフェース１１４を備えている。ホームネットワーク内に存在する場合のＤＨＣＰサーバに対しては、ＡＡＡｈサーバ１１０は、ＤＨＣＰサーバ割当モジュール１１１を含み、これは、モバイルホストへの適切なＤＨＣＰサーバの割当及び再割当の少なくとも一方を行うために動作可能である。訪問先ネットワークに存在する場合のＤＨＣＰサーバに対しては、ＡＡＡｈサーバ１１０は、典型的には、自身のＩ／Ｏインタフェース１１４で、ＡＡＡｖから必要なＤＨＣＰサーバ割当情報を受信する。ＡＡＡｈサーバは、典型的には、モバイルホストからキーシード（key seed：キーの種）あるいはナンス（nonce）も受信する。選択的には、ＡＡＡｈサーバは、キーシード自身を生成し、それをモバイルホストへ送信する。ＤＨＣＰセキュリティアソシエーションモジュール１１２は、そのキーシードに応じて、必要なセキュリティキーを生成することが好ましく、また、このセキュリティキーを安全にしてＤＨＣＰサーバへ送信する（ホームネットワーク内のＤＨＣＰサーバに直接送信する、あるいはＡＡＡｖサーバを介して訪問先ネットワーク内のＤＨＣＰサーバに送信する）。ＡＡＡｖサーバ１１０は、認可情報情報マネージャ１１３に関連する認可情報を記憶する。ＡＡＡｈサーバは、ＤＨＣＰセキュリティアソシエーションを成立させるために、ＩＰＳｅｃ情報のような情報を、ＤＨＣＰサーバから受信することもできる。そして、収集されたＤＨＣＰ認可情報は、ＡＡＡインフラストラクチャを介してモバイルホストへ送信される。
【００６８】
ＡＡＡｈサーバは、ホームアドレス割当及びホームエージェント（ＨＡ）割当の少なくとも一方を担当しても良い（ホームアドレスがＭＮ自身によって構成されてない限り）。
【００６９】
本発明をより理解するために、ＤＨＣＰ用の拡張認証プロトコル及びＤＨＣＰ用に適合されているＡＡＡフレームワークプロトコルアプリケーションの詳細例を説明する。
【００７０】
ＤＨＣＰ用の拡張認証プロトコル
本実施形態では、ＤＨＣＰ用の拡張認証プロトコル、本明細書では、新規のあるいは拡張ＥＡＰ認証プロトコルによって例示される（「ＤＨＣＰ認証方法」あるいは「ＥＡＰ／ＤＨＣＰ」と称する）プロトコルでは、例えば、ＤＨＣＰ認証拡張（ＲＦＣ３１１８）、即ち、ＤＨＣＰ  ＳＡリクエスト、キー生成ナンス、キーＩＤ及びその類をブートストラップすることを容易にするＤＨＣＰ関連情報を搬送することが定義されている。ＥＡＰ／ＤＨＣＰは、必要なＤＨＣＰサーバＩＰアドレスをＤＨＣＰクライアントへトランスポートすることによって、ホームネットアwークあるいは訪問先ネットワークの一方に配置することができる適切なＤＨＣＰサーバの割当を容易にすることもできる。
【００７１】
ＥＡＰあるいはＥＡＰのようなプロトコルを使用することで、ＡＡＡクライアント（及び訪問先ネットワークのＡＡＡｖ及び他のネットワークコンポーネント）に、ＲＦＣ３１１８処理を不可知にすることを可能にし（即ち、これは、訪問先ネットワークのＲＦＣ３１１８サポートについての依存性をなくす）、また、単なるパススルーエージェント（群）として動作することを可能にする。このことは、ＥＡＰのようなトランスペアレントなエンドツーエンドプロトコルの使用についての主要な利点の１つである。
【００７２】
上述したように、ＥＡＰ／ＤＨＣＰは、例えば、ＰＡＮＡ、ＰＰＰ、ＩＣＭＰ、ＩＥＥＥ８０２．１Ｘ、あるいはＧＰＲＳ／ＵＭＴＳのインタフェースによって、モバイルホスト（ＭＮ）と訪問先ネットワークのＡＡＡクライアント間で搬送されても良い。但し、ＰＡＮＡは、いくつかの場合には、他の搬送プロトコルであっても良い。この他の搬送プロトコルとは、ＭＮとＡＡＡクライアント間でＥＡＰ／ＤＨＣＰを搬送するために使用することができるＰＰＰ［７］及びＩＥＥＥ８０２．１Ｘ［８］のような、下位レイヤ順序付け保証におけるＥＡＰ要件を満足するものである。特に、３ＧＰＰ２  ＣＤＭＡ２０００の場合に対しては、プロトコルフィールド値にＥＡＰ［７］用にＣ２２７（１６進数）が設定されているＰＰＰデータリンクレイヤプロトコルカプセル化を使用して、ＭＮとＡＡＡクライアント間をＥＡＰ／ＤＨＣＰを搬送することができる。
【００７３】
本実施形態は、ＡＡＡクライアントとＡＡＡｈサーバ間の下位レイヤ通信に対しては、Ｄｉａｍｅｔｅｒ、Ｒａｄｉｕｓあるいは同様のＡＡＡフレームワークあるいは搬送プロトコルを使用する。例えば、ＡＡＡクライアント向け及びＡＡＡインフラストラクチャ内を越えて、Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーション［９］を、Ｄｉａｍｅｔｅｒ内、即ち、ＰＡＡ／ＡＡＡクライアントとＡＡＡｈ間でのＥＡＰ／ＤＨＣＰのカプセル化を行うために使用することができる。Ｄｉａｍｅｔｅｒプロトコルは、ＰＡＮＡセキュリティ用のセキュリティキーのＰＡＡ／ＡＡＡクライアントへの配信、及びオプションのＱｏＳパラメータのシグナリング（信号送受信）のために、ＡＡＡｈで使用されても良い。
【００７４】
Ｄｉａｍｅｔｅｒが好ましい選択であるとしても、時には、当業者の自明な範囲で、Ｒａｄｉｕｓのような別のＡＡＡプロトコルを使用することが適切な場合もあることに注意すべきである。
【００７５】
ＥＡＰ／ＤＨＣＰプロトコルの詳細例
以下では、ＥＡＰ／ＤＨＣＰプロトコルの詳細例を、概念の全体フローと実行可能性の例を示すために提供する。
【００７６】
ＥＡＰ  ＴＬＶ属性
第１の実現例では、新規のＥＡＰタイプ長値（ＴＬＶ）あるいは同様の属性のセットが定義されることが好ましく、これは、ＤＨＣＰ認証拡張（ＲＦＣ３１１９）のブートストラップを容易にする情報、即ち、ＤＨＣＰ  ＳＡリクエスト、キー生成ナンス、キーＩＤ等を搬送し、また、適切なＤＨＣＰサーバの割当（ＤＨＣＰサーバＩＰアドレス）を容易にする情報を搬送する。
【００７７】
別の認証スキームを、ＥＡＰ／ＤＨＣＰに対して利用することも可能である。本実施形態では、本発明は、ＭＤ−５チャレンジ認証を介する実装を提案しているが、他のスキームも本発明の範囲に含まれる。
【００７８】
１つ以上の以下に例示するＥＡＰ−ＴＬＶ属性を、ＤＨＣＰ目的用に定義することもできる。
【００７９】
・DHCP Server Address Request EAP-TLV属性：
これは、認証が成功した場合に、ＭＮに対し動的に割り当てられるＤＨＣＰサーバのアドレス用のリクエストを示している。これは、認証され、与えられるＤＨＣＰサービスをＭＮがリクエストする場合に、ＭＮによってＡＡＡｈへ典型的にはリクエストされる。
【００８０】
ＤＨＣＰサーバ割当リクエストは、選択的には、他のＤＨＣＰリクエストに潜在していても良い。
【００８１】
・DHCP Server Address Response EAP-TLV属性：
これは、認証されたＭＮに対し、動的に割り当てられるＤＨＣＰサーバのアドレスを示している。これは、ＭＮが認証され、かつＤＨＣＰサーバが動的に割り当てられている場合に、ＡＡＡｈからＭＮへ通知される。
【００８２】
・DHCP Server-MN (Pre-shared) Key Generation Nonce EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間の事前共有キーを生成するためのシードとする、ＭＮによってランダムに生成されるオクテットストリングを示している。ＭＮは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＤＨＣＰサーバ−ＭＮ（事前共有）キーを生成することができる。この属性は、有効なＤＨＣＰサーバ−ＭＮ（事前共有）キーが既に存在している場合のオプションである。
【００８３】
・DHCP Server-MN (Pre-shared Key) EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間で動的に生成される（事前共有）キーを示している。これは、典型的には、ＡＡＡｈからＤＨＣＰサーバへ通知される。ＡＡＡｈは、DHCP Server-MN (Pre-shared) Key Generation Nonce EAP-TLV属性によって与えられるナンスと、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＤＨＣＰサーバ−ＭＮ（事前共有）キーを生成することができる。この属性は、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合のオプションである。
【００８４】
・DHCP Server IKE  KeyID EAP-TLV属性：
これは、［１０］で定義されるＩＤペイロードを示している。ＫｅｙＩＤは、ＡＡＡｈによって生成され、そして、認証が成功しているＭＮに送信される。ＫｅｙＩＤは、いくつかのオクテットを含み、これは、どのようにしてＡＡＡｈから、ＤＨＣＰサーバ−ＭＮ事前共有キーを検索（あるいは生成）するかについてを、ＤＨＣＰサーバへ通知する。この属性は、オプションであり、かつ、ＭＮがＤＨＣＰサーバ−ＭＮ事前共有キー生成ナンス（DHCP Server-MN pre-shared key generation nonce）を提示しない場合、即ち、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、ＤＨＣＰサーバ−ＭＮ事前共有キーがＡＡＡｈによってＤＨＣＰサーバに搬送される場合にも必要とされない。
【００８５】
・DHCP Server-MN  IPSec SPI EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間のＩＰＳｅｃに対するセキュリティパラメータインデックス（Security Parameter Index）を示している。これは、ＤＨＣＰサーバによって生成され、かつ、ＤＨＣＰサーバ−ＭＮ事前共有キーがＡＡＡｈによってＤＨＣＰサーバに搬送される場合にＭＮに通知されることが好ましい。この属性は、オプションであり、かつ、ＭＮがＤＨＣＰサーバ−ＭＮ事前共有キー生成ナンス（DHCP Server-MN pre-shared key generation nonce）を提示しない場合、即ち、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００８６】
・DHCP Server-MN IPSec Protocol EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間のＩＰＳｅｃプロトコル（例えば、ＥＳＰあるいはＡＨ）を示している。これは、ＤＨＣＰサーバ−ＭＮ（事前共有）キーがＡＡＡｈによってＤＨＣＰサーバに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＤＨＣＰサーバ−ＭＮ事前共有キー生成ナンス（DHCP Server-MN pre-shared key generation nonce）を提示しない場合、即ち、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００８７】
・DHCP Server-MN IPSec Crypto EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間のＩＰＳｅｃに対する暗号アルゴリズムを示している。これは、ＤＨＣＰサーバ−ＭＮ（事前共有）キーがＡＡＡｈによってＤＨＣＰサーバに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＤＨＣＰサーバ−ＭＮ事前共有キー生成ナンス（DHCP Server pre-shared key generation nonce）を提示しない場合、即ち、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００８８】
・DHCP Server-MN IPSec Key Lifetime EAP-TLV属性：
これは、ＤＨＣＰサーバとＭＮ間のＩＰＳｅｃに対するキー期限を示している。これは、ＤＨＣＰサーバ−ＭＮ（事前共有）キーがＡＡＡｈによってＤＨＣＰサーバに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＤＨＣＰサーバ−ＭＮ事前共有キー生成ナンス（DHCP Server-MN pre-shared key generation nonce）を提示しない場合、即ち、有効なＤＨＣＰサーバ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。
【００８９】
以下のＥＡＰ−ＴＬＶ属性は、モバイルＤＨＣＰクライアント（ＭＮ）の認証に対して定義されても良い。
【００９０】
・MD5 Challenge EAP-TLV属性：
これは、ＡＡＡｈによってランダムに生成され、かつＭＤ５チャレンジ（Challenge）に対するＭＮへ送信されるオクテットストリングを示している。
【００９１】
・MD5 Response EAP-TLV属性：
これは、ＡＡＡｈとＭＮ間の共有シークレットキーを用いるＭＤ５ハッシュ関数の結果として生成されるオクテットストリングを示している。
【００９２】
最後に、以下のオプションのＥＡＰ−ＴＬＶ属性は、ＰＡＮＡセキュリティに対するＰＡＣとＰＡＡ間でのセキュリティキーの配信に対して定義されても良い。
【００９３】
・PAC-PAA Pre-shared Key Generation Nonce EAP-TLV属性：
これは、ＰＡＣ−ＰＡＡ間の事前共有キーを生成するためのシードとする、ＭＮ／ＰＡＣによってランダムに生成されるオクテットストリングを示している。ＭＮ／ＰＡＣは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＰＡＣ−ＰＡＡ事前共有キーを生成することができる。この属性は、ＰＡＮＡセキュリティに対して必要とされる。
【００９４】
選択的には、ＡＡＡｈサーバは、ＭＮ−ＤＨＣＰサーバセキュリティキーを生成するだけでなく、ＤＨＣＰセキュリティアソシエーションを成立させるために必要とされる情報を生成するように構成されても良い。
【００９５】
セッションセットアップ時間遅延を短縮するためにＤＨＣＰとＨＭＩＰｖ６／ＭＩＰｖ６との両方の認証及び認可を同時に実行したい場合には、いくつかのＥＡＰ方法から関連するＴＬＶ群を単に組み合わせることによって、例えば、ＥＡＰ／ＤＨＣＰと、いわゆるＥＡＰ／ＨＭＩＰｖ６及びＥＡＰ／ＭＩＰｖ６の少なくとも一方とを、単一のＥＡＰセッション（即ち、ＥＡＰ／ＤＨＣＰ＋ＨＭＩＰｖ６／ＭＩＰｖ６）にマージすることも可能となる。ＥＡＰ／ＨＭＩＰｖ６は、ＥＡＰ認証プロトコルである。これは、ＭＡＰ（モビリティアンカーポイント）の探索、ＤＨＣＰサーバの動的割当、ＲＣｏＡの動的割当、ＭＮとＭＡＰ間のセキュリティキーの配信及びＨＭＩＰｖ６モビリティ処理の取り得るピギーバック（piggyback）の少なくともいずれかを容易にするＨＭＩｐｖ６関連情報を搬送する。Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーションのような適切なＥＡＰキャリヤは、ＡＡＡインフラストラクチャ内にＥＡＰ／ＤＨＣＰをトランスポートすることができる。これに対して、ＥＡＰ／ＭＩＰｖ６はＥＡＰ認証プロトコルであり、これは、ＭＩＰｖ６認証及び認可情報を含むＭＩＰｖ６関連情報を搬送する。
【００９６】
文献［１５］は、ＥＡＰ認証フェーズを記載していて、これは、ＥＡＰピア（例えば、モバイルクライアント）からセッションパラメータに対する認証をリクエストすることをＥＡＰサーバに可能にするために、ＥＡＰフレームワーク内のＥＡＰ認証フェーズの後につながれる。［１５］で示唆されるアプローチは、ＤＨＣＰ、ＭＩＰｖ６及びＨＭＩＰｖ６の少なくともいずれかに対して想定されている状況とは完全に逆である。これは、ＥＡＰサーバは、ＥＡＰピア（同位）からの認証を問い合わせるものの１つであるからである。ピア側からのＥＡＰサーバの認証は、例えば、サービスに対する課金を行うために、ネットワーク側がユーザによる認証（ユーザの承認）を必要とする場合の課金目的用に使用することができる。これに対して、ＤＨＣＰ、ＭＩＰｖ６及びＨＭＩＰｖ６では、クライアントは、ＤＨＣＰ、ＭＩＰｖ６及びＨＭＩＰｖ６サービスの少なくともいずれかを使用することを可能にするための認証をネットワーク側へ要求する。
【００９７】
EAP Generic Container Attribute(EAP GCA)（ＥＡＰ汎用コンテナ属性）
別のＥＡＰの実現では、ＥＡＰは、新規のいわゆるＥＡＰメソッド（EAP method）を生成することなく、ＤＨＣＰ関連情報（オプションとしては、ＨＭＩＰｖ６／ＭＩＰｖ６情報）のキャリヤとして使用される。これは、ＥＡＰメソッドとともに使用することができる汎用コンテナＥＡＰ属性で情報を搬送することによるものではない。
【００９８】
この例の実現では、アクセスネットワークでＡＡＡサポートを構築する、ＥＡＰは、汎用コンテナ属性で増やされる（augmented）。この汎用コンテナ属性は、任意の（当然のことのように、非ＥＡＰ関連）データ、例えば、ＤＨＣＰ専用データと、オプションのＨＭＩＰｖ６／ＭＩＰｖ６専用データ（ＭＩＰｖ６のブートストラップも要求される場合）を搬送するために使用することができる。これは、ＭＮとＡＡＡｈに、アクセスネットワークを含む訪問先ドメインに対してトランスペアレントとなる方法で、ＡＡＡクライアントとＡＡＡｖと通信することを可能にする。ＥＡＰは、ＡＡＡプロトコルで、ＡＡＡクライアントとＡＡＡｈ間で搬送されることが好ましい。このＡＡＡプロトコルは、例えば、Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーションあるいはＲａｄｉｕｓ［１１］、［１２］がある。
【００９９】
この新規の属性は、すべてのＥＡＰメソッドに対して利用可能であるとすべきことが好ましく、また、ＥＡＰ成功／失敗メッセージを含む任意のＥＡＰメッセージに含めることができる。このソリューションでは、新規の汎用コンテナ属性は、ＭＮとＡＡＡｈ間で、ＤＨＣＰ専用データを搬送するために使用される。このソリューションは、ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションを含んでいても良く、これらは、ＡＡＡｈとＨＡ間で、ＡＡＡとそれに関連するデータの交換のために使用される。
【０１００】
以下では、汎用コンテナ属性（ＧＣＡ）の実現可能な実装について、現存のＥＡＰプロトコル［１３］に関して説明する。上述のように、汎用コンテナ属性は、あらゆる方法で利用可能とすべきことが好ましく、また、ＥＡＰ成功／失敗メッセージを含む任意のＥＡＰメッセージに含めることを可能とすべきである。これは、ＥＡＰメソッドレイヤ［１３］ではなく、ＥＡＰレイヤの一部とすべきであることを意味する。考慮するための重要な問題は、後方互換性1である。与えられる例でのＧＣＡの使用は、新規の属性が後方互換性のある方法でＥＡＰに導入され、かつＥＡＰ認証器に対してトランスペアレントであると想定する。これらの特性を伴うＧＣＡの導入は、以下に説明するように、いくつかの特別な配慮を必要とする場合がある。
【０１０１】
例えば、ＧＣＡのフォーマットは、ＧＣＡ受信インジケータとＧＣＡペイロードに続く２バイトのＧＣＡレングス（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）で、ＤＨＣＰとＨＭＩＰｖ６／ＭＩＰｖ６の両方の認証及び認可を同時に実行することが可能となる。特定の場合に特別に必要とするＭＮに依存して、ＨＭＩＰｖ６／ＭＩＰｖ６に対応するものなしで、ＤＨＣＰの認証及び認可だけを実行することが可能となり、その逆も可能である。これは、単一のアプリケーションである、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションに、様々な使用状況で使用される場合の柔軟性を与えることを可能にする。
【０１４０】
Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションの詳細
以下では、例として、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションの詳細を、概念の全体フロー及び実行可能性を例示するために提供する。好ましくは、新規のＤＨＣＰ−専用コマンドコード、ＡＶＰ（属性値ペア）、及びフラグが定義され、これは、ＤＨＣＰ認証拡張（ＲＦＣ３１１８）、即ち、ＤＨＣＰ  ＳＡリクエスト、キー生成ナンス、キーＩＤ等のブートストラップを容易にし、また／あるいは、適切なＤＨＣＰサーバ（ＤＨＣＰサーバのＩＰアドレス）の割当を容易にする情報を搬送する。
【０１４１】
更なる情報については、インターネットドラフト［９］で、ネットワークアクセスサーバ（ＮＡＳ）とバックエンド認証サーバ間でＥＡＰパケットを搬送するために必要なコマンドコードとＡＶＰを定義している。
【０１４２】
Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーション用のシグナリング（信号送受信）フロー例
図９は、ＤＨＣＰサーバがホームネットワークに配置されている場合に対する、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションシグナリング（信号送受信）フローの例を示している。
【０１４３】
ＡＡＡクライアントは、例えば、インターネット制御メッセージプロトコル（ＩＣＭＰ）、ＰＡＮＡ等のプロトコルを介して、認証対象のＭＮに対してチャレンジを発行する。ＭＮは、ＤＨＣＰサポートに対するリクエスト、キーナンス、また、おそらくは、ＨＭＩＰｖ６／ＭＩＰｖ６ブートストラップリクエストにも従って、チャンレンジ応答で応答する。
【０１４４】
ＡＡＡクライアントは、ＤＨＣＰサポートブートストラップリクエストを理解し、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードを使用して、ＡＡＡインフラストラクチャを介して、ＭＮ応答をＡＡＡｈへ送信する。この処理では、ＡＡＡクライアントも、ＡＡＡｈにＭＮの認証を検証することを可能にするチャレンジ応答を含んでいる。
【０１４５】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味するものである、そして、ＡＡＡｈはＭＮのリクエストの処理に進む。
【０１４６】
まず、ＡＡＡｈは、ホームネットワーク内のＤＨＣＰサーバを選択して、例えば、生成されたＤＨＣＰセキュリティキーを含む適切なＤｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードをＤＨＣＰサーバへ送信する。また、必要であればあるいはそうでなければ適切であれば、好ましくは、コマンドコードを介してＭＮとのＤＨＣＰセキュリティアソシエーションを成立させるための情報を提供することによって、ＤＨＣＰサーバはＡＡＡｈに応答する。
【０１４７】
第２に、ＨＭＩＰｖ６／ＭＩＰｖ６ブートストラップがリクエストされる場合に、ＡＡＡｈは、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードを使用するＭＡＰ／ＨＡを選択することによって、ＨＭＩＰｖ６／ＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。そして、ＭＡＰ／ＨＡは、コマンドコードを介してＭＮとのＨＭＩＰｖ６／ＭＩＰｖ６セキュリティアソシエーションを生成するために必要な情報を提供することによってＡＡＡｈに応答する。ここで、認証及び認可の交換時に、「ＭＡＰバインディング更新」と「ＨＡバインディング更新」とをピギーバックすることが可能であることに注意する。
【０１４８】
ＡＡＡｈが、上述のように、ＤＨＣＰサーバ及びＭＡＰ／ＨＡと通信した後、ＡＡＡｈは、認可情報及び認証成功指示に従うセキュリティアソシエーション情報を、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードと、例えば、ＩＣＭＰ、ＰＡＮＡ等を介してＭＮへ返信する。ここで、この認可情報には、例えば、ＤＨＣＰサーバアドレス、（ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス）がある。
【０１４９】
図１０は、ＤＨＣＰサーバが訪問先ネットワークに配置されている場合に対する、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションのシグナリング（信号送受信）フローの例を示している。
【０１５０】
ＡＡＡクライアントは、例えば、ＩＣＭＰあるいはＰＡＮＡを介して、認証対象のＭＮに対してチャレンジを発行する。ＭＮは、ＤＨＣＰサポートに対するリクエストに従って、また、おそらくは、ＨＭＩＰｖ６／ＭＩＰｖ６ブートストラップリクエストにも従って、チャンレンジ応答で応答する。
【０１５１】
ＡＡＡクライアントは、ＤＨＣＰブートストラップリクエストを理解し、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードを使用して、ＡＡＡインフラストラクチャを介して、ＭＮ応答をＡＡＡｈへ送信する。この処理では、ＡＡＡクライアントも、ＡＡＡｈにＭＮの認証を検証することを可能にするチャレンジ応答を含んでいる。
【０１５２】
ＡＡＡｈは、ＭＮのチャレンジ応答を有効にして、これが成功する場合、このことは、ＭＮが真正のものであることを意味するものである、そして、ＡＡＡｈはＭＮのクエストの処理に進む。
【０１５３】
第１に、ＡＡＡｈは、ＤＨＣＰクライアント−サーバキーを生成し、そのキーと訪問先ネットワーク内のＤＨＣＰサーバに対するリクエストを適切なＡＡＡｖへ送信する。これは、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードを介して実行される。ＡＡＡｖは、訪問先ネットワーク内の適切なＤＨＣＰサーバを選択して、例えば、ＤＨＣＰセキュリティキーを含むコマンドコードをＤＨＣＰサーバへ送信する。また、必要であればあるいはそうでなければ適切であれば、好ましくは、コマンドコードを使用するＭＮとのセキュリティアソシエーションを成立させるための情報を提供することによって、ＤＨＣＰサーバはＡＡＡｖを介してＡＡＡｈに応答する。
【０１５４】
第２に、必要である場合、ＡＡＡｈは、ＨＭＩＰｖ６／ＭＩＰｖ６ブートストラップリクエストを提供するために処理を進める。
【０１５５】
ＡＡＡｈが、上述のように、ＤＨＣＰサーバ（及びＭＡＰ／ＨＡ）と通信した後、ＡＡＡｈは、認可情報及び認証成功指示に従うセキュリティアソシエーション情報を、Ｄｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションコマンドコードと、ＩＣＭＰあるいはＰＡＮＡのようなプロトコルを介してＭＮへ返信する。ここで、この認可情報には、例えば、ＤＨＣＰサーバアドレス、（ＭＡＰアドレス、ＲＣｏＡ、ＨＡアドレス、ＭＮホームアドレス）がある。
【０１５６】
他の用途範囲に渡って、本発明は、あらゆるアクセスネットワークに適用することが可能である。これには、ＷＬＡＮ、ＣＤＭＡ２０００、ＷＣＤＭＡ等がある。また、ＤＨＣＰと、オプションとしてＨＭＩＰｖ６／ＭＩＰｖ６も使用することができ、これは、次のような技術を含んでいる。この技術には、ＡＡＡ、ＤＨＣＰとＩＰｖ６移動性（モビリティ）、ＣＭＳ１１、ＷＣＤＭＡ及びＧＳＭシステムのようなシステム群と、サービス／アプリケーションサブシステムのようサブシステム及び端末、ＡＡＡサーバ、ＤＨＣＰサーバ及び端末ノードのような製品がある。
【０１５７】
上述の実施形態は、単なる例として挙げられていて、本発明がそれに限定されるものではないことが理解されるべきである。本明細書で、開示され、かつ請求項で示される原理を根本とする基礎を維持する、更なる、変形、変更及び改良は、本発明の範囲にある。
【０１５８】
略語
ＤＨＣＰ      動的ホストコンフィグレーションプロトコル
ＥＡＰ        拡張可能認証プロトコル（Extensible Authentication Protocol）
ＮＡＳ        ネットワークアクセスサーバ
ＳＡ          セキュリティアソシエーション（Security Association）
ＡＡＡ        認証、認可及びアカウンティング（Authentication, Authorization and Accounting）
ＡＡＡｈ      ホームＡＡＡ
ＡＡＡｖ      訪問先ＡＡＡ（Visited AAA）
ＡＫＡ        認証キーアグリーメント（Authentication Key Agreement）
ＥＡＰ        拡張可能認証プロトコル（Extensible Authentication Protocol）
ＥＰ          実施点
ＨＡ          ホームエージェント
ＩＫＥ        インターネットキー交換（Internet Key Exchange）
ＩＰｓｅｃ    ＩＰ  セキュリティ
ＩＳＡＫＭＰ  インターネットセキュリティアソシエーション及びキー管理プロトコル
（Internet Security Association and Key Management Protocol）
ＭＤ５          メッセージダイジェスト５（Message Digest 5）
ＭＩＰｖ６      モバイルＩＰバージョン６
ＭＮ            モバイルノード
ＰＡＡ          ＰＡＮＡ認証エージェント
ＰＡＣ          ＰＡＮＡクライアント
ＰＡＮＡ        ネットワークアクセス認証搬送用プロトコル
ＳＰＩ          セキュリティパラメータインデックス
ＴＬＳ          トランスポートレイヤセキュリティ
ＴＬＶ          タイプレングス値（Type Length Value）
ＴＴＬＳ        トンネル化ＴＬＳ（Tunneled TLS）
ＷＬＡＮ        無線ローカルエリアネットワーク
参考文献
[１]動的ホストコンフィグレーションプロトコル、ＲＦＣ２１３１、アール．ドルムス、１９９７年３月（[1] Dynamic Host Configuration Protocol,RFC2131, R. Droms, March 1997）
［２］ＤＨＣＰメッセージ用認証、ＲＦＣ３１１８、アール．ドロムス、ダブリュー．アルバウ、２００１年６月（[2] Authentication for DHCP Messages, RFC3118, R. Droms, W. Arbaugh, June 2001）
［３］ＥＡＰベースのネットワークアクセス認証を使用する、ＲＦＣ３１１８による遅延ＤＨＣＰ認証のブートストラップ、エイ．イエイン、エイチ．シュフォニグ、ディー．フォルスベルグ、２００４年２月、＜draft-yegin-eap-boot-rfc3118-00.txt＞（[3] Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication, A. Yegin, H. Tschofenig, D. Forsberg, February 2004, ＜draft-yegin-eap-boot-rfc3118-00.txt＞）
［４］ＰＡＮＡを使用する、ＲＦＣ３１１８による遅延認証のブートストラップ、エイチ．シュフォニグ、エイ．イエイン、ディー．フォルスベルグ、２００３年８月、＜draft-tschofenig-pana-bootstrap- rfc3118-01.txt＞（[4] Bootstrapping RFC3118 Delayed authentication using PANA, H. Tschofenig, A. Yegin, D. Forsberg, October 2003, ＜draft-tschofenig-pana-bootstrap- rfc3118-01.txt＞）
［５］ＤｉａｍｅｔｅｒモバイルＩＰｖ６アプリケーション、ステファノ  エム．ファッチン、フランク  リー、バサバラジ  パチル、チャールズ  イー．ペルキンス、２００３年４月、＜draft-le-aaa-diameter-mobileipv6- 03.txt＞（[5] Diameter Mobile IPv6 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-00.txt＞（[6] MIPv6 Authorization and Configuration based on EAP, G. Giaretta, I. Guardini, E. Demaria, February 2004, ＜draft-giaretta-mip6-authorization-eap-00.txt＞）
［７］ＰＰＰ拡張可能認証プロトコル（ＥＡＰ）、ＲＦＣ２２８４、エル．ブルンク、ジェイ．ボルブレッヒト、１９９８年３月（PPP Extensible Authentication Protocol (EAP), RFC2284, L. Blunk, J. Vollbrecht, March 1998）
［８］ＩＥＥＥ  標準８０２．１Ｘ、ローカル及びメトロポリトンエリアネットワーク−ポートベースのネットワークアクセス制御（IEEE Standard802.1X, Local and metropolitan area networks - Port-Based Network Access Control）
［９］Ｄｉａｍｅｔｅｒ拡張可能認証プロトコル（ＥＡＰ）アプリケーション、ピー．エロネン、ティー．ヒラー、ジー．ゾルン、２００４年２月１６日、＜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＞）
［１０］インターネットセキュリティアソシエーション及びキー管理プロトコル（ＩＳＡＫＭＰ）、ＲＦＣ２４０８、ディー．マウグハン、エム．シェルター、エム．シュナイダー、ジェイ．ターナー、１９９８年１１月（Internet Security Association and Key Management Protocol (ISAKMP), RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998）
［１１］リモート認証ダイアルインユーザサービス（ＲＡＤＩＵＳ）−ＲＦＣ２８６５、シー．リグネイ、エス．ウィレンス、エイ．ルーベンス、ダブリュー．シンプソン、２０００年６月（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＞）
［１５］ＥＡＰ認証、エム．グレイソン、ジェイ．サロウェイ、２００３年３月＜draft-grayson-eap- authorization-0 1.txt＞（EAP Authorization, M. Grayson, J. Salowey, March 2003, ＜draft-grayson-eap- authorization-01.txt＞）
【図面の簡単な説明】
【０１５９】
【図１】従来のＤＨＣＰディスカバリープロセスを示す図である。
【図２】クライアントホストに対してＤＨＣＰサービスをサポートする方法の例のフロー図である。
【図３】本発明の実施形態に従う訪問先ネットワークでローミングするＤＨＣＰクライアントに対するＤＨＣＰ認証及び認可サポート用の新規のアーキテクチャを示す図である。
【図４】本発明の別の実施形態に従う訪問先ネットワークでローミングするＤＨＣＰクライアントに対するＤＨＣＰサポート用の新規のアーキテクチャを示す図である。
【図５】本発明の実施形態に従う自身のホームネットワークで動作するＤＨＣＰクライアントに対するＤＨＣＰサポート用の新規のアーキテクチャを示す図である。
【図６】本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。
【図７】ＤＨＣＰサーバがホームネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＤＨＣＰを使用するＤＨＣＰ  ＡＡＡについてのシグナリングフローを示す図である。
【図８】ＤＨＣＰが訪問先ネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＤＨＣＰとＤｉａｍｅｔｅｒ  ＤＨＣＰアプリケーションとの組み合わせを使用するＤＨＣＰ  ＡＡＡについてのシグナリングフローを示す図である。
【図９】ＤＨＣＰサーバがホームネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ  ＤＨＣＰ  アプリケーションを使用するＤＨＣＰ  ＡＡＡについてのシグナリングフローを示す図である。
【図１０】ＤＨＣＰサーバが訪問先ネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ  ＤＨＣＰ  アプリケーションを使用するＤＨＣＰ  ＡＡＡについてのシグナリングフローを示す図である。
【図１】
2007534267.tif 000004
【図２】
2007534267.tif 000005
【図３】
2007534267.tif 000006
【図４】
2007534267.tif 000007
【図５】
2007534267.tif 000008
【図６】
2007534267.tif 000009
【図７】
2007534267.tif 000010
【図８】
2007534267.tif 000011
【図９】
2007534267.tif 000012
【図１０】
2007534267.tif 000013
【手続補正書】
【提出日】平成18年5月23日(2006.5.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＤＨＣＰクライアント用の動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートする方法であって、
ＡＡＡサーバで、適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てる工程と、
し、前記ＤＨＣＰクライアントと前記ＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するためのＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信する工程と
を備えることを特徴とする請求項１に記載の方法。
【請求項２】
前記送信する工程は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信することを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークのオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てる
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記モバイルホストは、前記ＡＡＡインフラストラクチャを介して、ＤＨＣＰ割当リクエストをＡＡＡホームネットワークサーバ（ＡＡＡｈ）へ送信し、
前記ＡＡＡｈは、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ転送し、
前記ＡＡＡホームネットワークサーバは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データは、前記ＡＡＡｖを介して、前記ＡＡＡｈから前記ＤＨＣＰサーバへ転送され、
前記ＡＡＡｈは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ＡＡＡｖを介して前記ＡＡＡｈへ応答し、
前記ＡＡＡｈは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記ＤＨＣＰクライアントへ割り当てる
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記ＤＨＣＰクライアントはモバイルホストであり、
前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データを、前記ＤＨＣＰサーバへ送信し、
前記ホームネットワークのＡＡＡコンポーネントは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ホームネットワークのＡＡＡコンポーネントへ応答し、
前記ホームネットワークのＡＡＡコンポーネントは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行する
ことを特徴とする請求項１に記載の方法。
【請求項１１】
ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするシステムであって、
適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てるように動作可能なＡＡＡサーバと、
前記ＤＨＣＰクライアントと前記ＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するための前記ＡＡＡインフラストラクチャコンポーネントを介して、ＤＨＣＰ関連情報を送信する手段と
を備えることを特徴とするシステム。
【請求項１２】
前記送信する手段は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信する手段を含む
ことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てるように動作可能である
ことを特徴とする請求項１１に記載のシステム。
【請求項１４】
ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、
前記モバイルホストから、ＤＨＣＰ割当リクエストを受信し、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ送信する手段と、
前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記ＡＡＡｖを介して前記割り当てられたＤＨＣＰサーバへ送信し、かつ前記ＡＡＡｖを介して前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
を備えることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記モバイルホストへ割り当てるように動作可能である
ことを特徴とする請求項１１に記載のシステム。
【請求項１６】
前記ＤＨＣＰクライアントはモバイルホストであり、
前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、
前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを、前記割り当てられたＤＨＣＰサーバへ送信する手段と、
前記セキュリティアソシエーションを成立させるための情報を前記ＤＨＣＰサーバから受信する手段と、
ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
を備えることを特徴とする請求項１１に記載のシステム。
【請求項１７】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
ことを特徴とする請求項１１に記載のシステム。
【請求項１８】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
ことを特徴とする請求項１１に記載のシステム。
【請求項２０】
ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡサーバであって、
前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ、適切なＤＨＣＰサーバを割り当てる手段を備える
ことを特徴とするＡＡＡサーバ。
【請求項２１】
前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、前記ＡＡＡサーバは、前記訪問先ネットワークオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）である
ことを特徴とする請求項２０に記載のＡＡＡサーバ。
【請求項２２】
前記ＤＨＣＰクライアントはモバイルホストであり、前記ＡＡＡサーバは、前記モバイルホストの前記ホームネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡホームネットワークサーバ（ＡＡＡｈ）である
ことを特徴とする請求項２０に記載のＡＡＡサーバ。
【請求項２３】
モバイルホストに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡホームネットワークサーバであって、
前記モバイルホストとＡＡＡサーバによって割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
前記信用関連データを前記割り当てられたＤＨＣＰサーバへ送信する手段と、
前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
前記モバイルホストへ、ＤＨＣＰセキュリティアソシエーション情報を含むＤＨＣＰ認可情報を送信する手段と
を備えることを特徴とするＡＡＡホームネットワークサーバ。
【請求項２４】
当該ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記モバイルホストへの更なる送信のために、前記ＡＡＡインフラストラクチャコンポーネントから前記ＤＨＣＰサーバ割当情報を受信するように動作可能であり、
前記モバイルホストは、訪問先ネットワーク内をローミングするホストであり、
前記ＤＨＣＰ認可情報を送信する手段は、前記モバイルホストの前記ホームネットワークと前記訪問先ネットワークとをリンクするＡＡＡインフラストラクチャを介して、前記情報を送信するように動作可能であり、
前記ＡＡＡホームネットワークサーバは、前記割り当てられたＤＨＣＰサーバから、ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信するように構成され、
前記ＤＨＣＰ認可情報を送信する手段は、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記モバイルホストへ送信するように構成されている
ことを特徴とする請求項２３に記載のＡＡＡホームネットワークサーバ。
【請求項２５】
モバイルホストに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするシステムであって、
ＤＨＣＰサービスに対する前記モバイルホストを認証し、かつ認可するＡＡＡインフラストラクチャを介して、訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報を、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間で送信する手段を備える
ことを特徴とするシステム。
【請求項２６】
前記ＤＨＣＰ関連認証及び認可情報は、拡張可能認証プロトコル（ＥＡＰ）で、前記モバイルホストとＡＡＡホームネットワークサーバ間を送信され、
前記ＤＨＣＰ関連情報は、ＥＡＰプロトコルスタックに追加データとして組み込まれる
ことを特徴とする請求項２５に記載のシステム。
【国際調査報告】
2007534267.tif 000014
2007534267.tif 000015
2007534267.tif 000016
2007534267.tif 000017