JP4564054B2 - Ｄｈｃｐ用サポート - Google Patents

Ｄｈｃｐ用サポート Download PDF

Info

Publication number
JP4564054B2
JP4564054B2 JP2007509417A JP2007509417A JP4564054B2 JP 4564054 B2 JP4564054 B2 JP 4564054B2 JP 2007509417 A JP2007509417 A JP 2007509417A JP 2007509417 A JP2007509417 A JP 2007509417A JP 4564054 B2 JP4564054 B2 JP 4564054B2
Authority
JP
Japan
Prior art keywords
dhcp
server
aaa
eap
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007509417A
Other languages
English (en)
Other versions
JP2007534267A (ja
Inventor
ジョンソン 王山
良司 加藤
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2007534267A publication Critical patent/JP2007534267A/ja
Application granted granted Critical
Publication of JP4564054B2 publication Critical patent/JP4564054B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H04W8/065—Registration at serving network Location Register, VLR or user mobility server involving selection of the user mobility server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

本発明の技術分野
本発明は、一般的には、ネットワーク通信の分野に関するものであり、より詳しくは、ＤＨＣＰ（動的ホストコンフィグレーション（設定）プロトコル）用のＡＡＡ（認証、認可、課金（アカウンティング））サポートに関するものである。
本発明の背景
ＤＨＣＰプロトコル（ＲＦＣ２１３１）［１］は、インターネット及び、モバイルネットワークを含む同様のネットワーク上のホストへコンフィグレーションパラメータを提供するためのフレームワークを提供する。ＤＨＣＰは、基本的には、クライアント−サーバモデルで構築される。このクライアント−サーバモデルでは、指定されたＤＨＣＰサーバホストがネットワークアドレスを割り当て、そのようなコンフィグレーションパラメータを、動的に構成されたＤＨＣＰクライアントに配信する。つまり、ＤＨＣＰクライアントは、ネットワークアドレスのようなコンフィグレーションパラメータを取得するためにＤＨＣＰを使用するホストであり、また、ＤＨＣＰサーバは、コンフィグレーションパラメータをＤＨＣＰクライアントへ返信するホストである。ＤＨＣＰサーバは、通常は、システム管理者によって構成される。基本的なＤＨＣＰプロトコルは、アドレス割当用に３つのメカニズムをサポートしている。自動割当では、ＤＣＨＰは、固定アドレスをＤＨＣＰクライアントへ割り当てる。動的割当では、アドレスは、期限が設定されてクライアントに割り当てられる（あるいは、クライアントがそのアドレスを解放するまで）。手動割当では、アドレスはネットワーク管理者によって割り当てられ、また、ＤＨＣＰは単に割り当てられたアドレスをＤＨＣＰクライアントへ搬送するために使用される。ＤＨＣＰを介してパラメータ（例えば、ＴＣＰ／ＩＰスタックパラメータ）を取得した後は、ＤＨＣＰクライアントは、考慮されているネットワーク内の任意の他のホストとパケット交換することが可能とならなければならない。
ＲＦＣ２１３１のＤＨＣＰプロトコルに従えば、ＤＨＣＰコンフィグレーションを必要とするクライアント１３０は、ＤＨＣＰ ＤＩＳＣＯＶＥＲ（ディスカバー：探索）メッセージをブロードキャストする。ＤＨＣＰサーバ群１２５は、ＤＨＣＰ ＯＦＦＥＲ（オファー：申出）を用いてそれぞれ応答することができ、このメッセージには、利用可能なネットワークアドレスと他のオプションのコンフィグレーションパラメータを含んでいる（図１）。クライアント１３０は、ＤＨＣＰサーバ群１２５からＤＨＣＰ ＯＦＦＥＲメッセージを受信し、実際のＤＨＣＰコンフィグレーションに対して使用すべきＤＨＣＰサーバ群の１つを選択する。次に、クライアントは、選択したＤＨＣＰサーバを示すＤＨＣＰ ＲＥＱＵＥＳＴメッセージをブロードキャストする。選択されたサーバは、コンフィグレーションをコミットし、最終的には、そのリクエストしているクライアントに対するコンフィグレーションパラメータを含むＤＨＣＰ ＡＣＫメッセージで応答する。図１に示されるＤＨＣＰサーバディスカバーフェーズ（ＤＨＣＰ ＤＩＳＣＯＶＥＲ及びＤＨＣＰ ＯＦＦＥＲ）は、ＤＨＣＰコンフィグレーション用のサービスを行うことができるＤＨＣＰサーバ群のＤＨＣＰクライアントへ通知することが必要とされ、これは、かなり繁雑な処理である。
また、基本的なＤＨＣＰプロトコル（ＲＦＣ２１３１）は、明確なセキュリティメカリズムを含んでおらず、また、一般的には、かなり不安定なものとされている。
ＤＨＣＰ認証拡張（ＲＦＣ３１１８）［２］には、セキュリティを向上するために様々なＤＨＣＰメッセージをどのようにして認証するかを定義するＤＨＣＰ認証プロトコルがある。残念なことに、ＤＨＣＰ認証拡張（ＲＦＣ３１１８）は、ローミングするクライアントをサポートしておらず、また、ＤＨＣＰクライアントとサーバに対する帯域外キーアグリーメントプロトコル（an out-of-band key agreement protocol）の欠如のために、広範囲に展開することができない。
今日までには、局所的な信頼関係を確立し、かつＲＦＣ３１１８とともに使用することができるキーを生成するために、ＥＡＰベースのネットワークアクセス認証メカニズムをどのように使用できるかについてのアウトラインが、ＩＥＴＦで提案されている。
例えば、文献［３］は、セッションキーを生成するＥＡＰ認証方法を利用することによって、ＤＨＣＰクライアントがネットワークアクセスを獲得することを提案している。ネットワークアクセスプロセスの一部として、ＤＨＣＰクライアントと認証エージェント（ＮＡＳ；ＡＡＡクライアント）は互いの意図を通信して、ＤＨＣＰセキュリティアソシエーション（ＳＡ）を生成し、かつ必要とされるパラメータ（例えば、ナンス（nonce）、キーＩＤ等）を交換する。必要とされる情報交換は、ＥＡＰも搬送するＥＡＰ下位レイヤによって取り扱われる。
このことに従って、文献［４］は、ＲＦＣ３１１８をブートストラップ（bootstrap：起動）するために、ＰＡＮＡ内で必要とされる追加のペイロードを提案している。この文献［４］は、ＰＡＮＡ認証の成功後、ＤＨＣＰ ＳＡがＰＡＮＡ ＳＡに基づいて生成されることも提案している。
ＥＡＰ下位レイヤが、ＲＦＣ３１１８をブートストラップするために必要とされる情報交換をサポートできないことになる場合が存在する。例えば、ＥＡＰ下位レイヤが、ＰＰＰ、ＩＥＥＥ８０２．１ＸあるいはレガシーＰＡＮＡプロトコルである場合である。必要とするＥＡＰ下位レイヤのサポートを必要とすることは、ＡＡＡクライアントがＲＦＣ３１１８ブートストラップの要件を理解しなければならず、また、ＤＨＣＰクライアントとサーバ間で交換される内容を知っていなければならないことを意味する。
このように、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスに対する潜在的なサポートを改善する必要が存在している。
本発明の要約
本発明は、従来技術の構成のこれらの欠点及び他の欠点を解消するものである。
本発明の一般的な目的は、ＤＨＣＰコンフィグレーションを必要とするモバイルホストのようなＤＨＣＰクライアント用のＤＨＣＰサービスに対して改善されたサポートを提供することである。
このソリューションは、ＤＨＣＰの配備を容易にするメカニズムを含んでいることが好ましい。
特に、ＤＨＣＰサービスの認証及び認可に対して、合理化されていて、そしてなお耐性のあるソリューションを提供することが好ましい。
本発明の特別な目的は、ＤＨＣＰサービスをサポートする方法及びシステムを提供することである。
本発明の更なる目的は、ＤＨＣＰサービスの認証及び認可をサポートする固有のネットワークコンポーネントを提供することである。
これらの及び他の目的は、特許請求の範囲によって定義される本発明によって達成されるものである。
本発明の基本的な特徴は、ＤＨＣＰクライアント用のＤＨＣＰサポートを「ブートストラップ（bootstrap）」するためのＡＡＡインフラストラクチャに依存することである。この概念は、ＡＡＡインフラストラクチャを使用して、適切なＤＨＣＰサーバを、ＤＨＣＰサービスに対するＤＨＣＰクライアントへ割り当て、かつその割り当てられたＤＨＣＰサーバを用いて、ＤＨＣＰサービスに対するＤＨＣＰクライアントを認証及び認可するためのＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信することである。
従来の繁雑なＤＨＣＰサーバディスカバリープロセスに代えて、ＡＡＡインフラストラクチャ、より詳しくは、適切なＡＡＡサーバが、適切なＤＣＨＰサーバをＤＨＣＰクライアントへ割り当てるために使用される。その結果、ＤＨＣＰディスカバリー関連メッセージのこれ以上の強制的な依存性はなくなる。この割当は、典型的には、クライアントホストから開始されるＤＨＣＰサーバ割当リクエストに応答する、あるいはネットワークから開始される（network-initiated）再割当で行われる。
また、割り当てられたＤＨＣＰサーバを用いて、ＤＨＣＰサービスに対するＤＨＣＰクライアントの認証だけではなく認可が、必要なＤＨＣＰ関連認証及び認可情報の送信用のＡＡＡインフラストラクチャを使用することによってサポートされる。ＤＨＣＰブートストラップは、通常、割り当てられたＤＨＣＰサーバとモバイルホスト間のセキュリティアソシエーションの確立に基づいていて、これは、クライアントホストの次のＤＨＣＰコンフィグレーションに関係する通信を安全にする。そのため、ＤＨＣＰ関連情報の送信には、ＤＨＣＰサーバ割当情報（例えば、割り当てられたＤＨＣＰサーバのネットワークアドレス）とＤＨＣＰセキュリティ関連情報のＤＨＣＰクライアントへの送信を含んでいることが好ましい。
重要な状況の例では、ＤＨＣＰクライアントは訪問先ネットワークをローミングするモバイルホストである。訪問先ネットワーク内のＡＡＡサーバ、いわゆる、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、適切なＤＨＣＰサーバをクライアントへ割り当てることを担当することが好ましい。ＤＨＣＰサーバ割当は、例えば、訪問先ネットワークオペレータによって決定されるいくつかのポリシーに基づいていても良い。
ホームネットワークあるいは他のネットワーク内に配置されるＤＨＣＰサーバを構成することが有益である場合が存在することも理解されるであろう。これには、例えば、訪問先ネットワークがＤＣＨＰサーバサポートを提供しない場合がある。ＤＨＣＰサーバがモバイルホストのホームネットワークに配置される場合では、いわゆるＡＡＡホームネットワークサーバ（ＡＡＡｈ）を、ＤＨＣＰサーバ割当用の適切なＡＡＡインフラストラクチャコンポーネントとして使用することが適切な場合がある。
事実、本発明を用いると、ＤＨＣＰサーバの位置は、ホームネットワーク、訪問先ネットワークあるいは他のネットワークにさえも配置することができる。
ＡＡＡインフラストラクチャの信頼性は、ＤＨＣＰ認証及び認可サポートをブートストラップするための様々な可能性を提案する。例えば、ＤＨＣＰクライアントが訪問先ネットワークをローミングするモバイルホストである場合、訪問先ドメインに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、モバイルホストとＡＡＡホームネットワークサーバ間をＤＣＨＰ関連認証及び認可情報（好ましくは、同時に）を送信することはかなり有益であることが証明されている。これは、好ましくは、アクセスネットワークノードのようなノード、ＡＡＡクライアント及び訪問先ネットワーク内のＡＡＡサーバ、更には、他の介在し得る中間ＡＡＡサーバの透過性（transparency）を含んでいる。このことは、訪問先ネットワークのＡＡＡノードを単なるパススルーエージェントとすることを可能にする。これは、重要な効果である。また、モバイルホストとＡＡＡｈ間で事前暗号化を適用することも可能である。これは、エアインタフェースを介する交換を不可視にすることができる。
認証プロトコルは、既存プロトコルあるいは新規なプロトコルに基づく、拡張された認証プロトコルであっても良い。ＤＨＣＰ認証及び認可をブートストラップするための基礎として使用することが可能な認証プロトコルには、拡張可能認証プロトコル（ＥＡＰ）がある。これは、ＥＡＰ拡張を生成するとともに、好ましくは、ＥＡＰ下位レイヤ（群）をそのまま維持する。このことは、通常は、ＤＣＨＰ関連情報が追加データとして、例えば、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性として、ＥＡＰプロトコルスタックに組み込まれることを意味する。あるいは、ＤＣＨＰ関連情報がＥＡＰレイヤあるいはＥＡＰメソッドレイヤ上の汎用コンテナで送信されることを意味する。
別の方法では、補完として使用する、あるいはＥＡＰ拡張の代替として使用することは、ＤＨＣＰに適合されているＤｉａｍｅｔｅｒアプリケーション、あるいはＲａｄｉｕｓプロトコルに基づく対応アプリケーションのような、新規のあるいは拡張されたＡＡＡフレームワークプロトコルアプリケーションを生成するようなＥＡＰ「下位レイヤ（群）」を拡張することになる。
ＤＨＣＰサーバが訪問先ネットワークに配置される場合、新規のあるいは拡張されたＥＡＰ形式のプロトコルは、拡張されたＡＡＡフレームワークプロトコルアプリケーションと組み合わせて使用されることが好ましい。あるいは、選択的には、拡張されたＡＡＡフレームワークプロトコルアプリケーションは、ＥＡＰ形式の拡張のサポートなしで使用される。
ＤＨＣＰサーバがホームネットワークに配置される場合、例えば、新規のあるいは拡張された認証プロトコル、あるいは拡張されたＡＡＡフレームワークプロトコルアプリケーションを使用することが可能である。
例えば、拡張されたＥＡＰあるいはＥＡＰ形式プロトコルは、例えば、ＰＡＮＡ（ネットワークアクセス用認証搬送プロトコル）、ＰＰＰ（ポイントツーポイントプロトコル）、ＩＥＥＥ８０２．１Ｘ、あるいは、モバイルホストと訪問先ネットワーク内のＡＡＡクライアント間のＧＰＲＳ／ＵＭＴＳインタフェースを介して搬送されても良い。また、拡張されたＥＡＰあるいはＥＡＰ形式プロトコルは、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓによって搬送されても良い。
ＤＨＣＰ認証及び認可情報の両方を搬送するためのＥＡＰ拡張のような認証プロトコル拡張の類の、カスタマイズされた認証プロトコルに依存することは、合理化されたソリューションを提供する。このことは、後方互換性の問題を最小限にして管理可能であり、かつ的確である。
拡張認証プロトコルスタックあるいは拡張ＡＡＡフレームワークプロトコルアプリケーションに、ＨＭＩＰｖ６関連情報あるいはＭＩＰｖ６関連情報を含めることによって、ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行することが可能である。もちろん、特定の場合に特別に必要とするモバイルホストに依存して、例えば、ＤＨＣＰ／ＨＭＩＰｖ６／ＭＩＰｖ６使用可能ネットワークを使用して、ＨＭＩＰｖ６／ＭＩＰｖ６に対応するものなしで、ＤＨＣＰ認証及び認可のみを実行することが可能であり、その逆も可能である。これは、単一の拡張認証プロトコル及び拡張フレームワークプロトコルアプリケーションの少なくとも一方に、様々な使用状況で使用される場合の柔軟性を与えることを可能にする。
本発明は、以下の効果を提供する：
・ＡＡＡベースのＤＨＣＰサーバ割当
・ＤＨＣＰサポートの効果的なブートストラップ
・ＤＨＣＰサービスを認可するためのＤＨＣＰ関連情報の効果的な送信
・ＥＡＰ形式の拡張に基づくＤＨＣＰ認証及び認可サポートについて合理化されたソリューション、これは、後方互換性の問題を最小限にして管理可能であり、かつ的確である
・共通の処理で、認証及び認可の最適化
・訪問先ネットワークに制限されないＤＨＣＰサーバ位置
・ＤＨＣＰサーバをホームネットワーク内に配置することができる
・同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６とＭＩＰｖ６認証及び認可の同時実行
本発明によって提供される他の効果は、本発明の実施形態の以下の説明を読むことによって理解されるであろう。
本発明の実施形態の詳細説明
図面全体を通して、同一の参照文字は、対応する要素あるいはそれに類する要素に対して使用している。
基本的な概念は、ＡＡＡインフラストラクチャを使用して、ＤＨＣＰサービスに対するＤＨＣＰクライアントに適切なＤＨＣＰサーバを割り当てることであり、また、その割り当てられたＤＨＣＰサーバを用いてＤＨＣＰサービスに対するＤＨＣＰクライアントを認証し、かつ認可するためのＡＡＡインフラストラクチャを介してＤＨＣＰ関連情報を送信することである。
従来より知られている、かなりより複雑なＤＨＣＰサーバディスカバリープロセスに代えて、ＡＡＡインストラクチャ、より詳しくは適切なＡＡＡサーバあるいはそれと等価のＡＡＡコンポーネントが、適切なＤＨＣＰサーバをＤＨＣＰクライアントに対して割り当てるために使用される。その結果、ＤＨＣＰディスカバリー関連メッセージにおける依存性はもはや必須ではない。
例えば、ＤＨＣＰクライアントをモバイルホストとすることができ、また、本発明は、ローミングするホストに対するサポートさえも提供する。モバイルホストが訪問先ネットワーク内でローミングしている場合、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、クライアントに適切なＤＨＣＰサーバを割り当てることを担当することが好ましい。ＤＨＣＰサーバ割当は、例えば、訪問先ネットワークオペレータによって決定されるいくつかのポリシーに基づいても良い。ＤＨＣＰサーバの選択は、例えば、利用可能なＤＨＣＰサーバ群の現在の負荷、モバイルホストの位置、モバイルホストによって与えられるプリファレンスの少なくともいずれかに基づくことができる。
しかしながら、ホームネットワークあるいは他のネットワークに配置されるＤＨＣＰサーバを持つことが有益な場合も存在する。これは、例えば、訪問先ネットワークがＤＨＣＰサーバサポートを提供しない場合である。このような場合は、ＤＨＣＰサーバ割当用の適切なＡＡＡインフラストラクチャとして、いわゆる、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）を使用することが適切であるからである。
事実、本発明を用いると、ＤＨＣＰサーバの位置を、ホームネットワーク、訪問先ネットワーク、あるいは他のネットワーク内さえにもすることができる。
ＡＡＡ ＤＨＣＰのブートストラップは、通常、セキュリティアソシエーションの確立、即ち、ＡＡＡインフラストラクチャを介する、割当られたＤＨＣＰサーバと認証されたＤＨＣＰクライアント（例えば、モバイルホスト）間のセキュリティ関係に基づいていて、これにより、クライアントのＤＨＣＰコンフィグレーション用に、そのＤＨＣＰサーバとクライアント間の通信を安全（セキュア）にする。ＤＨＣＰセキュリティアソシエーション情報とＤＨＣＰサーバ割当情報は、ＤＨＣＰコンフィグレーションサービスに対するＤＨＣＰクライアントを認可するためのＡＡＡインフラストラクチャを介してＤＨＣＰクライアントへ送信される。本発明は、適切なＤＨＣＰサーバの割当を容易にすること、及びＤＨＣＰ認証拡張（ＲＦＣ３１１８）のブートストラップを容易にするＤＨＣＰ関連情報を搬送することによってＤＨＣＰクライアントとサーバに対して帯域外キーアグリーメントプロトコルを提供することの少なくとも一方を行うために、ＡＡＡプロトコルサポートを提供することが好ましい。
以下の実施形態では、ＤＣＨＰクライアントは、基本的には、モバイルホストあるいはモバイルノードによって示される。しかしながら、本発明はこれに限定されないことが理解されるべきである。
図２は、クライアントホストに対してＤＨＣＰサービスをサポートする方法の例を示すフロー図である。ステップＳ１では、モバイルＤＨＣＰクライアントホストは、典型的には、ＡＡＡインフラストラクチャを介するチャレンジ−応答（challenge-response）処理に基づいて、そのモバイルホストのホームネットワーク内のＡＡＡサーバのような適切なネットワークコンポーネントによって認証される。ステップＳ２Ａで示されるように、ＤＨＣＰクライアントは、ＤＨＣＰサーバ割当をリクエストすることができる。このリクエストは、必要とされるラウンドトリップ回数を削減するために、認証応答とともに、ＡＡＡインフラストラクチャを介して送信されることが好ましい。実際には、このことは、クライアントが最終的に認証される前に、クライアントで開始されるＤＨＣＰリクエストが実行されても良いことを意味する。別のクライアントで開始されるＤＨＣＰサーバ割当としては、ＤＨＣＰサーバの割当は、ステップＳ２Ｂで示されるように、ネットワークによって開始されても良い。ステップＳ３では、ＡＡＡインフラストラクチャは、適切なＤＨＣＰサーバを、リクエストしているクライアントホストへ割り当てるために使用される。このＡＡＡインフラストラクチャは、ＤＨＣＰセキュリティアソシエーション情報を生成するためにも使用されることが好ましい。ステップＳ４では、ＡＡＡインフラストラクチャを介して、割り当てられたＤＨＣＰサーバにおける情報を含むＤＨＣＰ認可情報とＤＨＣＰセキュリティアソシエーション情報をＤＨＣＰクライアントへ送信することによって、ＤＨＣＰサービスに対して、ＤＨＣＰクライアントが認可される。これは、ＤＨＣＰクライアントが、割り当てられたＤＨＣＰサーバからネットワークアドレス（例えば、ＩＰアドレス）と他のオプションのＤＨＣＰコンフィグレーションパラメータを安全に受信することに備えることを意味するものである。
用語「ＡＡＡ」は、インターネットドラフト（草稿）、ＲＦＣ及び他の標準化文献におけるそれ自身の汎用的な意味の範囲とされるべきである。典型的には、ＡＡＡ（認証、認可、アカウンティング）インフラストラクチャの認証及びセキュリティキーアグリーメントは、ＤＨＣＰクライアント（例えば、モバイルホスト）と、そのクライアントのホームネットワークオペレータあるいは信用機関との間で共有されるイニシャルシークレット（initial secret：初期秘密鍵）の存在を示唆する、対称暗号方法に基づいている。いくつかの状況及びアプリケーションでは、例えば、ＡＡＡインフラストラクチャのアカウンティング特性は、無効にされても良く、あるいは実現されなくても良い。統合ＡＡＡインフラストラクチャは、一般的には、ホームネットワーク、中間ネットワーク（存在する場合）及び訪問先ネットワークの少なくともいずれかに、１つ以上のＡＡＡサーバを含んでいて、また、１つ以上のＡＡＡクライアントを含んでいても良い。
一般的には、ＤｉａｍｅｔｅｒプロトコルのようなＡＡＡプロトコルは、モバイルユーザに、ネットワーク内を移動して、ネットワーク内のサービスを取得することを正確に可能にする。ここで、このネットワークは、モバイルユーザ自身のホームサービスプロバイダによって所有されている必要はない。商用ネットワークで展開されるモバイルＩＰに対しては、このプロトコルに対するＡＡＡサポートを持っているべきである。特殊な場合として、モバイルＩＰｖ６（ＭＩＰｖ６）に対しては、ホームオペレータによって管理されるネットワーク以外のネットワークでのＭＩＰｖ６ローミングを可能にするＤｉａｍｅｔｅｒへの新規のアプリケーションを説明するインターネットドラフト［５］が提案されている。２００３年６月１８日に出願された本出願人の米国仮特許出願６０／４７９，１５６と、後述するインターネットドラフト［６］では、ＡＡＡインフラストラクチャに基づいてモバイルＩＰｖ６認可及びコンフィグレーションを実行するためのアーキテクチャ及び関連プロトコルが示唆されている。ホームプロバイダのＡＡＡサーバと、ＭＩＰｖ６用のモバイルホスト間で必要な対話は、ＥＡＰ（Extensible Authentication Protocol：拡張可能認証プロトコル）を使用して実現され、これは、認証データとともにモバイルＩＰｖ６ネゴシエーション用の情報を搬送する。
図３は本発明の実施形態に従うＤＨＣＰサポート用の新規のアーキテクチャを示す図である。モバイルホスト１３０（モバイルノードＭＮとも参照する）の形式でのＤＨＣＰクライアントは訪問先ネットワークでローミングしていて、また、ＤＨＣＰ認証及び認可は、訪問先ネットワークとモバイルホストのホームネットワークとをリンクしているＡＡＡインフラストラクチャを使用することによって実行される。この例では、ＡＡＡインフラストラクチャは、基本的には、ＡＡＡホームネットワークサーバ１１０、ＡＡＡ訪問先ネットワークサーバ１２０及び訪問先ネットワーク内のＡＡＡクライアント１２２を含んでいる。
好ましくは、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）１２０は、適切なＤＨＣＰサーバの割当用の適切なＡＡＡインフラストラクチャコンポーネントして使用され、これは、ＤＨＣＰサーバの選択においては、訪問先オペレータのポリシーを考慮する。
ＡＡＡインフラストラクチャのメインコンポーネントはＡＡＡサーバ１１０であり、これは、好ましくは、ＤＨＣＰサーバ割当用のリクエストをモバイルＤＨＣＰクライアントからＡＡＡｖサーバ１２０へ転送し、また、所与のモバイルＤＨＣＰクライアントホスト１３０と割り当てられたＤＨＣＰサーバ１２５間の即時あるいは将来のセキュリティアソシエーション用のセキュリティキーあるいは同様の信用証明を生成する。このセキュリティキーは、典型的には、ＡＡＡｖ１２０を介してＡＡＡｈ１００からＤＨＣＰサーバ１２５へ転送され、また、ＤＨＣＰサーバ１２５は、好ましくは、ＡＡＡｖ１２０を介してＡＡＡｈ１００とのＤＨＣＰセキュリティアソシエーションを成立させるための情報で応答する。そして、ＡＡＡｈサーバ１１０は、ＤＨＣＰサーバアドレスを含む、生成されかつ収集されたＤＨＣＰ認可情報とＤＨＣＰ ＳＡ情報をＡＡＡインフラストラクチャを介してモバイルホスト１３０へ送信する。ここで、ＡＡＡインフラストラクチャのセキュアトンネルあるいは、暗号化及びソース完全性保護のような他のセキュリティ対策は、セキュリティキー（群）のような機密情報の転送用に採用される。
ＡＡＡインフラストラクチャにおける信頼性は、ＤＨＣＰ認証及び認可サポートをブートストラップするための様々な可能性を提案する。例えば、図３に示されるように、新規に拡張された認証プロトコルを提供すること、ＡＡＡインフラストラクチャを介して搬送される既存の認証プロトコルへの拡張を提供すること、及びＤＨＣＰ認可情報を含むＤＨＣＰ関連情報を搬送するためにＡＡＡフレームワークプロトコルアプリケーションを拡張することの少なくともいずれかを行うことを可能にする。好ましくは、必要とされる認証及び認可情報は、同一のラウンドトリップで同時に送信される。
ＤＨＣＰクライアントが訪問先ネットワークでローミングするモバイルホストである場合、例えば、ＤＨＣＰ関連認証及び認可情報は、訪問先ドメインに対してトランスペアレントなエンドツーエンド処理で、認証プロトコル内のモバイルホストとＡＡＡホームネットワークサーバ間を送信されても良い。これは、訪問先ネットワークのＡＡＡノードに単なるパススルーエージェントとして動作することを可能にする。これは、重要な利点である。
好ましくは、ＤＨＣＰ用に適合されている拡張ＥＡＰ（拡張可能認証プロトコル）のような拡張認証プロトコルは、ＡＡＡｈサーバと、ＡＡＡｖサーバを介する訪問先ネットワークＤＨＣＰサーバ間のインタフェース用に、ＤＨＣＰ ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような拡張ＡＡＡフレームワークプロトコルアプリケーションとともに利用される。
例えば、拡張認証プロトコルは、ＰＡＮＡ（ネットワークアクセス認証搬送用プロトコル）、ＰＰＰ（ポイント−ツー−ポイント（point-to-point）プロトコル）、ＩＥＥＥ８０２．１Ｘ、あるいはＧＰＲＳ／ＵＭＴＳのインタフェースによって、モバイルホストと訪問先ネットワークのＡＡＡクライアント間で搬送されても良く、また、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒあるいは同様のＡＡＡフレームワーク、あるいは搬送プロトコルによって搬送されても良い。
選択的には、新規のあるいは拡張ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような、拡張ＡＡＡフレームワークプロトコルアプリケーションが、任意のＥＡＰあるいはＥＡＰ形式の拡張のサポートなしに使用される。モバイルホストとＡＡＡクライアント間の経路に対しては、ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションは、例えば、ＩＣＭＰ（インターネット制御メッセージプロトコル）によって搬送することができる。
ＭＩＰｖ６用に、ＭＮ１３０は、オプションのホームエージェント（ＨＡ）１５０に関連付けられていても良い。また、ＨＭＩＰｖ６用に、ＭＮ１３０は、オプションのモビリティアンカーポイント（不図示）に関連付けられていても良い。
ホームネットワークあるいは他のネットワーク内に配置されているＤＨＣＰサーバを持つことが有益な場合も存在することが認識される。これは、例えば、訪問先ネットワークがＤＨＣＰサーバのサポートを提供しない場合である。ホームネットワーク内に配置されている割り当てられたＤＨＣＰサーバを用いてＤＨＣＰをサポートするためのアーキテクチャの例を、図４に示す。
ＤＨＣＰサーバ割当用のＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０を使用することは有益である。好ましくは、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）１１０は、モバイルホストと割り当てられたＤＨＣＰサーバ１２５間のセキュリティアソシエーション用のセキュリティキー、あるいは同様のセキュリティパラメータあるいは信用証明書を生成し、また、そのセキュリティキーをＤＨＣＰサーバ１２５を送信する。ＤＨＣＰサーバ１２５は、セキュリティアソシエーションを成立させるための情報でＡＡＡｈ１１０に応答し、ＡＡＡｈ１１０は、次に、ＤＨＣＰサーバアドレスを含むＤＨＣＰ認可情報とＤＨＣＰ ＳＡ情報を、ＡＡＡインフラストラクチャを介してモバイルホスト１３０へ送信する。
ＤＨＣＰサーバ１２５はホームネットワークに配置されていて、また、ＤＨＣＰ用に適合されている拡張ＥＡＰ（拡張可能認証プロトコル）のような拡張認証プロトコルが採用される場合、ＡＡＡｖ１２０はＤＨＣＰトランザクションを監視する必要はなく、また、（ＭＮとＡＡＡｈ間だけでない）ＤＨＣＰ認証及び認可用の完全な「エンドツーエンド処理」を持つことが可能である。
選択的には、ＤＨＣＰ ＤｉａｍｅｔｅｒあるいはＲａｄｉｕｓアプリケーションのような拡張フレームワークプロトコルアプリケーションを利用することができる。
理解されるべきことは、本発明は、ＤＨＣＰサーバ１２５が訪問先ネットワーク内に配置されていなければならないという従来技術の制約を解消していることである。ここで、ＤＨＣＰサーバの位置は、ホームネットワーク、訪問先ネットワークあるいは他のネットワークでさえにも配置することができる。
ＤＨＣＰサーバの再割当は、以下の例の場合の間に発生する可能性がある。
・ＤＨＣＰクライアント（ＭＮ）とＤＨＣＰサーバ間のセキュリティキーの満了、この場合に対しては、ＭＮは、ＤＨＣＰ再認証／認可を開始しても良く、また、ネットワークは、例えば、ＭＮの現在のトポロジー的な位置に基づいてより適切となる異なるＤＨＣＰを割り当てても良い。
・モバイルＤＨＣＰクライアントのリクエスト（ＭＮからの開始）で、この場合に対しては、ＭＮはＤＣＨＰサーバの再割当をリクエストするＤＨＣＰ再認証／認可を開始する。
・ネットワーク（ネットワークからの開始）のリクエストで、この場合に対しては、ＡＡＡｈあるいはＡＡＡｖは、ＤＨＣＰサーバの再割当を開始することができ、また、必要が発生する場合、例えば、ＭＮは、新規のＤＨＣＰサーバによってより良好にカバーされるアクセスルータ（ＡＲ）へＭＮが移動する場合に、これをＭＮへ「プッシュ」する。
図３及び図４を再度参照すると、セグメントＡＡＡクライアント−ＡＡＡｈ、ＡＡＡｈ−（ＡＡＡｖ）−ＤＨＣＰサーバ間の異なるプロトコルの取り得る組み合わせの例を以下にまとめる。
Figure 0004564054
組み合わせ（ｉｉｉ）は、特に、ＤＨＣＰサーバがホームネットワークに配置されている場合に適用可能である。ＤＨＣＰサーバが訪問先ネットワークに配置されている場合、ＡＡＡｖは、訪問先ネットワークポリシーに基づいて、ＤＨＣＰサーバの選択に関与しても良い。
ＥＡＰのような拡張認証プロトコルに対しては、ＤＨＣＰ関連認証及び認可情報は、同一のＥＡＰラウンドトリップで同時に送信されることが好ましい。
別の状況では、図５に示されるように、モバイルＤＨＣＰクライアント１３０は実際にホームネットワークに配置されていて、また、ＡＡＡｈサーバ１１０のようなホームネットワークのＡＡＡインフラストラクチャコンポーネントは、ホームネットワーク内のＤＨＣＰサーバ１２５でのＤＨＣＰサービスに対して必要なサポートを提供する。これは、拡張認証ＤＨＣＰプロトコル及びＡＡＡ ＤＨＣＰアプリケーションの少なくとも一方の関連部分のみが、必要な認証及び認可情報の交換に対して使用されなければならないことを意味する。
図６は、本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。この例では、ＡＡＡｈサーバ１１０は、基本的には、オプションのＤＨＣＰサーバ割当モジュール１１１、ＤＨＣＰセキュリティアソシエーションモジュール１１２、ＤＨＣＰ認可情報マネージャ１１３及び入力−出力（Ｉ／Ｏ）インタフェース１１４を備えている。ホームネットワーク内に存在する場合のＤＨＣＰサーバに対しては、ＡＡＡｈサーバ１１０は、ＤＨＣＰサーバ割当モジュール１１１を含み、これは、モバイルホストへの適切なＤＨＣＰサーバの割当及び再割当の少なくとも一方を行うために動作可能である。訪問先ネットワークに存在する場合のＤＨＣＰサーバに対しては、ＡＡＡｈサーバ１１０は、典型的には、自身のＩ／Ｏインタフェース１１４で、ＡＡＡｖから必要なＤＨＣＰサーバ割当情報を受信する。ＡＡＡｈサーバは、典型的には、モバイルホストからキーシード（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＞）
従来のＤＨＣＰディスカバリープロセスを示す図である。 クライアントホストに対してＤＨＣＰサービスをサポートする方法の例のフロー図である。 本発明の実施形態に従う訪問先ネットワークでローミングするＤＨＣＰクライアントに対するＤＨＣＰ認証及び認可サポート用の新規のアーキテクチャを示す図である。 本発明の別の実施形態に従う訪問先ネットワークでローミングするＤＨＣＰクライアントに対するＤＨＣＰサポート用の新規のアーキテクチャを示す図である。 本発明の実施形態に従う自身のホームネットワークで動作するＤＨＣＰクライアントに対するＤＨＣＰサポート用の新規のアーキテクチャを示す図である。 本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。 ＤＨＣＰサーバがホームネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＤＨＣＰを使用するＤＨＣＰ ＡＡＡについてのシグナリングフローを示す図である。 ＤＨＣＰが訪問先ネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ／ＥＡＰ／ＤＨＣＰとＤｉａｍｅｔｅｒ ＤＨＣＰアプリケーションとの組み合わせを使用するＤＨＣＰ ＡＡＡについてのシグナリングフローを示す図である。 ＤＨＣＰサーバがホームネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ ＤＨＣＰ アプリケーションを使用するＤＨＣＰ ＡＡＡについてのシグナリングフローを示す図である。 ＤＨＣＰサーバが訪問先ネットワークに配置されている場合に対して、Ｄｉａｍｅｔｅｒ ＤＨＣＰ アプリケーションを使用するＤＨＣＰ ＡＡＡについてのシグナリングフローを示す図である。

Claims (24)

  1. ＤＨＣＰクライアント用の動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートする方法であって、
    ＡＡＡサーバで、適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てる工程と、
    前記ＤＨＣＰクライアントと前記ＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するためのＡＡＡインフラストラクチャを介して、ＤＨＣＰ関連情報を送信する工程と
    を備えることを特徴とする方法。
  2. 前記送信する工程は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信することを含む
    ことを特徴とする請求項１に記載の方法。
  3. 前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークのオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てる
    ことを特徴とする請求項１に記載の方法。
  4. 前記モバイルホストは、前記ＡＡＡインフラストラクチャを介して、ＤＨＣＰ割当リクエストをＡＡＡホームネットワークサーバ（ＡＡＡｈ）へ送信し、
    前記ＡＡＡｈは、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ転送し、
    前記ＡＡＡホームネットワークサーバは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データは、前記ＡＡＡｖを介して、前記ＡＡＡｈから前記ＤＨＣＰサーバへ転送され、
    前記ＡＡＡｈは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ＡＡＡｖを介して前記ＡＡＡｈへ応答し、
    前記ＡＡＡｈは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
    ことを特徴とする請求項３に記載の方法。
  5. 前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記ＤＨＣＰクライアントへ割り当てる
    ことを特徴とする請求項１に記載の方法。
  6. 前記ＤＨＣＰクライアントはモバイルホストであり、
    前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のセキュリティアソシエーション用の信用関連データを生成し、前記信用関連データを、前記ＤＨＣＰサーバへ送信し、
    前記ホームネットワークのＡＡＡコンポーネントは、前記セキュリティアソシエーションを成立させるための情報を生成する、あるいは前記ＤＨＣＰサーバは、前記セキュリティアソシエーションを成立させるための情報を用いて、前記ホームネットワークのＡＡＡコンポーネントへ応答し、
    前記ホームネットワークのＡＡＡコンポーネントは、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する
    ことを特徴とする請求項１に記載の方法。
  7. 前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
    前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は、前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
    ことを特徴とする請求項１に記載の方法。
  8. 前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
    ことを特徴とする請求項７に記載の方法。
  9. 前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
    ことを特徴とする請求項１に記載の方法。
  10. 前記ＡＡＡインフラストラクチャを介して、同一のラウンドトリップで、ＤＨＣＰ認証及び認可と、ＨＭＩＰｖ６／ＭＩＰｖ６認証及び認可を同時に実行する
    ことを特徴とする請求項１に記載の方法。
  11. ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするシステムであって、
    適切なＤＨＣＰサーバを、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ割り当てるように動作可能なＡＡＡサーバと、
    前記ＤＨＣＰクライアントと前記ＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーションを確立するために、前記割り当てられたＤＨＣＰサーバを用いて、前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントを認証及び認可するための前記ＡＡＡインフラストラクチャコンポーネントを介して、ＤＨＣＰ関連情報を送信する手段と
    を備えることを特徴とするシステム。
  12. 前記送信する手段は、ＤＨＣＰサーバ割当情報とＤＨＣＰセキュリティアソシエーション情報を前記ＤＨＣＰクライアントへ送信する手段を含む
    ことを特徴とする請求項１１に記載のシステム。
  13. 前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）は、前記訪問先ネットワークオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを前記モバイルホストに割り当てるように動作可能である
    ことを特徴とする請求項１１に記載のシステム。
  14. ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、
    前記モバイルホストから、ＤＨＣＰ割当リクエストを受信し、前記ＤＨＣＰ割当リクエストを、ＤＨＣＰサーバの割当用の前記ＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）へ送信する手段と、
    前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
    前記信用関連データを前記ＡＡＡｖを介して前記割り当てられたＤＨＣＰサーバへ送信し、かつ前記ＡＡＡｖを介して前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
    ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
    を備えることを特徴とする請求項１３に記載のシステム。
  15. 前記ＤＨＣＰクライアントはモバイルホストであり、ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記ホームネットワーク内のＤＨＣＰサーバを前記モバイルホストへ割り当てるように動作可能である
    ことを特徴とする請求項１１に記載のシステム。
  16. 前記ＤＨＣＰクライアントはモバイルホストであり、
    前記モバイルホストの前記ホームネットワークのＡＡＡコンポーネントは、
    前記モバイルホストと前記割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
    前記信用関連データを、前記割り当てられたＤＨＣＰサーバへ送信する手段と、
    前記セキュリティアソシエーションを成立させるための情報を前記ＤＨＣＰサーバから受信する手段と、
    ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記ＡＡＡインフラストラクチャを介して、前記モバイルホストへ送信する手段と
    を備えることを特徴とする請求項１１に記載のシステム。
  17. 前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、
    前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理において、認証プロトコルで、ＤＨＣＰ関連認証及び認可情報は前記モバイルホストとＡＡＡホームネットワークサーバ（ＡＡＡｈ）間を送信される
    ことを特徴とする請求項１１に記載のシステム。
  18. 前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＤＨＣＰ関連認証及び認可情報は、前記ＥＡＰプロトコルスタック内に追加データとして組み込まれる
    ことを特徴とする請求項１７に記載のシステム。
  19. 前記ＤＨＣＰ関連情報は、前記ＡＡＡインフラストラクチャを介して、ＡＡＡフレームワークプロトコルアプリケーションで送信される
    ことを特徴とする請求項１１に記載のシステム。
  20. ＤＨＣＰクライアントに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡサーバであって、
    前記ＤＨＣＰサービスに対する前記ＤＨＣＰクライアントへ、適切なＤＨＣＰサーバを割り当てる手段を備える
    ことを特徴とするＡＡＡサーバ。
  21. 前記ＤＨＣＰクライアントは、訪問先ネットワークでローミングするモバイルホストであり、前記ＡＡＡサーバは、前記訪問先ネットワークオペレータのポリシーに基づいて、前記訪問先ネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡ訪問先ネットワークサーバ（ＡＡＡｖ）である
    ことを特徴とする請求項２０に記載のＡＡＡサーバ。
  22. 前記ＤＨＣＰクライアントはモバイルホストであり、前記ＡＡＡサーバは、前記モバイルホストの前記ホームネットワーク内のＤＨＣＰサーバを割り当てるように動作可能なＡＡＡホームネットワークサーバ（ＡＡＡｈ）である
    ことを特徴とする請求項２０に記載のＡＡＡサーバ。
  23. モバイルホストに対して、動的ホストコンフィグレーションプロトコル（ＤＨＣＰ）サービスをサポートするＡＡＡホームネットワークサーバであって、
    前記モバイルホストとＡＡＡサーバによって割り当てられたＤＨＣＰサーバ間のＤＨＣＰセキュリティアソシエーション用の信用関連データを生成する手段と、
    前記信用関連データを前記割り当てられたＤＨＣＰサーバへ送信する手段と、
    前記ＤＨＣＰサーバから、前記ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信する手段と、
    前記モバイルホストへ、ＤＨＣＰセキュリティアソシエーション情報を含むＤＨＣＰ認可情報を送信する手段と
    を備えることを特徴とするＡＡＡホームネットワークサーバ。
  24. 当該ＡＡＡホームネットワークサーバ（ＡＡＡｈ）は、前記モバイルホストへの更なる送信のために、前記ＡＡＡインフラストラクチャコンポーネントから前記ＤＨＣＰサーバ割当情報を受信するように動作可能であり、
    前記モバイルホストは、訪問先ネットワーク内をローミングするホストであり、
    前記ＤＨＣＰ認可情報を送信する手段は、前記モバイルホストの前記ホームネットワークと前記訪問先ネットワークとをリンクするＡＡＡインフラストラクチャを介して、前記情報を送信するように動作可能であり、
    前記ＡＡＡホームネットワークサーバは、前記割り当てられたＤＨＣＰサーバから、ＤＨＣＰセキュリティアソシエーションを成立させるための情報を受信するように構成され、
    前記ＤＨＣＰ認可情報を送信する手段は、ＤＨＣＰサーバ割当情報を含むＤＨＣＰ認可情報と、ＤＨＣＰセキュリティアソシエーション情報を、前記モバイルホストへ送信するように構成されている
    ことを特徴とする請求項２３に記載のＡＡＡホームネットワークサーバ。
JP2007509417A 2004-04-23 2004-12-10 Ｄｈｃｐ用サポート Expired - Fee Related JP4564054B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US56459004P 2004-04-23 2004-04-23
PCT/SE2004/001856 WO2005104500A1 (en) 2004-04-23 2004-12-10 Aaa support for dhcp

Publications (2)

Publication Number Publication Date
JP2007534267A JP2007534267A (ja) 2007-11-22
JP4564054B2 true JP4564054B2 (ja) 2010-10-20

Family

ID=34959696

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007509417A Expired - Fee Related JP4564054B2 (ja) 2004-04-23 2004-12-10 Ｄｈｃｐ用サポート

Country Status (4)

Country Link
US (1) US7983418B2 (ja)
JP (1) JP4564054B2 (ja)
GB (1) GB2429381B (ja)
WO (1) WO2005104500A1 (ja)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8312267B2 (en) 2004-07-20 2012-11-13 Time Warner Cable Inc. Technique for securely communicating programming content
US8266429B2 (en) 2004-07-20 2012-09-11 Time Warner Cable, Inc. Technique for securely communicating and storing programming material in a trusted domain
FI20050384A0 (fi) * 2005-04-14 2005-04-14 Nokia Corp Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä
CN100388739C (zh) * 2005-04-29 2008-05-14 华为技术有限公司 实现dhcp地址安全分配的方法及系统
US7624181B2 (en) 2006-02-24 2009-11-24 Cisco Technology, Inc. Techniques for authenticating a subscriber for an access network using DHCP
US7853708B2 (en) * 2006-02-24 2010-12-14 Cisco Technology, Inc. Techniques for replacing point to point protocol with dynamic host configuration protocol
US20070220598A1 (en) * 2006-03-06 2007-09-20 Cisco Systems, Inc. Proactive credential distribution
US8745253B2 (en) * 2006-03-08 2014-06-03 Alcatel Lucent Triggering DHCP actions from IEEE 802.1x state changes
EP1881434A1 (en) * 2006-06-09 2008-01-23 Axalto SA A personal token having enhanced signaling abilities
US7831997B2 (en) * 2006-06-22 2010-11-09 Intel Corporation Secure and automatic provisioning of computer systems having embedded network devices
US8520850B2 (en) 2006-10-20 2013-08-27 Time Warner Cable Enterprises Llc Downloadable security and protection methods and apparatus
US8732854B2 (en) 2006-11-01 2014-05-20 Time Warner Cable Enterprises Llc Methods and apparatus for premises content distribution
CN101179554B (zh) * 2006-11-07 2012-12-12 华为技术有限公司 一种告知移动用户终端自举模式的方法
US8621540B2 (en) * 2007-01-24 2013-12-31 Time Warner Cable Enterprises Llc Apparatus and methods for provisioning in a download-enabled system
US8296438B2 (en) * 2007-07-11 2012-10-23 International Business Machines Corporation Dynamically configuring a router to find the best DHCP server
US8104073B2 (en) * 2007-08-10 2012-01-24 Juniper Networks, Inc. Exchange of network access control information using tightly-constrained network access control protocols
US8239549B2 (en) 2007-09-12 2012-08-07 Microsoft Corporation Dynamic host configuration protocol
US8806565B2 (en) 2007-09-12 2014-08-12 Microsoft Corporation Secure network location awareness
EP2210429B1 (en) * 2007-09-20 2014-01-15 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for roaming between communications networks
US8341702B2 (en) * 2007-11-01 2012-12-25 Bridgewater Systems Corp. Methods for authenticating and authorizing a mobile device using tunneled extensible authentication protocol
CN101184100A (zh) * 2007-12-14 2008-05-21 中兴通讯股份有限公司 基于动态主机配置协议的用户接入认证方法
CN101471767B (zh) * 2007-12-26 2011-09-14 华为技术有限公司 密钥分发方法、设备及系统
EP2091204A1 (en) 2008-02-18 2009-08-19 Panasonic Corporation Home agent discovery upon changing the mobility management scheme
US20090290539A1 (en) * 2008-05-21 2009-11-26 Huawei Technologies, Co., Ltd. Method and apparatus for home agent address acquisition for IPv4 mobile nodes
CN101321074B (zh) 2008-06-26 2011-09-14 华为技术有限公司 享用订购业务内容的方法及其系统
JP5255403B2 (ja) * 2008-10-30 2013-08-07 日本無線株式会社 サービスプラン作成方法
KR101691778B1 (ko) * 2009-03-05 2016-12-30 인터디지탈 패튼 홀딩스, 인크 안전한 원격 가입 관리
US9602864B2 (en) 2009-06-08 2017-03-21 Time Warner Cable Enterprises Llc Media bridge apparatus and methods
US9866609B2 (en) 2009-06-08 2018-01-09 Time Warner Cable Enterprises Llc Methods and apparatus for premises content distribution
CN102035815B (zh) * 2009-09-29 2013-04-24 华为技术有限公司 数据获取方法、接入节点和系统
US8260902B1 (en) * 2010-01-26 2012-09-04 Juniper Networks, Inc. Tunneling DHCP options in authentication messages
US9906838B2 (en) 2010-07-12 2018-02-27 Time Warner Cable Enterprises Llc Apparatus and methods for content delivery and message exchange across multiple content delivery networks
KR20120091635A (ko) * 2011-02-09 2012-08-20 삼성전자주식회사 통신 시스템에서 인증 방법 및 장치
US9521108B2 (en) * 2011-03-29 2016-12-13 Intel Corporation Techniques enabling efficient synchronized authenticated network access
US9407506B2 (en) * 2011-09-12 2016-08-02 Microsoft Technology Licensing, Llc Multi-entity management
US9143937B2 (en) 2011-09-12 2015-09-22 Qualcomm Incorporated Wireless communication using concurrent re-authentication and connection setup
US8837741B2 (en) 2011-09-12 2014-09-16 Qualcomm Incorporated Systems and methods for encoding exchanges with a set of shared ephemeral key data
US9439067B2 (en) 2011-09-12 2016-09-06 George Cherian Systems and methods of performing link setup and authentication
CN102497378B (zh) * 2011-12-15 2015-03-18 杭州华三通信技术有限公司 为客户端动态选择dhcp服务器的方法和装置
CN104011699A (zh) 2011-12-16 2014-08-27 华为技术有限公司 用于同时进行地址分配和认证的系统和方法
US8725860B1 (en) 2011-12-22 2014-05-13 Infoblox Inc. Visualization for managing multiple IP address management systems
US8862725B1 (en) * 2011-12-22 2014-10-14 Infoblox Inc. Managing multiple IP address management systems
CN102752277A (zh) * 2012-02-28 2012-10-24 新奥特（北京）视频技术有限公司 一种信息分发系统的动态注册方法
US9565472B2 (en) 2012-12-10 2017-02-07 Time Warner Cable Enterprises Llc Apparatus and methods for content transfer protection
US20140282786A1 (en) 2013-03-12 2014-09-18 Time Warner Cable Enterprises Llc Methods and apparatus for providing and uploading content to personalized network storage
US10368255B2 (en) 2017-07-25 2019-07-30 Time Warner Cable Enterprises Llc Methods and apparatus for client-based dynamic control of connections to co-existing radio access networks
US9066153B2 (en) 2013-03-15 2015-06-23 Time Warner Cable Enterprises Llc Apparatus and methods for multicast delivery of content in a content delivery network
US9313568B2 (en) 2013-07-23 2016-04-12 Chicago Custom Acoustics, Inc. Custom earphone with dome in the canal
US9621940B2 (en) 2014-05-29 2017-04-11 Time Warner Cable Enterprises Llc Apparatus and methods for recording, accessing, and delivering packetized content
US11540148B2 (en) 2014-06-11 2022-12-27 Time Warner Cable Enterprises Llc Methods and apparatus for access point location
US9935833B2 (en) 2014-11-05 2018-04-03 Time Warner Cable Enterprises Llc Methods and apparatus for determining an optimized wireless interface installation configuration
US9794190B2 (en) 2015-02-16 2017-10-17 International Business Machines Corporation Managing asset deployment for a shared pool of configurable computing resources
US9986578B2 (en) 2015-12-04 2018-05-29 Time Warner Cable Enterprises Llc Apparatus and methods for selective data network access
US9918345B2 (en) 2016-01-20 2018-03-13 Time Warner Cable Enterprises Llc Apparatus and method for wireless network services in moving vehicles
US10492034B2 (en) 2016-03-07 2019-11-26 Time Warner Cable Enterprises Llc Apparatus and methods for dynamic open-access networks
US10164858B2 (en) 2016-06-15 2018-12-25 Time Warner Cable Enterprises Llc Apparatus and methods for monitoring and diagnosing a wireless network
US10645547B2 (en) 2017-06-02 2020-05-05 Charter Communications Operating, Llc Apparatus and methods for providing wireless service in a venue
US10638361B2 (en) 2017-06-06 2020-04-28 Charter Communications Operating, Llc Methods and apparatus for dynamic control of connections to co-existing radio access networks
EP3932044B1 (en) * 2019-02-28 2024-05-01 Telefonaktiebolaget Lm Ericsson (Publ) Automatic distribution of dynamic host configuration protocol (dhcp) keys via link layer discovery protocol (lldp)
US11956635B2 (en) 2022-01-20 2024-04-09 Hewlett Packard Enterprise Development Lp Authenticating a client device

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4352547B2 (ja) * 2000-01-04 2009-10-28 パナソニック株式会社 リモートアクセスサーバ装置
US7451312B2 (en) * 2000-03-07 2008-11-11 General Instrument Corporation Authenticated dynamic address assignment
JP2002033764A (ja) * 2000-07-14 2002-01-31 Fujitsu Ltd 通信サービス提供システム、並びに通信サービス提供システムにおいて使用される移動端末装置、アドレスサーバ装置、およびルータ装置
US6957276B1 (en) * 2000-10-23 2005-10-18 Microsoft Corporation System and method of assigning and reclaiming static addresses through the dynamic host configuration protocol
JP2003008622A (ja) * 2001-06-22 2003-01-10 Fujitsu Ltd サービス制御ネットワーク、及びそのサービス制御ネットワークにおいて使用されるルータ装置
US7389412B2 (en) * 2001-08-10 2008-06-17 Interactive Technology Limited Of Hk System and method for secure network roaming
US6973567B1 (en) * 2001-09-14 2005-12-06 Cisco Technology, Inc. Early authentication during modem training
JP2003318939A (ja) * 2002-04-22 2003-11-07 Canon Inc 通信システムおよびその制御方法
US7533160B2 (en) * 2003-02-18 2009-05-12 Qualcomm Incorporated Provisioning server information in a mobile station
EP1634425A1 (de) * 2003-06-18 2006-03-15 Siemens Aktiengesellschaft Verfahren und einrichtung zum bilden und entschlüsseln einer verschlüsselten nachricht mit kommunikations-konfigurationsdaten

Also Published As

Publication number Publication date
US20080282325A1 (en) 2008-11-13
GB0617265D0 (en) 2006-10-11
WO2005104500A1 (en) 2005-11-03
US7983418B2 (en) 2011-07-19
GB2429381A (en) 2007-02-21
GB2429381B (en) 2007-11-14
JP2007534267A (ja) 2007-11-22

Similar Documents

Publication Publication Date Title
JP4564054B2 (ja) Ｄｈｃｐ用サポート
RU2368086C2 (ru) Способ, система и устройство для поддержки услуги hierarchical mobile ip
US20060185013A1 (en) Method, system and apparatus to support hierarchical mobile ip services
KR100918440B1 (ko) 가상 사설망에서 게이트웨이의 ip 주소를 이용한 이동 단말의 통신 방법 및 장치
US9445272B2 (en) Authentication in heterogeneous IP networks
JP4723158B2 (ja) パケット・データ・ネットワークにおける認証方法
JP2006527968A (ja) Ｃｄｍａシステムで、モバイルｉｐバージョン６サービスをサポートするための方法、システム及び装置
JP5166524B2 (ja) 証明書処理のための方法および装置
KR100935421B1 (ko) 모바일 인터넷 프로토콜 키 분배를 위한 일반 인증아키텍처의 이용
US9686669B2 (en) Method of configuring a mobile node
US20030039234A1 (en) System and method for secure network roaming
WO2009152676A1 (zh) Aaa服务器、p-gw、pcrf、用户设备标识的获取方法和系统
WO2008086749A1 (fr) Système et procédé pour réaliser une inter-fusion de plusieurs types de réseaux de communication
KR20080053160A (ko) Ｐａｎａ 인증 방법 및 장치
CN100539586C (zh) 支持分级移动ip业务的方法、系统和设备
WO2008086747A1 (en) Mobile ip system and method for updating home agent root key
ES2616499T3 (es) Aparatos y método para autenticación en redes de IP heterogéneas
Hartman et al. Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
Hoeper Internet Engineering Task Force (IETF) S. Hartman, Ed. Request for Comments: 6677 Painless Security Category: Standards Track T. Clancy

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100305

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100507

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100726

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100729

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130806

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4564054

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees