(57)【要約】【課題】ＬＡＮによりＰＰＰを使用しないでホストを収容する場合でも、ＩＰｖ６の特徴である自動コンフィギュレーションを活用できるようにする。【解決手段】ノード１４の各々に異なるグローバル（サイトローカル）アドレス用プレフィックスを付与することにより、各リンクローカル内に１つのノードが属するようする。本来はＩＰアドレスおよびＭＡＣアドレスの双方が共にマルチキャストであるルータ広告を、特定のノード１４に対して、そのノード１４のＩＰアドレスが不明でも送達できるようにする。これにより、そのノード１４に、当該ノード専用のプレフィックスを割当てる。【選択図】図２
2004072633.tif 000002
【特許請求の範囲】
【請求項１】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードをルータに収容するＩＰｖ６ノード収容方法であって、
前記ルータが、ＩＰｖ６ノード毎に固有のプレフィックスが設定された、ルータ広告を表すＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを生成し、このＩＣＭＰメッセージを、宛先ＩＰアドレスにマルチキャストＩＰアドレスが設定されたＩＰｖ６パケットに格納し、さらに、このＩＰｖ６パケットを、宛先ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスに前記固有のネットワークプレフィックスを設定すべきＩＰｖ６ノードのＭＡＣアドレスが設定されたＭＡＣフレームに格納して、前記ＬＡＮ上に送出すること
を特徴とするＩＰｖ６ノード収容方法。
【請求項２】
請求項１記載のＩＰｖ６ノード収容方法であって、
前記ルータが、自身に接続された認証サーバでのＩＰｖ６ノードの認証を通じて、当該ＩＰｖ６ノードのＭＡＣアドレスを入手すること
を特徴とするＩＰｖ６ノード収容方法。
【請求項３】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードをルータに収容するＩＰｖ６ノード収容方法であって、
ＩＰｖ６ノード間のアドレス重複通知を禁止すると共に、
前記ルータが、自身に接続された認証サーバでの認証に成功したＩＰｖ６ノード各々のＩＰアドレスおよびＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスを管理すると共に、ＩＰｖ６ノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスが他のＩＰｖ６ノードで使用中であるか否かを判定し、使用中である場合に、前記問合せをした前記ＩＰｖ６ノードに対してアドレス重複通知を行なうこと
を特徴とするＩＰｖ６ノード収容方法。
【請求項４】
請求項３記載のＩＰｖ６ノード収容方法であって、
前記ルータが、ＩＰｖ６ノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスと前記問合わせをしたＩＰｖ６ノードのＭＡＣアドレスとを比較して、前記対象ＩＰアドレスがＭＡＣアドレスベースで生成されたものか否かを判定し、ＭＡＣアドレスベースで使用されたものでない場合に、前記問合せをしたＩＰｖ６ノードに対してアドレス重複通知を行なうこと
を特徴とするＩＰｖ６ノード収容方法。
【請求項５】
請求項１、２、３または４記載のＩＰｖ６ノード収容方法であって、
前記複数のＩＰｖ６ノード各々が、前記ルータあるいは前記ルータおよび前記複数のＩＰｖ６ノード間を中継するブリッジのみが復号可能な暗号鍵を用いて、通信を行なうこと
を特徴とするＩＰｖ６ノード収容方法。
【請求項６】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードを収容するルータと、前記複数のＩＰｖ６ノードを認証する認証サーバとを有するＩＰｖ６ノード収容システムであって、
前記認証サーバは、
認証に成功したＩＰｖ６ノードに付与すべき固有のプレフィックスを生成して、これを当該ＩＰｖ６ノードのＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスと共に、前記ルータに通知し、
前記ルータは、
前記認証サーバより通知された固有のプレフィックスが設定された、ルータ広告を表すＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを生成し、このＩＣＭＰメッセージを、宛先ＩＰアドレスにマルチキャストＩＰアドレスが設定されたＩＰｖ６パケットに格納し、さらに、このＩＰｖ６パケットを、宛先ＭＡＣアドレスに前記認証サーバより通知されたＭＡＣアドレスが設定されたＭＡＣフレームに格納して、前記ＬＡＮ上に送出すること
を特徴とするＩＰｖ６ノード収容システム。
【請求項７】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードを収容するルータと、前記複数のＩＰｖ６ノードを認証する認証サーバとを有するＩＰｖ６ノード収容システムであって、
前記複数のＩＰｖ６ノード各々は、前記ルータあるいは前記ルータおよび前記複数のＩＰｖ６ノード間を中継するブリッジのみが復号可能な暗号鍵を用いて、通信を行ない、
前記認証サーバは、
認証に成功したＩＰｖ６ノードのＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスとを前記ルータに通知し、
前記ルータは、
前記認証サーバより通知されたＭＡＣアドレスとこのＭＡＣアドレスを有するＩＰｖ６ノードが使用中のＩＰアドレスとを管理すると共に、ＩＰｖ６ノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスが他のＩＰｖ６ノードで使用中であるか否かを判定し、使用中である場合に、前記問合せをした前記ＩＰｖ６ノードに対してアドレス重複通知を行なうこと
を特徴とするＩＰｖ６ノード収容システム。
【請求項８】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードを収容するルータであって、
ＩＰｖ６ノード毎に固有のプレフィックスが設定された、ルータ広告を表すＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを生成し、このＩＣＭＰメッセージを、宛先ＩＰアドレスにマルチキャストＩＰアドレスが設定されたＩＰｖ６パケットに格納し、さらに、このＩＰｖ６パケットを、宛先ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスに前記固有のネットワークプレフィックスを設定すべきＩＰｖ６ノードのＭＡＣアドレスが設定されたＭＡＣフレームに格納して、前記ＬＡＮ上に送出すること
を特徴とするルータ。
【請求項９】
ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により複数のＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）ノードを収容するルータであって、
自身に接続された認証サーバでの認証に成功したＩＰｖ６ノード各々のＩＰアドレスおよびＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスを管理すると共に、ＩＰｖ６ノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスが他のＩＰｖ６ノードで使用中であるか否かを判定し、使用中である場合に、前記問合せをした前記ＩＰｖ６ノードにアドレス重複通知を行なうこと
を特徴とするルータ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＰｖ６ノードのネットワーク接続技術に関する。
【０００２】
【従来の技術】
ＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）に関し、ＩＥＴＦ（Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）規格のＲＦＣ２４６１”Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）”およびＲＦＣ２４６３”ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ”に、ネットワークへの接続に際して、ノードがＩＰ通信に必要な最低限のコンフィグレーションを自動で行う手順（自動コンフィギュレーション）が規定されている。
【０００３】
図１８は、ＩＰｖ６の自動コンフィギュレーションの動作手順を説明するためのシーケンス図である。図示するように、自動コンフィギュレーションは、３つの段階ＳＴ１００１〜ＳＴ１００３で構成される。
【０００４】
（１）ＳＴ１００１：リンクローカルアドレスの仮決め
先ず、ノードは、インターフェースＩＤを、ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスをベースとして生成する。ＭＡＣアドレスからインタフェースＩＤを生成する方法は、ＲＦＣ２３７３”ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ”に規定されている。そして、このインターフェースＩＤにリンクローカルアドレス用の固定プレフィックスを付加し、これをリンク（サブネット）内でのみ使用可能なＩＰアドレスであるリンクローカルアドレスに仮決めする。
【０００５】
（２）ＳＴ１００２：リンクローカルアドレスの正式決定
次に、ノードは、仮決めしたリンクローカルアドレスが同一リンク内で既に使用されているか否かを、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージによりリンク内にマルチキャストで問合せる（アドレス重複問合せ：Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔ）。ここで、アドレス重複問合せのソースアドレスは０である（ｓｒｃＩＰａｄｄｒ＝０）。そして、規定時間内に、リンク内の他ノードから応答（アドレス重複通知：Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅ）がなかった場合は、仮決めしたリンクローカルアドレスを正式採用する。
【０００６】
もし、リンク内の他のノードがそれに応答した場合は、この他のノードが同一のリンクローカルアドレスを既に使用中である。アドレス重複問合せをしたノードは、このリンクローカルアドレスを使用することはできない。つまり、自動コンフィグレーションは失敗となる。アドレス重複問合せをしたノードは、ユーザの介在等により適切なＩＰｖ６アドレスをノードに割当てなければ、ＩＰ通信を行なうことができない。
【０００７】
（３）ＳＴ１００３：グローバル（サイトローカル）アドレスの決定
次に、ノードは、ルータがＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージによりリンク内で定期的にマルチキャストで広告しているルータ広告（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅ）を受信する。そして、ルータ広告からグローバル（サイトローカル）アドレス用プレフィックスを取得し、これを正式採用したリンクローカルアドレスに付加することで、ノードがルータを超えたＩＰ通信に必要なグローバル（サイトローカル）アドレスを決定する。
【０００８】
グローバル（サイトローカル）アドレス用プレフィックスは、グローバル（サイトローカル）内でユニークであることが保証されている。これにより、ノードは、ルータを経由したグローバル（サイトローカル）でのＩＰ通信が可能になる。なお、ルータ広告を受信することで、ノードは、ルータのＭＡＣアドレス、ＩＰｖ６アドレスを学習する。
【０００９】
以上のように、ノードがＩＰ通信を行う上で必要な最低限のコンフィグレーションを、ユーザの介在なしに自動で行えるのがＩＰｖ６の利点のひとつである。
【００１０】
ところで、現在主流のＩＰｖ４（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　４）で実現されているアクセスサービスの１つに、公衆無線ＬＡＮアクセスサービスがある。
【００１１】
公衆無線ＬＡＮアクセスサービスは、喫茶店や駅に、ブリッジとして動作する無線ＬＡＮの基地局であるＡＰ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ）を設置し、これをＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）に接続することで、無線ＬＡＮとのインターフェースを備えたホストのインターネットアクセスを実現するものである。
【００１２】
公衆無線ＬＡＮアクセスサービスにおいて、ホストを収容する方法としては、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ　Ｐｒｏｔｏｃｏｌ）をホスト−ＩＳＰ間で確立する方法と、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ、ＩＥＥＥ８０２．３シリーズのネットワーク）によりＰＰＰを使用しないでホストを収容する方法とがある。
【００１３】
後者は、前者に比べ、ＩＰ通信開始時のオーバヘッドが小さいことや、通常のＬＡＮ接続と同様の設定で手軽にネットワークアクセスできることなどの利点がある。後者においてホストの認証には、ＩＥＥＥ８０２．１委員会が規定した８０２．１Ｘ規格が使用される。ＩＥＥＥ８０２．１Ｘ規格は、ブリッジが、それにアクセスしてきたノードを認証した上で、そのノードのＭＡＣフレーム（ＩＥＥＥ８０２．３シリーズのフレーム）の送受信を許可するプロトコルである。公衆無線ＬＡＮアクセスサービスでは、ＡＰがノードに対してユーザ名とパスワードを要求して入手し、これらをＲＡＤＩＵＳ（Ｒｅｍｏｔｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｄｉａｌ−Ｉｎ　Ｕｓｅｒ　Ｓｅｒｖｉｃｅ）サーバへ送信して認証を依頼する。そして、ＲＡＤＩＵＳサーバでの認証結果に基づいて、ＡＰがノードのネットワークアクセスを制御する。
【００１４】
【発明が解決しようとする課題】
さて、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する方法を用いて公衆無線ＬＡＮアクセスサービスを実現しようとした場合、ＩＰｖ６の特徴である自動コンフィグレーションを活かしつつ、如何にしてノードを収容するリンク（サブネット）の可用性を高めるかが問題となる。
【００１５】
例えば、図１８のＳＴ１００２において、あるノードが行なったアドレス重複問合せに対し、リンク内の他のノードがそれに応答しアドレス重複通知を行なうことで、前記あるノードがこのアドレスを使用するのを禁止することができる。このため、悪意を持ったノードの存在により自動コンフィギュレーションが成功しなくなる可能性がある。
【００１６】
また、図１８のＳＴ１００３において、ルータ以外のあるノードがルータ広告を行なうことにより、このノード以外のノードは、ルータ広告を行なったノードをルータと認識して、ネットワークアクセスを試みてしまう。このため、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性がある。
【００１７】
これらの問題は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する方法を用いて、加入者宅からのインターネットアクセスサービスを実現しようとした場合にも、同様に生じる。
【００１８】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する場合に生じる問題を解決することにある。例えば、ＩＰｖ６の特徴である自動コンフィギュレーションを有効活用できるようにすることにある。また、ネットワークアクセスできなくなる可能性を低減することにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、本発明では、各ノードへのアドレス割当てにルータを介在させ、ルータに、ノード間のアドレス重複が生じないように、各ノードにアドレスを割当てることにより、ＩＰｖ６においてＬＡＮによりＰＰＰを使用しないでノードを収容する。
【００２０】
例えば、ノードの各々に異なるグローバル（サイトローカル）アドレス用プレフィックスを付与することにより、各リンクローカル内に１つのノードが属するようにする。具体的には、ノード毎に固有のプレフィックスが設定されたルータ広告用ＩＣＭＰメッセージを生成し、このＩＣＭＰメッセージを、宛先ＩＰアドレスにマルチキャストＩＰアドレスが設定されたＩＰｖ６パケットに格納する。さらに、このＩＰｖ６パケットを、宛先ＭＡＣアドレスに前記固有のプレフィックスを設定すべきＩＰｖ６ノードのＭＡＣアドレスが設定されたＭＡＣフレームに格納して、ＬＡＮ上に送出する。なお、ノードのＭＡＣアドレスは、当該ノードの認証（ＩＥＥＥ８０２．１Ｘ規格による認証）を通じて入手すればよい。
【００２１】
このようにすることで、本来はＩＰアドレスおよびＭＡＣアドレスの双方が共にマルチキャストであるルータ広告を、特定のノードに対して、そのノードのＩＰアドレスが不明でも送達できる。これにより、そのノードに、当該ノード専用のプレフィックスを割当てることができる。そして、各ノードに専用のプレフィックスを割当てれば、ノード間でのインタフェースＩＤの重複は発生しない。したがって、各ノードのＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。
【００２２】
また、上記課題を解決するために、本発明では、ノード間のアドレス重複通知を禁止する。例えば、ノード固有の暗号鍵を用いて、ルータとノードとの間の通信、あるいは、ルータおよびノード間を接続するブリッジとノードとの間の通信を行なうようにする。これにより、ノードがルータ以外の他ノードと直接通信できないようにする。さらに、本発明では、認証（ＩＥＥＥ８０２．１Ｘ規格による認証）に成功した各ノードのＩＰアドレスおよびＭＡＣアドレスを管理する。そして、あるノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスが他のＩＰｖ６ノードで使用中であるか否かを判定する。使用中である場合に、前記問合せをしたノードに対してアドレス重複通知を行なう。なお、使用中のＩＰアドレスに対するアドレス重複問合せがあった場合は、ルータがネットワーク管理装置に通知することで、どのユーザ間でアドレス重複が発生したかを管理するようにしてもよい。
【００２３】
このようにすることで、各ノードのＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。また、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
【００２５】
先ず、本発明の第１実施形態について説明する。
【００２６】
図１は、本発明の第１実施形態が適用される公衆無線ＬＡＮアクセスサービスシステムの概略図を示している。
【００２７】
図示するように、喫茶店や駅といったスポット１０毎に、ブリッジとして動作する無線ＬＡＮの基地局であるＡＰ１２が設置される。無線ＬＡＮカードなどの無線通信機能を有するＩＰｖ６対応のノード１４は、自身が位置するスポット１０に設置されているＡＰ１２と無線通信を行なう。この無線通信に用いられる通信規格としては、ＩＥＥＥ８０２．１１ｂやＩＥＥＥ８０２．１１ａなどがある。
【００２８】
ＡＰ１２は、自身が設置されているスポット１０に位置するノード１４を、ＩＰｖ６ネットワーク４０へのアクセスサービスを提供するＩＳＰ２０に接続する。本実施形態では、ＬＡＮによりＰＰＰを使用しないでノード１４をＩＳＰ２０に収容するようにしている。したがって、ＩＳＰ２０およびノード１４間は、ＭＡＣフレームにより通信が行なわれる。
【００２９】
なお、本実施形態では、ＡＰ１２をＩＳＰ２０に接続するためのアクセス回線として、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）回線を想定している。このため、ＡＰ１２は、１０Ｂａｓｅ−ＴなどのＬＡＮケーブルでＡＤＳＬモデム１６と接続し、ＡＤＳＬモデム１６は、電話線（メタル線）を介して、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ　Ａｃｃｅｓｓ　Ｍｕｌｔｉｐｌｅｘｅｒ）３０と接続する。そして、ＤＳＬＡＭ３０は、１００Ｂａｓｅ−ＴＸなどのＬＡＮケーブルでＩＳＰ２０内のルータ２２と接続する。但し、ＡＰ１２をＩＳＰ２０に接続するためのアクセス回線は、ＡＤＳＬ回線に限られるものではなく、光ファイバなどを利用してもよい。
【００３０】
ＩＳＰ２０は、ＬＡＮによりＰＰＰを使用しないでノード１４を収容するルータ２２と、ＩＥＥＥ８０２．１Ｘ規格に従いノード１４のユーザを認証を行なうＲＡＤＩＵＳサーバ２４と、ルータ２２をＩＰｖ６ネットワーク４０に接続するＧＷ（ゲートウエイ）２６と、ルータ２２の保守情報を管理する管理装置２８とが、ＬＡＮ接続されて構成される。
【００３１】
以上のような構成において、ノード１４のユーザは、ＩＳＰ２０の運営事業者と契約を行う。そして、ＩＳＰ２０の運営事業者は、契約したユーザのユーザ名およびパスワードをＲＡＤＩＵＳサーバ２４に登録する。
【００３２】
さて、ノード１４のユーザがあるスポット１０を訪れ、自身のノード１４を用いてＩＰｖ６ネットワーク４０へのネットワーク接続を開始すると、ＩＥＥＥ８０２．１Ｘ規格に従った認証が開始される。先ず、ＡＰ１２は、ネットワーク接続を開始したノード１４に、ユーザ名およびパスワードを要求し入手する。そして、入手したユーザ名およびパスワードをＲＡＤＩＵＳサーバ２４に転送し、認証を依頼する。次に、ＡＰ１２は、ＲＡＤＩＵＳサーバ２４から認証結果を受け取ると、それが認証成功であるならば、このノード１４およびルータ２２間の通信を中継する。これにより、ノード１４は、ＡＰ１２、ルータ２２およびＧＷ２６を介してＩＰｖ６ネットワーク４０へのアクセスが可能となる。
【００３３】
なお、ここでは、無線通信によりノード１４およびＡＰ１２間の通信を行なうものとして説明しているが、当然のことながら、ノード１４およびＡＰ１２間をＬＡＮケーブルで接続して通信を行なうようにしてもよい。
【００３４】
図２は、ＡＰ１２の概略構成図である。
【００３５】
図示するように、ＡＰ１２は、ノード１４と無線通信を行なうための無線ＩＦ（インターフェース）部１２１と、ＡＤＳＬモデム１６よりのＬＡＮケーブルを接続するためのＬＡＮコネクタ１２２と、無線ＩＦ部１２１およびＬＡＮコネクタ１２２のそれぞれに対して設けられた、対応する無線ＩＦ部１２１あるいはＬＡＮコネクタ１２２と送受する信号の物理レイヤの処理を行うＰＨＹ（ｐｈｙｓｉｃａｌｌａｙｅｒ）処理部１２３と、ＰＨＹ処理部１２２毎に設けられた、ノード１４およびルータ２２間のＭＡＣフレームの送受を制御するための処理を行なうＭＡＣＦＷＤ部１２４と、ＩＥＥＥ８０２．１Ｘメッセージを制御するＰＲＯＣ部１２５と、を有する。各ＭＡＣＦＷＤ部１２４およびＰＲＯＣ部１２５は、バス１２６によりバス接続されている。
【００３６】
ＭＡＣＦＷＤ部１２４は、ＭＡＣアドレス毎に、このＭＡＣアドレスが付与された装置およびこの装置へＭＡＣフレームを中継するＭＡＣＦＷＤ部１２４の情報を登録するＭＡＣアドレステーブル１２７を有している。
【００３７】
図３に、ＭＡＣアドレステーブル１２７の登録内容例を示す。図示するように、ＭＡＣアドレステーブル１２７は、ＭＡＣアドレスを登録するためのフィールド１２７１と、このＭＡＣアドレスが付与された装置との接続ポートを示すポート番号を登録するためのフィールド１２７２と、この接続ポートに接続された装置の属性を示すポート属性を登録するためのフィールド１２７３と、このＭＡＣアドレスが付与された装置との通信に利用する暗号鍵を登録するためのフィールド１２７４と、このＭＡＣアドレスが付与された装置との通信に対するＩＥＥＥ８０２．１Ｘ規格による認証の要否および必要な場合はその状態を示す認証状態を登録するためのフィールド１２７５とを備えて１つのレコードが形成される。
【００３８】
例えば、ルータ２２に付与されたＭＡＣアドレスがフィールド１２７１に登録されているレコードは、フィールド１２７２にルータ２２との接続ポート番号が登録され、フィールド１２７３にポート属性「ルータ」が登録され、そして、フィールド１２７５に、ＩＥＥＥ８０２．１Ｘ規格による認証が不要であることを示す認証状態「認証不要」が登録される。なお、ルータ２２との通信に暗号化が不要であれば、フィールド１２７４に暗号鍵は登録されない。
【００３９】
また、ノード１４に付与されたＭＡＣアドレスがフィールド１２７１に登録されているレコードは、フィールド１２７２にこのノード１４との接続ポート番号が登録され、フィールド１２７３にポート属性「ノード」が登録され、そして、フィールド１２７５に、ＩＥＥＥ８０２．１Ｘ規格による認証を実行中であれば認証状態「認証中」が、また、認証が実行済みであれば認証状態「認証済」が登録される。そして、フィールド１２７５が「認証中」から「認証済」に変わると、フィールド１２７４に登録されている暗号鍵を用いて、このノード１４との通信が行なわれる。
【００４０】
さて、ＭＡＣＦＷＤ部１２４は、対応するＰＨＹ処理部１２３からＭＡＣフレームを受け取ると、このＭＡＣフレームの送信元ＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から検索する。そして、検出したレコード（注目レコードと呼ぶ）のフィールド１２７３に登録されているポート属性が「ノード」ならば、次の処理を行なう。
【００４１】
すなわち、注目レコードのフィールド１２７５に登録されている認証状態が「認証済」であるか否かを調べる。「認証済」の場合、フィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを復号化する。それから、フィールド１２７３にポート属性「ルータ」が登録されているレコードを特定し、このレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。注目レコードのフィールド１２７４に暗号鍵が登録されていないならば、復号処理を行なうことなく、このＭＡＣフレームを、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ送信する。一方、注目レコードのフィールド１２７５に登録されている認証状態が「認証中」である場合、このＭＡＣフレームの宛先ＭＡＣアドレスを調べ、それがＡＰ１２のＭＡＣアドレスもしくはポートアクセスエンティティである場合のみ、このＭＡＣフレームをＰＲＯＣ部１２５に転送する。それ以外は、このＭＡＣフレームを廃棄する。
【００４２】
また、ＭＡＣＦＷＤ部１２４は、注目レコードのフィールド１２７３に登録されているポート属性が「ルータ」ならば、次の処理を行なう。
【００４３】
すなわち、このＭＡＣフレームの宛先ＭＡＣアドレスを調べ、それがフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介して無線ＩＦ部１２１に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。
【００４４】
なお、注目レコードを検出できなかった場合、すなわち、ＭＡＣフレームの送信元ＭＡＣアドレスがフィールド１２７１に登録されているレコードが、ＭＡＣアドレステーブル１２７に存在しない場合は、新たなレコードを追加し、このレコードのフィールド１２７１に送信元ＭＡＣアドレスを、フィールド１２７２に受信ポート番号を、フィールド１２７３にポート属性「ノード」を、そして、フィールド１２７５に認証状態「認証中」を登録する。
【００４５】
また、ＭＡＣＦＷＤ部１２４は、バス１２６を介して他のＭＡＣＦＷＤ部１２４からＭＡＣフレームを受け取ると、このＭＡＣフレームの送信先ＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から検索する。そして、検出したレコードのフィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを暗号化してから、対応するＰＨＹ処理部１２３へ送信する。暗号鍵が登録されていないならば、暗号化処理を行なうことなく、このＭＡＣフレームを対応するＰＨＹ処理部１２３へ送信する。
【００４６】
ＰＲＯＣ部１２５は、ＩＥＥＥ８０２．１Ｘメッセージを制御して、ノード１４の認証を、ＩＳＰ２０に依頼する。そして、その状態（認証中か認証済か）に従ってＭＡＣＦＷＤ部１２４のＭＡＣアドレステーブル１２７を更新する。具体的には、認証対象のノード１４のＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から特定し、このレコードのフィールド１２７５に認証状態を登録・更新する。
【００４７】
また、ＰＲＯＣ部１２５は、ＩＥＥＥ８０２．１Ｘメッセージを送信する場合は、これを格納したＭＡＣフレームを作成し、その宛先ＭＡＣアドレスに対応するＭＡＣＦＷＤ部１２４に送信する。
【００４８】
図４は、ルータ２２の概略構成図である。
【００４９】
図示するように、ルータ２２は、ＤＳＬＡＭ３０よりのＬＡＮケーブルを接続するためのＬＡＮコネクタ２２１と、ＲＡＤＩＵＳサーバ２４やＧＷ２６や管理装置２８と接続するＬＡＮケーブルを接続するためのＬＡＮコネクタ２２２と、ＬＡＮコネクタ２２１、２２２のそれぞれに対して設けられた、対応するＬＡＮコネクタ２２１、２２２と送受する信号の物理レイヤの処理を行うＰＨＹ処理部２２３と、ＰＨＹ処理部２２３毎に設けられたＩＰｖ６の処理を行なうＩＰｖ６処理部２２４と、ＩＥＥＥ８０２．１Ｘメッセージを制御するＰＲＯＣ部２２５と、を有する。各ＩＰｖ６処理部２２４およびＰＲＯＣ部２２５は、バス２２６によりバス接続されている。
【００５０】
ＩＰｖ６処理部２２４は、ＩＰｖ６のルーティングを行なうためのルーティングテーブル２２７を有している。ルーティングテーブルには、プレフィックス毎に、そのプレフィックスにより特定されるネットワークに向かうための次ホップのＩＰアドレスと、次ホップのＩＰアドレスに対応するＭＡＣアドレスと、次ホップへの中継を行なうＩＰｖ６処理部２２４の識別情報とが、互いに対応付けられて登録されている。
【００５１】
さて、ＩＰｖ６処理部２２４は、対応するＰＨＹ処理部２２３からＭＡＣフレームを受信すると、このＭＡＣフレームからＩＰパケットを取り出す。そして、ルーティングテーブルを用いて、このＩＰパケットの最長適合プレフィックスに対応付けれれている次ホップのＩＰアドレスおよびＭＡＣアドレスと、ＩＰｖ６処理部２２４の識別情報とを特定する。それから、このＩＰパケットを格納した、次ホップのＭＡＣアドレスを宛先とするＭＡＣフレームを生成し、特定した識別情報を持つＩＰｖ６処理部２２４へ送出する。また、ＩＰｖ６処理部２２４は、バス２２６を介して、他のＩＰｖ６処理部２２４からＭＡＣフレームを受け取ると、これを対応するＰＨＹ処理部２２３へ送信する。
【００５２】
なお、ＩＰｖ６処理部２２４は、対応するＰＨＹ処理部２２３より受け取ったＭＡＣフレームに格納されているＩＰパケットが、ＲＡＤＩＵＳメッセージやＩＣＭＰメッセージ等のルータ２２宛のＩＰパケットである場合、これをＰＲＯＣ２２５に送信する。
【００５３】
ＰＲＯＣ部２２５は、ＩＥＥＥ８０２．１Ｘメッセージを制御して、ノード１４の認証を、ＲＡＤＩＵＳサーバ２４に依頼する。また、ＰＲＯＣ部２２５は、ユーザ管理テーブル２２８を有しており、これを用いて、ノード１４のユーザ毎にプレフィックスを管理する。
【００５４】
図５に、ユーザ管理テーブル２２８の登録内容例を示す。図示するように、ユーザ管理テーブル２２８は、ノード１４のＩＥＥＥ８０２．１Ｘ規格による認証の状態を登録するフィールド２２８１と、ノード１４のＭＡＣアドレスを登録するためのフィールド２２８２と、ノード１４に割り当てたプレフィックスを登録するためのフィールド２２８３と、このノード１４がルータ２２と暗号通信を行なう場合に使用する暗号鍵を登録するためのフィールド２２８４と、このノード１４のユーザ名を登録するフィールド２２８５と、を備えて１つのレコードが形成される。ここで、フィールド２２８１の認証状態が「認証中」である場合、そのレコードのフィールド２２８２に登録されているＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信してはならないことを示している。
【００５５】
管理装置２８は、上述したように、ルータ２２の保守情報を管理する。
【００５６】
図６は、管理装置２８の概略図である。
【００５７】
図示するように、管理装置２８は、ルータ２２などと通信を行なうためのネットワークＩＦ部２８１と、管理者より各種指示を受け付けたり、管理者に情報を表示したりするＧＵＩ部２８２と、ルータ２２の保守情報を管理する保守管理部２８３と、を有する。保守管理部２８３は、ＧＵＩ部２８２を制御して、ルータ２２より受け取ったＩＰアドレスの重複報告メッセージを表示したり、ネットワークＩＦ部２８１を介してルータ２２にアクセスし、管理者より指示された情報を入手して表示したりする。
【００５８】
管理装置２８は、例えば図７に示すような、ＣＰＵ８０１と、メモリ８０２と、ＨＤＤ等の外部記憶装置８０３と、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の可搬性を有する記憶媒体８０４から情報を読み出す読取装置８０５と、キーボードやマウスなどの入力装置８０６と、ＣＲＴやＬＣＤなどの表示装置８０７と、ルータ２２などと通信を行なうための通信装置８０８と、を備えた一般的なコンピュータシステムにおいて、ＣＰＵ８０１がメモリ８０２上にロードされた所定のプログラムを実行することにより実現することができる。この所定のプログラムは、読取装置８０５を介して記憶媒体８０４から、あるいは、通信装置８０８を介してインターネットなどの通信媒体から、メモリ８０２に直接ロードしてもよいし、あるいは、一旦、外部記憶装置８０９にダウンロードしてから、メモリ８０２にロードしてもよい。
【００５９】
なお、ノード１４、ＡＤＳＬモデム１６、ＤＳＬＡＭ３０、ＲＡＤＩＵＳサーバ２４およびＧＷ２６は、ＩＰｖ６対応の既存の装置を利用することができるので、その詳細な説明は省略している。
【００６０】
図８は、図１に示す本実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示したものである。
【００６１】
上述したように、ルータ２２、ＲＡＤＩＵＳサーバ２４および管理装置２８間は、ＬＡＮ接続されている。このため、実際には、図示していないＬ２ＳＷ（Ｌａｙｅｒ　２　ｓｗｉｔｃｈ）が、ルータ１０３、ＲＡＤＩＵＳサーバ２４および管理装置２８間の接続に用いられている。
【００６２】
図示するように、本実施形態では、各ノード１４は、それぞれ異なるリンクに収容される。すなわち、ルータ２２は、個々のノード１４に対して、異なるネットワークプレフィックスをルータ広告する。これにより、ノード１４間でＩＰｖ６アドレスが重複するのを防止する。なお、個々のノード１４にルータ広告されるネットワークプレフィックスのユニーク性は、ルータ２２が保証する。
【００６３】
さらに、本実施形態では、あるノード１４が送信したアドレス重複通知パケットが、他のノード１４に届かないようにしている。
【００６４】
具体的には、ノード１４およびＡＰ１２間の通信をノード１４毎に異なる暗号鍵で暗号化することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする方法（方法Ａとする）、および、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする、もしくは不正パケットとして無視するようにする方法（方法Ｂとする）のいずれかを採用している。
【００６５】
いずれの方法でも、ノード１４およびＲＡＤＩＵＳサーバ２４は、予めユーザ名に対応した認証鍵と暗号鍵との組を格納しており、認証鍵はＩＥＥＥ８０２．１Ｘの認証で用いられ、暗号鍵は認証成功後の暗号通信に用いられる。
【００６６】
先ず、方法Ａについて、図９を用いて説明する。
【００６７】
図９は、ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合、つまり方法Ａが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスは、それぞれｍ１、ｌ０およびｋ０としている。
【００６８】
ノード１４は、電源が投入されると、ネットワーク接続を開始する。先ず、インターフェースＩＤを、ＭＡＣアドレスをベースとして自動生成する（ＳＴ２００１）。上述したように、ＭＡＣアドレスからインタフェースＩＤを生成する方法は、ＲＦＣ２３７３”ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ”に規定されている。図１０に、ＭＡＣアドレスと、ＭＡＣアドレスをベースとして自動生成されるインタフェースＩＤとの関係を示す。
【００６９】
図示するように、インターフェースＩＤ９０２は、ＭＡＣアドレス９０１内の企業ＩＤ（図中ｃで示したビット列）と拡張ＩＤ（図中ｍで示したビット列）の間に、１６ビットのビット列「１１１１１１１１１１１１１１１０」を挿入し、ユニバーサル／ローカルビット（図中、ビット値が「０」となっているビット）を反転させることで生成する。なお、図中「ｇ」で示したビットは、個別／グループビットと呼ばれるビットである。リンクローカルアドレス９０３は、インタフェースＩＤ９０２の上位に、リンクローカルアドレス用の固定プレフィックス「ＦＥ８０：：」を付加したものである。
【００７０】
また、図１０において、要請ノードマルチキャストＩＰアドレス９０４は、インタフェースＩＤ９０２の下位３バイトに、「ＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４」を付加したものである。それに対応する要請ノードマルチキャストＭＡＣアドレス９０５は、要請ノードマルチキャストＩＰアドレス９０４の下位４バイトに、「０ｘ３３３３」を付加したものである。
【００７１】
また、図１０において、全ノードマルチキャストＩＰアドレス９０６は、「ＦＦ０２：：１」であり、それに対応する全ノードマルチキャストＭＡＣアドレス９０７は、全ノードマルチキャストＩＰアドレス９０７の下位４バイトに、「０ｘ３３３３」を付加したものである。全ノードマルチキャストＩＰアドレス９０６が宛先ＩＰアドレスであるＩＰｖ６パケットのＭＡＣフレームは、通常、全ノードマルチキャストＭＡＣアドレス９０７を宛先ＭＡＣアドレスに設定する。
【００７２】
ノード１４は、ＲＦＣ２２８４で規定されている、ＲＡＤＩＵＳサーバ２４がノード１４の認証を行うためのプロトコルであるＥＡＰ（ＰＰＰ　Ｅｘｔｅｎｓｉｂｌｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に従い、ＡＰ１２とＥＡＰメッセージ（ＥＡＰＯＬ−Ｓｔａｒｔ、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙ、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅ、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐ）の送受信を行なう。ここで、ＥＡＰメッセージは、ＩＥＥＥ８０２．１Ｘ規格で規定されているＥＡＰＯＬ（ＥＡＰ　ｏｖｅｒ　ＬＡＮ）パケットにより送受信される。
【００７３】
一方、ＡＰ１２は、ＥＡＰＯＬパケットによりノード１４と送受信するＥＡＰメッセージを、ＲＡＤＩＵＳパケット（ＲＡＤＩＵＳ　ＡＣＣＥＳＳ−Ｒｅｑ、−Ｃｈａｌｌｅｎｇｅ、−Ａｃｐｔ）によりＲＡＤＩＵＳサーバ２４と送受信する。ＡＰ１２は、このためのＩＰアドレスを有している。なお、ＲＡＤＩＵＳプロトコルは、ＲＦＣ２８６５〜２８６９に規定されている。
【００７４】
さて、ノード１４は、ＩＥＥＥ８０２．１Ｘ規格の認証開始を要求するＥＡＰＯＬ−Ｓｔａｒｔメッセージを、ポートアクセスエンティティを意味するＭＡＣアドレス宛に送信する（ＳＴ２００２）。これにより、ＥＡＰＯＬ−Ｓｔａｒｔメッセージがノード１４からＡＰ１２へ送信される。
【００７５】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰＯＬ−Ｓｔａｒｔメッセージを受け取ると、ＭＡＣアドレステーブル１２７にレコードを追加し、このレコードのフィールド１２７１に、ＥＡＰＯＬ−Ｓｔａｒｔメッセージを送信したノード１４のＭＡＣアドレスを、フィールド１２７２に、このノード１４との接続ポートのポート番号を、そして、フィールド１２７５に、認証状態「認証中」を登録する（ＳＴ２００３）。
【００７６】
また、ＰＲＯＣ部１２５は、ユーザ名を要求するＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを作成し、これを無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からＥＡＰＯＬ−Ｓｔａｒｔメッセージを送信したノード１４へ送信する（ＳＴ２００４）。
【００７７】
ノード１４は、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを受信すると、予め登録された、あるいは、ユーザより入力されたユーザ名を含んだＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを生成し、ＡＰ１２に送信する（ＳＴ２００５）。
【００７８】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを作成し、このメッセージのＣａｌｌｉｎｇ−Ｓｔａｔｉｏｎ−Ｉｄアトリビュートにノード１４のＭＡＣアドレスを格納すると共に、ＥＡＰ−ＭｅｓｓａｇｅアトリビュートにこのＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを格納する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、ＬＡＮコネクタ１２２からルータ２２へ送信する（ＳＴ２００６）。
【００７９】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＡＰ１２よりＲＡＤＩＵＳＡｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ユーザ管理テーブル２２８にレコードを追加し、このレコードのフィールド２２８１に、認証状態「認証中」を、フィールド２２８２に、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを送信したノード１４のＭＡＣアドレスを、そして、フィールド２２８５に、ノード１４のユーザのユーザ名を登録する（ＳＴ２００７）。
【００８０】
また、ＰＲＯＣ部２２５は、ＡＰ１２より受け取ったＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２からＲＡＤＩＵＳサーバ２４へ送信する（ＳＴ２００８）。これにより、ノード１４のユーザ名とＭＡＣアドレスとを、ＲＡＤＩＵＳサーバ２４に通知する。
【００８１】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを生成すると共に、認証乱数を生成し、これをＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＣｈａｌｌｅｎｇｅメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュート内のＥＡＰメッセージに設定する。それから、このＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを、ルータ２２を介して、ＡＰ１２に送信する（ＳＴ２００９）。
【００８２】
ＡＰ１２において、ＰＲＯＣ部１２５は、ＬＡＮコネクタ１２２側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを受け取ると、このメッセージに含まれている認証乱数を含んだ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを作成する。そして、このメッセージを、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からノード１４へ送信する（ＳＴ２０１０）。
【００８３】
ノード１４は、ＡＰ１２よりＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを受信すると、このメッセージに含まれている認証乱数と、予め保持している認証鍵とを用いて認証演算を行う。そして、その結果を、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含めてＡＰ１２に送信する（ＳＴ２０１１）。
【００８４】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを受信すると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを生成し、このメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、受信したＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを設定する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、ＬＡＮコネクタ１２２から、ルータ２２経由で、ＲＡＤＩＵＳサーバ２４に送信する（ＳＴ２０１２）。
【００８５】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受信すると、これに設定されているＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含まれている認証結果を用いて、ノード１４のユーザの認証を行う。具体的には、このノード１４のユーザ名に対応付けて予め登録されている認証鍵を用いて、ＳＴ２００９で生成した認証乱数に対し認証演算を行う。その結果がノード１４から受信したものと一致するか判定する（ＳＴ２０１３）。
【００８６】
一致した場合は認証成功となる。この場合、ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを生成し、これに、ノード１４に割り当てるプレフィックスと、ＡＰ１２が無線区間の暗号通信に利用する暗号鍵とを含めて、ルータ３３に通知する（ＳＴ２０１４）。ここで、プレフィックスは、ノード１４毎に異なる値とされ、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＡｃｐｔメッセージのＦｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘアトリビュートに設定される。また、暗号鍵は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージの例えばＣａｌｌｂａｃｋ−Ｉｄアトリビュートに設定される。
【００８７】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれているプレフィックスを、ＳＴ２００７でユーザ管理テーブル２２８に追加したレコードのフィールド２２８３に登録する。また、フィールド２２８１に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２０１５）。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信できるように、各部を制御する。
【００８８】
また、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から、ＡＰ１２に送信する（ＳＴ２０１６）。
【００８９】
ＡＰ１２において、ＰＲＯＣ部１２５は、ＬＡＮコネクタ１２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ルータ２２よりＲＡＤＩＵＳＡｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれている暗号鍵を、ＳＴ２００３でＭＡＣアドレステーブル１２７に追加したレコードのフィールド１２７４に登録する。また、フィールド１２７５に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２０１７）。これにより、ＰＲＯＣ部１２５は、このノード１４とルータ２２との間で送受されるＭＡＣフレームがブリッジされるように、各部を制御する。
【００９０】
また、ＰＲＯＣ部１２５は、登録した暗号鍵を含んだＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを生成し、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からノード１４に送信し、ノード１４に、認証が成功したことを通知する（ＳＴ２０１８）。
【００９１】
ノード１４は、ＡＰ１２よりＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを受け取ると、これに含まれている暗号鍵を登録する（ＳＴ２０１９）。
【００９２】
以上により、ＩＥＥＥ８０２．１規格に従った認証が終了する。以降、ノード１４およびＡＰ１２は、この暗号鍵を用いてＭＡＣフレームの暗号通信を行なう。
【００９３】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージに含まれていたプレフィックスを、このプレフィックスが割り当てられるノード１４に通知するため、ルータ広告であるＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これを、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から、ＡＰ１２経由でノード１４に送信する（ＳＴ２０２０）。
【００９４】
ここで、図１１に、本実施形態で用いるＩＰｖ６パケットを格納したＭＡＣフレームのフォーマット構成例を示す。
【００９５】
図示するように、本実施形態で用いるＭＡＣフレーム９２０は、宛先ＭＡＣアドレス９２１と、送信元ＭＡＣアドレス９２２と、格納データのタイプ９２３と、格納データ９２４と、ＣＲＣ（Ｃｙｃｌｉｃ　Ｒｅｄｕｎｄａｎｃｙ　Ｃｈｅｃｋｉｎｇ）９２５と、を含んでいる。タイプ９２３が「０ｘ８６ＤＤ」の場合、格納データ９２４がＩＰｖ６パケットであることを示している。
【００９６】
ＩＰｖ６パケット９３０は、ＩＰヘッダと、ＩＰペイロード９３４とを含んでいる。ＩＰヘッダには、送信元ＩＰアドレス９３１および宛先ＩＰアドレス９３２が含まれる。さらに、ＩＰヘッダには、拡張ヘッダとしてＩＰパケットの認証情報を設定するための認証ヘッダやＩＰペイロード７９３４を暗号化する場合に必要な暗号ペイロードヘッダ９３３を含めることができる。ＩＰペイロード９３４には、ＩＣＭＰパケットを設定することができる。
【００９７】
Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージ９４０は、ＩＣＭＰタイプ９４１が「１３４」のＩＣＭＰパケットである。送信元リンクレイヤオプション９４２に送信元ルータのＭＡＣアドレスが登録され、プレフィックス情報オプション９４３にリンク（サブネット）のプレフィックスが登録される。
【００９８】
図９のＳＴ２０２０において、ルータ２２がＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを送信する場合、この時点ではノード１４のＩＰアドレスが未だ確定していないため、ＩＰヘッダの宛先ＩＰアドレス９３２には全ノードマルチキャストＩＰアドレスを設定する必要がある。しかし、本実施形態では、各ノード１４をそれぞれ異なるリンクに収容するようにしている。このため、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージで送信するプレフィックスは、このプレフィックスが割り当てられるノード１４以外に受信されないようにする必要がある。
【００９９】
そこで、ルータ２２において、ＰＲＯＣ部２２５は、このＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを含むＭＡＣフレームの宛先ＭＡＣアドレス９２１に、ユーザ管理テーブル２２８にてＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージのプレフィックスがフィールド２２８３に登録されているレコードの、フィールド２２８２に登録されているＭＡＣアドレスを設定する。図９に示す例では、ノード１４のＭＡＣアドレス「ｍ１」が設定される。
【０１００】
ＡＰ１２において、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４は、ＬＡＮコネクタ１２２およびＰＨＹ処理部１２３を介して、ルータ２２より、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを格納したＭＡＣフレームを受信すると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの宛先ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介して無線ＩＦ部１２１に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。
【０１０１】
これを受けて、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、バス１２６を介してＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４からＭＡＣフレームを受け取ると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの宛先ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７５に登録されている認証状態が「認証済」であることを確認した後、このレコードのフィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを暗号化してから、対応するＰＨＹ処理部１２３へ送信する。これにより、格納データが暗号化されたＭＡＣフレームが、ＡＰ１２からＭＡＣアドレス「ｍ１」を持つノード１４へ送信される。
【０１０２】
ノード１４は、宛先ＭＡＣアドレスが自身のＭＡＣフレームを受信すると、ＳＴ２０１９で登録した暗号鍵を用いて格納データを復号化し、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを得る。そして、このメッセージに含まれている自身専用のプレフィックスを入手する。また、このメッセージの送信元ＩＰアドレスおよび送信元ＭＡＣアドレスを、デフォルトルータとして認識する（ＳＴ２０２１）。
【０１０３】
さて、ノード１４は、ＩＥＥＥ８０２．１規格に従った認証が終了した後、ＳＴ２００１で生成したインターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するために、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信して、アドレス重複問合せを行う（ＳＴ２０２２）。
【０１０４】
図１１に示すように、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０は、ＩＣＭＰタイプ９５１が「１３５」のＩＣＭＰパケットである。対象ＩＰアドレス９５２は、インターフェースＩＤ「Ｍ１」から生成したリンクローカルアドレス（図１０参照）が設定される。送信元リンクレイヤアドレスオプション９５３は含まれない。
【０１０５】
また、図１１に示すように、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０を格納するＩＰｖ６パケット９３０の送信元ＩＰアドレス９３１には、アドレス重複問合わせであることを示す「０」が設定され、宛先ＩＰアドレス９３２には、インターフェースＩＤ「Ｍ１」から生成される要請ノードマルチキャストＩＰアドレス（図１０参照）が設定される。
【０１０６】
また、図１１に示すように、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０を格納するＩＰｖ６パケット９３０を格納するＭＡＣフレーム９２０の宛先ＭＡＣアドレス９２１は、インタフェースＩＤ「Ｍ１」に対応する要請ノードマルチキャストＭＡＣアドレス（図１０参照）が設定され、送信元ＭＡＣアドレス９２２はノード１４のＭＡＣアドレスである「ｍ１」が設定される。
【０１０７】
ノード１４は、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを、その格納データを暗号鍵で暗号化して送信する。
【０１０８】
ＡＰ１２において、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、無線ＩＦ部１２１およびＰＨＹ処理部１２３を介して、ノード１４より、ＮｅｇｈｂｏｒＳｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを受信すると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの送信元ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７５に登録されている認証状態が「認証済」であることを確認した後、このレコードのフィールド１２７４に登録されている暗号鍵を用いて、このＭＡＣフレームの格納データを復号化する（ＳＴ２０２３）。
【０１０９】
次に、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、このＭＡＣアドレステーブル１２７から、フィールド１２７３にポート属性「ルータ」が登録されているレコードを特定し、このレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。これにより、このＭＡＣフレームは、ルータ２２へ送信される（ＳＴ２０２４）。
【０１１０】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信すると、このメッセージの対象ＩＰアドレス９５２（図１１参照）が自身のＩＰアドレスと一致しているか否かを調べる。そして、一致していなければ、このメッセージを無視する（ＳＴ２０２５）。
【０１１１】
ノード１４は、アドレス重複問合せの応答であるＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを一定時間内に受信しなかった場合、自身のインタフェースＩＤがユニークであると判断し、このインターフェースＩＤと、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅメッセージにより受信したプレフィックスとを用いて、リンクローカルアドレスおよびグローバル（あるいはサイトローカル）アドレスを生成し、自身のＩＰｖ６インタフェースに割り当てる（ＳＴ２０２６）。
【０１１２】
なお、他のノード１４が送信したＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、アドレス管理テーブル１２７にてＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージの送信元ＭＡＣアドレスに対応するポート属性が「ノード」であるため、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージと同様、ポート属性が「ルータ」となっているポート番号のポート、つまり、ルータ２２にしか送出されない。このため、そのメッセージがノード１４のアドレス自動設定を妨害することはない。
【０１１３】
次に、方法Ｂについて、図１２を用いて説明する。
【０１１４】
図１２は、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加する場合、つまり方法Ｂが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスは、図９に示す方法Ａの場合と同様に、それぞれｍ１、ｌ０およびｋ０としている。なお、方法Ｂでは、ＡＰ１２に、ＩＥＥＥ８０２．１Ｘ認証のサポート機能を持たせる必要がない。
【０１１５】
先ず、ノード１４は、ＭＡＣアドレスをベースとして、インターフェースＩＤを自動生成し（ＳＴ２１０１）。その後、インターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するために、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信して、アドレス重複問合せを行う（ＳＴ２１０２）。ここで、ノード１４は、他のノード１４がＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信しないようにするために、送信ＩＰパケットに対して暗号鍵による暗号化もしくは認証を行うようにしている。また、他のノード１４からの、自身が送信したアドレス重複問合せに対するアドレス重複通知であるＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信しないようにするために、受信ＩＰパケットに対して暗号鍵による復号化もしくは認証を行うようにしている。
【０１１６】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＬＡＮコネクタ２２１からＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを受け取ると、このＭＡＣフレームの送信元ＭＡＣアドレスがユーザ管理テーブ２２８に登録されているか否かを調べる。そして、未だ登録されていないこと、つまり、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４が認証されていないことを確認する（ＳＴ２１０３）。それから、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを生成し、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＬＡＮコネクタ２２１からＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４へ送信する（ＳＴ２１０４）。
【０１１７】
ノード１４は、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、これがＩＰｖ６パケットではなくＥＡＰＯＬパケットであることを認識し、したがって、暗号鍵による認証／復号を行なわずに処理する。そして、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを生成し、これに自身のユーザ名を設定してルータ２２に送信する（ＳＴ２１０５）。
【０１１８】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、ユーザ管理テーブル２２８にレコードを追加し、このレコードのフィールド２２８１に認証状態「認証中」を、フィールド２２８２にＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージの送信元ＭＡＣアドレス「ｍ１」を、そして、フィールド２２８５に、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージに設定されているユーザ名を登録する（ＳＴ２１０６）。
【０１１９】
それから、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを作成し、このメッセージのＣａｌｌｉｎｇ−Ｓｔａｔｉｏｎ−Ｉｄアトリビュートに、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージの送信元ＭＡＣアドレス「ｍ１」を、ＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、このＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを格納する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２からＲＡＤＩＵＳサーバ２４へ送信する（ＳＴ２１０７）。これにより、ノード１４のユーザ名とＭＡＣアドレスとを、ＲＡＤＩＵＳサーバ２４に通知する。
【０１２０】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを生成すると共に、認証乱数を生成し、これをＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＣｈａｌｌｅｎｇｅメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュート内のＥＡＰメッセージに設定する。それから、このＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを、ルータ２２に送信する（ＳＴ２１０８）。
【０１２１】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを受け取ると、このメッセージに含まれている認証乱数を含んだ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを作成する。そして、このメッセージを、ＬＡＮコネクタ２２１側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４へ送信する（ＳＴ２１０９）。
【０１２２】
ノード１４は、ルータ２２よりＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを受信すると、このメッセージに含まれている認証乱数と、予め保持している認証鍵とを用いて認証演算を行う。そして、その結果を、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含めてルータ２２に送信する（ＳＴ２１１０）。
【０１２３】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを受信すると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを生成し、このメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、受信したＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを設定する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から、ＲＡＤＩＵＳサーバ２４に送信する（ＳＴ２１１１）。
【０１２４】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受信すると、これに設定されているＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含まれている認証結果を用いて、ノード１４のユーザの認証を行う。具体的には、このノード１４のユーザ名に対応付けて予め登録されている認証鍵を用いて、ＳＴ２１０８で生成した認証乱数に対し認証演算を行う。その結果がノード１４から受信したものと一致するか判定する（ＳＴ２１１２）。
【０１２５】
一致した場合は認証成功となる。この場合、ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを生成し、これに、ノード１４に割り当てるプレフィックスと、ノード１４およびルータ２２間の暗号通信に利用する暗号鍵とを含めて、ルータ２２に通知する（ＳＴ２１１３）。ここで、プレフィックスは、ノード１４毎に異なる値とされ、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＡｃｐｔメッセージのＦｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘアトリビュートに設定される。また、暗号鍵は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージの例えばＣａｌｌｂａｃｋ−Ｉｄアトリビュートに設定される。
【０１２６】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれているプレフィックスおよび暗号鍵を、ＳＴ２１０６でユーザ管理テーブル２２８に追加したレコードのフィールド２２８３およびフィールド２２８４にそれぞれ登録する。また、フィールド２２８１に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２１１４）。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを暗号通信により送受信できるように、各部を制御する。
【０１２７】
また、ＰＲＯＣ部２２５は、登録した暗号鍵を含んだＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを生成し、ＬＡＮコネクタ２２１側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４に送信し、ノード１４に、認証が成功したことを通知する（ＳＴ２１１５）。
【０１２８】
ノード１４は、ルータ２２よりＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを受け取ると、これに含まれている暗号鍵を登録する（ＳＴ２１１６）。
【０１２９】
以上によりＩＥＥＥ８０２．１規格に従った認証が終了する。以降、ノード１４およびルータ２２は、この暗号鍵と、ＩＰｖ６パケットの認証ヘッダ／暗号ペイロードヘッダ９３３とを用いて、ＩＰｖ６パケットの認証付通信あるいは暗号通信を行なうことが可能となる。
【０１３０】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージに含まれていたプレフィックスを、このプレフィックスが割り当てられるノード１４に通知するため、ルータ広告であるＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これを、宛先ＭＡＣアドレス「ｍ１」、宛先ＩＰアドレス「全ノードマルチキャストＩＰアドレス」として、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４に送信する（ＳＴ２１１７）。
【０１３１】
ノード１４は、宛先ＭＡＣアドレスが自身のＭＡＣフレームを受信すると、このフレームからＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを得る。そして、このメッセージに含まれている自身専用のプレフィックスを入手する。また、このメッセージの送信元ＩＰアドレスおよび送信元ＭＡＣアドレスを、デフォルトルータとして認識する（ＳＴ２１１８）。
【０１３２】
さて、ノード１４は、ＩＥＥＥ８０２．１規格に従った認証が終了した後、ＳＴ２００１で生成したインターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するためのＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを生成し送信して、アドレス重複問合せを行う（ＳＴ２１１９）。
【０１３３】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信すると、このメッセージを格納したＭＡＣフレームの送信元ＭＡＣアドレスがユーザ管理テーブ２２８に登録されているか否かを調べる。そして、既に登録されていないこと、つまり、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４が認証されていることを確認する（ＳＴ２１２０）。それから、このメッセージの対象ＩＰアドレス９５２（図１１参照）が自身のＩＰアドレスと一致しているか否かを調べる。そして、一致していなければ、このメッセージを無視する（ＳＴ２１２１）。
【０１３４】
ノード１４は、アドレス重複問合せの応答であるＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを一定時間内に受信しなかった場合、自身のインタフェースＩＤがユニークであると判断し、このインターフェースＩＤと、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅメッセージにより受信したプレフィックスとを用いて、リンクローカルアドレスおよびグローバル（あるいはサイトローカル）アドレスを生成し、自身のＩＰｖ６インタフェースに割り当てる（ＳＴ２１２２）。
【０１３５】
なお、以上説明した方法Ａおよび方法Ｂのいずれの方法においても、ＡＰ１２が有線でノード１４と接続するＬ２ＳＷである場合は、ノード１４間の通信をＬ２ＳＷで禁止するようにしてもよい。この場合、ノード１４が送信するフレームを他のノード１４が傍受することはできない。したがって、ノード１４−Ｌ２ＳＷ間（方法Ａ）、あるいは、ノード１４−ルータ２２（方法Ｂ）間の通信を暗号化する必要がなくなる。
【０１３６】
以上、本発明の第１実施形態について説明した。
【０１３７】
本実施形態では、ノード１４の各々に異なるグローバル（サイトローカル）アドレス用プレフィックスを付与することにより、各リンクローカル内に１つのノードが属するようにしている。このため、本来はＩＰアドレスおよびＭＡＣアドレスの双方が共にマルチキャストであるルータ広告を、特定のノード１４に対して、そのノード１４のＩＰアドレスが不明でも送達できる。これにより、そのノード１４に、当該ノード専用のプレフィックスを割当てることができる。そして、各ノード１４に専用のプレフィックスを割当てれば、ノード間でのインタフェースＩＤの重複は発生しない。したがって、本実施形態によれば、各ノード１４のＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。
【０１３８】
また、本実施形態では、ノード１４毎に、固有の暗号鍵を用いて、ノード１４およびＡＰ１２あるいはルータ２２間の通信を行なうようにしている。このようにすることで、ノード１４がルータ２２以外の他ノード１４と直接通信できないようにすることができ、したがって、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【０１３９】
次に、本発明の第２実施形態について説明する。
【０１４０】
図１３は、本発明の第２実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示したものである。
【０１４１】
図示するように、本実施形態では、図８に示す第１実施形態と異なり、ＡＰ１２配下の全てのノード１４を１つのリンク（サブネット）５０に収容するようにしている。なお、本実施形態の公衆無線ＬＡＮアクセスサービスシステムは、図１に示す第１実施形態のものと基本的に同様である。ただし、図１４に示すように、本実施形態のルータ２２では、ＰＲＯＣ部２２５に、ユーザ管理テーブル２２８に代えてＩＰアドレス管理テーブル２２９が保持される。
【０１４２】
図１５に、ＩＰアドレス管理テーブル２２９の登録内容例を示す。図示するように、ＩＰアドレス管理テーブル２２９は、ノード１４のＩＥＥＥ８０２．１Ｘ規格による認証の状態を登録するフィールド２２９１と、ノード１４のＭＡＣアドレスを登録するためのフィールド２２９２と、ノード１４がルータ２２と暗号通信を行なう場合に使用する暗号鍵を登録するためのフィールド２２９４と、このノード１４のユーザ名を登録するフィールド２２９５と、複数のＩＰアドレスを管理するための使用中ＩＰアドレステーブル２２９７に登録されている、使用中ＩＰアドレスへのポインタを登録するためのフィールド２２９６と、を備えて１つのレコードが登録されている。
【０１４３】
本実施形態では、ＡＰ１２配下の全てのノード１４が同じリンクに属するため、ルータ２２が全ての使用中ＩＰアドレスを監視して、ユニーク性を保証する必要がある。使用中ＩＰアドレステーブル２２９７は、ノード１４のアドレス自動設定完了後、ＩＰ通信を開始する際のＩＰアドレス解決時に、ＮｅｉｇｈｂｏｒＣａｃｈｅと共に更新される。
【０１４４】
Ｎｅｉｇｈｂｏｒ　Ｃａｃｈｅは、ＩＰアドレスとＭＡＣアドレスとの対応リストであり、その更新方法はＲＦＣ２４６１に記載されている。ただし、ＲＦＣ２４６１では、Ｎｅｉｇｈｏｒ　Ｃａｃｈｅに対し、登録済みのＩＰアドレスに対応するＭＡＣアドレスの上書きは可能であるとしている。しかし、本実施形態では、この上書きを禁止とし、タイムアウトによるエントリ削除あるいは後述の不正ＩＰアドレス使用禁止のためのエントリ強制削除によってのみ、ＭＡＣアドレスの変更ができるようにしている。
【０１４５】
本実施形態においても、上記の第１実施形態と同様に、ノード１４が送信するＩＰｖ６パケットが他のノード１４に届かないようにする方法として、ノード１４およびＡＰ１２間の通信をノード１４毎に異なる暗号鍵で暗号化することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする方法（方法Ａ）、および、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする、もしくは不正パケットとして無視するようにする方法（方法Ｂ）のいずれかを採用している。
【０１４６】
ここでは、方法Ａを例に取り説明する。
【０１４７】
図１６は、ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合、つまり方法Ａが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ここでも、図９の場合と同様に、ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスを、それぞれｍ１、ｌ０およびｋ０としている。
【０１４８】
図１６において、ＳＴ２２０１〜ＳＴ２２１９は、図９のＳＴ２００１〜ＳＴ２０１９と基本的に同様である。
【０１４９】
ただし、本実施形態では、上述したように、ルータ２２にユーザ管理テーブル２２８に代えてＩＰアドレス管理テーブル２２９を設けている。したがって、ＳＴ２２０７において、ＩＰアドレス管理テーブル２２９に新たなレコードが追加され、このレコードのフィールド２２９１に認証状態「認証中」が、フィールド２２９２にノード１４のＭＡＣアドレスが、そして、フィールド２２９５にノード１４のユーザのユーザ名が登録される。
【０１５０】
また、本実施形態では、上述したように、ＡＰ１２配下の全ノード１４に対して同じプレフィックスを割り当てている。つまり、ノード１４毎に異なるプレフィックスを割当てることはしない。このため、ＳＴ２２１４において、ＲＡＤＩＵＳサーバ２４によるプレフィックスの割当て通知は行わない。その代わり、ルータ２２に、ＡＰ１２毎に、ＡＰ１２配下のノード１４に割り当てるプレフィックスを管理させるようにする。また、ＳＴ２２１５において、フレフィックスの登録は行なわない。ＳＴ２２０７でＩＰアドレス管理テーブル２２９に追加したレコードのフィールド２２９１に登録されている認証状態を「認証中」から「認証済」に変更する。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信できるように、各部を制御する。
【０１５１】
次に、図１６において、ＳＴ２２２０〜ＳＴ２２２４も、図９のＳＴ２０２０〜ＳＴ２０２４と基本的に同様である。ただし、本実施形態では、上述したように、ＡＰ１２配下の全ノード１４に対して同じプレフィックスを割り当てている。このため、ＳＴ２２２０において、ルータ２２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＭＡＣアドレスを、全ノードマルチキャストＭＡＣアドレスとしている。これにより、ＡＰ１２配下の全てのノード１４に同一のプレフィックスを通知する。
【０１５２】
なお、ＳＴ２２２０において、ＡＰ１２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージをノード１４へ送信する場合、これを各ノード１４に固有の暗号鍵で暗号化することはしない。暗号化を行なわないか、あるいは、ＡＰ１２配下の全ノード１４に共通の暗号鍵（マルチキャスト用暗号鍵）で暗号化する。
【０１５３】
一方、ＳＴ２２２２において、ノード１４は、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信する場合、図９のＳＴ２０２２と同様に、ノード１４に固有の暗号鍵で暗号化する。
【０１５４】
さて、第１実施形態では、ノード１４毎に異なるプレフィックスを割り当てているため、ノード１４のＩＰアドレスがルータ２２のＩＰアドレスと重複していないことを確認すればよい。このため、図９のＳＴ２０２５に示すように、ルータ２２は、ノード１４がアドレス重複問合せのために送信したＮｅｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージのうち、対象ＩＰアドレスが自身のＩＰアドレスでないものを無視していた。これに対し、本実施形態では、ノード１４がアドレス重複問合せのために送信した全てのＮｅｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを考慮し、ルータ２２が、同一リンク内でのアドレス重複を判定するようにしている。
【０１５５】
図１７は、ノード１４が送信したアドレス重複問合せのためのＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを、ルータ２２が受信した以降の動作手順、つまり図１６の続きを説明するためのシーケンス図である。
【０１５６】
図１７（ａ）において、ルータ２２のＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して受信したＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元アドレスにアドレス重複問合わせであることを示す「０」が設定されていることを確認する（ＳＴ２２５１）。それから、このメッセージの送信元ＭＡＣアドレスと、このメッセージに格納されている対象ＩＰアドレスとの関係が、図１０に示すＭＡＣアドレス９０１とリンクローカルアドレス９０３との関係になっているか否かを調べる（ＳＴ２２５２）。そのような関係になっている場合、このメッセージに格納されている対象ＩＰアドレスは、ＭＡＣアドレスから自動生成したアドレスである。この場合、このアドレスを正当なアドレスと判定する。ノード１４に対して、何も応答を返さない。その結果、ノード１４は、対象ＩＰアドレスに設定したアドレスをリンクローカルアドレスに正式採用する。これにより、アドレス自動設定を成功させる（ＳＴ２２５６）。
【０１５７】
なお、既にこのＩＰアドレスを使用している他のユーザ（ノード）が存在する場合、そのユーザにこのＩＰアドレスの使用を禁止させる必要がある。そこで、ＰＲＯＣ部２２５は、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードを検索する（ＳＴ２２５３）。そのようなレコードが検出されなかった場合、このＩＰアドレスを使用している他のユーザは存在しないことになるので、処理を終了する。一方、そのようなレコードが検出された場合、ＩＰアドレス管理テーブル２２９から検出したレコードを削除すると共に、Ｎｅｉｇｈｂｏｒ　Ｃａｃｈｅから、検出したレコードのフィールド２２９２に登録されているＭＡＣアドレスとこのＩＰアドレスとの対応関係を削除する（ＳＴ２２５４）。また、削除したレコードの情報を含む重複報告メッセージを作成し、これをＬＡＮコネクタ２２２側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から管理装置２８に送信する（ＳＴ２２５５）。
【０１５８】
一方、ＳＴ２２５２において、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスと、このメッセージに格納されている対象ＩＰアドレスとの関係が、図１０に示すＭＡＣアドレス９０１とリンクローカルアドレス９０３との関係になっていない場合、このメッセージに格納されている対象ＩＰアドレスは、ＭＡＣアドレスから自動生成したアドレスではない。この場合、このアドレスを、使用中のユーザ（ノード）が存在しない場合に限って認める正当でないアドレスと判定し、図１７（ｂ）のＳＴ２２６１に進む。
【０１５９】
図１７（ｂ）のＳＴ２２６１において、ルータ２２のＰＲＯＣ部２２５は、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、ＮｅｉｇｈｂｏｒＳｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードを検索する。そのようなレコードが検出された場合、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスを宛先ＭＡＣアドレスに設定したＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これをＬＡＮコネクタ２２１側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から送信する（ＳＴ２２６２）。
【０１６０】
図１１に示すように、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、ＩＣＭＰタイプ９６１が「１３６」のＩＣＭＰパケット９６０である。対象ＩＰアドレス９６２と、この対象ＩＰアドレスを使用中のノード１４のＭＡＣアドレスが設定された対象リンクレイヤアドレスオプション９６３と、を含む。なお、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＩＰアドレスは、全ノードマルチキャストＩＰアドレスである。しかし、宛先ＭＡＣアドレスにＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスが設定されているため、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信したノード１４に送信される。ノード１４は、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信すると、アドレス自動設定を失敗とする（ＳＴ２２６４）。
【０１６１】
また、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに含まれていた情報を含む重複報告メッセージを作成し、これをＬＡＮコネクタ２２２側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から管理装置２８に送信する（ＳＴ２２６３）。
【０１６２】
一方、ＳＴ２２６１において、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードが検出されなかった場合、このＩＰアドレスを使用している他のユーザは存在しないことになる。この場合、このＩＰアドレスの使用を許可するべく、図１７（ｃ）のＳＴ２２７１に進む。
【０１６３】
図１７（ｃ）のＳＴ２２７１において、ルータ２２のＰＲＯＣ部２２５は、使用を許可するＩＰアドレスを対象ＩＰアドレスとし、送信元ＩＰアドレスをルータ２２のＩＰアドレスとしたＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを生成する。そして、これをＬＡＮコネクタ２２１側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から送信する。このＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージは、送信元ＩＰアドレスが「０」でないので、アドレス解決問合せを意味する。このため、アドレス自動設定中のノード（ＭＡＣアドレス「ｍ１」）がこのメッセージを受信しても、ＲＦＣ２４６に従い、このメッセージを無視する（ＳＴ２２７２）。
【０１６４】
ここで、ＭＡＣアドレス「ｍ２」のノード１４がＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに設定されている対象ＩＰアドレスを使用中であると仮定する。このノード１４は、Ｎｅｇｈｂｏｒ　Ａｄｅｖｒｔｉｓｅメッセージをルータ２２に送信する（ＳＴ２２７３）。これを受けて、ルータ２２は、図１７（ｂ）のＳＴ２２６１で対象ＩＰアドレスがＩＰアドレス管理テーブル２２９に登録済みの場合と同様の処理を行う。
【０１６５】
なお、ＳＴ２２７１で送信したＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに対する応答として、ルータ２２配下のノード１４からＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信していない場合、ルータ２２は、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信したノード１４に対して、何も応答を返さない。その結果、このノード１４は、対象ＩＰアドレスに設定したアドレスをリンクローカルアドレスに正式採用する。これによりアドレス自動設定を成功させる。
【０１６６】
以上、方法Ａを例に取り説明したが、方法Ｂを本実施形態に適用する場合も、第１実施形態（図９）および第２実施形態（図１６、図１７）間における方法Ａの変更内容を、図１２に示す方法Ｂを用いた第１実施形態に適用することで実現できる。つまり、図１２に以下の変更点を加えればよい。
【０１６７】
（１）ＳＴ２１０６において、ＩＰアドレス管理テーブル２２９に新たなレコードが追加され、このレコードのフィールド２２９１に認証状態「認証中」が、フィールド２２９２にノード１４のＭＡＣアドレスが、そして、フィールド２２９５にノード１４のユーザのユーザ名が登録される。
【０１６８】
（２）ＳＴ２１１３において、ＲＡＤＩＵＳサーバ２４によるプレフィックスの割当て通知は行わなない。その代わり、ルータ２２に、ＡＰ１２毎に、ＡＰ１２配下のノード１４に割り当てるプレフィックスを管理させる。
【０１６９】
（３）ＳＴ２１１４において、フレフィックスの登録は行なわない。ＳＴ２１０６でＩＰアドレス管理テーブル２２９に追加したレコードのフィールド２２９１に登録されている認証状態を「認証中」から「認証済」に変更する。
【０１７０】
（４）ＳＴ２１１７において、ルータ２２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＭＡＣアドレスを、全ノードマルチキャストＭＡＣアドレスとする。
【０１７１】
（５）ノード１４が送信したアドレス重複問合せのためのＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを、ルータ２２が受信した以降の動作手順に、図１７で説明した動作手順が適用される。
【０１７２】
なお、本実施形態においても、ＡＰ１２が有線でノード１４と接続するＬ２ＳＷである場合は、ノード１４間の通信をＬ２ＳＷで禁止するようにしてもよい。この場合、ノード１４が送信するフレームを他のノード１４が傍受することはできない。したがって、ノード１４−Ｌ２ＳＷ間（方法Ａ）、あるいは、ノード１４−ルータ２２（方法Ｂ）間の通信を暗号化する必要がなくなる。
【０１７３】
以上、本発明の第２実施形態について説明した。
【０１７４】
本実施形態では、ノード１４毎に、固有の暗号鍵を用いて、ノード１４およびＡＰ１２あるいはルータ２２間の通信を行なうようにしている。また、ルータ２２に、認証に成功した各ノード１４のＩＰアドレス、ＭＡＣアドレスおよびユーザ名を管理させると共に、あるノード１４がアドレス重複問合せを行った場合に、対象ＩＰアドレスが他のノード１４で使用中であるか否かを判定させ、使用中である場合は、アドレス重複通知を行なわせる。あるいは、対象ＩＰアドレスとアドレス重複問合せを行ったノードのＭＡＣアドレスとを比較させ、対象ＩＰアドレスがＭＡＣアドレスベースで生成されたものか否かを判定させる。そして、ＭＡＣアドレスベースで生成されたものでない場合は、アドレス重複通知を行なわせる。このため、各ノード１４のＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。また、ノード１４がルータ２２以外の他ノード１４と直接通信できないようにすることができ、したがって、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【０１７５】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１７６】
例えば、図１に示した公衆無線ＬＡＮアクセスサービスシステムにおいて、ＡＰ１２およびＡＤＳＬモデム１６は、一体化されたものであってもよい。また、ＩＳＰ２０内にルータ２２やＲＡＤＩＵＳサーバ２４やＧＷ２６や管理装置２８は、いずれか２つ以上が同じコンピュータシステム上に構築されていてもよいし、それぞれが別々のコンピュータシステム上に構築されていてもよい。
【０１７７】
また、上記の実施形態では、本発明の公衆無線ＬＡＮアクセスサービスシステムに適用した場合を例に取り説明しているが、本発明は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容するシステムに広く適用できる。例えば、ＬＡＮによりＰＰＰを使用しないでホストを収容する、加入者宅からのＩＰｖ６ネットワークアクセスサービスシステムにも、同様に適用できる。
【０１７８】
【発明の効果】
以上説明したように、本発明によれば、ＩＰｖ６においてＬＡＮによりＰＰＰを使用しないでホストを収容する場合でも、ＩＰｖ６の特徴である自動コンフィギュレーションを有効活用することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態が適用される公衆無線ＬＡＮアクセスサービスシステムの概略図を示す図である。
【図２】図１に示すＡＰ１２の概略構成図である。
【図３】図２に示すＭＡＣアドレステーブル１２７の登録内容例を示す図である。
【図４】図１に示すルータ２２の概略構成図である。
【図５】図４に示すユーザ管理テーブル２２８の登録内容例を示す図である。
【図６】図１に示す管理装置２８の概略図である。
【図７】図６に示す管理装置２８のハードウエア構成例を示す図である。
【図８】本発明の第１実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示した図である。
【図９】ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合における、本発明の第１実施形態の動作手順を説明するためのシーケンス図である。
【図１０】ＭＡＣアドレスと、ＭＡＣアドレスをベースとして自動生成されるインタフェースＩＤとの関係を示す図である。
【図１１】本発明の第１実施形態で用いるＩＰｖ６パケットを格納したＭＡＣフレームのフォーマット構成例を示す図である。
【図１２】ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加する場合における、本発明の第２実施形態の動作手順を説明するためのシーケンス図である。
【図１３】本発明の第２実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示した図である。
【図１４】本発明の第２実施形態で用いられるルータ２２の概略構成図である。
【図１５】図１４に示すＩＰアドレス管理テーブル２２９の登録内容例を示す図である。
【図１６】ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合における、本発明の第２実施形態の動作手順を説明するためのシーケンス図である。
【図１７】本発明の第２実施形態において、図１６の続きの動作手順を説明するためのシーケンス図である。
【図１８】ＩＰｖ６の自動コンフィギュレーションの動作手順を説明するためのシーケンス図である。
【符号の説明】
１０…スポット、１２…ＡＰ、１４…ノード、１６…ＡＤＳＬモデム、２０…ＩＳＰ、２２…ルータ、２４…ＲＡＤＩＵＳサーバ、２６…ＧＷ、２８…管理装置、３０…ＤＳＬＡＭ、４０…ＩＰｖ６ネットワーク、１２１…無線ＩＦ部、１２２…ＬＡＮコネクタ、１２３…ＰＨＹ処理部、１２４…ＭＡＣＦＷＤ部、１２５…ＰＲＯＣ部、１２６…バス、１２７…ＭＡＣアドレステーブル、２２１…ＬＡＮコネクタ、２２２…ＬＡＮコネクタ、２２３…ＰＨＹ処理部、２２４…ＩＰｖ６処理部、２２５…ＰＲＯＣ部、２２６…バス、２２７…ルーティングテーブル、２２８…ユーザ管理テーブル、２２９…ＩＰアドレス管理テーブル
【図１】
2004072633.tif 000003
【図２】
2004072633.tif 000004
【図３】
2004072633.tif 000005
【図４】
2004072633.tif 000006
【図５】
2004072633.tif 000007
【図６】
2004072633.tif 000008
【図７】
2004072633.tif 000009
【図８】
2004072633.tif 000010
【図９】
2004072633.tif 000011
【図１０】
2004072633.tif 000012
【図１１】
2004072633.tif 000013
【図１２】
2004072633.tif 000014
【図１３】
2004072633.tif 000015
【図１４】
2004072633.tif 000016
【図１５】
2004072633.tif 000017
【図１６】
2004072633.tif 000018
【図１７】
2004072633.tif 000019
【図１８】
2004072633.tif 000020