(57)【要約】【課題】ＩＰ接続処理装置に関し、特に無線ＬＡＮ等により構築された所定エリアのＩＰ網に、ユーザ認証後直ちに接続を開始するＩＰ接続処理装置を提供する。【解決手段】ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、認証完了を検出する検出手段と、認証結果を獲得する獲得手段と、認証完了を契機にＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有する。前記ＩＰ接続手段は、前記認証完了を契機に、前記ＩＰ網へＩＰアドレス情報の取得要請を行い、前記ＩＰ網から返信される情報により自己のＩＰアドレスを取得する。【選択図】      図７
2004254277.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
認証完了を検出する検出手段と、
前記認証完了の検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【請求項２】
ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
認証完了を検出する検出手段と、
認証結果を獲得する獲得手段と、
認証が成功した認証完了を契機にＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【請求項３】
前記ＩＰ接続処理装置は、
ＩＰ接続処理を行なうＩＰ処理部と、
認証処理を行なう認証処理部と、
前記認証処理部に認証完了の検出を要求し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する高速ＩＰ接続処理部と、から成る、請求項１又は２に記載のＩＰ接続処理装置。
【請求項４】
前記高速ＩＰ接続処理部は、前記認証処理部に認証完了の検出を要求するのに代えて、前記認証処理部への入力情報を傍受して認証完了を検出し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する、請求項１又は２に記載のＩＰ接続処理装置。
【請求項５】
ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
アクセスポイントとの間の暗号化を行なうための鍵を含むパケットを検出する検出手段と、
前記鍵を含むパケットの検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【請求項６】
前記ＩＰ接続処理装置は、
ＩＰ接続処理を行なうＩＰ処理部と、
暗号鍵の管理を行なう暗号鍵管理部と、
前記暗号鍵管理部への入力情報を傍受して暗号鍵を検出し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する、高速ＩＰ接続処理部と、から成る、請求項５記載のＩＰ接続処理装置。
【請求項７】
前記高速ＩＰ接続処理部は、前記認証処理部を含むオペレーティング・システムとデバイスドライバとの間で前記傍受を行なう他のドライバ、又は前記傍受を行なうデバイスドライバを含む、請求項１又は２に記載のＩＰ接続処理装置。
【請求項８】
前記高速ＩＰ接続処理部は、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示するのに代えて、前記検出により、前記ＩＰ網へＩＰアドレス情報の取得要請を行い、
前記ＩＰ処理部は、前記ＩＰ網から返信される情報により自己のＩＰアドレスを取得する、請求項３、４又は６のいずれか一つに記載のＩＰ接続処理装置。
【請求項９】
アクセス網への接続時に前記ＩＰ接続処理を開始し、又はアクセス網間の移動時に前記ＩＰ接続処理を継続させる、請求項１〜８のいずれか一つに記載のＩＰ接続処理装置。
【請求項１０】
さらに、ユーザ認証の認証失敗を検出する手段と、
前記認証失敗を検出した後にＩＰ接続処理を抑制する手段と、を有する、請求項１又は２に記載のＩＰ接続処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はＩＰ接続処理装置に関し、特に無線ＬＡＮ等により構築された所定エリアのＩＰ網に、ユーザ認証後直ちに接続を開始するＩＰ接続処理装置に関するものである。
【０００２】
【従来の技術】
インターネットの爆発的な普及により、現在注目を浴びている技術の一つに無線ＬＡＮがある。無線ＬＡＮは、当初はオフィス内のＬＡＮ環境を無線でつなぐ技術として開発された。しかしながら、最近では、駅や喫茶店などの公共スペースに無線ＬＡＮを設置し、それらの場所からインターネットに高速アクセスできる「ホットスポットサービス」という形態が普及してきている。
【０００３】
無線ＬＡＮのパケット通信速度は、ＩＥＥＥ８０２．１１ｂで規定する１１Ｍｂｐｓである。これは、第２世代移動通信システムＰＤＣ−Ｐの最大２８．８Ｋｂｐｓや、第３世代移動通信システムＩＭＴ−２０００の最大３８４Ｋｂｐｓ（Ｗ−ＣＤＭＡ通信方式）と比べても圧倒的に速い。
【０００４】
また、無線ＬＡＮによるホットスポットサービスは、上述した従来システムが従量制の課金システムを採用しているのに対して、コスト面でより有利な定額制の課金システムを採用している。そのため、現状では限定エリア内でしかホットスポットサービスを利用でないという問題も、やがてはサービスエリアの拡大により解消し、人が集まりそうな地域は面としてカバーされる予定である。
【０００５】
現在のホットスポットサービスはインターネットプロトコル・バージョン４（ＩＰｖ４）を利用している。しかしながら、近年におけるＩＰネットワーク上での端末数の増大により、ＩＰｖ４のアドレス不足が懸念されており、ホットスポットサービスについても、大きく拡張されたアドレス空間をもつインターネットプロトコル・バージョン６（ＩＰｖ６）への移行が期待されている。
【０００６】
図１は、無線ＬＡＮとＩＰｖ６とにより構成したネットワークの一例を示したものである。ここでは、ホットスポットサービスを例に説明する。
【０００７】
図１において、ＩＰ端末１０は、無線ＬＡＮとの通信機能を有するノートＰＣやＰＤＡ等からなる。ＩＰ端末１０は、その移動中等において、駅や喫茶店に設置された無線ＬＡＮのアクセスポイント（ＡＰ）２１と接続する。
【０００８】
アクセスポイント２１は、それを中心に所定範囲内のホットスポットエリア２０をカバーし、ホットスポットエリア２０内ではＩＰ端末１０に対して高速インターネット接続サービス又はそのエリア内に限定された情報サービス等を提供する。
【０００９】
また、アクセスポイント２１は、その上位のアクセスルータ（ＡＲ）３１と接続され、オペレータ網３０を介してインターネット４０と接続する。アクセスルータ３１は、例えば駅構内やデパート店内の所定個所、インターネットサービスプロバイダ（ＩＳＰ）、電話交換局、等に設置され、それらを相互に接続することでオペレータ網３０が形成されている。
【００１０】
オペレータ網３０の特定個所に設置された認証サーバ３２は、各ホットスポットエリア２０内におけるＩＰ端末１０のユーザ認証処理を一括して行う。認証サーバ３２によりユーザ認証されたＩＰ端末１０は、インターネット４０への接続が許可されて、例えば無線ＬＡＮの高速性を生かしたインターネット電話（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）等を通信相手４１との間で行うことができる。
【００１１】
図２は、無線ＬＡＮ上のＩＰｖ６接続シーケンスの一例を示したものである。また、図３には、ルータ広告メッセージのフォーマットを示している。
【００１２】
図２において、ＩＰ端末１０は、ホットスポットエリア２０内に移動してくると、無線ＬＡＮのアクセスポイント２１からの電波を検出する（Ｓ１０１）。それにより、ＩＰ端末１０はアクセスポイント２１との間で接続処理  （Ａｓｓｏｃｉａｔｉｏｎ）  を開始する（Ｓ１０２）。
【００１３】
ＩＰ端末１０から接続要求を受信すると、アクセスポイント２１は認証サーバ（ＲＡＤＩＵＳサーバ）３２にＩＰ端末１０のユーザ認証処理を依頼する（Ｓ１０３）。その結果、ユーザ認証が成功するとその旨がＩＰ端末１０に通知され（Ｓ１０４）、同時にアクセスポイント２１は口を開いてＩＰ端末１０によるＩＰネットワークへのアクセスを可能にする（Ｓ１０５）。
【００１４】
以降、ＩＰ端末１０は、アクセスルータ３１が周期的に送信するルータ広告メッセージを受信すると（Ｓ１０６）（例えば、非特許文献１参照）、図３に示すルータ広告メッセージのプレフィックス・フィールド（Ｐｒｅｆｉｘ）に含まれるルータ・プレフィックスを利用して、ＩＰ端末１０が在圏するホットスポットエリア２０内で使用する自己のＩＰアドレスを生成する（Ｓ１０７）（例えば、非特許文献２参照）。
【００１５】
ＩＰ端末１０は、このＩＰアドレスを使って、インターネット４０等を含むＩＰネットワークを介して通信相手４１との間でＩＰｖ６に基づく通信を開始する（Ｓ１０８）。なお、ＩＰｖ６は、その標準化団体ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）  が規定している（例えば、非特許文献３参照）。
【００１６】
また、無線ＬＡＮの認証方式については、その標準化団体ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｏｎｉｃｓ  ａｎｄ  Ｅｌｅｃｔｒｉｃａｌ  Ｅｎｇｉｎｅｅｒｓ）で規定するＩＥＥＥ８０２．１ｘが主流となっている。その標準にはＥＡＰ−ＴＬＳ（Ｅｘｔｅｎｓｉｂｌｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  −  Ｔｒａｎｓｐｏｒｔ  Ｌｅｖｅｌ  Ｓｅｃｕｒｉｔｙ）、ＥＡＰ−ＴＴＬＳ（Ｔｕｎｎｅｌｅｄ  ＴＬＳ）、ＰＥＡＰ−ＴＬＳ（Ｐｒｏｔｅｃｔｅｄ  ＥＡＰ  Ｐｒｏｔｏｃｏｌ）又はＥＡＰ−ＭＤ５等の認証メカニズムが含まれる。
【００１７】
ＩＥＥＥ８０２．１ｘの認証は、ｉ）ネットワークアクセスのために認証が必要なノード（ＩＰ端末）、ｉｉ）ネットワークアクセスをパケットレベルで制御するノード（ＡＰ）、ｉｉｉ）ネットワークアクセスを許可するノード（認証サーバ）、の３つのノードによって実現される。前述した構成も、このようなノード構成に基づくものである。
【００１８】
図４には、ＩＰ端末１０における従来のＩＰ接続処理構成の一例を示している。
【００１９】
図４において、インタフェース部１１は、アクセスポイント（ＡＰ）２１との間で所定の無線通信方式により無線通信を行なう。カーネル部１２は、一般のＩＰｖ６対応のオペレーティング・システム（ＯＳ）のカーネル部を示しており、その中には認証処理部１４とＩＰ処理部１３とが含まれている。
【００２０】
認証処理部１４は、アクセスポイント（ＡＰ）２１を介して認証サーバ３２との間でユーザ認証処理を実行する。また、ＩＰ処理部１３は、ユーザ認証処理が成功した後最初のルータ広告メッセージを受信すると、そこに含まれるルータ・プレフィックスを利用して自己のＩＰアドレスを生成する。各部１３及び１４は図２に示した接続シーケンスに従ってそれぞれ個別に動作する。
【００２１】
ところで、ホットスポットサービスを行なう無線ＬＡＮ環境下においては、ユーザの移動によるアクセスポイント間切替え（ハンドオーバ）をサポートする必要性が高まっている。上述した無線ＬＡＮによれば、同一ＩＰサブネット内（同一アクセスルータ配下）におけるアクセスポイント間切替え時には通信セッションは切断されない。
【００２２】
しかしながら、異なるＩＰサブネット（異なるアクセスルータ配下）に跨るアクセスポイント間切替え時にはＩＰ端末１０のＩＰアドレスが変わるため、通信セッションが切断されて再度ＩＰ接続処理を開始する必要がある。このため、無線ＬＡＮ環境下で通信が切断されない移動を実現できるモバイルＩＰ  （Ｍｏｂｉｌｅ  ＩＰ）  技術が重要となる。モバイルＩＰは、ＩＰレベルの移動管理メカニズムであって、次の例で説明するようにＩＰアドレスが変わっても通信セッションが切断されないという特徴がある。
【００２３】
図５は、無線ＬＡＮとＩＰｖ６とにより構成した別のネットワークの一例を示したものである。ここでは、モバイルＩＰｖ６  （Ｍｏｂｉｌｅ  ＩＰｖ６）  を例に説明する。
【００２４】
図５と先に説明した図１との相違は、図１のＩＰ端末１０を図５ではモバイルノード（ＭＮ）１０’と呼び、また図５ではインターネット４０にさらにホームエージェント（ＨＡ）４２が接続されている点だけである。ＩＰ端末１０とモバイルノード（ＭＮ）１０’とは呼び名を異にするが、実際は同様の機能を有する端末又はノードである。
【００２５】
ホームエージェント４２は、モバイルノード１０’の位置（エリア）を管理する。そのため、モバイルノード１０’に固有のＩＰアドレス（ＨｏＡ：Ｈｏｍｅ  Ａｄｄｒｅｓｓ）と、モバイルノード１０’が別のアクセスルータ（ＡＲ）３１配下へ移動する際に生成するＩＰアドレス（ＣｏＡ：Ｃａｒｅ  Ｏｆ  Ａｄｄｒｅｓｓ）とを保有する。
【００２６】
モバイルノード１０’は生成したＩＰアドレス（ＣｏＡ）をホームエージェント４２に通知し、ホームエージェント４２は既存のＩＰアドレス（ＣｏＡ）を通知されたＩＰアドレス（ＣｏＡ）に随時更新する。これにより、ある通信先のモバイルノード１０’との通信は、その移動先に係わらず通信先モバイルノード１０’の固有ＩＰアドレス（ＨｏＡ）を使ってホームエージェント４２との間で行なわれる。
【００２７】
ホームエージェント４２は、受信した固有のＩＰアドレス（ＨｏＡ）が付加されたデータを通信先のモバイルノード１０’が現に在圏するエリアのＩＰアドレス（ＣｏＡ）を付したトンネリングにより送出する。同様に、通信先のモバイルノード１０’は、発信元のモバイルノード１０’との通信を、発信元モバイルノード１０’の固有ＩＰアドレス（ＨｏＡ）を使ってホームエージェント４２との間で行なう。
【００２８】
図６は、無線ＬＡＮ環境下でのモバイルＩＰｖ６ハンドオーバシーケンスの一例を示したものである。
【００２９】
図６において、モバイルノード１０’は、はじめに旧アクセスポイント（旧ＡＰ）２１配下でホームエージェント４２を介して通信相手（ＣＮ：Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）４１’と通信を行っている（Ｓ２０１）。次に、モバイルノード１０’が新たなエリアに移動して別のアクセスポイント（新ＡＰ）２１’からの電波を検出する（Ｓ２０２及び２０３）。それにより、モバイルノード１０’は、新たなアクセスポイント２１’との間で接続処理  （Ａｓｓｏｃｉａｔｉｏｎ）  を開始する（Ｓ２０４）。
【００３０】
以降のステップＳ２０５〜２０９のユーザ認証処理は、先に説明した図２のステップＳ１０３〜１０７と同じである。次に、モバイルノード１０’は、自身が生成したＩＰアドレス（ＣｏＡ）をＢｉｎｄｉｎｇ＿Ｕｐｄａｔｅメッセージによりホームエージェント４２に通知する（Ｓ２１０）。それにより、ホームエージェント４２は既存のＩＰアドレス（ＣｏＡ）を新たなものに更新し、その更新完了をＢｉｎｄｉｎｇ＿Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔメッセージによりモバイルノード１０’に返信する（Ｓ２１１）。
【００３１】
これ以降、モバイルノード１０’は、新アクセスポイント２１’配下において通信を再開し、ホームエージェント４２を介して通信相手（ＣＮ：Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）４１’と通信を行なう（Ｓ２１２）。このように、ホームエージェント４２は、ＩＰアドレス（ＣｏＡ）の更新管理及び切替制御を一元的に実行するため、ＩＰアドレスの変更によっては通信セッションが切断されない。
【００３２】
なお、ＩＥＴＦのＲＦＣ２００２で標準化されている  Ｍｏｂｉｌｅ  ＩＰはＩＰｖ４をベースとしているが（例えば、非特許文献４参照）、ＩＰｖ６をベースとしたインターネット・ドラフト  Ｍｏｂｉｌｅ  ＩＰとＭｏｂｉｌｅ  ＩＰｖ６の基本的な動作は同じであるため、上記の例ではＭｏｂｉｌｅ  ＩＰｖ６について説明している。
【００３３】
【非特許文献１】
インターネット  ＜ＵＲＬ  ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４６１．ｔｅｘｔ＞
【非特許文献２】
インターネット  ＜ＵＲＬ  ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４６２．ｔｅｘｔ＞
【非特許文献３】
インターネット  ＜ＵＲＬ  ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４６０．ｔｅｘｔ＞
【非特許文献４】
インターネット  ＜ＵＲＬ  ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３３４４．ｔｅｘｔ＞
【００３４】
【発明が解決しようとする課題】
ところで、図１の無線ＬＡＮとＩＰｖ６を利用するネットワーク構成の場合には、ユーザ認証が必要とされる無線ＬＡＮ環境下でＩＰｖ６接続処理にかなりの時間を要するという問題があった。これは、図２のＩＰｖ６接続シーケンスに示すように、ユーザ認証が成功して通信が可能な状態となっても（Ｓ１０５）、アクセスルータ３１からルータ広告メッセージを受信するまではＩＰ接続処理が開始されないことに起因する（Ｓ１０６〜１０８）。
【００３５】
ＩＥＴＦで標準化されたＲＦＣ２４６１  “Ｎｅｉｇｈｂｏｕｒ  Ｄｉｓｃｏｖｅｒｙ  ｆｏｒ  ＩＰｖ６”  には、ルータが送信するルータ広告メッセージの周期に関する記載がある。それによれば、デフォルト周期が１９８秒に１回であり、最少周期が３秒に１回である。そのため、ルータ広告メッセージの送信タイミングによっては、ユーザ認証の終了からルータ広告メッセージを受信するまでに数秒〜３分程度の時間を要することになる。
【００３６】
その結果、ユーザ認証が成功したにも係わらず、ＩＰ端末１０のブラウザや通信アプリケーションによるＩＰ通信を開始できない問題が生じていた。この問題は、単にネットワーク側からルータ広告メッセージを受信するのが遅いというだけでなく、従来のＩＰ端末１０のＩＰ接続処理構成にも起因していた。
【００３７】
図４に示す従来構成で説明したように、一般のＩＰｖ６対応のオペレーティング・システム（ＯＳ）では、そのカーネル内部の認証処理部１４とＩＰ処理部１３とが図２に示す接続シーケンスに従ってそれぞれ個別に動作する。そのため、認証処理部１４はユーザ認証処理が終了するとそのプロセスを終了し、ルータ広告メッセージの受信をトリガにＩＰ接続処理を開始する。
【００３８】
このように、従来構成ではネットワークに対して積極的にルータ広告メッセージの早期送信を要求する手段がないため、又はその手段があったとしても、認証処理部とＩＰ処理部が連携されていないため、要求パケット（ルータ要請）が認証完了前に送られても、アクセスポイント（ＡＰ）で廃棄されてしまうため、以後のルータ広告メッセージの受信を待つしかないという問題があった。
【００３９】
上記の問題は、ＩＰ端末１０にモビリティを加えると更に重大化する。これは、ＩＰ端末１０の移動によってネットワーク側のアクセスルータ３１が頻繁に変更され、その都度通信が切断されてユーザ認証処理を含むＩＰ接続処理が再度要求されることになるためである。このため、図５の例では無線ＬＡＮ環境下でモバイルＩＰｖ６によるネットワーク構成を用いることでＩＰアドレスの変更時にも通信の切断を回避しようとしている。
【００４０】
しかしながら、図６のＩＰ接続シーケンスからも明らかなように、現状の無線ＬＡＮ環境下では、異なるアクセスルータ間に跨る移動時には必ずユーザ認証処理を含む新たなＩＰｖ６レベルの再接続処理が発生する。従って、この処理にかなりの時間を要すると、たとえモバイルＩＰｖ６を採用しても図１の例と同様の問題が発生する。
【００４１】
例えば、この時間が長引けば、通信相手４１’との通信が切断される。また、ハンドオーバ時にユーザが通信中であれば、ＩＰ通信が再開するまでアプリケーションが瞬断され、特にインターネット電話（ＶｏＩＰ）やビデオ・ストリーム等のリアルタイム・アプリケーションに対して、長い無通信時間は重大な問題を生じさせる。
【００４２】
上記の問題点は、ユーザ認証処理をＰＥＡＰ−ＴＬＳ等のように暗号化されたパケットを用いて行う場合により深刻となる。この場合には、認証パケットの受信後にその認証結果の解読処理がさらに必要となるため、認証成功を認識するまでの遅延が増大して高速ハンドオーバが困難となる問題があった。
【００４３】
上記のいずれの場合においても、複数のユーザからアクセスされるアクセスポイント（ＡＰ）の処理負荷を軽減して、無線ＬＡＮ環境下におけるＩＰ接続処理を一層高速化する必要がある。
【００４４】
そこで、本発明の目的は、上記種々の問題点に鑑みて、ＩＰ端末やモバイルノードにおけるＩＰ接続処理部の構成において、従来の認証処理部とＩＰ処理部に加えて、それら各部の動作を連携させる高速ＩＰ接続処理部を新たに設け、その高速ＩＰ接続処理部が認証処理部におけるユーザ認証完了を検出すると直ちにＩＰ処理部を起動させて、高速なＩＰ接続処理を実現するＩＰ接続処理装置を提供することにある。
【００４５】
具体的には、ユーザ認証の成功検出後に、起動されたＩＰ処理部又は高速ＩＰ接続処理部自らが直ちにネットワークにルータ広告メッセージを要求する。その応答として受信したルータ広告メッセージにより、以降のＩＰ接続処理を早期に開始させる。
【００４６】
また、ユーザ認証の成功／失敗に係わらず認証完了検出後、具体的には認証完了を含むパケット検出時に、起動されたＩＰ処理部又は高速ＩＰ接続処理部自らが直ちにネットワークにルータ広告メッセージを要求し、併せて、ユーザ認証失敗の際にアクセスポイントへの不要なアクセスを防止する手段を提供する。
【００４７】
その結果、無線ＬＡＮ環境下における既存のＩＰネットワーク構成を変更することなく、高速なＩＰ接続処理が実現される。ＩＰネットワークには、無線ＬＡＮ環境下におけるＩＰｖ６ネットワークやモバイルＩＰｖ６ネットワーク、そして従来のＩＰｖ４ネットワークのいずれもが含まれる。
【００４８】
【課題を解決するための手段】
本発明によれば、ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、認証完了を検出する検出手段と、認証結果を獲得する獲得手段と、認証が成功した認証完了を契機にＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有するＩＰ接続処理装置が提供される。
【００４９】
また本発明によれば、ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、認証完了を検出する検出手段（具体的には、認証完了を含むパケット検出時）と、前記認証完了を含むパケットの検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有するＩＰ接続処理装置が提供される。
【００５０】
さらに本発明によれば、ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、アクセスポイントとの間の暗号化を行なうための鍵を含むパケットを検出する検出手段と、前記鍵を含むパケットの検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有するＩＰ接続処理装置が提供される。
【００５１】
前記ＩＰ接続処理装置は、さらにユーザ認証の認証失敗を検出する手段と、前記認証失敗を検出した後にＩＰ接続処理を抑制する手段とを有する。
【００５２】
【発明の実施の形態】
図７は、本発明によるＩＰ端末又はモバイルノード内部のＩＰ接続処理装置の第１の基本構成を示したものである。
【００５３】
図７において、インタフェース部１１、認証処理部１４、及びＩＰ処理部１３は図４で説明した従来構成と同様である。本発明で新たに追加された高速ＩＰ接続処理部１５は、既存の認証処理部１４とＩＰ処理部１３との間の動作を連携させて高速なＩＰ接続処理を実現する。
【００５４】
図８及び９は、認証処理部１４の処理フロー例を示したものである。ここで、図８は認証結果パケットの受信処理フロー例を、そして図９は認証完了パケットの受信処理フロー例をそれぞれ示している。
【００５５】
図８では、認証パケットを受信すると、そのパケットを識別して認証結果パケットの場合には認証処理部１４で管理している認証結果情報を更新する（Ｓ３０１〜３０４）。
【００５６】
一方、図９では、認証パケットを受信すると、そのパケットを識別して認証完了パケットの場合には認証処理部１４で管理している認証状態を更新する（Ｓ３１１〜３１４）。また、いずれのパケットでもない場合には処理は終了する（Ｓ３０５及び３１５）。なお、受信した認証パケットが認証結果と認証完了の両方を含む同一パケットの場合には上記図８及び９の両方の処理が実行される。
【００５７】
図１０〜１２は、高速ＩＰ接続処理部１５の処理フローの一例を示したものである。ここで、図１０及び１１には認証処理部１４との連携に関する認証完了検出機能と認証結果獲得機能の処理フロー例を、そして図１２にはＩＰ処理部１３との連携に関するＩＰ接続処理機能の処理フロー例をそれぞれ示している。
【００５８】
図１０の（ａ）は、高速ＩＰ接続処理部１５が認証処理部１４に対して認証状況と認証結果を要求する処理フロー例を示している。
【００５９】
高速ＩＰ接続処理部１５は、認証処理部１４へ認証状態と認証結果とを要求し（Ｓ４０１及び４０２）、認証完了で且つ認証が成功すればＩＰ接続処理を実行する（Ｓ４０３及び４０４）。認証が不成功の場合には処理を終了する（Ｓ４０５）。この場合、認証処理部１４は、図８及び９で示した認証結果情報や認証状態を返信する。
【００６０】
図１０の（ｂ）は、それとは別の方法として、高速ＩＰ接続処理部１５が認証処理部１４に到達する前の認証完了パケットをキャプチャー（傍受）する処理フロー例を示している。
【００６１】
高速ＩＰ接続処理部１５は、認証処理部１４に到達する前の認証完了パケットをキャプチャーし、そのパケットから認証結果を抽出する（Ｓ４１２）。その結果、認証が成功であればＩＰ接続処理を実行する（Ｓ４１３及び４１４）。認証が不成功の場合には処理を終了する（Ｓ４１５）。なお、次の図１１との関係でいえば、本例は認証完了と認証結果の両方を含む同一パケットをキャプチャーする場合を示している。
【００６２】
図１１は、図１０の（ｂ）の別の態様例として、認証完了パケットと認証結果パケットとが異なるパケットで受信される場合に、事前に認証完了パケット及び認証結果パケットをキャプチャー（傍受）する処理フロー例を示している。
【００６３】
ここでは、先ず認証パケットを識別し、それが認証結果パケットであれば認証結果を抽出して保存しておく（Ｓ４２１〜４２５）。それが認証完了パケットであれば、前記認証結果の保存内容を確認して、それが「認証成功」であればＩＰ接続処理を実行する（Ｓ４２６〜４３１）。
【００６４】
このように、上記いずれの例においても、認証完了且つ認証成功の場合には直ちにＩＰ接続処理が実行される。
【００６５】
図１２の（ａ）は、高速ＩＰ接続処理部１５のＩＰ接続処理機能がＩＰ処理部１３にＩＰ接続処理を要求（Ｓ５０１）して実行を依頼する処理フロー例を示している。また、図１２の（ｂ）には、高速ＩＰ接続処理部１５のＩＰ接続処理機能がＩＰ処理部１３の代行処理を実行する処理フロー例を示している。後者の場合、高速ＩＰ接続処理部１５自らがＩＰ接続用のパケットを作成して送信する（Ｓ５１１及び５１２）。
【００６６】
次に、図１３及び１４は、ＩＰ処理部１３の処理フローの一例を示したものである。ここで、図１３にはルータ要請送信処理のフロー例を、そして図１４にはルータ広告受信処理のフロー例をそれぞれ示している。
【００６７】
図１３では、ルータ要請の送信トリガ、例えば、図１２の（ａ）で示した高速ＩＰ接続処理部１５からの要求、ルータ要請送信タイマの満了、又はアプリケーションからの送信要求、等が発生すると、ルータ要請パケットを作成して送信する（Ｓ６０１〜６０３）。なお、ルータ要請については、ＲＦＣ２４６１“Ｎｅｉｇｈｂｏｕｒ  Ｄｉｓｃｏｖｅｒｙ  ｆｏｒ  ＩＰｖ６”で定義されている
図１４では、ルータ広告メッセージを受信して、そこに含まれるプレフィックスが新しい場合には新たなＩＰｖ６アドレスを生成し（ＣｏＡ）、ＩＰ処理部１３で管理しているＩＰアドレス情報を更新する（Ｓ６１１〜６１５）。新しいプレフィックスでなければ処理を終了する（Ｓ６１６）。
【００６８】
図１５は、無線ＬＡＮ環境下での本発明によるＩＰｖ６接続シーケンスの一例を示したものであり、その内容は従来例の図２と対応する。
【００６９】
図１５のステップ７０１〜７０５及びＳ７０７、７０８は、図２のステップ１０１〜１０５及びＳ１０７、１０８とそれぞれ対応している。図１５のステップ７６１では、ＩＰ端末１０が本発明によるＩＰ接続処理装置を内蔵しており、その高速ＩＰ接続処理部１５を介して認証処理部１４に送られる認証パケット（Ｓ７０４）から認証結果「成功」と認証完了の情報を取得してＩＰ処理部１３にＩＰ接続処理を指示する。
【００７０】
ＩＰ処理部１３又は高速ＩＰ接続処理部１５は、直ちにルータ要請パケットを作成して送信する（Ｓ７６２）。これを受けてアクセスルータ３１はルータ広告メッセージをＩＰ端末１０へ送信する（Ｓ７６３）。以降は、図２と同様にＩＰ処理部１３がルータ広告メッセージに含まれるルータ・プレフィックスを利用して、自己のＩＰアドレス（ＣｏＡ）を生成して（Ｓ７０７）、通信相手４１との通信が短時間で開始される（Ｓ７０８）。なお、本発明によるＩＰ接続処理装置では、図１０〜１２に示した種々の高速ＩＰ接続処理部１５とＩＰ処理部１３との組み合わせが可能である。
【００７１】
図１６は、図１０の（ｂ）及び図１１に示した高速ＩＰ接続処理部１５が認証処理部１４に到達する前の認証完了パケットをキャプチャー（傍受）する実施例を示したものである。
【００７２】
ここでは、オペレーティング・システム（ＯＳ）として、Ｍｉｃｒｏｓｏｆｔ社  の  ＷｉｎｄｏｗｓＸＰ（登録商標）（以下「ＸＰ」という）を用いて説明する。この説明ではＸＰを使用するが、本発明は他のＯＳに関しても適用可能である。
【００７３】
図１６にはＸＰの簡略化した構成を示している。ＸＰは、カーネル１２の内部にＩＰ処理部１３及び認証処理部１４を有しており、ＩＥＥＥ８０２．１ｘ認証に関してはＥＡＰ−ＴＬＳ認証をサポートしている。本発明の高速ＩＰ接続処理部１５の認証完了検出機能及び認証結果獲得機能として、管理アプリケーション１７からカーネル１２の認証処理部１４を駆動するＡＰＩ  （Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を用いて、図１０の（ａ）に示した認証処理部１４へ要求を出すことができる。
【００７４】
本実施例では図１０の（ｂ）及び図１１に示した具体例を説明するが、その前に、図１７を用いて中間ドライバ１６の一般的な機能について説明しておく。ＸＰは、カーネル１２のＴＣＰ／ＩＰプロトコルスタック１３とデバイスドライバ１９の間に中間ドライバ１６が存在する。中間ドライバ１６は、通常は単にパケットをスルーさせるだけであるが、図１７の（ａ）及び（ｂ）に示すようにユーザ独自にパケットフィルタリング等の所定のドライバを追加することができる（Ｓ８０２及び８１２）。そのための標準インタフェース（ＮＤＩＳ：  Ｎｅｔｗｏｒｋ  Ｄｒｉｖｅｒ  Ｉｎｔｅｒｆａｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）が規定されている。
【００７５】
本実施例では、図１０の（ｂ）及び図１１に示す認証結果獲得処理及び認証完了検出処理を、この中間ドライバ１６やデバイスドライバ１９によって実現できる。上記処理とは、ネットワークから受信した認証パケットがカーネル１２の認証処理部１４に到達する前に、中間ドライバ１６やデバイスドライバ１９でキャプチャーし、キャプチャーしたパケットの中身から直接認証結果を得たり、認証完了を検出することである。
【００７６】
また、本実施例ではＩＰ接続処理の開始又は継続手段として図１２の（ｂ）に示すＩＰ処理部１３の代行処理も、中間ドライバ１６の内部処理や管理アプリケーション１７によって実現できる。この代行処理とは、高速ＩＰ接続処理部１５がルータ要請パケットを自分で作成して送信することである。
【００７７】
図１８は、より具体的な実施例の構成を示している。また、図１９にはＥＡＰ−ＴＬＳ認証処理の認証完了パケットである  ＥＡＰ  Ｓｕｃｃｅｓｓ  パケットのフォーマットを示している。以下、ウィンドウズネットワークドライバ上のＥＡＰ−ＴＬＳ認証完了処理を例に説明する。
【００７８】
ＩＰ端末１０又はモバイルノード１０’−  アクセスポイント２１−認証サーバ３２の間で行なわれるＥＡＰ−ＴＬＳ認証処理の公知のシーケンスにより、ＥＡＰ−ＴＬＳ認証処理が完了すると、図１９に示す認証完了パケットがＩＰ端末１０又はモバイルノード１０’に送くられてくる。ＥＡＰ−ＴＬＳ認証の成功はＥＡＰ−Ｓｕｃｃｅｓｓ  パケットのコードフィールド「３」で検出することができる。
【００７９】
本実施例では、先ず中間ドライバ１６のキャプチャー部２２がＥＡＰ−Ｓｕｃｃｅｓｓ  パケットをキャプチャーし、中間ドライバ１６の認証結果抽出部２３はそのコードフィールドが「３」であれば認証が成功したことが分かる。認証結果抽出部２３は、その認証の成功を管理アプリケーション１７にイベントとして通知する。
【００８０】
これにより、管理アプリケーション１７のルータ要請作成部２４がルータ要請パケットを作成してルータ要請メッセージをネットワーク側へ送信する。よって、本例ではＩＰ処理部１３がルータ要請を作成することはない。なお、管理アプリケーション１７自らがルータ要請を作成せずに、ＩＰ処理部１３にその作成と送信を要求するようにすれば、図１２の（Ａ）の構成となる。
【００８１】
図２０は、無線ＬＡＮ環境下での本発明によるモバイルＩＰｖ６ハンドオーバシーケンスの一例を示したものであり、その内容は従来例の図６と対応する。
【００８２】
図２０のステップ９０１〜９０７及びＳ９０９〜９１２は、図６のステップ２０１〜２０７及びＳ２０９〜２１２とそれぞれ対応している。図２０のステップは図１８に示す構成により、中間ドライバ１６が検出した認証完了と認証成功の情報により管理アプリケーションがルータ要請メッセージを送出する（Ｓ９８１及び９８２）。アクセスルータ３１は、この要請に応じてルータ広告メッセ−ジを返信する（Ｓ９８３）。これにより、ＩＰ処理部１３又は管理アプリケーションは、直ちにＩＰアドレス（ＣｏＡ）を生成して以降の処理を早期に開始する（Ｓ９０９〜９１２）。
【００８３】
なお、モバイルＩＰｖ６のハンドオーバでは、本願発明の高速ＩＰ接続処理部１５が自ら実行する処理は、上記実施例のルータ要請メッセージの作成と送信に限定されるべきではない。認証完了時には新しいＩＰアドレス（ＣｏＡ）を既に保有しているケースもあり得るからである。例えば、ＩＥＴＦで提案されているインターネット・ドラフト“Ｆａｓｔ  Ｈａｎｄｏｖｅｒｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰｖ６”では、  ＣｏＡを新しいアクセスルータへ移動する前に取得することでモバイルＩＰｖ６ハンドオーバを高速化している。
【００８４】
このような場合には、認証完了時のＩＰ接続処理として、ルータ要請メッセージではなく、Ｂｉｎｄｉｎｇ＿Ｕｐｄａｔｅ  メッセージをホームエージェントに送信してもよい。また、インターネット・ドラフト“Ｈｉｅｒａｒｃｈｉｃａｌ  ＭＩＰｖ６  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ”で提案されている階層的な移動管理を行う場合は、Ｂｉｎｄｉｎｇ＿Ｕｐｄａｔｅ  メッセージをホームエージェントへ送らずに、ローカルエリア内の移動を管理している移動アンカーポイント（Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ  Ｐｏｉｎｔ）へ送信するようにしてもよい。
【００８５】
これまでＩＰｖ６ネットワークを対象に本願発明を説明してきたが、次に本願発明を既存のＩＰｖ４ネットワークに適用した実施例について説明する。これより、本願発明自体は特定の認証メカニズムやノード構成には依存しないことが分かる。
【００８６】
図２１は、ＤＨＣＰ  （Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）  シーケンスを示しており、ＩＰｖ４ネットワークで一般的に用いられるＤＨＣＰサーバから認証完了直後の新しいＩＰアドレスを取得する。なお、ＤＨＣＰ処理はＲＦＣ２１３１で標準化されている。
【００８７】
本願発明によるＩＰ接続処理装置を備えたＩＰ端末１０又はモバイルノード１０’は、ユーザ認証完了を検出すると直ちにＤＨＣＰクライアントからＤＨＣＰサーバへの最初の要求“ＤＨＣＰＤＩＳＣＯＶＥＲ（発見）”を送出する。その結果、ユーザ認証完了を契機に図４に示すＤＨＣＰシーケンスが早期に開始され、ＩＰ端末１０又はモバイルノード１０’はＤＨＣＰサーバから最短時間で新しいＩＰアドレスを取得することができ、ＩＰネットワークへの高速接続が可能となる。
【００８８】
図２２は、無線ＬＡＮ環境下での本発明によるＩＰｖ４接続シーケンスの一例を示したものである。また、図２３は、無線ＬＡＮ環境下での本発明によるモバイルＩＰｖ４ハンドオーバシーケンスの一例を示したものである。
【００８９】
図２２及び２３の各動作はこれまでの説明から容易に理解できる。ＩＰｖ４に特有のシーケンスとしては、図２２の認証完了検出／認証結果獲得処理（Ｓ１００６）及びＩＰＶ４アドレス獲得シーケンス（Ｓ１００７）がある。同様に、図２３の認証完了検出／認証結果獲得処理（Ｓ１１０８）及びＩＰＶ４アドレス獲得シーケンス（Ｓ１１０９）がある。これらについては、まとめて前述してあるためそれらを参照願いたい。
【００９０】
なお、モバイルＩＰｖ４ハンドオーバでも、本願発明による高速ＩＰ接続処理部１５が行うＩＰ接続処理は上記実施例のＤＨＣＰ処理には限られない。認証完了時に新しいＩＰアドレス（ＣｏＡ）を既に獲得しているケースでは、“ＤＨＣＰＤＩＳＣＯＶＥＲ（発見）”に代えて  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔ  メッセージをホームエージェント４２へ送出してもよい。
【００９１】
また、モバイルノード１０’が在圏しているエリアにフォーリンエージェント（ＦＡ）が存在すれば  Ｒｅｇｉｓｔｒａｔｉｏｎ＿Ｒｅｑｕｅｓｔ  メッセージをフォーリンエージェントへ送信してもよい。さらに、ＣｏＡが取得済みで且つインターネット・ドラフト  “Ｍｏｂｉｌｅ  ＩＰｖ４  Ｒｅｇｉｏｎａｌ  Ｒｅｇｉｓｔｒａｔｉｏｎ”  で提案されている階層的な移動管理を行う場合には、ＩＰ接続処理として、ローカルエリアの移動管理を行うゲートウェイ・フォーリンエージェントに  Ｒｅｇｉｎａｌ＿Ｒｅｇｉｓｔｒａｔｉｏｎ＿Ｒｅｑｕｅｓｔメッセージを送信してもよい。
【００９２】
次に、本発明によるＩＰ接続処理を、暗号化された認証処理にも適用し得るようにした幾つかの実施例について説明する。
【００９３】
図２４は、本発明によるＩＰ接続処理装置の第２の基本構成を示したものである。図２５には、本発明による認証完了検出機能５１の処理フローの一例を示している。
【００９４】
図３６には、図２４を暗号化に特化した具体的な構成例を示している。暗号鍵を管理する暗号鍵管理部５５、暗号鍵を含むパケットを検出する暗号鍵パケット検出部５６は、図２４の認証処理部１４、認証完了検出機能５１にそれぞれ対応する。
【００９５】
図２４において、インタフェース部１１、認証処理部１４、高速ＩＰ接続処理部１５及びＩＰ処理部１３は図７の第１の基本構成と同様である。本例では、新たに認証完了検出機能５１が追加されている。
【００９６】
認証完了検出機能５１は、認証完了を含むパケットを検出すると（Ｓ１２０１）、その認証結果（成功／失敗）とは無関係に、その旨を高速ＩＰ接続処理部１５に通知してＩＰ接続処理を直ちに開始させる（Ｓ１２０２）。一方、認証処理部１４は、そのＩＰ接続処理と同時並行して、検出された認証完了を含むパケットの認証結果（成功／失敗）を判断して後述する対応処理を実行する。
【００９７】
図２６には、ＰＥＡＰ−ＴＬＳ認証処理の認証完了を含むデータパケットの一例を示している。ＰＥＡＰ−ＴＬＳ認証完了を含むパケットは、ＥＡＰ−Ｒｅｑｕｅｓｔメッセージのタイプフィールド「３３」で検出され、その認証結果はデータフィールドに含まれる「Ｓｕｃｃｅｓｓ」又は「Ｆａｉｌｕｒｅ」の暗号化データを解読することにより得られる。
【００９８】
図２７は、ユーザ認証が成功した場合のＩＰｖ６接続シーケンスの一例を示したものである。一方、図２８には、ユーザ認証が失敗した場合のＩＰｖ６接続シーケンスの一例を示している。以降では、図１５に示す本発明の第１の基本構成によるＩＰｖ６接続シーケンスとの相違点だけを説明する。
【００９９】
図２７のユーザ認証の成功例では、太実線の矢印で示す既知のＰＥＡＰ−ＴＬＳ認証処理が完了すると、アクセスポイント２１からＩＰ端末１０へ認証完了を含むパケット（タイプフィールド「３３」のＥＡＰ−Ｒｅｑｕｅｓｔメッセージ）が送出される（Ｓ１３０３及び１３０４）。また、ユーザ認証の「成功」によりアクセスポイント２１の口が開かれる（Ｓ１３０５）。
【０１００】
ＩＰ端末１０では、認証完了を含むパケット検出部５１がＥＡＰ−Ｒｅｑｕｅｓｔメッセージのタイプフィールド「３３」を検出すると（Ｓ１３０６）、ＩＰ処理部１３又は高速ＩＰ接続処理部１５が直ちにルータ要請パケットを作成して送信する（Ｓ１３０７）。それと同時並行して認証処理部１４が認証結果を獲得すべく暗号化データの解読処理を開始する（Ｓ１３０８）。
【０１０１】
アクセスルータ３１は、アクセスポイント２１を通過したルータ要請パケットを受けてルータ広告メッセージをＩＰ端末１０へ送信する（Ｓ１３０９）。以降は、認証処理部１４が「認証成功」を確認してＣｏＡを生成し（Ｓ１３１０）、通信相手４１との間でＩＰ通信を開始する（Ｓ１３１１）。このように、本例では認証結果を得るまでの時間とは無関係にＩＰ接続処理が直ちに開始される。
【０１０２】
一方、図２８のユーザ認証の失敗例では、太実線の矢印で示す既知のＰＥＡＰ−ＴＬＳ認証処理が完了しても（Ｓ１４０３及び１４０４）、ユーザ認証の「失敗」によってアクセスポイント２１の口は閉じたままである（Ｓ１４０５）。図２７と同様の処理によって、ＩＰ端末１０はＥＡＰ−Ｒｅｑｕｅｓｔメッセージのタイプフィールド「３３」の検出後にルータ要請パケットを送信するが（Ｓ１４０６及び１４０７）、そのルータ要請パケットはアクセスポイント２１で受付けられずに廃棄される（Ｓ１４０８）。
【０１０３】
ＩＰ端末１０の認証処理部１４は、やがて「認証失敗」を確認して（Ｓ１４０９）、ユーザ認証処理を終了するか又は再度ユーザ認証を試みる。これから、ＩＰ端末１０が、認証結果（成功／失敗）を確認せずに認証完了を含むパケットの検出後直ちにルータ要請パケットを送信しても、ネットワーク側の動作に特段の不都合を生じさせないことが分る。その一方で、図２７の「認証成功」時にはＩＰ接続処理が直ちに開始される。
【０１０４】
ここでは上述した図２７及び２８の一態様例として、ＩＰ端末１０とアクセスポイント２１との間でＷＥＰ（Ｗｉｒｅｄ  Ｅｑｕｉｖａｌｅｎｔ  Ｐｒｉｖａｃｙ）暗号化を行なう場合について説明する。図２９にはＷＥＰ暗号化を伴うＩＰｖ６接続シーケンスの一例を示しており、また図３０にはＥＡＰＯＬ鍵を含むパケットの一例を示している。なお、図２９には、図２７又は２８のルータ要請（Ｓ１３０７又はＳ１４０７）後のシーケンスだけを抜粋して示している。
【０１０５】
ＩＰ端末１０は認証完了を含むパケットを検出するだけでルータ要請を送信するために（Ｓ１３０７又はＳ１４０７）、アクセスポイント２１が意図するＷＥＰ暗号と合わない場合が生じる。この場合、そのルータ要請はアクセスポイント２１で受付けられずに廃棄され、アクセスポイント２１の口が閉じている状態となる（Ｓ１５０１）。この後、アクセスポイント２１からはＩＰ端末１０へＷＥＰ用鍵（ＥＡＰＯＬ鍵）が送信される（Ｓ１５０２）。
【０１０６】
図３０に示すように、ＥＡＰＯＬ鍵を含むパケットは、タイプフィールドが“３”で、キーインデックスフィールドが“ｕｎｉｃａｓｔ  ｉｎｄｅｘ＝１”により検出される。ＥＡＰＯＬ鍵は、ＩＰ端末１０とアクセスポイント２１との間でＷＥＰによる暗号化を行なうときの鍵を払い出す処理に使われ、無線路上の暗号化ではこの情報がアクセスポイント２１の口を開くタイミングとなり得る。
【０１０７】
本例では、ＩＰ端末１０においてＥＡＰＯＬ鍵を含むパケットの検出を契機にルータ要請を送信する。これにより、ＷＥＰ暗号化が行なわれている場合でも本発明による高速なＩＰ処理接続が可能となる。ここでは、認証完了を含むパケット検出部５１が、ＥＡＰＯＬ鍵を含むパケットの検出機能を兼ね備えており、それ以降の処理はこれまでの実施例と同様である。
【０１０８】
なお、本発明の第２の基本構成は、第１の基本構成で述べた各実施例、例えば中間ドライバの使用（図１８参照）等、にも当然に適用することができる。図１８の例でいえば、認証処理部１４が中間ドライバ１６を通過する認証完了を含むパケット及び／又はＥＡＰＯＬ鍵を含むパケットを傍受して検出するようにできる。また、認証完了検出機能５１を中間ドライバ１６内に配置してもよい。
【０１０９】
次に、本発明による端末からアクセスポイントに対する不要なトラフィックの発生を防止する構成について説明する。
【０１１０】
図３１は、本発明によるＩＰ接続処理装置の第３の基本構成を示したものである。図３２には、本例で用いられるアクセス規制テーブルの一例を示している。また、図３３〜３５には、本発明によるアクセス規制処理フローの一例を示している。
【０１１１】
図３１において、インタフェース部１１、認証処理部１４、高速ＩＰ接続処理部１５、ＩＰ処理部１３及び認証完了検出機能５１は、図２４と同様である。ここでは、ユーザ認証の失敗時における再認証処理の繰り返しによって、アクセスポイント２１に不要なトラフィックが発生するのを防止するためのアクセス規制テーブル制御部５２、及びそのアクセス規制時間を管理するタイマ管理部５３が新たに設けられている。
【０１１２】
アクセス規制テーブル制御部５２の内部には、図３２に示すアクセス規制テーブル５４が設けられており、その「アクセス規制」フィールドには本テーブルを用いるアクセス規制を実施する場合に“有効”を指定し、「アクセス規制対象全体」フィールドにはアクセス規制対象のアクセスポイントが１つでも存在すれば“有効”を指定する。
【０１１３】
また、「規制対象アクセスポイント」毎に１つのレコードが生成されて、その「規制対象ＡＰ」フィールドにはアクセスポイント毎のユニークな情報、例えばＢＳＳＩＤ（Ｂａｓｉｃ  Ｓｅｒｖｉｃｅ  Ｓｅｔ  Ｉｄｅｎｔｉｆｉｅｒ）等、が設定される。その「フラグ」フィールドには対応アクセスポイントでの認証失敗回数が所定の閾値を超えて規制有効状態になったときに“１”を、「失敗回数」フィールドには実際に認証を失敗した回数を、「規制閾値」フィールドには規制有効状態となる失敗回数を、そして「規制時間」フィールドにはアクセス規制時間内のときに“有効時間”を、それぞれ設定する。このアクセス規制時間が経過すると「規制時間」、「フラグ」及び「失敗回数」の各フィールドに“０”が設定され、アクセス規制が解除される。
【０１１４】
ここでは、図３３〜３５を参照しながら本発明によるアクセス規制処理について説明する。なお、本処理は、先に述べた認証結果獲得処理（図１５のステップＳ７６１、図２７のステップ１３０８、図２８のＳ１４０９、又は図２９のＳ１５０５）の中で、又はそれとの関連で実行される。
【０１１５】
図３３にはアクセス規制判定処理の一例を示している。認証完了検出機能５１は、認証処理部１４へ到達する前の認証結果をキャプチャーした際に、アクセス規制テーブル制御部５２から与えられるアクセス規制の情報に基づき、「アクセス規制」及び「アクセス規制対象全体」が共に有効であれば「規制対象アクセスポイント」を判定し、それが規制有効状態（フラグ“１”且つ規制時間“ｘ（０以外）”）であれば、対応アクセスポイント２１が規制中と判断して認証完了を含むパケットを廃棄する（Ｓ１６０２〜１６０４及びＳ１６０６）。これにより、不要なＩＰ接続処理の発生が未然に防止される。
【０１１６】
図３３のＳ１６０４の条件が一致した時のＳ１６０６への処理をＳ１６０７へのルートとさせた場合では、ＩＰ接続処理を行わないことによる、無効なトラフィックの防止と認証が成功した時に、直ぐにアクセス規制の解除を行なわせることが可能となる。
【０１１７】
これらの条件に該当しない場合には、認証完了検出機能５１が高速ＩＰ接続処理部１５へＩＰ接続処理を指示し（Ｓ１６０５）、同時に認証処理部１４へ認証完了を含むパケットを送出する（Ｓ１６０７）。アクセス規制テーブル制御部５２は、認証処理部１４の認証結果に基づいてアクセス規制テーブル５４を更新する（Ｓ１６０８）。
【０１１８】
図３４にはアクセス規制テーブルの更新処理の一例を示している。
【０１１９】
アクセス規制テーブル制御部５２は、認証処理部１４の認証結果が認証成功であれば該当「規制対象アクセスポイント」を削除して、全ての「規制対象アクセスポイント」が無くなると「アクセス規制対象全体」を“無効”にする（Ｓ１７０１及び１７０２）。認証失敗の場合には、最初の失敗かそれ以外の失敗かを判定し（Ｓ１７０３）、前者の場合には当該アクセスポイントの「規制対象アクセスポイント」レコードを新たに生成して登録する（Ｓ１７０４）。また、後者の場合にはその「失敗回数」をインクリメントする（Ｓ１７０６）。次に、それらが「規制閾値」を超える場合には所定の「規制時間」及び「フラグ」を設定して当該アクセスポイントを規制有効状態にする（Ｓ１７０５、１７０７及び１７０８）。
【０１２０】
図３４のアクセス規制を有効とした時に、オペレーティング・システムや、アプリケーション等へアクセス規制対象のアクセスポイント（ＢＳＳＩＤ）を通知することにより、上位からアクセスポイントを選択させないようにする契機を通知することも可能である。
【０１２１】
図３５にはタイマ管理部５３のタイマ処理の一例を示しており、該当アクセスポイントの「規制時間」が経過するとその旨をアクセス規制テーブル制御部５２に通知し、アクセス規制テーブル制御部５２はそれによって該当「規制対象アクセスポイント」を削除し、全ての「規制対象アクセスポイント」が無くなると「アクセス規制対象全体」を“無効”にする（Ｓ１８０１）。本発明によれば規制後の不要なＩＰ接続処理の発生やその再接続処理が抑制されるため、複数のＩＰ端末がアクセスするアクセスポイント２１のトラフィックが低減され、ネットワーク全体としてＩＰ接続処理が高速化される。
【０１２２】
（付記１）  ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
認証完了を検出する検出手段と、
前記認証完了の検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【０１２３】
（付記２）  ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
認証完了を検出する検出手段と、
認証結果を獲得する獲得手段と、
認証が成功した認証完了を契機にＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【０１２４】
（付記３）  前記ＩＰ接続装置は、
ＩＰ接続処理を行なうＩＰ処理部と、
認証処理を行なう認証処理部と、
前記認証処理部に認証完了の検出を要求し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する高速ＩＰ接続処理部と、から成る、付記１又は２に記載のＩＰ接続処理装置。
【０１２５】
（付記４）  前記高速ＩＰ接続処理部は、前記認証処理部に認証完了の検出を要求するのに代えて、前記認証処理部への入力情報を傍受して認証完了を検出し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する、付記１又は２に記載のＩＰ接続処理装置。
【０１２６】
（付記５）  ネットワーク接続にユーザ認証が必要とされるＩＰ網への接続処理装置であって、
アクセスポイントとの間の暗号化を行なうための鍵を含むパケットを検出する検出手段と、
前記鍵を含むパケットの検出を契機に、ＩＰ接続処理を開始し又は継続させるＩＰ接続手段と、を有することを特徴とするＩＰ接続処理装置。
【０１２７】
（付記６）  前記ＩＰ接続装置は、
ＩＰ接続処理を行なうＩＰ処理部と、
暗号鍵の管理を行なう暗号鍵管理部と、
前記暗号鍵管理部への入力情報を傍受して暗号鍵を検出し、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示する、高速ＩＰ接続処理部と、から成る、付記５記載のＩＰ接続処理装置。
【０１２８】
（付記７）  前記高速ＩＰ接続処理部は、前記認証処理部を含むオペレーティング・システムとデバイスドライバとの間で前記傍受を行なう他のドライバ、又は前記傍受を行なうデバイスドライバを含む付記１又は２に記載のＩＰ接続処理装置。
【０１２９】
（付記８）  前記高速ＩＰ接続処理部は、前記暗号鍵管理部を含むオペレーティング・システムとデバイスドライバとの間で前記傍受を行なう他のドライバ、又は前記傍受を行なうデバイスドライバを含む付記５に記載のＩＰ接続処理装置。
【０１３０】
（付記９）  前記高速ＩＰ接続処理部は、前記認証処理部と前記ＩＰ処理部とを含むオペレーティング・システムとの間の処理に、オペレーティング・システムのＡＰＩを利用する、付記３又は４に記載のＩＰ接続処理装置。
【０１３１】
（付記１０）  前記ＩＰ処理部は、前記指示により、前記ＩＰ網へＩＰアドレス情報の取得要請を行い、前記ＩＰ網から返信される情報により自己のＩＰアドレスを取得する、付記３、４又は６のいずれか一つに記載のＩＰ接続処理装置。
【０１３２】
（付記１１）  前記高速ＩＰ接続処理部は、前記検出を契機にＩＰ接続処理の開始又は継続を前記ＩＰ処理部へ指示するのに代えて、前記検出により、前記ＩＰ網へＩＰアドレス情報の取得要請を行い、
前記ＩＰ処理部は、前記ＩＰ網から返送される情報により自己のＩＰアドレスを取得する、付記３、４又は６のいずれか一つに記載のＩＰ接続処理装置。
【０１３３】
（付記１２）  アクセス網への接続時に前記ＩＰ接続処理を開始し、又はアクセス網間の移動時に前記ＩＰ接続処理を継続させる、付記１〜１１のいずれか一つに記載のＩＰ接続処理装置。
【０１３４】
（付記１３）  さらに、ユーザ認証の認証失敗を検出する手段と、
前記認証失敗を検出した後にＩＰ接続処理を抑制する手段と、を有する、付記１又は２に記載のＩＰ接続処理装置。
【０１３５】
（付記１４）  前記ＩＰ接続処理を抑制する手段は、アクセスポート毎のアクセス有効／無効を管理するアクセス規制テーブルを有する、付記１３記載のＩＰ接続処理装置。
【０１３６】
【発明の効果】
以上述べたように、本発明の第１の基本構成によれば不要なＩＰ接続処理を発生させずにＩＰ接続処理が高速化される。また、本発明の第２の基本構成によれば暗号復号処理等による遅延とは無関係にＩＰ接続処理が高速化される。さらに、本発明の第３の基本構成によればアクセスポイントでの不要なトラフィックが低減されてネットワーク全体としてＩＰ接続処理が高速化される。
【０１３７】
このように、ＯＳの認証処理部とＩＰ処理部とを連携させる高速ＩＰ接続処理部を新たに設けることで、ＩＰ通信が開始できるまでの接続時間を短縮することが可能となる。また、本発明を無線ＬＡＮ環境下のアクセスポイント切替えに適用することで、高速なハンドオーバが実現できる。
【図面の簡単な説明】
【図１】無線ＬＡＮとＩＰｖ６により構成したネットワークの一例を示した図である。
【図２】無線ＬＡＮ上のＩＰｖ６接続シーケンスの一例を示した図である。
【図３】ルータ広告メッセージのフォーマットを示した図である。
【図４】ＩＰ端末における従来のＩＰ接続処理構成の一例を示した図である。
【図５】無線ＬＡＮとＩＰｖ６により構成した別のネットワークの一例を示した図である。
【図６】無線ＬＡＮ環境下でのモバイルＩＰｖ６ハンドオーバシーケンスの一例を示した図である。
【図７】本発明によるＩＰ接続処理装置の第１の基本構成を示した図である。
【図８】認証処理部の処理フロー例（１）を示した図である。
【図９】認証処理部の処理フロー例（２）を示した図である。
【図１０】認証完了検出と認証結果獲得の処理フロー例（１）を示した図である。
【図１１】認証完了検出と認証結果獲得の処理フロー例（２）を示した図である。
【図１２】ＩＰ接続処理機能の処理フロー例を示した図である。
【図１３】ＩＰ処理部のルータ要請送信処理のフロー例を示した図である。
【図１４】ＩＰ処理部のルータ広告受信処理のフロー例を示した図である。
【図１５】無線ＬＡＮ環境下での本発明によるＩＰｖ６接続シーケンスの一例を示した図である。
【図１６】認証完了パケットをキャプチャー（傍受）する一実施例を示した図である。
【図１７】中間ドライバの一般的な機能を示した図である。
【図１８】図１６のより具体的な実施構成例を示した図である。
【図１９】ＥＡＰ  Ｓｕｃｃｅｓｓ  パケットのフォーマットを示した図である。
【図２０】無線ＬＡＮ環境下での本発明によるモバイルＩＰｖ６ハンドオーバシーケンスの一例を示した図である。
【図２１】ＤＨＣＰシーケンスを示した図である。
【図２２】無線ＬＡＮと本発明によるＩＰｖ４接続シーケンスの一例を示した図である。
【図２３】無線ＬＡＮ環境下での本発明によるモバイルＩＰｖ４ハンドオーバシーケンスの一例を示した図である。
【図２４】本発明によるＩＰ接続処理装置の第２の基本構成を示した図である。
【図２５】本発明による認証完了検出機能、具体的には認証完了を含むパケット検出の処理フローの一例を示した図である。
【図２６】ＰＥＡＰ−ＴＬＳの認証完了を含むパケットの一例を示した図である。
【図２７】図２４のユーザ認証が成功した場合のＩＰｖ６接続シーケンスの一例を示した図である。
【図２８】図２４のユーザ認証が失敗した場合のＩＰｖ６接続シーケンスの一例を示した図である。
【図２９】図２４でＷＥＰ暗号化が行なわれていた場合のＩＰｖ６接続シーケンスの一例を示した図である。
【図３０】ＥＡＰＯＬ鍵を含むパケットの一例を示した図である。
【図３１】本発明によるＩＰ接続処理装置の第３の基本構成を示した図である。
【図３２】アクセス規制テーブルの一例を示した図である。
【図３３】図３１のアクセス規制処理フロー例（１）を示した図である。
【図３４】図３１のアクセス規制処理フロー例（２）を示した図である。
【図３５】図３１のアクセス規制処理フロー例（３）を示した図である。
【図３６】図２４の暗号化における具体例を示した図である。
【符号の説明】
１０…ＩＰ端末
１０’…モバイルノード
１１…インタフェース部
１２…カーネル
１３…ＩＰ処理部
１４…認証処理部
１５…高速ＩＰ接続処理部
１６…中間ドライバ
１７…管理アプリケーション
１８…通常アプリケーション
２０…ホットスポットエリア
２１…アクセスポイント
２２…キャプチャー部
２３…認証結果抽出部
２４…ルータ要請作成部
３０…オペレータ網
３１…アクセスルータ
３２…認証サーバ
４０…インターネット
４１…通信相手
４２…ホームエージェント
５１…認証完了を含むパケット検出部
５２…アクセス規制テーブル制御部
５３…タイマ管理部
５４…アクセス規制テーブル
【図１】
2004254277.tif 000003
【図２】
2004254277.tif 000004
【図３】
2004254277.tif 000005
【図４】
2004254277.tif 000006
【図５】
2004254277.tif 000007
【図６】
2004254277.tif 000008
【図７】
2004254277.tif 000009
【図８】
2004254277.tif 000010
【図９】
2004254277.tif 000011
【図１０】
2004254277.tif 000012
【図１１】
2004254277.tif 000013
【図１２】
2004254277.tif 000014
【図１３】
2004254277.tif 000015
【図１４】
2004254277.tif 000016
【図１５】
2004254277.tif 000017
【図１６】
2004254277.tif 000018
【図１７】
2004254277.tif 000019
【図１８】
2004254277.tif 000020
【図１９】
2004254277.tif 000021
【図２０】
2004254277.tif 000022
【図２１】
2004254277.tif 000023
【図２２】
2004254277.tif 000024
【図２３】
2004254277.tif 000025
【図２４】
2004254277.tif 000026
【図２５】
2004254277.tif 000027
【図２６】
2004254277.tif 000028
【図２７】
2004254277.tif 000029
【図２８】
2004254277.tif 000030
【図２９】
2004254277.tif 000031
【図３０】
2004254277.tif 000032
【図３１】
2004254277.tif 000033
【図３２】
2004254277.tif 000034
【図３３】
2004254277.tif 000035
【図３４】
2004254277.tif 000036
【図３５】
2004254277.tif 000037
【図３６】
2004254277.tif 000038