JP4377409B2 - モバイルＩＰ（モバイルＩＰ：ＭｏｂｉｌｅＩＰ）バージョン６サービスをサポートするための方法、システム及び装置 - Google Patents

Description

技術分野
本発明は、一般的には、移動通信に関するものであり、より詳しくは、モバイルＩＰバージョン６サービスのサポートに関するものである。

背景
モバイルＩＰ（ＭＩＰ）は、最小限のサービス中断（disruption）で、移動ノードに、インターネットとの自身の接続ポイントを変更することを可能にする。ＭＩＰ自身では、異なる管理ドメインに渡る移動性（mobility）について専用のサポートは提供しない。これは、大規模の商用配備において、ＭＩＰの適用性を制限するものである。

モバイルＩＰバージョン６（ＭＩＰｖ６）プロトコル［１］は、ノードにインターネットトポロジー内での移動を可能にしながら、到達可能性を維持し、かつ対応するノードとの接続を継続する。この状況では、各移動ノードは、ＩＰｖ６インターネットとの自身の現在の接続ポイントに関係なく、常に自身のホームアドレスによって識別される。自身のホームネットワークから離れる状況では、移動ノードは気付アドレス（ＣｏＡ：care-of address）にも関連付けられている。これは、移動ノードの現在の位置についての情報を提供する。移動ノードのホームアドレスにアドレス指定されているＩＰｖ６パケットは、自身の気付アドレスに対して、多かれ少かれ透過的（トランスペアレント）に転送される。ＭＩＰｖ６プロトコルは、ＩＰｖ６ノードに、移動ノードのホームアドレスと自身の気付アドレスとのバインディング（binding：結合）をキャッシュして、その後、その気付アドレスへ、移動ノード宛てのパケットを送信することを可能にする。つまり、移動ノードは、移動する毎に、いわゆるバインディング更新を自身のホームエージェント（ＨＡ）と、それと通信する対応するノードに送信する。

ＭＩＰｖ６機能を有する移動ノードには、例えば、セルラー電話、ラップトップおよび他のエンドユーザ端末があり、これらは、自身のホームサービスプロバイダが属するネットワーク間ばかりでなくそれ以外のものとの間でローミングすることができる。外部（foreign）ネットワーク内でのローミングは、オペレータ間で存在するサービスレベルとローミングアグリーメント（協定）を受けて可能となる。ＭＩＰｖ６は、単一の管理ドメイン内でのセッション継続性を提供するが、これは、認証、認可及びアカウンティング（ＡＡＡ）インフラストラクチャの利用可能性に依存した上で、異なる管理ドメインに渡って自身のサービスセッションを提供する。即ち、ホームオペレータによって管理されるネットワークの外部のローミングの場合である。この種のローミングメカニズムを可能にすることに寄与する鍵となるＡＡＡプロトコルの１つには、Ｄｉａｍｅｔｅｒがある。

加えて、モバイルＩＰｖ６は、完全な移動性プロトコルとしてみなすことができるが、ＭＩＰｖ６の配備を容易にする、より多くのまた／あるいは改良されたメカニズムが、大規模配備を可能にするためにいまだなお必要とされている。これらのメカニズムは、実際のＭＩＰｖ６プロトコルの一部となってはいないが、ＭＩＰｖ６サービスの効果的な配備はこれらにかなり依存することになる。配備に関連するメカニズムは、例えば、ＭＩＰｖ６機能を有する移動ノード（ＭＮ）の初期のコンフィグレーション（configuration：構成）のような問題を扱うことになる。このコンフィグレーションには、ホームネットワークプレフィックスあるいはホームアドレス、ホームエージェントアドレス及び必要とされるＩＰｓｅｃ ＳＡ群あるいは動的に確立されたＩＰｓｅｃ ＳＡ群に基づかせることができる場合のセキュリティパラメータのようなコンフィグレーションデータを含んでいる。配備に関連するメカニズムに対する１つのアプローチは、既存のＡＡＡインフラストラクチャを活用することである。

［２］では、例えば、ホームドメイン以外のネットワークでのＭＩＰｖ６ローミングを容易にするＤｉａｍｅｔｅｒへ新規のアプリケーションを指定するための試行がなされている。この文献は、ＭＮとネットワーク内のＡＡＡクライアント間での情報の交換が典型的には必要であることを確認していて、この情報には、ＭＩＰ特性データ、ＥＡＰデータ、セキュリティキーデータ及び埋込データがある。ＡＡＡクライアントとＡＡＡｖ（訪問先ＡＡＡサーバ）間、ＡＡＡｖとＡＡＡｈ（ホームＡＡＡサーバ）間、及びＨＡとＡＡＡインフラストラクチャ間での情報の交換に、新規のＤｉａｍｅｔｅｒアプリケーションを使用することも提案している。［２］は、移動ノードとＡＡＡクライアント案の通信に対しては、特別のメカニズムは特定しないが、ＰＡＮＡプロトコル［３］の使用の可能性については言及している。しかしながら、ＰＡＮＡ ＷＧは、ＰＡＮＡの範囲を定義しているものの、言及されているＭＩＰｖ６関連情報を送信すること可能にするものではない。このことは、このソリューションを不十分で完全でないものとしている。

［２］におけるソリューションの別の問題は、認証方法を理解し、かつＭＮとＡＡＡｈ間での交換するものの内容（ＭＩＰ特性データ、ＥＡＰデータ、セキュリティキーデータ及び埋込データ）を知るには、ＡＡＡクライアント（及びＡＡＡｖ）を必要とすることである。このようなソリューションを用いると、ＭＮとＡＡＡｈ間で前もって暗号化を適用することができず、また、この交換は、エアインタフェースを介して視認されることになる。これは、盗聴に対するセキュリティ、中間者及びその他の攻撃にさらされる可能性がある。

［２］のソリューションの更に別の問題は、アクセスネットワーク内と、ＡＡＡｖ内の両方のメカニズムに対するサポートを必要とすることである。これは、ソリューションの配備の妨げになる可能性がある、なぜなら、それを使用することを要望するオペレータは、そのソリューションをサポートするためには、自身のネットワークをアップグレードするためのローミングパートナに依存することになるからである。

従って、従来の移動性ソリューションは、いくつかの問題に関わっていて、ＭＩＰｖ６をサポートする満足のいくメカニズムの必要性が残存している。

要約
本発明の一般的な目的は、ＭＩＰｖ６の認証及び認可をサポートするための改良されたメカニズムを提供することである。特別な目的は、高いセキュリティを維持しながら、外部（foreign）ネットワークに容易にローミングすることである。別の目的は、移動ノードとホームエージェントのコンフィグレーションを簡単にすることによって、ＭＩＰｖ６の配備を容易にすることである。更に別の目的は、訪問先ドメインに対して完全かつトランスペアレントとなるＭＩＰｖ６サポートについてのメカニズムを提供することである。

これらの目的は、請求項に従って達成される。

簡単に言えば、本発明の方法は、外部ネットワークへ訪問する移動ノードと、その移動ノードのホームネットワーク間でのＡＡＡインフラストラクチャを介する、エンドツーエンド（end-to-end：端末間）処理において、ＭＩＰｖ６関連情報を送信することによって、ＭＩＰｖ６用の認証及び認可のサポートを達成する。ＭＩＰｖ６関連情報は、通常、ＡＡＡインフラストラクチャを介して送信される、認証、認可及びコンフィグレーション情報の少なくとも１つを有する。このＡＡＡインフラストラクチャは、移動ノードとホームエージェントのコンフィグレーションを簡単にするためのものである。あるいは、移動ノードと、ホームネットワークあるいは訪問先ネットワーク内のどちらかに配置されるホームエージェント間でのＭＩＰｖ６セキュリティアソシエーションを確立するためのものである。エンドツーエンド機能（end-to-end feature）は、ＡＡＡインフラストラクチャを介して搬送される認証プロトコルによって達成される。認証プロトコルは、拡張認証プロトコルであることが好ましいが、完全に新規に定義されるプロトコルを使用することもできる。

本発明の実施形態は、拡張認証プロトコルに対する基礎として、拡張可能認証プロトコル（ＥＡＰ）を使用する。これは、典型的には、ＥＡＰ下位レイヤ（群）を維持しながら、ＥＡＰ拡張を生成する。これは、通常、ＭＩＰｖ６関連情報がＥＡＰプロトコルスタック内の追加データとして組み込まれることを意味する。この追加データは、例えば、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性である。あるいは、これは、ＥＡＰレイヤあるいはＥＡＰメソッドレイヤ上の汎用コンテナで送信されるＥＡＰ属性である。

本発明によれば、完全なＭＩＰｖ６ＡＡＡソリューションが初めて達成される。一方、従来技術では、互いに首尾一貫しない部分的なソリューションのみが存在している。また、ＥＡＰ拡張のような認証プロトコル拡張に依存することは、合理化されたソリューションを提供し、これは、後方互換性問題を最小限にして管理可能であり、かつ的確である。ＥＡＰの使用は、ＡＡＡクライアント（及びＡＡＡｖ）に、ＭＩＰｖ６処理について不可知（agnostic）とすることを可能にし（即ち、これは、訪問先ネットワークでのＭＩＰｖ６サポートについての依存性を解消する）、また、単なるパススルーエージェント（群）として動作することを可能にする。この状況は、ＨＡがホームネットワーク内に存在する場合が少なくとも含まれる。換言すれば、提案されるＭＩＰｖ６認証／認可ソリューションは、訪問先ドメインに対してトランスペアレントであり、これは、ＥＡＰのようなプロトコルを使用することについての大きな利点の１つとなる。これは、ＭＮとＡＡＡｈ間での事前の暗号化を適用することを可能にし、これによって、ＭＩＰｖ６を用いて外部ネットワークでローミングする際のセキュリティを満足なものにする。加えて、オペレータに対して、自身のローミングパートナのネットワーク内の更新に依存することなく、このソリューションを展開することを可能にする。

本発明に従えば、移動ノードのＭＩＰｖ６専用コンフィグレーションと、ホームエージェントの移動ノード専用コンフィグレーションを解消するあるいは簡略化することで、ＭＩＰｖ６の配備を更に容易にすることができる。このようなコンフィグレーションは、汎用的な認証の一部であり、また、例えば、ホームネットワークプレフィックスあるいはホームアドレスと、ホームエージェントアドレスと、動的に確立されるセキュリティリレーション（例えば、ＩＰｓｅｃ ＳＡ群）が基づくことができる必要なＩＰｓｅｃ ＳＡ群あるいはセキュリティパラメータを含んでいても良い。

本発明の他の構成に従えば、ＭＩＰｖ６サポート用のシステムとＡＡＡｈサーバが提供される。

詳細説明
このセクションの後に、本明細書で使用される略語を示す。

背景セクションで言及されるように、従来技術では、ＭＩＰｖ６の認証及び認可の少なくとも一方をサポートするための完全なソリューションは提供されていない。また、［２］の従来のメカニズムは、認証方法を理解し、かつＭＮとＡＡＡｈ間でのＭＩＰｖ６関連データの交換の内容をするために、ＡＡＡクライアントとＡＡＡｖを必要とする。このようなソリューションを用いると、ＭＮとＡＡＡｈ間で前もって暗号化を適用することができず、また、この交換は、エアインタフェースを介して視認されることになる。これは、盗聴、中間者攻撃及びその類について脆弱性が高いシステムを構成することになる。

これら及びその他の問題は本発明によって解決される。これは、ＡＡＡインフラストラクチャを介して、外部ネットワークに訪問している移動ノードと、移動ノードのホームネットワーク間でのエンドツーエンド処理で、ＭＩＰｖ６関連情報を送信することによって達成される、ＭＩＰｖ６に対する認証及び認可のサポートに従うものである。ＭＩＰｖ６関連情報は、認証、認可及びコンフィグレーション情報の少なくとも１つを含むことが好ましく、これらは、即時あるいは将来のＭＩＰｖ６セキュリティアソシエーション（即ち、セキュリティリレーション）を確立するために、あるいは移動ノードとホームエージェント間をバインディングするために、ＡＡＡインフラストラクチャを介して送信される。エンドツーエンドの構成は、新規のあるいは拡張認証プロトコルによって達成され、これは、訪問先ドメインに対してトランスペアレントとなる方法で動作する。

本発明に従えば、最も有効な方法で、ＭＩＰｖ６の端末移動性と、ユーザ認証及び認可（典型的には、ＡＡＡ）を組み合わせるために、ＡＡＡインフラストラクチャを介して搬送される認証プロトコルが提案される。これによって、完全なＭＩＰｖ６ ＡＡＡソリューションが達成される。従来技術では、これらは、互いに首尾一貫しない部分的なソリューションのみが存在している。

ＭＮと、ホームネットワーク内のＡＡＡサーバ間でのエンドツーエンドプロトコルを使用することによって、本発明は、訪問先ドメインに対してトランスペアレントとなるＭＩＰｖ６ ＡＡＡソリューションを生成する。この訪問先ドメインには、アクセスネットワーク、訪問先ネットワーク内のＡＡＡクライアントとＡＡＡサーバ、及び他の取り得る中間ＡＡＡサーバが含まれる。これは、ＡＡＡクライアントに、例えば、単なるパススルーエージェントとして動作させることを可能にする。このことは、かなりの利点となる。また、これは、ＭＮとＡＡＡｈ間（例えば、ＥＡＰ／ＴＴＬＳ［４］）で前もって暗号化を適用することを可能にする。これは、交換がエアインタフェースを介して可視される（visible）ことはないからである。これは、盗聴、中間者及び他の攻撃に対する満足なセキュリティを、外部ネットワーク内でローミングする移動ノードに対して維持することができることを意味する。

図８は、本発明の実施形態に従うＡＡＡホームネットワークサーバのブロック図である。この例では、ＡＡＡｈサーバ３４は、基本的には、ホームアドレス割当モジュール５１、ホームエージェント（ＨＡ）割当モジュール５２、セキュリティアソシエーションモジュール５３、認可情報マネージャ５４及び入力−出力（Ｉ／Ｏ）インタフェース５５を備えている。モジュール５１は、ホームアドレス割当を実行することが好ましい（ホームアドレスが、移動ノードにおいて構成され、かつＨＡに送信されない限り）、モジュール５２は、適切なホームエージェント（ＨＡ）の割当及び再割当の少なくとも一方を行うために動作可能である。ＡＡＡｈサーバ３４は、典型的には、移動ノードから、キーシード及びバインディング更新（ＢＵ）も受信する。選択的には、ＡＡＡｈサーバ３４は、キーシード自身を生成し、それを移動ノードへ送信する。セキュリティアソシエーションモジュール５３は、シードに応じて必要なセキュリティキーを生成し、かつそのキーを安全にＨＡへ送信することが好ましい。バインディング更新（ＢＵ）は、ホームエージェント（ＨＡ）へも送信され、そうすることで、ＨＡは、移動ノードの気付アドレス（care-of address）とホームアドレスとのバインディングをキャッシュすることができる。ＡＡＡｈサーバは、ＩＰＳｅｃ情報のような情報を、セキュリティアソシエーションを完成するためにＨＡから受信しても良い。この情報とともに、他の収集された認可（及び／あるいはコンフィグレーション）情報は、移動ノードへの次の送信のために、オプションの認証情報マネージャ５４に記憶されても良い。

認可フェーズは、通常、明示的な認可を含んでいるが、介在するノードのコンフィグレーションを含んでいても良い。それゆえ、例えば、移動ノードのコンフィグレーション及びＨＡのコンフィグレーションの少なくとも一方の、ＭＩＰｖ６関連コンフィグレーションは、通常、全体の認可処理の一部としてみなされる。

用語「ＡＡＡ」は、インターネットドラフト、ＲＦＣ及び他の標準化文献での、それ自身の一般的な意味の範疇にあるとされるべきである。典型的には、ＡＡＡ（認可、認証及びアカウンティング）インフラストラクチャの、認証及びセキュリティキーアグリーメントは、対称暗号技術に基づいていて、これは、移動ノードと、ホームネットワークオペレータあるいは信用機関の間で共有される初期シークレットが存在することを意味するものである。いくつかの状況及び用途では、例えば、ＡＡＡインフラストラクチャのアカウンティング機能は、無効にされるあるいは実現されない場合がある。ＡＡＡインフラストラクチャは、一般的には、１つ以上のＡＡＡサーバを、ホームネットワーク及び訪問先ネットワークの少なくとも一方に含んでいて、また、１つ以上のＡＡＡクライアントを含んでいても良い。オプションとしては、ＡＡＡインフラストラクチャに含まれる１つ以上の中間ネットワークを存在させることもできる。

本発明は、拡張／変形されたバージョンの、予め定義された認証プロトコルを、ＭＩＰｖ６関連データを送信する認証プロトコルの基準として使用し、以下では、これについて、このような拡張プロトコルで主に例示する。それでもなお、一から構築される認証プロトコルも、本発明の範囲内に入ることが強調されるべきである。

本発明の実施形態は、ＥＡＰに基づく拡張認証プロトコルを使用し、これは、典型的には、ＥＡＰの下位のレイヤ（群）を維持しながらＥＡＰ拡張を生成する。このことは、典型的には、１つ以上の新規のＥＡＰ属性（群）によって、ＭＩＰｖ６関連情報がＥＡＰプロトコルスタックの追加のデータとして組み込まれることを通常、意味する。このようなＥＡＰ属性を実現するための別のソリューションについては、「メソッド−専用ＥＡＰ属性」及び「汎用コンテナ属性」のセクションで説明する。これの前に、ＡＡＡインフラストラクチャを介して、拡張認証プロトコルを搬送するプロトコルソリューションのいくつかの例を、「搬送プロトコル例」のセクションで説明する。基本的には、図１で示されるＭＩＰｖ６ ＡＡＡ関係者（actors）及びアーキテクチャを参照する。

搬送プロトコル例
例えば、拡張認証プロトコル（例えば、拡張ＥＡＰ）は、ＭＮ（ＰＡＣ）１０とＡＡＡクライアント（ＰＡＡ）２２間、即ち、図１の（Ｉ）で、ＰＡＮＡによって搬送される。選択的には、満足のいく下位レイヤの順序付けの保障に関連する他の搬送プロトコル、例えば、ＰＰＰとＩＥＥＥ８０２．Ｘ［５］が、ＭＮとＡＡＡクライアント間の拡張認証プロトコルを搬送するために使用されても良い。３ＧＰＰ２ ＣＤＭＡ２０００システムに対しては、代わりとして、ＥＡＰ［６］に対してＣ２２７（１６進数）が設定されているプロトコルフィールド値を持つＰＰＰデータリンクレイヤプロトコルカプセル化を使用することができる。

本実施形態は、訪問先ネットワーク／ドメイン２０内のＡＡＡｖサーバ２４を介して、ＡＡＡクライアント２２とホームネットワーク／ドメイン３０の移動ノード１０内のＡＡＡサーバ３４間（ＩＩ、ＩＩＩ）の通信に対して、ＤｉａｍｅｔｅｒアプリケーションのようなＡＡＡフレームワークプロトコルアプリケーションを使用する。一実施形態は、ＤｉａｍｅｔｅｒＥＡＰアプリケーション［７］を使用して、ＡＡＡクライアントを経由してＤｉａｍｅｔｅｒ内で、かつＡＡＡインフラストラクチャ内で、典型的には、ＡＡＡクライアントとＡＡＡｈ間で、拡張認証プロトコルをカプセル化する。また、Ｄｉａｍｅｔｅｒプロトコルは、フィルタ実行ポイントに対応するＭＩＰフィルタルールを介する、オプションのＭＩＰパケットフィルタのＰＡＡ／ＥＰ及びＨＡへの割当ために、また、ＰＡＮＡセキュリティためのＰＡＡへのセキュリティキーの配信のために、及びオプションのＱｏＳパラメータのシグナリング（信号送受信）等のために、ＤｉａｍｅｔｅｒプロトコルがＡＡＡｈによって使用することができる。

Ｄｉａｍｅｔｅｒは設計事項であるとしても、時には、代わりに、別のＡＡＡフレームワークプロトコルアプリケーション、例えば、ＩＩ及びＩＩＩの少なくとも一方を介して、拡張認証プロトコルを搬送するためのＲＡＤＩＵＳ［８、９］の代わりに使用しても良いことに注意すべきである。

例えば、セキュリティキーを交換して、ＨＡとＭＮ１０間でのセキュリティアソシエーションＳＡを確立するための、ホームネットワーク内のＨＡ３６とＡＡＡインフラストラクチャ間（ＩＶ）での通信については、２つの可能性が考えられる。１つには、ＡＡＡフレームワークプロトコルアプリケーションを、ＩＶを介してＭＩＰｖ６データを送信するために利用できる。これについては、ＤｉａｍｅｔｅｒＭＩＰｖ４アプリケーション［１０］で特定されるＡＡＡｈ−ＨＡインタフェースプロトコルを、例えば、使用することができる。以下で説明されるように、拡張あるいは新規のＤｉａｍｅｔｅｒアプリケーション、あるいは新規の属性で拡張されたＲＡＤＩＵＳが、ＡＡＡｈ３４とＨＡ３６間でのＡＡＡとＭＩＰｖ６データの交換のために使用される実施形態は、本発明の範囲に含まれる。２つには、ＩＫＥフレームワーク［１２］を伴う現在の３ＧＰＰ２ソリューション［１１］と同様のメカニズムは、ＭＮ１０とＨＡ３６間での動的に前もって共有されるキーを配信するために使用することができる。次に、ＨＡ−ＭＮ事前共有キーをＡＡＡｈ３４から検索するあるいは生成するために、キーＩＤがＨＡによって使用される。このキーＩＤは、ＭＮに送信される認証の成功に応じてＡＡＡｈによって生成され、ＭＮは、それをＩＫＥを使用するＨＡへ送信する（図１の通信経路Ｖ）。

図１を更に参照して、本発明に従うＭＩＰｖ６サポートに対する、ＭＮ−ＡＡＡクライアント−ＡＡＡｖ−ＡＡＡｈ−ＨＡのセグメント間のプロトコルの組み合わせ例を、表１にまとめる。

例えば、暗号化及びソース完全性保護のようなセキュリティ対策は、セキュリティキー（群）のような機密情報の送信用に利用されるものと想定する。

メソッド専用ＥＡＰ属性
本発明の一実施形態に従えば、ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性として送信される。新規の（拡張）ＥＡＰ認証プロトコルは、ＭＩＰｖ６認証に対するメソッドを搬送するために定義される。拡張ＥＡＰプロトコルは、ＭＩＰｖ６認証のネゴシエーション／実行を可能にしなければならず、また、いくつかの補助情報をサポートしても良い。この補助情報は、例えば、動的ＭＮホームアドレス割当、動的ＨＡ割当、ＨＡとＭＮ間でのセキュリティキーの配信、ＰＡＮＡセキュリティ用に、ＰＡＣとＰＡＡ間でのセキュリティキーの配信を容易にする。

新規のＥＡＰ属性は、例えば、新規のＥＡＰ ＴＬＶ属性とすることができ、また、例示するプロトコルの詳細を、全体フロー及び概念の実行可能性を示すために提供する。

以下のＥＡＰ−ＴＬＶは、新規のＥＡＰ ＴＬＶの例であり、これらは本発明の拡張ＥＡＰプロトコルの下で定義することができる。

i） MD5チャレンジEAP-TLV属性
（MD5 Challenge EAP-TLV attribute）
ii） MD5応答EAP-TLV属性
（MD5 Response EAP-TLV attribute）
iii） MIPv6ホームアドレスリクエストEAP-TLV属性
（MIPv6 HomeAddress Request EAP-TLV attribute）
iv） MIPv6ホームアドレス応答EAP-TLV属性
（MIPv6 HomeAddress Response EAP-TLV attribute
v） MIPv6ホームエージェントアドレスリクエストEAP-TLV属性
（MIPv6 Home Agent Address Request EAP-TLV attribute）
vi） MIPv6ホームエージェントアドレス応答EAP-TLV属性
（MIPv6 Home Agent Address Response EAP-TLV attribute）
vii） HA-MN事前共有キー生成ナンスEAP-TLV属性
（HA-MN Pre-shared Key Generation Nonce EAP-TLV attribute）
viii） IKEキーID EAP-TLV属性
（IKE KeyID EAP-TLV attribute）
ix） HA-MN IPSec SPI EAP-TLV属性
（HA-MN IPSec SPI EAP-TLV attribute）
x） HA-MN IPSecキー期限EAP-TLV属性
（HA-MN IPSec Key Lifetime EAP-TLV attribute）
xi） PAC-PAA事前共有キー生成ナンスEAP-TLV属性
（PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute）
xii） MIPv6ホームアドレスEAP-TLV属性
（MIPv6 Home Address EAP-TLV attribute）
xiii） HA-MN事前共有キーEAP-TLV属性
（HA-MN Pre-shared Key EAP-TLV attribute）
xiv） HA-MN IPSecプロトコルEAP-TLV属性
（HA-MN IPSec Protocol EAP-TLV attribute）
xv） HA-MN IPSec Crypto EAP-TLV属性
（HA-MN IPSec Crypto EAP-TLV attribute）
xvi） MIP-バインディング-更新 EAP-TLV属性
（MIP-Binding-Update EAP-TLV attribute）
xvii） MIP-バインディング-応答確認EAP-TLV属性
（MIP-Binding-Acknowledgement EAP-TLV attribute）
これらの属性（のサブセットあるいはすべて）によって、ＥＡＰプロトコルは、メインのＩＰｖ６認証情報に加えて、ＭＩＰｖ６関連補助情報を搬送することができる。これは、顕著な利点となる。ＭＩＰｖ６関連補助情報は、例えば、動的ＭＮホームアドレス割当、動的ホームエージェント割当用のリクエスト、これに加えて、必要なセキュリティキーの生成用のナンス／シードを備えることができる。

本発明に従う拡張ＥＡＰプロトコルの認証メカニズムは、例えば、ＭＤ５−チャレンジ認証を使用することができるが、他のタイプのプロトコルも本発明の範囲に含まれる。以下のＥＡＰ−ＴＬＶ属性は、ＭＤ−５チャレンジ認証を介して実現する場合のＭＩＰｖ６認証について定義することができる。

i) MD5 Challenge EAP-TLV属性：
これは、ＡＡＡｈによってランダムに生成され、かつＭＤ５チャレンジ（Challenge）に対するＭＮへ送信されるオクテットストリングを示している。

ii) MD5 Response EAP-TLV属性：
これは、ＡＡＡｈとＭＮ間の共有シークレットキーを用いるＭＤ５ハッシュ関数の結果として生成されるオクテットストリングを示している。

動的ＭＮホームアドレス割当を容易にするＭＩＰｖ６関連情報が送信対象である場合、以下のＥＡＰ−ＴＬＶ属性を、例えば、定義することができる。

iii) MIPv6 Home Address Request EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスに対するリクエストを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＭＮによってＡＡＡｈからリクエストされる。このＥＡＰ属性は、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているホームアドレスを持っている場合のオプションの属性として通常定義される。

iV) MIPv6 Home Address Response EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスを示している。これは、ホームアドレスをリクエストしているＭＮが、認証に成功している場合に、ＡＡＡｈからＭＮへ通知される。この属性は、通常、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているホームアドレスを持っている場合のオプションである。

動的ＨＡ割当に対しては、以下の例のＥＡＰ−ＴＬＶ属性を使用することができる。

v) MIPv6 Home Agent Address Request EAP-TLV属性：
これは、認証が成功している場合に、ＭＮに対して、動的に割り当てられるＨＡのアドレスに対するリクエストを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＭＮによってＡＡＡｈからリクエストされる。ＨＡ割当が既に存在する場合、例えば、ＭＩＰｖ６プロトコルの動的ＨＡ探索方法がＨＡを割り当てるために使用される場合、あるいはＭＮが既に、予め割り当てられたＨＡ（例えば、ＭＩＰｖ６ハンドオフ中）を持っている場合、この属性は、通常、オプションとして定義される。

vi) MIPv6 Home Agent Address Response EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＨＡのアドレスを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＡＡＡｈからＭＮへ通知される。ＭＩＰｖ６プロトコルは、ホームエージェント割当用の動的ホームエージェント探索方法を持っているので、この属性は通常オプションとなる。これは、例えば、ＭＩＰｖ６ハンドオフ中に、ＭＮが既に、事前に割当られているＨＡを持っている場合も同様である。

以下の属性の例は、ＥＡＰ−ＴＬＶ属性を、ＨＡとＭＮ間でのセキュリティキーの配信用に定義することができる。

vii) HA-MN Pre-shared Key Generation Nonce EAP-TLV属性：
ＨＡ−ＭＮ間の事前共有キーを生成するためのシードとする、ＭＮによってランダムに生成されるオクテットストリングを示している。ＭＮは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＨＡ−ＭＮ事前共有キーを生成することができる。この属性は、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合に通常オプションとなる。

viii) IKE KeyID EAP-TLV属性：
これは、［１３］で定義されるＩＤペイロードを示している。Ｋｅｙ（キー）ＩＤは、ＡＡＡｈによって生成され、そして、認証が成功しているＭＮに送信される。ＫｅｙＩＤは、いくつかのオクテットを含み、これは、どのようにしてＡＡＡｈから、ＨＡ−ＭＮ事前共有キーを検索（あるいは生成）するかについてを、ＨＡへ通知する。この属性は、典型的には、オプションとして定義され、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、ＨＡ−ＭＮ事前共有キーが、［１０］で定義されるＡＡＡｈ−ＨＡインタフェースを介して（あるいは、例えば、上述の「搬送プロトコル例」で説明される任意の他のプロトコルを使用して）、ＡＡＡｈによってＨＡに搬送される場合にも必要とされない。

ix) HA-MN IPSec SPI EAP-TLV属性：
これは、ＨＡとＭＮ間のＩＰＳｅｃに対するセキュリティパラメータインデックス（Security Parameter Index）を示している。この属性は、ＨＡによって生成され、かつ、ＨＡ−ＭＮ事前共有キーが、［１０］で定義されるＡＡＡｈ−ＨＡインタフェースを介して（あるいは、例えば、上述の「搬送プロトコル例」で説明される任意の他のプロトコルを使用して）、ＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、典型的にはオプションとして定義され、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、ＡＡＡｈ−ＨＡインタフェースが使用されない場合も必要とされない。

x) HA-MN IPSec Key Lifetime EAP-TLV属性：
これは、ＨＡとＭＮ間のＩＰＳｅｃに対するキー期限を示している。この属性は、ＨＡによって生成され、かつ、ＨＡ−ＭＮ事前共有キーが、［１０］で定義されるＡＡＡｈ−ＨＡインタフェースを介して（あるいは、例えば、上述の「搬送プロトコル例」で説明される任意の他のプロトコルを使用して）、ＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、典型的にはオプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。これは、典型的には、ＡＡＡｈ−ＨＡインタフェースが使用されない場合も必要とされない。

ＭＮとＡＡＡクライアント間で拡張ＥＡＰプロトコルを搬送するために、ＰＡＮＡが使用される場合、以下の例のＥＡＰ−ＴＬＶ属性を、ＭＮ／ＰＡＣと、ＰＡＮＡセキュリティ用のＡＡＡクライアント／ＰＡＡ間でのセキュリティキー配信のために定義することができる。

xi) PAC-PAA Pre-shared Key Generation Nonce EAP-TLV属性：
これは、ＭＮ／ＰＡＣと、ＡＡＡクライアント／ＰＡＡ間の事前共有キーを生成するためのシードとする、ＭＮ／ＰＡＣによってランダムに生成されるオクテットストリングを示している。ＭＮ／ＰＡＣは、このナンス（nonce）と、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＰＡＣ−ＰＡＡ事前共有キーを生成することができる。この属性によって、満足のゆくＰＡＮＡセキュリティを達成することができる。

最後に、以下のオプションのＥＡＰ−ＴＬＶ属性は、専用のＭＩＰｖ６目的のために定義されても良い。

xii) MIPv6 Home Address EAP-TLV属性：
これは、認証済ＭＮに対して、動的に割り当てられるＭＩＰｖ６ホームアドレスを示している。これは、あるものにリクエストを行っているＭＮが、認証に成功している場合に、ＨＡ内のＭＩＰｖ６ホームアドレスを割り当てるために、ＡＡＡｈからＨＡへ通知される。

xiii) HA-MN Pre-shared Key EAP-TLV属性：
これは、ＨＡ−ＭＮ間で動的に生成される事前共有キーを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮがリクエストする場合に、ＡＡＡｈからＨＡへ通知される。ＡＡＡｈは、HA-MN Pre-shared Key Generation Nonce EAP-TLV属性によって与えられるナンスと、ＭＮとＡＡＡｈ間の共有キーの組み合わせにおいて、適切なハッシュアルゴリズムを使用することによって、内部的に、ＨＡ−ＭＮ事前共有キーを生成することができる。この属性は、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合のオプションである。

xiv) HA-MN IPSec Protocol EAP-TLV属性：
これは、ＨＡ−ＭＮ間のＩＰＳｅｃプロトコル（例えば、ＥＳＰあるいはＡＨ）を示している。これは、ＨＡ−ＭＮ事前共有キーがＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。

xv) HA-MN IPSec Crypto EAP-TLV属性：
これは、ＨＡ−ＭＮ間のＩＰＳｅｃに対する暗号化アルゴリズムを示している。これは、ＨＡ−ＭＮ事前共有キーがＡＡＡｈによってＨＡに搬送される場合にＭＮに通知される。この属性は、オプションであり、かつ、ＭＮがＨＡ−ＭＮ事前共有キー生成ナンス（HA-MN pre-shared key generation nonce）を提示しない場合、即ち、例えば、ＭＩＰｖ６ハンドオフ中に、有効なＨＡ−ＭＮ事前共有キーが既に存在している場合には、通常必要とされない。

xvi) MIP-Binding-Update EAP-TLV属性：
これは、ＭＮによって生成されるバインディング更新パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＭＮからＨＡへ転送される。この属性は、オプションであり、かつ、ＭＮがバインディング更新パケットを直接ＨＡへ送信する場合には、通常必要とされない。

xvii) MIP-Binding-Acknowledgement EAP-TLV属性：
これは、ＨＡによって生成されるバインディング応答確認パケットを示している。これは、認証及び認可の交換時に、ＡＡＡｈを介して、ＨＡからＭＮへ転送される。この属性は、オプションであり、かつ、ＨＡがバインディング応答確認パケットを直接ＭＮへ送信する場合には、通常必要とされない。

ＭＩＰｖ６関連情報の送信用に例示されるＥＡＰ−ＴＬＶの総括構成（summary matrix）を表２に示す。

本発明に従う、ＭＩＰｖ６の開始及びハンドオフを処理するためのスキーム例が、図２、図３、図４のシグナリング（信号送受信）フロー図で提供される。ＭＮ、ＡＡＡクライアント、ＡＡＡｈ及びＨＡ間で、上述で例示のＥＡＰ ＴＬＶ属性を使用して実現されるＭＩＰｖ６関連情報の送信が示されている。用語「ＥＡＰ／ＭＩＰｖ６」は、ここでは、新規の拡張ＥＡＰプロトコルを意味するものであり、本発明の実施形態では、ＡＡＡインフラストラクチャを介して、ＭＩＰｖ６関連情報を送信するために使用される。図示の例は、搬送プロトコルとして、ＰＡＮＡとＤｉａｍｅｔｅｒの組み合わせを使用するＭＩＰｖ６ ＡＡＡに関するものである。図２のフロー図は、ＨＡ−ＭＮ事前共有キーの交換のために、［１０］に従うＡＡＡｈ−ＨＡインタフェースを使用するＭＩＰｖ６の開始を示している。図３に示される、ＭＩＰｖ６の開始メカニズムの別の実施形態は、ＨＡ−ＭＮ事前共有キーの交換のために、ＩＫＥキーＩＤを使用する。図４のシグナリングフローは、本発明の実施形態に従うＭＩＰｖ６ハンドオフを示している。

汎用コンテナ属性
本発明の別の実施形態では、ＭＩＰｖ６関連情報は、汎用コンテナＥＡＰ属性で搬送される。これは、任意のＥＡＰパケットに含まれる任意のＥＡＰメソッドとともに使用できることが好ましい。つまり、ＥＡＰは、汎用コンテナ属性（ＧＣＡとも呼ばれる）で増やされる（augmented）。この汎用コンテナ属性は、非ＥＡＰ関連データ、より詳しくは、ＭＩＰｖ６専用データを、ＭＮ１０とＡＡＡｈ３４間で搬送するために使用することができる。これは、ＭＮとＡＡＡｈに、アクセスネットワーク、ＡＡＡクライアント及びＡＡＡｖ２４を含む訪問先ドメイン２０に対してトランスペアレントとなる方法で通信することを可能にする。つまり、メソッド専用ＥＡＰ−ＴＬＶ属性での場合で上述されたように、ＡＡＡインフラストラクチャは、訪問先ドメインに対してトランスペアレントとなる方法で、ＭＩＰｖ６関連機能をサポートするために利用される。このソリューションは、例えば、ホームネットワーク（ホームネットワークプレフィックスを含む）内での動的ＨＡ割当、ＭＮ−ＨＡ信用証明の配信、ＭＩＰｖ６メッセージカプセル化、ネットワークアクセスとＭＩＰｖ６用の単一の認証エンティティ、及びステートフル（stateful：状態把握による）動的ホームアドレス割当の少なくとも１つをサポートすることができる。

汎用コンテナ属性を使用する場合、新規のＥＡＰメソッドを生成することなく、ＥＡＰを、ＭＩＰｖ６関連データのキャリヤとして使用することが好ましい。しかしながら、別の変形は、プロトコルスタックのメソッドレイヤ上の１つ（あるいはそれ以上）のＥＡＰメソッド（群）に汎用コンテナ属性を導入することである。これによって、ＭＩＰｖ６関連データの送信用の新規のＥＡＰメソッドが定義され、かつ汎用コンテナ属性がこの新規のＥＡＰメソッドに対してのみ使用される。換言すれば、汎用コンテナ属性は、ＥＡＰ ＴＬＶ属性に関係して説明される方法と同様の方法で、メソッド専用とすることができる。

上述のように、ＥＡＰは、ＡＡＡフレームワークプロトコルで、ＡＡＡクライアント２２とＡＡＡｈ３４間を搬送されることが好ましい。このＡＡＡフレームワークプロトコルは、例えば、Ｄｉａｍｅｔｅｒ ＥＡＰアプリケーション［７］あるいはＲａｄｉｕｓ［８］、［９］がある。しかしながら、ＡＡＡｈ３４とＨＡ３６間でＡＡＡ及びＭＩＰｖ６データを交換するために、新規の／拡張Ｄｉａｍｅｔｅｒアプリケーション（あるいは新規の属性で拡張されたＲＡＤＩＵＳ）を使用することも提案される。このＤｉａｍｅｔｅｒアプリケーションは、既存のＤｉａｍｅｔｅｒの拡張バージョン、例えば、Ｄｉａｍｅｔｅｒ ＥＡＰアプリケーション［７］、あるいは新規のＤｉａｍｅｔｅｒアプリケーションとすることができる。この新規の／拡張Ｄｉａｍｅｔｅｒアプリケーション（あるいは、拡張ＲＡＤＩＵＳ）は、以下では、「Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーション」と呼ぶことにする。これは、説明を簡単にするためだけに使用されるものであり、また、拡張ＲＡＤＩＵＳあるいは、セクション「搬送プロトコル例」で上述されるメカニズムを含むＡＡＡｈ−ＨＡ通信用の他の方法の使用を除外するものではないことが強調されるべきである。

ホームエージェントとホームアドレスの割当を含み、本発明に従う汎用コンテナ属性を使用する認証処理を扱う好適な方法を、主に、例として図１で参照するＥＡＰプロトコルを使用して説明する。

認証処理中には、ＭＮ１０は、自身がホームネットワーク３０で割り当てられるＨＡ３６を持ちたいことを、汎用コンテナ属性を介してＡＡＡｈ３４に指示する。ここでは、想定することとして３つの場合が存在する。

Ａ）ＭＮが、既に、有効なホームアドレスを持っている。

Ｂ）ステートフル動的ホームアドレス割当が使用されている。

Ｃ）ステートフルホームアドレス自動コンフィグレーションが使用されている。

ＭＮ１０が既にホームアドレスを持っている場合（Ａ）、ホームエージェントアドレス用のリクエストとともにそれがＡＡＡｈ３４に送信される。ＡＡＡｈがホームアドレスが有効であると判定する場合、ＨＡ３６を選択し、ＭＮ−ＨＡ信用証明を生成する。これには、事前共有キーあるいは事前共有キーから導出することができるデータがある。ＭＮのホームアドレスと、生成されたＭＮ−ＨＡ信用証明は、例えば、Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションを介して、選択されたＨＡへ送信することができる。選択されたＨＡのアドレスと、生成された信用証明（あるいは、生成された信用証明から導出することができるデータ）は、拡張認証プロトコル、例えば、拡張ＥＡＰを介してＭＮへ送信される。例えば、事前共有キーがＭＮへ送信される場合、これは、ＡＡＡｈとＭＮ間のセキュリティリレーションから導出されるキー（例えば、認証処理中に生成されるセッションキー）によって、保護される（暗号化され、かつ完全性が保護される）べきである。そうでなければ、事前共有キーは、明示的に送信されるべきでない。それに代えて、ＭＮ−ＡＡＡｈセキュリティリレーション、例えば、ナンスに基づいて事前共有キー（あるいは他の信用証明）から導出することができるデータの一部（例えば、ＥＡＰ ＡＫＡ［１４］あるいはＥＡＰ ＳＩＭ［１５］が使用される場合に、ＡＫＡあるいはＧＳＭ認証アルゴリズムに供給されるＲＡＮＤパラメータ）を送信することができる。暗号保護が信用証明に適用される場合、ＨＡアドレスとホームアドレスに対して、同種の保護を使用することは都合が良い場合がある。

ネットワークアクセス認証が完了し、かつＭＮが認可されて、アクセスサーバ（例えば、ＷＬＡＮ ＡＰあるいはアクセスルータ）を介してネットワークへアクセスする場合、ＭＮは、取得される信用証明に基づくＩＫＥ（例えば、ＩＫＥｖ１あるいはＩＫＥｖ２）処理を介して、割り当てられたＨＡへ向けてのＩＰＳｅｃ ＳＡ群を確立することができる。この処理と、その次のバインディング更新／バインディング応答確認（ＢＵ／ＢＡ）交換が、従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して実行される。

ＭＮがホームアドレスを全く含んでいない場合、あるいはホームエージェントに対する自身のリクエスト内でもはや有効でないホームアドレス（例えば、ＭＩＰｖ６ホームネットワーク再採番（renumbering）による）を含んでいる場合、ホームアドレスは、ＭＮに割り当てられるべきである。これに対して、本発明は、ステートフル動的ホームアドレス割当（Ｂ）あるいはステートレス（stateless）ホームアドレス自動コンフィグレーション（Ｃ）を提案している。

本発明は、ステートフル動的ホームアドレス割当（Ｂ）を可能にし、これによって、ＡＡＡｈ３４は、ホームアドレスをＭＮ１０へ割り当てる。また、ＡＡＡｈは、ＭＮ−ＨＡ信用証明を生成し、これは、Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションを介して、割当ホームドレスとともに選択されたＨＡ３６へ送信することが好ましい。また、ＡＡＡｈは、拡張ＥＡＰで例示される本発明の拡張認証プロトコルを介して、割当ＨＡのアドレスと、生成された信用証明（あるいはその生成された信用証明から導出することができるデータ）とともに割当ホームアドレスを、ＭＮへ送信する。（Ａ）の場合では、ＭＮ−ＨＡ信用証明は、拡張認証プロトコルを介して送信される前に保護される、あるいは、選択的には、信用証明から導出することができるデータ、例えば、ナンスが実際の信用証明の代わりに送信される。ネットワークアクセス認証が完了すると、ＭＮはＩＰＳｅｃ ＳＡ群と確立することができ、かつ従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して、割当ＨＡへ向けてのＢＵ／ＢＡ交換を実行することができる。

ホームアドレスのステートレス自動コンフィグレーションが使用される場合（Ｃ）、処理は、選択されるＥＡＰメソッドのラウンドトリップの回数に依存する。ＨＡ３６に対するリクエストに応じて、ＡＡＡｈ３４は、信用証明（あるいは、信用証明から導出することができるデータ）とともにＨＡアドレスをＭＮ１０へ返信する。ＭＮは、典型的には、受信したＨＡアドレスのプレフィックスを使用して、ホームアドレスを構築する。ＥＡＰ処理が完了していない場合、即ち、ＨＡアドレスが、ＥＡＰ成功パケットでなく、ＥＡＰリクエストパケットで搬送された場合、ＭＮは、自身のホームアドレスをＡＡＡｈへ送信する。ＡＡＡｈは、次に、受信したホームアドレスを信用証明とともに、割当ＨＡへ送信する。次に、ＨＡは、自身のサブネット上で受信したホームアドレスに対してＤＡＤを実行すべきである。デュプリケートアドレス検出（ＤＡＤ）が成功すると、ＭＮとＨＡは、その後、ＩＰＳｅｃ ＳＡ群を確立し、従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して、ＢＵ／ＢＡ交換を実行することができる。

これに代わって、ＭＮがＥＡＰ処理の最終パケット（即ち、ＥＡＰ成功パケット）でＨＡアドレスを受信する場合、自身で新規に構築するホームアドレスをＡＡＡｈへ搬送することはできない。ＥＡＰラウンドトリップの回数が十分でない問題を解決する方法は、汎用コンテナ属性の送信を可能にするためのＥＡＰ通知リクエスト／応答を使用するＥＡＰラウンドトリップの回数を、ＡＡＡｈに増やさせることである。

上述のメカニズムの主な利点は、それらがＭＮ１０とＨＡ３６の両方のコンフィグレーションを簡略化することである。ＭＮは、自身のネットワークアクセスコンフィグレーションパラメータ（ＮＡＩと、ＭＮ−ＡＡＡｈセキュリティリレーション）を活用することができるので、ＭＩＰｖ６専用のコンフィグレーションは必要とされない。ＨＡは、任意のＭＮ専用コンフィグレーションを必要としない、これは、ＨＡ−ＡＡＡｈセキュリティリレーションが十分であるからである。ＡＡＡｈ３４は、大体において、ネットワークアクセスとＭＩＰｖ６の両方に対して、単一の認証エンティティを形成することができる（但し、ＩＫＥ認証は、依然として、ＡＡＡｈから受信されるデータに基づいてＨＡで実行される）。

有効なＭＮ−ＨＡセキュリティアソシエーション（例えば、ＩＰＳｅｃ ＳＡ群）が既に存在している場合、ＭＮ１０は、ＡＡＡｈ３４からのＨＡアドレスをリクエストする必要はない。その代わりに、汎用コンテナ属性にＢＵをカプセル化することによって、全体のアクセス遅延を減らして、それを、拡張認証プロトコルを介してＡＡＡｈへ送信しても良い。ＡＡＡｈは、ＢＵをＤｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションメッセージにカプセル化し、また、それを、ＢＵの宛先アドレスによって示されるＨＡ３６へ送信することが好ましい。ＨＡはＢＡで応答し、そして、ＡＡＡｈはその応答をＭＮへ中継する。カプセル化ＢＵとＢＡは、ＭＮ−ＨＡ ＩＰＳｅｃ ＳＡ群によって保護される。実施形態に従えば、ＡＡＡｈは、ＨＡアドレスが有効であり、かつＭＩＰｖ６ホームネットワークが、ＢＵをＨＡへ送信する前に再採番されていないことをチェックする。ＨＡアドレスが有効でないならば、ＡＡＡｈは、通常、エラーをＭＮへ指示し、かつ上述のようにＨＡを割り当てる。即ち、ＡＡＡｈは、ＨＡアドレス、信用証明（あるいは、信用証明から導出することができるデータ）及びおそらくはホームアドレスをＭＮ等へ送信する。

Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションは、時には、ＨＡ３６内で生成されるアカウンティングデータを搬送するために使用されても良い。これは、例えば、リバーストンネルリング（reverse tunneling）が採用され（即ち、ＭＮに対するすべてのトラフィックが、ＨＡを介して送信され、かつＭＮとＨＡ間をトンネルされる場合）、かつホームオペレータがＡＡＡｖ２４から受信されるアカウンティングデータを検証することを可能にすることを要望している場合に役立たせることができる。

ここで、本発明に従う汎用コンテナ属性（ＧＣＡ）のいくつかの実例を、より詳細に説明する。

好ましくは、ＧＣＡ属性は、すべての方法に利用することができ、また、任意のＥＡＰメッセージに含めることができる。このメッセージには、ＥＡＰ成功／失敗メッセージが含まれる。このことは、それがＥＡＰメソッドレイヤ以外のＥＡＰレイヤの一部とするべきであることを意味するものである（［１６］参照）。これによって、考慮すべき重要な問題は、ＭＮとＥＡＰ認証器による後方互換性である（典型的には、ネットワークアクセスサーバ（ＮＡＳ）内のＥＡＰエンティティ）。上述の例における、この汎用コンテナ属性の使用は、新規の属性が、後方互換性があり、かつＥＡＰ認証器に対してトランスペアレントとなる方法でＥＡＰに導入されることを想定している。ＧＣＡをこれらのプロパティに導入することは、いくつかの特別な考慮が必要であり、これは、以下の段落で詳しく説明する。

以下の説明で参照するために、図５では、現在のＥＡＰパケットフォーマット［６、１６］を示している。図５Ａは、汎用ＥＡＰパケットフォーマットを示していて、これは、コード（Code）、識別子（Identifier）及びレングス（長（Length））フィールドを含むＥＡＰレイヤヘッダと、オプションデータフィールドを備えている。割当ＥＡＰコードは、次のように定義される：１＝リクエスト、２＝応答、３＝成功及び４＝失敗である。ＥＡＰ成功／失敗パケット（コード＝３／４）のフォーマットと、ＥＡＰリクエスト／応答パケット（コード＝１／２）は、それぞれ図５Ｂで示される。割当ＥＡＰタイプ：１＝アイデンティティ、２＝通知、３＝Ｎａｋ、４＝認証方法である。

例えば、ＧＣＡのフォーマットは、ＧＣＡ受信インジケータとＧＣＡペイロードに続く２バイトのＧＣＡ長インジケータとすることができる。ＧＣＡ受信インジケータは、どの内部エンティティへ、受信ＧＣＡのペイロードをＥＡＰモジュールが送信するかについてを示す（即ち、このインジケータは、ＩＰヘッダ内のプロトコル／ネクストヘッダフィールド、あるいはＵＤＰ及びＴＣＰヘッダ内のポート番号に対応する）。ＧＣＡペイロードは、ＥＡＰレイヤによって解釈されないデータの汎用部分（generic chunk）となる。ＧＣＡの不在は、例えば、ゼロが設定されるＧＣＡレングスインジケータによって示される。

後方互換性を達成するために、パススルー（pass-through）ＥＡＰ認証器に対してトランスペアレントとなる方法で、ＧＣＡは、ＥＡＰパケットに含ませるべきである。パススルーＥＡＰ認証器は、ＮＡＳ内に存在するＥＡＰ認証器であり、これは、ＭＮとバックエンドＥＡＰ認証サーバ（ＡＡＡサーバ）間のＥＡＰパケットを中継する。ＥＡＰ認証器のパススルー動作は、ＥＡＰレイヤヘッダ、即ち、ＥＡＰパケットの最初にある、コード、識別子及びレングスフィールドに基づいてＥＡＰパケットを中継することである。これは、要求される透過性（トランスペアレンシー）、かつ、ここでは後方互換性が、ＧＣＡがＥＡＰレイヤヘッダ、即ち、コード、識別子及びレングスフィールドの後に配置される場合に達成できることを意味している。

しかしながら、ＥＡＰアイデンティティ応答パケットを識別するために、ＥＡＰ認証器は、通常は、ＥＡＰ応答パケットのタイプ（Type）フィールド（ＥＡＰレイヤヘッダの後に続く）のチェックもしなければならない。ここで、ＡＡＡルーティングに対して必要とされるＮＡＩがＥＡＰアイデンティティ応答パケットから抽出される。ＥＡＰ認証器がＥＡＰアイデンティティ応答パケットを識別する場合、これは、タイプフィールドに続くタイプ−データ（Type-Data）フィールドからＮＡＩを抽出する。ここで、ＥＡＰレイヤヘッダの直後にＧＣＡを配置することは（ＥＡＰ認証器に対してトランスペアレントとなる方法で）、ＥＡＰリクエストパケットについてのみ可能である。それゆえ、通常は、タイプフィールドの後、あるいは（可能であれば、ＮＵＬＬで終了されている）タイプデータフィールドの後にＧＣＡを配置することが好ましい。

タイプフィールドの直後にＧＣＡを配置することは、ＥＡＰアイデンティティ応答パケットではなく、すべてのＥＡＰ応答パケット内でＧＣＡの使用を可能とする。ＥＡＰアイデンティティ応答パケット内でのＧＣＡの使用は禁止されている、これは、これらのパケットから、ＥＡＰ認証器がタイプ−データフィールドからＮＡＩを抽出する必要があるからであり、これは、元来のＥＡＰ認証器がタイプフィールドの直後で検出することを予定しているからである。これは、ＥＡＰが通常数回以上のラウンドトリップ（やりとり（round trip））を持っていることを考慮するＧＣＡの使用についての制約となり得る。場合によっては、他のＥＡＰパケット内のタイプフィールドの後にその位置を保持しながら、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内のＮＵＬＬで終了されているタイプデータフィールドの後に配置することができる。

しかしながら、すべてのＥＡＰパケットで一貫して使用することができるＧＣＡの位置を用いることが通常望ましいとされている。上述の説明からは、後方互換性がある方法でＧＣＡをすべてのＥＡＰパケットに配置することができる位置は、多かれ少なかれトレーラー（trailer）とするパケットの最後となることが上述の説明から理解される。しかしながら、ＧＣＡ位置は、ＥＡＰレイヤヘッダ内のレングスフィールドに依存するが、タイプ−データパラメータ（群）に対する明確なレングスインジケータを持っていないという、問題がこれらのＥＡＰに対して生じることになる。このようなパケットに対しては、通常、ＧＣＡとタイプ−データフィールドを区別することができないことになる。

この問題を解決するために、特定のＧＣＡの実施形態に従って、ＧＣＡレングスインジケータ、ＧＣＡ受信インジケータ及びＧＣＡペイロードの順序を、ＧＣＡレングスインジケータが最後に現れるように入れ換えることが提案される。ＧＣＡをＥＡＰのパケットの最後に配置することによって、ＥＡＰパケットの最後の２つのオクテット（この長さは、ＥＡＰレイヤヘッダ内のレングスフィールドによって示される）は、常に、ＧＣＡレングスインジケータとなる。ＧＣＡレングスインジケータがゼロでない限り、ＧＣＡ受信インジケータは、ＧＣＡレングスインジケータの前に現れ、ＧＣＡペイロード（このサイズは、ＧＣＡレングスインジケータから判定される）は、ＧＣＡ受信インジケータの前に配置されることになる。この方法で、ＥＡＰパケットのＧＣＡを識別し、かつタイプ−データフィールドからＧＣＡを区別することが常に可能となる。一方で、それでもなお、ＧＣＡの使用は、パススルーＥＡＰ認証器に対してトランスペアレントとなる。本発明に従うＧＣＡの好適な位置及びフォーマットは、図６に示される。汎用のフォーマットでのＥＡＰパケット内のＧＣＡの位置は、図６Ａで示される。ＧＣＡは、パケットの最後のトレーラとして配置される。ＧＣＡペイロードとＧＣＡ受信インジケータの後に続いて配置されるＧＣＡレングスインジケータを備える、提案されるＧＣＡフォーマットは、図６Ｂで示される。

図６のＧＣＡ実施形態による後方互換性は、更に、ＥＡＰ認証器がＥＡＰリクエスト／応答パケット（ＥＡＰレイヤヘッダとＮＡＩ以外）からの情報の抽出を試行しないものと仮定し、また、成功／失敗パケット内のレングスフィールドが４より大きい値を示していることを受け入れているものと仮定する。

後方互換性問題に対処する別の方法は、ＥＡＰ ＧＣＡテストリクエスト／応答パケット、即ち、タイプフィールドの新規に定義されている値を持つ新規のＥＡＰパケットを使用して、ＭＮがＧＣＡをサポートしているかを判定することである。最初のＥＡＰアイデンティティリクエスト／応答パケット交換の前後で、ＧＣＡをサポートするＥＡＰ認証器は、ＥＡＰ ＧＣＡテストリクエストパケット、即ち、専用のタイプ値を持つＥＡＰリクエストパケットをＭＮへ送信する（［１７］のＥＡＰ同位状態マシーン（peer state machine）は、２つの異なる送信回数が可能であることを示している）。ＭＮがＧＣＡをサポートしている場合、これは、ＥＡＰ ＧＣＡテスト応答パケットで応答する。そうでない場合、ＭＮは、ＥＡＰ ＧＣＡテストリクエストパケットを、未知のＥＡＰメソッドを使用するためのリクエストと解釈するので、ＭＮは、ＥＡＰ Ｎａｋ パケットで応答する。ＭＮからの応答に基づいて、ＥＡＰ認証器は、ＭＮがＧＣＡをサポートしているかどうかを判定する。

ＧＣＡをサポートするＭＮは、ＥＡＰ ＧＣＡテストリクエストパケットの存在あるいは不在によって、ＥＡＰ認証器がＧＣＡをサポートしているかを判定することができる。ＥＡＰ ＧＣＡテストリクエストパケットが受信されることが予想される場合、即ち、ＥＡＰ アイデンティティリクエスト／応答交換の前後で、ＥＡＰ認証器はＧＣＡをサポートすることを想定する。そうでない場合は、ＭＮは、ＥＡＰ認証器はＧＣＡをサポートしないという結論を出す。

ＭＮとＥＡＰ認証器の両方がＧＣＡをサポートする場合、これは、すべての次のＥＡＰパケット内のＥＡＰレイヤヘッダの後に（ＧＣＡコンポーネントの本来の順序で）配置することができる。そうでない場合、ＧＣＡは、上述の後方互換性のある方法で含ませることを可能にするＥＡＰパケットにいまだなお含めることができる。

後方互換性の問題を扱う上述の別の方法には、いくつかの制限がある。１つには、あるＭＮ−ＥＡＰ認証器のラウンドトリップが無駄になる。また、最初のＥＡＰアイデンティティ／応答パケット交換の後に、ＥＡＰ ＧＣＡテストリクエスト／応答パケットが交換される場合、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内で使用することはできない。この実施形態は、ＥＡＰ認証器（おそらくはＮＡＳ）がＥＡＰの修正版、例えば、ＥＡＰｖ２を使用することを要求しても良い。従って、他の方法では可能であるが、ＥＡＰパケット内にＧＣＡを配置する好適な方法は、典型的には、図６に示されるようにすることである。これによって、ＥＡＰ認証器に伴う後方互換性は、すべてのＥＡＰパケットについて達成することができる。

ＥＡＰラウンドトリップの回数がＧＣＡ内で交換されるデータに対して十分でない場合には、ＡＡＡｈは、ＧＣＡの搬送目的のために、ＥＡＰ通知リクエスト／応答交換を介する、ＥＡＰラウンドトリップの回数を増やしても良い。

ＧＣＡがメソッド専用のものである場合、ＧＣＡは後方互換性の問題を持ち込むことはない。これは、通常、タイプ−データフィールドの一部となるからである。

２００４年２月のインターネットドラフト［１８］では、ＡＡＡインフラストラクチャに基づくモバイルＩＰｖ６認可及びコンフィグレーションが提案されている。ホームプロバイダのＡＡＡサーバとＭＩＰｖ６用の移動ノード間で必要な対話は、保護されたＥＡＰを使用して実現され、これにより、認証データとともにモバイルＩＰｖ６ネゴシエーション用の情報を搬送する。しかしながら、本発明に従う上述の汎用コンテナ属性はＥＡＰ処理に統合することができるのに対して、［１８］のＭＩＰｖ６データは第２フェーズに追加される。上述のソリューションの別の効果的な特徴は、セキュリティメカニズムに関連付けられていることである。本発明に従えば、信用証明が開示されていないことを保証するために、ＭＮ−ＡＡＡｈセキュリティリレーションを活用することができる。一方、［１８］では、信用証明を保護するために保護されたＥＡＰに依存する。また、［１８］は、いくつかのラウンドトリップが追加され、かつネットワーク全体のアクセス遅延が増えることになる。これに対し、本明細書で提案するメカニズムは、ネットワーク全体のアクセス遅延を減らすことも可能にする。

拡張ソリューション−ローカルホームエージェント
図７は、本発明のモビリティサポートメカニズムの別の実施形態を示している。ここでは、いわゆる「ローカルホームエージェント」２６が訪問先ネットワーク２０内に配置されている。以下の説明から明らかとなるように、ローカルＨＡ２６は、最も効果的な方法で、ホームネットワーク３０内のＨＡ３６を補完するために使用することができる。ホームネットワーク内のＨＡと、訪問先ネットワーク内のローカルＨＡは、通常、一つずつ使用され、同時には使用されない。

この実施形態は、図１を参照して説明されるソリューション（以下では、「ベーシックソリューション」とも称する）を拡張したものである。これは、例えば、メソッド専用ＥＡＰ属性あるいは汎用コンテナ属性を使用することができ、また、ＡＡＡｖ２４内のＭＩＰｖ６サポートを必要とする。拡張ソリューションの対象となる状況は、ＨＡ３６がホームネットワーク３０内に存在しない場合である。その代り、ローカルＨＡ２６が、訪問先ドメイン２０内のローミングＭＮ１０に動的に割り当てられている。ベーシックソリューションは再使用され（ＨＡがホームネットワーク内に存在しない場合、ＡＡＡｈ−ＨＡ通信（ＩＶ）されない場合を除く）、かつそれに加えて、Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションが拡張される。そうすることで、ＡＡＡｈ３４とＡＡＡｖ２４（ＶＩ）間で使用して、訪問先ドメイン２０内のローカルＨＡ２６の割当を可能にすることができる。Ｄｉａｍｅｔｅｒ ＭＩＰｖ６アプリケーションも、ＡＡＡｖ２４とローカルＨＡ２６（ＶＩＩ）間で使用される。

つまり、ＭＮ１０とローカルＨＡ２６間の経路は、「トロンボーン型（tromboning）」経路となる（この経路は、脚形状のＡＡＡｖ−ＡＡＡｈ経路を双方向で通過する）：ＭＮ←→ＡＡＡクライアント←→ＡＡＡｖ←→ＡＡＡｈ←→ローカルＨＡ（Ｉ、ＩＩ、ＩＩＩ、ＩＶ）。しかしながら、ＡＡＡシグナリング、例えば、次のＢＵ／ＢＡ交換には統合されないＭＩＰｖ６シグナリングは、ＭＮ−ローカルＨＡの直接経路（ＶＩＩＩ）に従うことになる。

経路Ｉ、ＩＩ、ＩＩＩ、ＩＶの上述の機能は、ベーシックソリューションから再使用されるので（ＩＶに対して、ＨＡがホームネットワーク内に存在しない場合を除く）、ローカルＨＡ割当に対する追加の機能だけについて詳細に説明する。

ローカルＨＡ２６の割当は、本質的には、ベーシックソリューションで説明されるＡＡＡｈ−ＨＡ通信が、ＡＡＡｈ−ＡＡＡｖ−ローカルＨＡ通信になることを意味する。ここで、ＭＮ−ローカルＨＡの全経路は、次の構造を有する：ＭＮ−ＡＡＡクライアント−ＡＡＡｖ−ＡＡＡｈ−ＡＡＡｖ−ローカルＨＡ。この経路では、拡張認証プロトコル、例えば、拡張ＥＡＰが、ＭＮからＡＡＡｈの間で使用される。経路ＥＡＰのＡＡＡクライアント−ＡＡＡｖ−ＡＡＡｈの部分は、既存のＡＡＡプロトコル、例えば、ＤｉａｍｅｔｅｒＥＡＰアプリケーションあるいはＲＡＤＩＵＳで搬送される。ＡＡＡｈ−ＡＡＡｖ−ローカルＨＡの部分では、ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーションが使用される。搬送される情報は、本質的には、ベーシックソリューションと同じである。

図７で参照される、本発明に従う拡張ＭＩＰｖ６サポートに対して、セグメントＭＮ−ＡＡＡクライアント−ＡＡＡｖ−ＡＡＡｈ−ＨＡと、セグメントＡＡＡｈ−ＡＡＡｖ−ローカルＨＡ間のプロトコルの組み合わせ例が、表３でまとめられている。ローカルＨＡ２６を用いる場合は、ＡＡＡｈ３４は、ＡＡＡプロトコルアプリケーションを介して、好ましくは、ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーション（但し、例えば、ＲＡＤＩＵＳの拡張バージョンとすることもできる）のようなＤｉａｍｅｔｅｒアプリケーションを介して、ＨＡに対するリクエストを適切なＡＡＡｖ２４へ送信する。経路（ＩＩ、ＩＩＩ）を介して、新規／拡張認証プロトコルを搬送し、また、経路（ＩＶ、ＶＩ、ＶＩＩ）を介してＭＩＰｖ６データを送信するＡＡＡフレームワークプロトコルアプリケーション（群）は、例えば、Ｄｉａｍｅｔｅｒアプリケーション（群）とすることができる。

ホームネットワーク３０にＨＡ３６が存在しないことを想定してみる。この状況では、ＭＮ１０へＭＩＰｖ６サポートを提供するための唯一の方法は、訪問先ドメイン２０内にローカルＨＡ２６を割り当てることである。つまり、ＨＡアドレスに対するリクエストがＡＡＡｈ３４内で受信される場合、ＡＡＡｈは、ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーションを介して、ＡＡＡｖ２４へリクエストを送信する。また、ＡＡＡｈは、ＭＮ−ＨＡ信用証明を生成し、必要であれば、ＭＮに対するホームアドレスも生成する。信用証明とホームアドレス（あるいは、利用可能なホームアドレスがない場合には、ＮＡＩ）は、ローカルＨＡアドレスに対するリクエストに従って、ＡＡＡｖに送信される。

ローカルＨＡアドレスに対するリクエストを受信すると、ＡＡＡｖ２４は、ローカルＨＡ２６を選択し、そして、ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーションを使用して、信用証明とホームアドレス（あるいはＮＡＩ）を、その選択されたＨＡへ送信する。次に、ＡＡＡｖは、ローカルＨＡのアドレスをＡＡＡｈ３４へ返信する。また、ＡＡＡｖは、ＭＮ−ＨＡ ＩＰＳｅｃ ＳＡ群に対するＳＰＩ群を生成しても良い（ここでは、拡張ソリューションは、ＡＡＡｈによって生成されない）。このような場合、ＡＡＡｖは、ＳＰＩ群の１つをローカルＨＡに送信し、他のＳＰＩをローカルＨＡのアドレスとともに、ＡＡＡｈへ返信する。続いて、ステートレスで構成されている（即ち、自動構成されている）ホームアドレスをＡＡＡｈがＭＮ１０から受信する場合、ＤｉａｍｅｔｅｒＭＩＰｖ６アプリケーションは、ＡＡＡｖとローカルＨＡへホームアドレスを搬送するために使用することができる。

次のＩＫＥ（ＩＫＥｖ１あるいはＩＫＥｖ２）処理（使用する場合）とＭＩＰｖ６処理は、ホームネットワーク３０内のＨＡ３６に代えて、ローカルＨＡ２６とＭＮ１０が直接通信すること以外は、ベーシックソリューションで説明されるものと同様である。

ここで、ホームネットワーク３０にＨＡ３６が存在していると想定する。このような場合、ＭＮ１０がホームネットワーク内のＨＡとの有効なバインディングを持っていない限り、ローカルＨＡ２６は割り当てられるべきでない。ＭＮがホームネットワーク内のＨＡとの有効なバインディングを持っておらず、かつＨＡアドレスに対するリクエストをＡＡＡｈ３４に送信する場合、これには、ローカルＨＡあるいはホームネットワーク内のＨＡを選択しているかどうかの指示を含んでいても良い。ＡＡＡｈはこの指示を考慮しても良いが、最終的には、ＡＡＡｈは、ローカルＨＡあるいはホームネットワーク内のＨＡが、ＭＮに割り当てられるべきであるかを決定する。ＡＡＡｈがローカルへ割り当てることを決定する場合、この処理は、ＨＡがホームネットワーク内に存在しない場合について上述したものと同一の処理となる。

次のＩＫＥ（ＩＫＥｖ１あるいはＩＫＥｖ２）処理（使用する場合）とＭＩＰｖ６処理は、ホームネットワーク３０内のＨＡ３６に代えて、ローカルＨＡ２６とＭＮ１０が直接通信すること以外は、ベーシックソリューションで説明されるものと同様である。

別の実施形態では、ホームネットワーク３０内のＨＡ３６との有効なバインディングが持っている場合でさえも、ＭＮ１０は、ＡＡＡｈ３４にローカルＨＡ２６を選択することを指示することが許容される。このような場合、通常、ＡＡＡｈは、ホームネットワーク内のＨＡに、ローカルＨＡの割当前後で、バインディングを削除することを指示する。バインディングが残っていて、かつローカルＨＡとホームネットワーク内のＨＡが同時に使用されることになる場合、追加の機能が、例えば、階層ＭＩＰｖ６の形態で必要とされる。

ＢＵ／ＢＡパケットのカプセル化は、ローカルＨＡ３６が使用される場合にも可能であり、これは、必要とされるＭＮ−ローカルＨＡ ＩＰＳｅｃ ＳＡ群が存在していることが提供される。ベーシックソリューションとの違いは、カプセル化ＢＵ／ＢＡパケットが、経路（ＩＶ）の代わりに、経路（ＶＩ＋ＶＩＩ）を介して送信されることである。

上述のいくつかの構成をまとめると、図９は、移動ノード用のＭＩＰｖ６サービスをサポートする方法の基本例のフローチャートであるとみなすことができる。この例では、ステップＳ１−Ｓ４で示される、情報送信と動作は、移動ノードの認証（Ｓ１）、ＭＮ−ＨＡセキュリティアソシエーションの確立（Ｓ２）、ＭＩＰｖ６コンフィグレーション（Ｓ３）及びＭＩＰｖ６バインディング（Ｓ４）に関するものである。ステップＳ２−Ｓ３は、一般には、認可フェーズとしてみなされる。ステップＳ１−Ｓ４は、要求される場合には、全体のセットアップ回数を少なくするために多かれ少から平行して実行されても良い。ステップＳ１では、情報が、ホームネットワーク側で移動ノードを認証するためのＡＡＡインフラストラクチャを介して送信される。ステップＳ２で、ＭＮとＨＡ間のセキュリティアソシエーションを即時に確立すること、あるいは将来に確立することを可能にするために、ＭＩＰｖ６関連情報が送信される。ステップＳ３で、例えば、コンフィグレーションパラメータを、移動ノード及び、その内部の適切な記憶用のホームエージェントの少なくとも一方に送信することによって、追加のＭＩＰｖ６コンフィグレーションが実行される。ステップＳ４で、移動ノードはバインディング更新を送信し、そして、ＭＩＰｖ６バインディングがＨＡで確立される。

本発明の詳細な実施形態は、現在のＥＡＰ［６、１６］を参照して主に説明している。しかしながら、本発明は、ＥＡＰｖ２のような他のＥＡＰバージョンにも良好に適用可能であり、更には、上述の方法で拡張される他の認証プロトコルにも良好に適用可能であることが理解されるべきである。ＥＡＰは、単なる取り得る実装の例示であり、また、本発明は、通常は、それに限定されるものではなく、また、選択的には、非ＥＡＰスキームを介在させても良い。

上述の例では、移動ノード（ＭＮ）とＡＡＡｈは、共通の共有化シークレットを持っているものと想定している。これは、例えば、移動ノード内にインストールされているアイデンティティモジュールとホームネットワーク間で共有される対称キーとすることができる。このアイデンティティモジュールは、従来より周知の任意の不正開封防止アイデンティティモジュールとすることができる。これには、ＧＳＭ移動電話で使用される標準ＳＩＭカード、ユニバーサルＳＩＭ（ＵＳＩＭ）、ＷＡＰ ＳＩＭ、これは、ＷＩＭとしても知られる。また、ＩＳＩＭ、また、より一般的には、ＵＩＣＣモジュールがある。ＭＮ−ＨＡセキュリティリレーションに対しては、シードあるいはナンスは、ＭＮによってＡＡＡｈへ搬送することができる（あるいは、別のメソッドでは、即ち、シードは、ＡＡＡｈによって生成されて、ＭＮへ搬送される）。このシードあるいはナンスから、ＡＡＡｈは、共有シークレットに基づいて、ＭＮ−ＨＡセキュリティキー（群）、例えば、事前共有化キーを生成することができる。移動ノードは、自身で、同一のセキュリティキー（群）を生成することができる。これは、この移動ノードが、シード／ナンスを生成して（あるいはＡＡＡｈからシードを受信して）いて、また、共有シークレットを持っているからである。選択的には、ＡＡＡｈは、自身で、ＭＮ−ＨＡセキュリティキー（群）を生成して、そして、それをＭＮ（暗号技術で保護されている）とＨＡへ送信するようにしても良い。

本発明は特定の実施形態を参照して説明されているが、本発明は、開示される構成と等価なもの、また、当業者にとって自明な変更及び変形も含むことが重視されるべきである。つまり、本発明の範囲は、請求項によってのみ制限されるものである。

略語
ＡＡＡ 認証、認可及びアカウンティング（Authentication, Authorization and Accounting）
ＡＡＡｈ ホームＡＡＡサーバ
ＡＡＡｖ 訪問先ＡＡＡサーバ（Visited AAA server）
ＡＫＡ 認証及びキーアグリーメント（Authentication and Key Agreement）
ＡＰ アクセスポイント
ＢＡ バインディング応答確認（Binding Acknowledgement）
ＢＵ バインディング更新（Binding Update）
ＤＡＤ デュプリケートアドレス検出（Duplicate Address Detection）
ＥＡＰ 拡張可能認証プロトコル（Extensible Authentication Protocol）
ＥＰ 実行ポイント（Enforcement Point）
ＧＣＡ 汎用コンテナ属性（Generic Container Attribute）
ＧＳＭ 移動通信用グローバルシステム
（Global System for Mobile communications）
ＨＡ ホームエージェント
ＩＫＥ インターネットキー交換
（Internet Key Exchange）
ＩＰ インターネットプロトコル
ＩＰsec ＩＰ セキュリティ
ＩＳＡＫＭＰ インターネットセキュリティアソシエーション及びキー管理プロトコル
（Internet Security Association and Key Management Protocol）
ＩＳＩＭ ＩＭサービスアイデンティティモジュール
ＭＤ５ メッセージダイジェスト５（Message Digest 5）
ＭＩＰｖ６ モバイルＩＰバージョン６
ＭＮ 移動ノード
ＮＡＩ ネットワークアクセス識別子
ＮＡＳ ネットワークアクセスサーバ
ＰＡＡ ＰＡＮＡ認証エージェント
ＰＡＣ ＰＡＮＡクライアント
ＰＡＮＡ ネットワークアクセス認証用搬送プロトコル
（Protocol for carrying Authentication for Network Access）
ＰＰＰ ポイントツーポイントプロトコル（Point-to-Point Protocol）
ＳＡ セキュリティアソシエーション（Security Association）
ＳＩＭ 加入者アイデンティティモジュール（Subscriber Identity Module）
ＳＰＩ セキュリティパラメータインデックス
ＴＬＳ トランスポートレイヤセキュリティ
ＴＬＶ タイプレングス値（Type Length Value）
ＴＴＬＳ トンネル化ＴＬＳ（Tunneled TLS）
ＵＩＣＣ ユニバーサル集積化回路カード（Universal Integrated Circuit Card）
ＷＡＰ 無線アプリケーションプロトコル
ＷＬＡＮ 無線ローカルエリアネットワーク
参考文献
［１］ＩＰｖ６における移動性のサポート、ディー．ジョンソン、シー．パーキンス、ジェイ．アルコ、２００３年６月３０日、（Mobility Support inIPv6, D. Johnson, C. Perkins, J. Arkko, June 30,2003）
［２］ＤｉａｍｅｔｅｒモバイルＩＰｖ６アプリケーション、ステファノ エム．ファッチン、フランク レ、バサバラヤ パチル、チャールズ イー．ペルキンス、２００３年４月（Diameter MobileIPv6 Application, Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E. Perkins, April 2003）
［３］ネットワークアクセス認証用搬送プロトコル、ディー フォルスバーグ、ワイ．オオバ、ビー．パチル、エイチ．ショフェニグ、エイ．ヤイン、２００３年４月（Protocol for Carrying Authentication for Network Access (PANA), D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, A. Yegin, April 2003）
［４］ＥＡＰトンネル化ＴＬＳ認証プロトコル、ポール フンク、サイモン ブレーク−ウィルソン、２００２年１１月（EAP Tunneled TLS Authentication Protocol, Paul Funk, Simon Blake-Wilson, November 2002）
［５］ＩＥＥＥ規格８０２．１Ｘ、ローカル及びメトロポリンタンネットワーク−ポートベースのネットワークアクセス制御（IEEE Standard 802. 1X, Local and metropolitan area networks-Port-Based Network Access Control）
［６］ＰＰＰ拡張可能認証プロトコル（ＥＡＰ）、ＲＦＣ２２８４、エル．ブルンク、ジェイ．ボルブレッヒ、１９９８年３月（PPP Extensible Authentication Protocol (EAP),RFC2284, L. Blunk, J. Vollbrecht, March 1998）
［７］Ｄｉａｍｅｔｅｒ拡張可能認証プロトコル（ＥＡＰ）アプリケーション、ティー．ヒルラー、ジー．ゾルン、２００３年３月（Diameter Extensible Authentication Protocol (EAP) Application, T. Hiller, G. Zorn, March 2003）
［８］リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）−ＲＦＣ２８６５、シー．リギニー、エス．ウィレンス、エイ．ルーベンス、ダブリュ．シムプソン、２０００年６月（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）
［１０］ＤｉａｍｅｔｅｒモバイルＩＰｖ４アプリケーション、ピー．カルホン、ティー，ジョアンソン、シー．ペルキンス、２００３年４月２９日（Diameter MobileIPv4 Application, P. Calhoun, T. Johansson, C. Perkins, April 29, 2003）
［１１］３ＧＰＰ２ Ｘ．Ｐ００１１ Ｖｅｒ．１．０−９、３ＧＰＰ２無線ＩＰネットワーク規格、２００３年２月（3GPP2 X.P0011 Ver.1. 0-9,3GPP2 Wireless IP Network Standard, February, 2003）
［１２］インターネットキー交換（ＩＫＥ）、ＲＦＣ２４０９、ディー．ハルキンス、ディー．カレル、１９９８年１１月（The Internet Key Exchange (IKE), RFC2409, D. Harkins, D. Carrel, November1998）
［１３］インターネットセキュリティアソシエーション及びキー管理プロトコル（ＩＳＡＫＭＰ）、ＲＦＣ２４０８、ディー．マウガン、エム．シェルトラー、エム．シュナイダー、ジェイ．ターナー、１９９８年１１月（Internet Security Association and Key Management Protocol (ISAKMP),RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998）
［１４］ＥＡＰ ＡＫＡ認証、ジェイ．アルコ、エイチ．ハベリネン、２００３年１０月（EAP AKA Authentication, J. Arkko, H. Haverinen, October 2003）
［１５］ＥＡＰ ＳＩＭ認証、エイチ．ハベリネン、ジェイ．サロウェイ、２００３年１０月（EAP SIM Authentication, H. Haverinen, J. Salowey, October 2003）
［１６］拡張可能認証プロトコル（ＥＡＰ）、エル．ブランク、ジェイ．ボルブレッヒ、ビー．アボバ、ジェイ．カールソン、エイチ．レブコベッツ、２００３年７月（Extensible Authentication Protocol(EAP)-RFC2284, L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, September 2003）
［１７］ＥＡＰ同位認証器用状態マシーン、ジェイ．ボルフレッヒ、ピー．エロネン、エヌ．ペトロニ、ワイ．オオバ、２００３年１０月（State Machines for EAP Peer and Authenticator, J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, October 2003, ＜ draft-ietf-eap-statemachine-01. pdf ＞）
［１８］ＥＡＰに基づくＭＩＰｖ６認可及びコンフィグレーション、ジー．ジアレッタ、アイ．グアルディニ、イー．デマリア、２００４年２月（MIPv6 Authorization and Configuration based on EAP, G. Giaretta, I.Guardini, E. Demaria, February 2004）

本発明で使用される、ＭＩＰｖ６ ＡＡＡ用の通信システムの概要図である。 本発明の第１の実施形態に従うＭＩＰｖ６の開始の信号フロー図である。 本発明の第２の実施形態に従うＭＩＰｖ６の開始の信号フロー図である。 本発明の実施形態に従うＭＩＰｖ６ハンドオフの信号フロー図である。 従来のＥＡＰパケットフォーマットを示す図である。 従来のＥＡＰパケットフォーマットを示す図である。 本発明の実施形態に従うＧＣＡ属性の配置及びフォーマットを示す図である。 本発明の実施形態に従うＧＣＡ属性の配置及びフォーマットを示す図である。 本発明の実施形態に従うＭＩＰｖ６ ＡＡＡ用の通信システムの概要図である。 本発明の実施形態に従うＡＡＡホームネットワークサーバを示すブロック図である。 本発明に従う移動ノード用のＭＩＰｖ６サービスをサポートするための方法の基本例のフロー図である。

Claims (14)

1. モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートする方法であって、
   訪問先ネットワーク（２０）内の移動ノード（１０）と前記移動ノードのホームネットワーク（３０）内のＡＡＡサーバ（３４）間で、訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理で、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連認証及び認可情報を送信し、
   更に、前記ホームネットワーク（３０）内の前記ＡＡＡサーバ（３４）からホームエージェント（２６、３６）へＭＩＰｖ６関連情報を送信し、
   前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と前記ホームエージェント（２６、３６）間のＭＩＰｖ６セキュリティアソシエーションの即時確立あるいは将来確立のために、また、前記ホームエージェント（２６、３６）で前記移動ノード（１０）に対するバインディングを確立するために、前記ＡＡＡインフラストラクチャを介して送信される
   ことを特徴とする方法。
2. 前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連認証及び認可情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
   ことを特徴とする請求項１に記載の方法。
3. 前記ＭＩＰｖ６関連情報は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性で送信される
   ことを特徴とする請求項２に記載の方法。
4. 前記ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性で送信される
   ことを特徴とする請求項２に記載の方法。
5. 前記ホームネットワークサーバ（３４）で、前記ホームエージェント（２６、３６）を前記移動ノード（１０）へ割り当て、
   前記移動ノードと前記ホームエージェント間でのセキュリティアソシエーションの確立のために、信用証明関連データを、前記ＡＡＡホームネットワークサーバから、前記移動ノードと前記ホームエージェントそれぞれへ配信する
   ことを特徴とする請求項１に記載の方法。
6. 前記移動ノード（１０）で、自身に割り当てられるホームエージェント（２６、３６）のアドレスの少なくとも一部を使用して、前記移動ノードのホームアドレスを構築し、
   選択されたＥＡＰ処理のラウンドトリップを使用して、前記移動ノードの前記ホームアドレスを、前記移動ノードから前記ＡＡＡホームネットワークサーバ（３４）へ送信する
   ことを特徴とする請求項５に記載の方法。
7. 前記ＡＡＡホームネットワークサーバ（３４）で、ホームアドレスを、前記移動ノード（１０）へ割り当て、かつ選択されたＥＡＰ処理のラウンドトリップを使用して、前記移動ノード（１０）の前記ホームアドレスのコンフィグレーションを実行する
   ことを特徴とする請求項１に記載の方法。
8. ＭＩＰｖ６用の認証及び認可をサポートするためのシステムであって、
   訪問先ネットワーク（２０）内の移動ノード（１０）と前記移動ノードのホームネットワーク（３０）内のＡＡＡサーバ（３４）間で、前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理で、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連認証及び認可情報を送信する手段を備え、
   更に、前記ホームネットワーク（３０）内の前記ＡＡＡサーバ（３４）からホームエージェント（２６、３６）へＭＩＰｖ６関連情報を送信する手段を備え、
   前記ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報及び認可情報を送信する手段は、前記移動ノード（１０）と前記ホームエージェント（２６、３６）間のＭＩＰｖ６セキュリティアソシエーションの即時確立あるいは将来確立し、かつ前記ホームエージェント（２６、３６）内の前記移動ノード（１０）に対するバインディングを確立する手段を備える
   ことを特徴とするシステム。
9. 前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連認証及び認可情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
   ことを特徴とする請求項８に記載のシステム。
10. 前記ＭＩＰｖ６関連情報を送信する手段は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性を送信するために動作可能である
    ことを特徴とする請求項９に記載のシステム。
11. 前記ＭＩＰｖ６関連情報を送信する手段は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性を送信するために動作可能である
    ことを特徴とする請求項９に記載のシステム。
12. 前記ホームネットワークサーバ（３４）で、前記ホームエージェント（２６、３６）を前記移動ノード（１０）へ割り当てる手段と、
    前記移動ノードと前記ホームエージェント間でのセキュリティアソシエーションの確立のために、信用証明関連データを、前記ＡＡＡホームネットワークサーバから、前記移動ノードと前記ホームエージェントそれぞれへ配信する手段と
    を備えることを特徴とする請求項８に記載のシステム。
13. 前記移動ノード（１０）で、自身に割り当てられるホームエージェント（２６、３６）のホームアドレスの少なくとも一部を使用して、前記移動ノードのホームアドレスを構築する手段と、
    選択されたＥＡＰ処理のラウンドトリップを使用して、前記移動ノードの前記ホームアドレスを、前記移動ノードから前記ＡＡＡホームネットワークサーバ（３４）へ送信する手段と
    を備えることを特徴とする請求項１２に記載のシステム。
14. 前記ＡＡＡホームネットワークサーバ（３４）で、ホームアドレスを前記移動ノード（１０）へ割り当てる手段と、選択されたＥＡＰ処理のラウンドトリップを使用して、前記移動ノード（１０）の前記ホームアドレスのコンフィグレーションを実行する手段を備える
    ことを特徴とする請求項８に記載のシステム。

Images