JP2000041069A

JP2000041069A - クライアント構成方法

Info

Publication number: JP2000041069A
Application number: JP6482399A
Authority: JP
Inventors: Sundararajan Subramaniam; サンダララジャン・サブラマニアン; Paul T Congdon; ポール・ティー・コンドン
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1998-03-26
Filing date: 1999-03-11
Publication date: 2000-02-08
Anticipated expiration: 2019-03-11
Also published as: DE69836673T2; DE69836673D1; US6070187A; EP0946027A3; JP4519214B2; EP0946027A2; EP0946027B1

Abstract

(57)【要約】【課題】ネットワーク・ノードをそれ自身のゲートウェ
イ・アドレスとして自動的に構成することができるよう
にする。【解決手段】構成されるべきノードを含む１つのネット
ワーク・セグメント、および、構成パラメータを自動的
に提供することができる機能を有するサーバを含む別の
１つのネットワーク・セグメントという２つのネットワ
ーク・セグメントに接続される(スイッチまたはブリッ
ジのような)ネットワーク装置の上に構成エージェント
を配置する。構成エージェントは、構成されるべきノー
ドにサーバから送られるメッセージをインターセプトし
て、そのメッセージに含まれるデフォルト・ゲートウェ
イのアドレスを構成されるべきノードのアドレスに修正
した後、当該ノードに送信する。これによって、ノード
は、それ自身のデフォルト・ゲートウェイであるように
構成されることが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク・ノ
ードの間の通信に関するもので、特に、ネットワーク・
ノードがそれ自身のデフォルト・ゲートウェイであるよ
うに自動的に構成されることを可能にする方法および装
置に関するものである。

【０００２】

【従来の技術】コンピュータ・ネットワークの技術分野
においては、同軸ケーブルまたはツイスト・ペア配線の
ようなネットワーク媒体によって連結されるネットワー
ク・ノードの間でデータを伝送するためプロトコル・ス
タックが一般に使用されている。ネットワーク・ノード
は、コンピュータ・ワークステーション、サーバ、ネッ
トワーク・プリンタ、ネットワーク・スキャナなどのよ
うな装置を含む。プロトコル・スタックの開発および実
施の調和を図るため、国際標準機構(すなわちＩＳＯ）
は、ネットワーク・プトトコルの７つの層を定めたオー
プン・システム相互接続(Open System Interconnection
の頭文字を取ってＯＳＩと呼ばれる)の基準モデルを発
布した。

【０００３】図１は、ＯＳＩ基準モデル１０のブロック
図である。モデルは、ハードウェア層１２、データ・リ
ンク層１４、ネットワーク層１６、トランスポート層１
８、セッション層２０、プレゼンテーション層２２およ
びアプリケーション層２４を含む。各層は特定の作業を
実行することに対して責任を持つ。ハードウェア層１２
は、ビット・ストリームの物理的伝送の機械的および電
気的細部を取り扱うことに対して責任がある。データ・
リンク層１４は、ハードウェア・プロトコルによって使
用されるアドレスの生成ならびに解読、および、物理層
で発生したエラー検出ならびに訂正を含むパケット処理
に対して責任がある。例えば、イーサネット・ネットワ
ークのデータ・リンク層１４は、媒体アクセス制御アド
レスの生成および解読に対して責任がある。ネットワー
ク層１６は、上位プロトコルによって使用されるアドレ
スの生成ならびに解読、および、負荷の変化に適切に応
答するための経路指定情報の維持を含めて、接続を行
い、通信ネットワークにおけるパケットの経路指定を行
うことに対して責任がある、例えば、ＴＣＰ／ＩＰプロ
トコルにおいて、ネットワーク層１６はＩＰアドレスを
生成および解読することに対して責任がある。

【０００４】トランスポート層１８は、メッセージのパ
ケットへの細分化、パケット順序ならびに送達の維持、
フロー制御および物理アドレス生成を含めて、ネットワ
ークにおけるノード間のエンド対エンドの接続およびユ
ーザの間でのメッセージ伝送に対して責任がある。セッ
ション層２０は、プロセス対プロセスのプロトコルを実
施することに対して責任がある。プレゼンテーション層
２２は、文字変換および多重化(エコー化)を含めて、ネ
ットワークにおけるいろいろなサイトの間での形式の相
違を解決することに対して責任がある。最後に、アプリ
ケーション層２４は直接ユーザと対話することに対して
責任がある。層２４は、例えば、電子メールのようなア
プリケーション、分散データベース、ウェブ・ブラウザ
などを含む。

【０００５】ＩＳＯがＯＳＩ基準モデルを発布する前
に、米国国防総省高等研究計画局(ＤＡＰＲＡ)がＡＲＰ
ＮＥＴ基準モデルを発布した。ＡＲＰＮＥＴ基準モデル
は、ネットワーク・ハードウェア層、ネットワーク・イ
ンタフェース層、ホスト対ホスト層およびプロセス/ア
プリケーション層という４つの層を含む。

【０００６】その名前が示唆するように、ＯＳＩおよび
ＡＲＰＮＥＴ基準モデルは、ネットワーク通信プロトコ
ルの設計者がそれに従うこともあれば従わないこともあ
るガイドラインを提供する。しかしながら、大部分のネ
ットワーク・プロトコルは、１つの基準モデルにすくな
くともゆるやかに対応する諸層を定義している。コンピ
ュータの分野においては、ネットワーク・ノードの間で
データを伝送するために使用される多数の有名なプロト
コルがある。例えば、ＴＣＰ／ＩＰ、アップルＴａｌｋ
Ｒ(ＮｅｔＢＥＵＩ）およびＩＰＸXはすべて、コンピュ
ータ・ネットワークに接続されるサーバ、ワークステー
ション、プリンタおよび他の装置の間でデータを送るた
めに使用される有名なプロトコルである。

【０００７】たとえネットワーク・ノードが単一のネッ
トワーク・インタフェースを持つとしても、単一ネット
ワーク・ノードの範囲内でいくつかのプロトコルが同時
に動作することは普通である。例えば、典型的なコンピ
ュータ・ワークステーションは、インターネットを経由
して通信を行うためＴＣＰ／ＩＰ、および、ネットワー
ク・サーバと通信するＩＰＸを使用する場合がある。同
様に、プリンタが、ＡｐｐｌｅＴａｌｋＲプロトコルま
たはＮｅｔＢＥＵＩプロトコルのいずれかを使用して印
刷ジョブを受け取るように構成される場合がある。典型
的には、これらのプロトコルは、一層低位の層のハード
ウェア・プロトコルと通信し対話する。例えば、イーサ
ネット・ネットワークを経由して接続された２つのコン
ピュータ・システムがＴＣＰ／ＩＰプロトコルを使用し
て通信することは一般的である。一般に、データ・リン
ク層１４またはネットワーク層１６に存在しているソフ
トウェア・ルーチンは、ネットワーク・アダプタおよび
適切なプロトコル・スタックの間でデータ・パケットを
伝送する。

【０００８】ここで、イーサネット・ネットワーク経由
で伝送されるＴＣＰ／ＩＰパケットを考察する。各パケ
ットは、イーサネット・ネットワーク上の別のノードを
識別する４８ビットの媒体アクセス制御(media access
controlを略してＭＡＣと呼ばれる)アドレスを含む。Ｍ
ＡＣアドレスは、一般的には、ハードウェア・アドレス
として知られている。イーサネット・パケット全体は、
送信元のネットワーク・アダプタによって計算されイー
サネット・パケットに詰め込まれる周期的冗長検査コー
ド(すなわちＣＲＣコード)によって保護されている。受
け取りネットワーク・アダプタは、イーサネット・パケ
ットの完全性を検証するためＣＲＣを復号する。

【０００９】パケットの完全性が検証されない場合、す
なわち、エラーが検出される場合、パケットは破棄され
る。ＴＣＰ／ＩＰプロトコルのＩＰ部分は、"データグ
ラム"として知られるもので、イーサネット・パケット
の範囲内にカプセル化されている。データグラムは、３
２ビットのＩＰアドレスおよびＩＰヘッダを保護する１
６ビットのチェックサム・コードを含む。ＩＰは、より
一般的にはネットワーク・アドレスとして知られている
ものである。ＩＰヘッダの完全性が検証されないと、デ
ータグラムは破棄される。ＴＣＰ／ＩＰプロトコルのＴ
ＣＰ部分は、データグラムの範囲内にカプセル化され、
ＴＣＰヘッダおよびデータグラムのＴＣＰ部分のコンテ
ントを保護する１６ビットのチェックサム・コードを持
つ。ＴＣＰヘッダまたはＴＣＰ部分のコンテントの完全
性が検証されない場合、データグラムは破棄され、送信
元は、意図された受け取り人から肯定応答データグラム
を受け取らなかったならその後パケットを再送信する。
このパケットは、ハードウェア(イーサネット)アドレス
およびネットワーク(ＩＰ)アドレスという２つのアドレ
スを含む点に注意する必要がある。これら２つのアドレ
スの関係を以下詳細に記述する。

【００１０】図２は、従来技術のネットワーク２６を示
している。ネットワーク２６は、ネットワーク・ノード
２８、３０、３２、３４、３６、３８、４０、４２およ
び４４を相互に接続させる。上述のように、ネットワー
ク・ノードは、例えば、コンピュータ・ワークステーシ
ョン、サーバ、ネットワーク・プリンタ、ネットワーク
・スキャナなどのような装置である。以下の記述におい
て、ネットワーク・ノードは、イーサネット・ネットワ
ーク・アダプタを備えていて、ＴＣＰ／ＩＰプロトコル
を使用してデータを伝送すると仮定する。多くのネット
ワークは、ＩＥＥＥによって発布された一連の規格に従
う。この一連の規格は、当業界においてＩＥＥＥ８０２
ファミリ規格として知られている。本明細書はＩＥＥＥ
８０２ファミリ規格を参照する。

【００１１】いくつかのネットワーク・ノードがハブを
介して１つのＬＡＮセグメントにまとめられる。１つの
ＬＡＮセグメントにおける各ノードは別のノードがパケ
ットを送信することを試みる時信号を受け取り、また、
１つのＬＡＮセグメントにおける２つのノードが同時に
パケットの伝送を試みるとき衝突が発生するので、１つ
のＬＡＮセグメントにおけるすべてのノードは共通の衝
突ドメインの中にある。イーサネット・プロトコルは、
２つのノードがそれぞれのパケットを再送信しようとす
る時更にもう１つの衝突が発生する可能性を最小にする
転送アルゴリズムを含む。図２において、ネットワーク
・ノード２８、３０および３２はハブ４６を介してＬＡ
Ｎセグメント４８として結合され、同様に、ネットワー
ク・ノード４、３６および３８は、ハブ５０を介してＬ
ＡＮセグメント５０として結合され、ネットワーク・ノ
ード４０、４２および４４は、ハブ５４を介してＬＡＮ
セグメント５６として結合されている。

【００１２】ローカルまたは遠隔のＬＡＮセグメントを
相互接続させるためスイッチおよびブリッジが使用され
る。スイッチおよびブリッジは、(しばしばサブネット
と呼ばれる)単一の論理ネットワークを形成し、ＯＳＩ
参照モデル１０のデータ・リンク層１４およびハードウ
ェア層１２での動作を実行する。図２において、スイッ
チ５８はＬＡＮセグメント４８および５２を接続してい
る。イーサネット・プロトコルにおいては、パケット
は、媒体アクセス制御(すなわちＭＡＣ)アドレスによっ
てアドレス指定される。スイッチおよびブリッジは、接
続する各ＬＡＮセグメント上のネットワーク・ノードの
ＭＡＣアドレスのリストを維持する。ＭＡＣアドレスに
よってアドレス指定されるノードを含むＬＡＮセグメン
トに各パケットを経路指定するスイッチまたはブリッジ
の範囲内の適切なポートへ個々のパケットが伝送され
る。

【００１３】スイッチおよびブリッジがサブネットを形
成するようにＬＡＮセグメントを結合する一方、インタ
ーネットまたはワイド・エリア・ネットワーク(ＷＡＮ)
のような別のネットワークを経由してサブネット同志を
結合するため、ルータ(経路指定機構)が使用される。ル
ータは、また、共通のサブネットの範囲内でパケットの
経路指定を行うためにも使用される場合がある(詳細は
後述)。ルータは、(ＩＰアドレスのような)より高位の
プロトコル・アドレスをルータのポートと関連付けるテ
ーブルを維持する。スイッチおよびブリッジと対照的
に、ルータは、階層的トポロジーとしてネットワークを
見ることができる。この場合、大きいブロックおよび範
囲のアドレスが、更なる経路指定のため他のルータへ送
付される。この理由のため、インターネットのような非
常に大きいネットワークにおいて、複数パケットを経路
指定するため、ルータがしばしば使用される。

【００１４】デフォルト・ゲートウェイは、送出パケッ
トを同じサブネット上のノードへアドレス指定すること
をノードが決定することができない時、そのノードがパ
ケットを送付する先のルータである。デフォルト・ゲー
トウェイに送付されたパケットは、宛先ノードへ到着す
るまでにいくつかの他のルータによって処理される可能
性がある。

【００１５】ＴＣＰ／ＩＰプロトコルがイーサネット・
プロトコルのような低位のハードウェア・プロトコルで
動作することを可能にするいくつかのプロトコルが定義
されている。例えば、ＴＣＰ／ＩＰを使用するように構
成されたイーサネット・ノードは、サブネット・マスク
およびデフォルト・ゲートウェイ・アドレスをＩＰアド
レスに割り当てられる。サブネット・マスクは、同じサ
ブネットの上にあるＩＰアドレスを識別し、デフォルト
・ゲートウェイ・アドレスは、同じサブネット上にない
パケットを処理するルータを識別する。同じサブネット
上のパケットに関しては、アドレス・レゾリューション
・プロトコル(ＡＲＰ)を使用して、宛先ノードのＩＰア
ドレスが見つけ出される。

【００１６】ノード２８が192.44.133.13というＩＰア
ドレスを持ち、ノード３０が192.44.133.25というＩＰ
アドレスを持つと仮定する。更に、ノード２８のサブネ
ット・マスクが255.255.255.0に設定されると仮定す
る。ノード２８は、パケットをノード３０に送るため、
先ずノード３０のＩＰアドレスとサブネット・マスクの
ビット単位ＡＮＤ演算を行い、その結果をノード２８の
ＩＰアドレスとサブネット・マスクのビット単位ＡＮＤ
演算と比較する。２つのＡＮＤ演算が一致すれば、ノー
ド３０はノード２８と同じサブネット上にあり、ノード
３０のＭＡＣアドレスはＡＲＰを使用して判明できる。
次に、ノード２８は、ＡＲＰに従ってそれ自身のＭＡＣ
アドレスおよびノード３０のＩＰアドレスを用いてブロ
ードキャスト・イーサネット・パケットを送出する。イ
ーサネット・プロトコルは、ユニキャストおよびブロー
ドキャスト・パケットをサポートする。ブロードキャス
ト・パケットは、１つのサブネット上のすべてのノード
へアドレス指定され、すべてのノードによって受け取ら
れるものであり、一方、ユニキャスト・パケットは、特
定のノードへアドレス指定され、特定のノードによって
受け取られるものである。

【００１７】ノード３０は、ノード３０のＭＡＣアドレ
スを含むユニキャスト・パケットをノード２８に送り戻
すことによってこのメッセージに応答する。次に、ノー
ド２８は、ノード３０から受け取ったＭＡＣアドレスを
使用してＴＣＰ／ＩＰパケットをノード３０に伝送す
る。更に、ノードは将来の伝送のためこの情報をキャッ
シュ記憶して、同じサブネット上のノードのＭＡＣアド
レスの検出を反復するする必要性を最小限にとどめる。

【００１８】更に、上述のように構成されたノード２８
が、168.45.198.2というＩＰアドレスを持つノード４０
にパケットを送信することを試みると仮定する。ノード
２８は、上述のビット単位ＡＮＤ演算を使用するサブネ
ット・マスクに基づいて、ノード４０が同じサブネット
上にないと判断する。このような場合、ノード２８が同
じサブネットにあることを検証することができないノー
ドにアドレス指定されているパケットを伝送するために
ノード２８によって使用されるデフォルト・ゲートウェ
イであるルータ６２にノード２８はそのパケットを中継
する。ルータ６２は、ルータ６８へ、ルータ６８はルー
タ６９へ、ルータ６９はルータ６０へそのパケットを順
に中継する。ルータ６０は(宛先ノードである)ノード４
０と同じサブネット上にあるので、ルータ６０は、ＡＲ
Ｐを使用してノード４０のＭＡＣアドレスを検出し、ノ
ード４０のＭＡＣアドレスでそのパケットのアドレスを
再指定し、その結果、ＬＡＮセグメント５６へそのパケ
ットを伝送して、そのパケットがノード４０によって受
け取られる。

【００１９】ＩＰアドレス、サブネット・マスク、デフ
ォルト・ゲートウェイのアドレスおよびその他のパラメ
ータでノードが構成されることを許容する種々のプロト
コルが定義されている。以下の記述において、"クライ
アント"、"クライアント・ノード"および"構成されるべ
きノード"という用語は、それ自身のための構成パラメ
ータを取得することを求めるネットワーク・ノードを意
味する。また、「サーバ」という用語は、構成パラメー
タを提供するネットワーク・ノードを意味する。１つの
単純なプロトコルは、イーサネット・ネットワーク上で
実行され、イーサネット・アドレスをＩＰアドレスに変
換する逆アドレス変換プロトコル(Reverse Address Res
olution Protocolの頭文字を取ってＲＡＲＰと略称され
る)である。クライアントが、そのＭＡＣアドレスを用
いてイーサネット・パケットをブロードキャストする
と、サーバが、クライアントのＩＰアドレスを含むユニ
キャスト・パケットをクライアントに伝送することによ
って応答する。ＲＡＲＰは、主にディスクのないネット
ワーク・ノードによって使用される。

【００２０】ディスクのないノードで構成されるネット
ワークにおいて一般に使用されるもう１つの標準プロト
コルは、ブートストラップ・プロトコル(略してＢＯＯ
ＴＰ)である。ＢＯＯＴＰは、ユーザ・データグラム・
プロトコル(略してＵＤＰ)を使用する。ＢＯＯＴＰは、
ノードが、それ自身のＩＰアドレス、サブネット・マス
ク、デフォルト・ゲートウェイ・アドレス、ＢＯＯＴＰ
サーバのアドレス、および、ノードが起動する時ＢＯＯ
ＴＰサーバからロードされるブート・ファイルをポイン
トするパス名を決定することを可能にする。ＢＯＯＴＰ
は、また、構成パラメータを捜し求めているノードが別
のサブネット上のＢＯＯＴＰサーバによってサービスを
提供されることを可能にするＢＯＯＴＰ中継エージェン
トを定義している。ＢＯＯＴＰは、ＲＦＣ(意見を求め
る案)９５１に定義されている。

【００２１】また、ネットワーク情報プロトコル(略し
てＮＩＰ)は、ネットワーク・ノードがそれ自身のＩＰ
アドレスを決定し、ＩＰアドレスが使用中であるか否か
を判断するためネットワーク・ノードがポーリングされ
る"ポーリング／防御"メカニズムを使用することによっ
て使用可能なＩＰアドレスを識別することを可能にす
る。クライアントは、ポーリングしているメッセージに
応答することによって使用中のＩＰアドレスを防御す
る。クライアントがＩＰアドレスを捜し求めているメッ
セージを送出する時、ＮＩＰサーバは、ネットワーク上
で利用できるＩＰアドレス・セットを返す。クライアン
トは、ＩＰアドレスの１つを選択し、ＡＲＰを使用し
て、そのＩＰアドレスが利用できることを確認する２重
検証を行う。クライアントは、次に、ＮＩＰサーバに応
答することによって自身のＩＰアドレスを確保し、ＮＩ
Ｐサーバは割り当てられたＩＰアドレスを記録する。

【００２２】最後に、動的ホスト構成プロトコル(Dynam
ic Host Configuration Protocolを略してＤＨＣＰと呼
ばれる)は、ＲＦＣ１５４１およびＲＦＣ１５３３に記
述されているＢＯＯＴＰの拡張である。ＢＯＯＴＰの拡
張であるから、ＤＨＣＰはＢＯＯＴＰによって提供され
るすべてのサービスを提供する。ＤＨＣＰは、有限のリ
ースを持つ(従って一定時間経過後満期になる)ＩＰアド
レスの自動割り当て、無限リースを持つ(従って決して
満期にならない)ＩＰアドレスの自動割り当て、およ
び、ネットワーク管理者によって選択されるＩＰアドレ
スの静的割り当てを提供することができる。

【００２３】下記表１は、クライアント／サーバ対話の
記述とともにＤＨＣＰプロトコルに従って交換される主
要メッセージである。

【００２４】

【表１】

【００２５】クライアントとサーバの間の構成対話は、
そのローカル・サブネット上にDHCPDISCOVERメッセージ
をブロードキャストするクライアントから始まる。その
サブネット上のＢＯＯＴＰ中継ソフトウェア・エージェ
ントが、同じサブネット上にないＤＨＣＰサーバにその
メッセージを伝える。次に、各サーバは、利用できるネ
ットワークＩＰアドレスおよびその他の構成パラメータ
を含むDHCPOFFERメッセージで応答する。サーバは可能
であればそのクライアントにDHCPOFFERメッセージをユ
ニキャストし、また必要に応じてＢＯＯＴＰ中継エージ
ェントを使用する。代替的に、サーバは、ブロードキャ
スト・アドレスを使用して、そのクライアントのサブネ
ットにメッセージをブロードキャストすることもでき
る。

【００２６】クライアントは、次に、１つまたは複数の
サーバから１つまたは複数のDHCPOFFERメッセージを受
け取る。クライアントは、複数の応答を待って待機する
ことを選択することができる。DHCPOFFERメッセージで
申し出を受けた構成パラメータに基づいた構成パラメー
タを要求するため１つのサーバを選択する。クライアン
トは、どのサーバを選択したかを標示するサーバ識別子
オプションを必ず含むDHCPREQUESTメッセージをブロー
ドキャストする。このメッセージは、所望の構成値を指
定するその他のオプションを含むこともできる。

【００２７】すべてのサーバはクライアントからDHCPRE
QUESTブロードキャストを受け取り、DHCPREQUESTメッセ
ージによって選択されなかったサーバ(複数)は、クライ
アントがそのサーバの申し出を辞退したことの通知とし
てそのメッセージを使用する。DHCPREQUESTメッセージ
によって選択されたサーバは、クライアントとの連結を
コミットして、構成パラメータを含むDHCPACKメッセー
ジで応答する。選択されたサーバがDHCPREQUESTメッセ
ージを満たすことができないならば、サーバは、クライ
アントの要求を拒否するDHCPNAKメッセージで応答す
る。

【００２８】クライアントはDHCPNAKメッセージを受け
取ると、やり直しする。クライアントが構成パラメータ
を含むDHCPACKメッセージを受け取ると、クライアント
は、パラメータに関する最終的検証を実行し、ＩＰアド
レスが有効な(リースの持続)時間の長さおよびDHCPACK
メッセージに指定されるリース識別情報を確認する。こ
の時点で、クライアントは、クライアントＩＰアドレ
ス、サブネット・マスクおよびデフォルト・ゲートウェ
イ・アドレスで構成される。クライアントがDHCPACKメ
ッセージの中のパラメータに関して問題を検出する場
合、クライアントは、DHCPDECLINEメッセージをサーバ
に送り返して、構成プロセスをやり直す。クライアント
は、サーバにDHCPRELEASEメッセージを送ることによっ
てＩＰアドレスに関するリースを放棄することができ
る。ＢＯＯＴＰプロトコルにおけるメッセージの対話も
同様である。

【００２９】

【発明が解決しようとする課題】上記従来技術のノード
は、宛先ノードが同じサブネット上にあるか否か判断す
るためサブネット・マスクを使用する。サブネット・マ
スク・メカニズムは、２の累乗のノード・アドレスがサ
ブネットに加えられなければならず、これは必ずしも常
に実用的または可能ではないので、柔軟性に欠けてい
る。それ自身のゲートウェイであるようにノードを構成
することが望ましいにも関わらず、ＤＨＣＰのような従
来技術構成プロトコールは、ネットワーク・ノードがそ
れ自身のゲートウェイとして構成されることを許容しな
い。従って、このな問題の解決が求められている。

【００３０】

【課題を解決するための手段】本発明は、ネットワーク
・ノードが、それ自身のゲートウェイ・アドレスとして
構成されることができるように、ＩＰアドレスおよびデ
フォルト・ゲートウェイ・アドレスで自動的に構成され
ることを可能にする構成エージェントを提供する。それ
自身のデフォルト・ゲートウェイであるようにノードを
構成することによって、ノードは、サブネット内および
サブネット外パケットを処理する共通のデフォルト・ゲ
ートウェイ・ルーチンを実行することができる。本発明
に従った構成エージェントは、構成されるべきノードを
含む１つのネットワーク・セグメントおよび構成パラメ
ータを自動的に提供することができる機能を有するサー
バを含む別の１つのネットワーク・セグメントという２
つのネットワーク・セグメントに接続される(スイッチ
またはブリッジのような)ネットワーク装置の上に配置
される。

【００３１】本発明の第１の側面において、構成エージ
ェントは詮索型エージェントの役を果たす。構成サーバ
から構成されるべきノードへのメッセージが、ＩＰアド
レスおよびデフォルト・ゲートウェイ・アドレスを含む
メッセージを発見するため詮索される。そのようなメッ
セージは、構成を求めているノードに申し出されている
ＩＰアドレスをデフォルト・ゲートウェイ・アドレスに
コピーするように変更され、そのメッセージがその意図
されている宛先に送られることによって、構成されるこ
とを求めているノードがそれ自身のデフォルト・ゲート
ウェイであるように構成されることが可能にされる。場
合によっては、構成されることを求めているノードへの
構成サーバからのメッセージがブロードキャスト・メッ
セージであることを保証するため、構成されるべきノー
ドから構成サーバへのメッセージが変更される。

【００３２】本発明の第２の側面において、構成エージ
ェントは代理エージェントの役を果たす。構成されよう
としているノードから見れば、代理エージェントは構成
エージェントであるように見える。構成サーバから見れ
ば、構成サーバおよび構成されることを求めているノー
ドが異なるサブネット上に存在するとすれば、代理エー
ジェントは中継エージェントであるように見える。それ
らが同じサブネット上にあれば、代理エージェントは、
詮索エージェントの場合と同様に、構成サーバから構成
されることを求めているノードへのメッセージを処理す
る。

【００３３】構成されることを求めているノードが、Ｉ
Ｐアドレスおよびデフォルト・ゲートウェイで構成され
ることを求めていることを標示するメッセージを送る
時、代理エージェントがそのメッセージを受け取る。代
理エージェントは、サーバからユニキャストまたはブロ
ードキャスト応答を要求するようにメッセージを変更す
る。加えて、構成されるべきノードおよび構成エージェ
ントが同じサブネット上にないならば、構成サーバが代
理エージェントを中継エージェントとしてみなすように
メッセージが変更される。

【００３４】構成サーバが(おそらく代理エージェント
を中継エージェントとしてみなして)構成されるべきノ
ードにメッセージを送る時、代理エージェントは、メッ
セージをインターセプトして、メッセージで提供された
ＩＰアドレスをデフォルト・ゲートウェイ・アドレスに
コピーする。これによって、構成されることを求めてい
るノードがそれ自身のデフォルト・ゲートウェイとして
構成されることが可能とされる。代理エージェントは、
また、実際の構成サーバのＩＰアドレスを代理エージェ
ントのＩＰアドレスと置き換えて、構成されることを求
めているノードが代理エージェントを構成エージェント
として見なすことを可能にする。

【００３５】

【発明の実施の形態】本発明は、スイッチのようなネッ
トワーク装置上に位置する構成エージェントである。構
成エージェントは、たとえサブネット・マスクがノード
が異なるサブネット上にあることを標示しても、同じサ
ブネット上にあるノードと直接通信するため、構成パラ
メータを捜し求めているネットワーク・ノードがそれ自
身のデフォルト・ゲートウェイとして構成されることを
可能にする。本発明の詳細な記述の前に、コンピュータ
・ネットワークの技術分野における最近の傾向を考察す
る。

【００３６】伝統的に、大規模ＴＣＰ／ＩＰネットワー
クは、ネットワーク・ノードの間でパケットを伝送する
ためしばしばルータを使用してきた。しかしながら、ス
イッチと比較して、ルータは比較的遅く、プロセッサ集
約的である。加えて、ルータはスイッチよりかなり高価
である。

【００３７】上述のように、イーサネット・ネットワー
クを通して接続される２つのＴＣＰ／ＩＰノードは、宛
先ＩＰアドレスが同じイーサネット・ネットワーク上に
あることを送信元ノードのサブネット・マスクが標示す
ることを前提とすれば、ルータなしに直接通信すること
ができる。送信元ノードは、サブネット・マスクおよび
そのＩＰアドレスに関するビット単位ＡＮＤ演算を実行
して、その結果をサブネット・マスクおよび宛先ＩＰア
ドレスに関するビット単位ＡＮＤ演算と比較する。結果
が一致すれば、送信元ノードは、アドレス・レゾリュー
ション・プロトコル(すなわちＡＲＰ)を使用してＴＣＰ
／ＩＰパケットを送信する前にＩＰアドレスをイーサネ
ット・アドレスに変換する。以下の記述において、"ハ
ードウェア・アドレス"という用語は、イーサネットＭ
ＡＣアドレスのようなネットワーク・ハードウェアによ
って使用される低位アドレスを意味し、"ネットワーク
・アドレス"という用語は、ＩＰアドレスのような高位
プロトコル・スタックで使用されるアドレスを意味す
る。

【００３８】サブネット・マスクは、比較的未完成のメ
カニズムである。ＩＰアドレスは、２の累乗の単位でネ
ットワークに加えられる。従って、サブネット・マスク
が255.255.255.0に設定される場合、１０２４のユニー
クなＩＰアドレスがネットワーク上で利用することが可
能であり、これらのアドレスを割り当てられるノード
は、ルータを必要とすることなく直接相互に通信するこ
とができる。しかしながら、ネットワーク管理者がそれ
より多いＩＰアドレスを加えることを望むとすれば、サ
ブネット・マスクの中のビットの１つを消去することに
よって２０４８のユニークなアドレスが提供される。多
くの状況において、これらのアドレスのすべてが利用で
きるというわけではない。従って、ネットワーク管理者
は、宛先パケットによってアドレス指定されるノードが
たとえ同じサブネット上にあったとしても、デフォルト
・ゲートウェイ・アドレスによって識別されるルータへ
パケットを送信するようにＴＣＰ／ＩＰを構成すること
を強制される。実際、構成問題を最小にするため、多く
のネットワーク・ノードは、すべてのＴＣＰ／ｌＰパケ
ットをデフォルト・ゲートウェイに送信するように単純
に構成される。

【００３９】この問題の１つの解決策は、そのノード自
身のＩＰアドレスに各ノードのデフォルト・ゲートウェ
イ・アドレスを構成することである。このようにする
と、ネットワーク・ノードがＴＣＰ／ＩＰパケットを送
信しようとする時、ネットワーク・ノード上のゲートウ
ェイ・サブルーチンがパケットの経路指定を行う。ゲー
トウェイ・サブルーチンは、ＡＲＰを使用して、パケッ
トを送付すべきＭＡＣアドレスを検出する。ルータおよ
びスイッチがＡＲＰ代理サーバを含むように構成される
ことができる点に注意する必要がある。スイッチに関し
て、ＡＲＰ代理サーバは、サブネット上のすべてのノー
ドのＭＡＣ対ＩＰアドレス対応関係をキャッシュ記憶す
ることによってネットワーク・トラフィックを減少させ
る。従って、ノードが同じサブネット上の遠隔ノードの
ＩＰアドレスを検出を試みてＡＲＰ要求パケットをブロ
ードキャストする時、パケットは単にそのＬＡＮセグメ
ントの範囲内で送信されるだけである。ＬＡＮセグメン
トがスイッチを介してサブネットに統合されていれば、
ＡＲＰ代理サーバは必要とされない。しかしながら、ス
イッチ上にＡＲＰ代理サーバがないと、ＡＲＰブロード
キャストはサブネット上のすべてのノードに伝送される
ので、ネットワーク・トラフィックは増加する。スイッ
チがＡＲＰ代理サーバを持つとして、ゲートウェイ・サ
ブルーチンがＡＲＰを使用して、別のＬＡＮセグメント
上の遠隔ノードのＭＡＣアドレスを検出する時、ＡＲＰ
代理サーバが遠隔ノードのＭＡＣアドレスを提供する。

【００４０】対照的に、異なるサブネット上のノードが
ＡＲＰを使用して通信するとすれば、ルータ上のＡＲＰ
代理サーバが必要とされる。ルータのＡＲＰ代理サーバ
は、ＭＡＣアドレスおよびＩＰアドレスの対応関係を維
持する。しかしながら、サブネット外ノードの場合、ル
ータのＡＲＰ代理サーバによって提供されるＭＡＣアド
レスは、そのルータ自身のＭＡＣアドレスである。ゲー
トウェイ・サブルーチンが別のサブネット上の遠隔ノー
ドのＭＡＣアドレスを見つけるためＡＲＰを使用する
時、ルータのＡＲＰ代理サーバは、ルータのＭＡＣアド
レスを応答するので、更に経路指定を行うためパケット
がルータに送信される。

【００４１】ＡＲＰはすべてのＩＰアドレスを検出する
ために使用されるので、同じサブネット上のすべてのパ
ケットはスイッチによって経路指定され、ルータは、そ
のイーサネット・ネットワークから実際に離れているパ
ケットを伝送するためにだけ使用される。スイッチはル
ータより速いので、ネットワークの範囲内で送られるＴ
ＣＰ／ＩＰパケットは比較的速く伝送される。サブネッ
ト・マスク・メカニズムと比較すると、ゲートウェイ・
サブルーチンは、２の累乗でＩＰアドレスを加えること
に限定されていない。また、加えられる範囲は連続的で
ある必要はない。従って、ネットワーク管理者は、イー
サネット・ネットワークにＩＰアドレスを一層柔軟に割
り当てることができる。

【００４２】この手法を追求する際、ネットワーク管理
者が直面する１つの問題は、各ネットワーク・ノードを
それ自身のゲートウェイであるように構成することであ
る。当然のことであるがこれは手操作で実施することは
できるが、それは初歩のユーザにとって適切な解決策で
はない。加えて、多くのノードを持つネットワークにと
ってこれは受け入れることのできる解決策ではない。

【００４３】ネットワーク管理を単純化するため、多く
のネットワーク管理者は、既に、ＢＯＯＴＰまたはＤＨ
ＣＰのような自動ホスト構成プロトコルへ移行してい
る。あいにく、これらのプロトコルは、ネットワーク・
ノードをそれ自身のゲートウェイであるように構成する
ことをサポートしていない。ネットワーク管理者が、自
動ホスト構成プロトコル・サーバを確立する作業に着手
し、そのサーバから構成パラメータを受け取るようにす
べてのネットワーク・ノードを構成した後管理者が手動
構成に戻る可能性はほとんどない。

【００４４】本発明はこのジレンマを解く。１つの実施
形態において、スイッチ(または同様のネットワーク装)
はＤＨＣＰ詮索エージェントを含む。詮索エージェント
は、スイッチを通して伝送されるパケットを詮索して、
ＤＨＣＰ構成メッセージを監視する。ネットワーク・ノ
ード方向の、構成パラメータを含むメッセージを検出す
る時、詮索エージェントは、候補ＩＰアドレスを含むフ
ィールドをデフォルト・ゲートウェイを含むフィールド
にコピーする。次に、詮索エージェントは、そのパケッ
トを意図されたノードへ送信する。これによって、ネッ
トワーク・ノードに記憶されたデフォルト・ゲートウェ
イのＩＰアドレスがノード自身のＩＰアドレスに設定さ
れることが可能にされる。

【００４５】第２の、一層洗練された実施形態におい
て、スイッチ(または同様の装置)はＤＨＣＰ代理エージ
ェントを含む。構成情報を捜し求めているネットワーク
・ノードから見れば、代理エージェントは、ＤＨＣＰサ
ーバであるように見える。ＤＨＣＰサーバから見れば、
代理エージェントは、構成されるべきクライアント、お
よび、ＤＨＣＰサーバが異なるサブネット上にあるとす
れば、ＤＨＣＰ／ＢＯＯＴＰ中継エージェントであるよ
うに見える。クライアントおよびサーバが同じサブネッ
ト上にあれば、代理エージェントは、サーバからクライ
アントへのメッセージを、詮索エージェントと同じよう
に、処理する。ＤＨＣＰ／ＢＯＯＴＰ中継エージェント
は、当業界においては既知であり、ネットワークの間で
構成パラメータを中継するために使用される。代理エー
ジェントは、構成パラメータを求めるネットワーク・ノ
ードとＤＨＣＰサーバの間に位置するので、代理エージ
ェントが、候補ＩＰアドレスを含むフィールドをデフォ
ルト・ゲートウェイを含むフィールドへコピーすること
によってＤＨＣＰサーバとの間で伝送されているメッセ
ージを変更することができる。上記２つの実施形態の詳
細は以下に記述される。

【００４６】本発明は、動的ホスト構成プロトコル(す
なわちＤＨＣＰ)を引用して記述される。しかし、本発
明はＤＨＣＰに限定されていない。本発明がＢＯＯＴＰ
のようなその他の類似したプロトコルにも適用できるこ
とは当業者に理解されるであろう。ＤＨＣＰメッセージ
の形式は、下記表２にリストされている。この形式はＲ
ＦＣ１５４１からと取り出したものである。各フィール
ドの定義は、下記表３の通りである。

【００４７】

【表２】

【００４８】

【表３】

【００４９】図３は、本発明に従った構成エージェント
を有するスイッチ７６を含むネットワーク７４を示す。
図３は、構成エージェントがＤＨＣＰ詮索エージェント
である第１の実施形態、および、構成エージェントがＤ
ＨＣＰ代理エージェントである第２の実施形態の両者に
対して共通である。スイッチ７６は、ハブ８０およびハ
ブ８４を経由してＬＡＮセグメント７８をＬＡＮセグメ
ント８２に連結する。ＬＡＮセグメント７８は構成され
ることを求めるネットワーク・ノード８６を含み、ＬＡ
Ｎセグメント８２は構成パラメータを提供するＤＨＣＰ
サーバ８８を含む。本発明の両方の構成において、スイ
ッチ上の構成エージェントは、ノード８６およびサーバ
８８の間の対話を変更する。従って、スイッチ７６は、
ノード８６およびサーバ８８の間の通信経路がスイッチ
７６を通過するように、ノード８６およびサーバ８８の
間に配置されることが好ましい。

【００５０】図４は、本発明の第１の実施形態に従うＮ
ポート・スイッチ９０を示す。各ポートは、送出装置１
００への入力経路、および、出力バッファ９２、９４、
９６および９８のような出力バッファを含む出力経路を
持つ。更に、送出装置１００は、ＤＨＣＰ詮索エージェ
ント１０２を含む。以下に記述される場合を除いて、送
出装置１００は従来技術における既知の方法で、パケッ
トを送出する。

【００５１】図５は、ＤＨＣＰ詮索エージェント１０２
がパケットを処理する方法を示す流れ図１０４である。
ブロック１０６においてパケットが受け取られる。ブロ
ック１０８は、そのパケットがそれ自身のゲートウェイ
として構成されるべきネットワーク・ノードを指定して
いるHCPDISCOVER、DHCPREQUEST、DHCPOFFERまたはDHCPA
CKパケットであるか否か判断する。本発明の１つの構成
において、"援助"されるべきノードのテーブルを維持す
ることによって一定のＭＡＣアドレスを持つノードを単
に"援助"するようにスイッチ９０が構成される場合があ
ることに注意する必要がある。言い換えると、それ自身
のゲートウェイとして構成されることが望ましいノード
もあれば、従来技術に従って構成されるのが望ましいノ
ードもある。パケットが上記のタイプの１つでなけば、
あるいは、パケットが"援助"されるべきものではないノ
ードからのパケットであれば、ブロック１０８は"NO"に
分岐して、ブロック１１０においてパケットが伝送され
る。制御はブロック１０６に渡り、次のパケットを待機
する。

【００５２】パケットがDHCPDISCOVERまたはDHCPREQUES
Tパケットであれば、ブロック１０８は"YES"に分岐し
て、ブロック１１２へ進み、そこで、パケットのＢフラ
グがセットされているか否か検査される。Ｂフラグの機
能はＲＦＣ１５４１において次のように定義されてい
る。

【００５３】「そのプロトコル・ソフトウェアがＩＰア
ドレスで構成されるまでユニキャストＩＰデータグラム
を受け取ることができないクライアントは、そのクライ
アントが送るDHCPDISCOVERまたはDHCPREQUESTメッセー
ジにおけるフラグ・フィールドのBROADCAST(ブロードキ
ャスト)ビット(すなわちＢフラグ)を１に設定しなけれ
ばならない。Ｂフラグは、ＤＨＣＰサーバおよびＢＯＯ
ＴＰ中継エージェントがクライアントのサブネット上に
クライアントに対するメッセージをブロードキャストす
るためのヒントを与える。そのプロトコル・ソフトウェ
アが構成される前にユニキャストＩＰデータグラムを受
け取ることができるクライアントは、Ｂフラグ・ビット
を０に設定しなければならない。('giaddr'フィールド
に指定されている中継エージェントへではなく)ＤＨＣ
Ｐクライアントに直接ＤＨＣＰメッセージを送信または
中継するサーバまたは中継エージェントは、Ｂフラグを
検査しなければならない。Ｂフラグが１に設定されてい
れば、ＩＰ宛先アドレスとしてＩＰブロードキャスト・
アドレス(好ましくは255.255.255.255)を、リンク層(イ
ーサーネット)宛先アドレスとしてリンク層(イーサーネ
ット)ブロードキャスト・アドレスを使用してＤＨＣＰ
はＩＰブロードキャストとして送信されなければならな
い。Ｂフラグが０に設定されていれば、メッセージは、
ＩＰとしてユニキャストを送られなければならない"YIA
DDR"フィールドに指定されているＩＰアドレスおよび"C
HADDR"フィールドに指定されているリンク層(イーサー
ネット)へのＩＰユニキャストとしてそのメッセージは
送信されなければならない。ユニキャスト送信が可能で
ないならば、ＩＰ宛先アドレスとしてＩＰブロードキャ
スト・アドレス(好ましくは255.255.255.255)を、リン
ク層(イーサーネット)宛先アドレスとしてリンク層(イ
ーサーネット)ブロードキャスト・アドレスを使用して
ＩＰブロードキャストとしてそのメッセージを送信して
もよい。」一部のスイッチは、ユニキャストおよびブロ
ードキャスト・パケットをトラップおよび処理すること
ができる。このタイプのスイッチは、ブロック１１２お
よび１１４をスキップして、ブロック１１０においてパ
ケットを送信し、Ｂフラグを解除する。しかしながら、
その他のスイッチは、スイッチＭＡＣアドレスに直接ア
ドレスされるパケットをトラップすることができるだけ
である。このタイプのスイッチにとって、構成対話に関
係しているすべてのパケットがイーサネット・ブロード
キャスト・パケットであって、スイッチのＣＰＵがパケ
ットをインターセプトすることができることが重要であ
る。

【００５４】初期的DHCPDISCOVERおよびDHCPREQUESTパ
ケットは、クライアントが通常ＤＨＣＰサーバにおける
ＩＰアドレスを知らないので、典型的には、イーサネッ
ト・ブロードキャスト・パケットである。しかしなが
ら、クライアントがＩＰアドレスで構成される前にユニ
キャストＩＰデータグラムを受け取ることができるなら
ば、クライアントはＢフラグを設定し、ＤＨＣＰサーバ
がノードへ応答を送る方法を決定する時のヒントとして
Ｂフラグを使用することができる。フラグが解除される
と、DHCPOFFER、DHCPACKおよびDHCPNAKパケットはノー
ドへ戻されるユニキャストとなり、そのため、スイッチ
がユニキャスト・パケットをトラップすることができな
ければエージェント１０２がパケットをインターセプト
することができなくなる。多くのノードがＩＰアドレス
で構成されるまでユニキャストＩＰデータグラムを受け
る取ることができないのでＢフラグが既に設定されてい
る可能性が高い。Ｂフラグが設定されていれば、ブロッ
ク１１０へ進み、パケットは送信され、制御は次のパケ
ットを待つためブロック１０６へ戻る。フラグが解除さ
れていれば、ブロック１１４へ進み、Ｂフラグが設定さ
れ、イーサネット・チェックサムが再計算される。制御
はブロック１１０に移り、パケットが送信され、制御は
次のパケットを待つためブロック１０６へ戻る。

【００５５】ブロック１０８において、パケットがDHCP
OFFERまたはDHCPACKパケットである場合、制御は下方分
岐"YES"からブロック１１６へ進む。ブロック１１６
は、オプション・フィールドにおけるデフォルト・ゲー
トウェイ・フィールドへYIADDRフィールドの候補ＩＰア
ドレスをコピーして、それ自身のゲートウェイあるよう
にネットワーク・ノードを構成させ、その後パケット・
チェックサムを再計算する。制御はブロック１１０に移
り、パケットが送信され、制御は次のパケットを待つた
めブロック１０６へ戻る。

【００５６】本発明のこの実施形態の主な利点は、実施
が容易で、オーバーヘッドをあまり必要としないことで
ある。しかし、この実施形態には２、３のマイナーな制
限がある。ユニキャスト・パケットをインターセプトす
ることができないスイッチに関して、構成されることを
求めているノードがＤＨＣＰサーバのアドレスを知って
いる時、ノードはそのアドレスを使用して、DHCPDISCOV
ERおよびDHCPREQUESTパケットをユニキャストするかも
しれない。初期的ＤＨＣＰパケットがブロードキャスト
でないので、ＤＨＣＰ詮索エージェントは、そのような
パケットを見逃し、Ｂフラグを設定することができな
い。しかしながら、ＤＨＣＰプロトコルの大部分の実施
において、構成されることを求めているノードは、ＤＨ
ＣＰサーバのアドレスを知らないので、初期的ＤＨＣＰ
パケットがブロードキャストでないことを確認する。

【００５７】ネットワーク・ノードがそのＩＰアドレス
のリース期間を更新しようとする時、同じような問題が
発生する可能性がある。ノードはＤＨＣＰサーバのアド
レスを知っているので、典型的にはノードはサーバにDH
CPREQUESTパケットをユニキャストする。ＤＨＣＰ詮索
エージェントは、ユニキャスト・パケットをインターセ
プトすることができないスイッチ上に所在するので、Ｂ
フラグを設定する機会のないままこのメッセージをサー
バに直接送信する。クライアントはＩＰアドレスで構成
され、従って、ユニキャストＩＰデータグラムを受け取
ることができるので、クライアントはＢフラグを解除
し、ＤＨＣＰサーバはユニキャスト・メッセージで応答
する可能性が高い。ＤＨＣＰサーバは、修正されたデフ
ォルト・ゲートウェイ・アドレスを認識しないので、パ
ケットを破棄するか、正しいと信じているアドレスにデ
フォルト・ゲートウェイ・アドレスを戻すことを試みる
かもしれない。

【００５８】メッセージはクライアントへのユニキャス
トであるから、ＤＨＣＰ詮索エージェントがデフォルト
・ゲートウェイ・アドレスを修正する機会はない。従っ
て、ＤＨＣＰサーバを修正しない場合、この実施形態
は、ユニキャスト・パケットをインターセプトすること
ができないスイッチに関する動的アドレス割り当ての問
題を持つ可能性がある。一方、ＤＨＣＰサーバがクライ
アントによって提供されるデフォルト・ゲートウェイを
使用するように修正されれば、本発明が従来技術のＤＨ
ＣＰサーバを用いて動作するという大きな利点が得られ
る。当然、ユニキャスト・パケットをインターセプトす
ることができるスイッチは影響を受けない。

【００５９】もう１つのマイナーな欠点は、Ｂフラグを
設定することが、さもなければＢフラグを解除したまま
にしておくであろう構成において、ネットワーク・トラ
フィックを若干増加させることになる点である。このよ
うなマイナーな欠点にもかかわらず、ＤＨＣＰまたはＢ
ＯＯＴＰのような従来技術の自動構成プロトコルを使用
してそれ自身のゲートウェイであるようにノードを構成
することをネットワーク管理者が求める場合、ＤＨＣＰ
詮索エージェントは、多くのネットワークに対して効果
的で構成の容易な解決策を提供する。

【００６０】本発明の第２の実施形態は、上記のような
マイナーな欠点に苦しまない。図６は、本発明の第２の
実施形態に従ったＮポート・スイッチ１１８を示す。各
ポートは、送出装置１２０への入力経路、および、出力
バッファ１２２、１２４、１２６および１２８のような
出力バッファを含む出力経路を有する。更に、送出装置
１２０は、ＤＨＣＰ代理エージェント１３０を含む。Ｄ
ＨＣＰ代理エージェント１３０が、ＤＨＣＰサーバ１３
２として構成されることを求めているノードに見えるよ
うに構成される。加えて、ＤＨＣＰ代理エージェント１
３０のＤＨＣＰ／ＢＯＯＴＰ中継詮索エージェント１３
４が、ＤＨＣＰサーバが同じサブネット上になければ、
ＤＨＣＰ／ＢＯＯＴＰ中継エージェントとしてのサーバ
に見えるように構成される。構成されるべきクライアン
トとＤＨＣＰサーバが同じサブネットの上にあれば、Ｄ
ＨＣＰ／ＢＯＯＴＰ中継詮索エージェント１３４が、Ｄ
ＨＣＰサーバからクライアントへ伝送されるパケットに
関して(第１の実施形態と同様な)詮索エージェントとし
て機能する。以下に記述される点を除いて、送出装置１
２０は従来技術における既知の方法でパケットを送出す
る。

【００６１】図７乃至図１０は、ＤＨＣＰ代理エージェ
ント１３０がパケットを処理する方法を示す流れ図１３
６である。ブロック１３８においてパケットが受け取ら
れる。制御がブロック１４０に渡り、そこで、そのパケ
ットがそれ自身のゲートウェイとして構成されるべきネ
ットワーク・ノードを指定しているHCPDISCOVER、DHCPR
EQUEST、DHCPOFFER、DHCPACKまたはDHCPNAKパケットで
あるか否か判断する。上述のＤＨＣＰ詮索エージェント
１０２の場合と同様に、ＤＨＣＰ代理エージェント１３
０は、"援助"されるべきネットワーク・ノードを識別す
るＭＡＣアドレスのテーブルを維持するように構成され
ることができる。パケットが上記のタイプの１つでなけ
ば、あるいは、ノードが、"援助"されるべきものではな
い場合、ブロック１４０は"NO"に分岐して、ブロック１
４２においてパケットが伝送される。次に制御はブロッ
ク１３８に戻り、次のパケットを待機する。

【００６２】ＤＨＣＰ代理エージェント１３０は構成対
話において伝送されるすべてのブロードキャスト・パケ
ットを受け取る点に注意する必要がある。加えて、パケ
ットがクライアントからのユニキャストであれば、構成
されることを求めているクライアントがＤＨＣＰ代理エ
ージェント１３０がそのクライアントのＤＨＣＰサーバ
であると見なすので、ＤＨＣＰ代理エージェント１３０
はそれらのパケットを受け取る。

【００６３】パケットがDHCPDISCOVERまたはDHCPREQUES
Tパケットであれば、制御は、ブロック１４０の右側の"
YES"からブロック１４４へ進む。ブロック１４４は、パ
ケットがCIADDRフィールドにＩＰアドレスを含むDHCPRE
QUESTパケットであるか否か判断する。クライアント・
ノードが以前に割り当てられた構成パラメータを検証す
ることを求めている場合、上記表２および表３に示され
るように、DHCPREQUESTパケットのCIADDRフィールドは
クライアント・ノードによって記入されているはずであ
る。このプロセスは当業界においてリース更新として知
られているものである。パケットがCIADDRフィールドに
ＩＰアドレスを含むDHCPREQUESTパケットであれば、制
御はブロック１４５へ進む。

【００６４】ブロック１４５は、ＤＨＣＰサーバおよび
スイッチが同じサブネット上にあるか否か判断する。こ
れは、ＤＨＣＰ代理エージェント１３０をＤＨＣＰサー
バによって構成させることによって判断されるか、ある
いは、スイッチは、ＤＨＣＰ応答を受け取る時ＤＨＣＰ
サーバの存在を動的に知ることができる。ＤＨＣＰサー
バおよびスイッチが同じサブネット上にあれば、制御は
ブロック１４６に移る。ブロック１４６は、先ずサーバ
割り当てテーブルをアクセスする。サーバ割り当てテー
ブルは、以前に構成されたクライアントと構成情報を提
供したＤＨＣＰサーバの間の対応関係を維持する。サー
バ割り当てテーブルは、ＤＨＣＰサーバを１つだけ持つ
ネットワークにおいては必ずしも必要でない点に注意す
る必要がある。DHCPACKおよびDHCPREQUESTパケットが処
理される時テーブルに１つのエントリが記憶される(詳
細は後述)。

【００６５】ブロック１４６は、クライアントを構成し
たＤＨＣＰサーバのアドレスをサーバ割り当てテーブル
から取り出す。サーバとクライアントが同じサブネット
上にあるので、アドレスは、ＭＡＣアドレスまたは(Ａ
ＲＰを使用してＭＡＣアドレスに変換される)ＩＰアド
レスである。次に、ブロック１４６は、取り出したＤＨ
ＣＰサーバのＭＡＣアドレスにパケットを再アドレス指
定する。次に、ブロック１４６は、(すでに設定されて
なければ)Ｂフラグを設定して、それによって、ＤＨＣ
Ｐサーバが、上記第１の実施形態と同様に、インターセ
プトされるブロードキャスト・メッセージを応答するこ
とが保証される。最後に、パケット・チェックサムが再
計算され、制御はブロック１４２に渡る。

【００６６】ブロック１４５において、ＤＨＣＰサーバ
とスイッチが同じサブネット上になければ、制御はブロ
ック１４７に移る。ブロック１４７は、ブロック１４６
の場合と同様に、サーバ割り当てテーブルにアクセスし
て、サーバによって提供されたデフォルト・ゲートウェ
イ・アドレスと共に、クライアントを構成したＤＨＣＰ
サーバのＩＰアドレスを取り出す。次に、ブロック１４
７は、ＤＨＣＰサーバのＩＰアドレスへパケットを再ア
ドレス指定して、ＤＨＣＰ代理エージェント１３０のＩ
ＰアドレスをGIADDRフィールドに加え、(すでに解除さ
れてなければ)Ｂフラグを解除し、チェックサムを再計
算する。ＤＨＣＰ代理エージェント１３０のＩＰアドレ
スをGIADDRフィールドに加え、Ｂフラグを解除すること
によって、ＤＨＣＰ代理エージェント１３０がＤＨＣＰ
サーバに対するＤＨＣＰ／ＢＯＯＴＰ中継エージェント
のように見えるので、応答されるユニキャスト・パケッ
トはＤＨＣＰ代理エージェント１３０へ戻される。次
に、制御はブロック１４２へ戻り、ＤＨＣＰ代理エージ
ェント１３０のデフォルト・ゲートウェイを通してパケ
ットがＤＨＣＰサーバに伝送される。制御は次のパケッ
トを待機するためブロック１３８に移る。

【００６７】ブロック１４４において、パケットがCIAD
DRフィールドにＩＰアドレスを含むDHCPREQUESTパケッ
トでない場合、制御はブロック１４８へ進む。ブロック
１４８は、パケットがDHCPREQUESTパケットであるかDHC
PDISCOVERパケットであるか判断する。(ここでは、DHCP
REQUESTパケットは、CIADDRフィールドにアドレスがあ
ればブロック１４４において"YES"となっているので、
当然、CIADDRフィールドにアドレスを持っていない)。
パケットがDHCPREQUESTパケットであれば、パケット
は、構成されることを求めているノードによって要求さ
れたパラメータを含み、制御はブロック１５０へ進む。
ブロッック１５０は、申し出されたネットワーク・ノー
ド対ＤＨＣＰサーバの対応関係でサーバ割り当てテーブ
ルを更新する。クライアントがDHCPREQUESTパケットに
よってＩＰアドレスに関するリース期間を更新すること
を求める時、このテーブルが使用される。制御は次にブ
ロック１５２に移る。ブロック１４８において、パケッ
トがDHCPDISCOVERパケットであれば、制御はブロック１
５２に進む。

【００６８】ブロック１５２は、ＤＨＣＰサーバとスイ
ッチが同じサブネット上にあるか否か判断する。この判
断は、上述のステップ１４５の場合と同様に行われる。
スイッチおよびＤＨＣＰサーバが同じサブネット上にな
ければ、制御はブロック１５４へ進む。ブロック１５４
において、GIADDRフィールドにＤＨＣＰ代理エージェン
ト１３０のＩＰアドレスが挿入され、これにより、ＤＨ
ＣＰ代理エージェント１３０はＤＨＣＰサーバにとって
ＤＨＣＰ／ＢＯＯＴＰ中継エージェントのように見え
る。次に、ブロック１５４は、ユニキャスト伝送が要求
されるように、Ｂフラグを解除する。これはネットワー
ク・バンド幅を節約する。次に、パケットはＤＨＣＰサ
ーバのＩＰアドレスでアドレス指定される。ＤＨＣＰ代
理エージェント１３０がサブネット外ＤＨＣＰサーバに
関する限りＤＨＣＰ／ＢＯＯＴＰ中継エージェントの役
を果たしているので、ＤＨＣＰ代理エージェント１３０
は、応答パケットを調べることによって動的にＤＨＣＰ
サーバを発見するというＤＨＣＰサーバ・アドレス手操
作構成のような従来技術を使用して、ＤＨＣＰサーバの
リストを維持することもできる。最後に、パケット・チ
ェックサムが再計算され、制御はブロック１４２に戻っ
て、そこで、パケットはＤＨＣＰ代理エージェント１３
０のデフォルト・ゲートウェイを経由して伝送される。
次に、制御は次のパケットを待機するためブロック１３
８に移る。

【００６９】ブロック１５２において、ＤＨＣＰサーバ
およびスイッチが同じサブネット上にあれば、ブロック
１５６に進み、ＤＨＣＰサーバからのブロードキャスト
伝送を要求するため、Ｂフラグが設定され、既にＢフラ
グが解除されていた場合はチェックサムが再計算され
る。次に、制御はブロック１４２に戻って、そこで、パ
ケットが伝送される。制御は次のパケットを待機するた
めブロック１３８に移る。

【００７０】一方、ブロック１４０において、パケット
が、"援助"されるように構成されるネットワークのDHCP
OFFER、DHCPACKまたはDHCPNAKパケットであれば、制御
はブロック１５８に渡り、パケットがDHCPACパケットで
あるか否か判断される。DHCPACパケットであれば、パケ
ットは構成情報を含むことを意味し、制御はブロック１
６０へ進み、ステップ１５０の場合と同様に、ネットワ
ーク・ノード対ＤＨＣＰサーバ対応関係でサーバ割り当
てテーブルが更新される。次に、制御はブロック１６２
に移る。ブロック１５８においてパケットがDHCPACパケ
ットでない場合も、制御はブロック１６２に移る。

【００７１】ブロック１６２において、ＤＨＣＰ代理エ
ージェント１３２のＩＰアドレスがSIADDRフィールドに
コピーされ、それによって、構成されることを求めてい
るネットワーク・ノードがＤＨＣＰ代理エージェント１
３２をそのＤＨＣＰサーバとみなすことが可能となる。
ブロック１６２は、ＤＨＣＰ代理エージェント１３２が
クライアント・ノードにとってＤＨＣＰ／ＢＯＯＴＰ中
継エージェントであるように見えなくするように、GIAD
DRフィールドを消去する。次に、ノードをそれ自身のデ
フォルト・ゲートウェイであるように構成するため、候
補Ｐアドレスがオプション・フィールドでYIADDRフィー
ルドからデフォルト・ゲートウェイ・フィールドへコピ
ーされる。最後に、パケット・チェックサムが再計算さ
れ、制御はブロック１４２に戻って、そこで、パケット
が構成されるべきクライアントに送信される。次に、制
御は次のパケットを待機するためブロック１３８に移
る。

【００７２】本発明の第２の実施形態は、従来技術のＤ
ＨＣＰサーバを維持しながら、リース更新およびユニキ
ャスト伝送を含めＤＨＣＰメッセージのすべての面をサ
ポートすることを求めるネットワーク管理者に包括的な
解決策を提供する。それに加えて、ブロードキャスト・
パケットだけをインターセプトすることができるスイッ
チに関して使用される場合、本発明の第２の実施形態は
充分に機能的である。

【００７３】ネットワーク・ノードがそれ自身のゲート
ウェイとして自動的に構成されることを可能ににするこ
とによって、本発明の上記２つの実施形態は、自動構成
を維持しながら、かつ、ルータを経由するトラフィック
を大幅に増加させることなく、スイッチおよびブリッジ
を追加することによって、ネットワーク管理者がネット
ワークを拡張することを可能にする。スイッチおよびブ
リッジはルータより非常に速く、廉価であるので、本発
明は、ネットワークを拡張するコストを最小にし、ネッ
トワークの速度を最大にし、自動構成を維持する機会を
ネットワーク管理者に提供する。

【００７４】従来技術においては、スイッチまたはブリ
ッジの追加によってネットワークを拡張する時、ネット
ワーク管理者には３つの選択があった。第１に、管理者
は、サブネット・マスクを変更することが可能であっ
た。この選択は、自動構成を許容するが、多くの場合実
際的でない２の累乗の数でＩＰアドレスをサブネットに
追加しなければならない。第２に、ネットワーク管理者
は、それ自身のデフォルト・ゲートウェイであるように
各クライアントを手操作で構成することができたが、こ
の選択は、管理者がすでにＤＨＣＰのような自動構成プ
ロトコルを確立する出費を支出していれば、魅力のある
候補ではない。最後に、ネットワーク管理者は、ルータ
を使用することができたが、ルータは速度が遅く高価で
ある。本発明は、第４の選択を提供する。本発明に従え
ば、構成エージェントは、手操作での構成の実施を必要
とすることなく、また、ルータに頼ることもなく、いか
なるＩＰアドレスの増加をもサブネットに加えることを
可能にする。

【００７５】以上、特定の実施形態を参照して本発明を
記述したが、本発明の理念を逸脱することなく、上記実
施形態に種々の変更を加えることが可能である点は当業
者に認められることであろう。

【００７６】本発明には、例として次のような実施様態
が含まれる。

【００７７】（１）クライアントをそれ自身のデフォル
ト・ゲートウェイであるように構成する方法であって、
構成サーバおよびクライアントの間の構成対話の一部で
あり、該クライアントによって現在使用されているまた
は将来使用されるデフォルト・ゲートウェイ・アドレス
を含むメッセージをインターセプトするステップと、上
記メッセージ中のデフォルト・ゲートウェイ・アドレス
を該クライアントのアドレスであるように修正するステ
ップと、上記メッセージを伝送するステップと、を含む
クライアント構成方法。

【００７８】（２）上記メッセージが申し出メッセージ
である、上記（１）に記載のクライアント構成方法。

【００７９】（３）上記メッセージが肯定応答メッセー
ジである、上記（１）に記載のクライアント構成方法。

【００８０】（４）メッセージをインターセプトする上
記ステップが、上記サーバからメッセージを受け取るス
テップを含み、メッセージを伝送する上記ステップが、
上記メッセージを上記クライアントに伝送するステップ
を含む、上記（１）に記載のクライアント構成方法。

【００８１】（５）上記メッセージ中のデフォルト・ゲ
ートウェイ・アドレスを修正する上記ステップが、該ク
ライアントのネットワーク・アドレスとして現在使用さ
れているまたは将来使用される候補ネットワーク・アド
レスを当該メッセージのクライアント・ネットワーク・
アドレス・フィールドからコピーし、該メッセージのデ
フォルト・ゲートウェイ・アドレス・フィールドにその
候補アドレスを記憶するステップを含む、上記（１）に
記載のクライアント構成方法。

【００８２】（６）上記メッセージに関連するチェック
サムを再計算するステップを、更に含む上記（５）に記
載のクライアント構成方法。

【００８３】（７）構成サーバおよびクライアントの間
の構成対話の一部分である発見メッセージまたは要求メ
ッセージをインターセプトするステップと、その発見メ
ッセージまたは要求メッセージを調べて、そのメッセー
ジのブロードキャスト・フラグが設定されているか否か
を判断するステップと、ブロードキャスト・フラグが設
定されていなければ、ブロードキャスト・フラグを設定
し、上記発見メッセージまたは要求メッセージに関連す
るチェックサムを再計算し、上記発見メッセージまたは
要求メッセージを伝送するステップと、を更に含む、上
記（１）に記載のクライアント構成方法。

【００８４】（８）上記メッセージの構成サーバ・アド
レス・フィールドに構成エージェントのネットワーク・
アドレスを記憶するステップを更に含む、上記（１）に
記載のクライアント構成方法。

【００８５】（９）上記メッセージが肯定応答メッセー
ジであるか否かを判断するステップと、メッセージが肯
定応答メッセージであれば、サーバ割り当てテーブルに
当該クライアントと上記構成サーバを関連付ける１つの
エントリを記憶するステップを更に含む、上記（１）に
記載のクライアント構成方法。

【００８６】（１０）クライアントがそのリースを更新
することを求めるネットワーク・アドレスを含む要求メ
ッセージをインターセプトするステップと、構成サーバ
のアドレスに要求メッセージを再アドレス指定するステ
ップと、要求メッセージを構成サーバに伝送するステッ
プと、を更に含む、上記（１）に記載のクライアント構
成方法。

【００８７】（１１）構成エージェントおよび構成サー
バが同じサブネット上にあるか否かを判断し、構成エー
ジェントおよび構成サーバが同じサブネット上にあれ
ば、上記要求メッセージのブロードキャスト・フラグが
設定されてなければブロードキャスト・フラグを設定
し、上記要求メッセージに関連するチェックサムを再計
算するステップを含み、構成サーバのアドレスに要求メ
ッセージを再アドレス指定する上記ステップが、構成サ
ーバのハードウェア・アドレスに上記要求メッセージの
ハードウェア・アドレスを再アドレス指定するステップ
を含み、構成エージェントおよび構成サーバが同じサブ
ネット上になければ、上記要求メッセージのブロードキ
ャスト・フラグが解除されてなければブロードキャスト
・フラグを解除し、上記要求メッセージの中継エージェ
ント・フィールドに構成エージェントのネットワーク・
アドレスを記憶し、上記要求メッセージに関連するチェ
ックサムを再計算するステップを含み、構成サーバのア
ドレスに要求メッセージを再アドレス指定する上記ステ
ップが、構成サーバのネットワーク・アドレスに上記要
求メッセージのネットワーク・アドレスを再アドレス指
定するステップを含む、上記（１０）に記載のクライア
ント構成方法。

【００８８】（１２）構成サーバのアドレスに上記要求
メッセージを再アドレス指定する上記ステップが、サー
バ割り当てテーブルにアクセスして、クライアントと既
に関連付けられている構成サーバのアドレスを取り出
し、クライアントと既に関連付けられている構成サーバ
のアドレスに上記要求メッセージを再アドレス指定する
ステップを含む、上記（１０）に記載のクライアント構
成方法。

【００８９】（１３）構成サーバおよびクライアントの
間の構成対話の一部である発見メッセージまたは要求メ
ッセージをインターセプトするステップと、構成エージ
ェントおよび構成サーバが同じサブネット上にあるか否
か判断するステップと、構成エージェントおよび構成サ
ーバが同じサブネット上にあれば、ブロードキャスト・
フラグが設定されていなければ、発見メッセージまたは
要求メッセージのブロードキャスト・フラグを設定し、
上記発見メッセージまたは上記要求メッセージに関連す
るチェックサムを再計算し、上記発見メッセージまたは
上記要求メッセージを伝送するステップと、構成エージ
ェントおよび構成サーバが同じサブネット上になけれ
ば、ブロードキャスト・フラグが解除されていなければ
発見メッセージまたは要求メッセージのブロードキャス
ト・フラグを解除し、発見メッセージまたは要求メッセ
ージの中継エージェント・フィールドに構成エージェン
トのネットワーク・アドレスを記憶し、発見メッセージ
または要求メッセージに関連するチェックサムを再計算
し、発見メッセージまたは要求メッセージを伝送するス
テップと、を更に含む、上記（１）に記載のクライアン
ト構成方法。

【００９０】（１４）デフォルト・ゲートウェイ・アド
レスでクライアントを構成することができる構成サーバ
に接続された第１のポートと、デフォルト・ゲートウェ
イ・アドレスで構成されることを求めているクライアン
トに接続された第２のポートと、上記第１のポートおよ
び第２のポートの間に接続され、上記第１および第２の
ポートの間でパケットを送出する送出装置と、を備える
ネットワーク装置であって、上記送出装置が、構成サー
バおよびクライアントの間の構成対話の一部である構成
パケットをインターセプトする構成エージェントを含
み、上記構成パケットがクライアントによって使用され
るデフォルト・ゲートウェイ・アドレスを含み、上記構
成エージェントが、該クライアントのネットワーク・ア
ドレスであるようにデフォルト・ゲートウェイ・アドレ
スを修正して、該構成パケットを伝送する、ネットワー
ク装置。

【００９１】（１５）上記構成パケットが申し出パケッ
トを含む、上記（１４）に記載のネットワーク装置。

【００９２】（１６）上記構成パケットが肯定応答パケ
ットを含む、上記（１４）に記載のネットワーク装置。

【００９３】（１７）上記構成エージェントが、構成サ
ーバからの構成パケットを上記第１のポートで受け取る
ことによって上記構成パケットをインターセプトし、該
構成パケットを上記第２のポートで上記クライアントに
伝送すことによって該構成パケットを伝送する、上記
（１４）に記載のネットワーク装置。

【００９４】（１８）該クライアントのネットワーク・
アドレスとして現在使用されているまたは将来使用され
る候補ネットワーク・アドレスを上記構成パケットのク
ライアント・ネットワーク・アドレス・フィールドから
コピーして、上記構成パケットのデフォルト・ゲートウ
ェイ・アドレス・フィールドにその候補アドレスを記憶
することによって、上記構成エージェントが、クライア
ントによって使用されるべきデフォルト・ゲートウェイ
・アドレスを修正する、上記（１４）に記載のネットワ
ーク装置。

【００９５】（１９）上記構成エージェントが、構成パ
ケットを伝送する前に上記構成パケットに関連するチェ
ックサムを再計算する、上記（１４）に記載のネットワ
ーク装置。

【００９６】（２０）上記構成エージェントが、構成サ
ーバおよびクライアントの間の構成対話の一部である発
見メッセージまたは要求メッセージを含むパケットをイ
ンターセプトして、該発見メッセージまたは要求メッセ
ージを検査して、ブロードキャスト・フラグが設定され
ていなければ、発見メッセージまたは要求メッセージの
ブロードキャスト・フラグを設定し、該パケットに関連
するチェックサムを再計算し、上記要求パケットを伝送
する、上記（１４）に記載のネットワーク装置。

【００９７】（２１）上記構成エージェントが、構成パ
ケットの構成サーバ・アドレス・フィールドに構成エー
ジェントのネットワーク・アドレスを記憶する、上記
（１４）に記載のネットワーク装置。

【００９８】（２２）上記構成エージェントが、上記構
成パケットが肯定応答メッセージを含むか否かを判断
し、構成パケットが肯定応答メッセージを含めば、サー
バ割り当てテーブルに当該クライアントと上記構成サー
バを関連付ける１つのエントリを記憶する、上記（１
４）に記載のネットワーク装置。

【００９９】（２３）上記構成エージェントが、クライ
アントがそのリースを更新することを求めるネットワー
ク・アドレスを含む要求メッセージを含むパケットをイ
ンターセプトし、構成サーバのアドレスにそのパケット
を再アドレス指定して、そのパケットを構成サーバに伝
送する、上記（１４）に記載のネットワーク装置。

【０１００】（２４）上記構成エージェントが、構成エ
ージェントおよび構成サーバが同じサブネット上にある
か否かを判断し、構成エージェントおよび構成サーバが
同じサブネット上にあれば、上記要求メッセージのブロ
ードキャスト・フラグが設定されてなければブロードキ
ャスト・フラグを設定し、上記パケットに関連するチェ
ックサムを再計算し、構成サーバのネットワーク・アド
レスに上記パケットを再アドレス指定し、構成エージェ
ントおよび構成サーバが同じサブネット上になければ、
上記要求メッセージのブロードキャスト・フラグが解除
されてなければブロードキャスト・フラグを解除し、上
記要求メッセージの中継エージェント・フィールドに構
成エージェントのネットワーク・アドレスを記憶し、上
記要求メッセージに関連するチェックサムを再計算し、
構成サーバのネットワーク・アドレスに上記パケットを
再アドレス指定する、上記（２３）に記載のネットワー
ク装置。

【０１０１】（２５）上記構成エージェントが、構成サ
ーバ割り当てテーブルにアクセスして、クライアントと
既に関連付けられている構成サーバのアドレスを取り出
し、クライアントと既に関連付けられている構成サーバ
のアドレスに上記パケットを再アドレス指定することに
よって、上記パケットを構成サーバのアドレスに再アド
レス指定する、上記（２３）に記載のネットワーク装
置。

【０１０２】（２６）上記構成エージェントが、構成サ
ーバおよびクライアントの間の構成対話の一部である発
見メッセージまたは要求メッセージを含むパケットをイ
ンターセプトして、構成エージェントおよび構成サーバ
が同じサブネット上にあるか否か判断し、構成エージェ
ントおよび構成サーバが同じサブネット上にあれば、ブ
ロードキャスト・フラグが設定されていなければ、発見
メッセージまたは要求メッセージのブロードキャスト・
フラグを設定し、上記パケットに関連するチェックサム
を再計算し、上記パケットを伝送し、構成エージェント
および構成サーバが同じサブネット上になければ、ブロ
ードキャスト・フラグが解除されていなければ発見メッ
セージまたは要求メッセージのブロードキャスト・フラ
グを解除し、上記発見メッセージまたは要求メッセージ
の中継エージェント・フィールドに構成エージェントの
ネットワーク・アドレスを記憶し、上記パケットに関連
するチェックサムを再計算し、そのパケットを伝送す
る、上記（１４）に記載のネットワーク装置。

【０１０３】

【発明の効果】ネットワーク・ノードがそれ自身のゲー
トウェイとして自動的に構成されることを可能ににする
ことによって、本発明は、自動構成を維持しながら、か
つ、ルータを経由するトラフィックを大幅に増加させる
ことなく、スイッチおよびブリッジを追加することによ
って、ネットワーク管理者がネットワークを拡張するこ
とを可能にする。スイッチおよびブリッジは、ルータよ
り非常に速く、廉価であるので、本発明は、ネットワー
クを拡張するコストを最小にし、ネットワークの速度を
最大にしつつ、ノードの自動構成を維持する機会をネッ
トワーク管理者に提供する。

【図面の簡単な説明】

【図１】ＯＳＩ基準モデルのブロック図である。

【図２】従来技術のネットワークを示すブロック図であ
る。

【図３】本発明に従った構成エージェントを有するスイ
ッチを含むネットワークを示すブロック図である。

【図４】構成エージェントがＤＨＣＰ詮索エージェント
である本発明の第１の実施形態に従ったＮポート・スイ
ッチを示すブロック図である。

【図５】図４に示されたＤＨＣＰ詮索エージェントがパ
ケットを処理する方法を示す流れ図である。

【図６】構成エージェントがＤＨＣＰ代理エージェント
である本発明の第２の実施形態に従ったＮポート・スイ
ッチを示すブロック図である。

【図７】図８乃至図１０と共に、図６のＤＨＣＰ代理エ
ージェントがパケットを処理する方法を示す流れ図であ
る。

【図８】図７、図９および図１０と共に、図６のＤＨＣ
Ｐ代理エージェントがパケットを処理する方法を示す流
れ図である。

【図９】図７、図８および図１０と共に、図６のＤＨＣ
Ｐ代理エージェントがパケットを処理する方法を示す流
れ図である。

【図１０】図７乃至図９と共に、図６のＤＨＣＰ代理エ
ージェントがパケットを処理する方法を示す流れ図であ
る。

【符号の説明】

７４ネットワーク７６構成エージェントを含むスイッチ８６構成されるべきネットワーク・ノード(クラ
イアント) ８８、１３２ＤＨＣＰサーバ１００、１２０送出装置１０２ＤＨＣＰ詮索エージェント１３０ＤＨＣＰ代理エージェント１３４ＤＨＣＰ／ＢＯＯＴＰ中継詮索エージェント

フロントページの続き (72)発明者ポール・ティー・コンドンアメリカ合衆国95746カリフォルニア州グラニット・ベイ、ツリーレイク・ロード 9489

Claims

【特許請求の範囲】

【請求項１】クライアントをそれ自身のデフォルト・ゲ
ートウェイであるように構成する方法であって、構成サーバおよびクライアントの間の構成対話の一部で
あり、該クライアントによって現在使用されているまた
は将来使用されるデフォルト・ゲートウェイ・アドレス
を含むメッセージをインターセプトするステップと、上記メッセージ中のデフォルト・ゲートウェイ・アドレ
スを該クライアントのアドレスであるように修正するス
テップと、上記メッセージを伝送するステップと、を含むクライアント構成方法。