(57)【要約】【課題】Ｐｒｅｆｉｘ通知機能やＨＡアドレス発見機能を使用する場合、ＭＮのホームアドレスやＨＡアドレスが変更されるため、ＭＮとＨＡ間にＩＰｓｅｃ  ＳＡを手動設定する方法は現実的ではない。また、現在のＭｏｂｉｌｅ  ＩＰｖ６にはＭＮ自身を認証する機能がない。【解決手段】ＣＡ３はＭＮ４に対するＰｒｅｆｉｘ配布可否情報を保持する。ＨＡ１のサーバ部１２はＣＡ３が許可したＭＮ４に対してＰｒｅｆｉｘ情報を配布する。ＨＡ１のサーバ部１１はＭＮ４からＩＫＥパケットを受信すると、サーバ部１２にＰｒｅｆｉｘ情報を確認後、ＩＰｓｅｃ  ＳＡを生成する。サーバ部１１はＩＰｓｅｃ  ＳＡを満たすＭＮ４の位置登録要求を許容する。【効果】ＣＡ３が許可したＭＮ４にＰｒｅｆｉｘを配布し、ＭＮ４が配布されたＰｒｅｆｉｘを用いてＨＡ１との間にＩＰｓｅｃ  ＳＡを生成することにより、ＭＮ４の正当性が確認できる。【選択図】  図１
2004274521.tif 000002
【特許請求の範囲】
【請求項１】
公開鍵証明書を発行及び保証する手段と、
端末装置に対するＩＰｖ６  Ｐｒｅｆｉｘ配布可否情報を保持する手段と、
端末装置から公開鍵証明書発行要求を受信し、前記端末装置のＰｒｅｆｉｘ配布可否情報を更新する手段とを備え、
前記端末装置から公開鍵証明書発行要求を受信して、前記端末装置の公開鍵証明書を発行し、前記Ｐｒｅｆｉｘ配布可否情報を更新し、前記端末装置に対して前記証明書を送信することを特徴とするサーバ装置。
【請求項２】
請求項１に記載のサーバ装置において、
Ｐｒｅｆｉｘ配布機能を有する情報処理装置との通信手段を備え、
前記情報処理装置からＰｒｅｆｉｘ配布可否の問い合わせを受信し、前記端末装置のＰｒｅｆｉｘ配布可否情報を検索し、得られた情報を前記情報処理装置に対して送信することを特徴とするサーバ装置。
【請求項３】
請求項１に記載のサーバ装置において、
端末装置の位置情報を管理する端末制御装置との通信手段を備え、
前記端末制御装置からＰｒｅｆｉｘ配布可否の問い合わせを受信し、前記端末装置のＰｒｅｆｉｘ配布可否情報を検索し、得られた情報を前記端末制御装置に対して送信することを特徴とするサーバ装置。
【請求項４】
公開鍵証明書を発行及び保証する機能とＰｒｅｆｉｘ配布許可情報とを備えるサーバ装置との通信手段と、前記サーバ装置から公開鍵証明書を取得する手段と、ＩＰｓｅｃによるセキュリティを確保する手段と、端末装置の位置情報を格納する手段とを備え、
端末装置から本人性確認信号を受信し、前記端末装置の公開鍵証明書を取得することを特徴とする端末制御装置。
【請求項５】
請求項４記載の端末制御装置において、Ｐｒｅｆｉｘ配布機能を有する情報処理装置との通信手段とを備え、
前記末装置から前記本人確認性信号を受信し、前記情報処理装置に対しＰｒｅｆｉｘ情報を問合せ、前記情報処理装置が前記Ｐｒｅｆｉｘ情報を配布していれば、前記本人性確認信号の応答を前記端末装置に対して送信することを特徴とする端末制御装置。
【請求項６】
請求項４または請求項５に記載の端末制御装置において、
前記端末装置から位置登録要求を受信し、前記端末装置のセキュリティ情報を読み出し、前記要求が前記セキュリティ情報に合致すれば前記端末装置の位置登録処理を行うことを特徴とする端末制御装置。
【請求項７】
請求項４から請求項６のいずれか１項に記載の端末制御装置において、
前記サーバ装置から前記端末装置のＰｒｅｆｉｘ配布許可情報を読み出し、前記サーバ装置が前記端末装置に対してＰｒｅｆｉｘの配布を許可すれば、前記端末装置にＰｒｅｆｉｘ情報を広告することを特徴とする端末制御装置。
【請求項８】
在圏網と、該在圏網に接続可能な端末装置と、該端末装置が属しかつ前記在圏網と相互接続されるホーム網と、該ホーム網に設置された端末制御装置と、公開鍵証明書を発行及び保証する手段を備えたサーバ装置と、Ｐｒｅｆｉｘ配布機能を備える情報処理装置とを備えた通信システムにおける端末認証方法において、
前記サーバ装置は前記端末装置に対して公開鍵証明書を発行し、前記端末装置のＰｒｅｆｉｘ配布情報を更新し、
前記情報処理装置は、
前記端末装置からＰｒｅｆｉｘ配布要求を受信し、前記サーバ装置に前記端末装置のＰｒｅｆｉｘ配布可否情報を問合せ、Ｐｒｅｆｉｘの配布が許可される場合前記端末装置にＰｒｅｆｉｘ情報を配布し、
前記端末制御装置は、
前記端末装置から本人性確認信号を受信し、前記端末装置のＰｒｅｆｉｘ情報を前記情報処理装置に送信し、
前記情報処理装置は、前記Ｐｒｅｆｉｘ情報を発行した端末装置と前記端末制御装置との間にセキュリティアソシエーションを確立することを特徴とする端末認証方法。
【請求項９】
請求項８に記載の端末認証方法において、前記ホーム網と前記在圏網を相互接続する通信装置が前記情報処理装置にＰｒｅｆｉｘ配布要求を送信することを特徴とする端末認証方法。
【請求項１０】
請求項８または請求項９に記載の端末認証方法において、
前記端末制御装置は、前記端末装置から位置登録要求を受信し、前記セキュリティアソシエーションを読み出し、前記位置登録要求が前記セキュリティアソシエーションを満たす場合に前記端末装置の位置登録を許可することを特徴とする端末認証方法。
【請求項１１】
請求項８から請求項１０のいずれか１項に記載の端末認証方法において、前記端末制御装置は、前記サーバ装置との通信手段と、端末装置の公開鍵証明書情報を格納する手段とを備え、
前記移動体通信装置は、前記サーバ装置が許可した端末装置に対してＰｒｅｆｉｘ情報を送信することを特徴とする端末認証方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、サーバ装置、移動体制御装置、および、端末認証方法に関する。特にモバイルＩＰ（Ｍｏｂｉｌｅ  ＩＰ）プロトコルを適用した通信システムにおける、公開鍵証明書の発行・保証を行うサーバ装置、ホームエージェント装置、および、端末認証方法に関する。
【０００２】
【従来の技術】
ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）は、Ｍｏｂｉｌｅ  ＩＰｖ６の仕様を検討している（Ｒｅｆ．  Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６  ＜ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１９．ｔｘｔ＞、  Ｗｏｒｋ  ｉｎ  Ｐｒｏｇｒｅｓｓ）。
Ｍｏｂｉｌｅ  ＩＰｖ６の網構成要素は、移動ノード（ＭＮ：Ｍｏｂｉｌｅ  Ｎｏｄｅ）、ホームエージェント（ＨＡ：Ｈｏｍｅ  Ａｇｅｎｔ）、通信相手（ＣＮ：Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）である。
ＭＮには移動しても変わることのない一意のＩＰアドレス（ホームアドレス）が付与される。ホームアドレスと同じプレフィックスを持つリンクをホームリンクと呼ぶ。ＨＡはホームリンク以外に存在するＭＮの位置情報（Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ）を管理する。
【０００３】
ＭＮはホームリンク以外のリンク（在圏リンク）において気付アドレス（Ｃａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ、以下ＣｏＡで表す）を取得する。ホームリンク以外に存在するＭＮは、在圏リンクに存在するルータが定期的に送信するルータ広告を受信する。ＭＮはホームアドレスと異なるプレフィックスを検出することで移動を検知してＣｏＡを生成する。ＭＮはＨＡにホームアドレスとＣｏＡの対応情報を登録する。
【０００４】
ＭＮは、Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ機能（ＨＡアドレス発見機能）を備え、ＨＡのＩＰアドレスを動的に検索してもよい。まず、ＭＮはホームリンクのプレフィックスからＭｏｂｉｌｅ  ＩＰｖ６  Ｈｏｍｅ−Ａｇｅｎｔｓ  Ａｎｙｃａｓｔ  Ａｄｄｒｅｓｓを作成する。ＭＮは上記アドレス宛にＨＡアドレス発見要求（ＩＣＭＰ  Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｑｕｅｓｔ）を送信する。上記信号は、ホームリンクのいずれかのＨＡが受信する。上記信号を受信したＨＡは、ＭＮに対してＨＡの情報を含むＨＡアドレス発見応答（ＩＣＭＰ  Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｐｌｙ）を送信する。ＭＮは上記信号からＨＡの情報を取り出し、ＨＡのアドレスを取得する。ＭＮは上記ＨＡアドレスに対して位置登録信号（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ）を送信する。
【０００５】
ＨＡは、上記信号（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ）を受信し、ＭＮの位置情報をＢｉｎｄｉｎｇ  Ｃａｃｈｅに格納する。
【０００６】
次に、ＨＡはＭＮのプロキシとして動作するため、ＭＮの代わりにＮｅｉｇｈｂｏｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔをホームリンクのａｌｌ−ｎｏｄｅｓ  ｍｕｌｔｉｃａｓｔアドレス宛に送信する。上記Ｎｅｉｇｈｂｏｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔを受信したノードは、Ｎｅｉｇｈｂｏｒ  Ｃａｃｈｅに、ＭＮのホームアドレスとＨＡのリンクレイヤアドレスの対応情報を格納する。ＨＡは、ＭＮのホームアドレス宛に送信されたパケットを捕捉する。
【０００７】
Ｍｏｂｉｌｅ  ＩＰｖ６は、ホームリンク以外に存在するＭＮに対して、ホーム網のプレフィックス情報を通知する機能を備える。例えば、ホーム網がプレフィックスを変更する場合、ＨＡはＢｉｎｄｉｎｇ  Ｃａｃｈｅを参照して位置登録中のＭＮにプレフィックス情報を通知（Ｍｏｂｉｌｅ  Ｐｒｅｆｉｘ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ）する。ＭＮはＨＡにプレフィックス情報を要請（Ｍｏｂｉｌｅ  Ｐｒｅｆｉｘ  Ｓｏｌｉｃｉｔａｔｉｏｎ）してもよい。
【０００８】
ＩＰ網上のセキュリティを実現する技術として、ＩＰ  Ｓｅｃｕｒｉｔｙ  Ｐｒｏｔｏｃｏｌ（ＩＰｓｅｃ）が注目されている。ＩＰｓｅｃは、暗号化技術や認証技術を使用して、ＩＰパケットを安全に運ぶ技術である。Ｍｏｂｉｌｅ  ＩＰｖ６は、ＭＮがＨＡに送信する位置登録信号にＩＰｓｅｃを適用する（Ｒｅｆ．  ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｍｉｐｖ６−ｈａ−ｉｐｓｅｃ−０１．ｔｘｔ、  Ｗｏｒｋ  ｉｎ  Ｐｒｏｇｒｅｓｓ）。
【０００９】
ＩＰｓｅｃは、ＩＰｓｅｃを適用する装置の間にＳＡ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ）を生成することによってセキュリティ機能を提供する。ＩＰｓｅｃを適用する装置は、ＳＰＤ（Ｓｅｃｕｒｉｔｙ  Ｐｏｌｉｃｙ  Ｄａｔａｂａｓｅ）とＳＡＤ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｓｉａｔｉｏｎ  Ｄａｔａｂａｓｅ）を備える。
【００１０】
ＳＰＤはパケットの処理方法を規定する。ＳＡＤは、ＩＰｓｅｃ適用装置が保持するＳＡのリストである。ＳＡはＳＰＩ（Ｓｅｃｕｌｉｔｙ  Ｐａｒａｍｅｔｅｒｓ  Ｉｎｄｅｘ）で識別する。
【００１１】
ＳＡの生成方法には、手動設定する方法と自動生成する方法がある。ＩＫＥ（Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）は、ＳＡを自動生成・管理するプロトコルである。ＩＫＥは、Ｐｒｏｐｏｓａｌ交換機能と、秘密対称鍵を生成する機能と、ＩＫＥ通信相手の認証機能とを用いてＳＡを自動生成する。
【００１２】
ＩＫＥ通信相手の認証方式には、Ｐｒｅ−Ｓｈａｒｅｄ  Ｋｅｙ認証方式、公開鍵暗号認証方式、デジタル署名認証方式等が規定されている。デジタル署名認証方式は、通信相手毎に事前に鍵情報等を共有する必要がないため、拡張性が高い。デジタル署名認証方式は、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ）が発行する公開鍵証明書を使用する。公開鍵証明書のフォーマットは、Ｘ．５０９で規定される。
【００１３】
ＣＭＰ（Ｃｅｒｔｉｆｉｃａｔｅ  Ｍａｎａｇｅｍｎｅｔ  Ｐｒｏｔｏｃｏｌ）は、電子証明書を発行・管理するプロトコルである。ＣＭＰは、ＩＥＴＦ  ＲＦＣ２５１０で規定される。ＣＭＰは、トランスポートプロトコルにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を利用する。
【００１４】
一方、Ｍｏｂｉｌｅ  ＩＰｖ６をベースに局所的な移動管理を行う技術として、Ｈｉｅｒａｒｃｈｉｃａｌ  Ｍｏｂｉｌｅ  ＩＰｖ６  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  （ＨＭＩＰｖ６）  （Ｒｅｆ．  ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｈｍｉｐｖ６−０７．ｔｘｔ、Ｗｏｒｋ  ｉｎ  Ｐｒｏｇｒｅｓｓ）が提案されている。
ＨＭＩＰｖ６は、ＨＡとＭＮの間にＭＡＰ（Ｍｏｂｉｌｅ  Ａｎｃｈｏｒ  Ｐｏｉｎｔ）を備える。ＭＮは、ＡＲ（Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ）からＭＡＰオプションを含むルータ広告を受信して、ＭＡＰのＩＰアドレスを取得し、地域気付アドレス（Ｒｅｇｉｏｎａｌ  Ｃｏｒｅ  ｏｆ  Ａｄｄｒｅｓｓ  ：  ＲＣｏＡ）とリンク気付アドレス（Ｏｎ−ｌｉｎｋ  ＣｏＡ  ：  ＬＣｏＡ）を生成する。ＨＭＩＰｖ６対応ＭＮは、ＭＡＰとＨＡに位置登録を行う。ＭＡＰはＭＮのＲＣｏＡとＬＣｏＡのバインディング情報を管理する。ＨＡはＭＮのホームアドレスとＲＣｏＡのバインディング情報を管理する。ＭＮがＭＡＰ内で移動した場合、ＭＮはＭＡＰの位置情報のみ更新する。
ＩＥＴＦは、ＩＰｖ６  Ｐｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ  Ｏｐｔｉｏｎｓ  ｆｏｒ  ＤＨＣＰｖ６  （以下、ＤＨＣＰ−ＰＤ）（ｄｒａｆｔ−ｉｅｔｆ−ｄｈｃ−ｄｈｃｐｖ６−ｏｐｔ−ｐｒｅｆｉｘ−ｄｅｌｅｇａｔｉｏｎ−０１．ｔｘｔ、Ｗｏｒｋ  ｉｎ  Ｐｒｏｇｒｅｓｓ）を検討している。ＤＨＣＰ−ＰＤは、ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を活用して、アドレス割当側からサイトにＩＰｖ６プレフィックス（群）を割り当てる機能である。
ＤＨＣＰ−ＰＤの構成要素は、Ｄｅｌｅｇａｔｉｎｇ  ＲｏｕｔｅｒとＲｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒである。Ｒｅｑｕｅｓｔｉｎｇ  ＲｏｕｔｅｒがＤｅｌｅｇａｔｉｎｇ  ＲｏｕｔｅｒにＩＰｖ６プレフィックス（群）の割り当てを要求する。Ｄｅｌｅｇａｔｉｎｇ  ＲｏｕｔｅｒはＩＰｖ６プレフィックス（群）を選択して、それをＲｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒに送信する。ＤＨＣＰ−ＰＤは、例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）が加入者にＰｒｅｆｉｘを割り当てるとき利用される。
【００１５】
【発明が解決しようとする課題】
領域Ａと領域Ｂが相互接続された通信システムにおいて、領域Ａに属する移動ノード（ＭＮ）が領域Ｂに移動した場合、ＭＮは領域Ａに存在するＨＡに位置登録を行う。位置登録信号には、ＩＰｓｅｃを適用する。
【００１６】
ＨＡとＭＮの間にＳＡを手動設定すると、暗号化などに使用する鍵が漏洩した場合、安全性が保てないという課題がある。また、Ｍｏｂｉｌｅ  ＩＰｖ６のプレフィックス通知機能やＨＡアドレス発見機能を使用すると、ＭＮのホームアドレス、或いは、ＨＡアドレスが変わる。このため、ＭＮとＨＡ間のＳＡを手動設定する方法は、システムの運用上現実的ではない。さらに、現状のＭｏｂｉｌｅ  ＩＰには、ＭＮの正当性を確認する手段がない。
【００１７】
本特許の目的は、Ｍｏｂｉｌｅ  ＩＰの技術を活用して、端末の認証方法を提供することにある。
特に、デジタル署名認証方法とＭｏｂｉｌｅ  ＩＰの位置登録手順を連携し、ＨＡが公開鍵証明書にリンクしたホームアドレスに対してＳＡを生成・保持することにより、端末に対する認証手順を提供する。
【００１８】
本発明のその他の目的は、ＭＮがホームアドレスを動的に取得する場合、ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  ＲｏｕｔｅｒとＣＡの連携と、及び、ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  ＲｏｕｔｅｒとＨＡの連携により、端末の正当性を確認する認証手順を提供することにある。
【００１９】
特に、領域Ａに属するＨＡをホーム網とする端末ｘが、領域ＢにおいてＤＨＣＰ−ＰＤ機能を活用してホーム網のプレフィックスを取得する場合、以下を目的とする。
１）ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒは、ＣＡが許可した端末に対してＰｒｅｆｉｘ情報を配布する。
２）ＨＡは、上記Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒが配布したＰｒｅｆｉｘをもつＩＰアドレスに対してＳＡを生成し、上記ＳＡを満たす位置登録を許容する。
【００２０】
本発明のその他の目的は、領域Ｂに属する通信装置がＨＭＩＰｖ６対応ＭＡＰであり、上記通信装置が、ＭＮから制御信号（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ）を受信してＤＨＣＰ−ＰＤ機能を起動する場合、ＤＨＣＰ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒは、ＣＡが許可した端末に対してＰｒｅｆｉｘ情報を配布する認証方法を提供することにある。
【００２１】
本発明のその他の目的は、ＨＡはＣＡが許可した端末に対してプレフィックス情報を広告する通信方法を提供することにある。
【００２２】
【課題を解決するための手段】
上記の問題を解決するために、本発明は、従来の認証方式に加えて少なくても以下の手段を備える。すなわち、
（１）ＣＡはＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能との通信手段を備える。また、ＣＡは、端末に対して公開鍵証明書を発行し、Ｐｒｅｆｉｘ情報の通知を許可する。
（２）端末は、Ｍｏｂｉｌｅ  ＩＰｖ６機能と、ＩＰｓｅｃ機能と、デジタル署名に必要な情報を保持する機能を備える。デジタル署名認証に必要な情報は、外部記憶装置から受信してもよい。端末は、移動端末でなくてもよい。
（３）端末制御装置は、ＤＨＣＰｖ６  Ｐｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ  Ｏｐｔｉｏｎ（以下、ＤＨＣＰ−ＰＤ）のＤｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能を備える。Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能は、ＣＡとの通信手段と、ＣＡが許可した端末に対してＰｒｅｆｉｘ情報を通知する手段を備える。
（４）端末制御装置は、端末からＳＡの生成要求を受信すると、上記ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  機能にＰｒｅｆｉｘ情報を問い合わせる。上記Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能が配布したＰｒｅｆｉｘを利用する端末であれば、端末制御装置は上記端末との間にＳＡを生成する手段を備える。
（５）あるいは、端末制御装置が端末の公開鍵証明書を保持する手段を備え、ＣＡが許可した端末に対してＰｒｅｆｉｘ情報を通知してもよい。
【００２３】
【発明の実施の形態】
（実施例１）
本発明の第１の実施の形態を図面を用いて説明する。なお、本実施例においては、ＨＡが端末制御装置に該当する。
【００２４】
代表例として、Ｍｏｂｉｌｅ  ＩＰｖ６対応移動ノード（ＭＮ）がホームリンク（以下、ホーム網）以外の網（以下、在圏網）に存在するとき、ＭＮの認証方法及び位置登録方法について詳細に説明する。
【００２５】
図１は、本発明における通信網の構成例を示す。通信網はＭＮ４のホーム網８とＩＰ網７と在圏網５（５ａ、５ｂ）から構成される。実施例において、ホーム網８、ＩＰ網７、及び、在圏網５はＩＰｖ６網である。ＭＮ４はＭｏｂｉｌｅ  ＩＰｖ６対応移動ノード（ＭＮ）である。情報家電端末９は、Ｍｏｂｉｌｅ  ＩＰｖ６対応ＭＮの機能を備える。在圏網５とＩＰ網７、及び、ＩＰ網７とホーム網８は、ルータ、或いは、ゲートウェイ装置を介して接続される。在圏網５とホーム網８は、ルータ、或いは、ゲートウェイ装置を介して直接接続してもよい。
ホーム網８は、ＨＡ１を備える。ＨＡ１はＭｏｂｉｌｅ  ＩＰｖ６対応ホームエージェント（ＨＡ）である。ＨＡ１はホーム網８以外に存在するＭＮの位置情報を管理する。
在圏網５（５ａ、５ｂ）は通信装置２（２ａ、２ｂ）とルータ６（６ａ、６ｂ、６ｃ、６ｄ）を備える。通信装置２は、ルータ６とのインタフェースと、ＩＰ網７とのインタフェースを備える。ルータ６は機器認証機能を備える。
ルータ６が機器認証機能を備える代わりに、ルータ６に機器認証機能を備えるサーバとの通信手段を備えてもよい。
ＩＰ網７はＣＡ３を備える。ホーム網８或いは在圏網５がＣＡ３を備えてもよい。
【００２６】
図２はＭＮ４のホーム網８に設置するＨＡ１の構成例を示す。ＨＡ１は、サーバ部１１（１１ａ、１１ｂ、）、サーバ部１２と、回線１８（１８ａ、１８ｂ、１８ｍ、１８ｎ）を収容するインタフェース部（ＩＦ）１９（１９ａ、１９ｂ、１９ｍ、１９ｎ）と、スイッチ部１７（１７ａ、１７ｂ）とから構成される。
【００２７】
サーバ部１１は、主にパケット送信・受信処理部１３と、ＩＰｓｅｃ処理部１４と、Ｍｏｂｉｌｅ  ＩＰ処理部１５とを備える。
パケット送信・受信処理部１３はデータパケットを送信又は受信する機能を備える。
ＩＰｓｅｃ処理部１４は、主にＳＰＤとＳＡＤとＩＰｓｅｃ処理ルーチン７０を備え、パケットの認証処理や暗号化処理を行う。また、ＩＰｓｅｃ処理部１４は、ＣＡ３からサーバ部１１の公開鍵証明書を取得する。
Ｍｏｂｉｌｅ  ＩＰ処理部１５は、Ｍｏｂｉｌｅ  ＩＰｖ６のホームエージェント（ＨＡ）機能を備える。Ｍｏｂｉｌｅ  ＩＰ処理部１５は、Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０を含む。
【００２８】
図３はＢｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０のテーブル構成の一例を示す。Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０は、ＭＮのホームアドレス３１１に対して、少なくてもＭＮが在圏網で取得したＣａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ  （ＣｏＡ）３１２と、Ｂｉｎｄｉｎｇ  Ｃａｃｈｅの有効期間を示すＬｉｆｅｔｉｍｅ３１３の対応関係を格納する。
【００２９】
サーバ部１２は、主にパケット送信・受信処理部１３と、ＤＨＣＰ  ＰＤ機能部１６とを備える。
【００３０】
ＤＨＣＰ  ＰＤ機能部１６は、ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能を備え、主にＰｒｅｆｉｘ管理テーブル３２０と、Ｐｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ処理ルーチン６０と、ＤＨＣＰ−ＰＤを識別するＩＡ＿ＰＤとＭＮの識別子の対応テーブルとを含む。
【００３１】
図４はＰｒｅｆｉｘ管理テーブル３２０のテーブル構成の一例を示す。Ｐｒｅｆｉｘ管理テーブル３２０は、ＤＨＣＰ  Ｃｌｉｅｎｔ識別子３２１に対して、少なくてもＰｒｅｆｉｘ（群）を示すＩＡＩＤ３２２と、配布したＰｒｅｆｉｘ３２３と、ＰｒｅｆｉｘのＬｉｆｅｔｉｍｅ３２４との対応関係を格納する。本実施例において、サーバ部１２のＤＨＣＰ−ＰＤ機能はＨＡ１に実装されるが、ＨＡ１とは別のサーバ装置に、ＤＨＣＰ‐ＰＤ機能を実装してもよい。
【００３２】
図７はＩＰ網７に設置する認証局（ＣＡ）３の構成例を示す。ＣＡ３は、ＣＰＵ３１と、メモリ３２と、回線３４を収容するインタフェース部（ＩＦ）３３とをバス３５で接続する構成をとる。
メモリ３２は、少なくてもＰｒｅｆｉｘ配布管理テーブル３３０と、公開鍵証明書発行ルーチン８０と、証明書情報格納テーブルとを備える。
【００３３】
図８はＰｒｅｆｉｘ配布管理テーブル３３０のテーブル構成の一例を示す。Ｐｒｅｆｉｘ配布管理テーブル３３０は、端末の識別子（ＩＤ）３３１に対してＰｒｅｆｉｘ発行許可か否かを示すフラグ３３２の対応関係を格納する。
【００３４】
図１７と図１８に示すシーケンスに従って、図１に示す網５ｂに在圏するＭＮ４の認証及び位置登録のシーケンスを説明する。本実施例において、ＭＮ４は、識別子と秘密鍵と公開鍵を、Ｓｅｃｕｒｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｃａｒｄ（ＳＭＭＣ）等の記憶装置から読み出す手段を備える。また、ＭＮ４は、ＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備えるとする。
【００３５】
電源を入れたＭＮ４は、網５ｂに属するルータ６ｃからルータ広告（Ｒｏｕｔｅｒ  Ａｖｅｒｔｉｓｅｍｅｎｔ）を受信する（１０１）。ＭＮ４はＲｏｕｔｅｒ  ＡｖｅｒｔｉｓｅｍｅｎｔのＭビットを参照して、ＣｏＡ（Ｃａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ）の取得方法を決定する。Ｍビットが１であれば、ＭＮはＩＰｖ６ステートフルアドレス自動構成を用いてＣｏＡを取得する。Ｍビットが設定されていなければ、ＭＮはＩＰｖ６ステートレスアドレス自動構成を用いてＣｏＡを生成する（１０２）。
【００３６】
次に、ＭＮ４は、ルータ６ｃに機器認証要求を送信する（１０３）。ルータ６ｃは、機器ＩＤを検索キーとして機器認証を行う。ルータ６ｃは、ＭＮ４に対して認証結果を含む機器認証応答を送信する（１０４）。機器ＩＤとして、例えばＭＡＣアドレスを用いる。
【００３７】
機器認証が正常に終了すると、ＭＮ４は、ＳＭＭＣ等の記憶装置からＭＮ４の識別子と秘密鍵と公開鍵を読み出す。ＭＮ４の識別子は、例えばＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）やＸ．５００のＤｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅで指定する。
【００３８】
ＭＮ４は、ＣＡ３に対しＭＮ４の公開鍵と識別子を含む公開鍵証明書発行要求を送信する（１０５）。公開鍵証明書の送受信には、例えば、ＣＭＰ（Ｃｅｒｔｉｆｉｃａｔｅ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を用いる。
【００３９】
図１１は、ＣＭＰメッセージを含むパケットのフォーマット例Ｓ１を示す。
【００４０】
図１０は、ＩＰｖ６パケットのフォーマットを示す。
ＣＭＰメッセージＳ１は、ＩＰｖ６パケットのＰａｙｌｏａｄ４３内のデータ部４３Ｂに格納される。
【００４１】
ＣＡ３は、上記要求を受信し、公開鍵証明書発行ルーチン８０を起動する。
【００４２】
図９は公開鍵証明書発行ルーチン８０を示す。ＣＡ３は、ＭＮ４の識別子を用いてＭＮ４に証明書を発行可能であるか確認し（８１）、発行可能であれば、ＭＮ４の公開鍵証明書を発行する。次に、ＣＡ３はＰｒｅｆｉｘ配布管理テーブル３３０にＭＮ４の新規エントリを生成し、Ｐｒｅｆｉｘ発行許可フラグを設定する（８２、１０６）。ＣＡ３は、ＭＮ４に対してＭＮ４の公開鍵証明書とＣＡ３の公開鍵を含む公開鍵発行要求応答を送信し、本ルーチンを終了する（８３、１０７）。
ステップ８１において証明書の発行が不可能でなる場合、或いは、ステップ８２においてＭＮ４の公開鍵に対して証明書を発行できない場合、ＣＡ３はＭＮ４に対してエラーを通知する証明書発行要求応答を送信し（８４）、本ルーチンを終了する。
ＨＡ１のサーバ部１１はＭＮ４と同様に識別子と秘密鍵と公開鍵を保持する。サーバ部１１は、ＣＡ３からサーバ部１１の公開鍵証明書を取得する。
ＭＮ４は、公開鍵証明書を取得すると、Ｐｒｅｆｉｘ  Ｒｅｑｕｅｓｔ処理を起動し、ホームＰｒｅｆｉｘを取得する。
ＭＮ４は、Ｐｒｅｆｉｘの配布が可能なＤＨＣＰ  Ｓｅｒｖｅｒを発見するため、ＤＨＣＰ  ＳｏｌｉｃｉｔメッセージをＡｌｌ＿ＤＨＣＰ＿Ｒｅｌａｙ＿Ａｇｅｎｔｓ＿ａｎｄ＿Ｓｅｒｖｅｒｓ  ａｄｄｒｅｓｓ宛に送信する（１０８）。上記ＳｏｌｉｃｉｔメッセージはＤＨＣＰ  Ｃｌｉｎｅｔ識別子（Ｃｌｉｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ  ｏｐｔｉｏｎ）とＩＡ＿ＰＤ  ｏｐｔｉｏｎｓを含む。上記ＩＡ＿ＰＤ  ｏｐｔｉｏｎｓには、Ｐｒｅｆｉｘを付与するグループ（ＩＡ＿ＰＤ）をＭＮ内で一意に示すＩＡＩＤが設定される。
【００４３】
図１２は、ＤＨＣＰｖ６メッセージを含むパケットフォーマット例Ｓ２を示す。ＤＨＣＰｖ６はトランスポートレイヤにＵＤＰ／ＩＰを使うアプリケーションプロトコルである。
ＤＨＣＰメッセージＳ２は、ＩＰｖ６パケットのＰａｙｌｏａｄ４３内のデータ部４３Ｂに格納される。ＤＨＣＰメッセージは、Ｍｅｓｓａｇｅ−ｔｙｐｅフィールド５１の値で指定する。ＤＨＣＰメッセージのオプションパラメータは、Ｏｐｔｉｏｎｓフィールド５３に設定される。
ここで、ＨＡ１のサーバ部１２が上記ＤＨＣＰ  Ｓｏｌｉｃｉｔメッセージ（１０８）を受信したとする。ＨＡ１のサーバ部１２は、Ｐｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ処理ルーチン６０を起動する。
【００４４】
図５は、Ｐｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ処理ルーチン６０を示す。
【００４５】
サーバ部１２は、上記ＤＨＣＰ  ＳｏｌｉｃｉｔメッセージのＩＡ＿ＰＤ  ｏｐｔｉｏｎｓからＩＡＩＤを読み出し、ＩＡＩＤに対してＰｒｅｆｉｘを配布可能であるか判断する（６１）。配布可能であれば、サーバ部１２は、上記ＤＨＣＰ  Ｓｏｌｉｃｉｔに含まれるＩＡＩＤからＩＡ＿ＰＤを特定する。サーバ部１２は、ＩＡ＿ＰＤ  を検索キーとして、ＩＡ＿ＰＤとＭＮ４の識別子の対応テーブルを参照し、ＭＮ４の識別子を決定する。サーバ部１２は、ＣＡ３にＭＮ４の識別子を含む問合せを送信する（６２、１０９）。
【００４６】
ＣＡ３は、上記問い合わせを受信すると、ＮＮ４の識別子を検索キーとしてＰｒｅｆｉｘ配布管理テーブル３３０を検索する（１１０）。
【００４７】
ＣＡ３は、ステップ１０６で生成したＭＮ４のエントリを検出する。ＣＡ３は該当エントリのＰｒｅｆｉｘ発行許可フラグが設定されていることを確認して、サーバ部１２にＰｒｅｆｉｘ割当許可を示す応答を送信する（６３、１１１）。
【００４８】
サーバ部１２は、上記応答を受信すると、上記ＤＨＣＰ  Ｓｏｌｉｃｉｔメッセージに含まれるＤＨＣＰ  Ｃｌｉｎｅｔ識別子とＩＡＩＤでＰｒｅｆｉｘ管理テーブル３２０を検索する。該当エントリがＰｒｅｆｉｘ管理テーブル３２０に存在しなければ、サーバ部１２はＰｒｅｆｉｘ管理テーブル３２０に新規エントリを生成し、上記ＤＨＣＰ  Ｓｏｌｉｃｉｔメッセージに含まれるＤＨＣＰ  Ｃｌｉｎｅｔ識別子３２１とＩＡＩＤ３２２を格納する。そして、サーバ部１２はＭＮ４にＤＨＣＰ  Ａｄｖｅｒｔｉｓｅメッセージを送信する（６４、１１２）。上記Ａｄｖｅｒｔｉｓｅメッセージは、サーバ部１２の識別子（Ｓｅｒｖｅｒ  Ｉｄｅｎｔｉｆｉｅｒ  ｏｐｔｉｏｎ）と、上記ＭＮ４の識別子（Ｃｌｉｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ  ｏｐｔｉｏｎ）と、ステップ１０８で受信したＩＡ＿ＰＤ  ｏｐｔｉｏｎｓを含む。サーバ部１２は、ＤＨＣＰ  Ａｄｖｅｒｔｉｓｅメッセージに配布可能なＩＰｖ６  Ｐｒｅｆｉｘ情報を含んでもよい。
ステップ６１において、サーバ部１２がＩＡＩＤに対してＩＰｖ６  Ｐｒｅｆｉｘを配布することができないとき、或いは、ステップ６３において、ＣＡ３がＰｒｅｆｉｘの配布を許可しないとき、サーバ部１２は上記ＭＮ４にＰｒｅｆｉｘ配布不可を示すＳｔａｔｕｓ  Ｃｏｄｅ  ｏｐｔｉｏｎを含むＡｄｖｅｒｔｉｓｅメッセージを送信し、本ルーチンを終了する（６７）。
【００４９】
ＭＮ４は、Ｐｒｅｆｉｘの配布が許可された場合、上記サーバ部１２にＩＡ＿ＰＤ  ｏｐｔｉｏｎｓ  を含むＤＨＣＰ  Ｒｅｑｕｅｓｔメッセージを送信し、ＩＰｖ６  Ｐｒｅｆｉｘ情報を要求する（１１３）。
ステップ１１２で受信したＡｄｖｅｒｔｉｓｅメッセージがＩＰｖ６  Ｐｒｅｆｉｘ情報を含む場合、上記Ｒｅｑｕｅｓｔメッセージは、ＭＮ４が利用を希望するＰｒｅｆｉｘを含む。
ここで、図５に戻りＰｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ処理ルーチン６０の説明を続ける。
サーバ部１２は、上記ＤＨＣＰ  Ｒｅｑｅｕｓｔメッセージを受信すると（６５）、ＩＡＩＤを読み出し、配布するＩＰｖ６  Ｐｒｅｆｉｘを特定する。上記ＲｅｑｕｅｓｔメッセージがＩＰｖ６  Ｐｒｅｆｉｘ情報を含む場合、ＭＮ４が利用を希望するＰｒｅｆｉｘを承認する。
次に、サーバ部１２は、上記ＤＨＣＰ  Ｒｅｑｅｕｓｔメッセージに含まれるＤＨＣＰ  Ｃｌｉｎｅｔ識別子とＩＡＩＤでＰｒｅｆｉｘ管理テーブル３２０を検索する。サーバ部１２は、ステップ６４で生成したエントリを検出して、該当エントリに配布するＩＰｖ６  ＰｒｅｆｉｘとＰｒｅｆｉｘのライフタイムを格納する。サーバ部１２はＭＮ４に対してＰｒｅｆｉｘ情報を含むＤＨＣＰ  Ｒｅｐｌｙメッセージを送信して（６６、１１４）、本ルーチンを終了する。
ステップ６５においてＭＮ４に配布するＰｒｅｆｉｘが特定できなかった場合、或いは、ステップ６６においてＰｒｅｆｉｘ管理テーブル３２０に該当エントリが存在しない場合、上記サーバ部１２はＭＮ４にエラーを通知するＤＨＣＰ  Ｒｅｐｌｙメッセージを送信し（６８）、本ルーチンを終了する。
ＭＮ４は、上記ＤＨＣＰ  ＲｅｐｌｙメッセージからＩＰｖ６  Ｐｒｅｆｉｘ情報を抽出する。ＭＮ４は上記Ｐｒｅｆｉｘ情報とＭＮ４のインタフェース識別子からホームアドレスを生成する（１１５）。
【００５０】
次にＭＮ４は、ＨＡアドレス発見機能を用いてＨＡアドレスを特定する。ＭＮ４は、ステップ１１４で受信したＰｒｅｆｉｘをホーム網のＰｒｅｆｉｘに設定したＭｏｂｉｌｅ  ＩＰｖ６  Ｈｏｍｅ−Ａｇｅｎｔｓ  Ａｎｙｃａｓｔ  Ａｄｄｒｅｓｓ宛に、ＨＡアドレス発見要求（Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｑｕｅｓｔ）を送信する（１１６）。
上記Ｍｏｂｉｌｅ  ＩＰｖ６  Ｈｏｍｅ−Ａｇｅｎｔｓ  Ａｎｙｃａｓｔ  Ａｄｄｒｅｓｓと同一Ｐｒｅｆｉｘを有するＨＡのいずれかが上記Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｑｕｅｓｔを受信する。
ここで、ＨＡ１のサーバ部１１ａが、上記Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｑｕｅｓｔを受信したとする。サーバ部１１ａは、ＭＮ４にＨＡアドレス発見応答（Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｐｌｙ）を送信する（１１７）。
【００５１】
ＭＮ４は、上記Ｈｏｍｅ  Ａｇｅｎｔ  Ａｄｄｒｅｓｓ  Ｄｉｓｃｏｖｅｒｙ  Ｒｅｐｌｙを受信して、ＨＡアドレス（サーバ部１１ａのアドレス）を取得する（１１８）。
次に、ＭＮ４は、ＩＫＥを用いてＭＮ４とサーバ部１１ａとの間にＩＰｓｅｃ  ＳＡを生成する。
ＩＫＥフェーズ１において、ＭＮ４とサーバ部１１ａの間にＩＳＡＫＭＰ  ＳＡを確立する。ＩＳＡＫＭＰ  ＳＡはＩＫＥの制御用チャネルである
ＭＮ４は、サーバ部１１ａに、ＳＡペイロードを用いてＩＳＡＫＭＰ  ＳＡのパラメータを提案する（１２１）。
【００５２】
図１３は、ＩＳＡＫＭＰのパケットフォーマット例Ｓ３を示す。ＩＫＥで使用するパケットのフォーマットは、ＩＳＡＫＭＰプロトコルで規定される。ＩＫＥのトランスポートプロトコルはＵＤＰ／ＩＰである。
ＩＳＡＫＭＰパケットＳ３は、ＩＰｖ６パケットのＰａｙｌｏａｄ４３内のデータ部４３Ｂに格納される。ＩＳＡＫＭＰパケットＳ３は、ＩＳＡＫＭＰヘッダ５５と１つ以上のペイロード５６で構成される。ペイロード５６には、例えば、ＳＡの提案を運ぶＳＡペイロード、ＩＤ情報を交換するＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード、デジタル署名を送信するＳｉｇｎｉｔｕｒｅペイロードなどがある。
サーバ部１１ａは、ステップ１２１で受信したＳＡペイロードから受諾可能なＰｒｏｐｏｓａｌを選択してＭＮ４に返信する（１２２）。
次に、ＭＮ４とサーバ部１１ａは、Ｄｉｆｆｅ−Ｈｅｌｌｍａｎ公開値とＮｏｎｃｅによる乱数を交換して（１２３、１２４）、秘密対称鍵を生成する。
続いて、ＭＮ４とサーバ部１１ａは、本人性を確認するため、ＩＤ情報を交換する。なお、本実施例では、本人であるかどうかの属性の確認の際に伝送される信号を本人性確認信号と定義している。図１４は、ＩＫＥフェーズ１の本人性確認に用いるＩＳＡＫＭＰパケットのフォーマット例Ｓ４を示す。ＩＳＡＫＭＰパケットＳ４は、  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎペイロード５６ＡとＳｉｇｎｉｔｕｒｅペイロード５６Ｂ、Ｃｅｒｔｉｆｉｃａｔｅペイロード５６Ｃを含む。
ＭＮ４は、サーバ部１１ａに本人性確認に用いるＩＳＡＫＭＰパケットを送信する（１２５）。上記ＩＳＡＫＭＰパケット１２５のＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード５６Ａは、ＭＮ４がステップ１１５で生成したホームアドレスを含む。ＭＮ４は、ハッシュ値を計算し、そのハッシュ値にＭＮ４の秘密鍵を用いてデジタル署名を行い、Ｓｉｇｎｉｔｕｒｅペイロード５６Ｂに設定する。Ｃｅｒｔｉｆｉｃａｔｅペイロード５６Ｃは、ＣＡ３が発行したＭＮ４の公開鍵証明書を含む。
サーバ部１１ａは、上記パケット１２５のＳｉｇｎｉｔｕｒｅペイロード５６ＢからＭＮ４のデジタル署名を取り出し、ＭＮ４の公開鍵を使ってデジタル署名を復号化する。ＭＮ４の公開鍵は、上記パケット１２５のＣｅｒｔｉｆｉｃａｔｅペイロード５６Ｃから取得する。
受信パケット１２５から計算したハッシュ値と、上記デジタル署名を復号化した値を比較することにより、サーバ部１１ａはパケット送信者ＭＮ４の本人性を確認する。
次にサーバ部１１ａは、上記パケット１２５のＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードからＭＮ４のホームアドレスを取り出す。サーバ部１１ａは、サーバ部１２にホームプレフィックスを含む問い合わせを送信する（１２６）。サーバ部１２は、上記問合せ１２６に含まれるＰｒｅｆｉｘを検索キーとして、Ｐｒｅｆｉｘ管理テーブル３２０を検索する。上記Ｐｒｅｆｉｘ管理テーブル３２０に該当エントリが存在すれば、Ｐｒｅｆｉｘは割当済みである（１２７）。サーバ部１２は、サーバ部１１ａに対してＰｒｅｆｉｘ割当済みを通知する応答を送信する（１２８）。
Ｐｒｅｆｉｘが割当済みであれば、サーバ部１１ａは、ＩＫＥフェーズ１の処理を継続する。サーバ部１１ａはハッシュ値にサーバ部１１ａの公開鍵を使ってデジタル署名を行う。サーバ部１１ａは、ＭＮ４に上記デジタル署名を含むＩＳＡＫＭＰパケットを送信する（１２９）。上記ＩＳＡＫＭＰパケット１２９のＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードには、サーバ部１１ａのＩＰアドレスを設定する。上記ＩＳＡＫＭＰパケットはサーバ部１１ａの公開鍵証明書を含んでもよい。
ＭＮ４は、上記パケット１２９を受信し、サーバ部１１ａの公開鍵を使ってＩＫＥ通信相手が本物であることを確認する。ＭＮ４は、サーバ部１１ａの公開鍵を上記パケット１２９の公開鍵証明書、或いは、ＣＡ３から取得する。
以上で、ＭＮ４とサーバ部１１ａの間にＩＳＡＫＭＰ  ＳＡが確立する。
次に、ＩＫＥフェーズ２において、ＭＮ４とサーバ部１１ａ間にＩＰｓｅｃ  ＳＡを生成する。上記ＩＰｓｅｃ  ＳＡは、ＭＮ４とサーバ部１１ａとの間のパケットをＩＰｓｅｃ化して転送する際に利用する。ＩＫＥフェーズ２で送受信されるＩＳＡＫＭＰパケットのペイロードは、ＩＫＥフェーズ１で確立したＩＳＡＫＭＰ  ＳＡによって暗号化される。
ＭＮ４は、サーバ部１１ａにＩＰｓｅｃ  ＳＡプロポーザルを含むＳＡペイロードと、Ｎｏｎｃｅペイロードと、ハッシュペイロードを設定したＩＳＡＫＭＰパケットを送信する（１３０）。サーバ部１１ａは、ＭＮ４に、受諾したＩＰｓｅｃ  ＳＡのプロポーザルを含むＳＡペイロードと、Ｎｏｎｃｅペイロードと、ハッシュペイロードを設定したＩＳＡＫＭＰパケットを送信する（１３１）。
ＭＮ４はサーバ部１１ａにハッシュペイロードを含むＩＳＡＫＭＰパケットを送信する（１３２）。サーバ部１１ａは、上記パケット１３２を受信して、ＮＮ４が上記パケット１３１を受信したことを確認する。以上の処理により、２本のＩＰｓｅｃ  ＳＡ（ＭＮ４からサーバ部１１ａへのＩＰｓｅｃ  ＳＡとサーバ部１１ａからＭＮ４へのＩＰｓｅｃ  ＳＡ）が生成される。サーバ部１１ａとＭＮ４は、上記ＩＰｓｅｃ  ＳＡ（ＳＰＩ、ＭＮ４のホームアドレス、サーバ部１１ａのアドレス等）をそれぞれＳＡＤに格納する。
ＭＮ４は、サーバ部１１ａに、上記ＩＫＥフェーズ２で生成したＳＡを適用した位置登録メッセージ（Ｂｉｎｉｄｎｇ  Ｕｐｄａｔｅ）を送信する（１３３）。ＭＮ４は、Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ  Ｌｉｓｔ管理テーブルにサーバ部１１ａのアドレスを仮登録する（１３４）。
【００５３】
図１５は、ＩＰｓｅｃを適用したＢｉｎｄｉｎｇ  Ｕｐｄａｔｅのメッセージフォーマット例Ｓ１１を示す。ＩＰｖ６  Ｄｅｓｔｉｎａｔｉｏｎ  Ｏｐｔｉｏｎｓ  Ｈｅａｄｅｒ４０１と、ＩＰｓｅｃヘッダ（ＡＨ  ＨｅａｄｅｒまたはＥＳＰ  Ｈｅａｄｅｒ）４０２と、ＩＰｖ６  Ｍｏｂｉｌｉｔｙ  Ｈｅａｄｅｒ４０３は、ＩＰｖ６パケットの拡張ヘッダ４２に格納される。
ＭＮ４がサーバ部１１ａに送信するＢｉｎｄｉｎｇ  Ｕｐｄａｔｅには、以下の値が格納される。ＭＮ４のＣｏＡがＩＰｖ６パケットヘッダの送信元アドレス４１ａに設定される。ＭＮ４がステップ１１５で生成したホームアドレスがＩＰｖ６  Ｄｅｓｔｉｎａｔｉｏｎ  Ｏｐｔｉｏｎｓ  Ｈｅａｄｅｒ４０１のＨｏｍｅ  Ａｄｄｒｅｓフィールドに設定される。
サーバ部１１ａは、上記Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ１３３を受信し、ＩＰｓｅｃ処理ルーチン７０を起動する。
【００５４】
図６は、ＩＰｓｅｃ処理ルーチン７０を示す。まず、ＩＰｖ６  Ｄｅｓｔｉｎａｔｉｏｎ  Ｏｐｔｉｏｎｓ  Ｈｅａｄｅｒ４０１を処理する（７１）。具体的には、Ｄｅｓｔｉｎａｔｉｏｎ  Ｏｐｔｉｏｎｓ  Ｈｅａｄｅｒの値（ホームアドレス）と送信元アドレスの値（ＣｏＡ）を入れ替える。
【００５５】
次に、サーバ部１１ａは、ＳＡＤをＩＰｓｅｃの種類（ＡＨ  ｏｒ  ＥＳＰ）、ＳＰＩ値、及び、着信先アドレスで検索し、ＩＰｓｅｃ  ＳＡを特定する。受信パケットが暗号化されている場合、サーバ部１１ａは受信パケットを復号化した後、特定したＩＰｓｅｃ  ＳＡに合致することを確認する（７２）。次にサーバ部１１ａは、ＳＰＤを参照して、再構築したパケットが受け入れ可能であるかチェックする（７３）。
パケットを受け入れ可能であれば、サーバ部１１ａのＩＰｓｅｃ処理部１４は上記再構築されたパケットをＭｏｂｉｌｅ  ＩＰ処理部１５に送信する。
【００５６】
Ｍｏｂｉｌｅ  ＩＰ処理部１５は、ＭＮ４の位置登録処理を行う（７４）。
Ｍｏｂｉｌｅ  ＩＰ処理部１５は、ＭＮ４のホームアドレスを検索キーとして、Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０を検索する。上記Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０にＭＮ４のエントリが存在しなければ、上記Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０にＭＮ４のエントリを追加する（１３５）。上記エントリのＣａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ３１２には、ＭＮ４が在圏網５ｂで取得したＣｏＡを設定する。
ステップ７２及びステップ７３において処理が正常に終了しなかった場合、サーバ部１１ａは受信パケットを廃棄し、本ルーチンを終了する（７８）。
【００５７】
Ｍｏｂｉｌｅ  ＩＰ処理部１５は、ＭＮ４に対してＩＰｓｅｃを適用したＢｉｎｄｉｎｇ  Ｕｐｄａｔｅの応答（Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を送信するため、ＩＰｓｅｃ処理部１４にパケットを送信する。ＩＰｓｅｃ処理部１４は、ＳＰＤを検索して上記パケットのセキュリティポリシーを調べる（７５）。上記パケットはＩＰｓｅｃの適用対象であることがわかり、ＳＡＤから合致するＳＡを検出する。ＩＰｓｅｃ処理部１４は、上記パケットにＲｏｕｔｅｉｎｇ  Ｈｅａｄｅｒ４０４を追加し、ＩＰｓｅｃを適用する（７６）。次にサーバ部１１ａは、Ｒｏｕｔｅｉｎｇ  Ｈｅａｄｅｒの値と着信先アドレスの値を入れ替え、ＭＮ４にＩＰｓｅｃを適用したＢｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｇｅｍｅｎｔを送信し（７７、１３６）、本ルーチンを終了する。
【００５８】
図１６は、ＩＰｓｅｃを適用したＢｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔメッセージのフォーマット例Ｓ１２を示す。ＩＰｖ６  Ｒｏｕｔｉｎｇ  Ｈｅａｄｅｒ４０４と、ＩＰｓｅｃヘッダ（ＡＨ  Ｈｅａｄｅｒ  ｏｒ  ＥＳＰ  Ｈｅａｄｅｒ）４０２と、ＩＰｖ６  Ｍｏｂｉｌｉｔｙ  Ｈｅａｄｅｒ４０３は、ＩＰｖ６パケットの拡張ヘッダ４２に格納される。サーバ部１１ａがＭＮ４に送信するＢｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔには、以下の値が格納される。ＭＮ４のＣｏＡがＩＰｖ６パケットヘッダの着信先アドレス４１ｂに格納される。ＭＮ４のホームアドレスがＩＰｖ６  Ｒｏｕｔｉｎｇ  Ｈｅａｄｅｒ４０４のＨｏｍｅ  Ａｄｄｒｅｓｓフィールドに格納される。
【００５９】
ＭＮ４は、Ｂｉｎｉｄｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ１３６を受信すると、ＳＡＤを検索してＳＡを特定する。受信パケットが暗号化されている場合、復号化した後ＳＡに合致することを確認する。さらにＳＰＤを参照して、再構築したパケットが受け入れ可能であるかチェックする。受け入れ可能であれば、ＭＮ４はステップ１３４で仮登録したエントリをＢｉｎｄｉｎｇ  Ｕｐｄａｔｅ  Ｌｉｓｔ管理テーブルに登録する（１３７）。
【００６０】
ここで、ＭＮ４は識別情報（例えばＦＱＤＮ）とステップ１１５で取得したホームアドレスの対応情報をホーム網８、在圏網５、或いは、ＩＰ網７に属する位置情報管理装置（例えばＤＮＳサーバ装置）に登録してもよい。
【００６１】
情報家電端末９がＭｏｂｉｌｅ  ＩＰｖ６機能とＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備え、ＣＡ３から公開鍵証明書を取得すれば、上記認証方法を情報家電端末９に適用できる。
本発明の第１の実施の形態によると、デジタル署名認証方法とＭｏｂｉｌｅ  ＩＰの位置登録手順が連携し、ＨＡが公開鍵証明書にリンクしたホームアドレスに対してＳＡを生成・保持することにより、ＩＰｖ６端末の正当性を確認する認証方法の提供が可能になる。
【００６２】
ＭＮ４とＨＡ１のサーバ部１１はＣＡ３が発行した公開鍵証明書を保持し、ＨＡ１のサーバ部１２とＭＮ４がＤＨＣＰ−ＰＤ機能を備える。ＣＡ３とＨＡ１のサーバ部１２の連携により、ＨＡ１はＣＡ３がＰｒｅｆｉｘの配布を許可したＭＮ４に対してＰｒｅｆｉｘの通知が可能になる。さらに、ＨＡ１のサーバ部１１は、サーバ部１２が割り当てたＰｒｅｆｉｘをホームプレフィックスとするＭＮ４との間でＩＰｓｅｃ  ＳＡを生成することにより、ＭＮの正当性を確認する認証方法の提供が可能になる。
（実施例２）
本発明の第２の実施の形態を図面を用いて説明する。
【００６３】
図１９は、本発明の第２の実施例における通信網の構成例を示す。第２の実施例は、通信装置２がＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備えることを特徴とする。第２の実施例において、ＩＰ網７は認証サーバ１０を備える。認証サーバ１０はホーム網へのアクセス認証に必要な情報（ＩＤ、パスワード等）を管理する。
【００６４】
図２０は、本発明の第２の実施例における通信装置２の構成例を示す。通信装置２はＣＰＵ２１と、メモリ２２と、回線２４（２４ａ、２４ｂ）を収容するインタフェース部（ＩＦ）２３（２３ａ、２３ｂ）とを、バス２５で接続する構成をとる。
【００６５】
メモリ２２は、主にＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備えるＤＨＣＰ  ＰＤ機能部２６と、ホーム網８へのアクセス認証を行う認証処理部２７とを備える。
【００６６】
図２１は、本発明の第２の実施例におけるＭＮ４の認証及び位置登録のシーケンスを示す。
第１の実施例と第２の実施例は、ＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能の配備箇所が異なる。第２の実施例において通信装置２（ＧＷ２）がＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備え、ＤＨＣＰ−ＰＤメッセージを送受信する。
ステップ１０１からステップ１０７は、第１の実施例と同様である。
以下、ステップ１４１以降について説明する。
ＧＷ２は、ＭＮ４からパケットを受信すると、ＭＮ４に対して認証情報を要求する（１４１）。ＭＮ４は、ＩＤとパスワードを含む認証要求を送信する（１４２）。ＧＷ２ｂはＩＡＩＤを含むＤＨＣＰ  Ｓｏｌｉｃｉｔを送信する（１４３）。
サーバ部１２は、上記ＤＨＣＰ  Ｓｏｌｉｃｉｔ受信し、ＩＡＩＤからＩＡ＿ＰＤを特定する。サーバ部１２は、ＩＡ＿ＰＤ  を検索キーとして、ＩＡ＿ＰＤとＭＮ４の識別子の対応テーブルを参照し、ＭＮ４の識別子を決定する。
ステップ１４４からステップ１４６は、第１の実施例におけるステップ１０９からステップ１１１と同様である。
【００６７】
サーバ部１２は、応答１４６を受信すると、ＧＷ２ｂにＤＨＣＰ  Ａｄｖｅｒｔｉｓｅを送信する（１４７）。以下、サーバ部１２におけるステップ１４８とステップ１４９の処理は、第１の実施例と同様である。
【００６８】
ＧＷ２ｂは、Ｐｒｅｆｉｘ情報を含むＤＨＣＰ  Ｓｏｌｉｃｉｔ１４９を受信すると、ＭＮ４にＰｒｅｆｉｘ情報を含む認証応答を送信する（１５０）。以下、ＭＮの認証処理及び位置登録処理は、第１の実施例のステップ１１５からステップ１３７と同様である。
本発明の第２の実施の形態によると、通信装置２がＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能を備える場合であっても、デジタル署名認証方法とＭｏｂｉｌｅ  ＩＰの位置登録手順の連携により、ＤＨＣＰ−ＰＤ機能を備えないＩＰｖ６端末の正当性を確認する認証方法が提供できる。
また、上記通信装置２がＨＡへのアクセス認証機能を提供することにより、より安全性の高い通信サービスの提供が可能になる。
（実施例３）
本発明の第３の実施の形態を図面を用いて説明する。
【００６９】
図２２は、本発明の第３の実施例における通信網の構成例を示す。第３の実施例は、第２の実施例に示す機能に加えて、通信装置２がＨＭＩＰｖ６のＭＡＰ機能を備えることを特徴とする。第３の実施例において、ＭＮ４はＨＭＩＰｖ６対応移動端末である。
【００７０】
図２３は、第３の実施例における通信装置２の構成例を示す。通信装置２のメモリ２２は、第２の実施例に示す機能に加えてＨＭＩＰｖ６処理部２９を備える。ＨＭＩＰｖ６処理部２９はＨＭＩＰｖ６のＭＡＰ機能を提供し、ＲＣｏＡとＬＣｏＡの対応情報を保持するＢｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブルを備える。
【００７１】
図２４に示すシーケンスに従って、図２２に示す網５ｂに在圏するＭＮ４の認証及び位置登録のシーケンスを説明する。
【００７２】
ＭＮ４は網５ｂに属するルータ（ＡＲ：Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ）６ｃからＭＡＰオプションを含むルータ広告（Ｒｏｕｔｅｒ  Ａｖｅｒｔｉｓｅｍｅｎｔ）を受信する（１６１）。ＭＮ４は、ルータ広告１６１の情報を用いて、通信装置（以下、ＭＡＰ）２ｂを特定し、ＲＣｏＡとＬＣｏＡを生成する（１６２）。
【００７３】
ステップ１０３からステップ１０７は、第１の実施例と同様である。
【００７４】
ＭＮ４は、ＣＡ３から公開鍵証明書を受信すると、  ＭＡＰ２ｂに位置登録信号（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ）を送信する（１６３）。
【００７５】
第３の実施例において、ＭＡＰ２ｂは位置登録信号の受信を契機に認証処理を起動する。以下、ステップ１４１からステップ１５０は、第２の実施例と同様である。
【００７６】
ステップ１５０までの処理が正常に終了した場合、ＭＡＰ２ｂはＨＭＩＰｖ６処理部２９のＢｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブルにＭＮ４のＲＣｏＡとＬＣｏＡの対応情報を格納する。ＭＡＰ２ｂはＭＮ４にＢｉｎｉｄｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔを送信する（１６４）。
【００７７】
以下、ＭＮの認証処理及び位置登録処理は、第１の実施例のステップ１１５からステップ１３７と同様である。
本発明の第３の実施例によると、通信装置２がＨＭＩＰｖ６機能を備える場合であっても、デジタル署名認証方法とＭｏｂｉｌｅ  ＩＰの位置登録手順の連携により、ＤＨＣＰ−ＰＤ機能を備えないＩＰｖ６端末の正当性を確認する認証方法が提供できる。
また、上記通信装置はＨＭＩＰｖ６の制御信号受信を契機に、ホーム網に対するアクセス認証処理を起動することが可能になり、より安全性の高い通信サービスの提供が可能になる。
（実施例４）
本発明の第４の実施の形態を図面を用いて説明する。本発明の第４の実施例における通信網の構成例は、第１の実施と同様である。
【００７８】
第４の実施例は、ＨＡ１のサーバ部１１が、ＣＡ３によって許可されたＭＮにしてＰｒｅｆｉｘを配布する手段と、ＭＮ４の公開鍵証明書管理テーブルを備えることを特徴とする。公開鍵証明書管理テーブルは、ＩＰｓｅｃフェーズ１のＩＳＡＫＭＰパケットに含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードの情報と公開鍵証明書の対応情報を格納する。
【００７９】
第４の実施例において、ＨＡ１とＭＮは、ＤＨＣＰ−ＰＤ機能を備えなくてもよい。ＭＮ４のＨＡは、サーバ部１１ａとする。
【００８０】
図２５から図２７に示すシーケンスに従って、図１に示す網５ｂに在圏するＭＮ４がＨＡ１のサーバ部１１ａに位置登録を完了後、ＨＡ１のサーバ部１１ａがＭＮ４にプレフィックスを通知し、ＭＮ４が再度位置登録を完了するまでのシーケンスを説明する。
ステップ１０１からステップ１０７は、第１の実施例と同様である。
続いて、ＭＮ４はサーバ部１１ａとの間でＩＰｓｅｃ  ＳＡを生成する。
ステップ１２１からステップ１２５は、第１の実施例と同様である。ＭＮ４は、サーバ部１１ａに対して、  ＭＮ４のホームアドレスを設定したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードとＭＮ４の公開鍵証明書を設定したＣｅｒｔｉｆｉｃａｔｅペイロードを含むＩＳＡＫＭＰパケット１２５を送信する。
サーバ部１１ａは、上記パケット１２５からＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードとＣｅｒｔｉｆｉｃａｔｅペイロードの情報を読み出し、ＭＮ４のエントリを公開鍵証明書管理テーブルに追加する（１７１）。ＭＮ４のエントリが存在する場合は、該当エントリを更新する。
ステップ１２９からステップ１３２は、第１の実施例と同様である。
ＭＮ４はサーバ部１１ａとの間に生成したＩＰｓｅｃ  ＳＡを適用して位置登録を行う。位置登録処理（ステップ１３３から１３７）は、第１の実施例と同様である。
サーバ部１１ａは、例えば自身のＰｒｅｆｉｘを変更する場合、位置登録中のＭＮ４に対してプレフィックスを通知する。
まず、サーバ部１１ａは、Ｂｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル３１０を参照し、ステップ１３５で生成したＭＮ４のエントリを検出する。次に、サーバ部１１ａは、ＭＮ４のホームアドレスを検索キーとして、公開鍵証明書管理テーブルを検索し、ステップ１７１で生成したＭＮ４の公開鍵証明書を読み出す。
サーバ部１１ａはＭＮ４の公開鍵証明書からＭＮ４の識別子を特定し、上記ＭＮ４の識別子を含む問合せをＣＡ３に送信する（１７３）。
【００８１】
ＣＡ３は、上記問い合わせを受信すると、ＮＮ４の識別子を検索キーとしてＰｒｅｆｉｘ配布管理テーブル３３０を検索する。
【００８２】
ＣＡ３は、ステップ１０６で生成したＭＮ４のエントリを検出する。ＣＡ３は該当エントリのＰｒｅｆｉｘ発行許可フラグが設定されていることを確認して（１７４）、サーバ部１１ａにＰｒｅｆｉｘ割当許可を示す応答を送信する（１７５）。
【００８３】
サーバ部１１ａは、上記応答を受信すると、ＭＮ４にプレフィックス情報を通知するＭｏｂｉｌｅ  Ｐｒｅｆｉｘ  Ａｄｖｅｒｔｉｓｅｍｅｎｔを送信する（１７６）。サーバ部１１ａは、上記Ｍｏｂｉｌｅ  Ｐｒｅｆｉｘ  Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージに、ステップ１３０から１３２で生成したＩＰｓｅｃ  ＳＡを適用する。
【００８４】
ＭＮ４は、上記Ｍｏｂｉｌｅ  Ｐｒｅｆｉｘ  Ａｄｖｅｒｔｉｓｅｍｅｎｔからプレフィックスを読み出す。ＭＮ４は、ホームプレフィックスの変更を検出し、ホームアドレスを生成する。ホームアドレスの生成から位置登録を完了するまでの処理（ステップ１１５〜１２５、ステップ１２９〜１３７）は、第１の実施例と同様である。
本発明の第４の実施例によると、ＨＡ１がＣＡ３と連携することにより、ＭＮの正当性を確認したのち、ＭＮ４にプレフィックス情報を通知することが可能になる。
【００８５】
【発明の効果】
以上の実施の形態から明らかなように、本発明はデジタル署名認証方法とＭｏｂｉｌｅ  ＩＰの位置登録手順の連携により、ＩＰｖ６端末の正当性を確認する認証方法を提供する。
【００８６】
特に、領域Ａに属するＨＡをホーム網とする端末ｘが領域ＢにおいてＭｏｂｉｌｅ  ＩＰの位置登録を行う際、領域Ａに属するＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能が領域Ｂに属する端末ＸにＰｒｅｆｉｘを配布する手段を備え、１）ＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能がＣＡにＰｒｅｆｉｘ配布可否を問い合わせる手段、２）ＨＡがＤＨＣＰ−ＰＤ  Ｄｅｌｅｇａｔｉｎｇ  Ｒｏｕｔｅｒ機能にＰｒｅｆｉｘ情報を問い合わせる手段、３）ＨＡが端末ｘとの間にＩＰｓｅｃ  ＳＡを生成する際、端末ｘの公開鍵をＣＡまたは端末ｘから取得する手段、４）ＨＡが上記３）で生成したＩＰｓｅｃを適用した位置登録のみ許容する手段、を備えることにより、端末ｘの正当性を確認する認証方法の提供が可能になる。
【００８７】
領域Ａと領域Ｂを相互接続する通信装置がＤＨＣＰ−ＰＤ  Ｒｅｑｕｅｓｔｉｎｇ  Ｒｏｕｔｅｒ機能と、領域Ａへのアクセス認証機能を備えれば、  ＤＨＣＰ−ＰＤ機能を備えない端末ｘに対して上記認証方法の提供が可能になる。また、上記通信装置は認証された端末ｘのみＨＡへのアクセスを許容するため、安全性の高い通信サービスの提供が可能になる。
【００８８】
さらに、上記領域Ａと領域Ｂを相互接続する通信装置が、ＨＭＩＰｖ６のＭＡＰ機能を備えれば、上記通信装置はＨＭＩＰｖ６の制御信号受信を契機に、領域Ａに対するアクセス認証処理を起動することが可能になる。
また、ＨＡ１がＣＡ３との通信手段とＭＮ４の公開鍵証明書を保持する手段を備えれば、ＨＡ１はＣＡ３にＭＮ４の正当性を確認したのち、ＭＮ４にプレフィックス情報を通知することが可能になる。
【図面の簡単な説明】
【図１】本発明における通信網の構成例を示す構成図。
【図２】ＨＡ１のブロック図。
【図３】ＨＡ１が備えるＢｉｎｄｉｎｇ  Ｃａｃｈｅ管理テーブル図。
【図４】ＨＡ１が備えるＰｒｅｆｉｘ管理テーブル図。
【図５】ＨＡ１のＤＨＣＰ  ＰＤ機能部が備えるＰｒｅｆｉｘ  Ｄｅｌｅｇａｔｉｏｎ処理ルーチン図。
【図６】ＨＡ１のＩＰｓｅｃ処理部が備えるＩＰｓｅｃ処理ルーチン図。
【図７】ＣＡ３のブロック図。
【図８】ＣＡ３が備えるＰｒｅｆｉｘ配布管理テーブル図。
【図９】ＣＡ３が備える公開鍵証明書発行ルーチン図。
【図１０】ＩＰｖ６パケットのフォーマット図。
【図１１】ＣＭＰメッセージ例の図。
【図１２】ＤＨＣＰｖ６パケットのフォーマット図。
【図１３】ＩＳＡＫＭＰパケットのフォーマット例の図。
【図１４】ＩＫＥフェーズ１本人性確認時のＩＳＡＫＭＰパケットのフォーマット例の図。
【図１５】Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅメッセージ例の図。
【図１６】Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔメッセージ例の図。
【図１７】本発明における認証及び位置登録シーケンス図１。
【図１８】本発明における認証及び位置登録シーケンス図２。
【図１９】第２の実施例における通信網の構成例を示す構成図。
【図２０】第２の実施例における通信装置２のブロック図。
【図２１】第２の実施例における認証及び位置登録シーケンス図。
【図２２】第３の実施例における通信網の構成例を示す構成図。
【図２３】第３の実施例における通信装置２のブロック図。
【図２４】第３の実施例における認証及び位置登録シーケンス図。
【図２５】第４の実施例における認証及び位置登録シーケンス図１。
【図２６】第４の実施例における認証及び位置登録シーケンス図２。
【図２７】第４の実施例における認証及び位置登録シーケンス図３。
【符号の説明】
１  ＨＡ、２  通信装置、３  ＣＡ、４  Ｍｏｂｉｌｅ  ＩＰ移動ノード（ＭＮ）、６０  Ｐｒｅｆｉｘ  Ｒｅｑｕｅｓｔ処理ルーチン、７０  ＩＰｓｅｃ処理ルーチン、８０  証明書発行ルーチン。
【図１】
2004274521.tif 000003
【図２】
2004274521.tif 000004
【図３】
2004274521.tif 000005
【図４】
2004274521.tif 000006
【図５】
2004274521.tif 000007
【図６】
2004274521.tif 000008
【図７】
2004274521.tif 000009
【図８】
2004274521.tif 000010
【図９】
2004274521.tif 000011
【図１０】
2004274521.tif 000012
【図１１】
2004274521.tif 000013
【図１２】
2004274521.tif 000014
【図１３】
2004274521.tif 000015
【図１４】
2004274521.tif 000016
【図１５】
2004274521.tif 000017
【図１６】
2004274521.tif 000018
【図１７】
2004274521.tif 000019
【図１８】
2004274521.tif 000020
【図１９】
2004274521.tif 000021
【図２０】
2004274521.tif 000022
【図２１】
2004274521.tif 000023
【図２２】
2004274521.tif 000024
【図２３】
2004274521.tif 000025
【図２４】
2004274521.tif 000026
【図２５】
2004274521.tif 000027
【図２６】
2004274521.tif 000028
【図２７】
2004274521.tif 000029