JP2008244765A - 動的ホスト構成プロトコルサーバ及びｉｐアドレス割り当て方法 - Google Patents

Abstract

【課題】クライアント端末が接続する末端のネットワーク機器に特別な機能を必要とせずに、認証されたユーザに対してのみＩＰアドレスを提供できるようにする。
【解決手段】認証ＤＨＣＰサーバ１は、クライアントの物理アドレスに対応付けて当該クライアント端末の認証状態を管理するのに用いられるアドレス管理テーブル１１を有する。サーバ１の認証処理部１６は、ＩＰアドレス未割り当てのクライアントから送信された認証データを認証サーバに中継して認証を行わせる。サーバ１のＤＨＣＰ処理部１７は、要求された認証に成功した結果、アドレス管理テーブル１１によって認証済みとして管理されるクライアント端末にＩＰアドレスを割り当てる。サーバ１のＡＲＰ処理部１５は、認証済みとなっていないクライアントからのＡＲＰ要求に対して偽のＡＲＰ応答を返す。
【選択図】 図１

Description

本発明は、ネットワークに接続されたクライアント端末にＩＰアドレスを割り当てる動的ホスト構成プロトコルサーバ及びＩＰアドレス割り当て方法に関する。

ネットワークを介して通信を行うクライアント（クライアント端末）に、アドレス（ＩＰアドレス）を動的に配布する（割り当てる）サーバとして、ＤＨＣＰ（Dynamic Host Configuration Protocol：動的ホスト構成プロトコル）サーバが知られている。しかし、ＤＨＣＰサーバが適用するＤＨＣＰは、プロトコルにユーザ認証の概念が無いため、認証されたユーザに対してのみにＩＰアドレスを配布することができない。

ＤＨＣＰを使用するクライアントにアクセス制限をかける方法として、ＩＥＥＥで規定される８０２．１ｘに基づく認証スイッチを使用する方法が知られている。８０２．１ｘでは、認証スイッチとクライアントとの間の通信が、ＩＰヘッダを使用せずにデータリンク層のペイロードにＥＡＰＯＬ（EAP Over LAN）と呼ばれるフレームをセットすることによって行われる。ＥＡＰＯＬのデータ部には、認証データをＥＡＰＲＦＣ２２８４に規定されるＥＡＰ（Extensible Authentication Protocol: 拡張認証プロトコル）でカプセル化されたデータが格納される。認証スイッチと認証サーバ間の通信は、認証スイッチの持つＩＰアドレスと認証サーバのＩＰアドレスを使用してネットワーク（例えば基幹ＬＡＮ）を介して行われる。

認証プロトコルに関して認証スイッチは、クライアントが送信したＥＡＰＯＬパケットをＩＰパケットに変換して認証サーバにネットワークを介して中継する一方、認証サーバから基幹ＬＡＮを介して送信されたＩＰパケットをＥＡＰパケットに変換してクライアントに中継する。

ここで認証スイッチは、ユーザ認証が完了するまでは、認証パケットの全通信パケットを破棄するように設定されている。クライアントが認証スイッチに接続すると、当該認証スイッチは、認証要求（EAP Identity Request）を当該クライアントに対して送信する。クライアントは認証スイッチからの認証要求を受信すると、認証応答（EAP Identity Reply）を認証スイッチに送信する。

認証スイッチは、クライアントからの認証応答を、当該認証スイッチの持つＩＰアドレスと認証サーバのＩＰアドレスとを使用して、当該認証サーバに転送する。これにより、認証サーバにて認証プロトコルが実行される。

認証サーバによる認証に成功すると、認証スイッチは、クライアントのポートがネットワークに接続可能な状態にする。この状態でクライアントはＤＨＣＰサーバからＩＰアドレスを取得して、ネットワークと通信可能な状態となる。このように、８０２．１ｘに基づく認証スイッチを使用する方法によれば、クライアントがＤＨＣＰサーバからＩＰアドレスを取得する前に、ユーザ認証が可能となる。

上記の説明では、クライアントとネットワークとの間に１台の認証スイッチが存在するが、複数の認証スイッチがネットワークに対して階層的に接続されるのが一般的である。

ＤＨＣＰを使用するクライアントにアクセス制限をかける他の方法として、例えば特許文献１に記載されているような、認証ＶＬＡＮ（Virtual LAN）を使用する方法も知られている。この特許文献１に記載された方法では、ＶＬＡＮ対応のスイッチが用いられる。このスイッチは、全ポートをＤＨＣＰサーバと認証サーバにのみ接続可能なＶＬＡＮに設定する。このＶＬＡＮにクライアントが接続されると、ＤＨＣＰサーバが、当該クライアントに認証サーバと認証を行うためのＩＰアドレス（認証用ＩＰアドレス）を提供する。するとクライアントは、この認証用ＩＰアドレスを用いて認証サーバと認証（ユーザ認証）を行う。

認証に成功すると認証サーバは、ＤＨＣＰサーバにより、ネットワーク上のマシンと通信可能なＩＰアドレスをクライアントに配布させる。更に認証サーバは、スイッチに対しクライアントの接続するポートを、ネットワークに接続可能なＶＬＡＮに接続させる。これによりクライアントは、ＤＨＣＰサーバからＩＰアドレスを取得して、ネットワークと通信可能な状態となる。
特開２００４−６４２０４号公報

前述の認証スイッチを使用する方法では、認証スイッチがクライアントと認証サーバとの間の認証処理の中継を行うため、スイッチ自体が認証プロトコルを処理できなければならない。つまりクライアントが接続する末端のネットワーク機器が認証スイッチ（認証プロトコル対応）でなければならない。このためシステム構築の際に、末端のネットワーク機器を全て認証スイッチ（認証用ハブ）に切り替えなければならず、機器入れ替えの負荷が高くなる。同様に認証ＶＬＡＮを使用する方法でも、末端のネットワーク機器がＶＬＡＮに対応している必要がある。

本発明は上記事情を考慮してなされたものでその目的は、クライアント端末が接続する末端のネットワーク機器に特別な機能を必要とせずに、動的ホスト構成プロトコルを使用する環境で認証されたユーザに対してのみＩＰアドレスを提供できる動的ホスト構成プロトコルサーバ及びＩＰアドレス割り当て方法を提供することにある。

本発明の１つの観点によれば、ネットワークに接続されたクライアント端末にＩＰアドレスを割り当てる動的ホスト構成プロトコルサーバが提供される。この動的ホスト構成プロトコルサーバは、前記ネットワークに接続されたクライアント端末の物理アドレスに対応付けて当該クライアント端末の認証状態を保持する管理テーブルと、前記ネットワークとの間で通信データを送受信するネットワークインタフェースと、前記ネットワークに接続されたＩＰアドレス未割り当てのクライアント端末から送信された、認証を要求するための認証データを、前記ネットワークに接続された認証サーバに前記ネットワークインタフェースを介して中継する中継手段と、前記クライアント端末から要求された認証に成功したことが前記認証サーバによって通知された場合に、当該認証を要求した前記クライアント端末の物理アドレスに対応付けて前記管理テーブルに保持されている認証状態を、認証済みを示す状態に設定する認証処理手段と、前記認証済みを示す状態に設定された認証状態と対応付けて前記管理テーブルに保持されている物理アドレスのクライアント端末にＩＰアドレスを割り当てるＩＰアドレス割り当て手段と、前記ネットワークに接続されたクライアント端末からブロードキャストによって前記ネットワーク上に送信されたアドレス解決プロトコル要求が前記ネットワークインタフェースによって受信された場合に、前記管理テーブルを参照して当該アドレス解決プロトコル要求を送信したクライアント端末が認証済みであるかを判定し、認証済みでない場合に当該アドレス解決プロトコル要求を送信したクライアント端末に前記ネットワークインタフェースを介して偽のアドレス解決プロトコル応答を送信するアドレス解決プロトコル処理手段とを具備する。

本発明によれば、動的ホスト構成プロトコルサーバに、クライアント端末の物理アドレスに対応付けて当該クライアント端末の認証状態を管理する管理テーブルを持たせると共に、ＩＰアドレス未割り当てのクライアント端末から送信された認証データを認証サーバに中継して認証を行わせ、当該クライアント端末から要求された認証に成功した結果（つまり認証完了後に）、管理テーブルによって認証済みの状態となったクライアント端末にＩＰアドレスを割り当てる機能と、認証済みとなっていないクライアント端末からのアドレス解決プロトコル要求（ＡＲＰ要求）に対して偽のＡＲＰ応答を返すことで通信を妨害する機能とを持たせることにより、クライアント端末が接続する末端のネットワーク機器に特別な機能を必要とせずに、動的ホスト構成プロトコルを使用する環境でユーザ認証されたクライアント端末に対してのみ動的ホスト構成プロトコルサーバからＩＰアドレスを提供して当該クライアント端末を通信可能とするネットワークへのアクセス制御を実現できる。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る認証ＤＨＣＰサーバ（認証ＤＨＣＰサーバコンピュータ）を含むネットワークシステムの基本構成と動作原理を説明するための図である。図１において、認証ＤＨＣＰサーバ１及び認証サーバ２はネットワーク３に接続されている。ネットワーク３は例えばＩＰネットワークであり、ネットワークシステムの基幹ＬＡＮ（ローカルエリアネットワーク）として用いられているものとする。このネットワーク３には、クライアント（クライアント端末）４及び当該クライアント４の通信相手となる別のクライアント（クライアント端末）５が接続されている。図１のシステムでは、作図の都合上、２台のクライアント４及び５がネットワーク３に接続されているが、一般には３台以上のクライアントがネットワーク３に接続されている。

認証ＤＨＣＰサーバ１は、ＤＨＣＰを使用する環境でユーザ認証されたユーザ（クライアント）に対してのみＩＰアドレスを提供可能とするための、ネットワーク３へのアクセス制御を行うネットワークアクセス制御装置として機能する。

認証サーバ２は、例えばＩＥＥＥで規定される８０２．１ｘに対応する、ラジウスサーバ（ＲＡＤＩＵＳサーバ）のような一般的な認証サーバである。

クライアント４は、ＤＨＣＰクライアントとしての機能を有し、更に認証（例えばＩＥＥＥで規定される８０２．１ｘ認証）における認証クライアント（例えば「Supplicant」）の機能を有すものとする。これらの機能は、一般的にクライアントソフトウェアとして使用されている汎用ＯＳ（オペレーティングシステム）に標準的に搭載されているものであり、特別なクライアントソフトウェアを必要としない。

次に、図１のシステムにおける認証ＤＨＣＰサーバ１を中心とする、ＩＰアドレス割り当てを含むネットワークアクセス制御に関する動作の概要について説明する。
図１のシステムにおいて、クライアント４が認証ＤＨＣＰサーバ１に対して、ＤＨＣＰプロトコルによりＩＰアドレスを要求したものとする（ステップＳ１）。すると認証サーバは、クライアント４との間のＤＨＣＰプロトコルを中断し、直ちに当該クライアント４に対しＥＡＰプロトコルによる認証開始要求を送信する（ステップＳ２）。

クライアント４は、「Supplicant」の機能によりＥＡＰプロトコルを使用してユーザ認証を開始する（ステップＳ３）。ＥＡＰによる認証は、ＥＡＰＯＬを使用したＩＰヘッダを使用しない通信となるため、ＩＰアドレスを取得する前でも通信可能となる。このステップＳ３では、認証ＤＨＣＰサーバ１がクライアント４と認証サーバ２との間でＥＡＰＯＬを使用した認証を中継する。

認証が完了すると、認証ＤＨＣＰサーバ１は、中断していたクライアント４とのＤＨＣＰプロトコルを再開し、当該クライアント４に対してＩＰアドレスを配布する（ステップＳ４）。これによりクライアント４は、認証ＤＨＣＰサーバ１から配布されたＩＰアドレスを取得し、当該ＩＰアドレスを使用してネットワーク３経由で、例えばクライアント５と通信を行う（ステップＳ５）。

なお、図１のシステムでは、クライアント４及びクライアント５は、同一のネットワーク３（つまりネットワークアドレスが同一のネットワーク３）に接続されている。しかし、クライアント５がネットワーク３とはネットワークアドレスが異なる別のネットワークに接続されて、当該両ネットワークがルータによって接続されていても構わない。

図１のシステムにおいて、認証ＤＨＣＰサーバ１は、認証されていない不正な端末を通信できない状態にするための仕組み（つまり不正な端末がネットワーク３に接続するのを防ぐ仕組み）を有している。以下、この仕組みについて、図２を参照して説明する。ここでは便宜的に、クライアント４が、認証されていない不正な端末（つまり認証ＤＨＣＰサーバ１からＩＰアドレスが配布されていない）不正な端末であるとする。

今、不正な端末（クライアント４）が、ネットワーク３上の他のマシン（例えばクライアント５）と通信を行うのに必要な当該他のマシンのＭＡＣアドレス（つまり物理アドレス）を取得するためのＡＲＰ（Address Resolution Protocol：アドレス解決プロトコル）要求を、ネットワーク３上にブロードキャストしたものとする（ステップＳ１１）。このＡＲＰ要求は、送信元ＩＰアドレス及び送信元ＭＡＣアドレスを含む。

認証ＤＨＣＰサーバ１は、ＡＲＰ要求を受信すると、当該ＡＲＰ要求に含まれている送信元ＩＰアドレスが自身が配布していないＩＰアドレス（認証サーバを除く）であるか、或いは当該ＡＲＰ要求に含まれている送信元ＭＡＣアドレスがＩＰアドレスを配布したクライアント以外のＭＡＣアドレス（認証サーバを除く）であるかにより、当該ＡＲＰ要求を送信したクライアントが認証されていない不正な端末であるかを判定する。

もし、ＡＲＰ要求の送信元（図２ではクライアント４）が不正な端末である場合、認証ＤＨＣＰサーバ１は、当該送信元（クライアント４）がネットワーク３に接続するのを防ぐため、直ちに偽のＡＲＰ応答を当該送信元（クライアント４）に送信する（ステップＳ１２）。このＡＲＰ応答、即ち不正な端末（クライアント４）からのＡＲＰ要求に対する偽のＡＲＰ応答は、当該ＡＲＰ要求で要求されたマシン（端末）のＭＡＣアドレスとして、認証ＤＨＣＰサーバ１がＩＰアドレスを配布した全ての端末のいずれのＭＡＣアドレスとも異なるＭＡＣアドレスを含む。このような偽のＡＲＰ応答により、認証ＤＨＣＰサーバ１は、不正な端末（クライアント４）がネットワーク３を介して通信するのを妨害する。つまり認証ＤＨＣＰサーバ１は、偽のＡＲＰ応答により、不正な端末（クライアント４）が通信できない状態にする。

次に、図１のシステムにおいて、例えばクライアント４がユーザ認証を行いＩＰアドレスを取得するまでの通信シーケンスの詳細について、図３のシーケンスチャート及び図４Ａ乃至図４Ｃの通信データのフォーマットを参照して説明する。

クライアント４はまず、ネットワーク３上のＤＨＣＰサーバ（ここでは認証ＤＨＣＰサーバ１）を検出するための、例えばＤＨＣＰディスカバー（DHCP Discover）と呼ばれるＤＨＣＰ（動的ホスト構成プロトコル）に従うデータ（特定パケット）を含む、図４Ａ（ａ）に示すフォーマットの通信データ４０１をブロードキャストで送信する（ステップＳ２１）。

通信データ４０１は、データリンク層ヘッダを含むデータリンク層パケットである。データリンク層パケットのペイロード（データリンク層ペイロード）は、ＩＰヘッダ、ＵＤＰ（User Datagram Protocol）ヘッダ及びＵＤＰのペイロードを含む。

通信データ４０１のデータリンク層ヘッダは、宛先ＭＡＣアドレスと送信元ＭＡＣアドレスとを含む。ここでは、宛先ＭＡＣアドレスにはブロードキャストアドレスが、送信元ＭＡＣアドレスにはクライアント４のＭＡＣアドレスが、それぞれ用いられる。通信データ４０１のＩＰヘッダは、宛先ＩＰアドレスと送信元ＩＰアドレスとを含む。ここでは、宛先ＩＰアドレスにはブロードキャストアドレスが、送信元ＩＰアドレスにはＤＨＣＰ（動的ホスト構成プロトコル）に従ってＤＨＣＰサーバ（ここでは認証ＤＨＣＰサーバ１）を検出する際に用いられる特定のＩＰアドレス（例えば“０．０．０．０”）が、それぞれ用いられる。通信データ４０１のＵＤＰペイロードには、「DHCP Discover」（のデータ）が設定される。

認証ＤＨＣＰサーバ１は、クライアント４から送信された通信データ４０１を受信すると、当該クライアント４との間のＤＨＣＰ（動的ホスト構成プロトコル）を中断する。そして認証ＤＨＣＰサーバ１は認証を開始するために、通信データ４０１の送信元のクライアント４に対して、拡張認証プロトコルに従うＥＡＰリクエスト（EAP Request）と呼ばれる特別のコードを含む、図４Ａ（ｂ）に示すフォーマットの通信データ４０２を送信する（ステップＳ２２）。

通信データ４０２は、データリンク層ヘッダとＥＡＰＯＬパケット（ＥＡＰＯＬフレーム）とを含むデータリンク層パケットである。ＥＡＰＯＬパケットは、データリンク層パケットのペイロードをなし、当該ＥＡＰＯＬパケットのデータ部に上記「EAP Request」が設定される。ここでは、ＥＡＰのデータ部（ユーザ認証プロトコルのデータ部）には何も格納されない。

通信データ４０２のデータリンク層ヘッダは、通信データ４０１のそれと同様に、宛先ＭＡＣアドレスと送信元ＭＡＣアドレスとを含む。ここでは、宛先ＭＡＣアドレスには、図４Ａ（ｂ）において矢印４０３で示されるように、通信データ４０１のデータリンク層ヘッダに含まれている送信元ＭＡＣアドレス（クライアント４のＭＡＣアドレス）が用いられる。また送信元ＭＡＣアドレスには、認証ＤＨＣＰサーバ１のＭＡＣアドレスが用いられる。

クライアント４は、認証ＤＨＣＰサーバ１から送信されたＥＡＰリクエストを含む通信データ４０２を受信すると、ユーザ認証を行うための、ユーザＩＤを格納したラジウスアクセスリクエスト（Radius Access Request）と呼ばれる特別のリクエストを生成する。そしてクライアント４は、この「Radius Access Request」がデータとして格納された（つまりＥＡＰでカプセル化された）ＥＡＰ応答（EAP Response）を含む、図４Ａ（ｃ）に示すフォーマットの通信データ４０４（第１の認証データ）を生成する。

通信データ４０４は、データリンク層ヘッダとＥＡＰＯＬパケット（ＥＡＰＯＬフレーム）とを含むデータリンク層パケットである。ＥＡＰＯＬパケットのデータ部には「EAP Response」が設定され、ＥＡＰのデータ部（ユーザ認証プロトコルのデータ部）には上記「Radius Access Request」が格納される。通信データ４０４のデータリンク層ヘッダの宛先ＭＡＣアドレスには、図４Ａ（ｂ）において矢印４０５で示されるように、受信された通信データ４０２のデータリンク層ヘッダに含まれている送信元ＭＡＣアドレス（認証ＤＨＣＰサーバ１のＭＡＣアドレス）が用いられる。また送信元ＭＡＣアドレスには、クライアント４のＭＡＣアドレスが用いられる。
クライアント４は、生成された通信データ４０４を認証ＤＨＣＰサーバ１に送信する（ステップＳ２３）。即ちクライアント４は、ユーザＩＤが格納された「Radius Access Request」を、「EAP Response」により認証ＤＨＣＰサーバ１に送信する。

認証ＤＨＣＰサーバ１は、クライアント４から送信された通信データ４０４を受信すると、図４Ａ（ｄ）において矢印４０６で示されるように、当該通信データ４０４に含まれている「EAP Response」のデータ部に格納された「Radius Access Request」を取り出す。そして認証ＤＨＣＰサーバ１は、取り出された「Radius Access Request」がＵＤＰのペイロードに格納された、図４Ａ（ｄ）に示すフォーマットの通信データ４０７（第２の認証データ）を生成する。つまり認証ＤＨＣＰサーバ１は、クライアント４から送信された通信データ４０４（第１の認証データ）を通信データ４０７（第２の認証データ）に変換する。

通信データ４０７は、データリンク層ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ及びＵＤＰのペイロードを含む。通信データ４０７のデータリンク層ヘッダの宛先ＭＡＣアドレス及び送信元ＭＡＣアドレスには、それぞれ、認証サーバ２のＭＡＣアドレス及び認証ＤＨＣＰサーバ１のＭＡＣアドレスが用いられる。通信データ４０７のＩＰヘッダの宛先ＩＰアドレス及び送信元ＩＰアドレスには、それぞれ、認証サーバ２のＩＰアドレス及び認証ＤＨＣＰサーバ１のＩＰアドレスが用いられる。通信データ４０７のＵＤＰのペイロードには、通信データ４０４のＥＡＰのデータ部から取り出された「Radius Access Request」が格納される。
認証ＤＨＣＰサーバ１は、生成（変換）された通信データ４０７を認証サーバ２に送信（中継）する（ステップＳ２４）。

認証サーバ２は、認証ＤＨＣＰサーバ１によって中継された「Radius Access Request」を含む通信データ４０７を受信すると、ラジウスアクセスチャレンジ（Radius Access Challenge）と呼ばれる認証プロトコル（ユーザ認証プロトコル）のデータを含む、図４Ｂ（ａ）に示すフォーマットの通信データ４０８（第３の認証データ）を生成する。

「Radius Access Challenge」には、ユーザ認証のためのチャレンジ（Challenge）コードが格納されている。このChallengeコードは、受信された通信データ４０７に含まれる「Radius Access Request」に格納されているユーザＩＤに基づいて生成される。つまりChallengeコードは、このユーザＩＤに対応するデータである。

通信データ４０８は、データリンク層ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ及びＵＤＰのペイロードを含むデータリンク層パケットである。ＵＤＰのペイロードには、上述の「Radius Access Challenge」が格納される。

通信データ４０８のデータリンク層ヘッダの宛先ＭＡＣアドレス及びＩＰヘッダの宛先ＩＰアドレスには、それぞれ、認証ＤＨＣＰサーバ１のＭＡＣアドレス及びＩＰアドレスが用いられる。認証サーバ２は、この通信データ４０８を認証ＤＨＣＰサーバ１に送信する（ステップＳ２５）。

認証ＤＨＣＰサーバ１は、認証サーバ２から送信された通信データ４０８を受信すると、図４Ｂ（ａ）において矢印４０９で示されるように、当該通信データ４０８から「Radius Access Challenge」を取り出す。そして認証ＤＨＣＰサーバ１は、「EAP Request」のデータ部に、通信データ４０８から取り出された「Radius Access Challenge」が格納された（つまり「Radius Access Challenge」がＥＡＰでカプセル化された）、図４Ｂ（ａ）に示すフォーマットの通信データ４１０（第４の認証データ）を生成する。つまり認証ＤＨＣＰサーバ１は、認証サーバ２から送信された通信データ４０８（第３の認証データ）を通信データ４１０（第４の認証データ）に変換する。

通信データ４１０はデータリンク層ヘッダを含み、当該ヘッダの宛先ＭＡＣアドレスにはクライアント４のＭＡＣアドレスが用いられる。認証ＤＨＣＰサーバ１は、この通信データ４１０をクライアント４に対して送信（中継）する（ステップＳ２６）。

クライアント４は、認証ＤＨＣＰサーバ１から送信された、「EAP Request」を含む通信データ４１０を受信すると、当該「EAP Request」のデータ部、つまり「Radius Access Challenge」に格納されているChallengeコードに基づいて、応答（Response）コードを生成する。そしてクライアント４は、この応答（Response）コードを含む「Radius Access Request」がデータとして格納された（つまりＥＡＰでカプセル化された）「EAP Response」を含む、図４Ｂ（ｂ）に示すフォーマットの通信データ４１１（第１の認証データ）を生成する。

通信データ４１１は通信データ４０４と同様に、データリンク層ヘッダとＥＡＰＯＬパケット（ＥＡＰＯＬフレーム）とを含むデータリンク層パケットである。ＥＡＰＯＬパケットのデータ部には「EAP Response」が設定され、ＥＡＰのデータ部（ユーザ認証プロトコルのデータ部）には上記応答（Response）コードを含む「Radius Access Request」が格納される。通信データ４１１のデータリンク層ヘッダの宛先ＭＡＣアドレスには、認証ＤＨＣＰサーバ１のＭＡＣアドレスが用いられる。

クライアント４は、生成された通信データ４１１を認証ＤＨＣＰサーバ１に送信する（ステップＳ２７）。即ちクライアント４は、Challengeコードに基づいて生成された応答（Response）コードが格納された「Radius Access Request」を、「EAP Response」により認証ＤＨＣＰサーバ１に送信する。

認証ＤＨＣＰサーバ１は、クライアント４から送信された通信データ４１１（EAP Response）を受信すると、図４Ｂ（ｂ）において矢印４１２で示されるように、当該通信データ４１１に含まれている「EAP Response」のデータ部に格納された「Radius Access Request」を取り出す。そして認証ＤＨＣＰサーバ１は、取り出された「Radius Access Request」がＵＤＰのペイロードに格納された、図４Ｂ（ｂ）に示すフォーマットの通信データ４１３（第２の認証データ）を生成する。つまり認証ＤＨＣＰサーバ１は、クライアント４から送信された通信データ４１１（第１の認証データ）を通信データ４１３（第２の認証データ）に変換する。

通信データ４１３は通信データ４０７と同様に、データリンク層ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ及びＵＤＰのペイロードを含む。通信データ４１３のデータリンク層ヘッダの宛先ＭＡＣアドレス及びＩＰヘッダの宛先ＩＰアドレスには、それぞれ、認証サーバ２のＭＡＣアドレス及びＩＰアドレスが用いられる。通信データ４１３のＵＤＰのペイロードには、通信データ４１１のＥＡＰのデータ部から取り出された「Radius Access Request」が格納される。認証ＤＨＣＰサーバ１は、この通信データ４１３を認証サーバ２に送信（中継）する（ステップＳ２８）。

認証サーバ２は、認証ＤＨＣＰサーバ１から送信された「Radius Access Request」を含む通信データ４１３を受信すると、当該「Radius Access Request」に格納されている応答（Response）コードを取り出す。そして認証サーバ２は、取り出されたResponseコードが、ユーザ認証のために送信したChallengeコードに対応しているかをチェックする。

対応している場合、認証サーバ２は、認証が成功したことを通知するためのラジウスアクセスアクセプト（Radius Access Accept）を生成する。そして認証サーバ２は、この「Radius Access Accept」がＵＤＰのペイロードに格納された、図４Ｂ（ｃ）に示すフォーマットの通信データ４１４を生成する。

通信データ４１４はデータリンク層ヘッダ及びＩＰヘッダを含み、当該データリンク層ヘッダの宛先ＭＡＣアドレス及びＩＰヘッダの宛先ＩＰアドレスには、それぞれ、認証ＤＨＣＰサーバ１のＭＡＣアドレス及びＩＰアドレスが用いられる。認証サーバ２は、この通信データ４１４を認証ＤＨＣＰサーバ１に送信する（ステップＳ２９）。

認証ＤＨＣＰサーバ１は、認証サーバ２から送信された「Radius Access Accept」を含む通信データ４１４を受信すると、認証が成功したことを通知するためのＥＡＰ成功（EAP Success）と呼ばれる特別のコードを含む、図４Ｃ（ａ）に示すフォーマットの通信データ４１５を、クライアント４に送信する（ステップＳ３０）。

通信データ４１５は、データリンク層ヘッダとＥＡＰＯＬパケットとを含むデータリンク層パケットである。ＥＡＰＯＬパケットのデータ部には上記ＥＡＰ成功（EAP Success）が設定される。通信データ４１５のデータリンク層ヘッダの宛先ＭＡＣアドレスにはクライアント４のＭＡＣアドレスが用いられる。

認証ＤＨＣＰサーバ１は、ＥＡＰ成功（EAP Success）を含む通信データ４１５をクライアント４に送信すると、中断していたクライアント４との間のＤＨＣＰ（動的ホスト構成プロトコル）を再開する。そして認証ＤＨＣＰサーバ１は、認証が成功したクライアントにＩＰアドレスを配布することを宣言するＤＨＣＰオファー（DHCP Offer）と呼ばれる特別のパケット（DHCP Offerパケット）を含む、図４Ｃ（ｂ）に示すフォーマットの通信データ４１６を、クライアント４に送信する（ステップＳ３１）。この通信データ４１６は、データリンク層ヘッダ、ＩＰヘッダ及びＵＤＰヘッダ及びＵＤＰのペイロードを含む。通信データ４１６のデータリンク層ヘッダの宛先ＭＡＣアドレス及びＩＰヘッダの宛先ＩＰアドレスには、それぞれ、クライアント４のＭＡＣアドレス及びブロードキャストアドレスが用いられる。上記「DHCP Offer」（のデータ）は、通信データ４１６のＵＤＰのペイロードに格納される。

認証ＤＨＣＰサーバ１は、生成された通信データ４１６をクライアント４に送信する（ステップＳ３１）。即ち認証ＤＨＣＰサーバ１は、認証が成功したクライアントにＩＰアドレスを配布するための「DHCP Offer」をクライアント４に送信する。

クライアント４は、認証ＤＨＣＰサーバ１から送信された通信データ４１６（DHCP Offer）を受信すると、以下に述べるように、ＤＨＣＰ（動的ホスト構成プロトコル）の標準的なシーケンスでＩＰアドレスを取得する。

まずクライアント４は、自身に配布されるべきＩＰアドレスを取得するためのＤＨＣＰリクエスト（DHCP Request）と呼ばれる特別のパケットを含む、図４Ｃ（ｃ）に示すフォーマットの通信データ４１７を生成する。

通信データ４１７は、データリンク層ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ及びＵＤＰのペイロードを含むデータリンク層パケットである。ＵＤＰのペイロードには、上述の「DHCP Request」（のデータ）が格納される。

通信データ４１７のデータリンク層ヘッダの宛先ＭＡＣアドレス及び送信元ＭＡＣアドレスには、それぞれ、ブロードキャストアドレス及びクライアント４のＭＡＣアドレスがが用いられる。通信データ４１７のＩＰヘッダの宛先ＩＰアドレス及び送信元ＩＰアドレスには、それぞれ、ブロードキャストアドレス及び前記特定のＩＰアドレス（“０．０．０．０”）が、それぞれ用いられる。

クライアント４は、生成された通信データ４１７を認証ＤＨＣＰサーバ１に送信する（ステップＳ３２）。即ちクライアント４は、「DHCP Request」を認証ＤＨＣＰサーバ１に送信する。

認証ＤＨＣＰサーバ１は、認証が成功しているクライアント４から送信された通信データ４１７（DHCP Request）を受信すると、当該クライアント４に配布されるＩＰアドレスが格納されたＤＨＣＰ承認（DHCP ACK）と呼ばれる特別のパケット（DHCP ACKパケット）を含む、図４Ｃ（ｄ）に示すフォーマットの通信データ４１８を生成する。この通信データ４１８のデータリンク層ヘッダの宛先ＭＡＣアドレス及び送信元ＭＡＣアドレスには、それぞれ、クライアント４のＭＡＣアドレス及び認証ＤＨＣＰサーバ１のＭＡＣアドレスが用いられる。通信データ４１８のＩＰヘッダの宛先ＩＰアドレス及び送信元ＩＰアドレスには、それぞれ、ブロードキャストアドレス及び認証ＤＨＣＰサーバ１のＩＰアドレスが用いられる。上記「DHCP ACK」（のデータ）は、通信データ４１8のＩＰペイロードに格納される。「DHCP ACK」は、クライアント４に配布される（割り当てられる）ＩＰアドレスを含む。

認証ＤＨＣＰサーバ１は、生成された通信データ４１８をクライアント４に送信する（ステップＳ３３）。即ち認証ＤＨＣＰサーバ１は、認証が成功したクライアント４に「DHCP ACK」を送信することにより、当該クライアント４に対してＩＰアドレスを配布する。クライアント４は、認証ＤＨＣＰサーバ１から送信される通信データ４１８（DHCP ACK）を受信することにより、ＩＰアドレスを取得する。以後、クライアント４は、このＩＰアドレスを用いてネットワーク３に接続して当該ネットワーク３上の他のクライアント（例えばクライアント５）と通信可能な状態となる。

このように、本実施形態で適用される認証ＤＨＣＰサーバ１は、クライアント（ここではクライアント４）からブロードキャストで送信されたDHCP Discoverパケットの受信をトリガとして、ＤＨＣＰ（動的ホスト構成プロトコル）を中断して認証（認証の代行）を開始し、以後ＥＡＰＬＯを使用した認証を中継して、認証されたクライアントにＩＰアドレスを割り当てるように構成されている。これによりクライアントは、ＤＨＣＰクライアントとしての機能と８０２．１ｘ認証におけるＳｕｐｐｌｉｃａｎｔ（認証クライアント）の機能とを有しているならば、特別な機能を必要とせずにＩＰアドレスを取得することができる。

次に、認証ＤＨＣＰサーバ１が、ＩＰアドレスを配布していない不正な端末を通信できない状態にする通信シーケンスの詳細について、図５のシーケンスチャート及び図６の通信データのフォーマットを参照して説明する。ここでは、図３の場合と異なって、クライアント４が認証ＤＨＣＰサーバ１からＩＰアドレスが配布されていない不正な端末であるものとする。

今、不正な端末であるクライアント４が、例えばクライアント５との通信のために、当該クライアント５（通信相手）のＭＡＣアドレスを取得する必要があるものとする。この場合、クライアント４は、クライアント５（つまりターゲット）のＩＰアドレスをＭＡＣアドレスに解決するための、図６に示すフォーマットのＡＲＰ要求６０１をブロードキャストでネットワーク３上に送信する（ステップＳ４１）。

ＡＲＰ要求６０１は、データリンク層ヘッダ及びＡＲＰ要求パケットを含む。データリンク層ヘッダの宛先ＭＡＣアドレス及び送信元ＭＡＣアドレスには、それぞれ、ブロードキャストアドレス及びクライアント４（不正な端末）のＭＡＣアドレスが用いられる。ＡＲＰ要求パケットは、ターゲットＭＡＣアドレス及びターゲットＩＰアドレス、並びに送信元ＭＡＣアドレス及び送信元ＩＰアドレスを含む。ＡＲＰ要求パケットの送信元ＭＡＣアドレス及び送信元ＩＰアドレスには、クライアント４（不正な端末）のＭＡＣアドレス及びＩＰアドレス（認証ＤＨＣＰサーバ１によってクライアント４に配布されていないＩＰアドレス）が用いられる。

認証ＤＨＣＰサーバ１は、ネットワーク３からＡＲＰ要求６０１を受信すると、当該ＡＲＰ要求６０１のＡＲＰ要求パケットに含まれている送信元ＩＰアドレス及び送信元ＭＡＣアドレスをチェックする。そして認証ＤＨＣＰサーバ１は、ＡＲＰ要求パケットに含まれている送信元ＩＰアドレスが自身が配布していないＩＰアドレス（認証サーバを除く）であるか、或いは当該ＡＲＰ要求に含まれている送信元ＭＡＣアドレスがＩＰアドレスを配布したクライアント以外のＭＡＣアドレス（認証サーバを除く）である場合、ＡＲＰ要求６０１の送信元（ここではクライアント４）は不正な端末であると判定する。

すると認証ＤＨＣＰサーバ１は、ＡＲＰ要求６０１の送信元（ここではクライアント４）がネットワーク３に接続するのを防止するために、直ちに図６に示すフォーマットの偽のＡＲＰ応答６０２を当該送信元（クライアント４）に送信する（ステップＳ４２）。偽のＡＲＰ応答６０２の送信元ＭＡＣアドレスには、偽のＭＡＣアドレスが用いられる。偽のＭＡＣアドレスとは実在しないＭＡＣアドレスを指す。ここでは、ＭＡＣアドレスの上位３バイトに相当するベンダＩＤに、存在しない値が用いられたＭＡＣアドレスが、偽のＭＡＣアドレスとして用いられる。

認証ＤＨＣＰサーバ１からの偽のＡＲＰ応答６０２を受信した不正な端末（クライアント４）は、当該ＡＲＰ応答６０２に含まれている偽のＭＡＣアドレスを宛先ＭＡＣアドレスとする通信データを送信する（ステップＳ４３）。この場合、不正な端末（クライアント４）は、偽の宛先ＭＡＣアドレスのために通信ができない状態となる。即ち、認証ＤＨＣＰサーバ１は、不正な端末（クライアント４）からのＡＲＰ要求６０１に対して偽のＡＲＰ応答６０２を返すことで、不正な端末（クライアント）の通信を妨害する。

図７は認証ＤＨＣＰサーバ１の構成を示すブロック図である。認証ＤＨＣＰサーバ１は、アドレス管理テーブル１１と、テーブル管理部１２と、ネットワークＩＦ（ネットワークインタフェース）１３と、パケット処理部１４と、ＡＲＰ処理部１５と、認証処理部１６と、ＤＨＣＰ処理部１７とを含む。

図８はアドレス管理テーブル１１のデータ構造例を示す。アドレス管理テーブル１１のエントリは、認証中のクライアント、認証済みのクライアント、認証サーバ２、或いはルータのような機器のアドレス情報を格納するのに用いられる。アドレス管理テーブル１１のエントリは、ＭＡＣアドレス、ＩＰアドレス、状態（ステータス）、認証子、ＩＤ及び有効期限をそれぞれ保持するためのフィールド（ＭＡＣアドレスフィールド、ＩＰアドレスフィールド、状態フィールド、認証子フィールド、ＩＤフィールド及び有効期限フィールド）から構成される。以下、上記各フィールドについて説明する。

＜ＭＡＣアドレスフィールド＞
ＭＡＣアドレスフィールドは、認証中のクライアント、認証済みのクライアント、認証サーバ２、或いはルータのような機器のＭＡＣアドレスを保持するのに用いられる。

＜ＩＰアドレスフィールド＞
ＩＰアドレスフィールドは、ＭＡＣアドレスフィールドに保持されているＭＡＣアドレスの機器のＩＰアドレスを保持するのに用いられる。認証中のクライアントの場合、ＩＰアドレスフィールドには所定のＩＰアドレス「０．０．０．０」が保持される。認証済みのクライアントの場合、ＩＰアドレスフィールドには、ＤＨＣＰ処理部１７によって割り当てられたＩＰアドレスが保持される。

＜状態フィールド＞
状態フィールドは、ＭＡＣアドレスフィールドに保持されているＭＡＣアドレスの機器の状態を保持するのに用いられる。この状態は、「認証中」及び「認証済」の２種類であるものとする。例えば、クライアントの場合、当該クライアントが「DHCP Discover」を送信すると、状態フィールドは「認証中」を示す状態に設定される。その後、クライアントが認証を完了し、認証サーバから「Radius Access Accept」を受信すると、状態フィールドは「認証済」を示す状態に切り替えされる。また、認証サーバ２或いはルータのような機器の場合、状態フィールドは「認証済」を示す状態に設定される。

＜認証子フィールド＞
認証子フィールドは、ＭＡＣアドレスフィールドに保持されているＭＡＣアドレスの機器がクライアントの場合に、当該クライアントと認証サーバ２との間の認証プロトコルのセッションを識別するのに用いられる。認証子フィールドには、認証で使用されるラジウス（Radius）パケットの認証子フィールドの値が保持される。また認証サーバ２或いはルータのような機器の場合、認証子フィールドには例えば所定値「０」が保持される。

＜ＩＤフィールド＞
ＩＤフィールドは、ＭＡＣアドレスフィールドに保持されているＭＡＣアドレスの機器がクライアントの場合に、当該クライアントと認証ＤＨＣＰサーバ１との間のＤＨＣＰ（動的ホスト構成プロトコル）のセッションを識別するのに用いられる。ＩＤフィールドには、ＤＨＣＰで使用される、ＤＨＣＰパケットのトランザクションＩＤフィールドの値が保持される。また認証サーバ２或いはルータのような機器の場合、ＩＤフィールドには例えば所定値「０」が保持される。

＜有効期限フィールド＞
有効期限フィールドは、当該フィールドを含むアドレス管理テーブル１１内のエントリ（対応するエントリ）の情報（アドレス情報）の有効期限を示すのに用いられる。このフィールドの値は、テーブル管理部１２により定期的にデクリメントされ、値が０となると、対応するエントリの情報はアドレス管理テーブル１１から削除される。認証サーバ２或いはルータのような機器に対応するエントリの有効期限フィールドの値は、例えば所定値−１に保持され、定期的なデクリメントの対象とならない。つまり、認証サーバ２或いはルータのような機器のアドレス情報は、アドレス管理テーブル１１に静的に登録される。

次に、認証ＤＨＣＰサーバ１におけるテーブル管理部１２の処理について、図９のフローチャートを参照して説明する。テーブル管理部１２はアドレス管理テーブル１１を定期的に監視する。ここではアドレス管理テーブル１１は、例えば１秒間隔で監視されるものとする。

まずテーブル管理部１２は、アドレス管理テーブル１１から未処理のエントリの情報を取り出して（ステップＳ５１）、当該エントリ中の有効期限フィールドの値をチェックする（ステップＳ５２，Ｓ５３）。もし、有効期限フィールドの値が０であるならば（ステップＳ５２）、テーブル管理部１２は、当該有効期限フィールドを含むアドレス管理テーブル１１内のエントリ（対応するエントリ）の情報を、アドレス管理テーブル１１から削除する（ステップＳ５４）。

これに対し、有効期限フィールドの値が−１であるならば（ステップＳ５３）、テーブル管理部１２は、対応するエントリに認証サーバ２或いはルータのような機器のアドレス情報が静的に登録されていると判定する。この場合、テーブル管理部１２は対応するエントリに対して何も操作しない。また、有効期限フィールドの値が０でも−１でもないならば（ステップＳ５２，Ｓ５３）、テーブル管理部１２は当該有効期限フィールドの値を１デクリメントする（ステップＳ５５）。

テーブル管理部１２は、以上の処理を、アドレス管理テーブル１１の全てのエントリに対して繰り返し実行して（ステップＳ５６）、処理を終了する。

次に、認証ＤＨＣＰサーバ１におけるネットワークＩＦ１３の処理について、図１０のフローチャートを参照して説明する。
ネットワークＩＦ１３は、ネットワーク３から通信データを受信すると、当該通信データをテーブル管理部１２内のパケット処理部１４に転送する（ステップＳ６０）。またネットワークＩＦ１３は、ＡＲＰ処理部１５、認証処理部１６及びＤＨＣＰ処理部１７のいずれかから送信用の通信データが入力されると、当該通信データをネットワーク３に送信する（ステップＳ７０）。このようにネットワークＩＦ１３は、ネットワーク３と認証ＤＨＣＰサーバ１との間で通信データの送受信を行う。

次に、認証ＤＨＣＰサーバ１におけるパケット処理部１４の処理について、図１１のフローチャートを参照して説明する。
パケット処理部１４は、ネットワークＩＦ１３によって受信された通信データが当該パケット処理部１４に転送（入力）されると、当該通信データの種類をチェックする（ステップＳ８１）。ここでは、通信データが、ＡＲＰ要求、「DHCP Discover」、「EAP Response」、「Radius Access Challenge」、「Radius Access Accept」、「DHCP Request」、或いはそれ以外であるかがチェックされる（ステップＳ８２〜Ｓ８７）。

入力された通信データがＡＲＰ要求の場合（ステップＳ８２）、パケット処理部１４は入力された通信データをＡＲＰ処理部１５に転送する（ステップＳ８８）。
次に、入力された通信データが、「DHCP Discover」、「EAP Response」及び「Radius Access Challenge」のいずれかである場合（ステップＳ８３，Ｓ８４，Ｓ８５）、パケット処理部１４は当該通信データを認証処理部１６に転送する（ステップＳ８９）。
入力された通信データが「Radius Access Accept」の場合（ステップＳ８６）、パケット処理部１４は、当該通信データを認証処理部１６及びＤＨＣＰ処理部１７の両方に転送する（ステップＳ８９，Ｓ９０）。

入力された通信データが「DHCP Request」の場合（ステップＳ８７）、パケット処理部１４は、当該通信データをＤＨＣＰ処理部１７に転送する（ステップＳ９０）。

入力された通信データが、ＡＲＰ要求、「DHCP Discover」、「EAP Response」、「Radius Access Challenge」、「Radius Access Accept」及び「DHCP Request」のいずれでもない場合（ステップＳ８２〜Ｓ８７）、パケット処理部１４は何もしないで処理を終了する。つまりパケット処理部１４は、入力された通信データを破棄する。

次に、認証ＤＨＣＰサーバ１におけるＡＲＰ処理部１５の処理について、図１２のフローチャートを参照して説明する。
まず、通信データの種類がＡＲＰ要求であると判定された、例えば図６に示すフォーマットのＡＲＰ要求６０１が、パケット処理部１４によってＡＲＰ処理部１５に入力されたものとする。するとＡＲＰ処理部１５は、ＡＲＰ要求６０１の送信元ＭＡＣアドレス及び送信元ＩＰアドレスを含むアドレス情報（ＡＲＰ要求元のアドレス情報）が、アドレス管理テーブル１１に存在し、且つ当該アドレス情報の状態フィールドが「認証済」を示しているかをチェックする（ステップＳ９１）。

もし、ＡＲＰ要求元のアドレス情報が存在しないか、存在しても当該アドレス情報の状態フィールドが「認証済」を示していないならば（ステップＳ９２）、ＡＲＰ処理部１５は、図２に示されるステップＳ１２に相当する処理を次のように実行する。まずＡＲＰ処理部１５は、ＡＲＰ要求６０１に基づき、図６に示すフォーマットの偽のＡＲＰ応答６０２を生成する（ステップＳ９３）。そしてＡＲＰ処理部１５は、生成された偽のＡＲＰ応答６０２をネットワークＩＦ１３に転送して（ステップＳ９４）、処理を終了する。

これに対し、ＡＲＰ要求元のアドレス情報が存在し、且つ当該アドレス情報の状態フィールドが「認証済」を示しているならば（ステップＳ９２）、ＡＲＰ処理部１５はＡＲＰ要求６０１のターゲットＩＰアドレスが、認証ＤＨＣＰサーバ１のＩＰアドレスと一致するかをチェックする（ステップＳ９５）。このチェックは、ＡＲＰ要求１１のターゲットＩＰアドレスを、アドレス管理テーブル１１に登録されている認証ＤＨＣＰサーバ１のアドレス情報中のターゲットＩＰアドレスと比較することによって行われる。

もし、ＡＲＰ要求６０１のターゲットＩＰアドレスが、認証ＤＨＣＰサーバ１のＩＰアドレスと一致するならば（ステップＳ９６）、ＡＲＰ処理部１５は、当該ＡＲＰ要求６０１に対する、図１３に示すフォーマットのＡＲＰ応答１３１を生成する（ステップＳ９７）。

生成されたＡＲＰ応答１３１は、データリンク層ヘッダ及びＡＲＰ応答パケットを含む。ＡＲＰ応答１３１のデータリンク層ヘッダの宛先ＭＡＣアドレスには、図１３において矢印１３２で示されるように、ＡＲＰ要求６０１のデータリンク層ヘッダの送信元ＭＡＣアドレスが用いられる。また、ＡＲＰ応答１３１のＡＲＰ応答パケットのターゲットＭＡＣアドレス及びターゲットＩＰアドレスには、それぞれ、図１３において矢印１３３及び１３４で示されるように、ＡＲＰ要求６０１のＡＲＰ要求パケットの送信元ＭＡＣアドレス及び送信元ＩＰアドレスが用いられる。また、ＡＲＰ応答１３１の送信元ＭＡＣアドレス及び送信元ＩＰアドレスには、それぞれ、認証ＤＨＣＰサーバ１のＭＡＣアドレス及びＩＰアドレスが用いられる。

ＡＲＰ処理部１５は、ＡＲＰ応答１３１を生成すると（ステップＳ９７）、上記ステップＳ９４に進む。このステップＳ９４において、ＡＲＰ処理部１５は、生成されたＡＲＰ応答１３１をネットワークＩＦ１３に転送して、処理を終了する。

一方、ＡＲＰ要求６０１のターゲットＩＰアドレスが、認証ＤＨＣＰサーバ１のＩＰアドレスと一致しないならば（ステップＳ９６）、ＡＲＰ処理部１５は何もせずに処理を終了する。

次に、認証ＤＨＣＰサーバ１における認証処理部１６の処理について、図１４のフローチャートを参照して説明する。
まず、パケット処理部１４によって認証処理部１６に通信データ入力されたものとする。すると認証処理部１６は通信データ種類判定手段として機能して、通信データの種類をチェックする（ステップＳ１０１）。ここでは、通信データが、「DHCP Discover」、「EAP Response」、「Radius Access Challenge」、「Radius Access Accept」、或いはそれ以外であるかがチェックされる（ステップＳ１０２〜Ｓ１０５）。

入力された通信データが、例えば図４Ａ（ａ）に示される通信データ４０１であり、したがって当該データ４０１の種類が「DHCP Discover」であると判定された場合（ステップＳ１０２）、認証処理部１６は図１５に示すアドレス情報１５０を生成して、当該アドレス情報をアドレス管理テーブル１１の空きエントリに格納する（ステップＳ１０６）。このアドレス情報１５０のＭＡＣアドレスフィールド及びＩＰアドレスフィールドには、それぞれ、通信データ４０１の送信元ＭＡＣアドレス及び所定のＩＰアドレス「０．０．０．０」が保持される。アドレス情報１５０の状態フィールド、認証子フィールド及びＩＤフィールドには、それぞれ、「認証中」を示す状態、所定値「０」及び「DHCP Discover」のトランザクションＩＤが保持される。アドレス情報１５０の有効期限フィールドには、有効期限の初期値、例えば３００秒を表す値が保持される。この場合、３００秒以内に認証が完了しない場合、アドレス情報１５０がアドレス管理テーブル１１から削除される。この有効期限の初期値が、認証ＤＨＣＰサーバ１の管理者の操作によって、任意の値に設定される構成とすることも可能である。

認証処理部１６はステップＳ１０６を実行すると認証処理を開始する。即ち認証処理部１６は、通信データ４０１に基づき、「EAP Request」を含む、「DHCP Discover」の送信元のＭＡＣアドレス宛ての図４Ａ（ｂ）に示す通信データ４０２（ＥＡＰリクエスト）を生成する（ステップＳ１０７）。そして認証処理部１６は、生成された通信データ４０２（ＥＡＰリクエスト）をネットワークＩＦ１３に転送して（ステップＳ１０８）、処理を終了する。

次に、入力された通信データが、例えば図４Ａ（ｃ）に示される通信データ４０４であり、したがって当該データの種類が「EAP Response」であると判定された場合（ステップＳ１０３）、認証処理部１６はアドレス管理テーブル１１を参照する（ステップＳ１０９）。このステップＳ１０９において認証処理部１６は、通信データ４０４の送信元ＭＡＣアドレスに一致するＭＡＣアドレスを含むアドレス情報を検索する。ステップＳ１０９において認証処理部１６は更に、検索されたアドレス情報の認証子フィールドに、「EAP Response」のデータ部に格納されている「Radius Access Request」の認証子フィールドの値を設定（コピー）する。つまり認証処理部１６は、検索されたアドレス情報の認証子フィールドの値を、「EAP Response」のデータ部に格納されている「Radius Access Request」の認証子フィールドの値に更新する。この更新後のアドレス情報の一例を図１６に示す。

次に認証処理部１６は中継手段（変換手段）として機能して、「EAP Response」を含む通信データ４０４に基づき、当該「EAP Response」のデータ部に格納（カプセル化）されている「Radius Access Request」がＵＤＰのペイロードに格納（コピー）された、図４Ａ（ｄ）に示すフォーマットの認証サーバ２宛ての通信データ４０７（ラジウスアクセスリクエスト）を生成する（ステップＳ１１０）。そして認証処理部１６は、生成（変換）された通信データ４０７（ラジウスアクセスリクエスト）を認証サーバ２に中継するために、当該通信データ４０７をネットワークＩＦ１３に転送して（ステップＳ１０８）、処理を終了する。

次に、入力された通信データが、例えば図４Ｂ（ａ）に示される通信データ４０８であり、したがって当該データの種類が「Radius Access Challenge」であると判定された場合（ステップＳ１０４）、認証処理部１６はアドレス管理テーブル１１を参照する（ステップＳ１１１）。このステップＳ１１１において認証処理部１６は、通信データ４０８に含まれている「Radius Access Challenge」の認証子フィールドの値に一致する認証子を含むアドレス情報を検索する。

次に認証処理部１６は中継手段（変換手段）として機能して、検索されたアドレス情報のＭＡＣアドレスを宛先ＭＡＣアドレスとし、通信データ４０８の「Radius Access Challenge」が「EAP Request」のデータ部に格納（カプセル化）された、図４Ｂ（ａ）に示すフォーマットの通信データ４１０（ＥＡＰリクエスト）を生成する（ステップＳ１１２）。そして認証処理部１６は、生成（変換）された通信データ４１０（ＥＡＰリクエスト）を宛先ＭＡＣアドレスで示されるクライアント（ここではクライアント４）に中継するために、当該通信データ４１０をネットワークＩＦ１３に転送して（ステップＳ１０８）、処理を終了する。

次に、入力された通信データが、例えば図４Ｂ（ｃ）に示される通信データ４１４であり、したがって当該データの種類が「Radius Access Accept」であると判定された場合（ステップＳ１０５）、認証処理部１６はアドレス管理テーブル１１を参照する（ステップＳ１１３）。このステップＳ１１３において認証処理部１６は、通信データ４１４に含まれている「Radius Access Accept」の認証子フィールドの値に一致する認証子を含むアドレス情報を検索する。ステップＳ１１３において認証処理部１６は更に、検索されたアドレス情報の状態フィールドを、「認証中」を示す状態から「認証済」を示す状態に変更する。この変更後のアドレス情報の一例を図１７に示す。

次に認証処理部１６は中継手段（変換手段）として機能して、検索されたアドレス情報のＭＡＣアドレスを宛先ＭＡＣアドレスとし、ＥＡＰＯＬパケットのデータ部にＥＡＰ成功（EAP Success）が格納された、図４Ｃ（ａ）に示すフォーマットの通信データ４１５を生成する（ステップＳ１１４）。そして認証処理部１６は、生成（変換）された通信データ４１５（ＥＡ成功）を宛先ＭＡＣアドレスで示されるクライアント（ここではクライアント４）に中継するために、当該通信データ４１５をネットワークＩＦ１３に転送して（ステップＳ１０８）、処理を終了する。

次に、入力された通信データが、「DHCP Discover」、「EAP Response」、「Radius Access Challenge」及び「Radius Access Accept」のいずれでもない場合（ステップＳ１０２〜Ｓ１０５）、認証処理部１６は何もしないで処理を終了する。つまり認証処理部１６は、入力された通信データを破棄する。

次に、認証ＤＨＣＰサーバ１におけるＤＨＣＰ処理部１７の処理について、図１８のフローチャートを参照して説明する。
まず、パケット処理部１４によってＤＨＣＰ処理部１７に通信データ入力されたものとする。するとＤＨＣＰ処理部１７は、通信データの種類をチェックする（ステップＳ１２１）。ここでは、通信データが、「Radius Access Accept」、「DHCP Request」、或いはそれ以外であるかがチェックされる（ステップＳ１２２，Ｓ１２３）。

入力された通信データが、例えば図４Ｂ（ｃ）に示される通信データ４１４であり、したがって当該データ４１４の種類が「Radius Access Accept」であると判定された場合（ステップＳ１２２）、ＤＨＣＰ処理部１７はアドレス管理テーブル１１を参照する（ステップＳ１２４）。このステップＳ１２４においてＤＨＣＰ処理部１７は、通信データ４１４の送信元ＭＡＣアドレス及び当該通信データ４１４に含まれている「Radius Access Accept」の認証子フィールドの値にそれぞれ一致するＭＡＣアドレス及び認証子を含む目的のアドレス情報が存在するかをチェックする。

もし、目的のアドレス情報が存在しないならば（ステップＳ１２５）、ＤＨＣＰ処理部１７は何もしないで処理を終了する。つまりＤＨＣＰ処理部１７は、入力された通信データを破棄する。

これに対し、目的のアドレス情報が存在するならば（ステップＳ１２５）、ＤＨＣＰ処理部１７はＩＰアドレス割り当て手段として機能して、アドレス管理テーブル１１で使用されていない、新たに割り当て可能なＩＰアドレスを決定する（ステップＳ１２６）。そしてＤＨＣＰ処理部１７は、アドレス管理テーブル１１内の目的のアドレス情報のＩＰアドレスフィールドに、ステップＳ１２６で決定されたＩＰアドレスを設定する（ステップＳ１２７）。このＩＰアドレス設定後のアドレス情報の一例を図１９に示す。

次にＤＨＣＰ処理部１７は、図１９に示すＩＰアドレス設定後のアドレス情報に基づき、ＵＤＰのペイロードに「DHCP Offer」が格納された、図４Ｃ（ｂ）に示される通信データ４１６（DHCP Offerパケット）を生成する（ステップＳ１２８）。この通信データ４１５の宛先ＭＡＣアドレスには、ＩＰアドレス設定後のアドレス情報に含まれているＭＡＣアドレスが用いられる。

図２０は、生成された通信データ４１６の詳細なフォーマットを示す。図２０に示されるように、通信データ４１６に含まれる「DHCP Offer」は、トランザクションＩＤ、ユーザＩＰアドレス及びクライアントＭＡＣアドレスを含む。「DHCP Offer」のトランザクションＩＤ、ユーザＩＰアドレス及びクライアントＭＡＣアドレスには、図１９に示すアドレス情報に含まれている、ＩＤフィールドの値、ＩＰアドレス（決定されたＩＰアドレス）及びＭＡＣアドレスが用いられる。
ＤＨＣＰ処理部１７は、生成された通信データ４１６（DHCP Offer）をネットワークＩＦ１３に転送して（ステップＳ１２９）、処理を終了する。

一方、入力された通信データが、例えば図４Ｃ（ｃ）に示される通信データ４１７であり、したがって当該データ４１７の種類が「DHCP Request」であると判定された場合（ステップＳ１２３）、ＤＨＣＰ処理部１７はアドレス管理テーブル１１を参照する（ステップＳ１３０）。このステップＳ１３０においてＤＨＣＰ処理部１７は、通信データ４１７の送信元ＭＡＣアドレス及び当該通信データ４１７に含まれているトランザクションＩＤの値にそれぞれ一致するＭＡＣアドレス及びＩＤを含む目的のアドレス情報が存在するかをチェックする。

もし、目的のアドレス情報が存在しないならば（ステップＳ１３１）、ＤＨＣＰ処理部１７は何もしないで処理を終了する。つまりＤＨＣＰ処理部１７は、入力された通信データを破棄する。

これに対し、アドレス管理テーブル１１内に目的のアドレス情報が存在するならば（ステップＳ１３１）ＤＨＣＰ処理部１７はＩＰアドレス割り当て手段として機能して、当該アドレス情報の有効期限フィールドに、当該アドレス情報のＩＰアドレスフィールドに設定されているＩＰアドレスの有効期限（リース期限）を示す値を設定する（ステップＳ１３２）。ここでは、リース期限として、認証中の有効期限「３００秒」よりも長い期限、例えば２０００００秒を示す値が設定される。このリース期限設定後のアドレス情報の一例を図２１に示す。

次にＤＨＣＰ処理部１７は、ＩＰアドレスのリース期限が設定されたアドレス情報（図２１参照）に基づき、ＵＤＰのペイロードにＤＨＣＰ承認（DHCP ACK）が格納された、図４Ｃ（ｄ）に示される通信データ４１８（DHCP ACKパケット）を生成する（ステップＳ１３３）。この通信データ４１８の宛先ＭＡＣアドレスには、リース期限が設定されたアドレス情報に含まれているＭＡＣアドレスが用いられる。

図２２は、生成された通信データ４１８の詳細なフォーマットを示す。図２２に示されるように、通信データ４１８に含まれるDHCP ACKパケットは、トランザクションＩＤ、ユーザＩＰアドレス及びクライアントＭＡＣアドレスを含む。DHCP ACKパケットのトランザクションＩＤ、ユーザＩＰアドレス及びクライアントＭＡＣアドレスには、図２１に示すアドレス情報に含まれている、ＩＤフィールドの値、ＩＰアドレス及びＭＡＣアドレスが用いられる。
ＤＨＣＰ処理部１７は、生成された通信データ４１８（DHCP ACKパケット）をネットワークＩＦ１３に転送して（ステップＳ１２９）、処理を終了する。

このように本実施形態においては、認証ＤＨＣＰサーバ１にアドレス管理テーブル１１を設けて、当該アドレス管理テーブル１１により、クライアントの物理アドレスに対応付けて当該クライアントの認証状態、及び認証プロトコルによる通信で使用されるセッションを識別するための認証子（識別情報）が管理される。これにより、クライアント４を含む複数のクライアントの認証を並行して実行することができる。

また本実施形態においては、アドレス管理テーブル１１により、クライアントの物理アドレスに対応付けて、当該クライアントの認証状態だけでなく、ＤＨＣＰ（動的ホスト構成プロトコル）で使用されるトランザクション（セッション）を識別するための識別情報（トランザクションＩＤ）が管理される。これにより、クライアント４を含む複数のクライアントがＤＨＣＰによるＩＰアドレス取得を並行して実行することができる。

［変形例］
次に上記実施形態の変形例について説明する。
上記実施形態では、認証ＤＨＣＰサーバ１が不正なクライアント（つまり認証されていないクライアント）を通信できない状態にするために、当該不正なクライアントに偽のＡＲＰ応答（ＡＲＰ応答パケット）を送信している。本変形例の特徴は、これに加えて、不正なクライアントからのＡＲＰ要求のターゲットＩＰアドレスで指定されているクライアントに対しても、当該不正なクライアントに通信データを送信しないようにするための偽のＡＲＰパケットを認証ＤＨＣＰサーバ１が送信することにある。

以下、図２に示されている上記実施形態で適用された仕組みの変形例について、図２３を参照して説明する。図２３において、図２と同様の部分には同一符号を付してある。図２３においても、図２と同様に、クライアント４が認証されていない不正な端末であるものとする。

まず、不正な端末であるクライアント４が、例えばクライアント５と通信を行うのに必要な当該クライアント５のＭＡＣアドレスを取得するためのＡＲＰ要求を、ネットワーク３上にブロードキャストしたものとする（ステップＳ１１）。認証ＤＨＣＰサーバ１は、クライアント４からのＡＲＰ要求を受信して、上記実施形態と同様に、当該ＡＲＰ要求の送信元（クライアント４）が不正な端末であると判定したものとする。

すると認証ＤＨＣＰサーバ１は、ＡＲＰ要求の送信元（不正なクライアント４）の通信を妨害するために、直ちに偽のＡＲＰ応答を当該送信元に送信する（ステップＳ１２）。これに加えて認証ＤＨＣＰサーバ１は、上記ＡＲＰ要求のターゲットＩＰアドレスで指定されているクライアント（ここではクライアント５）に対しても、ＡＲＰ要求の送信元（不正なクライアント４）に通信データを送信しないようにするための偽のＡＲＰパケット、例えば偽のGratuitous ARP（Ｇ−ＡＲＰ）パケットを送信する（ステップＳ１３）。Ｇ−ＡＲＰパケットは、ターゲットＩＰアドレスの競合を確認するための特別のアドレス解決プロトコルパケットである。認証ＤＨＣＰサーバ１による上記のステップＳ１２及びＳ１３の処理は当該認証ＤＨＣＰサーバ１内のＡＲＰ処理部１５によって行われる。

以下、上記実施形態の変形例におけるＡＲＰ処理部１５の処理について、図２４のフローチャートを参照して、上記実施形態と相違する点を中心に説明する。なお、図１２のフローチャートと同様のステップには同一符号を付してある。

今、クライアント４からの図６に示されるＡＲＰ要求６０１を受信したＡＲＰ処理部１５が、上記実施形態と同様にステップＳ９１，Ｓ９２を実行することにより、当該ＡＲＰ要求６０１の送信元（クライアント４）が不正なクライアントであると判定したものとする。この場合、ＡＲＰ処理部１５は、ＡＲＰ要求６０１に基づき、図６に示すフォーマットの偽のＡＲＰ応答６０２を生成する（ステップＳ９３）。

次にＡＲＰ処理部１５はアドレス管理テーブル１１を参照して、ＡＲＰ要求６０１のターゲットＩＰアドレスと一致するＩＰアドレスを含むアドレス情報（目的のアドレス情報）がアドレス管理テーブル１１に存在するかをチェックする（ステップＳ１３１）。もし、目的のアドレス情報が存在するならば（ステップＳ１３２）、ＡＲＰ処理部１５はステップＳ１３３に進む。ステップＳ１３３においてＡＲＰ処理部１５は、ＡＲＰ要求６０１のターゲットＩＰアドレスで指定されているクライアント（クライアント５）が、当該ＡＲＰ要求６０１の送信元（クライアント４）に通信データを送信しないようにするために、ＡＲＰ要求６０１に基づき、図２５に示すフォーマットの偽のＧ−ＡＲＰ（Gratuitous ARP）２５１を生成する。

偽のＧ−ＡＲＰ２５１は、データリンク層ヘッダ及びＡＲＰ応答パケットを含む。偽のＧ−ＡＲＰ２５１のデータリンク層ヘッダ及びＡＲＰ応答パケットの送信元ＭＡＣアドレスには、偽のＡＲＰ応答６０２（図６参照）と同様に、偽のＭＡＣアドレスが用いられる。偽のＧ−ＡＲＰ２５１のデータリンク層ヘッダの宛先ＭＡＣアドレスには、上記目的のアドレス情報に含まれているＭＡＣアドレス、つまりＡＲＰ要求６０１のターゲットＩＰアドレスで指定されているクライアント（クライアント５）のＭＡＣアドレスが用いられる。偽のＧ−ＡＲＰ２５１のＡＲＰ応答パケットのターゲットＩＰアドレス及び送信元ＩＰアドレスには、図２５において矢印２５２及び２５３で示されるように、いずれもＡＲＰ要求６０１の送信元ＩＰアドレス（つまり不正なクライアント４のＩＰアドレス）が用いられる。

次にＡＲＰ処理部１５は、ステップＳ９３で生成された偽のＡＲＰ応答６０２とステップＳ１３３で生成された偽のＧ−ＡＲＰ２５１をネットワークＩＦ１３に転送して（ステップＳ９４）、処理を終了する。

ネットワークＩＦ１３は、この偽のＡＲＰ応答６０２及び偽のＧ−ＡＲＰ２５１をネットワーク３に送信する（図１０（ａ）のステップＳ７０）。不正なクライアント４は、偽のＡＲＰ応答６０２に従い、偽のＭＡＣアドレス宛ての通信データを送信する。これにより、不正なクライアント４がクライアント５と通信するのを妨害できる。

一方、クライアント５は、偽のＧ−ＡＲＰ２５１に従い、自身が管理しているアドレス管理テーブルの不正なクライアント４のＭＡＣアドレスを偽のＭＡＣアドレスに書き換える。これにより、クライアント５が当該偽のＭＡＣアドレス宛ての通信データを送信しても、不正なクライアント４は当該通信データを受信することはできない。つまり、不正なクライアント４からのＡＲＰ要求６０１のターゲットＩＰアドレスで指定されているクライアント５に対して、当該不正なクライアント４に通信データを送信しないようにすることができる。

一方、目的のアドレス情報が存在しないならば（ステップＳ１３２）、ＡＲＰ処理部１５は偽のＧ−ＡＲＰを生成する必要がないとして、ステップＳ１３３をスキップしてステップＳ９４に進む。この場合、ＡＲＰ処理部１５は上記実施形態と同様に、ステップＳ９３で生成された偽のＡＲＰ応答６０２をネットワークＩＦ１３に転送して、処理を終了する。

なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係る認証ＤＨＣＰサーバを含むネットワークシステムの基本構成と動作原理を説明するための図。 図１に示されるシステムにおいて、認証されていない不正な端末を通信できない状態にするための仕組みを説明するための図。 図１のシステムにおいて、クライアントがユーザ認証を行いＩＰアドレスを取得するまでの通信シーケンスの詳細を示すシーケンスチャート。 上記通信シーケンスで適用される通信データのフォーマットを示す図。 上記通信シーケンスで適用される通信データのフォーマットを示す図。 上記通信シーケンスで適用される通信データのフォーマットを示す図。 不正な端末を通信できない状態にする通信シーケンスの詳細を示すシーケンスチャート。 図５の通信シーケンスで適用される通信データのフォーマットを示す図。 図１に示される認証ＤＨＣＰサーバの構成を示すブロック図。 図７に示されるアドレス管理テーブルのデータ構造例を示す図。 認証ＤＨＣＰサーバにおけるテーブル管理部の処理手順を示すフローチャート。 認証ＤＨＣＰサーバにおけるネットワークＩＦの処理手順を示すフローチャート。 認証ＤＨＣＰサーバにおけるパケット処理部の処理手順を示すフローチャート。 認証ＤＨＣＰサーバにおけるＡＲＰ処理部の処理手順を示すフローチャート。 ＡＲＰ要求及びＡＲＰ応答のフォーマットを示す図。 認証ＤＨＣＰサーバにおける認証処理部の処理手順を示すフローチャート。 アドレス情報の一例を示す図。 アドレス情報の一例を示す図。 アドレス情報の一例を示す図。 認証ＤＨＣＰサーバにおけるＤＨＣＰ処理部の処理手順を示すフローチャート。 アドレス情報の一例を示す図。 DHCP Offerパケットを含む通信データのフォーマットを示す図。 アドレス情報の一例を示す図。 DHCP ACKパケットを含む通信データのフォーマットを示す図。 図２に示されている上記実施形態で適用された仕組みの変形例を示す図。 上記実施形態の変形例におけるＡＲＰ処理部の処理手順を示すフローチャート。 ＡＲＰ要求及びＧ−ＡＲＰのフォーマットを示す図。

符号の説明

１…認証ＤＨＣＰサーバ、２…認証サーバ、３…ネットワーク、４，５…クライアント（クライアント端末）、１１…アドレス管理テーブル、１２…テーブル管理部、１３…ネットワークＩＦ、１４…パケット処理部、１５…ＡＲＰ処理部、１６…認証処理部、１７…ＤＨＣＰ処理部。

Claims (6)

1. ネットワークに接続されたクライアント端末にＩＰアドレスを割り当てる動的ホスト構成プロトコルサーバにおいて、
   前記ネットワークに接続されたクライアント端末の物理アドレスに対応付けて当該クライアント端末の認証状態を保持する管理テーブルと、
   前記ネットワークとの間で通信データを送受信するネットワークインタフェースと、
   前記ネットワークに接続されたＩＰアドレス未割り当てのクライアント端末から送信された、認証を要求するための認証データを、前記ネットワークに接続された認証サーバに前記ネットワークインタフェースを介して中継する中継手段と、
   前記クライアント端末から要求された認証に成功したことが前記認証サーバによって通知された場合に、当該認証を要求した前記クライアント端末の物理アドレスに対応付けて前記管理テーブルに保持されている認証状態を、認証済みを示す状態に設定する認証処理手段と、
   前記認証済みを示す状態に設定された認証状態と対応付けて前記管理テーブルに保持されている物理アドレスのクライアント端末にＩＰアドレスを割り当てるＩＰアドレス割り当て手段と、
   前記ネットワークに接続されたクライアント端末からブロードキャストによって前記ネットワーク上に送信されたアドレス解決プロトコル要求が前記ネットワークインタフェースによって受信された場合に、前記管理テーブルを参照して当該アドレス解決プロトコル要求を送信したクライアント端末が認証済みであるかを判定し、認証済みでない場合に当該アドレス解決プロトコル要求を送信したクライアント端末に前記ネットワークインタフェースを介して偽のアドレス解決プロトコル応答を送信するアドレス解決プロトコル処理手段と
   を具備することを特徴とする動的ホスト構成プロトコルサーバ。
2. 前記認証処理手段は、前記ネットワークに接続されたクライアント端末からブロードキャストで送信された、動的ホスト構成プロトコルに従って動的ホスト構成プロトコルサーバを検出するための特定パケットを含む通信データが前記ネットワークインタフェースによって受信された場合に、拡張認証プロトコルに従う認証のための拡張認証プロトコルリクエストを生成して、当該生成されたリクエストを前記特定パケットの送信元の前記クライアント端末に前記ネットワークインタフェースを介して送信する拡張認証プロトコルリクエスト生成手段を含み、
   前記中継手段は変換手段を含み、
   前記変換手段は、前記認証データが、前記拡張認証プロトコルリクエストに応じて前記クライアント端末から送信された拡張認証プロトコルでカプセル化された第１の認証データの場合に、当該第１の認証データを前記認証サーバ宛てのＩＰヘッダを含む第２の認証データに変換して、当該第２の認証データを前記認証サーバに前記ネットワークインタフェースを介して送信し、前記第２の認証データに応じて前記認証サーバから第３の認証データが送信された場合に、当該第３の認証データを前記拡張認証プロトコルでカプセル化された第４の認証データに変換して、当該第４の認証データを前記第１の認証データの送信元の前記クライアント端末に前記ネットワークインタフェースを介して送信する
   ことを特徴とする請求項１記載の動的ホスト構成プロトコルサーバ。
3. 前記拡張認証プロトコルリクエスト、前記第１の認証データ、前記第２の認証データ、前記第３の認証データ及び前記第４の認証データの各通信データは、当該通信データが送信される前記クライアント端末と前記動的ホスト構成プロトコルサーバとの間の前記認証プロトコルによる通信で使用されるセッションを識別するための認証子を含み、
   前記管理テーブルは、前記ネットワークに接続されたクライアント端末の物理アドレスに対応付けて、当該クライアント端末の認証状態に加えて、当該クライアント端末と前記動的ホスト構成プロトコルサーバとの間の前記認証プロトコルによる通信で使用されるセッションを識別するための識別情報を保持し、
   前記変換手段は、前記第１の認証データから前記第２の認証データへの変換時と前記第３の認証データから前記第４の認証データへの変換時とに、当該変換される認証データに含まれている識別情報に一致する識別情報と対応付けて前記管理テーブルに保持されている物理アドレスを、変換後の認証データの宛先物理アドレスとして決定する
   ことを特徴とする請求項２記載の動的ホスト構成プロトコルサーバ。
4. 前記特定パケットは、前記動的ホスト構成プロトコルで使用されるトランザクションを識別するためのトランザクションＩＤを含み、
   前記管理テーブルは、前記ネットワークに接続されたクライアント端末の物理アドレスに対応付けて、当該クライアント端末の認証状態に加えて、当該クライアント端末と前記動的ホスト構成プロトコルサーバとの間の前記動的ホスト構成プロトコルによる通信で使用されるトランザクションを識別するためのトランザクションＩＤを保持し、
   前記認証処理手段は、前記特定パケットを含む通信データが前記ネットワークインタフェースによって受信された場合に、当該通信データを送信した前記クライアントクライアント端末の物理アドレスに対応付けて、認証中を示す認証状態及び当該通信データの前記特定パケットに含まれている前記トランザクションＩＤを前記管理テーブルに設定し、
   前記ＩＰアドレス割り当て手段は、前記クライアント端末に割り当てられるべきＩＰアドレス及び当該クライアント端末の物理アドレスと対応付けて前記管理テーブルに保持されている前記トランザクションＩＤを含む、当該物理アドレスを宛先とする前記動的ホスト構成プロトコルに従うパケットを生成して、当該生成されたパケットを当該クライアント端末に前記ネットワークインタフェースを介して送信する
   ことを特徴とする請求項２記載の動的ホスト構成プロトコルサーバ。
5. 前記管理テーブルは、前記ネットワークに接続されたクライアント端末の物理アドレスに対応付けてられている当該クライアント端末の認証状態が認証済みを示す場合に、当該物理アドレスに対応付けて、当該認証済みを示す認証状態に加えて、当該クライアント端末に割り当てられたＩＰアドレスを保持し、
   前記アドレス解決プロトコル要求は解決されるべきターゲットＩＰアドレスを含み、
   前記アドレス解決プロトコル処理手段は、前記偽のアドレス解決プロトコル応答を前記アドレス解決プロトコル要求を送信したクライアント端末に前記ネットワークインタフェースを介して送信すると共に、前記ターゲットＩＰアドレスの競合を確認するための特別のアドレス解決プロトコル要求を、前記アドレス解決プロトコル要求に含まれる前記ターゲットＩＰアドレスに一致するＩＰアドレスと対応付けて前記管理テーブルに保持されている物理アドレスのクライアント端末に前記ネットワークインタフェースを介して送信する
   ことを特徴とする請求項１記載の動的ホスト構成プロトコルサーバ。
6. ネットワークに接続されたクライアント端末に動的ホスト構成プロトコルサーバがＩＰアドレスを割り当てるためのＩＰアドレス割り当て方法において、
   前記ネットワークに接続されたＩＰアドレス未割り当てのクライアント端末から前記動的ホスト構成プロトコルサーバに送信された、認証を要求するための認証データを、前記ネットワークに接続された認証サーバに前記動的ホスト構成プロトコルサーバが中継するステップと、
   前記動的ホスト構成プロトコルサーバによって前記認証サーバに中継された前記認証データに基づく認証に前記認証サーバが成功した結果、前記クライアント端末から要求された認証に成功したことを示す認証データが前記認証サーバによって前記動的ホスト構成プロトコルサーバに通知された場合に、前記動的ホスト構成プロトコルサーバが有する管理テーブルに、前記動的ホスト構成プロトコルサーバが、当該クライアント端末の物理アドレスに対応付けて認証済みを示す認証状態を設定するステップと、
   前記認証済みを示す状態に設定された認証状態と対応付けて前記管理テーブルに保持されている物理アドレスのクライアント端末に前記動的ホスト構成プロトコルサーバがＩＰアドレスを割り当てるステップと、
   前記ネットワークに接続されたクライアント端末からブロードキャストによって前記ネットワーク上に送信されたアドレス解決プロトコル要求が前記ネットワークインタフェースによって受信された場合に、前記動的ホスト構成プロトコルサーバが前記管理テーブルを参照して、当該アドレス解決プロトコル要求を送信したクライアント端末が認証済みであるかを判定するステップと、
   認証済みでないと判定された場合に、当該アドレス解決プロトコル要求を送信したクライアント端末に前記動的ホスト構成プロトコルサーバが偽のアドレス解決プロトコル応答を送信するステップと
   を具備することを特徴とするＩＰアドレス割り当て方法。

Images