(57)【要約】本発明は、訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク間でのエンドツーエンド処理において、好ましくは、拡張された認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報を送信することによって、ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可のサポートを提供する。好ましくは、エンドツーエンド処理は、移動ノードと、ホームネットワーク内のＡＡＡサーバ（３４）間で実行される。訪問先ネットワークでは、下位レイヤのセットアップ後、ポイントツーポイント通信が、移動ノードとインターネット接続サーバ（２２）間で確立される。次に、アクセスサーバは、移動ノードのＭＩＰｖ６認証及び認可のために、ＡＡＡホームサーバと通信する。実施形態では、拡張認証プロトコルの基礎としてＥＡＰを使用する。次に、ＥＡＰ拡張は、ＭＩＰｖ６ハンドインに対してＣＨＡＰを有効にしながら、ＭＩＰｖ６の開始及び再認証に対して使用される。
2006527968.tif 000002
【特許請求の範囲】
【請求項１】
ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートする方法であって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク間でのエンドツーエンド処理において、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報を送信する
ことを特徴とする方法。
【請求項２】
前記認証プロトコルは、拡張認証プロトコルである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記エンドツーエンド処理は、前記移動ノード（１０）と、前記ホームネットワーク内のＡＡＡサーバ（３４）間で実行される
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と、前記ＡＡＡホームネットワークサーバ（３４）間で、認証プロトコルで、前記訪問先ネットワークに配置されるインターネット接続アクセスサーバ（２２）を介して送信される
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記インターネット接続アクセスサーバ（２２）は、ＰＤＳＮノードである
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記移動ノード（１０）と前記インターネット接続アクセスサーバ（２２）間のポイントツーポイント通信が、ＣＳＤ−ＰＰＰプロトコルに基づいて構成される
ことを特徴とする請求項４に記載の方法。
【請求項７】
前記ＭＩＰｖ６関連情報は、ＭＩＰｖ６認証、認可及びコンフィグレーション情報のグループから選択される情報を有する
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記拡張認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項２に記載の方法。
【請求項９】
前記ＭＩＰｖ６関連情報は、前記ＥＡＰプロトコルスタックのメソッドレイヤのＥＡＰ属性として送信される
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ＭＩＰｖ６関連情報は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性で送信される
ことを特徴とする請求項８に記載の方法。
【請求項１１】
前記ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性で送信される
ことを特徴とする請求項８に記載の方法。
【請求項１２】
前記移動ノード（１０）と前記訪問先ネットワークのインターネット接続アクセスサーバ間で、前記認証プロトコルは、ＰＡＮＡ、ＰＰＰ及びＣＳＤ−ＰＰＰのグループから選択されるプロトコルによって搬送される
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記認証プロトコルは、前記訪問先ネットワーク内の前記インターネット接続アクセスサーバ（２２）と、前記ホームネットワーク内の前記ＡＡＡサーバ（３４）間を、ＡＡＡフレームワークプロトコルアプリケーションによって搬送される
ことを特徴とする請求項４に記載の方法。
【請求項１４】
前記ＡＡＡフレームワークプロトコルアプリケーションは、Ｄｉａｍｅｔｅｒ及びＲＡＤＩＵＳのグループから選択される
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
更に、ＭＩＰｖ６ハンドインのために、前記移動ノードと前記ホームネットワーク間でＣＨＡＰ認証を実行するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項１６】
前記ＣＨＡＰ認証を実行するステップは、ＰＰＰの認証フェーズを使用するステップを含む
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ＭＩＰｖ６関連情報は、ホームエージェント（３６）の割当のために、前記ＡＡＡインフラストラクチャを介して送信される
ことを特徴とする請求項１に記載の方法。
【請求項１８】
前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と前記ホームエージェント（３６）間のＭＩＰｖ６セキュリティアソシエーションの確立のために、前記ＡＡＡインフラストラクチャを介して送信される
ことを特徴とする請求項１に記載の方法。
【請求項１９】
前記ＭＩＰｖ６関連情報は、前記ホームエージェント（３６）内の前記移動ノード（１０）に対するバインディングの確立のために、前記ＡＡＡインフラストラクチャを介して送信される
ことを特徴とする請求項１に記載の方法。
【請求項２０】
前記インターネット接続アクセスサーバ（２２）は、標準ＰＰＰ／ＬＣＰパケットと少なくともＰＰＰ／ＥＡＰパケットを送信することによって、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用する可能性を前記移動ノードへ提示する
ことを特徴とする請求項４に記載の方法。
【請求項２１】
前記移動ノードは、ＰＰＰ／ＥＡＰを使用するＣＳＤ−ＰＰＰを選択して、同時に、ＰＰＰ／ＬＣＰを処理する
ことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記移動ノードは、ＰＰＰを選択し、かつＰＰＰ／ＬＣＰを処理する
ことを特徴とする請求項２０に記載の方法。
【請求項２３】
前記インターネット接続アクセスサーバは、ＰＰＰ／ＬＣＰ及びＰＰＰ／ＥＡＰパケットとともに、ＰＰＰ／ＣＨＡＰパケットも送信する
ことを特徴とする請求項２０に記載の方法。
【請求項２４】
前記移動ノードは、ＭＩＰｖ６ハンドインを要求し、かつＰＰＰ／ＣＨＡＰを使用するＣＳＤ−ＰＰＰを選択して、同時に、ＰＰＰ／ＬＣＰを処理する
ことを特徴とする請求項２３に記載の方法。
【請求項２５】
グローバルＩＰｖ６アドレスの割当は、前記ＡＡＡインフラストラクチャを介する、前記移動ノードと前記ホームネットワーク間のＤＨＣＰ交換に基づいて実行される
ことを特徴とする請求項１に記載の方法。
【請求項２６】
ＩＰｖ６アドレスコンフィグレーションが、インタフェースＩＤ割当用のＰＰＰのＮＣＰ（ＩＰｖ６ＣＰ）フェーズと、ＩＰｖ６アドレスのグローバルプレフィックスを取得するためのＩＰｖ６ルータ勧誘／広告に基づいて実行される
ことを特徴とする請求項１に記載の方法。
【請求項２７】
ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートするシステムであって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク間でのエンドツーエンド処理において、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とするシステム。
【請求項２８】
前記認証プロトコルは、拡張認証プロトコルである
ことを特徴とする請求項２７に記載のシステム。
【請求項２９】
前記エンドツーエンド処理は、前記移動ノード（１０）と、前記ホームネットワーク内のＡＡＡサーバ（３４）間で実行される
ことを特徴とする請求項２７に記載のシステム。
【請求項３０】
前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と、前記ＡＡＡホームネットワークサーバ（３４）間で、前記認証プロトコルで、前記訪問先ネットワークに配置されるインターネット接続アクセスサーバ（２２）を介して送信される
ことを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記インターネット接続アクセスサーバ（２２）は、ＰＤＳＮノードである
ことを特徴とする請求項３０に記載のシステム。
【請求項３２】
前記移動ノード（１０）と前記インターネット接続アクセスサーバ（２２）間のポイントツーポイント通信を、ＣＳＤ−ＰＰＰプロトコルに基づいて構成する手段を更に備える
ことを特徴とする請求項３０に記載のシステム。
【請求項３３】
前記ＭＩＰｖ６関連情報は、ＭＩＰｖ６認証、認可及びコンフィグレーション情報のグループから選択される情報を有する
ことを特徴とする請求項２７に記載のシステム。
【請求項３４】
前記拡張認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項２８に記載のシステム。
【請求項３５】
前記ＭＩＰｖ６関連情報を送信する手段は、前記ＥＡＰプロトコルスタックのメソッドレイヤのＥＡＰ属性として、前記ＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項３４に記載のシステム。
【請求項３６】
前記ＭＩＰｖ６関連情報を送信する手段は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性で、前記ＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項３４に記載のシステム。
【請求項３７】
前記ＭＩＰｖ６関連情報を送信する手段は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性で、前記ＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項３４に記載のシステム。
【請求項３８】
前記移動ノード（１０）と前記訪問先ネットワークのインターネット接続アクセスサーバ間で、前記認証プロトコルは、ＰＡＮＡ、ＰＰＰ及びＣＳＤ−ＰＰＰのグループから選択されるプロトコルによって搬送される
ことを特徴とする請求項２７に記載のシステム。
【請求項３９】
前記認証プロトコルは、前記訪問先ネットワーク内の前記インターネット接続アクセスサーバ（２２）と、前記ホームネットワーク内の前記ＡＡＡサーバ（３４）間を、ＡＡＡフレームワークプロトコルアプリケーションによって搬送される
ことを特徴とする請求項３０に記載のシステム。
【請求項４０】
前記ＡＡＡフレームワークプロトコルアプリケーションは、Ｄｉａｍｅｔｅｒ及びＲＡＤＩＵＳのグループから選択される
ことを特徴とする請求項３９に記載のシステム。
【請求項４１】
更に、ＭＩＰｖ６ハンドインのために、前記移動ノードと前記ホームネットワーク間でＣＨＡＰ認証を実行する手段を備える
ことを特徴とする請求項２７に記載のシステム。
【請求項４２】
前記ＣＨＡＰ認証を実行する手段は、ＰＰＰの認証フェーズを使用するように動作可能である
ことを特徴とする請求項４１に記載のシステム。
【請求項４３】
前記ＭＩＰｖ６関連情報を送信する手段は、ホームエージェント（３６）の割当のために、前記ＡＡＡインフラストラクチャを介して前記ＭＩＰｖ６関連情報を送信するように動作可能である
ことを特徴とする請求項２７に記載のシステム。
【請求項４４】
前記ＭＩＰｖ６関連情報を送信する手段は、前記移動ノード（１０）と前記ホームエージェント（３６）間のＭＩＰｖ６セキュリティアソシエーションの確立のために、前記ＡＡＡインフラストラクチャを介して前記ＭＩＰｖ６関連情報を送信するように動作可能である
ことを特徴とする請求項２７に記載のシステム。
【請求項４５】
前記ＭＩＰｖ６関連情報を送信する手段は、前記ホームエージェント（３６）内の前記移動ノード（１０）に対するバインディングの確立のために、前記ＡＡＡインフラストラクチャを介して前記ＭＩＰｖ６関連情報を送信するように動作可能である
ことを特徴とする請求項２７に記載のシステム。
【請求項４６】
前記インターネット接続アクセスサーバ（２２）は、標準ＰＰＰ／ＬＣＰパケットと少なくともＰＰＰ／ＥＡＰパケットを送信することによって、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用する可能性を前記移動ノードへ提示するように動作可能である
ことを特徴とする請求項３０に記載のシステム。
【請求項４７】
前記移動ノードは、ＰＰＰ／ＥＡＰを使用するＣＳＤ−ＰＰＰを選択して、同時に、ＰＰＰ／ＬＣＰを処理するように動作可能である
ことを特徴とする請求項４６に記載のシステム。
【請求項４８】
前記移動ノードは、ＰＰＰを選択し、かつＰＰＰ／ＬＣＰを処理するように動作可能である
ことを特徴とする請求項４６に記載のシステム。
【請求項４９】
前記インターネット接続アクセスサーバは、ＰＰＰ／ＬＣＰ及びＰＰＰ／ＥＡＰパケットとともに、ＰＰＰ／ＣＨＡＰパケットも送信するように動作可能である
ことを特徴とする請求項４６に記載のシステム。
【請求項５０】
ＭＩＰｖ６ハンドインを要求する、前記移動ノードは、ＰＰＰ／ＣＨＡＰを使用するＣＳＤ−ＰＰＰを選択して、同時に、ＰＰＰ／ＬＣＰを処理するように動作可能である
ことを特徴とする請求項４９に記載のシステム。
【請求項５１】
前記ＡＡＡインフラストラクチャを介する、前記移動ノードと前記ホームネットワーク間のＤＨＣＰ交換に基づいて、グローバルＩＰｖ６アドレスを割り当てる手段を更に備える
ことを特徴とする請求項２７に記載のシステム。
【請求項５２】
インタフェースＩＤ割当用のＰＰＰのＮＣＰ（ＩＰｖ６ＣＰ）フェーズと、ＩＰｖ６アドレスのグローバルプレフィックスを取得するためのＩＰｖ６ルータ勧誘／広告に基づいて、ＩＰｖ６アドレスコンフィグレーションを実行する手段を更に備える
ことを特徴とする請求項２７に記載のシステム。
【請求項５３】
ＣＤＭＡフレームワーク内のモバイルＩＰバージョン６（ＭＩＰｖ６）ハンドインのためのシステムであって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク内のＡＡＡサーバ間で、ＡＡＡインフラストラクチャを介して、ＣＨＡＰ認証を実行する手段を備える
ことを特徴とするシステム。
【請求項５４】
ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートするＡＡＡホームネットワークサーバ（３４）であって、
ホームエージェント（３６）を移動ノード（１０）へ割り当てる手段と、
前記移動ノードと前記ホームエージェント間でのセキュリティアソシエーションの確立のために、信用証明関連データを、前記移動ノードと前記ホームエージェントそれぞれへ配信する手段と
を備えることを特徴とするサーバ。
【請求項５５】
ホームアドレスを前記移動ノード（１０）へ割り当てる手段を備える
ことを特徴とする請求項５４に記載のサーバ。
【請求項５６】
選択されたＥＡＰ処理のラウンドトリップを使用して、前記移動ノード（１０）の前記ホームアドレスのコンフィグレーションを実行する手段を備える
ことを特徴とする請求項５５に記載のサーバ。
【請求項５７】
ＡＡＡフレームワークプロトコルアプリケーションを使用して、前記移動ノード（１０）の前記ホームアドレスを前記ホームエージェント（３６）へ送信する手段を備える
ことを特徴とする請求項５５に記載のサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野
本発明は、一般的には、移動通信に関するものであり、より詳しくは、ＣＤＭＡシステムにおけるモバイルＩＰバージョン６サービスのサポートに関するものである。
【０００２】
背景
モバイルＩＰ（ＭＩＰ）は、最小限のサービス中断（disruption）で、移動ノードに、インターネットとの自身の接続ポイントを変更することを可能にする。ＭＩＰ自身では、異なる管理ドメインに渡る移動性（mobility）について特有のサポートは提供しない。これは、大規模の商用配備において、ＭＩＰの適用性を制限するものである。
【０００３】
モバイルＩＰバージョン６（ＭＩＰｖ６）プロトコル［１］は、ノードにインターネットトポロジー内での移動を可能にしながら、到達可能性を維持し、かつ対応するノードとの接続を係属する。この状況では、各移動ノードは、ＩＰｖ６インターネットとの自身の現在の接続ポイントに関係なく、常に自身のホームアドレスによって識別される。自身のホームネットワークから離れる状況では、移動ノードは気付アドレス（ＣｏＡ：care-of address）にも関連付けられている。これは、移動ノードの現在の位置についての情報を提供する。移動ノードのホームアドレスにアドレス指定されているＩＰｖ６パケットは、自身の気付アドレスに対して、多から少から透過的（トランスペアレント）に転送される。ＭＩＰｖ６プロトコルは、ＩＰｖ６ノードに、移動ノードのホームアドレスと自身の気付アドレスとのバインディング（binding：結合）をキャッシュして、その後、その気付アドレスへ、移動ノード宛てのパケットを送信することを可能にする。つまり、移動ノードは、移動する毎に、いわゆるバインディング更新を自身のホームエージェント（ＨＡ）と、それを通信する対応するノードに送信する。
【０００４】
ＭＩＰｖ６機能を有する移動ノードには、セルラー電話、ラップトップおよび他のエンドユーザ端末があり、これらは、自身のホームサービスプロバイダが属するネットワーク間ばかりでなくそれ以外のものとの間でローミングすることができる。異質のネットワーク内でのローミングは、オペレータ間で存在するサービスレベルとローミングアグリーメント（協定）を受けて可能となる。ＭＩＰｖ６は、単一の管理ドメイン内でのセッション継続性を提供するが、これは、認証、認可及びアカウンティング（ＡＡＡ）インフラストラクチャの利用可能性に依存した上で、異なる管理ドメインに渡って自身のサービスセッションを提供する。即ち、ホームオペレータによって管理されるネットワークの外部のローミングの場合である。
【０００５】
モバイルＩＰｖ６は完全な移動性プロトコルとみなすことができ、大規模配備を可能にするために、ＭＩＰｖ６の配備を容易にするより改良されたメカニズムがいまだなお必要とされている。特に、ＣＤＭＡシステム、例えば、ＣＤＭＡ２０００において、ＭＩＰｖ６の使用を容易にするソリューションは、この点が欠けている。今日の３ＧＰＰ２２  ＣＤＭＡ２０００フレームワークでは、モバイルＩＰｖ４の動作と、単純なＩＰｖ４／ＩＰｖ６の動作を説明している［２］。しかしながら、モバイルＩＰｖ６の動作に対応する仕様は存在せず、また、３ＧＰＰ２がどのようにしてＭＩＰｖ６に適合するかについてはまだ定義されていない。このように、ＣＤＭＳ２０００で、モバイルＩＰｖ６の動作を可能にするソリューションは、かなり要望されている。その結果、認証に関する事項についての適切なメカニズムは重要である。また、スムーズなモバイルＩＰｖ６動作を可能にするために、ＭＮが新規のドメインに移動して、新規の認可済ＣｏＡを取得する際に、ＭＮが一時的に到達不可能（unreachable：圏外）となる場合のハンドオフ回数を少なくすることが要望されている。
【０００６】
つまり、ＭＩＰｖ６認証メカニズムに対して重要な要求事項が存在している。このメカニズムとは、ＣＤＭＡ２０００及び同様のＣＤＭＡフレームワークに対して適したものであり、特に、比較的少ないハンドオフ／セットアップ回数を可能にするメカニズムに対して適したものである。
【０００７】
要約
本発明の一般的な目的は、ＣＤＭＡシステム内でＭＩＰｖ６サービスをサポートすることである。本発明の特別な目的は、ＣＤＭＡ２０００及びＣＤＭＡｏｎｅのようなフレームワーク内でＭＩＰｖ６認証及び認可の少なくとも一方を可能にすることである。別の目的は、ＣＤＭＡシステム内でＭＩＰｖ６通信に対する、パケットデータセッションセットアップ回数を改善することである。また、本発明の目的は、ＣＤＭＡフレームワーク内でＭＩＰｖ６ハンドイン用の一般的なメカニズムを提供することである。
【０００８】
これらの目的は、請求項に従って達成される。
【０００９】
本発明は、基本的には、ＣＤＭＡフレームワーク内で、ＭＩＰｖ６用の認証及び認可のサポートに関するものであり、これは、訪問先ネットワーク内の移動ノードと、移動ノードのホームネットワーク間でのエンドツーエンド（end-to-end）処理において、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報を送信することに基づいている。ＭＩＰｖ６関連情報は、典型的には、認証、認可及びコンフィグレーション情報の少なくとも１つ備えていても良い。認証プロトコルは、拡張認証プロトコルであることが好ましいが、完全に新規に定義されるプロトコルも使用することができる。
【００１０】
好ましくは、エンドツーエンド処理は、必要な場合には、ホームエージェントとの適切な対話を伴って、移動ノードと、ホームネットワークのＡＡＡサーバ間で実行される。訪問先ネットワークでは、下位レイヤのセットアップ後（無線リンクセットアップを含む）、ポイントツーポイント（point-to-point）通信が、例えば、移動ノードと、適切なＣＤＭＡ専用インターネット接続アクセスサーバ間で確立される。これには、例えば、パケットデータ提供ノード（ＰＤＳＮ）がある。アクセスサーバ／ＰＤＳＮは、次に、訪問先ネットワーク内のＡＡＡサーバと多かれ少なかれ直接的に、あるいはこれを介して、移動ノードのＭＩＰｖ６認証及び認可のために、ＡＡＡホームネットワークサーバと通信する。
【００１１】
例えば、本発明は、拡張認証プロトコルに対する基礎として、拡張可能認証プロトコル（ＥＡＰ）を使用する。これは、典型的には、ＥＡＰ下位レイヤ（群）を維持しながら、ＥＡＰ拡張を生成する。これは、通常、ＭＩＰｖ６関連情報がＥＡＰプロトコルスタック内の追加データとして組み込まれることを意味する。
【００１２】
認証プロトコルは、ＰＰＰ（ポイントツーポイントプロトコル）、ＣＳＤ−ＰＰＰ（回線交換データＰＰＰ）、あるいはＰＡＮＡ（ネットワークアクセス認証用搬送プロトコル）によって、移動ノードとアクセスサーバ（ＰＤＳＮ）間を搬送されることが好ましい。また、認証プロトコルは、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒ及びＲａｄｉｕｓのようなＡＡＡフレームワークプロトコルアプリケーションによって、アクセスサーバ（ＰＤＳＮ）とＡＡＡホームネットワークサーバ間を搬送されることが好ましい。
【００１３】
移動ノードとアクセスサーバ（ＰＤＳＮ）間のポイントツーポイント通信の開始及びコンフィグレーションは、例えば、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用することによって達成されることが好ましい。ここで、ＣＳＤ−ＰＰＰの使用は、ラウンドトリップの回数を著しく削減する。つまり、パケットデータセッションセットアップ時間を短縮する。効果的なことは、アクセスサーバ（ＰＤＳＮ）が、最初に、ＰＰＰの代替として、ＣＳＤ−ＰＰＰを使用する可能性があることを移動ノードへ提示する。これは、例えば、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される。移動ノードは、ＰＰＰとＣＳＤ−ＰＰＰの間での選択を行うことができる。移動ノードがＰＰＰを使用することを選択する場合、ＰＰＰ／ＬＣＰでないメッセージは無視する。移動ノードがＣＳＤ−ＰＰＰを使用することを選択する場合、ＬＣＰ（リンク制御プロトコル）、ネットワーク認証及びＮＣＰ（ネットワーク制御プロトコル）フェーズを、同時に処理することができる。
【００１４】
ＭＩＰｖ６認証及び認可の少なくとも一方について主に３つの状況に区別され、これには、ＭＩＰｖ６の開始、ＭＩＰｖ６ハンドイン及びＭＩＰｖ６再認証がある。ＭＩＰｖ６に適合しているＥＡＰ拡張は、ＭＩＰｖ６の開始及び再認証に対して使用することが好ましく、一方、ＣＨＡＰ（チャレンジハンドシェイク認証プロトコル）の使用は、ＭＩＰｖ６認証を伴うＭＩＰｖ６に対して有効に働くことになる。
【００１５】
本発明によれば、ＣＤＭＡフレームワーク内のＭＩＰｖ６認証について完全で総括的なソリューションが初めて達成される。一方で、従来技術では、互いに首尾一貫しない部分的なソリューションのみが存在している。このような状況でＣＳＤ−ＰＰＰを採用することによって、パケットデータセッションセットアップ時間を著しく短縮することができる。また、ＥＡＰ拡張のような認証プロトコル拡張に依存することは、合理化されたソリューションを提供し、これは、後方互換性問題を最小限にして管理可能であり、かつ的確である。ＥＡＰの使用は、訪問先ネットワーク内のＡＡＡコンポーネントに、ＭＩＰｖ６処理について不可知とすることを可能にし（即ち、これは、訪問先ネットワーク内のＭＩＰｖ６サポートの依存性を解消する）、また、単なるパススルーエージェント（群）として動作することを可能にする。これは、ＨＡがホームネットワーク内に存在する場合が少なくとも含まれる。
【００１６】
提案するソリューションは、例えば、３ＧＰＰ２仕様に従って、ＣＤＭＡ２０００内のＭＩＰｖ６認証に対して特に適しているが、ＣＤＭＡｏｎｅあるいは将来のＣＤＭＡフレームワークのような他のフレームワークで使用されても良い。
【００１７】
詳細説明
本明細書で使用する略語のリストを、この詳細説明の最後に提示している。
【００１８】
図１はモバイルＩＰアクセス用の一般的な３ＧＰＰ２基準モデルを示している。移動局が、ソースＲＮとサービス提供（serving）ＰＤＳＮからターゲットＲＮとターゲットＰＤＳＮへのハンドオーバする状況が示されている。図１のＡＡＡサーバは、ＲＡＤＩＵＳサーバとして例示されているが、他のＡＡＡサーバに置き換えることも可能であり、これには、Ｄｉａｍｅｔｅプロトコルに従って動作するサーバが含まれる。
【００１９】
図２は、本発明を使用することが可能な、モバイルＩＰアクセス用のＣＤＭＡ通信システムの概要図である。図２のＣＤＭＡアーキテクチャは、図１のモデルを簡略化及び概念化したモデルとしてみることができる。自身が関係するホームネットワーク以外の外部／訪問先ネットワークにローミングする移動ノード（ＭＮ）１０が示されていて、これには、例えば、セルラー電話、ラップトップあるいはＰＤＡがある。訪問先ネットワークでは、ＭＮ１０は、無線ネットワーク（ＲＮ）２１を介してパケットデータ提供ノード（packet data serving node）（ＰＤＳＮ）２２として例示されるインターネット接続（internetworking）アクセスサーバと通信する。このサーバは、ＭＮ１０との物理的なレイヤ接続を管理する。インターネット接続アクセスサーバ２２は、移動体とＩＰネットワーク間のインターネット接続を提供し、また、ある意味では、外部エージェントとして動作するＡＡＡクライアントに見合うものである。ＰＤＳＮはＣＤＭＡ２０００で使用される専用ノードであり、これと等価なものを、他のＣＤＭＡフレームワークで見つけることができる。つまり、ＰＤＳＮは、典型的には、ＭＮ１０に対して、認証、認可及びアカウンティング（accounting）を開始する。
【００２０】
図２に示されるように、ＰＤＳＮ２２は、１つ以上のＡＡＡサーバ２４、３４を備えるＡＡＡインフラストラクチャを介して、ＭＮ１０のホームネットワーク内のホームエージェント（ＨＡ）３６と接続する。ＨＡ３６は、典型的には、ユーザのサービスプロバイダによって維持されていて、これは、例えば、ユーザ登録及びＰＤＳＮへのパケットのリダイレクションを管理する。ＡＡＡサーバの全体的な目的は、ＰＤＳＮと他のＡＡＡサーバと対話して、移動クライアントに対する認可、認証及び（オプションとしての）アカウンティングを実行する。これには、通常、ＭＮ１０とＨＡ３６間で達成することができるセキュリティアソシエーションによるメカニズムの提供を含んでいる。
【００２１】
モバイルＩＰの認証及び認可は、通常は、次の基本ステップを介在する。ＭＮ１０は、近隣のＰＤＳＮ／外部エージェント２２と接続する。一方、ＰＤＳＮは、アクセスリクエストメッセージを用いて、通常は、ＡＡＡｖサーバ２４を介して、ＡＡＡｈサーバ３４とコンタクトをとり、ユーザを認証して、適切なトンネリングパラメータ、ＩＰアドレス等を取得する。認証が成功すると、ＡＡＡサーバ（群）はユーザを認可し、ＭＮ１０とＨＡ３６間のセキュリティアソシエーションを確立することができる。これで、通常は、ＨＡ３６はＩＰアドレスを割り当て、ユーザトラフィックを転送する。
【００２２】
我々が知る限りは、ＭＩＰｖ６の認証及び認可の一方をサポートするための完全なソリューションは従来には存在していない。エンドツーエンドＡＡＡの繋がりのターゲットとする部分についてはいくつかの提案（例えば、ＡＡＡクライアントとＡＡＡサーバ間の一部について［３］、ＭＮとＡＡＡクライアント間の一部についてＰＡＮＡ［４］プロトコル）があるが、これらの部分的なソリューションは、互いに首尾一貫しているものではなく、また、エンドツーエンドで動作しない。また、［３］の従来のメカニズムは、認証方法を理解し、かつＭＮとＡＡＡｈ間でのＭＩＰｖ６関連データの交換の内容を認識するために、ＡＡＡクライアントとＡＡＡｖを必要とする。このようなソリューションでは、ＭＮとＡＡＡｈ間での事前の暗号化を適用することができず、システムは、盗聴、中間者攻撃及びその類にさらされる危険が高くなる。
【００２３】
特に、上述の背景セクションでは、ＣＤＭＡ２０００のようなフレームワークにおいて、ＭＩＰｖ６認証及び認可の少なくとも一方についてのメカニズムは従来には存在しておらず、そのようなメカニズムについての必要性、特に、比較的少ないハンドオフ／セットアップ回数に関係するメカニズムについての必要性がかなり求められている。
【００２４】
この要求を満足するために、本発明は、ＡＡＡインフラストラクチャを介して、訪問先ネットワークの移動ノードと移動ノードのホームネットワーク間でのエンドツーエンド処理で認証プロトコルを採用することを提案する。このプロトコルの好ましい組み合わせは、上述のＰＰＰ、ＣＳＤ−ＰＰＰ、ＰＡＮＡ及びＤｉａｍｅｔｅｒ／Ｒａｄｉｕｓプロトコルがあり、この新規な方法で、ＣＤＭＡ２０００のようなＣＤＭＡシステムに対して適切な認証及び認可処理の少なくとも一方を達成する。ＭＩＰｖ６関連情報は、好ましくは、認証、認可及びコンフィグレーション（configuration：構成）情報の少なくとも１つを有し、この情報は、移動ノードとホームエージェント間でのＭＩＰｖ６セキュリティアソシエーション（即ち、セキュリティリレーション）あるいはバインディングを確立するためのＡＡＡインフラストラクチャを介して送信される。
【００２５】
好ましくは、エンドツーエンド処理が、必要であれば、ホームエージェントとの適切な対話を用いて、移動ノードとホームネットワークのＡＡＡサーバ間で実行される。図１３は、本発明に従うＡＡＡホームネットワークサーバの実施形態の概要ブロック図である。この例では、ＡＡＡｈサーバ３４は、基本的には、ホームアドレス割当モジュール５１、ホームエージェント（ＨＡ）割当モジュール５２、セキュリティアソシエーションモジュール５３、認可情報マネージャ５４及び入力−出力（Ｉ／Ｏ）インタフェース５５を備えている。モジュール５１は、ホームアドレス割当を実行することが好ましい（ホームアドレスが、移動ノードにおいて構成され、かつＨＡに送信されない限り）、モジュール５２は、適切なホームエージェント（ＨＡ）の割当及び再割当を行うために動作可能である。ＡＡＡｈサーバ３４は、典型的には、移動ノードから、キーシード及びバインディング更新（ＢＵ）も受信する。選択的には、ＡＡＡｈサーバ３４は、キーシード自身を生成し、それを移動ノードへ送信する。セキュリティアソシエーションモジュール５３は、シードに応じて必要なセキュリティキーを生成し、かつそのキーを安全にＨＡへ送信する。バインディング更新（ＢＵ）は、ホームエージェント（ＨＡ）へも送信され、そうすることで、ＨＡは、移動ノードの気付アドレス（care-of address）を用いてホームアドレスのバインディングをキャッシュすることができる。ＡＡＡｈサーバは、ＩＰＳｅｃ情報のような情報を、セキュリティアソシエーションを完成するために、ＨＡから受信しても良い。この情報とともに、他の収集された認可（及び／あるいはコンフィグレーション）情報は、移動ノードへの次の送信のために、オプションの認証情報マネージャ５４に記憶されても良い。
【００２６】
訪問先ネットワークでは、ポイントツーポイント通信が、典型的には、移動ノードと、ＰＤＳＮのような適切なインターネット接続アクセスサーバとの間で確立される。このサーバは、例えば、移動体とＩＰネットワーク間で必要なインターネット接続を提供する。図１２は、このようなインターネット接続アクセスサーバの実施形態のブロック図である。このインターネット接続アクセスサーバ２２は、例えば、ＰＰＰあるいはＣＳＤ−ＰＰＰを介して、移動ノードと通信するためのモジュール４１と、ＡＡＡサーバと同様のノードと通信するためのモジュール４２を備える。
【００２７】
認可フェーズは、通常、明示的な認可を含んでいるが、介在するノードのコンフィグレーションを含んでいても良い。それゆえ、移動ノードのコンフィグレーション及びＨＡのコンフィグレーションの少なくとも一方のような、ＭＩＰｖ６関連コンフィグレーションは、通常、全体の認可処理の一部としてみなされる。
【００２８】
用語「ＡＡＡ」は、インターネットドラフト、ＲＦＣ及び他の標準化文献での、それ自身の一般的な意味の範疇にあるとされるべきである。典型的には、ＡＡＡ（認可、認証及びアカウンティング）インフラストラクチャの、認証及びセキュリティキーアグリーメントは、対称暗号技術に基づいていて、これは、移動ノードと、ホームネットワークオペレータあるいは信用機関の間で共有されるシークレットが最初から存在することを意味するものである。いくつかの状況及び用途では、例えば、ＡＡＡインフラストラクチャのアカウンティング機能は、無効にされるあるいは実現されない場合がある。ＡＡＡインフラストラクチャは、一般的には、１つ以上のＡＡＡサーバを、ホームネットワーク及び訪問先ネットワークの少なくとも一方に含んでいて、また、１つ以上のＡＡＡクライアントを含んでいても良い。オプションとしては、ＡＡＡインフラストラクチャに含まれる１つ以上の中間ネットワークを存在させることもできる。
【００２９】
以下では、ＣＤＭＡフレームワークにおいて、ＭＩＰｖ６認証及び認可の少なくとも一方についてのいくつかの基本構成を、ＭＩＰｖ６の主要な３つの状況、ＭＩＰｖ６の開始、ＭＩＰｖ６ハンドイン、ＭＩＰｖ６再認証を参照して説明する。
【００３０】
ＭＩＰｖ６の開始については、利用可能なＭＩＰｖ６サービスが存在しない場合、無線リンクセットアップを含む下位レイヤコンフィグレーションが実行され、次に、移動ノードと、ＰＤＳＮあるいは訪問先ネットワーク内の等価ノードとの間のポイントツーポイント通信が開始され、かつ構成（コンフィグレーション）されなければならない。ポイントツーポイント通信のコンフィグレーションは、例えば、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用することによって達成されることが好ましい。ＣＳＤ−ＰＰＰの使用は、ラウンドトリップの数をかなり削減し、かつパケットデータセッションセットアップ回数を少なくする。
【００３１】
本発明は、ＭＩＰｖ６関連データを送信する拡張認証プロトコルに対する基礎として、拡張認証プロトコルを使用することが好ましい、これは、以下では、このような拡張プロトコルによってまず例示される。例えば、本発明は、拡張認証プロトコルに対する基礎として、拡張可能認証プロトコル（ＥＡＰ）を使用しても良く、これは、認証、認可及びコンフィグレーションの少なくとも１つに対するＭＩＰｖ６関連情報をＥＡＰプロトコルスタック内の追加データとして組み込んでいる。但し、最初から構築される認証プロトコルも本発明の範囲に含まれることが強調されるべきである。
【００３２】
移動ノードと、ＰＤＳＮあるいはそれと同等のノードとの間の通信が一旦構成されると、拡張認証プロトコルが、例えば、ＰＰＰ、ＣＳＤ−ＰＰＰ、あるいはＰＡＮＡによって、移動ノードとＰＤＳＮ間で搬送することができ、また、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒ及びＲＡＤＩＵＳのようなＡＡＡフレームワークプロトコルアプリケーアプリケーションによって、ＡＡＡホームネットワークサーバへ搬送することができる。
【００３３】
ＩＰアドレス割当目的のために、例えば、ＩＰアドレス割当用にＤＨＣＰを使用することができる。選択的には、ＰＰＰ／ＣＳＤ−ＰＰＰのＮＣＰ（ＩＰｖ６ＣＰ）フェーズを、インタフェース−ＩＤ割当用に使用することができ、また、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するためのＩＰｖ６ルータ勧誘（solicitation）／広告用に使用することができる。ＩＰｖ６における一般的な情報あるいはアドレスコンフィグレーションについては、［５］で参照される。
【００３４】
ＭＩＰｖ６ハンドインに対しては、継続することを可能にするための進行中のＭＩＰｖ６サービスに対して必要なベアラー（bearer）の再確立を必要とするハンドオーバが存在する場合に、ポイントツーポイント通信のコンフィグレーション用、かつプロトコルキャリヤとして、例えば、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用して、認証用にＣＨＡＰプロトコルを使用することが有効となる。
【００３５】
ＭＩＰｖ６再認証に対しては、例えば、移動ノードとホームエージェント間の信用関係が満了する場合、移動ノードとＰＤＳＮ間で、既に確立したポイントツーポイント通信が通常存在する。ＭＩＰｖ６の開始の場合と同様に、拡張認証プロトコルは、移動ノードとＰＤＳＮ間を、ＰＰＰあるいはＰＡＮＡによって搬送されることが好ましい。また、ＡＡＡインフラストラクチャ内のＤｉａｍｅｔｅｒ及びＲＡＤＩＵＳのようなＡＡＡフレームワークプロトコルアプリケーアプリケーションによって、ＡＡＡホームネットワークサーバへ搬送されることが好ましい。
【００３６】
上述したように、拡張認証プロトコル（例えば、拡張ＥＡＰ）は、例えば、ＭＮ１０とＰＤＳＮ２２（あるいは対応ノード）間を、ＰＡＮＡあるいはＰＰＰによって搬送することができる。選択的には、ＩＥＥＥ８０２．１Ｘ［６］のような、満足のゆく下位レイヤ順序付（ordering）保証に関連付けられている他の搬送プロトコルを、拡張認証プロトコルを搬送するために使用することができる。３ＧＰＰ２  ＣＤＭＡ２０００システムに対しては、ＥＡＰ［７］に対してＣ２２７［１６進数］に設定されているプロトコルフィールド値を有する、ＰＰＰデータリンクレイヤプロトコルカプセル化を使用することができる。
【００３７】
本発明はＣＤＭＡ２０００に対してかなり有効であるが、例えば、ＣＤＭＡ  Ｏｎｅ及び、ＣＤＭＡ技術に基づく他（現在あるいは将来）のフレームワーク／動作モードのような他のフレームワークに使用することもできることが強調されるべきである。
【００３８】
以下の段落では、拡張認証プロトコル（例えば、拡張ＥＡＰ）及びＣＨＡＰの少なくとも一方に対する、ポイントツーポイント通信のコンフィグレーション用及び／あるいはキャリヤとして、上述のＰＰＰ及びＣＳＤ−ＰＰＰプロトコルを使用する一般的な構成のいくつかを説明する。
【００３９】
３ＧＰＰ２  ＣＤＭＡ２０００内では、ＰＰＰ［８］は、移動体と単純ＩＰ動作の両方とに関連して、パケットデータセッションのセットアップ用に使用することができる。ここで、必要なＰＰＰ交換は、ハンドオフ中の遅延臨界経路（delay critical path）に入っている。３ＧＰＰ２  ＣＤＭＡ２０００で特定されるＰＰＰの使用は、単純ＩＰｖ４／ＩＰｖ６動作とモバイルＩＰｖ４動作の場合とは異なっている。単純ＩＰｖ４／ＩＰｖ６動作に対しては、ＰＰＰの認証フェーズはＣＨＡＰ認証用に使用され、一方、ＰＰＰのＮＣＰ（ＩＰＣＰ／ＩＰｖ６ＣＰ［９］）フェーズはＩＰアドレス割当用に使用される。モバイルＩＰｖ４動作に対してはＰＰＰ内では実行される認証フェーズはなく、また、ＰＰＰのＮＣＰ（ＩＣＰ）フェーズでリクエストされるＩＰアドレスはない。
【００４０】
従来技術では、ＣＤＭＡシステムのモバイルＩＰｖ６動作に対する、ＰＰＰの使用に関して作成されている仕様／定義は存在しない。しかしながら、モバイルＩＰｖ６動作に対するＰＰＰの使用についてのソリューションにおける強い要求事項として、それらが現在のＰＰＰ使用との後方互換性を少なくとも持つことがある。この要求事項は、本発明のいくつかの効果的な実施形態に従って満足することになり、これは、ＣＤＭＡシステムにおけるモバイルＩＰｖ６サポートに関してＣＳＤ−ＰＰＰの使用を導入する。現在のＰＰＰ使用についての相互運用性を確実にすることに加えて、同位（peer）のプロトコルエンティティ同士がＣＳＤ−ＰＰＰに従って適合できる場合において、ＣＳＤ−ＰＰＰは、コンフィグレーション時間を劇的に短縮する。
【００４１】
基本的には、この短縮されたコンフィグレーション時間は、ＰＰＰを変更することによって達成される。基本概念は、２つのＣＳＤ−ＰＰＰ同位（peers）が通信している場合、ＬＣＰの厳格な分割、認証及びＰＰＰのＮＣＰフェーズが、匿名性を必要としないことである。つまり、ＬＣＰ、認証及びＮＣＰフェーズは、全体のＰＰＰコンフィグレーション時間を短縮するために同時に行うことができる。また、一方のＰＰＰピア（同位）はＣＳＤ−ＰＰＰに従って変更され、他方のＰＰＰピアは変更されないので、変更されたピアはＰＰＰに従うためにフォールバックされることになる。これは、ＰＰＰコンフィグレーション時間を増減しない方法で実行される。一般的なＣＳＤ−ＰＰＰメカニズムについての情報は、例えば、［１０］で参照することができる。
【００４２】
本発明のより良い理解のために、本発明の実施形態に従う拡張認証プロトコルの例を説明する。これらの例示の実施形態は、拡張認証プロトコルを基礎としてＥＡＰを使用する。これは、典型的には、ＥＡＰ下位レイヤ（群）を維持しながら、ＥＡＰ拡張を生成する。しかしながら、本発明はこれに限定されず、他の一般的な認証プロトコルを同様に拡張しても良いことが理解されるべきである。特定のＥＡＰの場合に対しては、ＭＩＰｖ６関連情報は、典型的には、１つ以上のＥＡＰ属性（群）によって、通常、ＥＡＰプロトコルスタックの追加データとして組み込まれる。このようなＥＡＰ属性を実現するための様々なソリューションを、以下の「メソッド専用ＥＡＰ属性」と「汎用コンテナ属性」のセクションで説明する。
【００４３】
メソッド専用ＥＡＰ属性
本発明の一実施形態に従えば、ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタックのＥＡＰメソッドレイヤ内のＥＡＰ属性として送信される。新規の（拡張）ＥＡＰ認証プロトコルは、ＭＩＰｖ６認証に対するメソッドを搬送するために定義される。拡張ＥＡＰプロトコルは、好ましくは、ＭＩＰｖ６認証のネゴシエーション／実行を可能にしなければならず、また、いくつかの補助情報をサポートしても良い。この補助情報は、例えば、動的ＭＮホームアドレス割当、動的ＨＡ割当、ＨＡとＭＮ間でのセキュリティキーの配信、ＰＡＮＡセキュリティ用に、ＰＡＣとＰＡＡ間でのセキュリティキーの配信を容易にする。
【００４４】
新規のＥＡＰ属性は、例えば、新規のＥＡＰ  ＴＬＶ属性とすることができ、また、例示するプロトコルの詳細を、全体フロー及び概念の実行可能性を示すために提供する。
【００４５】
以下のＥＡＰ−ＴＬＶは、新規のＥＡＰ  ＴＬＶの例であり、これらは本発明の拡張ＥＡＰプロトコルの下で定義することができる。
【００４６】
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 暗号技術 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属性：
これは、認証が成功している場合に、ＭＮに対して、動的に割り当てられるＨＡのアドレスに対するリクエストを示している。これは、認証され、与えられるＭＩＰｖ６サービスをＭＮが最初にリクエストする場合に、ＭＮによってＡＡＡｈからリクエストされる。ＨＡ割当が既に存在する場合、例えば、ＭＩＰｖ６プロトコルの動的ＨＡディスカバリ（探索：discovery）方法がＨＡを割り当てるために使用される場合、あるいはＭＮが既に、予め割り当てられたＨＡ（例えば、ＭＩＰｖ６ハンドオフ中）を持っている場合、この属性は、通常、オプションとして定義される。
【００５５】
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）を表１に示す。
【００７１】
2006527968.tif 000003
【００７２】
本発明に従う、ＭＩＰｖ６の開始を処理するためのスキーム例が、図３及び図４のシグナリング（信号送受信）フローで提供される。ＭＮ、アクセスルータ、ＡＡＡｈ及びＨＡ間で、上述で例示のＥＡＰ  ＴＬＶ属性を使用して実現されるＭＩＰｖ６関連情報の送信が示される。アクセスルータは、例えば、ＰＤＳＮ機能を備えることができ、これについては、ＡＡＡクライアント機能に対応するものである。用語「ＥＡＰ／ＭＩＰｖ６」は、新規の拡張ＥＡＰプロトコルを意味するものであり、本発明の実施形態では、ＡＡＡインフラストラクチャを介して、ＭＩＰｖ６関連情報を送信するために使用される。図３及び図４の特定の例は、搬送プロトコルとして、ＰＡＮＡ及びＤｉａｍｅｔｅｒの組合わせを使用するＭＩＰｖ６ＡＡＡに関連するものであるが、本発明は、後述の図５−図１１のフロー図で明らかとなるものに限定されるものではない。図３のフロー図は、ＨＡ−ＭＮ事前共有キーの交換のための［１２］に従うＡＡＡｈ−ＨＡインタフェースを使用する、ＭＩＰｖ６の開始を示している。図４に示される、ＭＩＰｖ６の開始メカニズムの別の実施形態は、ＨＡ−ＭＮ事前共有キーの交換のために、ＩＫＥキーＩＤを使用する。
【００７３】
汎用コンテナ属性
本発明の別の実施形態では、ＭＩＰｖ６関連情報は、汎用コンテナＥＡＰ属性で搬送される。これは、任意のＥＡＰパケットに含まれる任意のＥＡＰメソッドとともに使用できることが好ましい。つまり、ＥＡＰは、汎用コンテナ属性（ＧＣＡとも呼ばれる）で増やされる。この汎用コンテナ属性は、非ＥＡＰ関連データ、より詳しくは、ＭＩＰｖ６関連データを、ＭＮ１０とＡＡＡｈ３４間で搬送するために使用することができる。これは、ＭＮとＡＡＡｈに、アクセスネットワーク、ＰＤＳＮ／ＡＡＡクライアント及びＡＡＡｖ２４を含む訪問先ドメインに対してトランスペアレントとなる方法で通信することを可能にする。つまり、メソッド専用ＥＡＰ−ＴＬＶ属性での場合で上述されたように、ＡＡＡインフラストラクチャは、好ましくは、訪問先ドメインに対してトランスペアレントとなる方法で、ＭＩＰｖ６関連特性をサポートするために利用される。このソリューションは、例えば、ホームネットワーク（ホームネットワークプレフィックスを含む）内での動的ＨＡ割当、ＭＮ−ＨＡ信用証明の配信、ＭＩＰｖ６メッセージカプセル化、ネットワークアクセスとＭＩＰｖ６用の単一の認証エンティティ、及びステートフル（stateful：状態把握による）動的ホームアドレス割当の少なくとも１つをサポートすることができる。
【００７４】
汎用コンテナ属性を使用する場合、新規のＥＡＰメソッドを生成することなく、ＥＡＰを、ＭＩＰｖ６関連データのキャリヤとして使用することが好ましい。しかしながら、別の変形は、プロトコルスタックのメソッドレイヤ上の１つ（あるいはそれ以上）のＥＡＰメソッド（群）に汎用コンテナ属性を導入することである。これによって、ＭＩＰｖ６関連データの送信用の新規のＥＡＰメソッドが定義され、かつ汎用コンテナ属性がこの新規のＥＡＰメソッドで使用される。換言すれば、汎用コンテナ属性は、ＥＡＰ  ＴＬＶ属性に関係して説明される方法と同様の方法で、メソッド専用とすることができる。
【００７５】
上述のように、ＥＡＰは、ＡＡＡフレームワークプロトコルで、ＰＤＳＮ／ＡＡＡクライアント２２とＡＡＡｈ３４間を搬送されることが好ましい。このＡＡＡフレームワークプロトコルは、例えば、Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーション［１３］あるいはＲａｄｉｕｓ［１４，１５］がある。しかしながら、ＡＡＡｈ３４とＨＡ３６間でＡＡＡ及びＭＩＰｖ６データを交換するために、新規の／拡張Ｄｉａｍｅｔｅｒアプリケーション（あるいは新規の属性で拡張されたＲＡＤＩＵＳ）を使用することも提案される。このＤｉａｍｅｔｅｒアプリケーションは、既存のＤｉａｍｅｔｅｒの拡張バージョン、例えば、Ｄｉａｍｅｔｅｒ  ＥＡＰアプリケーション［１３］、あるいは新規のＤｉａｍｅｔｅｒアプリケーションとすることができる。この新規の／拡張Ｄｉａｍｅｔｅｒアプリケーション（あるいは、拡張ＲＡＤＩＵＳ）は、以下では、「Ｄｉａｍｅｔｅｒ  ＭＩＰｖ６アプリケーション」と呼ぶことにする。これは、説明を簡単にするためだけに使用されるものであり、また、拡張ＲＡＤＩＵＳあるいは、ＡＡＡｈ−ＨＡ通信用の他の方法の使用を除外するものではないことが強調されるべきである。
【００７６】
ホームエージェントとホームアドレスの割当を含み、本発明に従う汎用コンテナ属性を使用する認証処理を扱う好ましい方法を、主に、例として図２で参照するＥＡＰプロトコルを使用して説明する。
【００７７】
認証処理中には、ＭＮ１０は、自身がホームネットワークで割り当てられるＨＡ３６を持ちたいことを、汎用コンテナ属性を介してＡＡＡｈ３４に指示する。ここでは、想定することとして３つの場合が存在する。
【００７８】
Ａ）ＭＮが、既に、有効なホームアドレスを持っている。
【００７９】
Ｂ）ステートフル動的ホームアドレス割当が使用されている。
【００８０】
Ｃ）ステートフルホームアドレス自動コンフィグレーションが使用されている。
【００８１】
ＭＮ１０が既にホームアドレスを持っている場合（Ａ）、ホームエージェントアドレス用のリクエストとともにそれがＡＡＡｈ３４に送信される。ＡＡＡｈがホームアドレスが有効であると判定する場合、ＨＡ３６を選択し、ＭＮ−ＨＡ信用証明を生成する。これには、事前共有キーあるいは事前共有キーから導出することができるデータがある。ＭＮのホームアドレスと、生成されたＭＮ−ＨＡ信用証明は、例えば、Ｄｉａｍｅｔｅｒ  ＭＩＰｖ６アプリケーションを介して、選択されたＨＡへ送信することができる。選択されたＨＡのアドレスと、生成された信用証明（あるいは、生成された信用証明から導出することができるデータ）は、拡張認証プロトコル、例えば、拡張ＥＡＰを介してＭＮへ送信される。例えば、事前共有キーがＭＮへ送信される場合、これは、ＡＡＡｈとＭＮ間のセキュリティリレーションから導出されるキー（例えば、認証処理中に生成されるセッションキー）によって、保護される（暗号化され、かつ完全性が保護される）必要がある。そうでなければ、事前共有キーは、明示的に送信されるべきでない。それに代えて、ＭＮ−ＡＡＡｈセキュリティリレーション、例えば、ナンスに基づいて事前共有キー（あるいは他の信用証明）から導出することができるデータの一部（例えば、ＥＡＰ  ＡＫＡ［１６］あるいはＥＡＰ  ＳＩＭ［１７］が使用される場合に、ＡＫＡあるいはＧＳＭ認証アルゴリズムに与えられるＲＡＮＤパラメータ）を送信することができる。暗号保護が信用証明に適用される場合、ＨＡアドレスとホームアドレスに対して、同種の保護を使用することは都合が良い場合がある。
【００８２】
ネットワークアクセス認証が完了し、かつＭＮが認証されて、アクセスサーバ（例えば、ＷＬＡＮ  ＡＰあるいはアクセスルータ）を介してネットワークへアクセスする場合、ＭＮは、取得される信用証明に基づくＩＫＥ（例えば、ＩＫＥｖ１あるいはＩＫＥｖ２）処理を介して、割り当てられたＨＡへ向けてのＩＰＳｅｃ  ＳＡ群を確立することができる。この処理と、その次のＢＵ／ＢＡ交換が、従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して実行される。
【００８３】
ＭＮがホームアドレスを含んでいない場合、あるいはホームエージェントに対する自身のリクエスト内でもはや有効でないホームアドレス（例えば、ＭＩＰｖ６ホームネットワーク再採番（renumbering）による）を含んでいる場合、ホームアドレスは、ＭＮに割り当てられるべきである。これに対して、本発明は、ステートフル動的アドレス割当（Ｂ）あるいはステートレス（stateless）ホームアドレス自動コンフィグレーション（Ｃ）を提案している。
【００８４】
本発明は、ステートフル動的ホームアドレス割当（Ｂ）を可能にし、これによって、ＡＡＡｈ３４は、ホームアドレスをＭＮ１０へ割り当てる。また、ＡＡＡｈは、ＭＮ−ＨＡ信用証明を生成し、これは、Ｄｉａｍｅｔｅｒ  ＭＩＰｖ６アプリケーションを介して、割当ホームドレスとともに選択されたＨＡ３６へ送信することが好ましい。また、ＡＡＡｈは、拡張ＥＡＰで例示される本発明の拡張認証プロトコルを介して、割当ＨＡのアドレスと、生成された信用証明（あるいはその生成された信用証明から導出することができるデータ）とともに割当ホームアドレスを、ＭＮへ送信する。（Ａ）の場合では、ＭＮ−ＨＡ信用証明は、拡張認証プロトコルを介して送信される前に保護される。あるいは、選択的には、信用証明から導出することができるデータ、例えば、ナンスが実際の信用証明の代わりに送信される。ネットワークアクセス認証が完了すると、ＭＮはＩＰＳｅｃ  ＳＡ群と確立することができ、かつ従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して、割当ＨＡへ向けてのＢＵ／ＢＡ交換を実行することができる。
【００８５】
ホームアドレスのステートレス自動コンフィグレーションが使用される場合（Ｃ）、動作は、選択されるＥＡＰメソッドのラウンドトリップの回数に依存する。ＨＡ３６に対するリクエストに応じて、ＡＡＡｈ３４は、信用証明（あるいは、信用証明から導出することができるデータ）とともにＨＡアドレスをＭＮ１０へ返信する。ＭＮは、典型的には、受信したＨＡアドレスのプレフィックスを使用して、ホームアドレスを構築する。ＥＡＰ処理が完了していない場合、即ち、ＨＡアドレスが、ＥＡＰ成功パケットでなく、ＥＡＰリクエストパケットで搬送された場合、ＭＮは、自身のホームアドレスをＡＡＡｈへ送信する。ＡＡＡｈは、次に、受信したホームアドレスを信用証明とともに、割当ＨＡへ送信する。次に、ＨＡは、自身のサブネット上で受信したホームアドレスに対してＤＡＤを実行すべきである。ＤＡＤが成功すると、ＭＮとＨＡは、その後、ＩＰＳｅｃ  ＳＡ群を確立し、従来のＩＫＥ及びＭＩＰｖ６メカニズムを使用して、ＢＵ／ＢＡ交換を実行することができるようになる。
【００８６】
これに代わって、ＭＮがＥＡＰ処理の最終パケット（即ち、ＥＡＰ成功パケット）でＨＡアドレスを受信する場合、自身で新規に構築するホームアドレスをＡＡＡｈへ搬送することはできない。ＥＡＰラウンドトリップの回数が十分でない問題を解決する方法は、汎用コンテナ属性の送信を可能にするためのＥＡＰ通知リクエスト／応答パケットを使用するＥＡＰラウンドトリップの回数を、ＡＡＡｈに増やさせることである。
【００８７】
上述のメカニズムの主な利点は、それらがＭＮ１０とＨＡ３６の両方のコンフィグレーションを簡略化することである。ＭＮは、自身のネットワークアクセスコンフィグレーションパラメータ（ＮＡＩと、ＭＮ−ＡＡＡｈセキュリティリレーション）を活用することができるので、ＭＩＰｖ６専用のコンフィグレーションは必要とされない。ＨＡは、任意のＭＮ専用コンフィグレーションを必要としない、これは、ＨＡ−ＡＡＡｈセキュリティリレーションが十分であるからである。ＡＡＡｈ３４は、大体において、ネットワークアクセスとＭＩＰｖ６の両方に対して、単一の認証エンティティを形成することができる（但し、ＩＫＥ認証は、依然として、ＡＡＡｈから受信されるデータに基づいてＨＡで実行される）。
【００８８】
有効なＭＮ−ＨＡセキュリティアソシエーション（例えば、ＩＰＳｅｃ  ＳＡ）が既に存在している場合、ＭＮ１０は、ＡＡＡｈ３４からのＨＡアドレスをリクエストする必要はない。その代わりに、汎用コンテナ属性にＢＵをカプセル化することによって、全体のアクセス遅延を減らし、また、カプセル化したものを拡張認証プロトコルを介してＡＡＡｈへ送信することができる。ＡＡＡｈは、ＢＵをＤｉａｍｅｔｅｒ  ＭＩＰｖ６アプリケーションメッセージにカプセル化し、また、それを、ＢＵの宛先アドレスによって示されるＨＡ３６へ送信することが好ましい。ＨＡはＢＡで応答し、そして、ＡＡＡｈはその応答をＭＮへ中継する。カプセル化ＢＵとＢＡは、ＭＮ−ＨＡ  ＩＰＳｅｃ  ＳＡ群によって保護される。実施形態に従えば、ＡＡＡｈは、ＨＡアドレスが有効であり、かつＭＩＰｖ６ホームネットワークが、ＢＵをＨＡへ送信する前に再採番されていないことをチェックする。ＨＡアドレスが有効とされるべきでないのは、ＡＡＡｈは、通常、エラーをＭＮへ指示し、かつ上述のようにＨＡを割り当てるからである。即ち、ＡＡＡｈは、ＨＡアドレス、信用証明（あるいは、信用証明から導出することができるデータ）及びおそらくはホームアドレスをＭＮ等へ送信する。
【００８９】
Ｄｉａｍｅｔｅｒ  ＭＩＰｖ６アプリケーションは、時には、ＨＡ３６内で生成されるアカウンティングデータを搬送するために使用されても良い。これは、リバーストンネルリング（reverse tunneling）が採用され、かつホームオペレータがＡＡＡｖ２４から受信されるアカウンティングデータを検証することを可能にすることを要望している場合に役立たせることができる。
【００９０】
ここで、本発明に従う汎用コンテナ属性（ＧＣＡ）のいくつかの実例を、より詳細に説明する。
【００９１】
好ましくは、ＧＣＡ属性は、すべての方法に利用することができ、また、任意のＥＡＰメッセージに含めることができる。このメッセージには、ＥＡＰ成功／失敗メッセージが含まれる。このことは、ＥＡＰメソッドレイヤ以外のＥＡＰレイヤの一部とするべきであることを意味するものである（［１８］参照）。これによって、考慮すべき重要な問題は、ＭＮとＥＡＰ認証器（典型的には、ネットワークアクセスサーバ（ＮＡＳ）内のＥＡＰエンティティ）による後方互換性である。上述の例における、この汎用コンテナ属性の使用は、新規の属性が、後方互換性があり、かつＥＡＰ認証器に対してトランスペアレントとなる方法でＥＡＰに導入されることを想定している。ＧＣＡをこれらのプロパティに導入することは、いくつかの特別な考慮が必要であり、これは、以下の段落で詳しく説明する。
【００９２】
例えば、ＧＣＡのフォーマットは、ＧＣＡ受信インジケータとＧＣＡペイロードに続く２バイトのＧＣＡレングス（長：length）インジケータとすることができる。ＧＣＡ受信インジケータは、どの内部エンティティへ、ＥＡＰモジュールが受信ＧＣＡのペイロードを送信するかについてを示すものである（即ち、このインジケータは、ＩＰヘッダ内のプロトコル／ネクストヘッダフィールド、あるいはＵＤＰ及びＴＣＰヘッダ内のポート番号に対応する）。ＧＣＡペイロードは、ＥＡＰレイヤによって解釈されないデータの汎用部分（generic chunk）となる。ＧＣＡの不在は、例えば、ゼロが設定されるＧＣＡレングスインジケータによって示される。
【００９３】
後方互換性を達成するために、パススルー（pass-through）ＥＡＰ認証器に対してトランスペアレントとなる方法で、ＧＣＡは、ＥＡＰパケットに含ませるべきである。パススルーＥＡＰ認証器は、ＮＡＳ内に存在するＥＡＰ認証器であり、これは、ＭＮとバックエンドＥＡＰ認証サーバ（ＡＡＡサーバ）間のＥＡＰパケットを中継する。ＥＡＰ認証器のパススルー動作は、ＥＡＰレイヤヘッダ、即ち、ＥＡＰパケットの最初にある、コード、識別子及びレングスフィールドに基づいてＥＡＰパケットを中継することである。これは、要求される透過性（トランスペアレンシー）、かつ、ここでは後方互換性が、ＧＣＡがＥＡＰレイヤヘッダ、即ち、コード、識別子及びレングスフィールドの後に配置することによって達成できることを意味している。
【００９４】
しかしながら、ＥＡＰアイデンティティ応答パケットを識別するために、ＥＡＰ認証器は、通常は、ＥＡＰ応答パケットのタイプ（Type）フィールド（ＥＡＰレイヤヘッダの後に続く）のチェックもしなければならない。ここで、ＡＡＡルーティングに対して必要とされるＮＡＩはＥＡＰアイデンティティ応答パケットから抽出される。ＥＡＰ認証器がＥＡＰアイデンティティ応答パケットを識別する場合、これは、タイプフィールドに続くタイプ−データ（Type-Data）フィールドからＮＡＩを抽出する。ここで、ＥＡＰレイヤヘッダの直後にＧＣＡを配置することは（ＥＡＰ認証器に対してトランスペアレントとなる方法で）、ＥＡＰリクエストパケットについてのみ可能である。それゆえ、通常は、タイプフィールドの後、あるいは（可能であれば、ＮＵＬＬで終了されている）タイプデータフィールドの後にＧＣＡを配置することが好ましい。
【００９５】
タイプフィールドの直後にＧＣＡを配置することは、ＥＡＰアイデンティティ応答パケットではなく、すべてのＥＡＰ応答パケット内でＧＣＡの使用を可能とすることになる。ＥＡＰアイデンティティ応答パケット内でのＧＣＡの使用は禁止されている、これは、これらのパケットから、ＥＡＰ認証器がタイプ−データフィールドからＮＡＩを抽出する必要があるからであり、これは、元来のＥＡＰ認証器がタイプフィールドの直後で検出することを予定しているからである。これは、ＥＡＰが通常数回以上のラウンドトリップ（やりとり（round trip））を持っていることを考慮してＧＣＡを使用することについての顕著な制約となり得る。場合によっては、他のＥＡＰパケット内のタイプフィールドの後にその位置を保持しながら、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内のＮＵＬＬで終了されているタイプデータフィールドの後に配置することができる。
【００９６】
しかしながら、すべてのＥＡＰパケットで一貫して使用することができるＧＣＡの位置が通常は望まれている。上述の説明からは、後方互換性がある方法でＧＣＡをすべてのＥＡＰパケットに配置することができる位置は、多かれ少なかれトレーラ（trailer）とするパケットの最後となる。しかしながら、このＧＣＡの位置は、ＥＡＰレイヤヘッダ内のレングスフィールドに依存するが、タイプ−データパラメータ（群）に対する明確なレングスインジケータを持っていないという、問題がこれらのＥＡＰパケットに対して生じることになる。このようなパケットに対しては、通常、ＧＣＡとタイプ−データフィールドとを区別することができないことになる。
【００９７】
この問題を解決するために、特定のＧＣＡの実施形態に従って、ＧＣＡレングスインジケータ、ＧＣＡ受信インジケータ及びＧＣＡペイロードの順序が、ＧＣＡレングスインジケータが最後に現れるように入れ換えることが提案される。ＧＣＡをＥＡＰのパケットの最後に配置することによって、ＥＡＰパケットの最後の２つのオクテット（この長さは、ＥＡＰレイヤヘッダ内のレングスフィールドによって示される）は、常に、ＧＣＡレングスインジケータとなる。ＧＣＡレングスインジケータがゼロでない限り、ＧＣＡ受信インジケータは、ＧＣＡレングスインジケータの前に現れ、ＧＣＡペイロード（このサイズは、ＧＣＡレングスインジケータから判定される）は、ＧＣＡ受信インジケータの前に配置されることになる。この方法で、ＥＡＰパケットのＧＣＡを識別し、かつタイプ−データフィールドからＧＣＡを区別することが常に可能となる。一方で、それでもなお、ＧＣＡの使用は、パススルーＥＡＰ認証器に対してトランスペアレントとなる。
【００９８】
図６の実施形態によるＧＣＡとの後方互換性は、更に、ＥＡＰ認証器がＥＡＰリクエスト／応答パケット（ＥＡＰレイヤヘッダとＮＡＩ以外）からの情報の抽出を試行しないものと仮定し、また、成功／失敗パケット内のレングスフィールドが４より大きい値を示していることを受け入れているものと仮定する。
【００９９】
後方互換性問題に対処する別の方法は、ＥＡＰ  ＧＣＡテストリクエスト／応答パケット、即ち、タイプフィールドで新規に定義されている値を持つ新規のＥＡＰパケットを使用して、ＭＮがＧＣＡをサポートしているかを判定することである。最初のＥＡＰアイデンティティリクエスト／応答パケット交換の前後で、ＧＣＡをサポートするＥＡＰ認証器は、ＥＡＰ  ＧＣＡテストリクエストパケット、即ち、専用のタイプ値を持つＥＡＰリクエストパケットをＭＮへ送信する（［１９］のＥＡＰ同位状態マシーン（peer state machine）は、２つの異なる送信時間が可能であることを示している）。ＭＮがＧＣＡをサポートしている場合、これは、ＥＡＰ  ＧＣＡテスト応答パケットで応答する。そうでない場合、ＭＮは、ＥＡＰ  ＧＣＡテストリクエストパケットを、未知のＥＡＰメソッドを使用するためのリクエストと解釈するので、ＭＮは、ＥＡＰ  Ｎａｋ  パケットで応答する。ＭＮからの応答に基づいて、ＥＡＰ認証器は、ＭＮがＧＣＡをサポートしているかどうかを判定する。
【０１００】
ＧＣＡをサポートするＭＮは、ＥＡＰ  ＧＣＡテストリクエストパケットの存在あるいは不在によって、ＥＡＰ認証器がＧＣＡをサポートしているかを判定することができる。ＥＡＰ  ＧＣＡテストリクエストパケットが受信されることが予想される場合、即ち、ＥＡＰ  アイデンティティリクエスト／応答交換の前後で、ＥＡＰ認証器はＧＣＡをサポートすると想定される。そうでない場合は、ＭＮは、ＥＡＰ認証器はＧＣＡをサポートしないという結論を出す。
【０１０１】
ＭＮとＥＡＰ認証器の両方がＧＣＡをサポートしている場合、これは、すべての次のＥＡＰパケット内のＥＡＰレイヤヘッダの後に（ＧＣＡコンポーネントの本来の順序で）配置することができる。そうでない場合、ＧＣＡは、上述の後方互換性のある方法で含ませることを可能にするＥＡＰパケットに依然として含められても良い。
【０１０２】
後方互換性の問題を扱う上述の別の方法には、いくつかの制限がある。１つには、あるＭＮ−ＥＡＰ認証器のラウンドトリップが無駄になる。また、最初のＥＡＰアイデンティティ／応答パケット交換の後に、ＥＡＰ  ＧＣＡテストリクエスト／応答パケットが交換される場合、ＧＣＡは、ＥＡＰアイデンティティ応答パケット内で使用することはできない。この実施形態は、ＥＡＰ認証器（例えば、ＮＡＳ）がＥＡＰの修正版、例えば、ＥＡＰｖ２を使用することも必要とする可能性がある。従って、他の方法でも可能ではあるが、ＥＡＰパケット内にＧＣＡを配置する好適な方法は、典型的には、ＧＣＡペイロードとＧＣＡ受信インジケータの後に続いて、ＧＣＡレングスインジケータを、パケットの最後のトレーラとすることである。
【０１０３】
ＥＡＰラウンドトリップの回数がＧＣＡ内で交換されるデータに対して十分でない場合には、ＡＡＡｈは、ＧＣＡの搬送目的のために、ＥＡＰ通知リクエスト／応答交換を介する、ＥＡＰラウンドトリップの回数を増やしても良い。
【０１０４】
ＧＣＡがメソッド専用のものである場合、ＧＣＡは後方互換性に関連する問題を持ち込むことはない。これは、通常、タイプ−データフィールドの一部となるからである。
【０１０５】
ＣＤＭＡフレームワークに対して専用に設計された実装例
以下では、本発明に従う、いくつかのＭＩＰｖ６実装の実施形態を説明する。一般的には、図１及び図２のアーキテクチャを参照する。全体フロー及び概念の実行可能性を示すために、図５−図１１で例示のシグナリングフロー図も参照する。
【０１０６】
上述の図３及び図４の例と比べて、図５−図１１のシグナリングフローは、ＣＤＭＡフレームワーク、特に、ＣＤＭＡ２０００に対してより特別に設計されているものである。以下のフロー図では、ＡＡＡｈ−ＨＡあるいはＭＮ−ＨＡの対話は、簡単にするために省略している。例えば、図３及び図４に示されるように、いくつかの形態でのＨＡ−ＭＮキー配信が発生するものと想定する。
【０１０７】
用語「ＥＡＰ／ＭＩＰｖ６」は、本明細書では、新規の拡張ＥＡＰプロトコルを示すために使用され、この新規の拡張ＥＡＰプロトコルは、本発明の実施形態では、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連情報を送信するために使用される。ＥＡＰ／ＭＩＰｖ６は、例えば、上述の新規のＥＡＰ  ＴＬＶ属性あるいは汎用コンテナ属性を使用して、ＭＩＰｖ６関連データを搬送することができる。
【０１０８】
ＣＤＭＡシステムにおいて、モバイルＩＰバージョン６（ＭＩＰｖ６）に対する認証及び認可をサポートするためのスキーム例は、以下のものがある。
【０１０９】
（Ａ）３ＧＰＰ２  モバイル  ＩＰｖ４動作で特定されるＰＰＰの使用と同様の方法で、ＰＰＰｖ６［９］を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
（Ｂ）ＩＥＴＦで定義されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
（Ｃ）ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
（Ｄ）３ＧＰＰ２２単純ＩＰｖ６動作で特定されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドイン
（Ｅ）ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドイン
（Ｆ）ＰＡＮＡを使用するＭＩＰｖ６再認証
（Ｇ）ＰＰＰを使用するＭＩＰｖ６再認証
利用可能な事前のＭＩＰｖ６サービスが存在しない場合に、通常、ＭＩＰｖ６の開始（Ａ、Ｂ、Ｃ）が実行され、移動体はＭＩＰｖ６サービスを受信することを要求する−移動体は、開始リクエストで、要求されたＭＩＰｖ６パラメータをネットワークへ送信する。実行中の事前のＭＩＰｖ６サービスが存在する場合には、ＭＩＰｖ６ハンドイン（Ｄ、Ｅ）が使用され、ハンドオーバが発生する−継続することを可能にするためにＭＩＰｖ６サービスに対して必要なベアラーを再確立することが必要となる。ＭＩＰｖ６再認証（Ｆ、Ｇ）は、典型的には、移動体とホームエージェント間の信頼関係が切れ、かつＭＩＰｖ６サービスを継続するためにこれを更新することが必要である場合に発生する。
【０１１０】
（Ａ）３ＧＰＰ２  モバイル  ＩＰｖ４動作で特定されるＰＰＰの使用と同様の方法で、ＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
−ＭＮ、ＲＡＮ及びＰＤＳＮは、３ＧＰＰ２規格に従って、必要な無線リンクとＡ１０／Ａ１１リンクをセットアップする。
【０１１１】
−ＰＤＳＮは、最初に、ＣＳＤ−ＰＰＰを使用する可能性をＭＮへ提示する。これは、図１２で参照されるように、最初に、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される。しかしながら、ＭＮは、ＰＰＰを使用することを選択して、ＰＰＰ／ＬＣＰでないメッセージを無視する（暗黙の上破棄する）。
【０１１２】
−認証フェーズは、ＰＰＰｖ６内では実行されない。
【０１１３】
−ＰＰＰｖ６内のＮＣＰ（ＩＰｖ６ＣＰ）フェーズでは、ＩＰアドレスはリクエストされない。
【０１１４】
−ＮＣＰ（ＩＰｖ６ＣＰ）フェーズが完了するまでは、続くＰＰＰ、ＩＰパケット（例えば、ＰＡＮＡ、ＤＨＣＰ）は送信されない。
【０１１５】
−ＰＡＮＡ交換は、ＩＰｖ６ＣＰが完了した後に開始する。ＰＡＮＡプロトコルは、ＭＮとＰＤＳＮ間で、ＥＡＰを搬送するために使用される。ＤＨＣＰも、グローバルＩＰアドレス（次のＤＨＣＰリプライで）をリクエストするために同時に送信される。
【０１１６】
−ＥＡＰ／ＭＩＰｖ６は、ＭＩＰｖ６認証、動的ＭＮホームアドレス割当等を容易にする情報を搬送するために使用される。
【０１１７】
−ＰＡＮＡプロトコルは、ＭＮとＰＤＳＮ間でＥＡＰを搬送するために使用される。
【０１１８】
−Ｄｉａｍｅｔｅｒ［例えば、１３］は、ＰＤＳＮとＡＡＡｈ間でＥＡＰを搬送するために使用される（Ｒａｄｉｕｓのような他のプロトコルも可能である）。
【０１１９】
−残りのシーケンスは、例えば、図３及び図４のＭＩＰｖ６の開始についての拡張ＥＡＰシグナリングフロースキームに従うことができる。
【０１２０】
−ＤＨＣＰ［２０］は、ステートフルなＩＰアドレス自動コンフィグレーションに対して使用することができる。（別の構成では、ルータ勧誘／広告＋デュプリケートアドレス検出を用いて、ステートレスなＩＰアドレス自動コンフィグレーションを使用することもある、但し、これは、典型的には、１つ以上のＲＴＴをシグナリングフローに追加することになる。）
−Ａ１０接続のセットアップの成功後、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約６．５のラウンドトリップ回数（ＲＴＴ）が通常必要とされる。
【０１２１】
３ＧＰＰ２  モバイル  ＩＰｖ４動作で特定されるＰＰＰの使用と同様の方法で、ＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始についてのスキームの実施形態は、図５のシグナリングフロー図で示される。
【０１２２】
（Ｂ）ＩＥＴＦで定義されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
−ＭＮ、ＲＡＮ及びＰＤＳＮは、３ＧＰＰ２規格に従って、必要な無線リンクとＡ１０／Ａ１１リンクをセットアップする。
【０１２３】
−ＰＤＳＮは、最初に、ＣＳＤ−ＰＰＰを使用する可能性をＭＮへ提示する。これは最初に、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される（図１２）。しかしながら、ＭＮは、ＰＰＰを使用することを選択して、ＰＰＰ／ＬＣＰでないメッセージを無視する（暗黙の上破棄する）。
【０１２４】
−ＰＰＰｖ６内で認証フェーズが、ＥＡＰ認証のために使用される。
【０１２５】
−ＥＡＰ／ＭＩＰｖ６は、ＭＩＰｖ６認証、動的ＭＮホームアドレス割当等を容易にする情報を搬送するために使用される。
【０１２６】
−Ｄｉａｍｅｔｅｒは、ＰＤＳＮとＡＡＡｈ間でＥＡＰを搬送するために使用される（Ｒａｄｉｕｓのような他のプロトコルも可能である）。
【０１２７】
−拡張ＥＡＰ（即ち、ＥＡＰ／ＭＩＰｖ６）シグナリングフロースキームは、例えば、図３及び図４のＭＩＰｖ６の開始に対するものにすることがことができる。
【０１２８】
−ＰＰＰ認証フェーズ後、ＰＰＰ内のＮＣＰ（ＩＰｖ６ＣＰ）フェーズが、インタフェースＩＤ割当のために使用される。
【０１２９】
−ＮＣＰ（ＩＰｖ６ＣＰ）フェーズが完了するまでは、続くＰＰＰ、ＩＰパケット（例えば、ルータ勧誘）は送信されない。
【０１３０】
−ＩＰｖ６ＣＰが完了した後、ＩＰｖ６ルータ勧誘が送信される。ルータ勧誘／広告は、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するために使用される。
【０１３１】
−Ａ１０接続のセットアップの成功後、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約５．５のＲＴＴが通常必要とされる。
【０１３２】
ＩＥＴＦで定義されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始についてのスキームの実施形態は、図６のシグナリングフロー図で示される。
【０１３３】
（Ｃ）ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始
−ＭＮ、ＲＡＮ及びＰＤＳＮは、３ＧＰＰ２規格に従って、必要な無線リンクとＡ１０／Ａ１１リンクをセットアップする。
【０１３４】
−ＰＤＳＮは、最初に、ＣＳＤ−ＰＰＰを使用する可能性をＭＮへ提示する。これは最初に、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される（図１２）。ＭＮは、ＰＰＰ／ＥＡＰを使用するＣＳＤ−ＰＰＰを選択する、これは、ＭＩＰｖ６を開始したいからである。ＰＰＰ／ＬＣＰは同時に処理される。ＰＰＰ／ＣＨＡＰパケットは、暗黙の上破棄される。
【０１３５】
−ＰＰＰｖ６内で認証フェーズが、ＥＡＰ認証のために使用される。
【０１３６】
−ＣＳＤ−ＰＰＰに従えば、ＰＰＰ／ＩＰｖ６ＣＰとＩＰパケット（例えば、ルータ勧誘）は、ＰＰＰ／ＥＡＰパケットと同時に送信することができる。
【０１３７】
−ＥＡＰ／ＭＩＰｖ６は、ＭＩＰｖ６認証、動的ＭＮホームアドレス割当等を容易にする情報を搬送するために使用される。
【０１３８】
−Ｄｉａｍｅｔｅｒは、ＰＤＳＮとＡＡＡｈ間でＥＡＰを搬送するために使用される（Ｒａｄｉｕｓのような他のプロトコルも可能である）。
【０１３９】
−拡張ＥＡＰ（即ち、ＥＡＰ／ＭＩＰｖ６）シグナリングフロースキームは、例えば、図３及び図４のＭＩＰｖ６の開始に対応するものでも良い。
【０１４０】
−ＩＰｖ６ＣＰが、インタフェースＩＤ割当のために使用される。
【０１４１】
−ルータ勧誘／広告は、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するために使用される。
【０１４２】
−Ａ１０接続のセットアップの成功後、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約２．５のＲＴＴが通常必要とされる。３−４ＲＴＴのファクタに従うゲインは、ＣＳＤ−ＰＰＰが使用されない上述のスキーム（Ａ）と（Ｂ）に関して得ることができる。
【０１４３】
ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６の開始についてのスキームの実施形態は、図７のシグナリングフロー図で示される。
【０１４４】
（Ｄ）３ＧＰＰ２２単純ＩＰｖ６動作で特定されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドイン
−ＭＮ、ＲＡＮ及びＰＤＳＮは、３ＧＰＰ２規格に従って、必要な無線リンクとＡ１０／Ａ１１リンクをセットアップする。
【０１４５】
−ＰＤＳＮは、最初に、ＣＳＤ−ＰＰＰを使用する可能性をＭＮへ提示する。これは最初に、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される（図１２）。しかしながら、ＭＮは、ＰＰＰを使用することを選択して、ＰＰＰ／ＬＣＰでないメッセージを無視する（暗黙の上破棄する）。
【０１４６】
−単純ＩＰｖ６とＭＩＰｖ６ハンドインに対するシグナリングフローを区別する必要はない。３ＧＰＰ２［２］で現在特定されている単純ＩＰｖ６処理は、再使用される。
【０１４７】
−ＰＰＰでの認証フェーズは、ＣＨＡＰ認証に対して使用される。
【０１４８】
−ＰＰＰｖ内のＮＣＰ（ＩＰｖ６ＣＰ）フェーズは、インタフェースＩＤ割当のために使用される。
【０１４９】
−ＩＰｖ６ＣＰフェーズが完了するまでは、続くＰＰＰ、ＩＰパケット（例えば、ルータ勧誘）は送信されない。
【０１５０】
−ＩＰｖ６ＣＰが完了した後、ＩＰｖ６ルータ勧誘が送信される。ルータ勧誘／広告は、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するために使用される。
【０１５１】
−Ａ１０接続のセットアップの成功後、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約４．５のＲＴＴが通常必要とされる。
【０１５２】
３ＧＰＰ２２単純ＩＰｖ６動作で特定されるＰＰＰｖ６を使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドインについてのスキームの実施形態は、図８のシグナリングフロー図で示される。
【０１５３】
（Ｅ）ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドイン
−ＭＮ、ＲＡＮ及びＰＤＳＮは、３ＧＰＰ２規格に従って、必要な無線リンクとＡ１０／Ａ１１リンクをセットアップする。
【０１５４】
−ＰＤＳＮは、最初に、ＣＳＤ−ＰＰＰを使用する可能性をＭＮへ提示する。これは最初に、標準的なＰＰＰ／ＬＣＰパケットを送信し、それに続いて、ＰＰＰ／ＣＨＡＰパケット、更に、ＰＰＰ／ＥＡＰパケットを送信することによって実行される（図１２）。ＭＮは、ＰＰＰ／ＣＨＡＰを使用するＣＳＤ−ＰＰＰを選択する、これは、ＭＩＰｖ６ハンドインを開始したいからである。ＰＰＰ／ＬＣＰは同時に処理される。ＰＰＰ／ＥＡＰパケットは、暗黙の上破棄される。
【０１５５】
−ＣＳＤ−ＰＰＰに従えば、ＰＰＰ／ＩＰｖ６ＣＰとＩＰパケット（例えば、ルータ勧誘）は、ＰＰＰ／ＣＨＡＰパケットと同時に送信することができる。
【０１５６】
−ＩＰｖ６ＣＰは、インタフェースＩＤ割当用に使用される。
【０１５７】
−ルータ勧誘／広告は、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するために使用される。
【０１５８】
−Ａ１０接続のセットアップの成功後、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約１．５のＲＴＴが通常必要とされる。３ＲＴＴのファクタに従うゲインは、ＣＳＤ−ＰＰＰが使用されない上述のスキーム（Ｄ）に関して得ることができる。
【０１５９】
ＣＳＤ−ＰＰＰを使用するＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドインについての処理の実施形態は、図９のシグナリングフロー図で示される。
【０１６０】
（Ｆ）ＰＡＮＡを使用するＭＩＰｖ６再認証
−ＭＩＰｖ６再認証を開始することの必要性がＭＮに対して発生する。これは、例えば、ＨＡ−ＭＮ  ＩＰＳｅｃキー期限の満了によるものである。
【０１６１】
−ＰＡＮＡは、ＥＡＰを搬送するために使用される。
【０１６２】
−ＥＡＰ／ＭＩＰｖ６は、ＭＩＰｖ６再認証を容易にする情報を搬送するために使用される。
【０１６３】
−Ｄｉａｍｅｔｅｒは、ＰＤＳＮとＡＡＡｈ間でＥＡＰを搬送するために使用される（Ｒａｄｉｕｓのような他のプロトコルも可能である）。
【０１６４】
−拡張ＥＡＰ（即ち、ＥＡＰ／ＭＩＰｖ６）シグナリングフロースキームは、例えば、図３及び図４のＭＩＰｖ６の開始に対応するものでも良い。
【０１６５】
−ＰＡＮＡの開始から、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約４のＲＴＴが通常必要とされる。
【０１６６】
ＰＡＮＡを使用するＭＩＰｖ６再認証についてのスキームの実施形態は、図１０のシグナリングフロー図で示される。
【０１６７】
（Ｇ）ＰＰＰを使用するＭＩＰｖ６再認証
−ＭＩＰｖ６再認証を開始することの必要性がＭＮに対して発生する。これは、例えば、ＨＡ−ＭＮ  ＩＰＳｅｃキー期限の満了によるものである。
【０１６８】
−ＰＰＰの認証フェーズは、ＥＡＰ認証のために使用される。
【０１６９】
−ＥＡＰ／ＭＩＰｖ６は、ＭＩＰｖ６再認証を容易にする情報を搬送するために使用される。
【０１７０】
−Ｄｉａｍｅｔｅｒは、ＰＤＳＮとＡＡＡｈ間でＥＡＰを搬送するために使用される（Ｒａｄｉｕｓのような他のプロトコルも可能である）。
【０１７１】
−拡張ＥＡＰ（即ち、ＥＡＰ／ＭＩＰｖ６）シグナリングフロースキームは、例えば、図３及び図４のＭＩＰｖ６の開始に対応するものでも良い。
【０１７２】
−ＰＰＰ／ＬＣＰ構成リクエスト（PPP/LCP Configure-Req）から、ＭＮによってＭＩＰｖ６バインディング更新がＨＡへ送信される前には、約３のＲＴＴが通常必要とされる。
【０１７３】
ＰＰＰを使用するＭＩＰｖ６再認証についてのスキームの実施形態は、図１１のシグナリングフロー図で示される。
【０１７４】
上述の説明から、本発明に従うＭＩＰｖ６認証のための方法の実施形態が、ＭＩＰｖ６の開始（Ａ、Ｂ、Ｃ）及びＭＩＰｖ６再認証（Ｆ、Ｇ）のような拡張認証プロトコルを使用することが理解される。ＭＩＰｖ６ハンドイン（Ｄ、Ｅ）と、ＩＰｖ６アドレス用のグローバルプレフィックスを取得するためのルータ勧誘／広告に対しては、ＣＨＡＰは効果的に使用することができる。
【０１７５】
上述の認証スキームによって示されるように、本発明は、特定のプロトコルに制限されるものではない。スキームＦ（図１０）は、例えば、いくつかの点では、ＰＡＮＡがＰＰＰのスキームＧ（図１１）についての代替構成を構築することを示している。プロトコルを使用する認証処理及び、例示されるものに対応する機能とのプロトコルの組み合わせは、本発明の範囲に含まれる。
【０１７６】
ＭＩＰｖ６の開始、ＭＩＰｖ６ハンドイン及びＭＩＰｖ６再認証についての各スキームのあらゆる組み合わせが可能であることに注意すべきである。特定の実施形態で、どの特定のスキームが選択されるかについては、いくつかのファクタに基づいて通常決定されるべきである。セットアップ回数は、このファクタの１つとなる。
【０１７７】
本発明は、訪問先ネットワーク内のいわゆる「ローカルホームエージェント」とともに使用することもできることが言及されるべきである。ローカルＨＡは、例えば、ホームネットワーク内にＨＡ３６が存在しない場合に使用することができる。その代わり、ローカルＨＡは、訪問先ドメイン内のローミングＭＮに動的に割り当てられる。ＭＩＰｖ６  ＡＡＡシグナリングは、経路ＭＮ←→ＲＮ←→ＲＤＳＮ←→ＡＡＡｖ←→ＡＡＡｈ←→ＡＡＡｖ←→ローカルＨＡに従うことができる。例えば、ＡＡＡｈとＡＡＡｖ間、また、ＡＡＡｖとローカルＨＡ間で、拡張Ｄｉａｍｅｔｅｒアプリケーションを使用することができる。このようなソリューションは、通常、ＡＡＡｖ内でＭＩＰｖ６サポートを必要とする。
【０１７８】
従って、本発明によって提供される主要な効果は、ＣＤＭＡ２０００のようなフレームワーク内でＭＩＰｖ６認証及び認可を可能にすることである。ＣＤＭＡシステムに対する完全なＭＩＰｖ６  ＡＡＡソリューションは、拡張認証プロトコルによって達成される。これは、訪問先ドメインに対してトランスペアレントとなる方法でエンドツーエンドで動作する。この訪問先ドメインには、例えば、アクセスネットワーク、ＰＤＳＮ及び訪問先ネットワーク内のＡＡＡサーバが含まれる。このことは、いくつかのあるいはすべてのこれらのノードを単なるパススルーエージェントとして動作させることを可能にする。これは、顕著な効果となる。ＭＮとＡＡＡｈ間での事前暗号化を適用することも可能である。これは、交換が、エアインタフェースを介して不可視となるからである。これは、盗聴、中間者攻撃及び他の攻撃に対する十分なセキュリティを、外部ＣＤＭＡネットワークをローミングする移動ノードに対して維持することができることを意味する。加えて、自身のローミングパラメータのネットワーク内の更新に依存することなく、このソリューションを配備することをオペレータに可能にする。
【０１７９】
別の利点は、より少ないパケットデータセッションセットアップ回数を本発明によって達成できることである。ＭＩＰｖ６ハンドインの場合と、ＭＩＰｖ６の開始の場合とに、例えば、開始用のＥＡＰ／ＭＩＰｖ６とハンドイン用のＣＨＡＰについての処理を別々にすることを可能にすることによって、ＭＩＰｖ６の開始の場合と比較して、ＭＩＰｖ６ハンドインに対するパケットデータセッションセットアップ回数を少なくすることができる。この方法では、２つの場合について別々の処理を可能にすることによって、少なくとも１回のＲＴＴが節約される。また、ＣＳＤ−ＰＰＰを使用することは、ＰＰＰと比べてパケットデータセッションセットアップ回数を著しく少なくする。３−４のＲＴＴのファクタに従うゲインが取得可能である。
【０１８０】
セッションセットアップ回数は、適切な場合には、例えば、ＰＡＮＡの代わりにＰＰＰを使用することによって少なくすることができる。これは、ＰＡＮＡを介在する処理は、通常は、ＰＰＰのみが使用される場合の処理と比較して完了するまでにより多くのＲＴＴを必要とするからである。しかしながら、たとえＰＰＰがセッションセットアップ回数について有利であるとしても、例えば、レイヤ−３−唯一のソリューション（layer-3-only solution）が選択される場合、ＰＡＮＡを介在する処理を使用することが適切となる場合が依然としてある。
【０１８１】
本発明の別の利点は、例えば、単純ＩＰｖ６とＭＩＰｖ６ハンドインについてのシグナリングフロー間を区別する必要性を解消することができることである。これらは共通の認証処理を使用することができる。３ＧＰＰ２で現在特定される単純ＭＩＰｖ６処理を採用することができる。
【０１８２】
上述のいくつかの構成をまとめると、図１４は、ＣＤＭＡシステム内の移動ノードに対してＭＩＰｖ６サービスをサポートする方法の基本例のフロー図として示すことができる。この例では、ステップＳ１−Ｓ４で示される情報送信及び動作は、移動ノードの認証（Ｓ１）、ＭＮ−ＨＡセキュリティアソシエーションの確立（Ｓ２）、ＭＩＰｖ６コンフィグレーション（Ｓ３）とＭＩＰｖ６バインディング（Ｓ４）に関するものである。ステップＳ２−Ｓ３は、一般には、認可フェーズとしてみなされる。ステップＳ１−Ｓ４は、要求される場合には、たいていは、全体のセットアップ回数を少なくするために平行して実行されても良い。ステップＳ１では、情報が、ホームネットワーク側で移動ノードを認証するために、ＡＡＡインフラストラクチャを介して送信される。ステップＳ２で、ＭＮとＨＡ間のセキュリティアソシエーションを即時に確立すること、あるいは将来に確立することを可能にするために、ＭＩＰｖ６関連情報が送信される。ステップＳ３で、例えば、コンフィグレーションパラメータを、移動ノード及び、その内部の適切な記憶用のホームエージェントの少なくとも一方に送信することによって、追加のＭＩＰｖ６コンフィグレーションが実行される。ステップＳ４で、移動ノードはバインディング更新を送信し、そして、ＭＩＰｖ６バインディングがＨＡで確立される。
【０１８３】
本発明の詳細な実施形態は、現在のＥＡＰ［７、１８］を参照して主に説明している。しかしながら、本発明は、ＥＡＰｖ２のような他のＥＡＰバージョンにも良好に適用可能であり、更には、上述の方法で拡張される他の認証プロトコルにも良好に適用可能である。ＥＡＰは、単なる取り得る実装の例示であり、また、本発明は、通常は、それに限定されるものではなく、また、選択的には、非ＥＡＰスキームを介在させても良い。
【０１８４】
上述の例では、移動ノード（ＭＮ）とＡＡＡｈは、共通の共有化シークレットを持っているものと想定している。これは、例えば、移動ノード内にインストールされているアイデンティティモジュールとホームネットワーク間で共有される対称キーとすることができる。このアイデンティティモジュールは、従来より周知の任意の不正開封防止アイデンティティモジュールとすることができる。これには、ＧＳＭ移動電話で使用される標準ＳＩＭカード、ユニバーサルＳＩＭ（ＵＳＩＭ）、ＷＡＰ  ＳＩＭ、これは、ＷＩＭとしても知られる。また、ＩＳＩＭ、また、より一般的には、ＵＩＣＣモジュールがある。ＭＮ−ＨＡセキュリティリレーションに対しては、シードあるいはナンスは、ＭＮによってＡＡＡｈへ搬送することができる（あるいは、別の方法では、即ち、シードは、ＡＡＡｈによって生成されて、ＭＮへ搬送される）。このシードあるいはナンスから、ＡＡＡｈは、共有シークレットに基づいて、ＭＮ−ＨＡセキュリティキー（群）、例えば、事前共有化キーを生成することができる。移動ノードは、自身で、同一のセキュリティキー（群）を生成することができる。これは、この移動ノードが、シード／ナンスを生成して（あるいはＡＡＡｈからシードを受信して）いて、また、共有シークレットを持っているからである。選択的には、ＡＡＡｈは、単独で、ＭＮ−ＨＡセキュリティキー（群）を生成して、そして、それをＭＮ（暗号技術で保護されている）とＨＡへ送信するようにしても良い。
【０１８５】
本発明は特定の実施形態を参照して説明されているが、本発明は、説明される構成と等価なもの、また、当業者にとって自明な変更及び変形も含むものである。
【０１８６】
参考文献
［１］ＩＰｖ６における移動性のサポート、ディー．ジョンソン、シー．パーキンス、ジェイ．アルコ、２００３年５月２６日、（Mobility Support inIPv6, D. Johnson, C. Perkins, J. Arkko, May 26, 2003）
［２］３ＧＰＰ２  Ｘ．Ｐ００１１  Ｖｅｒ．１．  ０−９、３ＧＰＰ２無線ＩＰネットワーク規格、２００３年２月（3GPP2 X.P0011 Ver.1. 0-9,3GPP2 Wireless IP Network Standard, February, 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）
［５］ＩＰｖ６における、ＩＰｖ６スタイル−アドレス自動コンフィグレーション、ＨＥＯ  セオンミヤング  インターネットリサーチ研究所、２００３年１月２７日（IPv6style-Address Autoconfiguration inIPv6, HEO SeonMeyong Internet Research Institute, January 27,2003）
［６］ＩＥＥＥ規格８０２．１Ｘ、ローカル及びメトロポリタンネットワーク−ポートベースのネットワークアクセス制御（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）
［８］ポイントツーポイントプロトコル（ＰＰＰ）、ＲＦＣ１６６１、ダブリュ．シンプソン、１９９４年７月（The Point-to-Point Protocol (PPP),RFC1661, W. Simpson, July 1994）
［９］ＰＰＰオーバＩＰバージョン６、ＲＦＣ２４７２、ディー．ハスキン、イー．アレン、１９９８年１２月（IP Version 6 over PPP,RFC2472, D. Haskin, E. Allen, December 1998）
［１０］米国特許第６，４８７，２１８号、Ａリンク構成方法及び装置、アール．ルドウィッグ、エム．ゲルデス、２００２年１１月２６日（US Patent 6,487, 218, Method and Device for Configuring A Link, R. Ludwig, M. Gerdes, November 26,2002）
［１１］インターネットセキュリティアソシエーション及びキー管理プロトコル（ＩＳＡＫＭＰ）、ＲＦＣ２４０８、ディー．マウガン、エム．シェルトラー、エム．シュナイダー、ジェイ．ターナー、１９９８年１１月（Internet Security Association and Key Management Protocol (ISAKMP),RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998）
［１２］ＤｉａｍｅｔｅｒモバイルＩＰｖ４アプリケーション、ピー．カルホン、ティー、ジョアンソン、シー．ペルキンス、２００３年４月２９日（Diameter MobileIPv4 Application, P. Calhoun, T. Johansson, C. Perkins, April 29, 2003）
［１３］Ｄｉａｍｅｔｅｒ拡張可能認証プロトコル（ＥＡＰ）アプリケーション、ティー．ヒルラー、ジー．ゾルン、２００３年３月（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）
［１６］ＥＡＰ  ＡＫＡ認証、ジェイ．アルコ、エイチ．ハベリネン、２００３年１０月（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 ＞）
［２０］ＩＰｖ６用動的ホストコンフィグレーションプロトコル（ＤＨＣＰｖ６）、アール．ドロムス、ジェイ．バウンド、ビー．ボルツ、ティー．レモン、シー．ペルキンス、エム．カルネイ、２００２年１１月２日（Dynamic Host Configuration Protocol for IPv6 (DHCPv6), R. Droms, J. Bound, B. Voltz, T. Lemon, C. Perkins, M. Carney, November 2,2002）
略語
ＡＡＡ    認証、認可及びアカウンティング
（Authentication, Authorization and Accounting）
ＡＡＡｈ  ホームＡＡＡサーバ
ＡＡＡｖ  訪問先ＡＡＡサーバ（Visited AAA server）
ＡＫＡ    認証及びキーアグリーメント（Authentication and Key Agreement）
ＡＰ      アクセスポイント
ＢＡ      バインディング応答確認（Binding Acknowledgement）
ＢＵ      バインディング更新（Binding Update）
ＣＤＭＡ  符号分割多元アクセス（Code Division Multiple Access）
ＣＨＡＰ  チャレンジハンドシェイク認証プロトコル
（Challenge Handshake Authentication Protocol）
ＣｏＡ    気付けアドレス（Care-of Address）
ＣＳＤ−ＰＰＰ  回線交換データポイントツーポイントプロトコル
（Circuit Switched Data Point-to-Point Protocol）
ＤＡＤ    デュプリケートアドレス検出（Duplicate Address Detection）
ＤＨＣＰ  動的ホストコンフィグレーションプロトコル
（Dynamic Host Configuration Protocol）
ＥＡＰ    拡張可能認証プロトコル（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）
ＰＤＡ      パーソナルデジタルアシスタント
ＰＤＳＮ    パケットデータ提供ノード（Packet Data Serving Node）
ＰＰＰ      ポイントツーポイントプロトコル（Point-to-Point Protocol）
ＰＰＰｖ６  ポイントツーポイントプロトコル  バージョン６
ＲＡＤＩＵＳ  リモート認証ダイヤルインユーザサービス
（Remote Authentication Dial User Service）
ＲＡＮ      無線アクセスネットワーク
ＲＮ        無線ネットワーク
ＲＴＴ      ラウンドトリップ回数（Round Trip Time）
３ＧＰＰ２  第３世代パートナシッププロジェクト２
（Third Generation Partnership Project 2）
ＳＰＩ      セキュリティパラメータインデックス
ＴＬＶ      タイプレングス値（Type Length Value）
ＷＬＡＮ    無線ローカルエリアネットワーク
【図面の簡単な説明】
【０１８７】
【図１】モバイルＩＰアクセス用の汎用３ＧＰＰ２基準モデルを示す図である。
【図２】本発明で使用される、モバイルＩＰアクセス用のＣＤＭＡネットワークの概要図である。
【図３】本発明の実施形態に従う、一般的なＭＩＰｖ６の開始を処理するための信号フロー図である。
【図４】本発明の別の実施形態に従う、一般的なＭＩＰｖ６の開始を処理するための信号フロー図である。
【図５】本発明の実施形態に従う、ＭＩＰｖ６認証を伴うＭＩＰｖ６の開始の信号フロー図である。
【図６】本発明の別の実施形態に従う、ＭＩＰｖ６認証を伴うＭＩＰｖ６の開始の信号フロー図である。
【図７】本発明の更に別の実施形態に従う、ＭＩＰｖ６認証を伴うＭＩＰｖ６の開始の信号フロー図である。
【図８】本発明の実施形態に従う、ＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドインの信号フロー図である。
【図９】本発明の別の実施形態に従う、ＭＩＰｖ６認証を伴うＭＩＰｖ６ハンドインの信号フロー図である。
【図１０】本発明の実施形態に従うＭＩＰｖ６再認証の信号フロー図である。
【図１１】本発明の別の実施形態に従うＭＩＰｖ６再認証の信号フロー図である。
【図１２】本発明の実施形態に従うインターネット接続アクセスサーバのブロック図である。
【図１３】本発明の実施形態に従うＡＡＡホームネットワークサーバを示すブロック図である。
【図１４】本発明に従う、ＣＤＭＡシステム内の移動ノードに対して、ＭＩＰｖ６サービスをサポートする方法の基本例のフロー図である。
【図１】
2006527968.tif 000004
【図２】
2006527968.tif 000005
【図３】
2006527968.tif 000006
【図４】
2006527968.tif 000007
【図５】
2006527968.tif 000008
【図６】
2006527968.tif 000009
【図７】
2006527968.tif 000010
【図８】
2006527968.tif 000011
【図９】
2006527968.tif 000012
【図１０】
2006527968.tif 000013
【図１１】
2006527968.tif 000014
【図１２】
2006527968.tif 000015
【図１３】
2006527968.tif 000016
【図１４】
2006527968.tif 000017
【手続補正書】
【提出日】平成18年2月16日(2006.2.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートする方法であって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク間で、訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理で、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連認証及び認可情報を送信する
ことを特徴とする方法。
【請求項２】
前記エンドツーエンド処理は、前記移動ノード（１０）と、前記ホームネットワーク内のＡＡＡサーバ（３４）間で実行され、前記訪問先ネットワーク内のノードは、前記エンドツーエンド処理内の単なるパススルーエージェントとして動作する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と、前記ＡＡＡホームネットワークサーバ（３４）間で、認証プロトコルで、前記訪問先ネットワークに配置されるインターネット接続アクセスサーバ（２２）を介して送信される
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記移動ノード（１０）と前記インターネット接続アクセスサーバ（２２）間のポイントツーポイント通信が、ＣＳＤ−ＰＰＰプロトコルに基づいて構成される
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連認証及び認可情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記ＭＩＰｖ６関連情報は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性で送信される
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記ＭＩＰｖ６関連情報は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性で送信される
ことを特徴とする請求項５に記載の方法。
【請求項８】
更に、ＭＩＰｖ６ハンドインのために、前記移動ノードと前記ホームネットワーク間でＣＨＡＰ認証を実行するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記ＭＩＰｖ６関連情報は、ホームエージェント（３６）の割当のために、また、前記移動ノード（１０）と前記ホームエージェント（３６）間のＭＩＰｖ６セキュリティアソシエーションの確立のために、また、前記ホームエージェント（３６）内の前記移動ノード（１０）に対するバインディングの確立のために、前記ＡＡＡインフラストラクチャを介して送信される
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記インターネット接続アクセスサーバ（２２）は、標準ＰＰＰ／ＬＣＰパケットと少なくともＰＰＰ／ＥＡＰパケットを送信することによって、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用する可能性を前記移動ノードへ提示する
ことを特徴とする請求項３に記載の方法。
【請求項１１】
前記インターネット接続アクセスサーバは、ＰＰＰ／ＬＣＰ及びＰＰＰ／ＥＡＰパケットとともに、ＰＰＰ／ＣＨＡＰパケットも送信する
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
ＣＤＭＡシステムにおける、モバイルＩＰバージョン６（ＭＩＰｖ６）用の認証及び認可をサポートするシステムであって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク（３０）間で、前記訪問先ネットワークに対してトランスペアレントなエンドツーエンド処理で、認証プロトコルで、ＡＡＡインフラストラクチャを介してＭＩＰｖ６関連認証及び認可情報を送信する手段を備える
ことを特徴とするシステム。
【請求項１３】
前記エンドツーエンド処理は、前記移動ノード（１０）と、前記ホームネットワーク内のＡＡＡサーバ（３４）間で実行され、前記訪問先ネットワーク内のノードは、前記エンドツーエンド処理内の単なるパススルーエージェントとして動作する
ことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記ＭＩＰｖ６関連情報は、前記移動ノード（１０）と、前記ＡＡＡホームネットワークサーバ（３４）間で、前記認証プロトコルで、前記訪問先ネットワークに配置されるインターネット接続アクセスサーバ（２２）を介して送信される
ことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記移動ノード（１０）と前記インターネット接続アクセスサーバ（２２）間のポイントツーポイント通信を、ＣＳＤ−ＰＰＰプロトコルに基づいて構成する手段を更に備える
ことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記認証プロトコルは、拡張された拡張可能認証プロトコル（ＥＡＰ）であり、前記ＭＩＰｖ６関連認証及び認可情報は、ＥＡＰプロトコルスタック内に追加データとして組み込まれる
ことを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記ＭＩＰｖ６関連情報を送信する手段は、任意のＥＡＰメソッドで利用可能な汎用コンテナ属性で、前記ＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記ＭＩＰｖ６関連情報を送信する手段は、ＥＡＰプロトコルスタック内のメソッドレイヤのメソッド専用汎用コンテナ属性で、前記ＭＩＰｖ６関連情報を送信する手段を備える
ことを特徴とする請求項１６に記載のシステム。
【請求項１９】
更に、ＭＩＰｖ６ハンドインのために、前記移動ノードと前記ホームネットワーク間でＣＨＡＰ認証を実行する手段を備える
ことを特徴とする請求項１２に記載のシステム。
【請求項２０】
前記ＭＩＰｖ６関連情報を送信する手段は、ホームエージェント（３６）の割当のために、また、前記移動ノード（１０）と前記ホームエージェント（３６）間のＭＩＰｖ６セキュリティアソシエーションの確立のために、また、前記ホームエージェント（３６）内の前記移動ノード（１０）に対するバインディングの確立のために、前記ＡＡＡインフラストラクチャを介して前記ＭＩＰｖ６関連情報を送信するように動作可能である
ことを特徴とする請求項１２に記載のシステム。
【請求項２１】
前記インターネット接続アクセスサーバ（２２）は、標準ＰＰＰ／ＬＣＰパケットと少なくともＰＰＰ／ＥＡＰパケットを送信することによって、ＰＰＰあるいはＣＳＤ−ＰＰＰを使用する可能性を前記移動ノードへ提示するように動作可能である
ことを特徴とする請求項１４に記載のシステム。
【請求項２２】
前記インターネット接続アクセスサーバは、ＰＰＰ／ＬＣＰ及びＰＰＰ／ＥＡＰパケットとともに、ＰＰＰ／ＣＨＡＰパケットも送信するように動作可能である
ことを特徴とする請求項２１に記載のシステム。
【請求項２３】
ＣＤＭＡフレームワーク内のモバイルＩＰバージョン６（ＭＩＰｖ６）ハンドインのためのシステムであって、
訪問先ネットワーク内の移動ノード（１０）と前記移動ノードのホームネットワーク内のＡＡＡサーバ間で、ＡＡＡインフラストラクチャを介して、ＣＨＡＰ認証を実行する手段を備える
ことを特徴とするシステム。
【国際調査報告】
2006527968.tif 000018
2006527968.tif 000019