JP2006014269A - エッジ内ルーティングのない宅内ｉｐ通信装置及びこれを用いた通信方法 - Google Patents

Abstract

【課題】本発明は、単一のＬＡＮセグメント上の互いに異なるサブネットに属するホストらが、ルーティングなしに互いに連動出来ると同時に、インターネットに円滑に接続出来るＩＰ通信装置及びこれを用いた通信方法を提供する。
【解決手段】本発明は、エッジルータ、及び複数のＬＩＰホストと複数のＧＩＰホストからなる複数のクライアントホストで構成され、前記エッジルータに連結している単一のエッジＬＡＮセグメントからなる複数のサブネットエッジ網において、ｉ）前記単一のエッジＬＡＮセグメント内に設置され、ｉｉ）ＩＰ通信のために、前記クライアントホストが要求するＤＨＣＰメッセージに応答して、元ＤＨＣＰサーバから提供される承認メッセージ内のサブネットマスクを含むＩＰコンフィギュレーション情報を変調して、前記ＧＩＰホストとＬＩＰホストが互いに同じサブネットを持つと勘違いするように誘導するＤＨＣＰプロキシサーバを含む。
【選択図】図８

Description

本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信装置及びこれを用いた通信方法に関し、特に、単一のＬＡＮセグメント上の互いに異なるサブネットに属するホストらが、ルーティングなしに互いに連動出来ると同時に、インターネットに円滑に接続出来るＩＰ通信装置及びこれを用いた通信方法に関する。

ＩＰ通信は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）及びサーバを越えて幅広く普及されつつある。非常に多様な端末及び装備が知能を持つことになることで、これらの端末及び装備にはＩＰ接続が要求された。これを“オールＩＰ”であると称し、ユビキタスライフ又はデジタルホームネットワーキングは事実上オールＩＰにおける環境を意味する。

ところが、ＩＰ通信のために必需的に要求されるＩＰアドレスが不足しつつある。現在、ＩＰｖ４体制では２＾３２個のアドレスが存在するだけで、その中でも２＾２９個のアドレスはマルチキャスティングやテストの用途で使用されるため、一般のホストには配分されていない。

一部の専門家らはＩＰｖ６アドレス体系の導入がＩＰアドレスの不足の問題を完璧に解決すると予測する。しかしながら、現在、ＩＰｖ４アドレス体系からＩＰｖ６体系への移行過程は、実は全てのインターネットホストの通信ソフトウェアの変更を伴うため、その過程が長期間に及ぶ。完全に移行が終了するまでは、ＩＰｖ６ホストはＩＰｖ４アドレスを同時に持ちながら、既存のＩＰｖ４ホストらと通信しなければならない。

一方、ＩＰｖ４アドレスにはＧＩＰ（Ｇｌｏｂａｌ ＩＰ）アドレス及びＬＩＰ（Ｌｏｃａｌ ＩＰ）アドレスが存在する。ＧＩＰアドレスはインターネット上でルーティングされるが、ＬＩＰアドレスはルーティングされない。ＧＩＰアドレスは完璧なインターネット接続を提供するが、ＬＩＰアドレスを用いる場合には色々な制約がある。反面、使用可能なＩＰアドレス数においてはＬＩＰアドレスは殆ど制限なく使用出来る。その理由は、ＬＩＰアドレスは宅内、事務室内或いはエッジ網内だけでユニークに使用されば良いからである。インターネット標準によって３個のＬＩＰアドレスブロックが存在する。第１は１０．０．０．０〜１０．２５５．２５５．２５５の２＾２４個のアドレスからなるブロックである（以下、“１０．ｘ．ｘ．ｘアドレスブロック”と言う）。第２は１７２．１６．０．０〜１７２．３１．２５５．２５５の２＾２０個のアドレスからなるブロックである（以下、“１７２．１６〜３１アドレスブロック”と言う）。第３は１９２．１６８．０．０〜１９２．１６８．２５５．２５５の２＾１６個のアドレスからなるブロックである（以下、“１９２．１６８アドレスブロック”と言う）。

ＩＰアドレスの不足を克服出来る効果的な方法の１つはＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）である。ＮＡＴを通したＩＰ通信方法を図１乃至図３を参照して説明する。

図１は単一のＬＡＮセグメントに存在する“複数サブネットエッジ網”を示すブロックダイアグラムである。ここで“複数サブネットエッジ網”とは、互いに異なるサブネットを持つＧＩＰホストとＬＩＰホストが１つのＬＡＮセグメント上に並存している“エッジ網”を言い、“エッジ網”はエッジルータが持つ最小のネットワークセグメントを言う。１つのエッジ網は専用線を使用する大型事務室である事が出来、或いは数百個の家庭或いは数百個の小型事務室からなることも出来る。

エッジルータ１２０は、ＷＡＮインターフェース１２１とＬＡＮインターフェース１２２を持つ。ＬＡＮセグメント１３には複数のＧＩＰホスト１４、１５とＬＩＰホスト１６、１７が連結している。また、エッジルータ１２０は複数のＬＩＰホスト１６、１７に対してデフォルトゲートウェイの役割を提供して、ＬＩＰホストをインターネットに連結させるＮＡＴ機能を備え、エッジルータ１２０のＬＡＮインターフェース１２２にはＬＩＰアドレスがエイリアス（Ａｌｉａｓｅｓ）されている。複数のＧＩＰホスト１４、１５及び複数のＬＩＰホスト１６、１７がインターネットに接続するために、各ＩＰホストに対するＩＰコンフィギュレーション過程を通じてＩＰアドレスを与えられなければならない。ところで、ＩＰコンフィギュレーション情報には次のような情報が含まれる。自分（ホスト）が使用するＩＰアドレス、サブネットを計算するためのサブネットマスク、ホストをインターネットに連結させるデフォルトゲートウェイ、目的地ドメインのＩＰアドレスを検索出来るドメインネームサービス（ＤＮＳ）サーバ、及びこのようなコンフィギュレーション情報を自動ダウンロード出来るＤＨＣＰサーバ情報などである。前記情報のうち、サブネットマスクは該ＩＰアドレスの前から何番目ビットまでがサブネットを意味するかを示す。サブネットはインターネットの論理的部分として、“自分の町”という概念と非常に類似している。例えば、３２ビットＩＰアドレスにおいて、所定のホストが“／２４”サブネットマスクを受けたとすれば、“所定のホストのＩＰアドレスの初めて２４個ビットと同じビットで始まるＩＰアドレスを持つホストは自分の町のホストである。でなければ、遠隔ホストだ”ということを意味する。

図２を参照して詳細に説明すれば、図２は、ネットワークサブネットマスク”／２４”であるＩＰアドレス２０１．１．１．１８８を示す。前述したように、“／２４”とは、ＩＰアドレスの３２個ビットの中の初めて２４個ビットからなる部分が、そのアドレスのネットワークプリフィックスだという意味である。サブネットの計算時には前の２４個ビットは１、残りは０とおく。従って、”／２４”サブネットマスクは、実は１１１１１１１１ １１１１１１１１ １１１１１１１１ ００００００００（２３）になる。この二進数を各オクテット（Ｏｃｔｅｔ）に対して十進数で表記すれば２５５．２５５．２５５．０になる。オクテットを十進数で表記したことは、一般人らもＰＣのネットワーク設定等でよく見られる。ところが、ＧＩＰホストとＬＩＰホストは互いに異なるサブネットに属する。

一方、所定のソースホストがターゲット目的地を持つようになれば、まず、ソースホストは目的地が同じサブネットに存在するか否かを検査する。第１に、ソースホストは“サブネットマスク”２３を自分のＩＰアドレス２１上に置いて各ビットに対してΑＮＤ演算を行う。その結果は１１００１００１．０００００００１．０００００００１．００００００００である。第２に、このソースホストはサブネットマスクを目的地のＩＰアドレスに置いて同じ演算を行ってその結果を取る。第３に、前記の２つの結果を比較して、同一であれば目的地はソースホストと同じサブネット内に存在し、同一でなければ目的地は遠隔に存在するということである。より一般的な言語で表現すれば、“私のＩＰアドレスの初めてｎビットが私のサブネットを意味する場合、その初めてｎビットが私のＩＰアドレスの初めてｎビットと同じ値を持つＩＰアドレスを使用するホストは全て私と同じサブネットに存在する。また、初めてｎビットと関連して、私のｎビットと違う値を持つアドレスを使用するホストは遠隔ホストである。”という事である。

ところが、所定のソースホストが、同じサブネットに存在する目的地を接近する方式と、遠隔に存在する目的地を接近する方式とは完全に違う。図３を参照すれば、ターゲット目的地のＩＰアドレスが確保されれば（３１）、ソースホストは目的地が同じサブネットに存在するか遠隔に存在するかを判断後（３２）、いかなる措置を取るかを示す。遠隔に存在する目的地に対して、ソースホストはデフォルトゲートウェイを通じてパケットを送る（３３）。同じサブネットに存在する目的地に対して、ソースホストはイーサーネット上でＡＲＰリクエスト（Ｒｅｑｕｅｓｔ）メッセージをブロードキャストする（３４）。ＡＲＰリクエストメッセージの意味は、“ｗ．ｘ．ｙ．ｚというＩＰアドレスを使用するホストのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスは何か？”である。ＭＡＣアドレスが確保されれば（３５）、ソースは目的地ホストに対して直接パケットを送る（３６）。ＭＡＣアドレスが確保されなければ、通信は失敗する（３７）。即ち、目的地がソースホストと同じサブネット内に存在する場合、ソースホストはＡＲＰリクエストをブロードキャストして目的地のＭＡＣアドレスを知ろうと試みる。ＭＡＣアドレスの確保後には、ソースホストはルーティングなしに直接目的地にパケットを送る。反面、目的地が遠隔に存在する場合、ソースホストはパケットをデフォルトゲートウェイに送ってルーティングされるようにする。

ところが、ＮＡＴ機能をするエッジルータ１２０は、複数台のＬＩＰホストが１つ又は少数のＧＩＰアドレスを利用してインターネットに連結させるが、様々な限界を伴う。多数のインターネット通信アプリケーションがＮＡＴを通過できなかったり、通信セッションが内部で始まらない通信に対しては正しく処理できなかったり、ペイロードの中にＩＰアドレス或いはポート番号変更情報が含まれている時にも正しく処理できなかったりする。そして、ＬＩＰホストらはＮＡＴを通してインターネットに接続出来るが、その接続の質は制限されざるをえない。

また、前述したように、ＧＩＰホストとＬＩＰホストはサブネットが違うため、同じＬＡＮセグメントに連結していても、ＧＩＰホストとＬＩＰホストとの間の通信を行うにはエッジ内ルーティングを必ず必要とする。そして、ＩＰホストの増大と伴い、エッジ網における一部ホストらに対してはＧＩＰアドレスをコンフィギュレーションし、他の一部ホストらに対してはＬＩＰアドレスを配分する必要性がより切実になっている。しかし、エッジ網に複数のサブネット構造を適用するのには困難性がある。第１に、ルータの設定のためには固定ＧＩＰアドレスを用いたインターネット接続をしなければならないが、事実上これは高すぎるため、一般人の使用が不可能である。第２に、複数のサブネットエッジ網は上手なネットワーク管理を必要とする。誰かは各ホストとルータを設定し管理しなければならない。従って、ＧＩＰホストとＬＩＰホストとの間にエッジ内ルーテリングなしに連動するようにする必要性が益々大きくなっている。

従って、本発明の目的は、本来の真のサブネットマスク値より大きい間違ったサブネットマスクを利用して、単一のＬＡＮセグメント上の互いに異なるサブネットに属する複数のホスト（ＧＩＰホスト及びＬＩＰホストと）が、同じサブネットを持つと勘違いして連動させる、エッジ内ルーティングのない宅内ＩＰ通信装置を提供することにある。ここで、間違ったサブネットマスクとは以下で述べるスーパーマスクである。スーパーマスクは、「／１」から「／２３」までの値をネットワークプレフィックス長とするサブネットマスクであり、なるべく大きいサブネットに成り得るよう「／１」の値が推奨される。このように大きなサブネットを指定するスーパーマスクの「／十進数」表記そのものは真のサブネットマスク値より小さい数字となる。

本発明の他の目的は、本来の真のサブネットマスク値より大きい間違ったサブネットマスクを利用して、単一のＬＡＮセグメント上の互いに異なるサブネットに属するホース間の通信時には同じサブネットを持つと勘違いして連動させ、インターネットの接続時にはホスト本来のサブネットによって通信するようにする、エッジ内ルーティングのない宅内ＩＰ通信装置を提供することにある。

本発明のまた他の目的は、本来の真のサブネットマスク値より大きい 間違ったサブネットマスクを利用して、単一のＬＡＮセグメント上の互いに異なるサブネットに属する複数のホストがルーティングなしに相互連動出来るようにする通信方法を提供することにある。ここで、間違ったサブネットマスクとは段落００１４で述べたスーパーマスクのことを示す。

本発明の更に他の目的は、本来の真のサブネットマスク値より大きい間違ったサブネットマスクを利用して、単一のＬＡＮセグメント上の互いに異なるサブネットに属する複数のホストがルーティングなしに相互連動出来ると同時に、インターネットに円滑に接続出来る通信方法を提供することにある。

前記目的を達成するために、本発明のＩＰ通信装置は、エッジまたは宅内におけるスーパーマスクコンフィギュレーションを行うＤＨＣＰプロキシサーバを含む。スーパーマスクの目的は、単一のＬＡＮセグメント上の複数のＬＩＰホスト及びＧＩＰホスト間のエッジ内ルーティングない通信のためのものである。単一のＬＡＮセグメントはエッジルータ、ＮＡＴボックス及び複数のＧＩＰホストとＬＩＰホストからなる。ＤＨＣＰプロキシサーバを持つ通信装置は単一のＬＡＮセグメント内に設置される。ＤＨＣＰプロキシサーバを持つ通信装置は複数のクライアント宅内ＤＧＩＰホスト及びＬＩＰホストのサブネットマスクを偽造して間違った値で作る。間違ったサブネットマスクは複数のクライアント宅内ＧＩＰホストとＬＩＰホストが同じサブネットに属すると勘違いする、非現実的かつ非正常的に大きいサブネットを意味する。ここで、間違った非正常的なサブネットマスクは“スーパーマスク”と称され、間違ったサブネットマスクは“間違ったスーパーサブネット”と称される。

詳しくは、前記ＤＨＣＰプロキシサーバは、前記クライアントホストのＭＡＣアドレスを基準として、ネットワーク管理者のＩＰアドレス割当政策によって設定された、各クライアントホストに割り当てられるＩＰ接続サービス種類、ＩＰアドレスタイプ及びＩＰアドレス値が記録されたテーブル（ＰＨＩＭＴ：Ｐｒｅｍｉｓｅｓ Ｈｏｓｔ ＩＰ ａｎｄ ＭＡＣ Ｔａｂｌｅ）、前記クライアントホストで発生した前記ＤＨＣＰメッセージを受信後、前記ＰＨＩＭＴを参照して前記ＤＨＣＰメッセージを発生したクライアントホストのＩＰアドレスタイプを判断する手段、前記クライアントホストがＬＩＰホストの場合には、前記ネットワーク管理者のＩＰアドレス割当政策により、自体管理するＬＩＰ資源から間違ったスーパーマスクを持つＬＩＰを選択して前記クライアントホストに割り当てる手段、前記クライアントホストがＧＩＰホストの場合には、ＤＨＣＰメッセージを前記元ＤＨＣＰサーバに転送する手段、前記ＤＨＣＰメッセージに応答して、前記元ＤＨＣＰサーバから受信したＤＨＣＰ承認メッセージ内に含まれたＩＰコンフィギュレーション情報中のサブネットマスクを前記サブネットマスクより大きいスーパーマスクに変調する手段、及び、前記スーパーマスクを含む変調されたＩＰコンフィギュレーション情報を利用して、クライアントホストのＩＰコンフィギュレーションを行う手段を含む。

また、前記ＤＨＣＰプロキシサーバは、前記承認メッセージ中の前記元ＤＨＣＰサーバのＩＰアドレスであるＤＨＣＰサーバＩＤを、前記ＤＨＣＰプロキシサーバのＩＰアドレスに変える手段、前記元ＤＨＣＰサーバで設定したＯＬＴ（Ｏｒｉｇｉｎａｌ Ｌｅａｓｅ Ｔｉｍｅ）を短縮して、前記ＤＨＣＰプロキシサーバで適用されるＰＬＴ（Ｐｒｅｍｉｓｅｓ Ｌｅａｓｅ Ｔｉｍｅ）を設定する手段、一定期間の間、前記ホストの更新リクエストが前記元ＤＨＣＰサーバに伝達されることを遮断し、前記更新リクエストに対して前記ＤＨＣＰプロキシサーバが自体応答する時間であるＣＥＴ（Ｃａｃｈｉｎｇ Ｅｘｐｉｒａｔｉｏｎ Ｔｉｍｅ）を設定し動作させる手段を更に含む。他の方法として、ＩＰ通信装置は、複数のＧＩＰクライアントホストをエッジルータに連結し、複数ＬＩＰホストをＮＡＴボックスに連結するゲートウェイ装置を更に含み、ＤＨＣＰプロキシサーバはゲートウェイ装置に内蔵されることが出来る。ＮＡＴボックスは宅内ではなく外部にあり、エッジＬＡＮセグメント内の複数の宅内で存在するＬＩＰホストとして利用される。

そして、ＤＨＣＰプロキシサーバによって互いに異なる種類のＩＰホスト間にもルーティングなしにＬＡＮセグメント構成が可能になるので、ＤＨＣＰプロキシサーバが内蔵された通信装置にはＬＩＰアドレスが付与されることが出来る。ゲートウェイ装置を含むＧＩＰホストとＬＩＰホスト共にスーパーマスクからコンフィギュレーションされ、これらが同様に間違ったスーパーサブネットに属するものと誘導されるので、ホームゲートウェイのようなゲートウェイ装置にＬＩＰアドレスが付与された状態でも、宅内ＬＩＰホストだけでなく宅内ＧＩＰホストはＮＡＴボックス無しにゲートウェイと通信出来る。

ＮＡＴボックスは、ＮＡＴボックスのＬＩＰインターフェース及びＧＩＰインターフェースを通じて、ＬＩＰアドレスからコンフィギュレーションされたゲートウェイ装置と元ＤＨＣＰサーバとの間のＤＨＣＰメッセージを伝達するためのＤＨＣＰ補助リレーモジュールを含む。そして、複数のゲートウェイ装置の各々が、アップストリームパケットのソースＭＡＣアドレスをゲートウェイ装置のＭＡＣアドレスに変換し、ダウンストリームパケットの目的地ＭＡＣアドレスを目的地宅内ホストのＭＡＣアドレスに変換するＤＬＡＴ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ ）モジュールを含む条件において、ＤＨＣＰメッセージを元ＤＨＣＰサーバから複数のゲートウェイに伝達する時、ＮＡＴボックスは、ダウンストリームＤＨＣＰパケットのデータリンクレイヤ目的地アドレスとして、ブロードキャストアドレス又はゲートウェイ装置のＭＡＣアドレスを使用するようにする手段を含む。

また、本発明によるＩＰ通信装置は、ＤＧＩＰホスト及びＬＩＰホストからなる複数のクライアントホストの真のサブネットを認知し、また、複数のクライアントホストのデフォルトゲートウェイのＭＡＣアドレスを認知する、サブネット−認知型ＡＲＰプロキシサーバを更に含む。サブネット−認知型ＡＲＰプロキシサーバは、ＤＨＣＰプロキシサーバを通じてコンフィギュレーションしたスーパーマスクによって同じサブネットに属したものと認識される遠隔ホストに対する、複数のクライアントホストのＡＲＰリクエストブロードキャストのとき、複数のクライアントホストの１つに対応するデフォルトゲートウェイのＭＡＣアドレスを提供するように、サブネットにより決定された真のサブネットを回復させる。具体的に、サブネット−認知型ＡＲＰプロキシサーバは、元ＤＨＣＰサーバから提供された複数のクライアントホストの真のサブネットマスクを認知する手段、複数のクライアントホストの各々のデフォルトゲートウェイのＭＡＣアドレスを認知する手段、スーパーマスクにより同じサブネットに属するものと勘違いする遠隔ホストに対する、クライアントホストの間違ったＡＲＰリクエストブロードキャストが発生することを認知する手段、及び、間違ったＡＲＰリクエストブロードキャスト発生時、間違ったＡＲＰリクエストブロードキャストに応答して、クライアントホストのデフォルトゲートウェイのＭＡＣアドレスを前記クライアントホストに付与する手段を含む。

本発明の目的を達成するために、本発明は、エッジルータ、ＮＡＴボックス及び複数のＬＩＰホストと複数のＤＧＩＰホストからなる複数の宅内ホストで構成されている単一のエッジＬＡＮセグメントからなる複数のサブネットエッジ網を用いた通信方法において、まず、複数のクライアントホストの少なくとも１つがＤＨＣＰメッセージをブロードキャストする。ＤＨＣＰプロキシサーバは、クライアントホストがＬＩＰホストの場合、元ＤＨＣＰサーバで管理されたＬＩＰ資源から偽造したスーパーマスクを持つＬＩＰアドレスを利用して、複数のクライアントホストの少なくとも１つをコンフィギュレーションし、クライアントホストがＤＧＩＰホストの場合、ＤＨＣＰメッセージを元ＤＨＣＰサーバに転送する。ＤＨＣＰプロキシサーバは、元ＤＨＣＰサーバからＤＨＣＰメッセージに対応する承認メッセージを受けて所定のテーブルに記録する。ここで、承認メッセージにはサブネットマスクを含むＩＰコンフィギュレーション情報が含まれる。また、サブネットマスクをサブネットマスクより大きい値を持つスーパーマスクに変更し、スーパーマスクを含む変調されたＩＰコンフィギュレーション情報を用いてクライアントホストをＩＰコンフィギュレーションする。以後、ＩＰコンフィギュレーションしたクライアントホストとターゲットホストとの間の通信を行う。

クライアントホストとターゲットホスト間の通信の際、ＩＰアドレスの付与されたソースホストがスーパーマスクによりカバーされるターゲット目的地への通信のためのＡＲＰリクエストをブロードキャストする。サブネット−認知型ＡＲＰプロキシサーバがサブネットマスク及びスーパーマスクにより決定されたサブネットを認知する状態で、サブネットマスクにより決定されたソースホストの真のサブネットにターゲット目的地が属するかを判断する。目的地ＩＰアドレスが、スーパーマスクによるソースホストのサブネットには属するが、サブネットマスクによるソースホストのサブネットには属しない場合、サブネット−認知型ＡＲＰプロキシサーバがＡＲＰリクエストに対応してソースホストのデフォルトゲートウェイのＭＡＣアドレスを前記ソースホストに通知する。ソースホストは、デフォルトゲートウェイのＭＡＣアドレス及び目的地ＩＰアドレスを含むパケットを作成して、デフォルトゲートウェイを通じて目的地と通信する。

実施例１のように、単一の顧客エッジ網に本発明によるＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバを適用する場合の主な効果は、ネットワーク管理作業の量が低減されることである。従来の技術によれば、エッジルータでエッジ内ルーティングを行う場合、ネットワークプリンタ等の一部端末或いは応用において相互連動がよく行われないことがあり、ネットワーク管理業務の負荷を高める傾向がある。しかしながら、本発明によるＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバを持つ通信装置を使用すれば、単一の顧客の複数サブネットエッジ網の管理作業負荷を非常に低減することが出来る。

実施例２乃至実施例５は複数の顧客エッジ網に適用されるもので、本発明によるＤＨＣＰプロキシサーバ及びサブネット−認知型ＡＲＰプロキシサーバを内蔵したＢＲＧ（Ｂｒｉｄｇｅ ｈｏｍｅ Ｇａｔｅｗａｙ）を宅内のゲートウェイに設置する場合を示す。この場合、次のような非常に重要な効果がある。

第１に、ＩＳＰはホームゲートウェイによるＧＩＰの消耗なしに、顧客の宅内にＤＧＩＰ接続サービスとＬＩＰ接続サービスを同時に提供出来る。

第２に、ＩＳＰはＬＩＰ接続サービスを更に複数の接続サービス商品カテゴリーに細分化することにより、その用途を効果的かつ效率的に管理出来る。

第３に、ＩＳＰはホームゲートウェイにＬＩＰアドレスを付与して、これを遠隔にて管理出来る。

第４に、顧客においては、宅内のＧＩＰホストとＬＩＰホストが完全に相互連動することにより、正常なホームネットワーキングを構成出来る。

第５に、顧客は宅内にホストを追加したり、或いは各々のホストに対するＩＰ接続サービスを設定・変更・取消したりする際、ホスト自体に複雑にＩＰコンフィギュレーションする必要なしに、単にホームゲートウェイ自体のＰＨＩＭＴ設定で該ホストを選択後、それに対する接続サービス種類を指定すれば、短時間（数秒）内に自動で該ホストに対する接続サービス種類が新しく設定される。

第６に、前記効果を実現する時、既存のエッジルータ、既存のＤＨＣＰサーバ、既存のエッジ網装備、既存のモデムなどをそのまま使用出来るだけでなく、ＣＭＴＳに対する私設ＩＰブロック許容追加設定の場合を除いては既存のネットワーク設定をそのまま維持出来る。

以下、添付の図面に基づき、本発明による通信装置及び通信方法を詳細に説明する。

本発明は、エッジルータと複数のクライアントホストからなる単一のエッジＬＡＮセグメントで構成される複数サブネットエッジ網に適用される。ここで、複数のクライアントホストは複数のＬＩＰホストと複数のＧＩＰホストからなり、ＬＩＰホストとＧＩＰホストは互いに異なるサブネットを持つ。このような複数サブネットエッジ網において、本発明による通信装置は、ＩＰ通信のために、クライアントホスト（宅内ホスト）が要求したＤＨＣＰメッセージに応答して、元ＤＨＣＰサーバから提供された承認メッセージ内のサブネットマスクを含むＩＰコンフィギュレーション情報を変調して、前記ＧＩＰホストとＬＩＰホストが互いに同じサブネットを持ったと勘違いするように誘導するＤＨＣＰプロキシサーバを含む。ＩＰコンフィギュレーション情報の変調は“スーパー−マスキング（Ｓｕｐｅｒ−Ｍａｓｋｉｎｇ）又はサブネットマスク変更）”を含む。“スーパー−マスキング”とは、複数サブネットエッジ網内のＧＩＰホストとＬＩＰホストを、非常に大きなサブネットにコンフィギュレーションして、相互間に同じサブネットに属すると勘違いするようにすることにより、複数サブネットエッジ網内のＧＩＰホストとＬＩＰホストとの間のエッジ内ルーティング（Ｉｎｔｒａａ−ｅｄｇｅ Ｒｏｕｔｉｎｇ）の必要性を除去したのである。例えば、“スーパー−マスキング”により”／１”のサブネットマスクを使用する場合、０．０．０．０から１２７．２５５．２５５．２５５間のＧＩＰアドレスを使用するホストは１０．ｘ．ｘ．ｘ．ブロックに該当するＬＩＰホストと同じサブネットに存在すると信じることになる。また、その反対と同様である。そして、ＧＩＰホストのＧＩＰ帯域が１２８．０．０．０〜２４４．２５５．２５５．２５５間に存在する場合、ＬＩＰホストは１７２．１６〜３１ＬＩＰブロックまたは１９２．１６８ＬＩＰブロックを使用すればよい。

ここで“元ＤＨＣＰサーバ”は、ＩＰ通信のためのＩＰコンフィギュレーション情報を所定のソースホストに提供するサーバとして、インターネット上に遠隔にて存在する事が出来、複数サブネットエッジ網内の別途の装備の中に存在する事も出来る。反面、本発明によるＤＨＣＰプロキシサーバは、実はＤＨＣＰサーバではないが、ＧＩＰホストとＬＩＰホストの観点からＤＨＣＰサーバと取扱われるもので、ＧＩＰホストとＬＩＰホストが連結しているゲートウェイ装置、例えば、ＢＲＧに内蔵されていることが出来る。

また、ＩＰコンフィギュレーション情報の変調は、“ＤＨＣＰサーバアドレスフィールド変更”と“ＬＴ（Ｌｅａｓｅ Ｔｉｍｅ）調節”を含む。“ＤＨＣＰサーバアドレスフィールド変更”とは、ゲートウェイ装置に連結しているＩＰホストがブーティングされて、元ＤＨＣＰサーバから提供されたメッセージ内の元ＤＨＣＰサーバのアドレス（ＩＰ）を元ＤＨＣＰサーバではないゲートウェイ装置の自身のＩＰアドレスに変えることを言う。これにより、ＩＰホストはゲートウェイ装置をＤＨＣＰサーバと認識することにより、ＧＩＰホストの完璧なＬＡＮネットワークを形成することになる。

“ＬＴ調節”とは、本発明によるＤＨＣＰプロキシサーバが、ゲートウェイ装置を通してＩＰホストに伝達される情報の中のＬＴにおいて、元ＤＨＣＰサーバが適用したＯＬＴよりも短いＰＬＴを適用するように調節することを言う。ＰＬＴに代えることにより、ＩＰホストの接続サービス種類を変更することが迅速かつ容易になり、そして、リリーズ（ｒｅｌｅａｓｅ）しなくてシャットダウンしたＤＧＩＰ（Ｄｙｎｍｉｃ ＧＩＰ）ホストのＩＰのリリーズがより迅速になった。これについては実施例２で詳細に説明する。一方、“ＬＴ調節”による元ＤＨＣＰサーバの電算処理の負荷を解決するために、ＤＨＣＰプロキシサーバには“ＣＥＴ（Ｃａｃｈｉｎｇ Ｅｘｐｉｒａｔｉｏｎ Ｔｉｍｅ）機能”が付与される。“ＣＥＴ”はＯＬＴを基準として決定することが望ましく、ゲートウェイ装置は、ＯＬＴの一定時点までは宅内のホストが元ＤＨＣＰサーバに送る更新リクエストを自体処理し、一定時点の以後には直接更新を試みる機能である。望ましくは、ＣＥＴをＯＬＴの１／２程度で設定すれば良い。何故ならば、ＤＨＣＰ基準によれば、ＯＬＴの半分が経過した時、クライアントホストが更新リクエストをするように勧めるためである。ＰＬＴ及びＣＥＴは実施例２で詳細に説明する。

図４を参照して、本発明による“ＤＨＣＰプロキシサーバ”のＩＰコンフィギュレーション情報の変調過程を詳細に説明する。

図４を参照すれば、まず、ＤＨＣＰプロキシサーバにＤＨＣＰメッセージが到着すれば（４１）、ＤＨＣＰプロキシサーバは、前記ＤＨＣＰメッセージが宅内ＬＡＮセグメントから発生したか或いはエッジＬＡＮセグメントから発生したかを判断する（４２）。判断結果、宅内ＬＡＮセグメントから発生した場合、更に宅内ＬＡＮセグメントのＬＩＰホストから発生したか或いはＧＩＰホストから発生したかを判断する（４３）。宅内ＬＡＮセグメントのＬＩＰホストから発生した場合、ＤＨＣＰプロキシサーバは、ネットワーク管理者の設定政策によってＤＨＣＰプロキシサーバが管理するＬＩＰアドレス資源から所定のＬＩＰを選択してＬＩＰホストに割り当てる。即ち、ＤＨＣＰプロキシサーバがＬＩＰホストのＤＨＣＰリクエストに応答する。段階４３の判断結果、ＤＨＣＰメッセージが宅内ＬＡＮセグメントのＧＩＰホストから発生した場合、ＤＨＣＰプロキシサーバは、前記ＤＨＣＰメッセージがＢＯＯＴＰ（ＢＯＯｓＴｒａｐ Ｐｒｏｔｏｃｏｌ）リクエスト（ＤＨＣＰディスカバー（ｄｉｓｃｏｖｅｒ）、ＤＨＣＰリクエスト、ＤＨＣＰリリーズを含む）であるかを判断する（４５）。判断結果、ＢＯＯＴＰリクエストがＤＨＣＰリクエストの場合、現在の時刻がＣＥＴ以前かを判断する（４６）。ＣＥＴ以前の場合、ＤＨＣＰプロキシサーバが宅内ＤＧＩＰホストのＤＨＣＰリクエストに自体応答する（４７）。段階４５の判断結果、ＢＯＯＴＰリクエストがＤＨＣＰディスカバーやＤＨＣＰリリーズの場合、及び段階４８の判断結果、ＣＥＴ以前でない場合、該ＤＨＣＰメッセージを含むパケットを作成して、エッジルータを通じて遠隔の元ＤＨＣＰサーバに転送する（４８）。そして、元ＤＨＣＰサーバはＧＩＰホストのＤＨＣＰメッセージに応答する。このような応答メッセージが本発明によるＤＨＣＰプロキシサーバに受信されれば、即ち、段階４２においてＤＨＣＰメッセージがエッジＬＡＮセグメントから発生したと判断されれば、ＢＯＯＴＰ応答かを判断する（４２１）。ＢＯＯＴＰ応答は承認（Ａｃｋ）、承認不可（Ｎａｋ）及びオファー（ｏｆｆｅｒ）のメッセージを含む。ＢＯＯＴＰ応答でない場合、応答しない４２２。一方、ＢＯＯＴＰ応答が承認メッセージの場合、ＤＨＣＰプロキシサーバはＤＨＣＰメッセージがＤＨＣＰ承認かを決定する（４２３）。承認メッセージがない場合、ＤＨＣＰプロキシサーバはＤＨＣＰメッセージを承認不可またはオファーメッセージとして処理する。承認メッセージの場合、真のＩＰコンフィギュレーション情報を変更する（４２５）。ＤＨＣＰプロキシサーバは、ＯＬＴをＰＬＴに代えて、ＣＥＴを設定して前記テーブルに格納し、承認メッセージ内のサブネットマスクを変調して、サブネットマスクよりも大きい値を持つスーパー−サブネットマスクを設定し、宅内ＬＡＮセグメントに転送されるパケットのフィールドアドレスの中でＤＨＣＰサーバのアドレスをＤＨＣＰプロキシサーバのアドレスに変更する（４２５）。この時、必要に応じて承認メッセージ内の他の情報も変更出来る。次に、ＤＨＣＰプロキシサーバで変調された承認メッセージはＧＩＰホストに提供され、ホストは変調された情報を通じてＩＰコンフィギュレーションされる（４２６）。

一方、“スーパー−マスキング”は本来のＩＰコンフィギュレーション情報を非常に深刻に変調したものである。例えば、“スーパー−マスキング”によってサブネットマスクが“／１”に変調される場合、ＩＰホストらは全体のインターネットホストの半分が自分と同じサブネットに属していると勘違いするようになる。言わば、エッジサブネットに存在していると勘違いする遠隔ホストらが２１億個以上存在し得る。よって、目的地を勘違いするホストらの１つの場合、エッジ内ソースホストは目的地のＭＡＣアドレスを知るために不要なＡＲＰリクエストをブロードキャストすることになり、結局、通信に失敗する。

このような問題を解決するために、本発明による通信装置は、サブネット−認知型ＡＲＰプロキシサーバを更に含む。前記サブネット−認知型ＡＲＰプロキシサーバは、元ＤＨＣＰサーバから提供されたＩＰコンフィギュレーション情報の中の本来のサブネットマスクを認知していて、“スーパー−マスキング”されたＩＰホストのインターネットへの接続時、例えば、実は遠隔に存在する目的地に対してＡＲＰリクエストを使用してＬＡＮ上で接近しようとする時、本来のサブネットを回復させて本来のサブネットによって通信するようにする。また、サブネット−認知型ＡＲＰプロキシサーバは、ＧＩＰサブネットに対しても、ＬＩＰサブネットに対しても、各サブネットのデフォルトゲートウェイのＭＡＣアドレスに対しても認知している。前記サブネット−認知型ＡＲＰプロキシサーバは、エッジ網内の別途の装置の中に存在する事が出来、エッジルータ内に存在する事が出来、またはホームゲートウェイに存在することも出来る。

図５及び図６を参照して、“サブネット−認知型ＡＲＰプロキシサーバ”の動作を詳細に説明する。図５は本発明によるサブネット−認知型ＡＲＰプロキシサーバのフローチャートであり、図６は実は遠隔に存在するが、スーパー−マスキングされたサブネットに含まれているため、サブネット内に存在すると勘違いするホストらに対するＡＲＰ処理及び通信過程を示すシークエンスチャートである。

図５を参照すれば、ＩＰホストから発生したＡＲＰリクエストが到着する（５１）。サブネット−認知型ＡＲＰプロキシサーバは、リクエストを送付したホストがＧＩＰホストかＬＩＰホストかを判断する（５２）。ＧＩＰホストからのリクエストの場合、サブネット−認知型ＡＲＰプロキシサーバはターゲット目的地がソースホストのサブネット内にあるか遠隔にあるかを判断する（５６）。このために、サブネット−認知型ＡＲＰプロキシサーバは該エッジ網の真のサブネットを認知しなければならない。ターゲット目的地が真のサブネット内にある場合、サブネット−認知型ＡＲＰプロキシサーバは沈黙を維持し、ターゲット目的地の自身がリクエストに対して直接応答する（５８）。ターゲット目的地が遠隔にある場合、サブネット−認知型ＡＲＰプロキシサーバはＧＩＰホストらのデフォルトゲートウェイ、即ち、エッジルータのＭＡＣアドレスをリクエストを送付したホストに通知する（５７）。リクエストがＬＩＰホストから送った場合、ターゲット目的地がサブネット内にあれば、サブネット−認知型ＡＲＰプロキシサーバは沈黙する（５５）。反面、ターゲット目的地が遠隔ホストであれば、リクエストを送ったホストにエッジルータに内蔵されたＮＡＴのＭＡＣアドレスを通知する（５４）。一例として、エッジルータはＮＡＴのためにＬＡＮインターフェースにＬＩＰアドレスをエイリアスして保有している事が出来、この場合、エッジルータにＮＡＴが内蔵されているため、サブネット−認知型ＡＲＰプロキシサーバはエッジルータのＭＡＣアドレスを付与する。

ソースホストの観点から見れば、ターゲット目的地のＩＰアドレスは次の３種類の１つに該当する。第１に、目的地アドレスがスーパー−マスキングされたサブネット外にある場合、第２に、実は遠隔ホストであるが、“スーパー−マスキング”処理によりサブネット内のホストと勘違いする場合、第３に、サブネット内にある場合である。第１の場合、ソースホストは“スーパー−マスキング”されていても目的地が遠隔にあるということを正確に判断でき、通信に何らの問題がない。第２の場合、本発明によるサブネット−認知型ＡＲＰプロキシサーバはソースが送るブロードキャストに応答する。これにより、ソースはデフォルトゲートウェイを通じてパケットを送り、その結果、通信に成功する。第３の場合、目的地ホストの自身がＡＲＰリクエストに応答することにより、通信に成功する。即ち、エッジ内ホストらは、これらのサブネットマスクが非正常的に変調されていても、本発明によるサブネット−認知型ＡＲＰプロキシサーバのおかげで、正常なインターネット通信が可能になった。

前記第２の場合のホストらに対するＡＲＰ処理及び通信過程を、図６を参照してより詳細に説明する。図６を参照すれば、クライアントホスト６１は、ターゲット目的地遠隔ホストのＩＰアドレスを自身のサブネットマスクを使用して同じサブネットにあるかテストする（６５）。その結果、ターゲット目的地ホストがクライアントホストのサブネット内にあると勘違いする（６６）。その後、ソースは目的地のＭＡＣアドレスを知るために、ＡＲＰリクエストブロードキャストする（６７）。本発明によるサブネット−認知型ＡＲＰプロキシサーバは、ブロードキャストにより、前記リクエストが実は遠隔に存在するにも関わらず、ソースが同じサブネットにあると勘違いした目的地に関するものであることを発見する（６８）。サブネット−認知型ＡＲＰプロキシサーバは、ソースホストのデフォルトゲートウェイのＭＡＣアドレスをソースホストに通知する（６９）。ソースは目的地が同じサブネット、即ち、エッジ網内にあると信じ、その目的地のＭＡＣアドレスが確保されたと信じる（６１０）。ソースはデータリンクレイヤの目的地（ＤＬＤ：Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ Ｄｅｓｔｉｎａｔｉｏｎ）がデフォルトゲートウェイのＭＡＣアドレスとし、ネットワークレイヤの目的地（Ｎｅｔｗｏｒｋ Ｌａｙｅｒ Ｄｅｓｔｉｎａｔｉｏｎ）が遠隔目的地のＩＰアドレスとして、パケットを作成する６１１。 そして、作成したパケットをデフォルトゲートウェイに転送する６１２。デフォルトゲートウェイはこのパケットをルーティングしてインターネットに転送ことにより、通信に成功する（６１３、６１４）。

要約すれば、本発明によるＩＰ通信システムは、エッジ網内のホストらはエッジ内ルーティングの必要性をなくすために、サブネットを“スーパー−マスキング”するＤＨＣＰプロキシサーバを含む。ＤＨＣＰプロキシサーバにより発生し得る通信失敗を解決するために、スーパー−マスキングされた複数サブネットエッジ網の真のサブネットを認知していて、ホストがインターネット上のホストと接続しようとする場合、本来のサブネットによって通信するようにするサブネット−認知型ＡＲＰプロキシサーバを含む。これにより、複数サブネットエッジ網内のホスト間のルーティングないＩＰ通信が可能になり、インターネット上のホストとの円滑な接続が可能になる。

本発明によるＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバの具現事例を具体的に議論する前、ＧＩＰホストとＬＩＰホストが混在された複数サブネットエッジ網の類型や、このようなエッジ網でエッジ内ルーティングなしにＧＩＰホストとＬＩＰホストとの間が円滑に連動されるという点が持つ意義を説明する。

単一のＬＡＮセグメント上の複数サブネットエッジ網には２つの類型がある。即ち、単一顧客エッジ網と複数顧客エッジ網である。

例えば、単一顧客エッジ網は、専用線が引入されて数百個の固定ＧＩＰが使用されて良質のネットワーク管理が為されるエッジ網である。このような類型のエッジ網に対する本発明の主な効果は、ネットワーク管理作業の負荷を低減することである。例えば、ネットワークプリンタ等の一部端末は普通ＬＩＰを使用して設定されるが、エッジ内ルーティングを設定しても、ＧＩＰホストと連動されない場合がよくある。本発明はエッジ内ルーティングなしにＧＩＰホストとＬＩＰホストが直接連動するようにすることで、ネットワーク管理がより容易になる。本発明の実施例１はこのような単一顧客エッジ網に関するものである。

複数顧客エッジ網は、サイバーアパートＬＡＮセグメント、ＤＳＬセグメント、ケーブル方式のＣＭＴＳセグメントなどである。複数顧客エッジ網には、数百数千個の家庭或いは小型事務室が存在する。各々の家庭と小型事務室では高価の固定ＧＩＰアドレス連結を要求するルータを設置しにくく、上手なネットワーク管理者も存在していない。更に、各々の家庭或いは小型事務室は各々その自体として１つのエッジ網と似ているネットワークの独立性を要求する。本発明の実施例２乃至実施例５はこのような複数顧客エッジ網に関するものである。

最も簡単な具現方式は、単一顧客エッジ網に、本発明によるＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバを設置するものである。“単一顧客エッジ網”とは、エッジ内の全てのホストを容易に識別でき、エッジ内顧客を識別する必要がない場合を意味する。反面、複数顧客エッジとは、複数の顧客が存在し、顧客の各々が保有しているホストを識別し認証しにくいだけでなく、このエッジ内の全ての家庭と小型事務室が、実は１つのエッジルータにより管理されているにも関わらず、顧客の各々が自分の宅或いは事務室が１つのネットワークセグメントのように管理されることを要望する場合を意味する。

単一顧客エッジ網に適合した実施例１では、ＤＨＣＰプロキシサーバ、サブネット−認知型ＡＲＰプロキシサーバ、エッジルータ及びＮＡＴなどを、どんな方式にて統合しても構わないが、議論及び理解の明確性のために、ＮＡＴはエッジルータ内に内蔵され、ＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバは各々別途の装置で具現される場合を想定する。

本発明による実施例１と関連して、ＤＨＣＰプロキシサーバは２つの機能を持つべきである。第１に、ネットワーク管理者によって設定された各々のホストに対して定義されたＩＰアドレスの種類（公認か私設か）、及び使用するＩＰアドレス値を知っているべきである。第２に、ＤＨＣＰプロキシサーバは、クライアントホストのＩＰをコンフィギュレーションする時、変調された即ちスーパー−マスキングされた情報を付与すべきである。スーパー−マスキングがネットワークプリフィックスの“／１”乃至“／２３”間のものであるが、本明細書で望ましい値は”／１”である。スーパーマスクの十進数は元サブネットマスク”／２４”そのものの値が小さい。

実施例１のサブネット−認知型ＡＲＰプロキシサーバは、クライアントホストがブロードキャストするＡＲＰリクエストにより、リクエストで言及される目的地ＩＰアドレスがエッジサブネットに属するか否かを判断する。エッジサブネットに属しない遠隔ホストに対するリクエストの場合、サブネット−認知型ＡＲＰプロキシサーバは、クライアントホストに該ソースホストのデフォルトゲートウェイのＭＡＣアドレスを通報する。即ち、サブネット−認知型ＡＲＰプロキシサーバは、エッジの真のサブネット、ＧＩＰサブネット、ＬＩＰサブネット及び各サブネットに対するデフォルトゲートウェイのＭＡＣアドレスも知っているべきである。このような理由から、このプロキシを“サブネット−認知型ＡＲＰプロキシサーバ”と称する。

図７は実施例１による通信装置が含まれた複数サブネットエッジ網のブロックダイアグラムである。実際は、このようなエッジ網は固定ＧＩＰアドレスブロックを使用する専用線を備えた大型事務室であることが出来る。例えば、このエッジのＧＩＰサブネットは２１０．１．１．０，“／２５”、ＬＩＰ区間は１９２．１６８．１．０，“／２４”とする。

図７を参照すれば、インターネット７４に連結している専用線７１があり、専用線７１にエッジルータ７２０が連結している。エッジルータ７２０は２つのネットワークインターフェース、即ち、ＷＡＮインターフェース７２１とＬＡＮインターフェース７２２を持つ。ＷＡＮインターフェース７２１は２１０．１．０．１０，“／２１”にコンフィギュレーションされている。ＬＡＮインターフェース７２２は２１０．１．１．１，”／２５”にコンフィギュレーションされている。また、エッジルータ７２０にはＮＡＴが内蔵されているため、ＬＡＮインターフェースには１９２．１６８．１．１，”／２４”がエイリアスされている。

エッジルータ７２０に連結しているエッジＬＡＮセグメント７３には、ＧＩＰホスト７８１〜７８ｎとＬＩＰホスト７９１〜７９ｎがあり、本発明によるＤＨＣＰプロキシサーバ７７０とサブネット−認知型ＡＲＰプロキシサーバ７６０がある。

ＧＩＰホスト７８１〜７８ｎとＬＩＰホスト７９１〜７９ｎは、ＤＨＣＰプロキシサーバ７７０により動的にコンフィギュレーションされる。ＤＨＣＰプロキシサーバ７７０のネットワークインターフェース７７１は２個のＩＰコンフィギュレーションを持つが、注目すべき点はこの２個とも正確かつ正直にそのサブネットマスクが設定されているということである。１つは２１０．１．１．３，”／２５”のようなＧＩＰアドレスであり、もう１つは１９２．１６８．１．２，”／２４”のようなＬＩＰアドレスである。また、ネットワーク管理者は、各々のホスト７８１〜７８ｎ、７９１〜７９ｎに対してどんな種類のＩＰアドレスを使用するか、更にどんな値のＩＰアドレスを使用するかを設定でき、これに関する情報をＤＨＣＰプロキシサーバ７７０が認知すべきである。この設定をネットワーク管理者による“割当政策設定”だと定義することが出来る。

ＩＰホストにＩＰコンフィギュレーションを提供するとき、ＤＨＣＰプロキシサーバ７７０はサブネットマスクを例えば“／１”にスーパー−マスキングする。この時、注目すべき点は一部の運営体制は“／１”のような大きなサブネットをキーインして入力すれば入力を受けないということである。しかし、ＤＨＣＰサーバを使用すればその値を受ける。

また、デフォルトゲートウェイに対して、ＤＨＣＰプロキシサーバ７７０は、ＧＩＰホストにはエッジルータのＩＰアドレスを提供し、ＬＩＰホストにはＮＡＴのＩＰアドレスを提供する。図７のような場合、エッジルータにＮＡＴが内蔵されているので、この両方のＩＰアドレスは同一になる。

サブネット−認知型ＡＲＰプロキシサーバ７６０のネットワークインターフェースは２つのＩＰアドレスを持つ。１つは２１０．１．１．４，”／２５”のようなＧＩＰであり、もう１つは１９２．１６８．１．３，”／２４”のようなＬＩＰである。

ＩＰホストがブーティングされれば、ネットワーク管理者の設定（スーパーサブネットマスク値が設定される）により、ＤＨＣＰプロキシサーバ７７０はＧＩＰ又はＬＩＰにコンフィギュレーションを提供する。いずれもサブネットは“／１”にスーパー−マスキングされる。このようにサブネットマスクが拡大されることにより、ＧＩＰホスト７７８１〜７８ｎとＬＩＰホスト７９１〜７９ｎはエッジルータ７２０によるエッジ内ルーティングなしに互いにエッジＬＡＮセグメント７３上で自由に連動する。

ＩＰホストがスーパー−マスクによるサブネット範囲内に含まれた遠隔ターゲット目的地を接近しようとする時、例えば、１４８．２１０．３４．９を接近しようとする時、ホストはＡＲＰリクエストをブロードキャストする。これは、ソースホストが遠隔目的地ホストをサブネット内にあると勘違いするためである。本発明によるサブネット−認知型ＡＲＰプロキシサーバ７６０は、このブロードキャストを聞いて、ソースホストのデフォルトゲートウェイのＭＡＣアドレスを通報する。この時、デフォルトゲートウェイは、ソースホストがＧＩＰホストの場合はエッジルータになり、ソースホストがＬＩＰホストの場合はＮＡＴになるが、図７のような例ではエッジルータ内にＮＡＴが内蔵されているため、これらのデフォルトゲートウェイのＭＡＣアドレスは結局同一になる。

ＭＡＣアドレスを知っているソースホストは、依然としてこのＭＡＣアドレスが目的地のＭＡＣだと考えてパケットを作る。パケットのＤＬＤは確保されたＭＡＣアドレス（デフォルトゲートウェイのＭＡＣアドレス）を使用し、ＮＬＤは遠隔目的地のＩＰアドレスを使用してパケットを作った後、これをデフォルトゲートウェイに送る。ソースがＧＩＰの場合はそのままルーティングされてインターネットにパケットが出て行く事になり、ソースがＬＩＰの場合はＮＡＴされてインターネットに出て行く事になる。

従って、“スーパー−マスキング”を行うＤＨＣＰプロキシサーバ７７０と、これと共に使用するために発明されたサブネット−認知型ＡＲＰプロキシサーバ７６０とは、複数サブネットエッジ網内にあるホストらにエッジ内ルーティングなしに完璧に相互連動出来るように為される。

一般的に、多数の家庭と小型事務室は１つのエッジ網に属する。例えば、ＩＳＰエッジルータは１つのアパートＬＡＮ、１つのＤＳＬセグメント或いは１つのＣＭＴＳセグメント内の数百加入者の家庭と事務室をサービスする。このように１つのルータが数百個の家庭と事務室をサービスするにも関わらず、これらの顧客の各々は自身の宅又は事務室（以下、便宜上、“宅内”という）において、ＩＳＰの認証なしに自由にホストを変更したり、外部インターネットには連結していないネットワークプリンタなどを別途の費用なしに連結したり、プライバシーが保護される宅内網の独立性を持ったりするなどのエッジ網と同じ特性を持つことを要望する。

本発明の実施例２は、本発明によるＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバを内蔵したブリッジ構造のホームゲートウェイ（ＢＲＧ：Ｂｒｉｄｇｅ Ｒｅｓｉｄｅｎｔｉａｌ Ｇａｔｅｗａｙ）を利用したエッジ網構造に関するものである。ここで、ホームゲートウェイとは、宅内ＬＡＮをエッジ網と連結する装置を意味する。

図８は本発明をアパートＬＡＮに適用した状態を示すエッジ網のブロックダイアグラムである。図８を参照すれば、専用線８１がエッジルータ８２０に連結しており、アパート共用のＮＡＴボックス８６０がエッジルータ８２０に連結している。このアパートにはｎ個の顧客の家庭がある。この家庭のゲートウェイには本発明によるＢＲＧ８５１０〜８５ｎ０が設置され、ＢＲＧが宅内ＬＡＮ８３１〜８３ｎをエッジＬＡＮセグメント８３０に連結させる。ＢＲＧ１８５１０に連結している宅内には、該顧客とＩＳＰとの間の該利用約款により、例えば、２台のＤＧＩＰホスト８７１１１、８７１１２が存在し、ｎ台のＬＩＰホスト８７１２１−８７１２ｎが存在する。このエッジ網のＧＩＰサブネットは例えば２１０．１．０．０，“／２３”であり、ＬＩＰサブネットは１７２．３０．０．０，”／２０”である。エッジルータ８２０のローカルインターフェース８２２は２１０．１．０．１，”／２３”で設定され、そのアドレスは団地内ＧＩＰホストらに対するデフォルトゲートウェイのアドレスであることも出来る。エッジルータ８２０はエッジ網内のＬＩＰホストの存在を認知する必要がない事が望ましい。何故ならば、本発明の根本趣旨は既存の網装備及びその設定を最大限そのまま保存出来ることにあるからである。

一般的に、エッジルータにはエッジ内のＤＨＣＰブロードキャストメッセージを外部のＤＨＣＰサーバに連結させるＤＨＣＰリレーが内蔵されている。最近、ＤＨＣＰサーバをエッジ内に設置することなく、遠隔に設置して多数のエッジ網をサービスする方式が益々多く使用されている。一般的なＤＨＣＰ及び本発明によるＢＲＧのＤＨＣＰプロキシサーバについては後で詳細に議論する。

ＮＡＴボックス８６０は２つのネットワークインターフェースを持つ。ＬＩＰアドレスを持つインターフェース８６２は例えば１７２．３０．０．１，”／２０”で設定され、ＧＩＰアドレスを持つインターフェース８６１は例えば２１０．１．０．２，“／２３”で設定される。ＧＩＰインターフェース８６１はＬＡＮ８４を通じてエッジルータ８２０に連結している。

本発明によるＢＲＧ８５１０〜８５ｎ０は、宅内ＤＧＩＰホスト及びＬＩＰホスト８７１１１、８７１１２、８７１２１〜８７１２ｎに対してＤＨＣＰプロキシサーバとして作動する。ＬＩＰに対してはＩＳＰがエッジ内でユニークに例えば加入者ごとに予め５０個ずつ割り当てて運営出来る。ＬＩＰを使用するように設定された宅内ホストがブーティングされれば、ＢＲＧ８５１０〜８５ｎ０は自身により運営される私設ＩＰアドレス資源から該ＬＩＰを選択してＬＩＰホストに配分する。

反面、ＤＧＩＰを使用するように設定されたホストに対して、ＢＲＧ８５１０〜８５ｎ０の役割はＤＨＣＰサーバ機能だけでは充分でない。ＤＧＩＰホストに対してはブーティング時に外部の元ＤＨＣＰサーバからＩＰを受けて伝達しなければならないためである。本発明によるＢＲＧ８５１０〜８５ｎ０に内蔵されたＤＨＣＰプロキシサーバは、宅内に対してはＤＨＣＰサーバとして作動し、ＤＧＩＰと関連して宅外ＤＨＣＰサーバに対してはＤＨＣＰクライアントヘルプ（ＤＨＣＰ Ｃｌｉｅｎｔ Ｈｅｌｐ）として作動する。本発明によるＤＨＣＰプロキシサーバは、後述するＤＬＡＴ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）環境下で、スーパーマスキングされている宅内クライアントが外部元ＤＨＣＰサーバと直接通信するように手助けする役割をする同時に、外部元ＤＨＣＰサーバが提供するコンフィギュレーション情報を操作して、クライアントにＢＲＧ８５１０〜８５ｎ０自身をＤＨＣＰサーバと認識するようにすることで、より完璧なホームネットワーキングが為される。

ＤＧＩＰを使用するように設定されているホストがブーティングされれば、ＢＲＧ８５１０〜８５ｎ０のＤＨＣＰプロキシサーバは、宅内ホストのディスカバー及びリクエストブロードキャストメッセージをエッジＬＡＮセグメント８３０に伝達し、それに対応して元ＤＨＣＰサーバ側から受けたメッセージ（応答）を変調して宅内クライアントホストをコンフィギュレーションする。この過程については図９乃至図１２ｄで詳細に説明する。

ここで、注目すべき点の１つは、ＮＡＴボックス８６０にＤＨＣＰ補助リレー機能をするプログラムモジュールを設置したことである。一般的に、ＤＨＣＰリレーはエッジルータ内に具現されている。通常、リレーはＤＨＣＰメッセージのペイロード内に言及されているクライアントホストのＭＡＣ（ＤＨＣＰ．ｃｈａｄｄｒ）に直ぐ応答する。ところが、本発明によるＢＲＧ８５１０〜８５ｎ０にはデータリンクレイヤアドレス変換モジュール（後述する）が設置され、一般的なリレーの場合のようにペイロード内のＭＡＣで通信を試みれば通信がなされない。本発明のＢＲＧ８５１０〜８５ｎ０のデータリンクレイヤアドレス変換機能は、本発明の核心要素であるＤＨＣＰプロキシサーバやサブネット−認知型ＡＲＰプロキシサーバとは異なり、付加的な要素であり、選択的に稼動されるか或いは稼動されないが、アパートＬＡＮのようにノードの数が多いＬＡＮでは非常に有用な機能である。

本発明によるＮＡＴボックス８６２に内蔵されているＤＨＣＰ補助リレー（ＤＨＣＰ Ａｕｘｉｌｉａｒｙ Ｒｅｌａｙ）機能をするプログラムモジュールは、一般のリレー用プログラムモジュールに比べて次の２つの差がある。第１に、ＮＡＴボックス８６２の私設インターフェース８６１でクライアントホストから受信したものを公認インターフェース８６２を通じて元ＤＨＣＰサーバに送り、反対に公認インターフェース８６２を通じて元ＤＨＣＰサーバから受信したものを私設インターフェース８６１を通じてクライアントに送るということである。一般のリレーは公認インターフェースを通じて受信して公認インターフェースを通じて送信する。第２に、ホストに送信時、エッジＬＡＮセグメント８３０上でブロードキャストしたり、或いはＢＲＧのＭＡＣをＤＬＤで使用したりするということである。本発明によるＤＨＣＰ補助リレーにより、ＢＲＧのＤＬＡＴ機能にも関わらず、遠隔のＤＨＣＰサーバとＢＲＧのＤＨＣＰプロキシサーバは円滑に通信出来ることになった。

本発明によるＢＲＧのＤＨＣＰプロキシサーバが遠隔ＤＨＣＰサーバからＤＧＩＰコンフィギュレーション情報を受信すれば、ＤＨＣＰプロキシサーバは、サブネットマスクを“／１”のようなスーパー−サブネットマスクに変更し、ＤＨＣＰサーバのアドレスを自分のものと変更し、選択的にはＬＴなどを変更して、宅内ホストをコンフィギュレーションする。

簡単に言えば、ＢＲＧ８５１０〜８５ｎ０のＤＨＣＰプロキシサーバは、ＢＲＧ８５１０〜８５ｎ０がＤＬＡＴを実行している状況で、スーパー−マスキングされている宅内ホストが外部元ＤＨＣＰサーバと円滑に通信して、ＩＰコンフィギュレーションを受信出来るように支援し、一旦、ＩＰコンフィギュレーション情報がＢＲＧ８５１０〜８５ｎ０に受信されれば、これを変調して宅内ホストに伝達することにより、宅内ホストに対して元ＤＨＣＰサーバのように作用する。

ＤＨＣＰの一般的な作動原理を説明すると同時に、本発明によるＤＨＣＰプロキシサーバの動作を詳細に説明する。

図９は宅内ＤＧＩＰホストに関し、各種ＤＨＣＰメッセージがどのようにプロセシングされるかを示し、図１０は宅内ＬＩＰホストに関し、各種ＤＨＣＰメッセージがどのようにプロセシングされるかを示す。注目すべき点は、ＢＲＧはブリッジであり、１つの管理用ＬＩＰを持ち、２つのネットワークインターフェースを持つということである。ルータやＮＡＴボックスとは異なり、ネットワークインターフェース自体にはＩＰアドレスを持っていない。ネットワークインターフェースの１つはエッジＬＡＮセグメント８３０に連結しており、もう１つは宅内ＬＡＮセグメント８３１〜８３ｎに連結している。そして、図９乃至図１２ｄにおいて、“外部転送（ｓｅｎｄ ｏｕｔ）”はブリッジがエッジＬＡＮセグメントに転送するという意味であり、“内部電送 （ｓｅｎｄ ｉｎ）”はブリッジが宅内ＬＡＮセグメントに転送するという意味である。

ＤＨＣＰプロトコルには、クライアントホスト（発信地又はソース）が送る五つのメッセージと、元ＤＨＣＰサーバが送る三つのメッセージとが存在する。ディスカバーはクライアントホストがブロードキャストするメッセージとして、“私のＤＨＣＰサーバはだれですか。私にＩＰコンフィギュレーションを提供して下さい。”という意味である。ブロードキャストしたディスカバーメッセージを受信後、ＤＨＣＰサーバはオファーを送る。オファーは“あなたはＩＰアドレスＡを使用出来る。”という意味である。オファーを受けたクライアントホストはリクエストをブロードキャストするが、“私はＩＰアドレスＡを使用したい。”という意味である。ブロードキャストしたリクエストを受けたＤＨＣＰサーバは最終の承認メッセージを送るが、“あなたはＩＰアドレスＡを使用すると確定された。”という意味である。これからクライアントホストはアドレスを持っている状態即ちバウンド（Ｂｏｕｎｄ）状態となる。クライアントホストは、ドメインネームサービス（ＤＳＮ：Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅ）サーバアドレス等の追加的な情報が承認メッセージに含まれず、他のサーバから受けなければならない状況であれば、情報（Ｉｎｆｏｒｍ）メッセージを送る。 また、クライアントホストは、オファーを受けたアドレスが他のホストのアドレスと衝突したりする場合には拒否（Ｄｅｃｌｉｎｅ）メッセージを送る。クライアントホストは終了状態になりながらリリースメッセージを送る。また、クライアントはＬＴを延長するための更新申請に対するリクエストを送る。この時、送るリクエストはブロードキャストでなくユニキャストで送る。サーバは、更新リクエストを拒む場合には承認不可メッセージを送り、受諾する場合には承認メッセージを送る。クライアントホストは更新に失敗する場合には更にディスカバー段階を開始する。

図１１ａ〜図１１ｄは本発明によるＢＲＧに内蔵されたＤＨＣＰプロキシサーバの動作フローチャートである。ＤＨＣＰメッセージがＢＲＧに到着する（１１０１）。ＤＨＣＰメッセージか否かは、ＢＯＯＴＰメッセージ（ＵＤＰ６７、６８番ポート）のオプションフィールドにＤＨＣＰメッセージであることを通知するマジックナンバーの存在有無により判断する。ＢＲＧはこのメッセージがエッジＬＡＮセグメントから到着したか、或いは宅内ＬＡＮセグメントから到着したか判断する（１１０２）。宅内ＬＡＮセグメントから到着した場合、ＢＲＧはＤＨＣＰメッセージペイロード内のＭＡＣアドレス（これをＤＨＣＰ標準では“ＤＨＣＰ．ｃｈａｄｄｒ”という）がＢＲＧの宅内ホストリスト（ＰＨＩＭＴ：Ｐｒｅｍｉｓｅｓ Ｈｏｓｔ ＩＰ ａｎｄ ＭＡＣ Ｔａｂｌｅ）の中に含まれるかを確認する（１１０３）。

ＰＨＩＭＴを具現して管理する方法には様々な方式がある。ＰＨＩＭＴは宅内ホストのＭＡＣアドレスを基準として、該ホストが使用すべきＩＰ接続サービスの種類及びＩＰアドレス種類を記録したテーブルである。この時、ＩＰ接続サービスの種類はＩＳＰにより定義される。ＢＲＧは知能的なブリッジ装置であって、データリンクレイヤでのフィルターリング等の知能的な作業を行うことが出来るため、ＩＳＰはこのような特性を利用して複数の接続サービス種類を管理出来る。

例えば、ＩＳＰは“宅内だけ”という宅内だけでは無料でＩＰ通信が可能な接続サービス種類を定義し、今まで宅内では接続したことがなく、初めて接続する装置に対してはこれをデフォルトで提供出来る。この場合、ＢＲＧは該ホストに対して他の接続サービス種類が再設定されない限り、ＬＩＰを付与し、宅外とのインターネット通信を遮断する。このような方式によるＰＨＩＭＴの運営の長所は、ユーザがホームネットワーキングのために自由にＩＰ端末を宅内ＬＡＮに連結出来ること、宅外へのインターネット通信はＩＳＰに適正価格を支払ったホストだけに対して可能であることである。ＰＨＩＭＴをどんな政策により具現して運営しても、本発明によるＤＨＣＰプロキシサーバは、ＤＨＣＰペイロード内のＤＨＣＰ．ＣｈａｄｄｒがＰＨＩＭＴに含まれているかを確認する。

ＤＨＣＰペイロード内のＭＡＣ（ＤＨＣＰ．Ｃｈａｄｄｒ）がＰＨＩＭＴに含まれていない場合、ＢＲＧはメッセージを無視し応答しない（１１０４）。含まれていれば、ＬＩＰアドレスを使用するホストか否かを確認する（１１０５）。ＬＩＰアドレスを使用するホストの場合、図１０に示す論理によって応答する（１１０６）。ＤＧＩＰを使用するホストの場合、メッセージがＢＯＯＴＰリクエストかを判断する（１１０７）。ＢＯＯＴＰリクエストはＤＨＣＰディスカバー、リクエスト、リリーズなどを含む。ＢＯＯＴＰリクエストでなければ、ＢＲＧは応答しない（１１０８）。

ＢＯＯＴＰリクエストの場合、ＢＲＧはＤＨＣＰディスカバーメッセージかを確認する（１１０９）。ＤＨＣＰディスカバーの場合、新しいディスカバーメッセージか、或いはコンフィギュレーションを待っていて更に繰り返して送る連続的なメッセージかを確認する（１１３２）。連続的なディスカバーメッセージであれば、プロセスＡ´につながる。連続的でない新しいディスカバーメッセージであれば、流動公認割当テーブル１１１２及びＤＨＣＰセッション記録を清掃（ｃｌｅａｒｉｎｇ）する（１１１１）。次に、プロセスはＡ´につながる。ＤＨＣＰセッションに関する正義は後述する。流動公認割当テーブル（ＤＧＩＰ Ａｓｓｉｇｎｍｅｎｔ Ｔａｂｌｅ）は宅内流動公認ホストに対するＤＧＩＰアドレスの割当からリリーズまでの全ての情報を記録したテーブルである。

ディスカバーメッセージではない場合、ＢＲＧはメッセージがＤＨＣＰリリーズかを判断する１１１０。ＤＨＣＰリリーズの場合、流動公認割当テーブル１１１２及びＤＨＣＰセッション記録を清掃する（１１１１）。次に、プロセスはＡ´につながる。ＤＨＣＰリリーズではない場合、ＤＨＣＰリクエストかを確認する（１１１３）。ＤＨＣＰリクエストではない場合にはＡ´につながる。ＤＨＣＰリクエストの場合には現在時刻がＣＥＴ以前かを判断する（１１１４）。さもなければ、次のプロセスはＡ´につながる。現在時刻がＣＥＴ以前であれば、ＢＲＧは直接承認メッセージをＤＨＣＰメッセージが発生したソースホストに送る（１１１５）。

ＣＥＴは本発明による用語であり、本発明による用語であるＰＬＴ及びＯＬＴと密接な関連性がある。ＩＳＰの元ＤＨＣＰサーバのリースタイム（ＬＴ：Ｌｅａｓｅ Ｔｉｍｅ）が例えば６０分（３，６００秒）の場合、本発明によるＢＲＧのＤＨＣＰプロキシサーバは、前記元ＤＨＣＰサーバのＬＴより非常に短く例えば６０秒で低減することが出来る。元ＤＨＣＰサーバが適用したリースタイム（Ｌｅａｓｅ Ｔｉｍｅ）をＯＬＴとし、ＢＲＧのＤＨＣＰプロキシサーバが適用したリースタイムをＰＬＴとする。ＯＬＴよりも非常に短いＰＬＴを適用する場合、次のような２つの長所がある。

第１に、ユーザが該ホストに対するＩＰ接続サービスの種類を変更したい場合、該ホスト自体の設定を変更することなく、ＢＲＧのＰＨＩＭＴの設定を変更さえすればよい。何秒後にＩＰコンフィギュレーションが更に行われるため、ＰＨＩＭＴ設定変更内容がその時に反映される。第２に、ＤＧＩＰアドレスを使用するホストが正しくＩＰアドレスをリリーズしなくてシャットダウンされた場合、これを数秒内に返還出来る。

一方、ＯＬＴよりも非常に短い例えば６０秒間隔のＰＬＴを適用すれば、ＤＧＩＰを使用するホストはＴ１を３０秒、Ｔ２を５２．５秒と認識することになる。Ｔ１、Ｔ２はＤＨＣＰ標準で定義されたもので、Ｔ１はリースタイムの０．５、Ｔ２はリースタイムの０．８７５を使用することを勧めている。Ｔ１までホストは該ＩＰアドレスをそのまま使用でき、Ｔ１以後からＴ２以前の間に更新を試みるべきであり、Ｔ２が過ぎれば該アドレスを使用しないことを勧めている。ＯＬＴよりも非常に短い例えば６０秒のＰＬＴを使用する場合、宅内ＤＧＩＰホストは３０秒が過ぎれば、継続更新リクエストを送る。６０分のＯＬＴで６秒のＰＬＴを使用すれば、殆ど１００番近いリクエストが元ＤＨＣＰサーバに転送される。サーバの立場から見れば、これは相当な電算処理の負荷になり得る。

従って、本発明によるＤＨＣＰプロキシサーバは、このような問題を解決するためにＣＥＴ機能を具備している。ＣＥＴは、ＯＬＴの一定時点までは宅内ホストがＤＨＣＰサーバに送る更新リクエストを自体処理し、一定時点以後には直接更新を試みる機能である。ＣＥＴをＯＬＴの１／２で設定し得る事が望ましい。この場合、宅内ホストは非常に短いＰＬＴで設定されていても、本来のＴ１（Ｏｒｉｇｉｎａｌ Ｔ１）が過ぎて直ぐリースタイムを更新するため、結局、元ＤＨＣＰサーバに対する負荷は宅内ホストにコンフィギュレーションされているリースタイムがＯＬＴの場合と同量の負荷になる。即ち、非常に短いＰＬＴによる利点はそのまま全て取ながら、元ＤＨＣＰサーバに対する負荷はリースタイムが本来のＯＬＴで設定された場合に発生する負荷の量で限定させることが出来る。

更に、本発明によるＤＨＣＰプロキシサーバのフローに対する論議に戻り、宅内ＤＧＩＰホストのリクエストに対して、ＣＥＴ以前であれば、ＤＨＣＰプロキシサーバは直接応答する（１１１５）。ＣＥＴ以前でなければ、プロセシングはＡ´につながる。この時、後者の場合、当初ＣＥＴが存在しない状況即ち更新のためのＤＨＣＰリクエストでなく、アドレスを初めて受けるためのリクエストの場合も含まれる。

Ａ’はＤＨＣＰプロキシサーバの設定がブロードキャストモードかユニキャストモードかによりその流れが変わる（１１１６）。ブロードキャストモードとは、宅内ＤＧＩＰホストのブロードキャストメッセージを、ＢＲＧのＤＨＣＰプロキシサーバがエッジＬＡＮインターフェースに送る時にブロードキャストに送ることを意味する。ユニキャストモードとは、宅内ＤＧＩＰクライアントのブロードキャストメッセージを、ＢＲＧのＤＨＣＰプロキシサーバがエッジＬＡＮインターフェースに送る時にユニキャストに送ることを意味するが、これはＢＲＧのＤＨＣＰプロキシサーバが元ＤＨＣＰサーバのＩＰを知っていることを意味する。ＢＲＧの設定が面倒でないという点から、望ましくはブロードキャストモードが効果的である。しかし、１つのアパートＬＡＮに多数のＩＳＰがサービスを提供しているため、各家庭に従ってサービスを受けるＩＳＰが違う場合にはユニキャストが適合である。

ブロードキャストモードの場合、ＤＨＣＰサーバは出ていくパケットにおいて、ブロードキャストＭＡＣ（０ｘｆｆｆｆｆｆｆｆｆｆｆｆ）を目的地ＭＡＣ（ＯｕｔＰａｃｋｅｔ．ｄｅｓＭＡＣ）と使用し、ブロードキャストＩＰを目的地ＩＰ（ＯｕｔＰａｃｋｅｔ．ｄｅｓＩＰ）と使用する１１１８。ところが、この時、本発明によるＤＨＣＰプロキシサーバにはどんな種類のブロードキャストＩＰを使用するかを設定出来る。エッジＬＡＮセグメント内にＤＨＣＰプロキシサーバがある時には２５５．２５５．２５５．２５５を使用出来るが、ＮＡＴボックスのリレーを使用する時には該エッジのＬＩＰブロックの真のサブネットのブロードキャストＩＰ（例えば１９２．１６８．２５５．２５５）を使用する方がより効果的な通信が為される場合が多い。

一方、ユニキャストモードの場合、ＤＨＣＰプロキシサーバは元ＤＨＣＰサーバアドレスが確保されているかを確認する（１１１７）。確保されていなければ、ブロードキャストの場合と同様である（１１１８）。確保されていれば、ＤＨＣＰプロキシサーバは出ていくパケットにおいて、元ＤＨＣＰサーバのＩＰを目的地ＩＰと使用する（１１１９）。

ブロードキャストモード及びユニキャストモードの各々に対して互いに異なる方式にてパケットの目的地アドレス部分を作った後、本発明によるＤＨＣＰプロキシサーバはパケットの発信地部分を作る。ＢＲＧのＤＬＡＴ機能により、ソース（発信地）ＭＡＣはＢＲＧのＭＡＣで作る（１１２０）。その後、ＢＲＧはエッジＬＡＮインターフェースを通じてパケットを転送する（１１２１）。

一方、ＤＨＣＰメッセージがＢＲＧのエッジＬＡＮインターフェースで受信された場合、本発明によるＤＨＣＰプロキシサーバは、ＤＨＣＰメッセージペイロード内で言及されるＭＡＣアドレス（ＤＨＣＰ．ｃｈａｄｄｒ）がＰＨＩＭＴに含まれているかを確認する（１１２２）。含まれていなければ応答しない１１０４。ＰＨＩＭＴに含まれていれば、ＤＨＣＰプロキシサーバはメッセージがＢＯＯＴＰ応答かを確認する（１１２３）。ＢＯＯＴＰ応答でなければ応答しない（１１２４）。ＢＯＯＴＰ応答の場合、ＤＨＣＰプロキシサーバはメッセージがＤＨＣＰ承認メッセージかを確認する（１１２５）。

承認メッセージでなければ、承認不可メッセージ又はオファーメッセージである。本発明によるＤＨＣＰプロキシサーバは、メッセージ内のＤＨＣＰサーバアドレス（ＳｅｖｅｒＩＤ）フィールドを元ＤＨＣＰサーバではないＢＲＧのＩＰアドレスに変更し（１１２９）、パケットのソースＭＡＣをＢＲＧのものに変更し、パケットのソースＩＰをＢＲＧのＩＰに変更後（１１３０）、宅内ＬＡＮインターフェースを通じてパケットを転送する（１１３１）。

反面、承認メッセージであれば、メッセージ内のデータを流動公認割当テーブルに記録し、元ＤＨＣＰサーバ情報を前記テーブルに格納し（１１２６）、既定の値（例えば６０秒）によってＣＥＴ値を設定して前記テーブルに格納する（１１２７）。また、承認メッセージ内のサブネットマスク値をスーパー−サーバネットマスク値に変更する（１１２８）。また、必要に応じて選択的にデフォルトゲートウェイ或いはＤＮＳサーバアドレス値などを追加で変更することが出来る（１１２８）。そして、メッセージ内のＤＨＣＰサーバアドレス（ＳｅｒｖｅｒＩＤ）フィールドを元ＤＨＣＰサーバではないＢＲＧのＩＰアドレスに変更し（１１２９）、パケットのソースＭＡＣをＢＲＧのものに変更し、パケットのソースＩＰをＢＲＧのＩＰに変更後（１１３０）、宅内ＬＡＮインターフェースを通じてパケットを転送する（１１３１）。

図１２ａ〜図１２ｄは流動ＧＩＰホストのＩＰコンフィギュレーションからＩＰアドレスリリースまでのシークエンスチャートである。ＮＡＴボックスは図８で例示したように、エッジ共用で使用され、本発明によるＤＨＣＰ補助リレーを持つ。元ＤＨＣＰサーバは遠隔に存在するものと想定している。

ＤＧＩＰを使用する宅内ホストがブーティングされる（１２０１）。ホストはＩＰコンフィギュレーションを受けるためにディスカバーメッセージをブロードキャストする（１２０２）。このブロードキャストメッセージを受信することを基点としてＢＲＧのＤＨＣＰ処理セッションが初期化される（１２０３）。ＢＲＧは受信されたディスカバーメッセージを図１１ｃの段階１１１７〜１１２０と同じ方法にて処理して、エッジＬＡＮインターフェースを通じてＮＡＴボックスに転送する（１２０４）。ＮＡＴボックスはローカルインターフェース８６２を通じてこのブロードキャストメッセージを受信する。ＮＡＴボックスに内蔵されている、本発明によるＤＨＣＰ補助リレーモジュールは、メッセージ内のリレーアドレスフィールド（ｇｉａｄｄｒ）にＮＡＴのＧＩＰアドレスを入れる（１２０５）。補助リレーはＧＩＰインターフェース８６１を通じてパケットを遠隔の元ＤＨＣＰサーバに送る（１２０６）。元ＤＨＣＰサーバはＩＰアドレスを“オファー”状態でマーキングする（１２０７）。元ＤＨＣＰサーバはオファーメッセージを、本発明による補助リレーを内蔵したＮＡＴのＧＩＰインターフェース８６１に送り、補助リレーはこれをＬＩＰインターフェース８６２を通じてＢＲＧに送る（１２０８）。注目すべき点は、この時、一般のリレーとは異なり、本発明による補助リレーではＮＡＴが為されるということ、一般のリレーは、遠隔サーバから送ったＤＨＣＰメッセージをエッジ網内にリレーする時、メッセージ内に含まれているＭＡＣアドレス（ＤＨＣＰ．ｃｈａｄｄｒ）を使用してパケット目的地を表示することにより、データリンクユニキャストを行うのに対して、本発明による補助リレーは、パケット目的地と関連して、データリンクブロードキャスト（アドレスは０ｘｆｆｆｆｆｆｆｆｆｆｆｆ）を使用したり、又は該ＢＲＧのＭＡＣを使用するという事である。

オファーメッセージを受けたＢＲＧは、オファーメッセージ内容と関連して、補助リレーが存在しないようにｇｉａｄｄｒフィールド値を０に変更し、元ＤＨＣＰサーバの代りにＢＲＧをＤＨＣＰサーバだと主張する内容でメッセージを変更する１２０９。ＢＲＧは変更されたオファーをホストに提供する（１２１０）。ホストはＩＰアドレスＡを使用するという意思、即ちリクエストをブロードキャストする（１２１１）。ＢＲＧはこのリクエストブロードキャストメッセージを受けた後、メッセージ内容のうち、ＢＲＧになっているサーバを元ＤＨＣＰサーバに還元して１２１２エッジＬＡＮセグメントに送る（１２１３）。ＢＲＧから送ったリクエストメッセージを私設インターフェースを通じて受信したＮＡＴの補助リレーは、ｇｉａｄｄｒフィールドにＮＡＴの公認ＩＰ値を入れ、公認インターフェースを通じて遠隔の元ＤＨＣＰサーバに送る（１２１４）。

元ＤＨＣＰサーバは、オファーしたＩＰアドレスＡをクライアントに割り当て（１２１５）、リスタイマーを作動後（１２１６）、例えば３，６００秒（１時間）のＯＬＴを付与して、承認メッセージをＮＡＴのリレーに送る（１２１７）。ＧＩＰインターフェースを通じて承認メッセージを受信した補助リレーは、これをＬＩＰインターフェースを通じてＢＲＧに送る。

ＢＲＧに内蔵されている本発明によるＤＨＣＰプロキシサーバは、図１１ｄの段階１１２６〜１１３０と同一の作業を行う。そのうち、代表的な作業は、ＣＥＴタイマーを作動させ（１２１８）、サブネットマスクを変調し、リースタイムをＰＬＴに変更し（１２１９）、ＤＨＣＰサーバをＢＲＧ自体で現れるようにし、リレーの存在を隠す（１２２０）。このような作業後、変調された承認メッセージをクライアントに提供する（１２２１）。この時、ＯＬＴは３，６００秒、ＰＬＴは６０秒、ＣＥＴはＯＬＴの半分で定義されて１，８００秒になる。もう宅内ホストはＩＰアドレスＡを使用することになり、ＰＬＴが６０秒なので、ＤＨＣＰ標準勧告によって３０秒をＴ１で設定することになった（１２２２）。宅内ホストがＩＰアドレスＡを使用している状態を“バウンド”という。

ＰＬＴが６０秒なので、ホストのＴ１は３０秒になり、ホストはＴ１が過ぎれば直ぐ更新リクエストをする。この更新リクエストがＣＥＴ満了以前に為される場合（１２２４、１２２５）、本発明によるＤＨＣＰプロキシサーバは、前記更新リクエストに対して直接承認メッセージとして応答する（１２２６）。

承認応答を受けたホストは、その瞬間から更に６０秒のＰＬＴを持つ（１２２７）。このような過程を繰り返す間にＣＥＴが満了することになる（１２２８）。

ＣＥＴ満了以後にクライアントの更新リクエストが行われれば（１２２９、１２３０）、ＢＲＧはこの更新リクエストメッセージのＤＨＣＰサーバ部分を更に元ＤＨＣＰサーバアドレスに変更し（１２３１）、図１１ｃの段階１１１６〜１１２０と同じ過程によりエッジＬＡＮセグメントに送る（１２３２）。ＮＡＴに内蔵されているＤＨＣＰ補助リレーは、このメッセージを遠隔の元ＤＨＣＰサーバに送る（１２３３）。遠隔の元ＤＨＣＰサーバはＩＰアドレスＡを更新して割り当て、リスタイマーを再作動させる（１２３４、１２３５）。そして、元ＤＨＣＰサーバは承認メッセージを送る（１２３６）。よって、更に更新されたリースタイムを開始し、本発明によるＤＨＣＰプロキシサーバは、更新されたＯＬＴ及びＣＥＴを適用する１２３７。

ホストがシャットダウンされながら（１２３８）、ホストはリリースメッセージを送る（１２３９）。ＢＲＧは、メッセージ内容のうち、ＤＨＣＰサーバを遠隔の元ＤＨＣＰサーバに還元させて（１２４０）、ＤＨＣＰセッションを掃除した後（１２４１）、リリースメッセージを補助リレーに送る（１２４２）。補助リレーはこのメッセージを外部の元ＤＨＣＰサーバに送る（１２４３）。このメッセージを受けた遠隔の元ＤＨＣＰサーバはＩＰアドレスＡをバウンド状態から解除する（１２４４）。

本発明によるＢＲＧは、ＤＨＣＰプロキシサーバとサブネット−認知型ＡＲＰプロキシサーバを備えるだけでなく、次のような重要な機能を備える。

第１に、ＤＬＡＴ機能により、エッジＬＡＮのホスト数が大きく増加してもエッジＬＡＮの性能は低下しない。ＤＬＡＴ機能とは、ＢＲＧを経て宅内ＬＡＮセグメントの外に出るパケットにおいて、ソースのＭＡＣアドレスを該ホストのＭＡＣアドレスの代りにＢＲＧのＭＡＣアドレスに変換することを言う。反対に、宅内ＬＡＮセグメントの外部から宅内ＬＡＮセグメントのホストにパケットが転送される場合、パケットの目的地のＭＡＣアドレスがＢＲＧのＭＡＣアドレスになり、ＢＲＧのＤＬＡＴ機能により受信されたパケットの目的地ＭＡＣアドレスを更にホストのＭＡＣアドレスに変更後、該ホストにパケットが伝達される。

第２に、イーサーネットフレームの目的地ＭＡＣとソースＭＡＣを比べてパケットをフィルターリング出来る。特に、この機能はＬＩＰ接続に関して、多様な種類の接続サービスを定義し管理出来るようにする。

図１３はＢＲＧのデータリンクレイヤフィルターリング機能を用いたパケット経路区分及びそれに基づいたＬＩＰホストの接続サービス管理法案を示す。

議論の便宜上、例えば、ＩＳＰがＬＩＰを用いた接続サービス種類を４種類で設定する。“宅内だけ”は宅内の機器間にはＩＰ通信が自由であるが、外部には連結していないＬＩＰ接続サービスであり、“電力メートル”は遠隔の電力会社システム１３８１のみと通信出来るＬＩＰ接続サービスであり、“遠隔ホーム制御”は遠隔のホーム制御サイト１３８２のみと通信出来るＬＩＰ接続サービスであり、“ＮＡＴ方式インターネット”はＮＡＴを用いた一般のインターネット通信が可能なＬＩＰ接続サービスであると定義する。

一方、ＮＡＴボックスのローカルインターフェースには３個の別途のインターフェース１３６２、１３６３、１３６４が存在し、インターフェースごとに互いに異なるＭＡＣアドレス及びＬＩＰアドレスを持つ。そのうち、インターフェース１３６２は遠隔の電力会社システム１３８１と通信のためのＮＡＴインターフェースであり、インターフェース１３６３は遠隔ホーム制御サイト１３８２と通信のためのＮＡＴインターフェースであり、インターフェース１３６４は“ＮＡＴ方式インターネット”サービスのためのＮＡＴインターフェースである。そして、このＮＡＴボックスにはネットワーク階層においてパケットフィルターリング機能が存在する。

一方、宅内ＬＩＰホストのうち、参照番号“１３７１２１”は電力メートル器であり、“１３７１２２”は遠隔制御を受けるインターネット家電であり、“１３７１２ｎ”は“ＮＡＴ方式インターネット”接続サービスを使用出来るＰＣとする。

本発明によるＢＲＧはパケットのデータリンクレイヤでソース−デスティネーション（目的地）間のフィルターリングを行う。即ち、ＮＡＴ方式インターネットをするＰＣ１３７１２ｎが、電力メートルゲートウェイ１３６２を経由したり、遠隔ホーム制御サイトゲートウェイ１３６３を経由したりしようとすれば、これは直ぐ遮断される。また、電力メートル器のＩＰアドレス及びＭＡＣアドレスを“宅内だけ”になっているＰＣに付与した後、インターフェース１３６４を経由してＮＡＴ方式インターネットを試みようとしても直ぐ遮断される。また、電力メートル器のＩＰアドレス及びＭＡＣアドレスを“宅内だけ”になっているＰＣに付与した後、インターフェース１３６２を経由してＮＡＴ方式インターネットを試みようとしても、これはＮＡＴボックスのフィルターリングにより直ぐ遮断される。ＮＡＴボックスに関して言及すれば、“インターフェース１３６２で出入りする全てのパケットは、必ず遠隔ホスト１３８１から来るものか、或いは遠隔ホスト１３８１に行くものであるべきである”というネットワーク階層フィルターリング規則を持つ。

即ち、ＢＲＧはデータリンクレイヤで強力なフィルターリング機能を行うため、ＮＡＴボックスのネットワーク階層フィルターリング作業が単純かつ效果的になった。その結果、ＩＳＰはＬＩＰを用いた接続サービスに関して非常に多様な接続サービス商品を定義し、これを管理出来ることになった。よって、各々の接続サービス商品に対して最適な価格を提示出来る。

本発明の実施例４は、アパートＬＡＮだけでなく、電話線を用いたＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）セグメントやケーブル放送のケーブルを用いたＣＭＴＳ（Ｃａｂｌｅ Ｍｏｄｅｍ Ｔｅｒｍｉｎａｔｉｏｎ Ｓｙｓｔｅｍ）セグメントにも適用出来る。

図１４はＣＭＴＳセグメントに対する本発明による実施例２の適用例を示す。ケーブル通信社の通信及び送出装備が存在する場所をＮＨＥ（Ｎｅｔｗｏｒｋ Ｈｅａｄ Ｅｎｄ）という。ＮＨＥはエッジルータ１４１２があり、エッジＬＡＮセグメント１４１３があり、ＣＭＴＳ１４１４０、１４１５０がある。ＣＭＴＳは光ケーブルで加入者の隣接のＯＮＵ（Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）１４２１まで連結し、更に太い同軸ケーブル１４２２がＯＮＵから道路に沿って延設されている。太い同軸ケーブルから薄い同軸枝線１４２２１、１４２２２、１４２２３、１４２２４が分離されて加入者の宅に引入される。放送波とデータを合成するコンバイナがＮＨＥ宅内又はＣＭＴＳとＯＮＵとの間の区間に存在するが、議論の便宜上、コンバイナの表示は省略した。

宅に引入された同軸ケーブルはケーブルモデム（ＣＭ）１４３１、１４３２、１４３３、１４３４に接続される。ケーブルモデムは、一方では更にＢＮＣケーブルによりテレビに連結し（省略する）、もう一方ではＬＡＮ線によって本発明によるＢＲＧ１４４１、１４４２、１４４３、１４４４に連結する。ＢＲＧは宅内ＬＡＮセグメント１４５１に更に連結し、宅内ＬＡＮセグメントにはＤＧＩＰホスト１４６１とＬＩＰホスト１４７１、１４７２が連結する。

エッジルータ１４１２からＢＲＧまでの区間がケーブルという点が異なるだけで、基本的にはアパートＬＡＮセグメントと非常に類似な構造を示す。ＤＧＩＰホストはアパートＬＡＮセグメントと同様にエッジルータ１４１２をデフォルトゲートウェイとしてインターネットに連結し、ＬＩＰホストもアパートＬＡＮと同様にＮＡＴ１４１６０の私設インターフェース１４１６１をデフォルトゲートウェイとしてインターネットに連結する。

注意点の１つは、一般的に、ＣＭＴＳは自身を通過するパケットに対して、アップストリームパケットはそのソースアドレスを検査し、ダウンストリームパケットはその目的地アドレスを検査する。これにより、ＣＭＴＳは誤ったＩＰアドレスの使用を防止する知能的な機能を持つということである。従って、ＣＭＴＳの設定時、該ＣＭＴＳで使用される私設ＩＰブロックに該当するパケットを許容するように設定する作業が必要である。

図１５はｘＤＳＬセグメントに本発明の実施例２を適用した状態を示す。ｘＤＳＬは電話線を用いたＤｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ通信方式の通称である。代表的としては、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）方式ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＩＰ方式ＡＤＳＬ、及びＶＤＳＬ（Ｖｅｒｙ Ｈｉｇｈ Ｓｐｅｅｄ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ） などがある。図１５はＩＰ方式ＡＤＳＬとＶＤＳＬの何れも該当する。ＡＴＭ方式ＡＤＳＬの場合、エッジルータとＤＳＬＡＭ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）との間にＮＡＳ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）が追加され、ＮＡＳからＤＳＬＡＭを経てモデムに至る区間はＡＴＭ方式の通信が為される。最近、ＡＴＭ、ＤＳＬＡＭは急速に退潮しつつあり、ＡＴＭで使用されるＰＶＣ（Ｐｅｒｍａｎｅｎｔ Ｖｉｒｔｕａｌ Ｃｉｒｃｕｉｔ）を適切に設定すれば、本発明を適用出来る環境になるため、特に示さなかった。

ＩＳＰの終端部通信装備の設置場所をＰＯＰ（Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ）と称する。ＰＯＰにはエッジルータ１５１２があり、エッジＬＡＮセグメント１５１３がある。また、ＤＳＬＡＭ１５１４、１５１５が存在し、本発明と関連したＮＡＴボックス１５１６０が存在する。ＤＳＬＡＭ１５１４、１５１５から加入者の宅内のモデムまでは電話線１５２１、１５２２、１５２３、１５２４が延設されている。ＰＯＰ内にＤＳＬＡＭ側にはＤＳＬＡＭから分離された音声信号を処理する電話交換機（主に電気電子交換機）が存在し、加入者の宅内モデム側には電話器が存在するが、議論の便宜上、図示しなかった。

モデム１５３１、１５３２、１５３３、１５３４ではＬＡＮケーブルを通じて本発明によるＢＲＧ１５５１、１５５２、１５５３、１５５４が連結しており、ＢＲＧには宅内ＬＡＮ１５６１が連結している。宅内ＬＡＮにはＤＧＩＰホスト１５７１とＬＩＰホスト１５８１が連結している。

注目すべき点の１つは、本発明によるＢＲＧが連結しているモデムは“接続機能内蔵型”モデムだということである。ＡＤＳＬモデムには様々な類型があるが、大別すれば、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）接続機能をホスト側に置くことを要求するモデムと、その機能がモデム自体に内蔵されたモデムとがある。

宅内ＤＧＩＰホストはエッジルータをデフォルトゲートウェイとしてインターネットに連結し、宅内ＬＩＰホストはＮＡＴボックスの私設インターフェース１５１６２をデフォルトゲートウェイとしてインターネットに連結する。

以上から分かるように、本発明の実施例２のＢＲＧは、アパートＬＡＮ、ＣＭＴＳセグメント、ＤＳＬセグメントの何れも広範囲に適用出来る。

単一のＬＡＮセグメントに存在する複数サブネットエッジ網を示すブロックダイアグラムである。 ＩＰパケットとサブネットマスクの構成原理を示すブロックダイアグラムである。 ＩＰホストがサブネットマスクを用いたテストを実行して目的地に対する接近方式を異にし、同じサブネットに位置したホストに対してはＡＲＰリクエストを使用することを示すフローチャートである。 本発明によるＤＨＣＰプロキシサーバのＩＰコンフィギュレーション情報の変調過程を示すフローチャートである。 本発明によるサブネット−認知型ＡＲＰプロキシサーバのフローチャートである。 本発明によるサブネット−認知型ＡＲＰプロキシサーバのシークエンスチャートである。 本発明の実施例１として、単一ＬＡＮセグメントに存在する、単一顧客の複数サブネットエッジ網のブロックダイアグラムである。 本発明の実施例２として、単一ＬＡＮセグメントに存在する、複数顧客の複数サブネットエッジ網のブロックダイアグラムである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＧＩＰホストから発生したＤＨＣＰメッセージ処理作業を要約したテーブルである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＬＩＰホストから発生したＤＨＣＰメッセージ処理作業を要約したテーブルである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理フローチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理フローチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理フローチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理フローチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理シークエンスチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理シークエンスチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理シークエンスチャートである。 図８のＢＲＧに内蔵されたＤＨＣＰプロキシサーバのＤＨＣＰメッセージ処理シークエンスチャートである。 図８のＢＲＧに付与されたデータリンクレイヤパケットフィルターリング機能を説明するためのブロックダイアグラムである。 本発明の実施例３として、本発明の実施例２をケーブル通信網環境に適用した例を示すブロックダイアグラムである。 本発明の実施例４として、本発明の実施例２をｘＤＳＬ通信網環境に適用した例を示すブロックダイアグラムである。

Claims (25)

1. エッジルータ、ＮＡＴボックス及び複数のＬＩＰホストと複数のＤＧＩＰホストからなる複数の宅内ホストで構成されている単一のエッジＬＡＮセグメントからなる複数のサブネットエッジ網において、ｉ）前記単一のエッジＬＡＮセグメント内に設置され、ｉｉ）前記複数の宅内ＤＧＩＰホストとＬＩＰホストが互いに同じサブネットを持ったと勘違いするように、前記複数の宅内ＤＧＩＰホストとＬＩＰホストのサブネットマスクを偽造して、非現実的かつ非正常的に大きいサブネットマスク（スーパーマスク）に変調するＤＨＣＰプロキシサーバを含む、エッジ内ルーティングのない宅内（Ｐｒｅｍｉｓｅｓ）ＩＰ通信装置。
2. 前記ＤＨＣＰプロキシサーバが、
   複数の宅内クライアントホストのＭＡＣアドレスを基準として、ネットワーク管理者のＩＰアドレス割当政策によって設定された、各宅内クライアントホストに割り当てられるＩＰ接続サービス種類、ＩＰアドレスタイプ及びＩＰアドレス値が記録されたテーブル、
   前記宅内クライアントホストの少なくとも１つで発生した前記ＤＨＣＰメッセージを受信後、前記テーブルを参照して前記ＤＨＣＰメッセージを発生したクライアントホストのＩＰアドレスタイプを判断する手段と、
   前記クライアントスホストがＬＩＰホストの場合、前記ネットワーク管理者のＩＰアドレス割当政策により、自体管理するＬＩＰ資源から所定のＬＩＰアドレスを選択して前記クライアントホストに割り当てる手段と、
   前記クライアントホストがＧＩＰホストの場合、ＤＨＣＰメッセージ（Ｄｉｓｃｏｖｅｒ及びＲｅｑｕｅｓｔ）を前記元ＤＨＣＰサーバに転送する手段と、
   前記ＤＨＣＰメッセージに応答して、前記元ＤＨＣＰサーバから受信したＤＨＣＰ承認メッセージ内に含まれたＩＰコンフィギュレーション情報中のサブネットマスクを前記サブネットマスクより大きいスーパーマスクに変調する手段と、
   前記スーパーマスクを含む変調されたＩＰコンフィギュレーション情報を利用して、クライアントホストのＩＰコンフィギュレーションを行う手段と
   を含む、請求項１に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
3. 前記ＤＨＣＰプロキシサーバが、前記元ＤＨＣＰサーバから提供された前記承認メッセージ中の前記元ＤＨＣＰサーバのＩＰアドレスから成るＩＤを、前記ＤＨＣＰプロキシサーバのＩＰアドレスに変える手段を含む、請求項２に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
4. 前記ＤＨＣＰプロキシサーバが、前記元ＤＨＣＰサーバで適用したＯＬＴ（Ｏｒｉｇｉｎａｌ Ｌｅａｓｅ Ｔｉｍｅ）を短縮して、前記ＤＨＣＰプロキシサーバで適用されるＰＬＴ（Ｐｒｅｍｉｓｅｓ Ｌｅａｓｅ Ｔｉｍｅ）を設定する手段を含む、請求項３に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
5. 前記ＤＨＣＰプロキシサーバが、一定期間の間、前記クライアントホストの更新リクエストを前記元ＤＨＣＰサーバに伝達せず、前記ＤＨＣＰプロキシサーバが前記元ＤＨＣＰサーバの代わりに自体応答するようにする時間であるＣＥＴ（Ｃａｃｈｉｎｇ Ｅｘｐｉｒａｔｉｏｎ Ｔｉｍｅ）値を設定し、動作させる手段を含む、請求項４に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
6. 前記ＣＥＴが前記ＯＬＴの約半分に該当する、請求項５に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
7. 前記複数のＤＧＩＰホストと前記ＬＩＰホストを各々前記エッジルータ及び前記ＮＡＴボックスに連結させるゲートウェイ装置を更に含み、前記ＤＨＣＰプロキシサーバが前記ゲートウェイ装置に内蔵される、請求項１乃至６の何れか１つに記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
8. 前記ゲートウェイ装置がホームゲートウェイである、請求項７に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
9. 単一のエッジＬＡＮセグメント内において、前記ゲートウェイ装置が複数個として各々ＬＡＮセグメントを自体構成する、請求項７に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
10. 前記複数のゲートウェイ装置にはＬＩＰアドレスが割り当てられており、前記ＮＡＴボックスは複数のゲートウェイ装置と通信するためのＬＩＰインターフェース及び前記ＤＨＣＰサーバと通信するためのＧＩＰインターフェースを持ち、前記ＮＡＴボックスのＬＩＰインターフェース及びＧＩＰインターフェースを通じて、前記ＤＨＣＰメッセージを前記ゲートウェイ装置と前記元ＤＨＣＰサーバとの間で伝達させるためのＤＨＣＰ補助リレーモジュールを含む、請求項９に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
11. 前記複数のゲートウェイ装置の各々が、アップストリームパケットのソースＭＡＣアドレスを前記ゲートウェイ装置のＭＡＣアドレスに変換し、ダウンストリームパケットの目的地ＭＡＣアドレスを目的地宅内ホストのＭＡＣアドレスに変換するＤＬＡＴ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）モジュールを含む条件において、前記ＤＨＣＰメッセージを前記ＤＨＣＰサーバから前記複数のゲートウェイに伝達する時、前記ＮＡＴボックスは、ダウンストリームＤＨＣＰパケットのデータリンクレイヤ目的地アドレスとして、ブロードキャストアドレス又は前記ゲートウェイ装置のＭＡＣアドレスを使用するようにする手段を含む、請求項１０に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
12. ＤＧＩＰホスト及びＬＩＰホストからなる複数のクライアントホストの真のサブネットを認知し、また、前記複数のクライアントホストのデフォルトゲートウェイのＭＡＣアドレスを認知して、前記ＤＨＣＰプロキシサーバを通じてコンフィギュレーションしたスーパーマスクによって同じサブネットに属したものと認識される遠隔ホストに対する、前記複数のクライアントホストのＡＲＰリクエストブロードキャストのとき、前記複数のクライアントホストの１つに対応するデフォルトゲートウェイのＭＡＣアドレスを提供するように、前記サブネットにより決定された真のサブネットを回復させるサブネット−認知型ＡＲＰプロキシサーバを更に含む、請求項１乃至６の何れか１つに記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
13. 前記サブネット−認知型ＡＲＰプロキシサーバは、前記元ＤＨＣＰサーバから提供された複数のクライアントホストの真のサブネットマスクを認知する手段と、
    前記複数のクライアントホストの各々のデフォルトゲートウェイのＭＡＣアドレスを認知する手段と、
    前記スーパーマスクにより同じサブネットに属するものと勘違いする遠隔ホストに対して発送される、前記クライアントホストの間違ったＡＲＰリクエストブロードキャストが発生することを認知する手段と、
    前記間違ったＡＲＰリクエストブロードキャスト発生時、前記間違ったＡＲＰリクエストブロードキャストに応答して、前記クライアントホストのデフォルトゲートウェイのＭＡＣアドレスを前記クライアントホストに送信する手段と
    を含む、請求項１２に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
14. 前記ＤＧＩＰホストと前記ＬＩＰホストを前記エッジルータ及び前記ＮＡＴボックスに連結させるゲートウェイ装置を更に含み、前記サブネット−認知型ＡＲＰプロキシサーバが前記ゲートウェイ装置に内蔵されている、請求項１３に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
15. 前記ＧＩＰホストと前記ＬＩＰホストを前記エッジルータ及び前記ＮＡＴボックスに連結させるゲートウェイ装置を更に含み、前記サブネット−認知型ＡＲＰプロキシサーバ及び前記ＤＨＣＰプロキシサーバが前記ゲートウェイ装置に内蔵されている、請求項１３に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
16. 前記ゲートウェイ装置がホームゲートウェイである、請求項１５に記載のエッジ内ルーティングのない宅内ＩＰ通信装置。
17. エッジルータ、ＮＡＴボックス及び複数のＬＩＰホストと複数のＤＧＩＰホストからなる複数の宅内ホストで構成されている単一のエッジＬＡＮセグメントからなる複数のサブネットエッジ網を用いた通信方法において、
    ａ）前記複数のクライアントホストの少なくとも１つがＤＨＣＰメッセージをブロードキャストし、ＤＨＣＰプロキシサーバが、前記クライアントホストがＬＩＰホストの場合、元ＤＨＣＰサーバから管理されたＬＩＰ資源から偽造したスーパーマスクを持つＬＩＰアドレスを利用して、前記複数のクライアントホストの少なくとも１つをコンフィギュレーションし、前記クライアントホストがＤＧＩＰホストの場合、ＤＨＣＰメッセージを前記元ＤＨＣＰサーバに転送する段階と、
    ｂ）前記ＤＨＣＰプロキシサーバが、前記元ＤＨＣＰサーバから前記ＤＨＣＰメッセージに対応する承認メッセージを受けて所定のテーブルに記録し、ここで、承認メッセージにはサブネットマスクを含むＩＰコンフィギュレーション情報が含まれ、前記サブネットマスクを前記サブネットマスクより小さい値を持つスーパーマスクに変更し、スーパーマスクを含む変調されたＩＰコンフィギュレーション情報を用いて前記クライアントホストをＩＰコンフィギュレーションする段階と
    ｃ）ＩＰコンフィギュレーションしたクライアントホストとターゲットホストとの間の通信を行う段階と
    を含む、通信方法。
18. 前記ａ）段階が、
    ａ−ｉ）前記ネックワーク管理者の設定によって決定され、前記ＤＨＣＰプロキシサーバに内蔵された、前記複数のクライアントホストのＭＡＣアドレスを基準として、該ホストが使用するＩＰ接続サービス種類、ＩＰアドレス種類及びＩＰアドレス値を含んだＩＰアドレス情報を記録したテーブルを参照して、ソースホストに付与可能なＩＰアドレス種類を判断する段階と、
    ａ−ｉｉ）前記クライアントホストのアドレス種類がＬＩＰの場合、前記ネットワーク管理者により割り当てられたＬＩＰ資源から偽造したスーパーマスクを持つ所定のＬＩＰアドレスを選択して前記クライアントホストに配分する段階と、
    ａ−ｉｉｉ）前記ソースホストのＩＰアドレス種類がＤＧＩＰの場合、前記ＤＨＣＰメッセージを前記元ＤＨＣＰサーバに転送する段階と
    を含む、請求項１７に記載の通信方法。
19. 前記ｂ）段階が、
    ｂ−ｉ）前記元ＤＨＣＰサーバでＯＬＴ（Ｏｒｉｇｉｎａｌ Ｌｅａｓｅ Ｔｉｍｅ）を設定し動作させる段階と、
    ｂ−ｉｉ）前記ＤＨＣＰプロキシサーバで前記元ＤＨＣＰサーバからＤＨＣＰ承認メッセージ（ＤＨＣＰＯＦＦＥＲ）を受けて、前記承認メッセージ内に含まれたＩＰコンフィギュレーション情報の前記サブネットマスクを前記サブネットマスクより大きい前記スーパーマスクに変更する段階と、
    ｂ−ｉｉｉ）前記ソースホストのＩＰアドレス種類がＤＧＩＰの場合、前記スーパーマスクを含む変調されたＩＰコンフィギュレーション情報を利用して、クライアントホストのＩＰコンフィギュレーションを行う段階と
    を含む、請求項１７または１８に記載の通信方法。
20. 前記ｂ−ｉｉ）とｂ−ｉｉｉ）の段階間に、前記承認メッセージ中の前記ＤＨＣＰサーバＩＤ即ちＩＰアドレスを、前記ＤＨＣＰプロキシサーバのＩＰアドレスに変える段階を更に行う、請求項１９に記載の通信方法。
21. 前記ｂ−ｉｉ）の段階において、前記ＤＨＣＰプロキシサーバで適用されるＯＬＴとして、前記ＯＬＴを短縮して形成されたＰＬＴ（Ｐｒｅｍｉｓｅｓ Ｌｅａｓｅ Ｔｉｍｅ）を設定する段階を更に含む、請求項１９に記載の通信方法。
22. 前記ｂ−ｉｉ）の段階において、前記ＤＨＣＰプロキシサーバが、一定期間の間、前記クライアントホストの更新リクエストを前記元ＤＨＣＰサーバに伝達せず、前記ＤＨＣＰプロキシサーバが前記元ＤＨＣＰサーバの代わりに自体応答するようにする時間であるＣＥＴ値を設定し、動作する段階を更に含む、請求項２１に記載の通信方法。
23. 前記ｃ）段階が、
    ｉ）ＩＰアドレスの付与されたソースホストが前記スーパーマスクによりカバーされるターゲット目的地への通信のためのＡＲＰリクエストをブロードキャストする段階と、
    ｉｉ）サブネット−認知型ＡＲＰプロキシサーバがサブネットマスク及びスーパーマスクにより決定されたサブネットを認知する状態で、前記サブネットマスクにより決定された前記ソースホストの真のサブネットに前記ターゲット目的地が属するかを判断する段階と、
    ｉｉｉ）目的地ＩＰアドレスがスーパーマスクによるソースホストのサブネットには属しても、サブネットマスクによるソースホストのサブネットには属しない場合、前記サブネット−認知型ＡＲＰプロキシサーバが前記ＡＲＰリクエストに対応して前記ソースホストのデフォルトゲートウェイのＭＡＣアドレスを前記ソースホストに通知する段階と、
    ｉｖ）前記ソースホストは、デフォルトゲートウェイのＭＡＣアドレス及び目的地ＩＰアドレスを含むパケットを作成して、前記デフォルトゲートウェイを通じて前記目的地と通信する段階と
    を含む、請求項１７乃至２１の何れか１つに記載の通信方法。
24. 前記ａ−ｉｉｉ）及びｂ−ｉｉ）の段階において、コンフィギュレーションした複数のゲートウェイと遠隔の前記元ＤＨＣＰサーバとの間で、前記ＤＨＣＰメッセージをＬＩＰホストに伝達する段階を更に含む、請求項１９に記載の通信方法。
25. 前記ａ−ｉｉｉ）及びｂ−ｉｉ）の段階において、前記複数のゲートウェイの各々がアップストリームパケットのデータリンクレイヤアドレスを自分のデータリンクレイヤアドレスに翻訳し、そして、ダウンストリームパケットのデータリンクレイヤアドレスを前記クライアントホストのデータリンクレイヤアドレスに翻訳する場合、前記補助ＤＨＣＰリレーモジュールを持つＮＡＴボックスが前記元ＤＨＣＰサーバからのダウンストリームＤＨＣＰパケットの目的地アドレスとしてデータリンクブロードキャストアドレス、または複数のゲートウェイのＭＡＣアドレスを使用する段階を更に含む、請求項２４に記載の通信方法。
    

Images