JP2004072633A

JP2004072633A - IPv6 NODE ACCOMMODATING METHOD AND IPv6 NODE ACCOMMODATING SYSTEM

Info

Publication number: JP2004072633A
Application number: JP2002232058A
Authority: JP
Inventors: Norihisa Matsumoto; 松本　謙尚; Tetsuhiko Hirata; 平田　哲彦; Masato Hino; 日野　雅透; Josuke Matsuki; 松木　譲介
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-08-08
Filing date: 2002-08-08
Publication date: 2004-03-04

Abstract

<P>PROBLEM TO BE SOLVED: To enable an automatic configuration which is a characteristic of an IPv6 to be utilized, even when a host is accommodated without using a PPP by a LAN. <P>SOLUTION: By assigning a different prefix for global (site local) address to each node 14, a single node belongs to each link local. Basically, a router advertisement in which both of an IP address and a MAC address are multicast is transmitted to a specific node 14, even if the IP address of the node 14 is uncertain. Thus, a prefix exclusive to the node is assigned to the node 14. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰｖ６ノードのネットワーク接続技術に関する。
【０００２】
【従来の技術】
ＩＰｖ６（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　６）に関し、ＩＥＴＦ（Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）規格のＲＦＣ２４６１”Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）”およびＲＦＣ２４６３”ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ”に、ネットワークへの接続に際して、ノードがＩＰ通信に必要な最低限のコンフィグレーションを自動で行う手順（自動コンフィギュレーション）が規定されている。
【０００３】
図１８は、ＩＰｖ６の自動コンフィギュレーションの動作手順を説明するためのシーケンス図である。図示するように、自動コンフィギュレーションは、３つの段階ＳＴ１００１〜ＳＴ１００３で構成される。
【０００４】
（１）ＳＴ１００１：リンクローカルアドレスの仮決め
先ず、ノードは、インターフェースＩＤを、ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスをベースとして生成する。ＭＡＣアドレスからインタフェースＩＤを生成する方法は、ＲＦＣ２３７３”ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ”に規定されている。そして、このインターフェースＩＤにリンクローカルアドレス用の固定プレフィックスを付加し、これをリンク（サブネット）内でのみ使用可能なＩＰアドレスであるリンクローカルアドレスに仮決めする。
【０００５】
（２）ＳＴ１００２：リンクローカルアドレスの正式決定
次に、ノードは、仮決めしたリンクローカルアドレスが同一リンク内で既に使用されているか否かを、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージによりリンク内にマルチキャストで問合せる（アドレス重複問合せ：Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔ）。ここで、アドレス重複問合せのソースアドレスは０である（ｓｒｃＩＰａｄｄｒ＝０）。そして、規定時間内に、リンク内の他ノードから応答（アドレス重複通知：Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅ）がなかった場合は、仮決めしたリンクローカルアドレスを正式採用する。
【０００６】
もし、リンク内の他のノードがそれに応答した場合は、この他のノードが同一のリンクローカルアドレスを既に使用中である。アドレス重複問合せをしたノードは、このリンクローカルアドレスを使用することはできない。つまり、自動コンフィグレーションは失敗となる。アドレス重複問合せをしたノードは、ユーザの介在等により適切なＩＰｖ６アドレスをノードに割当てなければ、ＩＰ通信を行なうことができない。
【０００７】
（３）ＳＴ１００３：グローバル（サイトローカル）アドレスの決定
次に、ノードは、ルータがＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージによりリンク内で定期的にマルチキャストで広告しているルータ広告（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅ）を受信する。そして、ルータ広告からグローバル（サイトローカル）アドレス用プレフィックスを取得し、これを正式採用したリンクローカルアドレスに付加することで、ノードがルータを超えたＩＰ通信に必要なグローバル（サイトローカル）アドレスを決定する。
【０００８】
グローバル（サイトローカル）アドレス用プレフィックスは、グローバル（サイトローカル）内でユニークであることが保証されている。これにより、ノードは、ルータを経由したグローバル（サイトローカル）でのＩＰ通信が可能になる。なお、ルータ広告を受信することで、ノードは、ルータのＭＡＣアドレス、ＩＰｖ６アドレスを学習する。
【０００９】
以上のように、ノードがＩＰ通信を行う上で必要な最低限のコンフィグレーションを、ユーザの介在なしに自動で行えるのがＩＰｖ６の利点のひとつである。
【００１０】
ところで、現在主流のＩＰｖ４（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　４）で実現されているアクセスサービスの１つに、公衆無線ＬＡＮアクセスサービスがある。
【００１１】
公衆無線ＬＡＮアクセスサービスは、喫茶店や駅に、ブリッジとして動作する無線ＬＡＮの基地局であるＡＰ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ）を設置し、これをＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）に接続することで、無線ＬＡＮとのインターフェースを備えたホストのインターネットアクセスを実現するものである。
【００１２】
公衆無線ＬＡＮアクセスサービスにおいて、ホストを収容する方法としては、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ　Ｐｒｏｔｏｃｏｌ）をホスト−ＩＳＰ間で確立する方法と、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ、ＩＥＥＥ８０２．３シリーズのネットワーク）によりＰＰＰを使用しないでホストを収容する方法とがある。
【００１３】
後者は、前者に比べ、ＩＰ通信開始時のオーバヘッドが小さいことや、通常のＬＡＮ接続と同様の設定で手軽にネットワークアクセスできることなどの利点がある。後者においてホストの認証には、ＩＥＥＥ８０２．１委員会が規定した８０２．１Ｘ規格が使用される。ＩＥＥＥ８０２．１Ｘ規格は、ブリッジが、それにアクセスしてきたノードを認証した上で、そのノードのＭＡＣフレーム（ＩＥＥＥ８０２．３シリーズのフレーム）の送受信を許可するプロトコルである。公衆無線ＬＡＮアクセスサービスでは、ＡＰがノードに対してユーザ名とパスワードを要求して入手し、これらをＲＡＤＩＵＳ（Ｒｅｍｏｔｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｄｉａｌ−Ｉｎ　Ｕｓｅｒ　Ｓｅｒｖｉｃｅ）サーバへ送信して認証を依頼する。そして、ＲＡＤＩＵＳサーバでの認証結果に基づいて、ＡＰがノードのネットワークアクセスを制御する。
【００１４】
【発明が解決しようとする課題】
さて、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する方法を用いて公衆無線ＬＡＮアクセスサービスを実現しようとした場合、ＩＰｖ６の特徴である自動コンフィグレーションを活かしつつ、如何にしてノードを収容するリンク（サブネット）の可用性を高めるかが問題となる。
【００１５】
例えば、図１８のＳＴ１００２において、あるノードが行なったアドレス重複問合せに対し、リンク内の他のノードがそれに応答しアドレス重複通知を行なうことで、前記あるノードがこのアドレスを使用するのを禁止することができる。このため、悪意を持ったノードの存在により自動コンフィギュレーションが成功しなくなる可能性がある。
【００１６】
また、図１８のＳＴ１００３において、ルータ以外のあるノードがルータ広告を行なうことにより、このノード以外のノードは、ルータ広告を行なったノードをルータと認識して、ネットワークアクセスを試みてしまう。このため、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性がある。
【００１７】
これらの問題は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する方法を用いて、加入者宅からのインターネットアクセスサービスを実現しようとした場合にも、同様に生じる。
【００１８】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容する場合に生じる問題を解決することにある。例えば、ＩＰｖ６の特徴である自動コンフィギュレーションを有効活用できるようにすることにある。また、ネットワークアクセスできなくなる可能性を低減することにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、本発明では、各ノードへのアドレス割当てにルータを介在させ、ルータに、ノード間のアドレス重複が生じないように、各ノードにアドレスを割当てることにより、ＩＰｖ６においてＬＡＮによりＰＰＰを使用しないでノードを収容する。
【００２０】
例えば、ノードの各々に異なるグローバル（サイトローカル）アドレス用プレフィックスを付与することにより、各リンクローカル内に１つのノードが属するようにする。具体的には、ノード毎に固有のプレフィックスが設定されたルータ広告用ＩＣＭＰメッセージを生成し、このＩＣＭＰメッセージを、宛先ＩＰアドレスにマルチキャストＩＰアドレスが設定されたＩＰｖ６パケットに格納する。さらに、このＩＰｖ６パケットを、宛先ＭＡＣアドレスに前記固有のプレフィックスを設定すべきＩＰｖ６ノードのＭＡＣアドレスが設定されたＭＡＣフレームに格納して、ＬＡＮ上に送出する。なお、ノードのＭＡＣアドレスは、当該ノードの認証（ＩＥＥＥ８０２．１Ｘ規格による認証）を通じて入手すればよい。
【００２１】
このようにすることで、本来はＩＰアドレスおよびＭＡＣアドレスの双方が共にマルチキャストであるルータ広告を、特定のノードに対して、そのノードのＩＰアドレスが不明でも送達できる。これにより、そのノードに、当該ノード専用のプレフィックスを割当てることができる。そして、各ノードに専用のプレフィックスを割当てれば、ノード間でのインタフェースＩＤの重複は発生しない。したがって、各ノードのＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。
【００２２】
また、上記課題を解決するために、本発明では、ノード間のアドレス重複通知を禁止する。例えば、ノード固有の暗号鍵を用いて、ルータとノードとの間の通信、あるいは、ルータおよびノード間を接続するブリッジとノードとの間の通信を行なうようにする。これにより、ノードがルータ以外の他ノードと直接通信できないようにする。さらに、本発明では、認証（ＩＥＥＥ８０２．１Ｘ規格による認証）に成功した各ノードのＩＰアドレスおよびＭＡＣアドレスを管理する。そして、あるノードからアドレス重複問合せを受信した場合に、前記問合せの対象ＩＰアドレスが他のＩＰｖ６ノードで使用中であるか否かを判定する。使用中である場合に、前記問合せをしたノードに対してアドレス重複通知を行なう。なお、使用中のＩＰアドレスに対するアドレス重複問合せがあった場合は、ルータがネットワーク管理装置に通知することで、どのユーザ間でアドレス重複が発生したかを管理するようにしてもよい。
【００２３】
このようにすることで、各ノードのＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。また、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
【００２５】
先ず、本発明の第１実施形態について説明する。
【００２６】
図１は、本発明の第１実施形態が適用される公衆無線ＬＡＮアクセスサービスシステムの概略図を示している。
【００２７】
図示するように、喫茶店や駅といったスポット１０毎に、ブリッジとして動作する無線ＬＡＮの基地局であるＡＰ１２が設置される。無線ＬＡＮカードなどの無線通信機能を有するＩＰｖ６対応のノード１４は、自身が位置するスポット１０に設置されているＡＰ１２と無線通信を行なう。この無線通信に用いられる通信規格としては、ＩＥＥＥ８０２．１１ｂやＩＥＥＥ８０２．１１ａなどがある。
【００２８】
ＡＰ１２は、自身が設置されているスポット１０に位置するノード１４を、ＩＰｖ６ネットワーク４０へのアクセスサービスを提供するＩＳＰ２０に接続する。本実施形態では、ＬＡＮによりＰＰＰを使用しないでノード１４をＩＳＰ２０に収容するようにしている。したがって、ＩＳＰ２０およびノード１４間は、ＭＡＣフレームにより通信が行なわれる。
【００２９】
なお、本実施形態では、ＡＰ１２をＩＳＰ２０に接続するためのアクセス回線として、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）回線を想定している。このため、ＡＰ１２は、１０Ｂａｓｅ−ＴなどのＬＡＮケーブルでＡＤＳＬモデム１６と接続し、ＡＤＳＬモデム１６は、電話線（メタル線）を介して、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ　Ａｃｃｅｓｓ　Ｍｕｌｔｉｐｌｅｘｅｒ）３０と接続する。そして、ＤＳＬＡＭ３０は、１００Ｂａｓｅ−ＴＸなどのＬＡＮケーブルでＩＳＰ２０内のルータ２２と接続する。但し、ＡＰ１２をＩＳＰ２０に接続するためのアクセス回線は、ＡＤＳＬ回線に限られるものではなく、光ファイバなどを利用してもよい。
【００３０】
ＩＳＰ２０は、ＬＡＮによりＰＰＰを使用しないでノード１４を収容するルータ２２と、ＩＥＥＥ８０２．１Ｘ規格に従いノード１４のユーザを認証を行なうＲＡＤＩＵＳサーバ２４と、ルータ２２をＩＰｖ６ネットワーク４０に接続するＧＷ（ゲートウエイ）２６と、ルータ２２の保守情報を管理する管理装置２８とが、ＬＡＮ接続されて構成される。
【００３１】
以上のような構成において、ノード１４のユーザは、ＩＳＰ２０の運営事業者と契約を行う。そして、ＩＳＰ２０の運営事業者は、契約したユーザのユーザ名およびパスワードをＲＡＤＩＵＳサーバ２４に登録する。
【００３２】
さて、ノード１４のユーザがあるスポット１０を訪れ、自身のノード１４を用いてＩＰｖ６ネットワーク４０へのネットワーク接続を開始すると、ＩＥＥＥ８０２．１Ｘ規格に従った認証が開始される。先ず、ＡＰ１２は、ネットワーク接続を開始したノード１４に、ユーザ名およびパスワードを要求し入手する。そして、入手したユーザ名およびパスワードをＲＡＤＩＵＳサーバ２４に転送し、認証を依頼する。次に、ＡＰ１２は、ＲＡＤＩＵＳサーバ２４から認証結果を受け取ると、それが認証成功であるならば、このノード１４およびルータ２２間の通信を中継する。これにより、ノード１４は、ＡＰ１２、ルータ２２およびＧＷ２６を介してＩＰｖ６ネットワーク４０へのアクセスが可能となる。
【００３３】
なお、ここでは、無線通信によりノード１４およびＡＰ１２間の通信を行なうものとして説明しているが、当然のことながら、ノード１４およびＡＰ１２間をＬＡＮケーブルで接続して通信を行なうようにしてもよい。
【００３４】
図２は、ＡＰ１２の概略構成図である。
【００３５】
図示するように、ＡＰ１２は、ノード１４と無線通信を行なうための無線ＩＦ（インターフェース）部１２１と、ＡＤＳＬモデム１６よりのＬＡＮケーブルを接続するためのＬＡＮコネクタ１２２と、無線ＩＦ部１２１およびＬＡＮコネクタ１２２のそれぞれに対して設けられた、対応する無線ＩＦ部１２１あるいはＬＡＮコネクタ１２２と送受する信号の物理レイヤの処理を行うＰＨＹ（ｐｈｙｓｉｃａｌｌａｙｅｒ）処理部１２３と、ＰＨＹ処理部１２２毎に設けられた、ノード１４およびルータ２２間のＭＡＣフレームの送受を制御するための処理を行なうＭＡＣＦＷＤ部１２４と、ＩＥＥＥ８０２．１Ｘメッセージを制御するＰＲＯＣ部１２５と、を有する。各ＭＡＣＦＷＤ部１２４およびＰＲＯＣ部１２５は、バス１２６によりバス接続されている。
【００３６】
ＭＡＣＦＷＤ部１２４は、ＭＡＣアドレス毎に、このＭＡＣアドレスが付与された装置およびこの装置へＭＡＣフレームを中継するＭＡＣＦＷＤ部１２４の情報を登録するＭＡＣアドレステーブル１２７を有している。
【００３７】
図３に、ＭＡＣアドレステーブル１２７の登録内容例を示す。図示するように、ＭＡＣアドレステーブル１２７は、ＭＡＣアドレスを登録するためのフィールド１２７１と、このＭＡＣアドレスが付与された装置との接続ポートを示すポート番号を登録するためのフィールド１２７２と、この接続ポートに接続された装置の属性を示すポート属性を登録するためのフィールド１２７３と、このＭＡＣアドレスが付与された装置との通信に利用する暗号鍵を登録するためのフィールド１２７４と、このＭＡＣアドレスが付与された装置との通信に対するＩＥＥＥ８０２．１Ｘ規格による認証の要否および必要な場合はその状態を示す認証状態を登録するためのフィールド１２７５とを備えて１つのレコードが形成される。
【００３８】
例えば、ルータ２２に付与されたＭＡＣアドレスがフィールド１２７１に登録されているレコードは、フィールド１２７２にルータ２２との接続ポート番号が登録され、フィールド１２７３にポート属性「ルータ」が登録され、そして、フィールド１２７５に、ＩＥＥＥ８０２．１Ｘ規格による認証が不要であることを示す認証状態「認証不要」が登録される。なお、ルータ２２との通信に暗号化が不要であれば、フィールド１２７４に暗号鍵は登録されない。
【００３９】
また、ノード１４に付与されたＭＡＣアドレスがフィールド１２７１に登録されているレコードは、フィールド１２７２にこのノード１４との接続ポート番号が登録され、フィールド１２７３にポート属性「ノード」が登録され、そして、フィールド１２７５に、ＩＥＥＥ８０２．１Ｘ規格による認証を実行中であれば認証状態「認証中」が、また、認証が実行済みであれば認証状態「認証済」が登録される。そして、フィールド１２７５が「認証中」から「認証済」に変わると、フィールド１２７４に登録されている暗号鍵を用いて、このノード１４との通信が行なわれる。
【００４０】
さて、ＭＡＣＦＷＤ部１２４は、対応するＰＨＹ処理部１２３からＭＡＣフレームを受け取ると、このＭＡＣフレームの送信元ＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から検索する。そして、検出したレコード（注目レコードと呼ぶ）のフィールド１２７３に登録されているポート属性が「ノード」ならば、次の処理を行なう。
【００４１】
すなわち、注目レコードのフィールド１２７５に登録されている認証状態が「認証済」であるか否かを調べる。「認証済」の場合、フィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを復号化する。それから、フィールド１２７３にポート属性「ルータ」が登録されているレコードを特定し、このレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。注目レコードのフィールド１２７４に暗号鍵が登録されていないならば、復号処理を行なうことなく、このＭＡＣフレームを、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ送信する。一方、注目レコードのフィールド１２７５に登録されている認証状態が「認証中」である場合、このＭＡＣフレームの宛先ＭＡＣアドレスを調べ、それがＡＰ１２のＭＡＣアドレスもしくはポートアクセスエンティティである場合のみ、このＭＡＣフレームをＰＲＯＣ部１２５に転送する。それ以外は、このＭＡＣフレームを廃棄する。
【００４２】
また、ＭＡＣＦＷＤ部１２４は、注目レコードのフィールド１２７３に登録されているポート属性が「ルータ」ならば、次の処理を行なう。
【００４３】
すなわち、このＭＡＣフレームの宛先ＭＡＣアドレスを調べ、それがフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介して無線ＩＦ部１２１に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。
【００４４】
なお、注目レコードを検出できなかった場合、すなわち、ＭＡＣフレームの送信元ＭＡＣアドレスがフィールド１２７１に登録されているレコードが、ＭＡＣアドレステーブル１２７に存在しない場合は、新たなレコードを追加し、このレコードのフィールド１２７１に送信元ＭＡＣアドレスを、フィールド１２７２に受信ポート番号を、フィールド１２７３にポート属性「ノード」を、そして、フィールド１２７５に認証状態「認証中」を登録する。
【００４５】
また、ＭＡＣＦＷＤ部１２４は、バス１２６を介して他のＭＡＣＦＷＤ部１２４からＭＡＣフレームを受け取ると、このＭＡＣフレームの送信先ＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から検索する。そして、検出したレコードのフィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを暗号化してから、対応するＰＨＹ処理部１２３へ送信する。暗号鍵が登録されていないならば、暗号化処理を行なうことなく、このＭＡＣフレームを対応するＰＨＹ処理部１２３へ送信する。
【００４６】
ＰＲＯＣ部１２５は、ＩＥＥＥ８０２．１Ｘメッセージを制御して、ノード１４の認証を、ＩＳＰ２０に依頼する。そして、その状態（認証中か認証済か）に従ってＭＡＣＦＷＤ部１２４のＭＡＣアドレステーブル１２７を更新する。具体的には、認証対象のノード１４のＭＡＣアドレスがフィールド１２７１に登録されているレコードをＭＡＣアドレステーブル１２７から特定し、このレコードのフィールド１２７５に認証状態を登録・更新する。
【００４７】
また、ＰＲＯＣ部１２５は、ＩＥＥＥ８０２．１Ｘメッセージを送信する場合は、これを格納したＭＡＣフレームを作成し、その宛先ＭＡＣアドレスに対応するＭＡＣＦＷＤ部１２４に送信する。
【００４８】
図４は、ルータ２２の概略構成図である。
【００４９】
図示するように、ルータ２２は、ＤＳＬＡＭ３０よりのＬＡＮケーブルを接続するためのＬＡＮコネクタ２２１と、ＲＡＤＩＵＳサーバ２４やＧＷ２６や管理装置２８と接続するＬＡＮケーブルを接続するためのＬＡＮコネクタ２２２と、ＬＡＮコネクタ２２１、２２２のそれぞれに対して設けられた、対応するＬＡＮコネクタ２２１、２２２と送受する信号の物理レイヤの処理を行うＰＨＹ処理部２２３と、ＰＨＹ処理部２２３毎に設けられたＩＰｖ６の処理を行なうＩＰｖ６処理部２２４と、ＩＥＥＥ８０２．１Ｘメッセージを制御するＰＲＯＣ部２２５と、を有する。各ＩＰｖ６処理部２２４およびＰＲＯＣ部２２５は、バス２２６によりバス接続されている。
【００５０】
ＩＰｖ６処理部２２４は、ＩＰｖ６のルーティングを行なうためのルーティングテーブル２２７を有している。ルーティングテーブルには、プレフィックス毎に、そのプレフィックスにより特定されるネットワークに向かうための次ホップのＩＰアドレスと、次ホップのＩＰアドレスに対応するＭＡＣアドレスと、次ホップへの中継を行なうＩＰｖ６処理部２２４の識別情報とが、互いに対応付けられて登録されている。
【００５１】
さて、ＩＰｖ６処理部２２４は、対応するＰＨＹ処理部２２３からＭＡＣフレームを受信すると、このＭＡＣフレームからＩＰパケットを取り出す。そして、ルーティングテーブルを用いて、このＩＰパケットの最長適合プレフィックスに対応付けれれている次ホップのＩＰアドレスおよびＭＡＣアドレスと、ＩＰｖ６処理部２２４の識別情報とを特定する。それから、このＩＰパケットを格納した、次ホップのＭＡＣアドレスを宛先とするＭＡＣフレームを生成し、特定した識別情報を持つＩＰｖ６処理部２２４へ送出する。また、ＩＰｖ６処理部２２４は、バス２２６を介して、他のＩＰｖ６処理部２２４からＭＡＣフレームを受け取ると、これを対応するＰＨＹ処理部２２３へ送信する。
【００５２】
なお、ＩＰｖ６処理部２２４は、対応するＰＨＹ処理部２２３より受け取ったＭＡＣフレームに格納されているＩＰパケットが、ＲＡＤＩＵＳメッセージやＩＣＭＰメッセージ等のルータ２２宛のＩＰパケットである場合、これをＰＲＯＣ２２５に送信する。
【００５３】
ＰＲＯＣ部２２５は、ＩＥＥＥ８０２．１Ｘメッセージを制御して、ノード１４の認証を、ＲＡＤＩＵＳサーバ２４に依頼する。また、ＰＲＯＣ部２２５は、ユーザ管理テーブル２２８を有しており、これを用いて、ノード１４のユーザ毎にプレフィックスを管理する。
【００５４】
図５に、ユーザ管理テーブル２２８の登録内容例を示す。図示するように、ユーザ管理テーブル２２８は、ノード１４のＩＥＥＥ８０２．１Ｘ規格による認証の状態を登録するフィールド２２８１と、ノード１４のＭＡＣアドレスを登録するためのフィールド２２８２と、ノード１４に割り当てたプレフィックスを登録するためのフィールド２２８３と、このノード１４がルータ２２と暗号通信を行なう場合に使用する暗号鍵を登録するためのフィールド２２８４と、このノード１４のユーザ名を登録するフィールド２２８５と、を備えて１つのレコードが形成される。ここで、フィールド２２８１の認証状態が「認証中」である場合、そのレコードのフィールド２２８２に登録されているＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信してはならないことを示している。
【００５５】
管理装置２８は、上述したように、ルータ２２の保守情報を管理する。
【００５６】
図６は、管理装置２８の概略図である。
【００５７】
図示するように、管理装置２８は、ルータ２２などと通信を行なうためのネットワークＩＦ部２８１と、管理者より各種指示を受け付けたり、管理者に情報を表示したりするＧＵＩ部２８２と、ルータ２２の保守情報を管理する保守管理部２８３と、を有する。保守管理部２８３は、ＧＵＩ部２８２を制御して、ルータ２２より受け取ったＩＰアドレスの重複報告メッセージを表示したり、ネットワークＩＦ部２８１を介してルータ２２にアクセスし、管理者より指示された情報を入手して表示したりする。
【００５８】
管理装置２８は、例えば図７に示すような、ＣＰＵ８０１と、メモリ８０２と、ＨＤＤ等の外部記憶装置８０３と、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の可搬性を有する記憶媒体８０４から情報を読み出す読取装置８０５と、キーボードやマウスなどの入力装置８０６と、ＣＲＴやＬＣＤなどの表示装置８０７と、ルータ２２などと通信を行なうための通信装置８０８と、を備えた一般的なコンピュータシステムにおいて、ＣＰＵ８０１がメモリ８０２上にロードされた所定のプログラムを実行することにより実現することができる。この所定のプログラムは、読取装置８０５を介して記憶媒体８０４から、あるいは、通信装置８０８を介してインターネットなどの通信媒体から、メモリ８０２に直接ロードしてもよいし、あるいは、一旦、外部記憶装置８０９にダウンロードしてから、メモリ８０２にロードしてもよい。
【００５９】
なお、ノード１４、ＡＤＳＬモデム１６、ＤＳＬＡＭ３０、ＲＡＤＩＵＳサーバ２４およびＧＷ２６は、ＩＰｖ６対応の既存の装置を利用することができるので、その詳細な説明は省略している。
【００６０】
図８は、図１に示す本実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示したものである。
【００６１】
上述したように、ルータ２２、ＲＡＤＩＵＳサーバ２４および管理装置２８間は、ＬＡＮ接続されている。このため、実際には、図示していないＬ２ＳＷ（Ｌａｙｅｒ　２　ｓｗｉｔｃｈ）が、ルータ１０３、ＲＡＤＩＵＳサーバ２４および管理装置２８間の接続に用いられている。
【００６２】
図示するように、本実施形態では、各ノード１４は、それぞれ異なるリンクに収容される。すなわち、ルータ２２は、個々のノード１４に対して、異なるネットワークプレフィックスをルータ広告する。これにより、ノード１４間でＩＰｖ６アドレスが重複するのを防止する。なお、個々のノード１４にルータ広告されるネットワークプレフィックスのユニーク性は、ルータ２２が保証する。
【００６３】
さらに、本実施形態では、あるノード１４が送信したアドレス重複通知パケットが、他のノード１４に届かないようにしている。
【００６４】
具体的には、ノード１４およびＡＰ１２間の通信をノード１４毎に異なる暗号鍵で暗号化することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする方法（方法Ａとする）、および、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする、もしくは不正パケットとして無視するようにする方法（方法Ｂとする）のいずれかを採用している。
【００６５】
いずれの方法でも、ノード１４およびＲＡＤＩＵＳサーバ２４は、予めユーザ名に対応した認証鍵と暗号鍵との組を格納しており、認証鍵はＩＥＥＥ８０２．１Ｘの認証で用いられ、暗号鍵は認証成功後の暗号通信に用いられる。
【００６６】
先ず、方法Ａについて、図９を用いて説明する。
【００６７】
図９は、ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合、つまり方法Ａが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスは、それぞれｍ１、ｌ０およびｋ０としている。
【００６８】
ノード１４は、電源が投入されると、ネットワーク接続を開始する。先ず、インターフェースＩＤを、ＭＡＣアドレスをベースとして自動生成する（ＳＴ２００１）。上述したように、ＭＡＣアドレスからインタフェースＩＤを生成する方法は、ＲＦＣ２３７３”ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ”に規定されている。図１０に、ＭＡＣアドレスと、ＭＡＣアドレスをベースとして自動生成されるインタフェースＩＤとの関係を示す。
【００６９】
図示するように、インターフェースＩＤ９０２は、ＭＡＣアドレス９０１内の企業ＩＤ（図中ｃで示したビット列）と拡張ＩＤ（図中ｍで示したビット列）の間に、１６ビットのビット列「１１１１１１１１１１１１１１１０」を挿入し、ユニバーサル／ローカルビット（図中、ビット値が「０」となっているビット）を反転させることで生成する。なお、図中「ｇ」で示したビットは、個別／グループビットと呼ばれるビットである。リンクローカルアドレス９０３は、インタフェースＩＤ９０２の上位に、リンクローカルアドレス用の固定プレフィックス「ＦＥ８０：：」を付加したものである。
【００７０】
また、図１０において、要請ノードマルチキャストＩＰアドレス９０４は、インタフェースＩＤ９０２の下位３バイトに、「ＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４」を付加したものである。それに対応する要請ノードマルチキャストＭＡＣアドレス９０５は、要請ノードマルチキャストＩＰアドレス９０４の下位４バイトに、「０ｘ３３３３」を付加したものである。
【００７１】
また、図１０において、全ノードマルチキャストＩＰアドレス９０６は、「ＦＦ０２：：１」であり、それに対応する全ノードマルチキャストＭＡＣアドレス９０７は、全ノードマルチキャストＩＰアドレス９０７の下位４バイトに、「０ｘ３３３３」を付加したものである。全ノードマルチキャストＩＰアドレス９０６が宛先ＩＰアドレスであるＩＰｖ６パケットのＭＡＣフレームは、通常、全ノードマルチキャストＭＡＣアドレス９０７を宛先ＭＡＣアドレスに設定する。
【００７２】
ノード１４は、ＲＦＣ２２８４で規定されている、ＲＡＤＩＵＳサーバ２４がノード１４の認証を行うためのプロトコルであるＥＡＰ（ＰＰＰ　Ｅｘｔｅｎｓｉｂｌｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に従い、ＡＰ１２とＥＡＰメッセージ（ＥＡＰＯＬ−Ｓｔａｒｔ、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙ、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅ、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐ）の送受信を行なう。ここで、ＥＡＰメッセージは、ＩＥＥＥ８０２．１Ｘ規格で規定されているＥＡＰＯＬ（ＥＡＰ　ｏｖｅｒ　ＬＡＮ）パケットにより送受信される。
【００７３】
一方、ＡＰ１２は、ＥＡＰＯＬパケットによりノード１４と送受信するＥＡＰメッセージを、ＲＡＤＩＵＳパケット（ＲＡＤＩＵＳ　ＡＣＣＥＳＳ−Ｒｅｑ、−Ｃｈａｌｌｅｎｇｅ、−Ａｃｐｔ）によりＲＡＤＩＵＳサーバ２４と送受信する。ＡＰ１２は、このためのＩＰアドレスを有している。なお、ＲＡＤＩＵＳプロトコルは、ＲＦＣ２８６５〜２８６９に規定されている。
【００７４】
さて、ノード１４は、ＩＥＥＥ８０２．１Ｘ規格の認証開始を要求するＥＡＰＯＬ−Ｓｔａｒｔメッセージを、ポートアクセスエンティティを意味するＭＡＣアドレス宛に送信する（ＳＴ２００２）。これにより、ＥＡＰＯＬ−Ｓｔａｒｔメッセージがノード１４からＡＰ１２へ送信される。
【００７５】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰＯＬ−Ｓｔａｒｔメッセージを受け取ると、ＭＡＣアドレステーブル１２７にレコードを追加し、このレコードのフィールド１２７１に、ＥＡＰＯＬ−Ｓｔａｒｔメッセージを送信したノード１４のＭＡＣアドレスを、フィールド１２７２に、このノード１４との接続ポートのポート番号を、そして、フィールド１２７５に、認証状態「認証中」を登録する（ＳＴ２００３）。
【００７６】
また、ＰＲＯＣ部１２５は、ユーザ名を要求するＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを作成し、これを無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からＥＡＰＯＬ−Ｓｔａｒｔメッセージを送信したノード１４へ送信する（ＳＴ２００４）。
【００７７】
ノード１４は、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを受信すると、予め登録された、あるいは、ユーザより入力されたユーザ名を含んだＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを生成し、ＡＰ１２に送信する（ＳＴ２００５）。
【００７８】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを作成し、このメッセージのＣａｌｌｉｎｇ−Ｓｔａｔｉｏｎ−Ｉｄアトリビュートにノード１４のＭＡＣアドレスを格納すると共に、ＥＡＰ−ＭｅｓｓａｇｅアトリビュートにこのＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを格納する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、ＬＡＮコネクタ１２２からルータ２２へ送信する（ＳＴ２００６）。
【００７９】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＡＰ１２よりＲＡＤＩＵＳＡｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ユーザ管理テーブル２２８にレコードを追加し、このレコードのフィールド２２８１に、認証状態「認証中」を、フィールド２２８２に、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを送信したノード１４のＭＡＣアドレスを、そして、フィールド２２８５に、ノード１４のユーザのユーザ名を登録する（ＳＴ２００７）。
【００８０】
また、ＰＲＯＣ部２２５は、ＡＰ１２より受け取ったＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２からＲＡＤＩＵＳサーバ２４へ送信する（ＳＴ２００８）。これにより、ノード１４のユーザ名とＭＡＣアドレスとを、ＲＡＤＩＵＳサーバ２４に通知する。
【００８１】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを生成すると共に、認証乱数を生成し、これをＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＣｈａｌｌｅｎｇｅメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュート内のＥＡＰメッセージに設定する。それから、このＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを、ルータ２２を介して、ＡＰ１２に送信する（ＳＴ２００９）。
【００８２】
ＡＰ１２において、ＰＲＯＣ部１２５は、ＬＡＮコネクタ１２２側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを受け取ると、このメッセージに含まれている認証乱数を含んだ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを作成する。そして、このメッセージを、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からノード１４へ送信する（ＳＴ２０１０）。
【００８３】
ノード１４は、ＡＰ１２よりＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを受信すると、このメッセージに含まれている認証乱数と、予め保持している認証鍵とを用いて認証演算を行う。そして、その結果を、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含めてＡＰ１２に送信する（ＳＴ２０１１）。
【００８４】
ＡＰ１２において、ＰＲＯＣ部１２５は、無線ＩＦ部１２１側のＰＨＹ処理部１２３およびＭＡＣＦＷＤ部１２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを受信すると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを生成し、このメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、受信したＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを設定する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、ＬＡＮコネクタ１２２から、ルータ２２経由で、ＲＡＤＩＵＳサーバ２４に送信する（ＳＴ２０１２）。
【００８５】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受信すると、これに設定されているＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含まれている認証結果を用いて、ノード１４のユーザの認証を行う。具体的には、このノード１４のユーザ名に対応付けて予め登録されている認証鍵を用いて、ＳＴ２００９で生成した認証乱数に対し認証演算を行う。その結果がノード１４から受信したものと一致するか判定する（ＳＴ２０１３）。
【００８６】
一致した場合は認証成功となる。この場合、ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを生成し、これに、ノード１４に割り当てるプレフィックスと、ＡＰ１２が無線区間の暗号通信に利用する暗号鍵とを含めて、ルータ３３に通知する（ＳＴ２０１４）。ここで、プレフィックスは、ノード１４毎に異なる値とされ、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＡｃｐｔメッセージのＦｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘアトリビュートに設定される。また、暗号鍵は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージの例えばＣａｌｌｂａｃｋ−Ｉｄアトリビュートに設定される。
【００８７】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれているプレフィックスを、ＳＴ２００７でユーザ管理テーブル２２８に追加したレコードのフィールド２２８３に登録する。また、フィールド２２８１に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２０１５）。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信できるように、各部を制御する。
【００８８】
また、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から、ＡＰ１２に送信する（ＳＴ２０１６）。
【００８９】
ＡＰ１２において、ＰＲＯＣ部１２５は、ＬＡＮコネクタ１２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ルータ２２よりＲＡＤＩＵＳＡｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれている暗号鍵を、ＳＴ２００３でＭＡＣアドレステーブル１２７に追加したレコードのフィールド１２７４に登録する。また、フィールド１２７５に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２０１７）。これにより、ＰＲＯＣ部１２５は、このノード１４とルータ２２との間で送受されるＭＡＣフレームがブリッジされるように、各部を制御する。
【００９０】
また、ＰＲＯＣ部１２５は、登録した暗号鍵を含んだＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを生成し、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４およびＰＨＹ処理部１２３を介して、無線ＩＦ部１２１からノード１４に送信し、ノード１４に、認証が成功したことを通知する（ＳＴ２０１８）。
【００９１】
ノード１４は、ＡＰ１２よりＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを受け取ると、これに含まれている暗号鍵を登録する（ＳＴ２０１９）。
【００９２】
以上により、ＩＥＥＥ８０２．１規格に従った認証が終了する。以降、ノード１４およびＡＰ１２は、この暗号鍵を用いてＭＡＣフレームの暗号通信を行なう。
【００９３】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージに含まれていたプレフィックスを、このプレフィックスが割り当てられるノード１４に通知するため、ルータ広告であるＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これを、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から、ＡＰ１２経由でノード１４に送信する（ＳＴ２０２０）。
【００９４】
ここで、図１１に、本実施形態で用いるＩＰｖ６パケットを格納したＭＡＣフレームのフォーマット構成例を示す。
【００９５】
図示するように、本実施形態で用いるＭＡＣフレーム９２０は、宛先ＭＡＣアドレス９２１と、送信元ＭＡＣアドレス９２２と、格納データのタイプ９２３と、格納データ９２４と、ＣＲＣ（Ｃｙｃｌｉｃ　Ｒｅｄｕｎｄａｎｃｙ　Ｃｈｅｃｋｉｎｇ）９２５と、を含んでいる。タイプ９２３が「０ｘ８６ＤＤ」の場合、格納データ９２４がＩＰｖ６パケットであることを示している。
【００９６】
ＩＰｖ６パケット９３０は、ＩＰヘッダと、ＩＰペイロード９３４とを含んでいる。ＩＰヘッダには、送信元ＩＰアドレス９３１および宛先ＩＰアドレス９３２が含まれる。さらに、ＩＰヘッダには、拡張ヘッダとしてＩＰパケットの認証情報を設定するための認証ヘッダやＩＰペイロード７９３４を暗号化する場合に必要な暗号ペイロードヘッダ９３３を含めることができる。ＩＰペイロード９３４には、ＩＣＭＰパケットを設定することができる。
【００９７】
Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージ９４０は、ＩＣＭＰタイプ９４１が「１３４」のＩＣＭＰパケットである。送信元リンクレイヤオプション９４２に送信元ルータのＭＡＣアドレスが登録され、プレフィックス情報オプション９４３にリンク（サブネット）のプレフィックスが登録される。
【００９８】
図９のＳＴ２０２０において、ルータ２２がＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを送信する場合、この時点ではノード１４のＩＰアドレスが未だ確定していないため、ＩＰヘッダの宛先ＩＰアドレス９３２には全ノードマルチキャストＩＰアドレスを設定する必要がある。しかし、本実施形態では、各ノード１４をそれぞれ異なるリンクに収容するようにしている。このため、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージで送信するプレフィックスは、このプレフィックスが割り当てられるノード１４以外に受信されないようにする必要がある。
【００９９】
そこで、ルータ２２において、ＰＲＯＣ部２２５は、このＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを含むＭＡＣフレームの宛先ＭＡＣアドレス９２１に、ユーザ管理テーブル２２８にてＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージのプレフィックスがフィールド２２８３に登録されているレコードの、フィールド２２８２に登録されているＭＡＣアドレスを設定する。図９に示す例では、ノード１４のＭＡＣアドレス「ｍ１」が設定される。
【０１００】
ＡＰ１２において、ＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４は、ＬＡＮコネクタ１２２およびＰＨＹ処理部１２３を介して、ルータ２２より、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを格納したＭＡＣフレームを受信すると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの宛先ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介して無線ＩＦ部１２１に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。
【０１０１】
これを受けて、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、バス１２６を介してＬＡＮコネクタ１２２側のＭＡＣＦＷＤ部１２４からＭＡＣフレームを受け取ると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの宛先ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７５に登録されている認証状態が「認証済」であることを確認した後、このレコードのフィールド１２７４に暗号鍵が登録されているならば、この暗号鍵を用いてＭＡＣフレームの格納データを暗号化してから、対応するＰＨＹ処理部１２３へ送信する。これにより、格納データが暗号化されたＭＡＣフレームが、ＡＰ１２からＭＡＣアドレス「ｍ１」を持つノード１４へ送信される。
【０１０２】
ノード１４は、宛先ＭＡＣアドレスが自身のＭＡＣフレームを受信すると、ＳＴ２０１９で登録した暗号鍵を用いて格納データを復号化し、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを得る。そして、このメッセージに含まれている自身専用のプレフィックスを入手する。また、このメッセージの送信元ＩＰアドレスおよび送信元ＭＡＣアドレスを、デフォルトルータとして認識する（ＳＴ２０２１）。
【０１０３】
さて、ノード１４は、ＩＥＥＥ８０２．１規格に従った認証が終了した後、ＳＴ２００１で生成したインターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するために、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信して、アドレス重複問合せを行う（ＳＴ２０２２）。
【０１０４】
図１１に示すように、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０は、ＩＣＭＰタイプ９５１が「１３５」のＩＣＭＰパケットである。対象ＩＰアドレス９５２は、インターフェースＩＤ「Ｍ１」から生成したリンクローカルアドレス（図１０参照）が設定される。送信元リンクレイヤアドレスオプション９５３は含まれない。
【０１０５】
また、図１１に示すように、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０を格納するＩＰｖ６パケット９３０の送信元ＩＰアドレス９３１には、アドレス重複問合わせであることを示す「０」が設定され、宛先ＩＰアドレス９３２には、インターフェースＩＤ「Ｍ１」から生成される要請ノードマルチキャストＩＰアドレス（図１０参照）が設定される。
【０１０６】
また、図１１に示すように、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージ９５０を格納するＩＰｖ６パケット９３０を格納するＭＡＣフレーム９２０の宛先ＭＡＣアドレス９２１は、インタフェースＩＤ「Ｍ１」に対応する要請ノードマルチキャストＭＡＣアドレス（図１０参照）が設定され、送信元ＭＡＣアドレス９２２はノード１４のＭＡＣアドレスである「ｍ１」が設定される。
【０１０７】
ノード１４は、このＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを、その格納データを暗号鍵で暗号化して送信する。
【０１０８】
ＡＰ１２において、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、無線ＩＦ部１２１およびＰＨＹ処理部１２３を介して、ノード１４より、ＮｅｇｈｂｏｒＳｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを受信すると、ＭＡＣアドレステーブル１２７から、このＭＡＣフレームの送信元ＭＡＣアドレス「ｍ１」がフィールド１２７１に登録されているレコードを特定する。そして、特定したレコードのフィールド１２７５に登録されている認証状態が「認証済」であることを確認した後、このレコードのフィールド１２７４に登録されている暗号鍵を用いて、このＭＡＣフレームの格納データを復号化する（ＳＴ２０２３）。
【０１０９】
次に、無線ＩＦ部１２１側のＭＡＣＦＷＤ部１２４は、このＭＡＣアドレステーブル１２７から、フィールド１２７３にポート属性「ルータ」が登録されているレコードを特定し、このレコードのフィールド１２７２に登録されているポート番号に対応するＭＡＣＦＷＤ部１２４、つまり、ＰＨＹ処理部１２３を介してＬＡＮコネクタ１２２に接続されているＭＡＣＦＷＤ部１２４へ、このＭＡＣフレームを送信する。これにより、このＭＡＣフレームは、ルータ２２へ送信される（ＳＴ２０２４）。
【０１１０】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信すると、このメッセージの対象ＩＰアドレス９５２（図１１参照）が自身のＩＰアドレスと一致しているか否かを調べる。そして、一致していなければ、このメッセージを無視する（ＳＴ２０２５）。
【０１１１】
ノード１４は、アドレス重複問合せの応答であるＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを一定時間内に受信しなかった場合、自身のインタフェースＩＤがユニークであると判断し、このインターフェースＩＤと、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅメッセージにより受信したプレフィックスとを用いて、リンクローカルアドレスおよびグローバル（あるいはサイトローカル）アドレスを生成し、自身のＩＰｖ６インタフェースに割り当てる（ＳＴ２０２６）。
【０１１２】
なお、他のノード１４が送信したＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、アドレス管理テーブル１２７にてＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージの送信元ＭＡＣアドレスに対応するポート属性が「ノード」であるため、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージと同様、ポート属性が「ルータ」となっているポート番号のポート、つまり、ルータ２２にしか送出されない。このため、そのメッセージがノード１４のアドレス自動設定を妨害することはない。
【０１１３】
次に、方法Ｂについて、図１２を用いて説明する。
【０１１４】
図１２は、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加する場合、つまり方法Ｂが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスは、図９に示す方法Ａの場合と同様に、それぞれｍ１、ｌ０およびｋ０としている。なお、方法Ｂでは、ＡＰ１２に、ＩＥＥＥ８０２．１Ｘ認証のサポート機能を持たせる必要がない。
【０１１５】
先ず、ノード１４は、ＭＡＣアドレスをベースとして、インターフェースＩＤを自動生成し（ＳＴ２１０１）。その後、インターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するために、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信して、アドレス重複問合せを行う（ＳＴ２１０２）。ここで、ノード１４は、他のノード１４がＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信しないようにするために、送信ＩＰパケットに対して暗号鍵による暗号化もしくは認証を行うようにしている。また、他のノード１４からの、自身が送信したアドレス重複問合せに対するアドレス重複通知であるＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信しないようにするために、受信ＩＰパケットに対して暗号鍵による復号化もしくは認証を行うようにしている。
【０１１６】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＬＡＮコネクタ２２１からＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを格納したＭＡＣフレームを受け取ると、このＭＡＣフレームの送信元ＭＡＣアドレスがユーザ管理テーブ２２８に登録されているか否かを調べる。そして、未だ登録されていないこと、つまり、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４が認証されていないことを確認する（ＳＴ２１０３）。それから、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを生成し、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＬＡＮコネクタ２２１からＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４へ送信する（ＳＴ２１０４）。
【０１１７】
ノード１４は、ＥＡＰ−Ｒｅｑ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、これがＩＰｖ６パケットではなくＥＡＰＯＬパケットであることを認識し、したがって、暗号鍵による認証／復号を行なわずに処理する。そして、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを生成し、これに自身のユーザ名を設定してルータ２２に送信する（ＳＴ２１０５）。
【０１１８】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを受け取ると、ユーザ管理テーブル２２８にレコードを追加し、このレコードのフィールド２２８１に認証状態「認証中」を、フィールド２２８２にＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージの送信元ＭＡＣアドレス「ｍ１」を、そして、フィールド２２８５に、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージに設定されているユーザ名を登録する（ＳＴ２１０６）。
【０１１９】
それから、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを作成し、このメッセージのＣａｌｌｉｎｇ−Ｓｔａｔｉｏｎ−Ｉｄアトリビュートに、ＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージの送信元ＭＡＣアドレス「ｍ１」を、ＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、このＥＡＰ−Ｒｓｐ／Ｉｄｅｎｔｉｔｙメッセージを格納する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２からＲＡＤＩＵＳサーバ２４へ送信する（ＳＴ２１０７）。これにより、ノード１４のユーザ名とＭＡＣアドレスとを、ＲＡＤＩＵＳサーバ２４に通知する。
【０１２０】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受け取ると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを生成すると共に、認証乱数を生成し、これをＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＣｈａｌｌｅｎｇｅメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュート内のＥＡＰメッセージに設定する。それから、このＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを、ルータ２２に送信する（ＳＴ２１０８）。
【０１２１】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｃｈａｌｌｅｎｇｅメッセージを受け取ると、このメッセージに含まれている認証乱数を含んだ、ＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを作成する。そして、このメッセージを、ＬＡＮコネクタ２２１側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４へ送信する（ＳＴ２１０９）。
【０１２２】
ノード１４は、ルータ２２よりＥＡＰ−Ｒｅｑ／ＭＤ５　Ｃｈａｌｌｅｎｇｅメッセージを受信すると、このメッセージに含まれている認証乱数と、予め保持している認証鍵とを用いて認証演算を行う。そして、その結果を、ＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含めてルータ２２に送信する（ＳＴ２１１０）。
【０１２３】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、ノード１４よりＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを受信すると、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを生成し、このメッセージのＥＡＰ−Ｍｅｓｓａｇｅアトリビュートに、受信したＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージを設定する。そして、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを、ＬＡＮコネクタ２２２側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から、ＲＡＤＩＵＳサーバ２４に送信する（ＳＴ２１１１）。
【０１２４】
ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ｒｅｑメッセージを受信すると、これに設定されているＥＡＰ−Ｒｓｐ／ＭＤ５　ｒｅｓｐメッセージに含まれている認証結果を用いて、ノード１４のユーザの認証を行う。具体的には、このノード１４のユーザ名に対応付けて予め登録されている認証鍵を用いて、ＳＴ２１０８で生成した認証乱数に対し認証演算を行う。その結果がノード１４から受信したものと一致するか判定する（ＳＴ２１１２）。
【０１２５】
一致した場合は認証成功となる。この場合、ＲＡＤＩＵＳサーバ２４は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを生成し、これに、ノード１４に割り当てるプレフィックスと、ノード１４およびルータ２２間の暗号通信に利用する暗号鍵とを含めて、ルータ２２に通知する（ＳＴ２１１３）。ここで、プレフィックスは、ノード１４毎に異なる値とされ、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−ＡｃｐｔメッセージのＦｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘアトリビュートに設定される。また、暗号鍵は、ＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージの例えばＣａｌｌｂａｃｋ−Ｉｄアトリビュートに設定される。
【０１２６】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２２側のＰＨＹ処理部２２３およびＩＰＶ６処理部２２４を介して、ＲＡＤＩＵＳサーバ２４よりＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージを受信すると、このメッセージに含まれているプレフィックスおよび暗号鍵を、ＳＴ２１０６でユーザ管理テーブル２２８に追加したレコードのフィールド２２８３およびフィールド２２８４にそれぞれ登録する。また、フィールド２２８１に登録されている認証状態を「認証中」から「認証済」に変更する（ＳＴ２１１４）。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを暗号通信により送受信できるように、各部を制御する。
【０１２７】
また、ＰＲＯＣ部２２５は、登録した暗号鍵を含んだＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを生成し、ＬＡＮコネクタ２２１側のＩＰｖ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４に送信し、ノード１４に、認証が成功したことを通知する（ＳＴ２１１５）。
【０１２８】
ノード１４は、ルータ２２よりＥＡＰ−Ｓｕｃｃｅｓｓ−メッセージを受け取ると、これに含まれている暗号鍵を登録する（ＳＴ２１１６）。
【０１２９】
以上によりＩＥＥＥ８０２．１規格に従った認証が終了する。以降、ノード１４およびルータ２２は、この暗号鍵と、ＩＰｖ６パケットの認証ヘッダ／暗号ペイロードヘッダ９３３とを用いて、ＩＰｖ６パケットの認証付通信あるいは暗号通信を行なうことが可能となる。
【０１３０】
さて、ルータ２２において、ＰＲＯＣ部２２５は、ＲＡＤＩＵＳサーバ２４より受信したＲＡＤＩＵＳ　Ａｃｃｅｓｓ−Ａｃｐｔメッセージに含まれていたプレフィックスを、このプレフィックスが割り当てられるノード１４に通知するため、ルータ広告であるＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これを、宛先ＭＡＣアドレス「ｍ１」、宛先ＩＰアドレス「全ノードマルチキャストＩＰアドレス」として、ＬＡＮコネクタ２２１側のＩＰＶ６処理部２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１からノード１４に送信する（ＳＴ２１１７）。
【０１３１】
ノード１４は、宛先ＭＡＣアドレスが自身のＭＡＣフレームを受信すると、このフレームからＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージを得る。そして、このメッセージに含まれている自身専用のプレフィックスを入手する。また、このメッセージの送信元ＩＰアドレスおよび送信元ＭＡＣアドレスを、デフォルトルータとして認識する（ＳＴ２１１８）。
【０１３２】
さて、ノード１４は、ＩＥＥＥ８０２．１規格に従った認証が終了した後、ＳＴ２００１で生成したインターフェースＩＤが同一リンク（サブネット）内でユニークであるか否かを確認するためのＮｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを生成し送信して、アドレス重複問合せを行う（ＳＴ２１１９）。
【０１３３】
ルータ２２において、ＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを受信すると、このメッセージを格納したＭＡＣフレームの送信元ＭＡＣアドレスがユーザ管理テーブ２２８に登録されているか否かを調べる。そして、既に登録されていないこと、つまり、Ｎｅｇｈｂｏｒ　Ｓｏｌｏｃｉｔメッセージを送信したノード１４が認証されていることを確認する（ＳＴ２１２０）。それから、このメッセージの対象ＩＰアドレス９５２（図１１参照）が自身のＩＰアドレスと一致しているか否かを調べる。そして、一致していなければ、このメッセージを無視する（ＳＴ２１２１）。
【０１３４】
ノード１４は、アドレス重複問合せの応答であるＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを一定時間内に受信しなかった場合、自身のインタフェースＩＤがユニークであると判断し、このインターフェースＩＤと、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅメッセージにより受信したプレフィックスとを用いて、リンクローカルアドレスおよびグローバル（あるいはサイトローカル）アドレスを生成し、自身のＩＰｖ６インタフェースに割り当てる（ＳＴ２１２２）。
【０１３５】
なお、以上説明した方法Ａおよび方法Ｂのいずれの方法においても、ＡＰ１２が有線でノード１４と接続するＬ２ＳＷである場合は、ノード１４間の通信をＬ２ＳＷで禁止するようにしてもよい。この場合、ノード１４が送信するフレームを他のノード１４が傍受することはできない。したがって、ノード１４−Ｌ２ＳＷ間（方法Ａ）、あるいは、ノード１４−ルータ２２（方法Ｂ）間の通信を暗号化する必要がなくなる。
【０１３６】
以上、本発明の第１実施形態について説明した。
【０１３７】
本実施形態では、ノード１４の各々に異なるグローバル（サイトローカル）アドレス用プレフィックスを付与することにより、各リンクローカル内に１つのノードが属するようにしている。このため、本来はＩＰアドレスおよびＭＡＣアドレスの双方が共にマルチキャストであるルータ広告を、特定のノード１４に対して、そのノード１４のＩＰアドレスが不明でも送達できる。これにより、そのノード１４に、当該ノード専用のプレフィックスを割当てることができる。そして、各ノード１４に専用のプレフィックスを割当てれば、ノード間でのインタフェースＩＤの重複は発生しない。したがって、本実施形態によれば、各ノード１４のＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。
【０１３８】
また、本実施形態では、ノード１４毎に、固有の暗号鍵を用いて、ノード１４およびＡＰ１２あるいはルータ２２間の通信を行なうようにしている。このようにすることで、ノード１４がルータ２２以外の他ノード１４と直接通信できないようにすることができ、したがって、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【０１３９】
次に、本発明の第２実施形態について説明する。
【０１４０】
図１３は、本発明の第２実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示したものである。
【０１４１】
図示するように、本実施形態では、図８に示す第１実施形態と異なり、ＡＰ１２配下の全てのノード１４を１つのリンク（サブネット）５０に収容するようにしている。なお、本実施形態の公衆無線ＬＡＮアクセスサービスシステムは、図１に示す第１実施形態のものと基本的に同様である。ただし、図１４に示すように、本実施形態のルータ２２では、ＰＲＯＣ部２２５に、ユーザ管理テーブル２２８に代えてＩＰアドレス管理テーブル２２９が保持される。
【０１４２】
図１５に、ＩＰアドレス管理テーブル２２９の登録内容例を示す。図示するように、ＩＰアドレス管理テーブル２２９は、ノード１４のＩＥＥＥ８０２．１Ｘ規格による認証の状態を登録するフィールド２２９１と、ノード１４のＭＡＣアドレスを登録するためのフィールド２２９２と、ノード１４がルータ２２と暗号通信を行なう場合に使用する暗号鍵を登録するためのフィールド２２９４と、このノード１４のユーザ名を登録するフィールド２２９５と、複数のＩＰアドレスを管理するための使用中ＩＰアドレステーブル２２９７に登録されている、使用中ＩＰアドレスへのポインタを登録するためのフィールド２２９６と、を備えて１つのレコードが登録されている。
【０１４３】
本実施形態では、ＡＰ１２配下の全てのノード１４が同じリンクに属するため、ルータ２２が全ての使用中ＩＰアドレスを監視して、ユニーク性を保証する必要がある。使用中ＩＰアドレステーブル２２９７は、ノード１４のアドレス自動設定完了後、ＩＰ通信を開始する際のＩＰアドレス解決時に、ＮｅｉｇｈｂｏｒＣａｃｈｅと共に更新される。
【０１４４】
Ｎｅｉｇｈｂｏｒ　Ｃａｃｈｅは、ＩＰアドレスとＭＡＣアドレスとの対応リストであり、その更新方法はＲＦＣ２４６１に記載されている。ただし、ＲＦＣ２４６１では、Ｎｅｉｇｈｏｒ　Ｃａｃｈｅに対し、登録済みのＩＰアドレスに対応するＭＡＣアドレスの上書きは可能であるとしている。しかし、本実施形態では、この上書きを禁止とし、タイムアウトによるエントリ削除あるいは後述の不正ＩＰアドレス使用禁止のためのエントリ強制削除によってのみ、ＭＡＣアドレスの変更ができるようにしている。
【０１４５】
本実施形態においても、上記の第１実施形態と同様に、ノード１４が送信するＩＰｖ６パケットが他のノード１４に届かないようにする方法として、ノード１４およびＡＰ１２間の通信をノード１４毎に異なる暗号鍵で暗号化することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする方法（方法Ａ）、および、ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加することにより、ノード１４が、ルータ２２が送信するパケット以外のパケットを認識（復号）できないようにする、もしくは不正パケットとして無視するようにする方法（方法Ｂ）のいずれかを採用している。
【０１４６】
ここでは、方法Ａを例に取り説明する。
【０１４７】
図１６は、ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合、つまり方法Ａが適用される場合における本実施形態の動作手順を説明するためのシーケンス図である。ここでも、図９の場合と同様に、ノード１４、ＡＰ１２およびルータ２２のＭＡＣアドレスを、それぞれｍ１、ｌ０およびｋ０としている。
【０１４８】
図１６において、ＳＴ２２０１〜ＳＴ２２１９は、図９のＳＴ２００１〜ＳＴ２０１９と基本的に同様である。
【０１４９】
ただし、本実施形態では、上述したように、ルータ２２にユーザ管理テーブル２２８に代えてＩＰアドレス管理テーブル２２９を設けている。したがって、ＳＴ２２０７において、ＩＰアドレス管理テーブル２２９に新たなレコードが追加され、このレコードのフィールド２２９１に認証状態「認証中」が、フィールド２２９２にノード１４のＭＡＣアドレスが、そして、フィールド２２９５にノード１４のユーザのユーザ名が登録される。
【０１５０】
また、本実施形態では、上述したように、ＡＰ１２配下の全ノード１４に対して同じプレフィックスを割り当てている。つまり、ノード１４毎に異なるプレフィックスを割当てることはしない。このため、ＳＴ２２１４において、ＲＡＤＩＵＳサーバ２４によるプレフィックスの割当て通知は行わない。その代わり、ルータ２２に、ＡＰ１２毎に、ＡＰ１２配下のノード１４に割り当てるプレフィックスを管理させるようにする。また、ＳＴ２２１５において、フレフィックスの登録は行なわない。ＳＴ２２０７でＩＰアドレス管理テーブル２２９に追加したレコードのフィールド２２９１に登録されている認証状態を「認証中」から「認証済」に変更する。これにより、ＰＲＯＣ部２２５は、このノード１４のＭＡＣアドレスを送信元あるいは宛先とするＭＡＣフレームを送受信できるように、各部を制御する。
【０１５１】
次に、図１６において、ＳＴ２２２０〜ＳＴ２２２４も、図９のＳＴ２０２０〜ＳＴ２０２４と基本的に同様である。ただし、本実施形態では、上述したように、ＡＰ１２配下の全ノード１４に対して同じプレフィックスを割り当てている。このため、ＳＴ２２２０において、ルータ２２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＭＡＣアドレスを、全ノードマルチキャストＭＡＣアドレスとしている。これにより、ＡＰ１２配下の全てのノード１４に同一のプレフィックスを通知する。
【０１５２】
なお、ＳＴ２２２０において、ＡＰ１２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージをノード１４へ送信する場合、これを各ノード１４に固有の暗号鍵で暗号化することはしない。暗号化を行なわないか、あるいは、ＡＰ１２配下の全ノード１４に共通の暗号鍵（マルチキャスト用暗号鍵）で暗号化する。
【０１５３】
一方、ＳＴ２２２２において、ノード１４は、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信する場合、図９のＳＴ２０２２と同様に、ノード１４に固有の暗号鍵で暗号化する。
【０１５４】
さて、第１実施形態では、ノード１４毎に異なるプレフィックスを割り当てているため、ノード１４のＩＰアドレスがルータ２２のＩＰアドレスと重複していないことを確認すればよい。このため、図９のＳＴ２０２５に示すように、ルータ２２は、ノード１４がアドレス重複問合せのために送信したＮｅｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージのうち、対象ＩＰアドレスが自身のＩＰアドレスでないものを無視していた。これに対し、本実施形態では、ノード１４がアドレス重複問合せのために送信した全てのＮｅｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを考慮し、ルータ２２が、同一リンク内でのアドレス重複を判定するようにしている。
【０１５５】
図１７は、ノード１４が送信したアドレス重複問合せのためのＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを、ルータ２２が受信した以降の動作手順、つまり図１６の続きを説明するためのシーケンス図である。
【０１５６】
図１７（ａ）において、ルータ２２のＰＲＯＣ部２２５は、ＬＡＮコネクタ２２１側のＰＨＹ処理部２２３およびＩＰｖ６処理部２２４を介して受信したＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元アドレスにアドレス重複問合わせであることを示す「０」が設定されていることを確認する（ＳＴ２２５１）。それから、このメッセージの送信元ＭＡＣアドレスと、このメッセージに格納されている対象ＩＰアドレスとの関係が、図１０に示すＭＡＣアドレス９０１とリンクローカルアドレス９０３との関係になっているか否かを調べる（ＳＴ２２５２）。そのような関係になっている場合、このメッセージに格納されている対象ＩＰアドレスは、ＭＡＣアドレスから自動生成したアドレスである。この場合、このアドレスを正当なアドレスと判定する。ノード１４に対して、何も応答を返さない。その結果、ノード１４は、対象ＩＰアドレスに設定したアドレスをリンクローカルアドレスに正式採用する。これにより、アドレス自動設定を成功させる（ＳＴ２２５６）。
【０１５７】
なお、既にこのＩＰアドレスを使用している他のユーザ（ノード）が存在する場合、そのユーザにこのＩＰアドレスの使用を禁止させる必要がある。そこで、ＰＲＯＣ部２２５は、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードを検索する（ＳＴ２２５３）。そのようなレコードが検出されなかった場合、このＩＰアドレスを使用している他のユーザは存在しないことになるので、処理を終了する。一方、そのようなレコードが検出された場合、ＩＰアドレス管理テーブル２２９から検出したレコードを削除すると共に、Ｎｅｉｇｈｂｏｒ　Ｃａｃｈｅから、検出したレコードのフィールド２２９２に登録されているＭＡＣアドレスとこのＩＰアドレスとの対応関係を削除する（ＳＴ２２５４）。また、削除したレコードの情報を含む重複報告メッセージを作成し、これをＬＡＮコネクタ２２２側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から管理装置２８に送信する（ＳＴ２２５５）。
【０１５８】
一方、ＳＴ２２５２において、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスと、このメッセージに格納されている対象ＩＰアドレスとの関係が、図１０に示すＭＡＣアドレス９０１とリンクローカルアドレス９０３との関係になっていない場合、このメッセージに格納されている対象ＩＰアドレスは、ＭＡＣアドレスから自動生成したアドレスではない。この場合、このアドレスを、使用中のユーザ（ノード）が存在しない場合に限って認める正当でないアドレスと判定し、図１７（ｂ）のＳＴ２２６１に進む。
【０１５９】
図１７（ｂ）のＳＴ２２６１において、ルータ２２のＰＲＯＣ部２２５は、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、ＮｅｉｇｈｂｏｒＳｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードを検索する。そのようなレコードが検出された場合、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスを宛先ＭＡＣアドレスに設定したＮｅｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを生成し、これをＬＡＮコネクタ２２１側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から送信する（ＳＴ２２６２）。
【０１６０】
図１１に示すように、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、ＩＣＭＰタイプ９６１が「１３６」のＩＣＭＰパケット９６０である。対象ＩＰアドレス９６２と、この対象ＩＰアドレスを使用中のノード１４のＭＡＣアドレスが設定された対象リンクレイヤアドレスオプション９６３と、を含む。なお、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＩＰアドレスは、全ノードマルチキャストＩＰアドレスである。しかし、宛先ＭＡＣアドレスにＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージの送信元ＭＡＣアドレスが設定されているため、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージは、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信したノード１４に送信される。ノード１４は、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信すると、アドレス自動設定を失敗とする（ＳＴ２２６４）。
【０１６１】
また、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに含まれていた情報を含む重複報告メッセージを作成し、これをＬＡＮコネクタ２２２側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２２から管理装置２８に送信する（ＳＴ２２６３）。
【０１６２】
一方、ＳＴ２２６１において、ＩＰアドレス管理テーブル２２９から、フィールド２２９６に、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに格納されている対象ＩＰアドレスへのポインタが登録されているレコードが検出されなかった場合、このＩＰアドレスを使用している他のユーザは存在しないことになる。この場合、このＩＰアドレスの使用を許可するべく、図１７（ｃ）のＳＴ２２７１に進む。
【０１６３】
図１７（ｃ）のＳＴ２２７１において、ルータ２２のＰＲＯＣ部２２５は、使用を許可するＩＰアドレスを対象ＩＰアドレスとし、送信元ＩＰアドレスをルータ２２のＩＰアドレスとしたＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを生成する。そして、これをＬＡＮコネクタ２２１側のＩＰｖ６処理装置２２４およびＰＨＹ処理部２２３を介して、ＬＡＮコネクタ２２１から送信する。このＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージは、送信元ＩＰアドレスが「０」でないので、アドレス解決問合せを意味する。このため、アドレス自動設定中のノード（ＭＡＣアドレス「ｍ１」）がこのメッセージを受信しても、ＲＦＣ２４６に従い、このメッセージを無視する（ＳＴ２２７２）。
【０１６４】
ここで、ＭＡＣアドレス「ｍ２」のノード１４がＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに設定されている対象ＩＰアドレスを使用中であると仮定する。このノード１４は、Ｎｅｇｈｂｏｒ　Ａｄｅｖｒｔｉｓｅメッセージをルータ２２に送信する（ＳＴ２２７３）。これを受けて、ルータ２２は、図１７（ｂ）のＳＴ２２６１で対象ＩＰアドレスがＩＰアドレス管理テーブル２２９に登録済みの場合と同様の処理を行う。
【０１６５】
なお、ＳＴ２２７１で送信したＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージに対する応答として、ルータ２２配下のノード１４からＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅメッセージを受信していない場合、ルータ２２は、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを送信したノード１４に対して、何も応答を返さない。その結果、このノード１４は、対象ＩＰアドレスに設定したアドレスをリンクローカルアドレスに正式採用する。これによりアドレス自動設定を成功させる。
【０１６６】
以上、方法Ａを例に取り説明したが、方法Ｂを本実施形態に適用する場合も、第１実施形態（図９）および第２実施形態（図１６、図１７）間における方法Ａの変更内容を、図１２に示す方法Ｂを用いた第１実施形態に適用することで実現できる。つまり、図１２に以下の変更点を加えればよい。
【０１６７】
（１）ＳＴ２１０６において、ＩＰアドレス管理テーブル２２９に新たなレコードが追加され、このレコードのフィールド２２９１に認証状態「認証中」が、フィールド２２９２にノード１４のＭＡＣアドレスが、そして、フィールド２２９５にノード１４のユーザのユーザ名が登録される。
【０１６８】
（２）ＳＴ２１１３において、ＲＡＤＩＵＳサーバ２４によるプレフィックスの割当て通知は行わなない。その代わり、ルータ２２に、ＡＰ１２毎に、ＡＰ１２配下のノード１４に割り当てるプレフィックスを管理させる。
【０１６９】
（３）ＳＴ２１１４において、フレフィックスの登録は行なわない。ＳＴ２１０６でＩＰアドレス管理テーブル２２９に追加したレコードのフィールド２２９１に登録されている認証状態を「認証中」から「認証済」に変更する。
【０１７０】
（４）ＳＴ２１１７において、ルータ２２は、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅメッセージの宛先ＭＡＣアドレスを、全ノードマルチキャストＭＡＣアドレスとする。
【０１７１】
（５）ノード１４が送信したアドレス重複問合せのためのＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔメッセージを、ルータ２２が受信した以降の動作手順に、図１７で説明した動作手順が適用される。
【０１７２】
なお、本実施形態においても、ＡＰ１２が有線でノード１４と接続するＬ２ＳＷである場合は、ノード１４間の通信をＬ２ＳＷで禁止するようにしてもよい。この場合、ノード１４が送信するフレームを他のノード１４が傍受することはできない。したがって、ノード１４−Ｌ２ＳＷ間（方法Ａ）、あるいは、ノード１４−ルータ２２（方法Ｂ）間の通信を暗号化する必要がなくなる。
【０１７３】
以上、本発明の第２実施形態について説明した。
【０１７４】
本実施形態では、ノード１４毎に、固有の暗号鍵を用いて、ノード１４およびＡＰ１２あるいはルータ２２間の通信を行なうようにしている。また、ルータ２２に、認証に成功した各ノード１４のＩＰアドレス、ＭＡＣアドレスおよびユーザ名を管理させると共に、あるノード１４がアドレス重複問合せを行った場合に、対象ＩＰアドレスが他のノード１４で使用中であるか否かを判定させ、使用中である場合は、アドレス重複通知を行なわせる。あるいは、対象ＩＰアドレスとアドレス重複問合せを行ったノードのＭＡＣアドレスとを比較させ、対象ＩＰアドレスがＭＡＣアドレスベースで生成されたものか否かを判定させる。そして、ＭＡＣアドレスベースで生成されたものでない場合は、アドレス重複通知を行なわせる。このため、各ノード１４のＩＰｖ６アドレスのユニーク性を保証でき、ＩＰｖ６の特徴である自動コンフィグレーションを有効活用できる。また、ノード１４がルータ２２以外の他ノード１４と直接通信できないようにすることができ、したがって、悪意を持ったノードの存在によりネットワークアクセスできなくなる可能性を低減できる。
【０１７５】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１７６】
例えば、図１に示した公衆無線ＬＡＮアクセスサービスシステムにおいて、ＡＰ１２およびＡＤＳＬモデム１６は、一体化されたものであってもよい。また、ＩＳＰ２０内にルータ２２やＲＡＤＩＵＳサーバ２４やＧＷ２６や管理装置２８は、いずれか２つ以上が同じコンピュータシステム上に構築されていてもよいし、それぞれが別々のコンピュータシステム上に構築されていてもよい。
【０１７７】
また、上記の実施形態では、本発明の公衆無線ＬＡＮアクセスサービスシステムに適用した場合を例に取り説明しているが、本発明は、ＩＰｖ６において、ＬＡＮによりＰＰＰを使用しないでホストを収容するシステムに広く適用できる。例えば、ＬＡＮによりＰＰＰを使用しないでホストを収容する、加入者宅からのＩＰｖ６ネットワークアクセスサービスシステムにも、同様に適用できる。
【０１７８】
【発明の効果】
以上説明したように、本発明によれば、ＩＰｖ６においてＬＡＮによりＰＰＰを使用しないでホストを収容する場合でも、ＩＰｖ６の特徴である自動コンフィギュレーションを有効活用することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態が適用される公衆無線ＬＡＮアクセスサービスシステムの概略図を示す図である。
【図２】図１に示すＡＰ１２の概略構成図である。
【図３】図２に示すＭＡＣアドレステーブル１２７の登録内容例を示す図である。
【図４】図１に示すルータ２２の概略構成図である。
【図５】図４に示すユーザ管理テーブル２２８の登録内容例を示す図である。
【図６】図１に示す管理装置２８の概略図である。
【図７】図６に示す管理装置２８のハードウエア構成例を示す図である。
【図８】本発明の第１実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示した図である。
【図９】ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合における、本発明の第１実施形態の動作手順を説明するためのシーケンス図である。
【図１０】ＭＡＣアドレスと、ＭＡＣアドレスをベースとして自動生成されるインタフェースＩＤとの関係を示す図である。
【図１１】本発明の第１実施形態で用いるＩＰｖ６パケットを格納したＭＡＣフレームのフォーマット構成例を示す図である。
【図１２】ノード１４およびルータ２２間の通信をノード１４毎に異なる暗号鍵で暗号化もしくは認証情報を付加する場合における、本発明の第２実施形態の動作手順を説明するためのシーケンス図である。
【図１３】本発明の第２実施形態の公衆無線ＬＡＮアクセスサービスシステムを、ノード１４を収容するリンク（サブネット）に注目し単純化して示した図である。
【図１４】本発明の第２実施形態で用いられるルータ２２の概略構成図である。
【図１５】図１４に示すＩＰアドレス管理テーブル２２９の登録内容例を示す図である。
【図１６】ノード１４毎に異なる暗号鍵で暗号化してノード１４およびＡＰ１２間の通信を行なう場合における、本発明の第２実施形態の動作手順を説明するためのシーケンス図である。
【図１７】本発明の第２実施形態において、図１６の続きの動作手順を説明するためのシーケンス図である。
【図１８】ＩＰｖ６の自動コンフィギュレーションの動作手順を説明するためのシーケンス図である。
【符号の説明】
１０…スポット、１２…ＡＰ、１４…ノード、１６…ＡＤＳＬモデム、２０…ＩＳＰ、２２…ルータ、２４…ＲＡＤＩＵＳサーバ、２６…ＧＷ、２８…管理装置、３０…ＤＳＬＡＭ、４０…ＩＰｖ６ネットワーク、１２１…無線ＩＦ部、１２２…ＬＡＮコネクタ、１２３…ＰＨＹ処理部、１２４…ＭＡＣＦＷＤ部、１２５…ＰＲＯＣ部、１２６…バス、１２７…ＭＡＣアドレステーブル、２２１…ＬＡＮコネクタ、２２２…ＬＡＮコネクタ、２２３…ＰＨＹ処理部、２２４…ＩＰｖ６処理部、２２５…ＰＲＯＣ部、２２６…バス、２２７…ルーティングテーブル、２２８…ユーザ管理テーブル、２２９…ＩＰアドレス管理テーブル[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an IPv6 node network connection technology.
[0002]
[Prior art]
With regard to IPv6 (Internet Protocol Version 6), RFC 2461 of the IETF (The Internet Engineering Task Force) standard, “Neighbor Discovery for IP Version 6 (IPv6), and RFC 2463 for IPv6” A procedure (automatic configuration) for automatically performing the minimum configuration required for communication is specified.
[0003]
FIG. 18 is a sequence diagram for explaining the operation procedure of IPv6 automatic configuration. As shown, the automatic configuration includes three stages ST1001 to ST1003.
[0004]
(1) ST1001: provisional determination of link local address
First, the node generates an interface ID based on a MAC (Media Access Control) address. A method of generating an interface ID from a MAC address is defined in RFC 2373 “IP Version 6 Addressing Architecture”. Then, a fixed prefix for a link local address is added to this interface ID, and this is provisionally determined as a link local address which is an IP address that can be used only within the link (subnet).
[0005]
(2) ST1002: Formal determination of link local address
Next, the node inquires in a link whether or not the provisionally determined link local address has already been used in the same link by an ICMP (Internet Control Message Protocol) message in the link (address duplication inquiry: Neighbor Solicit). Here, the source address of the address duplication inquiry is 0 (srcIPaddr = 0). Then, if there is no response (address overlap notification: Neighbor Advertise) from another node in the link within the specified time, the provisionally determined link local address is formally adopted.
[0006]
If another node in the link responds, it is already using the same link local address. The node that has performed the address duplication inquiry cannot use this link local address. That is, automatic configuration fails. A node that has made an address duplication inquiry cannot perform IP communication unless an appropriate IPv6 address is assigned to the node due to user intervention or the like.
[0007]
(3) ST1003: Determination of Global (Site Local) Address
Next, the node receives a router advertisement (Router Advertise) that the router periodically advertises in a link by multicast using an Internet Control Message Protocol (ICMP) message. Then, the node determines the global (site-local) address necessary for IP communication beyond the router by obtaining the global (site-local) address prefix from the router advertisement and adding this to the officially adopted link-local address. I do.
[0008]
The prefix for the global (site-local) address is guaranteed to be unique within the global (site-local). This allows the node to perform global (site-local) IP communication via the router. By receiving the router advertisement, the node learns the MAC address and the IPv6 address of the router.
[0009]
As described above, one of the advantages of IPv6 is that the minimum configuration required for the node to perform the IP communication can be automatically performed without user intervention.
[0010]
By the way, a public wireless LAN access service is one of the access services realized by the current mainstream IPv4 (Internet Protocol Version 4).
[0011]
In a public wireless LAN access service, an AP (Access Point), which is a base station of a wireless LAN that operates as a bridge, is installed in a coffee shop or a station, and is connected to an ISP (Internet Service Provider) to establish a connection with the wireless LAN. This realizes Internet access of a host having an interface.
[0012]
In the public wireless LAN access service, as a method for accommodating a host, a method of establishing a point-to-point protocol (PPP) between a host and an ISP, and a method of establishing a PPP by a LAN (Local Area Network, IEEE802.3 series network). There is a method of accommodating a host without using a host.
[0013]
The latter has advantages over the former in that the overhead at the start of IP communication is small and that the network can be easily accessed with the same settings as in a normal LAN connection. In the latter case, the host is authenticated using the 802.1X standard defined by the IEEE 802.11 committee. The IEEE 802.1X standard is a protocol that allows a bridge to authenticate a node that has accessed the bridge and then allow the node to transmit and receive a MAC frame (IEEE 802.3 series frame). In the public wireless LAN access service, an AP requests and obtains a user name and a password from a node, and transmits them to a RADIUS (Remote Authentication Dial-In User Service) server to request authentication. Then, the AP controls the network access of the node based on the authentication result in the RADIUS server.
[0014]
[Problems to be solved by the invention]
By the way, in IPv6, when an attempt is made to realize a public wireless LAN access service by using a method of accommodating a host without using a PPP by a LAN, how to accommodate a node while taking advantage of the automatic configuration characteristic of IPv6. The problem is whether to increase the availability of the link (subnet) to be used.
[0015]
For example, in ST1002 of FIG. 18, another node in the link responds to the address duplication inquiry performed by a certain node and performs address duplication notification, thereby prohibiting the certain node from using this address. be able to. For this reason, automatic configuration may not be successful due to the presence of a malicious node.
[0016]
Also, in ST1003 of FIG. 18, a certain node other than the router performs router advertisement, so that the node other than this node recognizes the node that has performed router advertisement as a router and attempts network access. For this reason, network access may not be possible due to the presence of a malicious node.
[0017]
These problems also occur when an Internet access service from a subscriber's home is realized by using a method of accommodating a host without using PPP by a LAN in IPv6.
[0018]
The present invention has been made in view of the above circumstances, and an object of the present invention is to solve a problem that occurs in IPv6 when a host is accommodated in a LAN without using PPP. For example, it is to enable automatic configuration, which is a feature of IPv6, to be effectively used. Another object of the present invention is to reduce the possibility that network access is disabled.
[0019]
[Means for Solving the Problems]
In order to solve the above-mentioned problems, the present invention provides a router in IPv6 by assigning an address to each node so that addresses do not overlap between nodes. Accommodates nodes without using PPP.
[0020]
For example, by assigning a different global (site-local) address prefix to each of the nodes, one node belongs to each link-local. Specifically, a router advertisement ICMP message in which a unique prefix is set for each node is generated, and the ICMP message is stored in an IPv6 packet in which a multicast IP address is set as a destination IP address. Further, this IPv6 packet is stored in a MAC frame in which the MAC address of the IPv6 node to which the unique prefix is to be set in the destination MAC address is transmitted to the LAN. The MAC address of the node may be obtained through authentication of the node (authentication according to the IEEE 802.1X standard).
[0021]
In this way, a router advertisement in which both the IP address and the MAC address are both multicast can be delivered to a specific node even if the IP address of the node is unknown. Thus, a prefix dedicated to the node can be assigned to the node. Then, if a dedicated prefix is assigned to each node, duplication of the interface ID between the nodes does not occur. Therefore, the uniqueness of the IPv6 address of each node can be guaranteed, and the automatic configuration which is a feature of IPv6 can be effectively used.
[0022]
Further, in order to solve the above problem, in the present invention, notification of address duplication between nodes is prohibited. For example, the communication between the router and the node, or the communication between the bridge connecting the router and the node and the node is performed using the encryption key unique to the node. This prevents the node from directly communicating with other nodes other than the router. Furthermore, in the present invention, the IP address and the MAC address of each node that has succeeded in authentication (authentication according to the IEEE 802.1X standard) are managed. Then, when an address duplication inquiry is received from a certain node, it is determined whether or not the target IP address of the inquiry is being used by another IPv6 node. If the node is in use, an address duplication notification is sent to the inquired node. When there is an address duplication inquiry for the IP address in use, the router may notify the network management apparatus to manage which user has the address duplication.
[0023]
By doing so, the uniqueness of the IPv6 address of each node can be guaranteed, and the automatic configuration which is a feature of IPv6 can be effectively used. Further, it is possible to reduce the possibility that network access becomes impossible due to the presence of a malicious node.
[0024]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described.
[0025]
First, a first embodiment of the present invention will be described.
[0026]
FIG. 1 is a schematic diagram of a public wireless LAN access service system to which the first embodiment of the present invention is applied.
[0027]
As shown in the figure, an AP 12 that is a wireless LAN base station that operates as a bridge is installed for each spot 10 such as a coffee shop or a station. An IPv6-compatible node 14 having a wireless communication function, such as a wireless LAN card, performs wireless communication with an AP 12 installed at a spot 10 where the node 14 is located. Communication standards used for the wireless communication include IEEE802.11b and IEEE802.11a.
[0028]
The AP 12 connects the node 14 located at the spot 10 where the AP 12 is installed to the ISP 20 that provides an access service to the IPv6 network 40. In the present embodiment, the node 14 is accommodated in the ISP 20 without using the PPP via the LAN. Therefore, communication is performed between the ISP 20 and the node 14 by the MAC frame.
[0029]
In the present embodiment, an ADSL (Asymmetric Digital Subscriber Line) line is assumed as an access line for connecting the AP 12 to the ISP 20. Therefore, the AP 12 is connected to the ADSL modem 16 via a LAN cable such as 10Base-T, and the ADSL modem 16 is connected to a DSLAM (Digital Subscriber Line Access Multiplexer) 30 via a telephone line (metal line). Then, the DSLAM 30 is connected to the router 22 in the ISP 20 by a LAN cable such as 100Base-TX. However, the access line for connecting the AP 12 to the ISP 20 is not limited to the ADSL line, but may use an optical fiber or the like.
[0030]
The ISP 20 includes a router 22 for accommodating the node 14 without using the PPP via the LAN, a RADIUS server 24 for authenticating the user of the node 14 according to the IEEE 802.1X standard, and a GW (gateway) for connecting the router 22 to the IPv6 network 40. 26 and a management device 28 for managing the maintenance information of the router 22 are connected by LAN.
[0031]
In the above configuration, the user of the node 14 makes a contract with the operator of the ISP 20. Then, the operating company of the ISP 20 registers the user name and password of the contracted user in the RADIUS server 24.
[0032]
Now, when the user of the node 14 visits a spot 10 and starts a network connection to the IPv6 network 40 using the node 14, the authentication according to the IEEE 802.1X standard is started. First, the AP 12 requests and obtains a user name and a password from the node 14 that has started the network connection. Then, the obtained user name and password are transferred to the RADIUS server 24, and authentication is requested. Next, upon receiving the authentication result from the RADIUS server 24, the AP 12 relays the communication between the node 14 and the router 22 if the authentication is successful. As a result, the node 14 can access the IPv6 network 40 via the AP 12, the router 22, and the GW 26.
[0033]
Although the description has been made here assuming that communication between the node 14 and the AP 12 is performed by wireless communication, it is needless to say that the communication may be performed by connecting the node 14 and the AP 12 with a LAN cable. .
[0034]
FIG. 2 is a schematic configuration diagram of the AP 12.
[0035]
As shown, the AP 12 includes a wireless IF (interface) unit 121 for performing wireless communication with the node 14, a LAN connector 122 for connecting a LAN cable from the ADSL modem 16, a wireless IF unit 121 and a LAN connector. 122, a PHY (physical layer) processing unit 123 for processing a physical layer of a signal transmitted / received to / from the corresponding wireless IF unit 121 or LAN connector 122 provided for each of the PHY processing units 122, It has a MACFWD unit 124 that performs processing for controlling transmission and reception of MAC frames between the node 14 and the router 22, and a PROC unit 125 that controls IEEE 802.1X messages. Each MACFWD unit 124 and PROC unit 125 are connected by a bus 126.
[0036]
The MACFWD unit 124 has, for each MAC address, a MAC address table 127 for registering the device to which the MAC address is assigned and the information of the MACFWD unit 124 that relays the MAC frame to the device.
[0037]
FIG. 3 shows an example of registration contents of the MAC address table 127. As shown in the figure, the MAC address table 127 includes a field 1271 for registering a MAC address, a field 1272 for registering a port number indicating a connection port with a device to which the MAC address is assigned, and a connection port A field 1273 for registering a port attribute indicating an attribute of a device connected to the device, a field 1274 for registering an encryption key used for communication with the device to which the MAC address is assigned, and a One record is formed with a field 1275 for registering the necessity of authentication according to the IEEE 802.1X standard for communication with the specified device and, if necessary, an authentication status indicating the status.
[0038]
For example, in the record in which the MAC address given to the router 22 is registered in the field 1271, the connection port number with the router 22 is registered in the field 1272, the port attribute “router” is registered in the field 1273, and In 1275, an authentication state "authentication unnecessary" indicating that authentication based on the IEEE 802.1X standard is unnecessary is registered. If encryption is not required for communication with the router 22, no encryption key is registered in the field 1274.
[0039]
In the record in which the MAC address given to the node 14 is registered in the field 1271, the connection port number with the node 14 is registered in the field 1272, the port attribute “node” is registered in the field 1273, and In the field 1275, the authentication status “authenticated” is registered if the authentication according to the IEEE 802.1X standard is being executed, and the authentication status “authenticated” is registered if the authentication has been executed. Then, when the field 1275 changes from “under authentication” to “authenticated”, communication with the node 14 is performed using the encryption key registered in the field 1274.
[0040]
When receiving the MAC frame from the corresponding PHY processing unit 123, the MACFWD unit 124 searches the MAC address table 127 for a record in which the source MAC address of the MAC frame is registered in the field 1271. If the port attribute registered in the field 1273 of the detected record (referred to as the record of interest) is “node”, the following processing is performed.
[0041]
That is, it is determined whether or not the authentication status registered in the field 1275 of the record of interest is “authenticated”. In the case of “authenticated”, if an encryption key is registered in the field 1274, the storage data of the MAC frame is decrypted using this encryption key. Then, a record in which the port attribute “router” is registered in the field 1273 is specified, and the LAN connector is connected via the MACFWD unit 124, that is, the PHY processing unit 123, corresponding to the port number registered in the field 1272 of this record. The MAC frame is transmitted to the MACFWD unit 124 connected to the 122. If the encryption key is not registered in field 1274 of the record of interest, this MAC frame is transmitted to MACFWD section 124 connected to LAN connector 122 via PHY processing section 123 without performing decryption processing. On the other hand, if the authentication state registered in the field 1275 of the record of interest is “authenticating”, the destination MAC address of this MAC frame is checked, and if the MAC address of the AP 12 or the port access entity is The frame is transferred to the PROC unit 125. Otherwise, this MAC frame is discarded.
[0042]
If the port attribute registered in the field 1273 of the record of interest is “router”, the MACFWD unit 124 performs the following processing.
[0043]
That is, the destination MAC address of this MAC frame is checked, and the record identifies the record registered in the field 1271. The MAC frame is transmitted to the MACFWD unit 124 corresponding to the port number registered in the field 1272 of the specified record, that is, the MACFWD unit 124 connected to the wireless IF unit 121 via the PHY processing unit 123. I do.
[0044]
If the target record cannot be detected, that is, if the record in which the source MAC address of the MAC frame is registered in the field 1271 does not exist in the MAC address table 127, a new record is added. , The source MAC address, the receiving port number in the field 1272, the port attribute “node” in the field 1273, and the authentication state “in-authentication” in the field 1275.
[0045]
When the MACFWD unit 124 receives a MAC frame from another MACFWD unit 124 via the bus 126, the MACFWD unit 124 searches the MAC address table 127 for a record in which the transmission destination MAC address of the MAC frame is registered in the field 1271. If the encryption key is registered in the field 1274 of the detected record, the data stored in the MAC frame is encrypted using this encryption key, and then transmitted to the corresponding PHY processing unit 123. If the encryption key is not registered, this MAC frame is transmitted to the corresponding PHY processing unit 123 without performing the encryption process.
[0046]
The PROC unit 125 controls the IEEE 802.1X message and requests the ISP 20 to authenticate the node 14. Then, the MAC address table 127 of the MACFWD unit 124 is updated according to the state (whether authentication is being performed or authentication is being performed). Specifically, a record in which the MAC address of the node 14 to be authenticated is registered in the field 1271 is specified from the MAC address table 127, and the authentication state is registered and updated in the field 1275 of this record.
[0047]
When transmitting an IEEE 802.1X message, the PROC unit 125 creates a MAC frame in which the IEEE 802.1X message is stored, and transmits the MAC frame to the MACFWD unit 124 corresponding to the destination MAC address.
[0048]
FIG. 4 is a schematic configuration diagram of the router 22.
[0049]
As shown in the figure, the router 22 includes a LAN connector 221 for connecting a LAN cable from the DSLAM 30, a LAN connector 222 for connecting a LAN cable connected to the RADIUS server 24, the GW 26, and the management device 28, and a LAN connector. PHY processing unit 223 provided for each of 221 and 222 for processing the physical layer of signals transmitted to and received from corresponding LAN connectors 221 and 222, and performs IPv6 processing provided for each PHY processing unit 223 It has an IPv6 processing unit 224 and a PROC unit 225 that controls IEEE 802.1X messages. Each IPv6 processing unit 224 and PROC unit 225 are connected by a bus 226.
[0050]
The IPv6 processing unit 224 has a routing table 227 for performing IPv6 routing. The routing table stores, for each prefix, an IP address of the next hop for going to the network specified by the prefix, a MAC address corresponding to the IP address of the next hop, and an IPv6 processing unit 224 for relaying to the next hop. Is registered in association with each other.
[0051]
When the IPv6 processing unit 224 receives a MAC frame from the corresponding PHY processing unit 223, it extracts an IP packet from the MAC frame. Then, using the routing table, the IP address and MAC address of the next hop associated with the longest matching prefix of the IP packet and the identification information of the IPv6 processing unit 224 are specified. Then, a MAC frame storing the IP packet and destined for the MAC address of the next hop is generated and transmitted to the IPv6 processing unit 224 having the specified identification information. Further, when receiving the MAC frame from another IPv6 processing unit 224 via the bus 226, the IPv6 processing unit 224 transmits this to the corresponding PHY processing unit 223.
[0052]
If the IP packet stored in the MAC frame received from the corresponding PHY processing unit 223 is an IP packet addressed to the router 22, such as a RADIUS message or an ICMP message, the IPv6 processing unit 224 transmits the IP packet to the PROC 225. I do.
[0053]
The PROC unit 225 controls the IEEE 802.1X message, and requests the RADIUS server 24 to authenticate the node 14. Further, the PROC unit 225 has a user management table 228, and uses this to manage prefixes for each user of the node 14.
[0054]
FIG. 5 shows an example of registered contents of the user management table 228. As shown in the figure, the user management table 228 includes a field 2281 for registering the authentication status of the node 14 according to the IEEE 802.1X standard, a field 2282 for registering the MAC address of the node 14, and a prefix assigned to the node 14. A field 2283 for registration, a field 2284 for registering an encryption key used when the node 14 performs cryptographic communication with the router 22, and a field 2285 for registering a user name of the node 14 are provided. One record is formed. Here, if the authentication state of the field 2281 is “under authentication”, it indicates that a MAC frame having the MAC address registered in the field 2282 of the record as the source or destination must not be transmitted or received.
[0055]
The management device 28 manages the maintenance information of the router 22 as described above.
[0056]
FIG. 6 is a schematic diagram of the management device 28.
[0057]
As shown in the figure, the management device 28 includes a network interface unit 281 for communicating with the router 22 and the like, a GUI unit 282 for receiving various instructions from an administrator and displaying information to the administrator, and a router 22. And a maintenance management unit 283 that manages the maintenance information of. The maintenance management unit 283 controls the GUI unit 282 to display an IP address duplication report message received from the router 22, accesses the router 22 via the network IF unit 281, and obtains information specified by the administrator. And display it.
[0058]
The management device 28 reads, for example, information from a CPU 801, a memory 802, an external storage device 803 such as an HDD, and a portable storage medium 804 such as a CD-ROM or DVD-ROM, as shown in FIG. In a general computer system including a device 805, an input device 806 such as a keyboard and a mouse, a display device 807 such as a CRT or an LCD, and a communication device 808 for communicating with the router 22, etc. This can be realized by executing a predetermined program loaded on the memory 802. The predetermined program may be directly loaded into the memory 802 from the storage medium 804 via the reading device 805, or from a communication medium such as the Internet via the communication device 808, or may be temporarily stored in the external storage device. The data may be downloaded to the memory 802 and then loaded into the memory 802.
[0059]
Since the node 14, the ADSL modem 16, the DSLAM 30, the RADIUS server 24, and the GW 26 can use existing devices that support IPv6, detailed descriptions thereof are omitted.
[0060]
FIG. 8 is a simplified view of the public wireless LAN access service system of the present embodiment shown in FIG. 1 focusing on the link (subnet) accommodating the node 14.
[0061]
As described above, the router 22, the RADIUS server 24, and the management device 28 are LAN-connected. For this reason, an L2SW (Layer 2 switch), not shown, is actually used for connection between the router 103, the RADIUS server 24, and the management device 28.
[0062]
As illustrated, in this embodiment, each node 14 is accommodated in a different link. That is, the router 22 router-advertises a different network prefix to each node 14. This prevents overlapping of IPv6 addresses between the nodes 14. Note that the router 22 guarantees the uniqueness of the network prefix advertised to each node 14 by router.
[0063]
Further, in the present embodiment, an address duplication notification packet transmitted by a certain node 14 is prevented from reaching another node 14.
[0064]
More specifically, a method for preventing the node 14 from recognizing (decrypting) a packet other than the packet transmitted by the router 22 by encrypting the communication between the node 14 and the AP 12 with a different encryption key for each node 14. (Method A), and by encrypting the communication between the node 14 and the router 22 with a different encryption key for each node 14 or adding authentication information, the node 14 transmits a packet other than the packet transmitted by the router 22. (Method B) to make it impossible to recognize (decode) or ignore as an illegal packet.
[0065]
In either method, the node 14 and the RADIUS server 24 store a pair of an authentication key and an encryption key corresponding to the user name in advance, and the authentication key is used in IEEE 802.1X authentication, and the encryption key is It is used for later encrypted communication.
[0066]
First, the method A will be described with reference to FIG.
[0067]
FIG. 9 is a sequence diagram for explaining an operation procedure of the present embodiment in a case where communication is performed between the node 14 and the AP 12 by encrypting with a different encryption key for each node 14, that is, when the method A is applied. . The MAC addresses of the node 14, the AP 12, and the router 22 are m1, l0, and k0, respectively.
[0068]
When the power is turned on, the node 14 starts a network connection. First, an interface ID is automatically generated based on a MAC address (ST2001). As described above, a method of generating an interface ID from a MAC address is specified in RFC 2373 “IP Version 6 Addressing Architecture”. FIG. 10 shows a relationship between a MAC address and an interface ID automatically generated based on the MAC address.
[0069]
As shown in the figure, the interface ID 902 inserts a 16-bit bit string “1111111111111110” between the company ID (the bit string shown in the figure, c) and the extension ID (the bit string shown in the figure, m) in the MAC address 901. Then, it is generated by inverting the universal / local bit (the bit whose bit value is “0” in the figure). The bit indicated by “g” in the figure is a bit called an individual / group bit. The link local address 903 is obtained by adding a fixed prefix “FE80 ::” for the link local address to a higher level of the interface ID 902.
[0070]
In FIG. 10, the request node multicast IP address 904 is obtained by adding “FF02: 0: 0: 0: 0: 0: 1: FF00: / 104” to the lower three bytes of the interface ID 902. The corresponding request node multicast MAC address 905 is obtained by adding “0x3333” to the lower 4 bytes of the request node multicast IP address 904.
[0071]
In FIG. 10, the all-node multicast IP address 906 is “FF02 :: 1”, and the corresponding all-node multicast MAC address 907 is “0x3333” in the lower 4 bytes of the all-node multicast IP address 907. It has been added. The MAC frame of an IPv6 packet having the all-node multicast IP address 906 as the destination IP address usually sets the all-node multicast MAC address 907 as the destination MAC address.
[0072]
The node 14 communicates with the AP 12 and an EAP message (EAPOL-Start, EAP-Req / Identity, EAP (PPP Extensible Authentication Protocol), which is a protocol for the RADIUS server 24 to authenticate the node 14 specified in RFC2284. EAP-Rsp / Identity, EAP-Req / MD5 Challenge, and EAP-Rsp / MD5 resp) are transmitted and received. Here, the EAP message is transmitted and received by an EAPOL (EAP over LAN) packet defined by the IEEE 802.1X standard.
[0073]
On the other hand, the AP 12 transmits and receives an EAP message transmitted and received to and from the node 14 by an EAPOL packet to and from the RADIUS server 24 by a RADIUS packet (RADIUS ACCESS-Req, -Challenge, -Acpt). The AP 12 has an IP address for this. The RADIUS protocol is defined in RFCs 2865 to 2869.
[0074]
Now, the node 14 transmits an EAPOL-Start message requesting the start of authentication according to the IEEE 802.1X standard, to a MAC address meaning a port access entity (ST2002). As a result, the EAPOL-Start message is transmitted from the node 14 to the AP 12.
[0075]
In the AP 12, when receiving the EAPOL-Start message from the node 14 via the PHY processing unit 123 and the MACFWD unit 124 on the wireless IF unit 121 side, the PROC unit 125 adds a record to the MAC address table 127, and The MAC address of the node 14 that has transmitted the EAPOL-Start message is registered in the field 1271, the port number of the connection port with the node 14 is registered in the field 1272, and the authentication state “under authentication” is registered in the field 1275 ( ST2003).
[0076]
The PROC unit 125 creates an EAP-Req / Identity message requesting a user name, and sends the EAP-Req / Identity message from the wireless IF unit 121 to the EAPOL-Start via the MACFWD unit 124 and the PHY processing unit 123 on the wireless IF unit 121 side. The message is transmitted to node 14 that has transmitted the message (ST2004).
[0077]
Upon receiving the EAP-Req / Identity message, node 14 generates an EAP-Rsp / Identity message including a user name registered in advance or entered by the user, and transmits the message to AP 12 (ST2005).
[0078]
In the AP 12, when receiving the EAP-Rsp / Identity message from the node 14 via the PHY processing unit 123 and the MACFWD unit 124 on the wireless IF unit 121 side, the PROC unit 125 creates a RADIUS Access-Req message, and generates this message. , The MAC address of the node 14 is stored in the Calling-Station-Id attribute, and the EAP-Rsp / Identity message is stored in the EAP-Message attribute. Then, a RADIUS Access-Req message is transmitted from LAN connector 122 to router 22 via MACFWD section 124 and PHY processing section 123 on LAN connector 122 side (ST2006).
[0079]
In the router 22, when receiving the RADIUSAccess-Req message from the AP 12 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the PROC unit 225 adds a record to the user management table 228, and In field 2281, the authentication status “under authentication” is registered, in field 2282 the MAC address of node 14 that transmitted the EAP-Rsp / Identity message, and in field 2285, the user name of the user of node 14 is registered (ST2007). ).
[0080]
Further, PROC section 225 transmits the RADIUS Access-Req message received from AP 12 from LAN connector 222 to RADIUS server 24 via IPv6 processing section 224 and PHY processing section 223 on LAN connector 222 side (ST2008). This notifies the RADIUS server 24 of the user name and the MAC address of the node 14.
[0081]
Upon receiving the RADIUS Access-Req message, the RADIUS server 24 generates a RADIUS Access-Challenge message, generates an authentication random number, and sets this in the EAP message in the EAP-Message attribute of the RADIUS Access-Challenge message. Then, this RADIUS Access-Challenge message is transmitted to AP 12 via router 22 (ST2009).
[0082]
In the AP 12, when the PROC unit 125 receives a RADIUS Access-Challenge message from the RADIUS server 24 via the PHY processing unit 123 and the MACFWD unit 124 on the LAN connector 122 side, the PROC unit 125 includes the authentication random number included in the message. , Create an EAP-Req / MD5 Challenge message. Then, this message is transmitted from wireless IF section 121 to node 14 via MACFWD section 124 and PHY processing section 123 of wireless IF section 121 (ST2010).
[0083]
Upon receiving the EAP-Req / MD5 Challenge message from the AP 12, the node 14 performs an authentication operation using an authentication random number included in the message and an authentication key stored in advance. Then, the result is included in the EAP-Rsp / MD5 resp message and transmitted to AP 12 (ST2011).
[0084]
In the AP 12, when receiving the EAP-Rsp / MD5 resp message from the node 14 via the PHY processing unit 123 and the MACFWD unit 124 on the wireless IF unit 121 side, the PROC unit 125 generates a RADIUS Access-Req message. The received EAP-Rsp / MD5 resp message is set in the EAP-Message attribute of the message. Then, a RADIUS Access-Req message is transmitted from the LAN connector 122 to the RADIUS server 24 via the router 22 via the MACFWD unit 124 and the PHY processing unit 123 on the LAN connector 122 side (ST2012).
[0085]
Upon receiving the RADIUS Access-Req message, the RADIUS server 24 authenticates the user of the node 14 using the authentication result included in the EAP-Rsp / MD5 resp message set therein. Specifically, an authentication operation is performed on the authentication random number generated in ST2009 using an authentication key registered in advance in association with the user name of node 14. It is determined whether the result matches the one received from node 14 (ST2013).
[0086]
If they match, the authentication is successful. In this case, the RADIUS server 24 generates a RADIUS Access-Act message, and notifies the router 33 of the message including the prefix assigned to the node 14 and the encryption key used by the AP 12 for encryption communication in the wireless section ( ST2014). Here, the prefix has a different value for each node 14, and is set in the Framed-IPv6-Prefix attribute of the RADIUS Access-Accept message. Further, the encryption key is set in, for example, a Callback-Id attribute of the RADIUS Access-Accept message.
[0087]
Now, in the router 22, when the PROC unit 225 receives a RADIUS Access-Acpt message from the RADIUS server 24 via the PHY processing unit 223 and the IPV6 processing unit 224 on the LAN connector 222 side, the prefix included in the message is received. Is registered in the field 2283 of the record added to the user management table 228 in ST2007. In addition, the authentication status registered in field 2281 is changed from “authenticated” to “authenticated” (ST2015). As a result, the PROC unit 225 controls each unit such that the MAC frame having the MAC address of the node 14 as a transmission source or destination can be transmitted and received.
[0088]
Further, PROC section 225 transmits the RADIUS Access-Accept message received from RADIUS server 24 from LAN connector 221 to AP 12 via IPV6 processing section 224 and PHY processing section 223 on LAN connector 221 side (ST2016). .
[0089]
In the AP 12, when the PROC unit 125 receives the RADIUSAccess-Acpt message from the router 22 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 122 side, the encryption key included in the message is transmitted in ST2003. It is registered in the field 1274 of the record added to the MAC address table 127. Further, the authentication status registered in field 1275 is changed from “authenticating” to “authenticated” (ST2017). As a result, the PROC unit 125 controls each unit such that the MAC frame transmitted and received between the node 14 and the router 22 is bridged.
[0090]
Also, the PROC unit 125 generates an EAP-Success-message including the registered encryption key, and transmits the EAP-Success-message from the wireless IF unit 121 to the node 14 via the MACFWD unit 124 and the PHY processing unit 123 on the wireless IF unit 121 side. Then, node 14 is notified that the authentication is successful (ST2018).
[0091]
Node 14, upon receiving the EAP-Success-message from AP 12, registers the encryption key included in the message (ST2019).
[0092]
With the above, the authentication according to the IEEE 802.1 standard is completed. Thereafter, the node 14 and the AP 12 perform the encryption communication of the MAC frame using the encryption key.
[0093]
Now, in the router 22, the PROC unit 225 transmits a Router Advertise message, which is a router advertisement, to notify the node 14 to which the prefix is included in the RADIUS Access-Accept message received from the RADIUS server 24 to the prefix. This is generated and transmitted to the node 14 from the LAN connector 221 via the AP 12 via the IPV6 processing unit 224 and the PHY processing unit 223 on the LAN connector 221 side (ST2020).
[0094]
Here, FIG. 11 shows a format configuration example of a MAC frame storing an IPv6 packet used in the present embodiment.
[0095]
As illustrated, the MAC frame 920 used in the present embodiment includes a destination MAC address 921, a transmission source MAC address 922, a storage data type 923, storage data 924, and a CRC (Cyclic Redundancy Checking) 925. Contains. When the type 923 is “0x86DD”, it indicates that the stored data 924 is an IPv6 packet.
[0096]
The IPv6 packet 930 includes an IP header and an IP payload 934. The IP header includes a source IP address 931 and a destination IP address 932. Further, the IP header can include an authentication header for setting authentication information of the IP packet as an extension header and an encryption payload header 933 necessary for encrypting the IP payload 7934. An ICMP packet can be set in the IP payload 934.
[0097]
The Router Advertise message 940 is an ICMP packet whose ICMP type 941 is “134”. The MAC address of the source router is registered in the source link layer option 942, and the prefix of the link (subnet) is registered in the prefix information option 943.
[0098]
In ST2020 of FIG. 9, when router 22 transmits a Router Advertise message, the IP address of node 14 has not yet been determined at this time, so that the multicast IP address of all nodes is set as destination IP address 932 of the IP header. There is a need. However, in the present embodiment, each node 14 is accommodated in a different link. For this reason, it is necessary to prevent the prefix transmitted in the Router Advertise message from being received by any node other than the node 14 to which the prefix is assigned.
[0099]
Therefore, in the router 22, the PROC unit 225 sets the field 2282 of the record where the prefix of the Router Advertise message is registered in the field 2283 in the destination MAC address 921 of the MAC frame including the Router Advertise message in the user management table 228. Set the MAC address registered in. In the example shown in FIG. 9, the MAC address “m1” of the node 14 is set.
[0100]
In the AP 12, when the MACFWD unit 124 of the LAN connector 122 receives the MAC frame storing the Router Advertise message from the router 22 via the LAN connector 122 and the PHY processing unit 123, the MAC frame is read from the MAC address table 127. Specifies the record whose destination MAC address “m1” is registered in the field 1271. The MAC frame is transmitted to the MACFWD unit 124 corresponding to the port number registered in the field 1272 of the specified record, that is, the MACFWD unit 124 connected to the wireless IF unit 121 via the PHY processing unit 123. I do.
[0101]
Upon receiving the MAC frame from the MACFWD unit 124 of the LAN connector 122 via the bus 126, the MACFWD unit 124 of the wireless IF unit 121 receives the destination MAC address of this MAC frame from the MAC address table 127. "m1" specifies the record registered in the field 1271. Then, after confirming that the authentication state registered in the field 1275 of the specified record is “authenticated”, if the encryption key is registered in the field 1274 of this record, the encryption key is used. The data stored in the MAC frame is encrypted and then transmitted to the corresponding PHY processing unit 123. Thereby, the MAC frame in which the stored data is encrypted is transmitted from the AP 12 to the node 14 having the MAC address “m1”.
[0102]
When the destination MAC address receives its own MAC frame, the node 14 decrypts the stored data using the encryption key registered in ST2019, and obtains a Router Advertise message. Then, it obtains its own prefix included in this message. The source IP address and the source MAC address of this message are recognized as the default router (ST2021).
[0103]
Now, after the authentication according to the IEEE 802.1 standard is completed, the node 14 transmits a Neighbor Solitic message in order to confirm whether or not the interface ID generated in ST2001 is unique within the same link (subnet). Then, an address duplication inquiry is made (ST2022).
[0104]
As shown in FIG. 11, the Neighbor Solocit message 950 is an ICMP packet whose ICMP type 951 is “135”. As the target IP address 952, a link local address (see FIG. 10) generated from the interface ID “M1” is set. The source link layer address option 953 is not included.
[0105]
As shown in FIG. 11, the source IP address 931 of the IPv6 packet 930 storing the Neighbor Solitic message 950 is set to “0” indicating an address duplication inquiry, and the destination IP address 932 is set. Is set to the requesting node multicast IP address (see FIG. 10) generated from the interface ID “M1”.
[0106]
Also, as shown in FIG. 11, the destination MAC address 921 of the MAC frame 920 storing the IPv6 packet 930 storing the Neighbor Solocit message 950 is a request node multicast MAC address corresponding to the interface ID “M1” (see FIG. 10). ) Is set, and “m1” which is the MAC address of the node 14 is set as the source MAC address 922.
[0107]
The node 14 encrypts the stored data of the MAC frame storing the Neighbor Solitic message with the encryption key and transmits the MAC frame.
[0108]
In the AP 12, when the MACFWD unit 124 of the wireless IF unit 121 receives the MAC frame storing the NegativeSolocit message from the node 14 via the wireless IF unit 121 and the PHY processing unit 123, the MACFWD unit 124 reads the MAC frame from the MAC address table 127. The source MAC address “m1” of the frame specifies the record registered in the field 1271. Then, after confirming that the authentication state registered in the field 1275 of the specified record is “authenticated”, the data stored in the MAC frame is stored using the encryption key registered in the field 1274 of the record. Is decrypted (ST2023).
[0109]
Next, the MACFWD unit 124 of the wireless IF unit 121 identifies a record in which the port attribute “router” is registered in the field 1273 from the MAC address table 127, and specifies the port registered in the field 1272 of this record. The MAC frame is transmitted to the MACFWD unit 124 corresponding to the number, that is, the MACFWD unit 124 connected to the LAN connector 122 via the PHY processing unit 123. Thereby, this MAC frame is transmitted to router 22 (ST2024).
[0110]
In the router 22, when the PROC unit 225 receives the Negative Sololoc message via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the target IP address 952 of this message (see FIG. 11) is changed to its own IP address. Check if the address matches. If they do not match, this message is ignored (ST2025).
[0111]
If the node 14 does not receive a Neighbor Advertise message, which is a response to the address duplication inquiry, within a predetermined period of time, the node 14 determines that its own interface ID is unique, and compares this interface ID with the prefix received by the RouterAdvertise message. Then, a link-local address and a global (or site-local) address are generated and assigned to its own IPv6 interface (ST2026).
[0112]
Since the port attribute corresponding to the transmission source MAC address of the Negative Advertise message in the address management table 127 of the Negative Advertise message transmitted by the other node 14 is “node”, the port attribute is similar to the Neighbor Solicit message. It is sent only to the port with the port number “router”, that is, to the router 22. Therefore, the message does not interfere with the automatic address setting of the node 14.
[0113]
Next, method B will be described with reference to FIG.
[0114]
FIG. 12 illustrates an operation procedure of the present embodiment in a case where communication between the node 14 and the router 22 is encrypted with a different encryption key for each node 14 or authentication information is added, that is, when the method B is applied. FIG. The MAC addresses of the node 14, the AP 12, and the router 22 are m1, l0, and k0, respectively, as in the case of the method A shown in FIG. In the method B, the AP 12 does not need to have a function of supporting IEEE 802.1X authentication.
[0115]
First, the node 14 automatically generates an interface ID based on the MAC address (ST2101). After that, in order to confirm whether or not the interface ID is unique within the same link (subnet), a Neighbor Solitic message is transmitted to perform an address duplication inquiry (ST2102). Here, the node 14 encrypts or authenticates the transmission IP packet using an encryption key in order to prevent another node 14 from receiving the Neighbor Solitic message. Further, in order not to receive a Neighbor Advertise message, which is an address duplication notification in response to an address duplication inquiry transmitted by itself from another node 14, decryption or authentication of the received IP packet with an encryption key is performed. I have to.
[0116]
In the router 22, when the PROC unit 225 receives the MAC frame storing the Negative Solocit message from the LAN connector 221 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the source MAC of the MAC frame is transmitted. It is checked whether the address is registered in the user management table 228. Then, it is confirmed that it has not been registered yet, that is, that the node 14 that transmitted the Neighbor Solitic message has not been authenticated (ST2103). Then, an EAP-Req / Identity message is generated, and transmitted to the node 14 that transmitted the Negative Solicit message from the LAN connector 221 via the PHY processing unit 223 and the IPv6 processing unit 224 of the LAN connector 221 (ST2104).
[0117]
Upon receiving the EAP-Req / Identity message, the node 14 recognizes that this is an EAPOL packet, not an IPv6 packet, and therefore processes the EAP-Req / Identity message without performing authentication / decryption using an encryption key. Then, it generates an EAP-Rsp / Identity message, sets its own user name in this message, and transmits it to the router 22 (ST2105).
[0118]
In the router 22, when receiving the EAP-Rsp / Identity message from the node 14 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the PROC unit 225 adds a record to the user management table 228, In the field 2281 of this record, the authentication state “under authentication” is set, the field 282 sets the source MAC address “m1” of the EAP-Rsp / Identity message, and the field 2285 sets the EAP-Rsp / Identity message. The user name is registered (ST2106).
[0119]
Then, the PROC unit 225 creates a RADIUS Access-Req message, and in the Calling-Station-Id attribute of this message, the source MAC address “m1” of the EAP-Rsp / Identity message, and the EAP-Message attribute. EAP-Rsp / Identity message is stored. Then, a RADIUS Access-Req message is transmitted from the LAN connector 222 to the RADIUS server 24 via the IPv6 processing unit 224 and the PHY processing unit 223 on the LAN connector 222 side (ST2107). This notifies the RADIUS server 24 of the user name and the MAC address of the node 14.
[0120]
Upon receiving the RADIUS Access-Req message, the RADIUS server 24 generates a RADIUS Access-Challenge message, generates an authentication random number, and sets this in the EAP message in the EAP-Message attribute of the RADIUS Access-Challenge message. Then, this RADIUS Access-Challenge message is transmitted to router 22 (ST2108).
[0121]
In the router 22, when the PROC unit 225 receives a RADIUS Access-Challenge message from the RADIUS server 24 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 222 side, the PROC unit 225 converts the authentication random number included in this message into an authenticated random number. Create an EAP-Req / MD5 Challenge message containing the message. Then, this message is transmitted from the LAN connector 221 to the node 14 via the IPv6 processing unit 224 and the PHY processing unit 223 on the LAN connector 221 side (ST2109).
[0122]
Upon receiving the EAP-Req / MD5 Challenge message from the router 22, the node 14 performs an authentication operation using the authentication random number included in the message and the authentication key stored in advance. Then, the result is included in the EAP-Rsp / MD5 resp message and transmitted to router 22 (ST2110).
[0123]
In the router 22, when receiving the EAP-Rsp / MD5 resp message from the node 14 via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the PROC unit 225 generates a RADIUS Access-Req message, The received EAP-Rsp / MD5 resp message is set in the EAP-Message attribute of this message. Then, a RADIUS Access-Req message is transmitted from the LAN connector 222 to the RADIUS server 24 via the IPv6 processing unit 224 and the PHY processing unit 223 on the LAN connector 222 side (ST2111).
[0124]
Upon receiving the RADIUS Access-Req message, the RADIUS server 24 authenticates the user of the node 14 using the authentication result included in the EAP-Rsp / MD5 resp message set therein. Specifically, an authentication operation is performed on the authentication random number generated in ST2108 using an authentication key registered in advance in association with the user name of node 14. It is determined whether the result matches the one received from node 14 (ST2112).
[0125]
If they match, the authentication is successful. In this case, the RADIUS server 24 generates a RADIUS Access-Act message, and notifies the router 22 of the message including the prefix assigned to the node 14 and the encryption key used for the encryption communication between the node 14 and the router 22. (ST2113). Here, the prefix has a different value for each node 14, and is set in the Framed-IPv6-Prefix attribute of the RADIUS Access-Accept message. Further, the encryption key is set in, for example, a Callback-Id attribute of the RADIUS Access-Accept message.
[0126]
Now, in the router 22, when the PROC unit 225 receives a RADIUS Access-Acpt message from the RADIUS server 24 via the PHY processing unit 223 and the IPV6 processing unit 224 on the LAN connector 222 side, the prefix included in the message is received. And the encryption key are registered in the fields 2283 and 2284 of the record added to the user management table 228 in ST2106. Also, the authentication status registered in field 2281 is changed from “authenticating” to “authenticated” (ST2114). As a result, the PROC unit 225 controls each unit so that a MAC frame having the MAC address of the node 14 as a transmission source or destination can be transmitted and received by encrypted communication.
[0127]
The PROC unit 225 generates an EAP-Success-message including the registered encryption key, and transmits the generated EAP-Success-message from the LAN connector 221 to the node 14 via the IPv6 processing unit 224 and the PHY processing unit 223 on the LAN connector 221 side. Then, the node 14 is notified that the authentication is successful (ST2115).
[0128]
Upon receiving the EAP-Success-message from router 22, node 14 registers the encryption key contained in the message (ST2116).
[0129]
Thus, the authentication according to the IEEE 802.1 standard is completed. Thereafter, the node 14 and the router 22 can perform the authentication communication or the encryption communication of the IPv6 packet using the encryption key and the authentication header / encryption payload header 933 of the IPv6 packet.
[0130]
Now, in the router 22, the PROC unit 225 transmits a Router Advertise message, which is a router advertisement, to notify the node 14 to which the prefix is included in the RADIUS Access-Accept message received from the RADIUS server 24 to the prefix. This is generated as a destination MAC address “m1” and a destination IP address “all-nodes multicast IP address”, and is transmitted from the LAN connector 221 to the node 14 via the IPV6 processing unit 224 and the PHY processing unit 223 of the LAN connector 221. It transmits (ST2117).
[0131]
When the destination MAC address receives its own MAC frame, the node 14 obtains a Router Advertise message from this frame. Then, it obtains its own prefix included in this message. The source IP address and the source MAC address of this message are recognized as the default router (ST2118).
[0132]
Now, after the authentication according to the IEEE 802.1 standard is completed, the node 14 generates a Neighbor Solitic message for confirming whether or not the interface ID generated in ST2001 is unique within the same link (subnet). By transmitting, an address duplication inquiry is made (ST2119).
[0133]
In the router 22, when the PROC unit 225 receives the Negative Sololoc message via the PHY processing unit 223 and the IPv6 processing unit 224 on the LAN connector 221 side, the source MAC address of the MAC frame storing this message is stored in the user management table. It is checked whether it is registered in 228. Then, it is confirmed that the node 14 that has not been registered, that is, the node 14 that has transmitted the Neighbor Solitic message is authenticated (ST2120). Then, it checks whether or not the target IP address 952 of this message (see FIG. 11) matches its own IP address. If they do not match, this message is ignored (ST2121).
[0134]
If the node 14 does not receive a Neighbor Advertise message, which is a response to the address duplication inquiry, within a predetermined period of time, the node 14 determines that its own interface ID is unique, and compares this interface ID with the prefix received by the RouterAdvertise message. Then, a link local address and a global (or site local) address are generated and assigned to its own IPv6 interface (ST2122).
[0135]
In any of the methods A and B described above, if the AP 12 is an L2SW connected to the node 14 by wire, the communication between the nodes 14 may be prohibited by the L2SW. In this case, the frame transmitted by the node 14 cannot be intercepted by another node 14. Therefore, there is no need to encrypt communication between the node 14 and the L2SW (method A) or between the node 14 and the router 22 (method B).
[0136]
The first embodiment of the present invention has been described above.
[0137]
In the present embodiment, a different global (site-local) address prefix is assigned to each of the nodes 14 so that one node belongs to each link local. Therefore, a router advertisement in which both the IP address and the MAC address are both multicast can be delivered to a specific node 14 even if the IP address of the node 14 is unknown. As a result, the node 14 can be assigned a prefix dedicated to the node. If a dedicated prefix is assigned to each node 14, duplication of interface IDs between nodes does not occur. Therefore, according to the present embodiment, the uniqueness of the IPv6 address of each node 14 can be guaranteed, and the automatic configuration which is a feature of IPv6 can be effectively used.
[0138]
In this embodiment, communication between the node 14 and the AP 12 or the router 22 is performed using a unique encryption key for each node 14. By doing so, it is possible to prevent the node 14 from directly communicating with the other nodes 14 other than the router 22. Therefore, it is possible to reduce the possibility that the network cannot be accessed due to the presence of a malicious node.
[0139]
Next, a second embodiment of the present invention will be described.
[0140]
FIG. 13 shows a simplified public wireless LAN access service system according to the second embodiment of the present invention, focusing on links (subnets) accommodating nodes 14.
[0141]
As shown in the drawing, in this embodiment, unlike the first embodiment shown in FIG. 8, all the nodes 14 under the AP 12 are accommodated in one link (subnet) 50. Note that the public wireless LAN access service system of the present embodiment is basically the same as that of the first embodiment shown in FIG. However, as shown in FIG. 14, in the router 22 of the present embodiment, the PROC unit 225 holds an IP address management table 229 instead of the user management table 228.
[0142]
FIG. 15 shows an example of registered contents of the IP address management table 229. As shown in the figure, the IP address management table 229 includes a field 2291 for registering the authentication state of the node 14 according to the IEEE 802.1X standard, a field 2292 for registering the MAC address of the node 14, A field 2294 for registering an encryption key used for performing encrypted communication, a field 2295 for registering the user name of this node 14, and an in-use IP address table 2297 for managing a plurality of IP addresses are registered. And a field 2296 for registering a pointer to a used IP address.
[0143]
In this embodiment, since all the nodes 14 under the AP 12 belong to the same link, the router 22 needs to monitor all the in-use IP addresses to guarantee uniqueness. The in-use IP address table 2297 is updated together with the NeighborCache when the automatic address setting of the node 14 is completed and the IP address is resolved when starting the IP communication.
[0144]
The Neighbor Cache is a correspondence list between the IP address and the MAC address, and the updating method is described in RFC2461. However, RFC2461 states that Neighbor Cache can be overwritten with a MAC address corresponding to a registered IP address. However, in the present embodiment, the overwriting is prohibited, and the MAC address can be changed only by deleting the entry due to timeout or forcibly deleting the entry to prohibit the use of an illegal IP address described later.
[0145]
Also in the present embodiment, as in the first embodiment, as a method for preventing the IPv6 packet transmitted by the node 14 from reaching another node 14, the communication between the node 14 and the AP 12 is different for each node 14. A method of preventing the node 14 from recognizing (decrypting) a packet other than the packet transmitted by the router 22 by encrypting with the encryption key (method A), and performing communication between the node 14 and the router 22 with the node 14 A method of preventing the node 14 from recognizing (decrypting) a packet other than the packet transmitted by the router 22 or ignoring the packet as an unauthorized packet by adding encryption or authentication information with a different encryption key for each time. Either (method B) is adopted.
[0146]
Here, the method A will be described as an example.
[0147]
FIG. 16 is a sequence diagram for explaining the operation procedure of the present embodiment when communication is performed between the node 14 and the AP 12 by encrypting with a different encryption key for each node 14, that is, when method A is applied. . Here, as in the case of FIG. 9, the MAC addresses of the node 14, the AP 12, and the router 22 are m1, l0, and k0, respectively.
[0148]
16, ST2201 to ST2219 are basically the same as ST2001 to ST2019 of FIG.
[0149]
However, in the present embodiment, as described above, the router 22 is provided with the IP address management table 229 instead of the user management table 228. Therefore, in ST2207, a new record is added to the IP address management table 229, and the authentication status “authentication” is added to the field 2291 of the record, the MAC address of the node 14 is set to the field 2292, and the node 14 The user name of the user is registered.
[0150]
In the present embodiment, as described above, the same prefix is assigned to all the nodes 14 under the control of the AP 12. That is, a different prefix is not assigned to each node 14. For this reason, in ST2214, the RADIUS server 24 does not notify the prefix assignment. Instead, the router 22 is made to manage a prefix assigned to the node 14 under the AP 12 for each AP 12. Also, in ST2215, registration of the flexfix is not performed. In ST2207, the authentication status registered in field 2291 of the record added to IP address management table 229 is changed from "authenticated" to "authenticated". As a result, the PROC unit 225 controls each unit such that the MAC frame having the MAC address of the node 14 as a transmission source or destination can be transmitted and received.
[0151]
Next, in FIG. 16, ST2220 to ST2224 are also basically the same as ST2020 to ST2024 in FIG. However, in the present embodiment, as described above, the same prefix is assigned to all the nodes 14 under the AP 12. Therefore, in ST2220, router 22 sets the destination MAC address of the Router Advertise message as the all-node multicast MAC address. Thereby, the same prefix is notified to all the nodes 14 under the control of the AP 12.
[0152]
Note that in ST2220, when transmitting the Router Advertise message to the nodes 14, the AP 12 does not encrypt the Router Advertise message with an encryption key unique to each node 14. No encryption is performed, or encryption is performed using an encryption key (multicast encryption key) common to all nodes 14 under the AP 12.
[0153]
On the other hand, in ST2222, when transmitting the Neighbor Solicit message, the node 14 encrypts with the encryption key unique to the node 14, as in ST2022 of FIG.
[0154]
Now, in the first embodiment, since a different prefix is assigned to each node 14, it is sufficient to confirm that the IP address of the node 14 does not overlap with the IP address of the router 22. For this reason, as shown in ST2025 of FIG. 9, the router 22 ignored the Negative Solicit message transmitted by the node 14 for the address duplication inquiry if the target IP address was not its own IP address. In contrast, in the present embodiment, the router 22 determines the address duplication within the same link in consideration of all the Neighbor Solicit messages transmitted by the node 14 for the address duplication inquiry.
[0155]
FIG. 17 is a sequence diagram for explaining the operation procedure after the router 22 receives the Neighbor Solicit message for the address duplication inquiry transmitted by the node 14, that is, the continuation of FIG.
[0156]
In FIG. 17A, the PROC unit 225 of the router 22 determines that the source address of the Neighbor Solicit message received via the PHY processing unit 223 and the IPv6 processing unit 224 of the LAN connector 221 is an address duplication inquiry. It is confirmed that the indicated “0” is set (ST2251). Then, it is checked whether or not the relationship between the transmission source MAC address of this message and the target IP address stored in this message is the relationship between the MAC address 901 and the link local address 903 shown in FIG. 10 ( ST2252). In such a case, the target IP address stored in this message is an address automatically generated from the MAC address. In this case, this address is determined to be a valid address. No response is returned to the node 14. As a result, the node 14 officially adopts the address set as the target IP address as the link local address. Thus, the automatic address setting is successful (ST2256).
[0157]
If there is another user (node) already using this IP address, it is necessary to prohibit that user from using this IP address. Therefore, PROC section 225 searches IP address management table 229 for a record in which pointer to the target IP address stored in the Neighbor Solicit message is registered in field 2296 (ST2253). If such a record is not detected, there is no other user using this IP address, and the process ends. On the other hand, when such a record is detected, the detected record is deleted from the IP address management table 229, and the correspondence between the MAC address registered in the detected record field 2292 and this IP address is detected from the Neighbor Cache. The relationship is deleted (ST2254). In addition, a duplicate report message including the information of the deleted record is created and transmitted from the LAN connector 222 to the management device 28 via the IPv6 processing device 224 and the PHY processing unit 223 on the LAN connector 222 side (ST2255).
[0158]
On the other hand, in ST2252, when the relationship between the source MAC address of the Neighbor Solicit message and the target IP address stored in this message is not the relationship between MAC address 901 and link local address 903 shown in FIG. The target IP address stored in this message is not an address automatically generated from the MAC address. In this case, this address is determined to be an invalid address that is permitted only when there is no user (node) in use, and the process proceeds to ST2261 in FIG. 17B.
[0159]
In ST2261 of FIG. 17B, the PROC unit 225 of the router 22 searches the IP address management table 229 for a record in which the pointer to the target IP address stored in the NeighborSolicit message is registered in the field 2296. . When such a record is detected, a Neighbor Advertise message in which the transmission source MAC address of the Neighbor Solicit message is set to the destination MAC address is generated, and this is transmitted via the IPv6 processing device 224 and the PHY processing unit 223 on the LAN connector 221 side. Then, the data is transmitted from the LAN connector 221 (ST2262).
[0160]
As shown in FIG. 11, the Neighbor Advertise message is an ICMP packet 960 whose ICMP type 961 is “136”. A target IP address 962 and a target link layer address option 963 in which the MAC address of the node 14 using the target IP address is set. The destination IP address of the Neighbor Advertise message is an all-node multicast IP address. However, since the source MAC address of the Neighbor Solicit message is set in the destination MAC address, the Neighbor Advertise message is transmitted to the node 14 that transmitted the Neighbor Solicit message. Upon receiving the Neighbor Advertise message, node 14 determines that the automatic address setting has failed (ST2264).
[0161]
In addition, a duplicate report message including the information included in the Neighbor Solicit message is created and transmitted from the LAN connector 222 to the management device 28 via the IPv6 processing device 224 and the PHY processing unit 223 on the LAN connector 222 side. (ST2263).
[0162]
On the other hand, in ST2261, if no record in which the pointer to the target IP address stored in the Neighbor Solicit message is registered in field 2296 from IP address management table 229 is detected, this IP address is used. No other user is present. In this case, the process proceeds to ST2271 in FIG. 17C to permit use of this IP address.
[0163]
In ST2271 of FIG. 17C, the PROC unit 225 of the router 22 generates a Neighbor Solicit message in which the IP address permitted to be used is set as the target IP address and the source IP address is set as the IP address of the router 22. Then, this is transmitted from the LAN connector 221 via the IPv6 processing device 224 and the PHY processing unit 223 on the LAN connector 221 side. This Neighbor Solicit message means an address resolution inquiry because the source IP address is not “0”. Therefore, even if the node whose address is being automatically set (MAC address “m1”) receives this message, it ignores this message in accordance with RFC 246 (ST2272).
[0164]
Here, it is assumed that the node 14 having the MAC address “m2” is using the target IP address set in the Neighbor Solicit message. This node 14 transmits a Neighbor Advertise message to router 22 (ST2273). In response to this, the router 22 performs the same process as in the case where the target IP address has been registered in the IP address management table 229 in ST2261 of FIG.
[0165]
Note that, when a Neighbor Advertise message has not been received from the node 14 under the router 22 as a response to the Neighbor Solicit message transmitted in ST2271, the router 22 sends no response to the node 14 that transmitted the Neighbor Solicit message. Do not return. As a result, the node 14 officially adopts the address set as the target IP address as the link local address. Thereby, the automatic address setting is successful.
[0166]
The method A has been described above as an example. However, even when the method B is applied to the present embodiment, the method A is changed between the first embodiment (FIG. 9) and the second embodiment (FIGS. 16 and 17). The contents can be realized by applying the method to the first embodiment using the method B shown in FIG. That is, the following changes may be made to FIG.
[0167]
(1) In ST2106, a new record is added to the IP address management table 229, and the authentication status “authentication” is added to the field 2291 of the record, the MAC address of the node 14 is set to the field 2292, and the node 14 is set to the field 2295. Are registered.
[0168]
(2) In ST2113, the RADIUS server 24 does not notify the prefix assignment. Instead, it causes the router 22 to manage the prefix assigned to the node 14 under the AP 12 for each AP 12.
[0169]
(3) In ST2114, registration of the flexfix is not performed. In ST2106, the authentication status registered in field 2291 of the record added to IP address management table 229 is changed from “authenticating” to “authenticated”.
[0170]
(4) In ST2117, the router 22 sets the destination MAC address of the Router Advertise message as the all-node multicast MAC address.
[0171]
(5) The operation procedure described with reference to FIG. 17 is applied to the operation procedure after the router 22 receives the Neighbor Solicit message for address duplication inquiry transmitted by the node 14.
[0172]
In this embodiment, when the AP 12 is an L2SW connected to the node 14 by wire, communication between the nodes 14 may be prohibited by the L2SW. In this case, the frame transmitted by the node 14 cannot be intercepted by another node 14. Therefore, there is no need to encrypt communication between the node 14 and the L2SW (method A) or between the node 14 and the router 22 (method B).
[0173]
As above, the second embodiment of the present invention has been described.
[0174]
In the present embodiment, communication between the node 14 and the AP 12 or the router 22 is performed using a unique encryption key for each node 14. Further, the router 22 manages the IP address, the MAC address, and the user name of each node 14 that has been successfully authenticated, and when a certain node 14 performs an address duplication inquiry, the target IP address is It is determined whether or not the address is in use. If the address is in use, an address duplication notification is performed. Alternatively, the target IP address is compared with the MAC address of the node that has performed the address duplication inquiry to determine whether the target IP address is generated on a MAC address basis. If not generated based on the MAC address, an address duplication notification is performed. Therefore, the uniqueness of the IPv6 address of each node 14 can be guaranteed, and the automatic configuration which is a feature of IPv6 can be effectively used. In addition, it is possible to prevent the node 14 from directly communicating with the other nodes 14 other than the router 22. Therefore, it is possible to reduce the possibility that the network cannot be accessed due to the presence of the malicious node.
[0175]
It should be noted that the present invention is not limited to the above embodiment, and various modifications are possible within the scope of the gist.
[0176]
For example, in the public wireless LAN access service system shown in FIG. 1, the AP 12 and the ADSL modem 16 may be integrated. In the ISP 20, any two or more of the router 22, the RADIUS server 24, the GW 26, and the management device 28 may be constructed on the same computer system, or may be constructed on separate computer systems. Is also good.
[0177]
Further, in the above embodiment, the case where the present invention is applied to the public wireless LAN access service system of the present invention is described as an example. Widely applicable to. For example, the present invention can be similarly applied to an IPv6 network access service system from a subscriber's house where a host is accommodated without using PPP by a LAN.
[0178]
【The invention's effect】
As described above, according to the present invention, even when a host is accommodated without using PPP by a LAN in IPv6, the automatic configuration which is a feature of IPv6 can be effectively used.
[Brief description of the drawings]
FIG. 1 is a diagram showing a schematic diagram of a public wireless LAN access service system to which a first embodiment of the present invention is applied;
FIG. 2 is a schematic configuration diagram of an AP 12 shown in FIG.
FIG. 3 is a diagram showing an example of registered contents of a MAC address table 127 shown in FIG. 2;
FIG. 4 is a schematic configuration diagram of a router 22 shown in FIG.
FIG. 5 is a diagram showing an example of registered contents of a user management table 228 shown in FIG. 4;
FIG. 6 is a schematic diagram of the management device 28 shown in FIG.
7 is a diagram illustrating a hardware configuration example of a management device 28 illustrated in FIG.
FIG. 8 is a simplified diagram of the public wireless LAN access service system according to the first embodiment of the present invention, focusing on links (subnets) accommodating nodes 14.
FIG. 9 is a sequence diagram for explaining an operation procedure of the first embodiment of the present invention in a case where communication between the node 14 and the AP 12 is performed by encrypting with a different encryption key for each node 14;
FIG. 10 is a diagram showing a relationship between a MAC address and an interface ID automatically generated based on the MAC address.
FIG. 11 is a diagram showing a format configuration example of a MAC frame storing an IPv6 packet used in the first embodiment of the present invention.
FIG. 12 is a sequence diagram for explaining an operation procedure of the second embodiment of the present invention in a case where communication between the node 14 and the router 22 is encrypted with a different encryption key for each node 14 or authentication information is added. is there.
FIG. 13 is a simplified view of a public wireless LAN access service system according to a second embodiment of the present invention, focusing on links (subnets) accommodating nodes 14.
FIG. 14 is a schematic configuration diagram of a router 22 used in the second embodiment of the present invention.
15 is a diagram showing an example of registered contents of an IP address management table 229 shown in FIG.
FIG. 16 is a sequence diagram for explaining an operation procedure according to the second embodiment of the present invention in a case where communication is performed between the node and the AP 12 by encrypting with a different encryption key for each node 14;
FIG. 17 is a sequence diagram for explaining an operation procedure following FIG. 16 in the second embodiment of the present invention.
FIG. 18 is a sequence diagram illustrating an operation procedure of IPv6 automatic configuration.
[Explanation of symbols]
10 spot, 12 AP, 14 node, 16 ADSL modem, 20 ISP, 22 router, 24 RADIUS server, 26 GW, 28 management device, 30 DSLAM, 40 IPv6 network, 121 Wireless IF section, 122 LAN connector, 123 PHY processing section, 124 MACFWD section, 125 PROC section, 126 bus, 127 MAC address table, 221 LAN connector, 222 LAN connector, 223 PHY processing section 224 IPv6 processing unit 225 PROC unit 226 bus 227 routing table 228 user management table 229 IP address management table

Claims

An IPv6 node accommodating method for accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes in a router by a LAN (Local Area Network),
The router generates an ICMP (Internet Control Message Protocol) message indicating a router advertisement in which a unique prefix is set for each IPv6 node, and transmits the ICMP message to an IPv6 packet in which a multicast IP address is set as a destination IP address. And stores the IPv6 packet in a MAC frame in which the MAC address of an IPv6 node to which the unique network prefix is to be set at a destination MAC (Media Access Control) address is transmitted to the LAN. A method for accommodating IPv6 nodes.

The IPv6 node accommodating method according to claim 1, wherein
The IPv6 node accommodating method, wherein the router obtains a MAC address of the IPv6 node through authentication of the IPv6 node by an authentication server connected to the router.

An IPv6 node accommodating method for accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes in a router by a LAN (Local Area Network),
In addition to prohibiting address duplication notification between IPv6 nodes,
The router manages the IP address and the MAC (Media Access Control) address of each IPv6 node that has been successfully authenticated by the authentication server connected to the router, and receives the address duplication inquiry from the IPv6 node. Determining whether the target IP address is being used by another IPv6 node, and if so, sending an address duplication notification to the inquired IPv6 node. Containment method.

The IPv6 node accommodating method according to claim 3, wherein
When the router receives an address duplication inquiry from an IPv6 node, the router compares the target IP address of the inquiry with the MAC address of the inquired IPv6 node, and the target IP address is generated on a MAC address basis. A method for accommodating an IPv6 node, comprising: judging whether or not an IPv6 node has been used on a MAC address basis, and notifying the IPv6 node that made the inquiry of address duplication.

The IPv6 node accommodating method according to claim 1, 2, 3, or 4,
An IPv6 node accommodating method, wherein each of the plurality of IPv6 nodes performs communication using an encryption key that can be decrypted only by the router or a bridge that relays between the router and the plurality of IPv6 nodes.

An IPv6 node accommodating system comprising: a router accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes by a LAN (Local Area Network); and an authentication server for authenticating the plurality of IPv6 nodes.
The authentication server,
Generate a unique prefix to be assigned to the IPv6 node that has been successfully authenticated, and notify the router of the unique prefix together with the MAC (Media Access Control) address of the IPv6 node;
The router is
It generates an ICMP (Internet Control Message Protocol) message indicating a router advertisement in which a unique prefix notified by the authentication server is set, and converts the ICMP message into an IPv6 packet in which a multicast IP address is set as a destination IP address. Storing the IPv6 packet in a MAC frame in which a MAC address notified from the authentication server is set as a destination MAC address, and transmitting the IPv6 packet to the LAN.

An IPv6 node accommodating system comprising: a router accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes by a LAN (Local Area Network); and an authentication server for authenticating the plurality of IPv6 nodes.
Each of the plurality of IPv6 nodes performs communication using an encryption key that can be decrypted only by the router or a bridge that relays between the router and the plurality of IPv6 nodes,
The authentication server,
Notify the router of the MAC (Media Access Control) address of the IPv6 node that has been successfully authenticated,
The router is
While managing the MAC address notified by the authentication server and the IP address being used by the IPv6 node having the MAC address, when receiving an address duplication inquiry from the IPv6 node, the inquiry target IP address is set to another IP address. An IPv6 node accommodating system, wherein it is determined whether or not an IPv6 node is being used, and if it is being used, an address duplication notification is sent to the inquired IPv6 node.

A router accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes by a LAN (Local Area Network),
Generate an ICMP (Internet Control Message Protocol) message indicating a router advertisement in which a unique prefix is set for each IPv6 node, and store the ICMP message in an IPv6 packet in which a multicast IP address is set as a destination IP address; Further, the IPv6 packet is stored in a MAC frame in which a MAC address of an IPv6 node to which the unique network prefix is to be set in a destination MAC (Media Access Control) address is transmitted to the LAN. And router.

A router accommodating a plurality of IPv6 (Internet Protocol Version 6) nodes by a LAN (Local Area Network),
It manages the IP address and MAC (Media Access Control) address of each IPv6 node that has been successfully authenticated by the authentication server connected to itself, and, when receiving an address duplication inquiry from the IPv6 node, the target IP address of the inquiry Determining whether the IPv6 node is being used by another IPv6 node, and if so, sending an address duplication notification to the IPv6 node that made the inquiry.