(57)【要約】  レジデンシャルゲートウェイ（１３０）は、アドレス又はポート変換を実行することなく、パブリックインターネットに対しインホームホスト（１４０）とインタフェースをとる。各インホームホストには、ゲートウェイのパブリックアドレスと任意的に１以上のポート（２２０）とが割り当てられる。インホームホストは、出力パケットのためのゲートウェイＩＰアドレスの下位レベルバージョンを生成する（Ｓ３７０）。ゲートウェイは、インターネットから入力されるパケットのパブリック・プライベートＩＰアドレス変換のためルックアップテーブル（７２０）を維持し、ＩＰアドレス（７３０）の対応する下位レベルを検出する。入出力したパケットは、アドレス又はポート変換が実行されることなくカプセル化される。
2008527829.tif 000002
【特許請求の範囲】
【請求項１】
第１ネットワークにおける１以上の装置のグループであって、
当該グループは、第１装置を有し、
当該グループは、情報を第２ネットワークにルーティングし、
前記第１及び第２ネットワークは、異なるアドレス領域であり、
当該グループは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスから下位レベルのアドレスを求め、前記第２ネットワーク内の第２装置をデスティネーションとして指定するパケットを生成するよう構成され、
当該グループはさらに、前記デスティネーションに基づき前記第１装置のための前記第２ネットワークのアドレスを決定し、前記決定したアドレスを前記パケットのソースとして提供し、
当該グループはまた、前記求めたアドレスを追加し、カプセル化されたパケットを形成するため前記パケットをカプセル化し、前記第２ネットワークへのルーティングのため前記カプセル化されたパケットをゲートウェイに転送するよう構成されるグループ。
【請求項２】
当該グループは、前記第１装置のみを有する、請求項１記載のグループ。
【請求項３】
当該グループは、前記第１装置に加えて、前記ゲートウェイから１ホップ離れた装置を含む、請求項１記載のグループ。
【請求項４】
前記第１装置は、前記生成、決定及び提供を実行し、
前記１ホップ離れた装置は、前記導出、追加、カプセル化、形成及び転送を実行する、請求項３記載のグループ。
【請求項５】
当該グループは、前記第１装置と、前記ゲートウェイから１ホップ離れた装置のみを含む、請求項４記載のグループ。
【請求項６】
前記第１ネットワークは、前記第１装置から前記ゲートウェイへの前記パケットが従うパスに沿って装置を有する、請求項３記載のグループ。
【請求項７】
請求項１記載のグループと前記ゲートウェイとを有するシステムであって、
前記ゲートウェイは、前記転送されたパケット内の何れかのアドレスについて前記転送されたパケットを変更することなく、前記生成されたパケットを抽出するためカプセル化を解除し、前記抽出されたパケットを前記デスティネーションに送信するよう構成されるシステム。
【請求項８】
前記生成されたパケット内の何れかのアドレスについて前記生成されたパケットを変更することなく、前記カプセル化を実行するようさらに構成される、請求項１記載のグループ。
【請求項９】
前記導出は、当該グループの装置によるリクエストに応答して、該装置が前記下位レベルアドレスを受信することを伴う、請求項１記載のグループ。
【請求項１０】
前記ＩＰアドレスは、前記ゲートウェイのための前記第１又は第２ネットワークのアドレスである、請求項１記載のグループ。
【請求項１１】
ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、前記ＩＰアドレスを前記第１装置に提供する、請求項１記載のグループ。
【請求項１２】
前記求められたアドレスは、物理アドレスである、請求項１記載のグループ。
【請求項１３】
前記第１ネットワークは、プライベートネットワークであり、
前記第２ネットワークは、パブリックネットワークである、請求項１記載のグループ。
【請求項１４】
前記第１ネットワーク内の第３装置をデスティネーションとして指定するパケットを生成するようさらに構成され、
前記第１装置はさらに、前記デスティネーションに基づき前記第１装置のための前記第１ネットワークのアドレスを決定し、前記第１ネットワークの決定されたアドレスを前記パケットのソースとして使用するようさらに構成される、請求項１記載のグループ。
【請求項１５】
前記決定されたアドレスに係るポートを前記生成されたパケットにおけるソースとして指定するようさらに構成される、請求項１記載のグループ。
【請求項１６】
ゲートウェイと任意的に第１ネットワークの１以上の装置とから構成されるゲートウェイグループであって、
当該グループは、第２ネットワークから、前記第１ネットワーク内の装置の位置を指定するパケットを受信し、該受信したパケット内の何れかのアドレスに関して前記受信したパケットを変更することなく、前記受信したパケットから前記位置に対応する前記第１ネットワークのアドレスを生成するよう構成され、
前記第１及び第２ネットワークは、異なるアドレス領域であり、
前記装置は、インターネットアドレスより下位レベルのアドレスを有し、
当該ゲートウェイグループは、前記変更なく、ａ）前記生成したアドレスから前記下位レベルアドレスを求め、ｂ）前記求めた下位レベルアドレスを追加し、カプセル化されたパケットを形成するため、前記受信したパケットをカプセル化し、ｃ）前記カプセル化したパケットを前記指定された位置に送信することを有する動作を実行するゲートウェイグループ。
【請求項１７】
前記受信したパケットによる指定は、前記受信したパケット内に含まれるポート番号に基づき、
前記ゲートウェイは、前記受信したパケットから前記ポート番号を読み取るようさらに構成され、
前記生成は、前記読み取ったポート番号に基づく、請求項１６記載のゲートウェイグループ。
【請求項１８】
第１ネットワーク上で通信用のパケットを準備する方法であって、
宛先アドレスが前記第１ネットワーク内にあるか決定するステップと、
前記アドレスが前記第１ネットワーク内にないと決定された場合、前記第１及び第２ネットワークを接続するゲートウェイによって使用される第２ネットワークからのアドレスの１つであるソースアドレスを前記パケットに提供するステップと、
前記アドレスが前記第１ネットワーク内にあると決定された場合、前記第１ネットワーク内のソースアドレスを前記パケットに提供するステップと、
を有する方法。
【請求項１９】
前記ゲートウェイ上のＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サーバのＤＨＣＰクライアントに前記ゲートウェイのための前記第２ネットワークのアドレスを割り当てるため、ＤＨＣＰオプションを規定するステップをさらに有し、
前記決定及び該決定に基づく実行は、前記クライアントにより実行される、請求項１８記載の方法。
【請求項２０】
前記オプションは、前記クライアントからのリクエストメッセージに応答して割り当てる、請求項１９記載の方法。
【請求項２１】
前記クライアントによって前記リクエストメッセージを前記ＤＨＣＰサーバに送信し、前記ＤＨＣＰサーバによって前記第２ネットワークのアドレスを前記クライアントに割り当てるステップをさらに有する、請求項２０記載の方法。
【請求項２２】
前記第２ネットワークの１以上のポートを、前記クライアントからの前記１以上のポートを要求するメッセージに応答して、前記クライアントに割り当てるＤＨＣＰオプションを規定するステップをさらに有する、請求項１９記載の方法。
【請求項２３】
更新を要求する前記クライアントからのメッセージに応答して、前記１以上のポートに対するリースを更新するＤＨＣＰオプションを規定するステップをさらに有する、請求項２２記載の方法。
【請求項２４】
前記更新を要求する前記クライアントからのメッセージに応答して、前記割り当てられたアドレスに対するリースを更新するＤＨＣＰオプションを規定するステップをさらに有する、請求項１９記載の方法。
【請求項２５】
第１ネットワーク上で通信用のパケットを準備する装置であって、
当該装置は、
宛先アドレスが前記第１ネットワーク内にあるか決定し、
前記アドレスが前記第１ネットワーク内にないと決定された場合、前記第１及び第２ネットワークを接続するゲートウェイによって使用される第２ネットワークからのアドレスの１つであるソースアドレスを前記パケットに提供し、
前記アドレスが前記第１ネットワーク内にあると決定された場合、前記第１ネットワーク内のソースアドレスを前記パケットに提供する、
よう構成される装置。
【請求項２６】
情報をルーティングする方法であって、
第１及び第２ネットワークが異なるアドレス領域となる前記第２ネットワークから、前記第１ネットワークにおいてインターネットアドレスより下位レベルのアドレスを有する装置の前記第１ネットワーク内の位置を指定するパケットを受信するステップと、
前記受信したパケット内の何れかのアドレスに関する前記受信したパケットを変更することなく、前記受信したパケットから前記位置に対応するアドレスを生成するステップと、
前記生成したアドレスから前記下位レベルアドレスを求めるステップと、
前記求めた下位レベルアドレスを追加し、カプセル化されたパケットを形成するため、前記受信したパケットをカプセル化するステップと、
前記カプセル化したパケットを前記指定した位置に送信するステップと、
を有する方法。
【請求項２７】
前記下位レベルアドレスは、物理アドレスである、請求項２６記載の方法。
【請求項２８】
第１及び第２ネットワークが異なるアドレス領域となる前記第１ネットワークから前記第２ネットワークに情報をルーティングする方法であって、
ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）から、下位レベルのアドレスを求めるステップと、
前記第１ネットワークの第１装置によって、前記第２ネットワーク内の第２装置とデスティネーションとして指定するパケットを生成するステップと、
前記生成したパケット内の何れかのアドレスに関して前記生成したパケットを変更することなく、前記求めたアドレスを追加し、カプセル化されたパケットを形成するため、前記生成したパケットをカプセル化するステップと、
前記カプセル化したパケットを前記第１ネットワークの他の装置に転送するステップと、
前記転送したパケット内の何れかのアドレスに関して前記転送したパケットを変更することなく、前記生成したパケットを抽出するため前記カプセル化を解除し、前記抽出されたパケットを前記デスティネーションに送信するステップと、
を有する方法。
【請求項２９】
前記送信するステップは、送信のため前記生成したパケットをまず再カプセル化するステップを有する、請求項２８記載の方法。
【請求項３０】
前記下位レベルのアドレスは、物理アドレスである、請求項２８記載の方法。
【請求項３１】
前記第１装置は、前記第１ネットワークの１以上の装置のグループに属し、
前記求めるステップは、前記グループの装置が該装置によるリクエストに応答して、前記下位レベルアドレスを受信することを伴う、請求項２８記載の方法。
【請求項３２】
前記ＩＰアドレスは、前記解除及び送信を実行するゲートウェイのための前記第１又は第２ネットワークのアドレスである、請求項２８記載の方法。
【請求項３３】
ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）によって、前記ＩＰアドレスを前記第１装置に提供するステップをさらに有する、請求項２８記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットアドレスの枯渇の回避に関し、より詳細には、パブリックインターネットからプライベートネットワークへのゲートウェイに対するネットワークアドレス変換負担の軽減に関する。
【背景技術】
【０００２】
単に２３２個の一意的なアドレスを提供するインターネットアドレスの３２ビットアドレススペースは、大変小さなものであるため、増大する装置をオンラインに収容することがまもなくできなくなる。
【０００３】
ネットワークアドレス変換（ＮＡＴ）は、３２ビットアドレススペースの寿命を拡大するため提案された技術である。図１を参照するに、ホームネットワークの家電機器全体など、いくつかの装置のサブネットワーク、すなわち“サブネット”１１０が、ルータ又は他のレジデンシャルゲートウェイ（ＲＧ）１３０によりインターネット１２０とインタフェースをとるかもしれない。インターネット１２０と通信するホスト装置１４０、すなわち“ホスト”は、典型的には、レジデンシャルゲートウェイ１３０に到達するのにホームネット１５０を有する他のホストに遭遇する。サブネット、すなわち“プライベートネットワーク”上の装置又は“ホスト”１４０は、インターネット１２０、すなわち“パブリックネットワーク”上のものと異なるフォーマットの各自のアドレスを有している。このため、プライベートネットワーク１１０は、パブリックネットワーク１２０と異なるアドレス領域となる。ＲＧ１３０は、プライベートネットワーク１１０からパブリックネットワーク１２０にパケットをルーティングするためＮＡＴを実行し、反対のトラフィックが実現される場合には、パブリックネットワークからプライベートネットワークへのパケットのルーティングのためＮＡＴが実行される。ＲＧ１３０は、サブネット１１０上の他のホスト１４０と通信するためのプライベートアドレスを有し、パブリックアドレス領域１２０のパブリック、すなわち“外部”ホストとインタフェースをとるためパブリックアドレスを有する。これらのパブリックアドレスは、外部通信を提供するためプライベートホストに割り当てられる。
【０００４】
ネットワークアドレスポート変換（ＮＡＰＴ）は、ＮＡＴのコンセプトを拡張するものである。パブリックアドレスは、サブネット１１０のプライベートホスト１４０により共有されているかもしれず、各ホストには１以上の各自のポート番号が割り当てられている。ＲＧ１３０には、アドレス及びポート変換の負荷が生ずる。
【０００５】
ＮＡＴ／ＮＡＴＰが、ソース装置とデスティネーション装置との間のパケット送信を変更しないことを推奨するインターネットのルーティング原理を妨げるという問題がある。他の問題のうち、これはレジデンシャルゲートウェイ上の過剰な計算をもたらし、ボトルネックを生じさせる。
【０００６】
さらに、アプリケーション固有のＡＬＧ（Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｙｅｒ  Ｇａｔｅｗａｙ）が、ＲＧ１３０をトラバースするため、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）などのプロトコルを可能にするため実現される必要がある。このようなプロトコルは、典型的には、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスとポート番号をメッセージヘッダでなくメッセージペイロードに埋め込む。このため、ＩＰアドレス及びポート番号は、ＮＡＴ／ＮＡＰＴを受けない。新たなアプリケーションプロトコルが発明され、使用されるとき、新規及び既存のＲＧ１３０は新たなＡＬＧを対応して収容するためアップグレードされる必要がある。これは実現可能であっても面倒なものである。
【０００７】
さらなる欠点として、ＮＡＴ／ＮＡＰＴの後方のインホームネットワークへのリモートアクセスは、静的なマッピングが予め手動により生成されていない場合には不可能である。このマッピングは、インホームホスト１４０のプライベートアドレス及びポートと、ＲＧ１３０のインホームホストのパブリックアドレス及びポートとの間のＮＡＴ／ＮＡＰＴ上の関連付けである。このような手動による設定はエラーを生じさせ、多数の家電機器（ＣＥ）１４０を有するインホームネットワークには適していない。
【０００８】
レジデンシャルゲートウェイの設計を簡単化し、それの処理負荷を低減する必要がある。さらに、アドレス及びポート変換は、よりフレキシブルなものとされるべきである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、従来技術による上記問題点を解決するものである。
【課題を解決するための手段】
【００１０】
本発明の一特徴では、第１ネットワークの１以上の装置のグループであって、第１装置を含むグループが、第２ネットワークに情報をルーティングするよう構成される。第１及び第２ネットワークは、異なるアドレス領域である。当該グループは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスから下位レベルのアドレスを求め、第２ネットワーク内の第２装置をデスティネーションとして指定するパケットを生成する。当該グループはまた、デスティネーションに基づき、第１装置のための第２ネットワークのアドレスを決定し、決定したアドレスをパケットにおいてソースとして提供する。当該グループは、求めたアドレスを追加するため、パケットをカプセル化する。カプセル化したパケットは、その後に、第２ネットワークへのルーティングのためゲートウェイに転送される。
【００１１】
本発明の他の特徴では、ゲートウェイは、第１及び第２ネットワークが異なるアドレス領域である第２ネットワークから、第１ネットワーク内の装置の位置を特定するパケットを受信する。当該装置は、インターネットアドレスより下位レベルのアドレスを有する。ゲートウェイは、受信したパケット内の何れかのアドレスに関して受信したパケットを変更することなく、受信したパケットから当該位置に対応する第１ネットワークのアドレスを生成する。ゲートウェイは、任意的には第１ネットワークの１以上の装置と共に、受信したパケットの上述した変更なく、ａ）生成したアドレスから下位レベルアドレスを求め、ｂ）求めた下位レベルアドレスを追加する受信したパケットをカプセル化し、ｃ）カプセル化したパケットを指定した位置に送信することを含む動作を実行する。
【００１２】
本発明のさらなる特徴では、第１ネットワーク上で通信用のパケットを準備する装置は、宛先アドレスが第１ネットワーク内にあるか決定する。当該アドレスが第１ネットワーク内にないと決定された場合、当該装置は、第１及び第２ネットワークを接続するゲートウェイによって使用される第２ネットワークからのアドレスの１つであるソースアドレスをパケットに提供する。他方、当該アドレスが第１ネットワーク内にあると決定された場合、当該装置は、第１ネットワーク内のソースアドレスをパケットに提供する。
【発明を実施するための最良の形態】
【００１３】
図２は、本発明によるパブリック領域１２０へのアクセスをＲＧ１３０の後方のホスト１４０に提供するのに使用されるプロトコルを例示的かつ非限定的に示す。
【００１４】
インホームホスト１４０がブートアップされると、それは通常はＤＨＣＰを利用して、ＲＧ１３０にあるＤＨＣＰサーバ２０４からそれのネットワークインタフェースのＩＰアドレスを取得する。インホームネットワーク１１０はプライベートネットワークであるため、ＤＨＣＰサーバ２０４は、インホームホスト又は“ＤＨＣＰクライアント”１４０にプライベートアドレス２０８（１９２．１６８．１．１１など）を割り当てる。この割当ては、ＤＨＣＰクライアント１４０によるＤＨＣＰサーバ２０４へのリクエストと、サーバによるリプライの結果として行われる。
【００１５】
本発明によると、ＤＨＣＰクライアント１４０にはさらに、パブリックアドレス２１２と任意的な１以上のポートとが割当て可能である。ＤＨＣＰは、ＤＨＣＰリクエスト及びリプライメッセージがユーザによりカスタマイズされるようにエンハンス可能な“ベンダー固有情報”と呼ばれるオプションを提供する。このオプションが実現された後、インホームホスト１４０は、ＲＧ１３０のいくつかのパブリックアドレスの１つであってもよいパブリックアドレス２１２を取得することが可能である。インホームホスト１４０はまた、パブリックアドレス２１２に係るある範囲のポートを取得することができる。
【００１６】
図２に示されるように、第１ＤＨＣＰリクエストメッセージ２１６とそれのリプライメッセージ２２０は、インホームホスト１４０がプライベートアドレスを取得するための“１”と番号付けされた従来の各自の第１コンポーネントを有する。“２”と番号付けされた第２コンポーネントは、オプションの一部として実現され、パブリックアドレスを介した通信を区別するため、ポート３０００〜３０１０とパブリックアドレス２１２とに関する。
【００１７】
インホームホスト１４０が特定のポート又はポート範囲を取得すると、それは以降の通信においてパブリックアドレスと共に当該ポートを利用することができる。
【００１８】
ＤＨＣＰにより割り当てられたプライベートアドレス２０８は、所定の更新可能な期間にリースされ、本発明により割り当てられたパブリックアドレスは、同様に更新可能なベースによりリースされてもよい。このプロセスは、図２のリクエストメッセージ２２４とリプライメッセージ２２８により示される。
【００１９】
アドレス（及びポート）設定に加えて、インホームホスト１４０はまた、典型的には、ＲＧの内部アドレス、ここでは“１９８．１６８．１．１”である少なくとも１つのルータアドレスにより設定される。当該アドレスを取得する１つの方法は、ＤＨＣＰ“デフォルトルータ”オプションを利用することによってである。
【００２０】
インホームホスト１４０が２つの異なるサブネットからの２つのＩＰアドレスを所有するという事実は、ホストがマルチホーム化されたホストであることを意味する。しかしながら、インホームホスト１４０は１つのネットワークインタフェースしか有しないため、それは真の“マルチホーム化”されたホストでなく、ここでは“擬似マルチホーム化されたホスト”と呼ばれる。
【００２１】
プライベートアドレスとパブリックアドレスの両方が、ネットワークインタフェースに拘束される。これはすでにＬｉｎｕｘ上で可能である。一例として、以下のコマンドを使用することは、同じ結果を実現するであろう。“ｉｆｃｏｎｆｉｇ  ｅｔｈ０  １９２．１６８．１．１１”は、プライベートアドレスが“１９２．１６８．１．１１”を有するイーサネット（登録商標）インタフェース０を設定する。“ｉｆｃｏｎｆｉｇ  ｅｔｈ０：１２０．２０．２０．２０”は、パブリックアドレス“２０．２０．２０．２０”を有する同一インタフェースを設定する。
【００２２】
インホームホスト１４０は、ネットワークインタフェース上で設定されている従来のＩＰアドレスと同様にプライベートアドレスを処理する。より詳細には、インホームホスト１４０は、ネットワークインタフェースのＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレス又は“物理アドレス”とプライベートアドレスとの間のマッピングに対するＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）リクエストに応答する。物理アドレスは、ＩＰアドレスより下位レベルのアドレスであるとみなされる。物理アドレスの他の２つの宛先は、“ハードウェアアドレス”と“イーサネット（登録商標）アドレス”である。データリンクレイヤのデバイスドライバは、インターネットアドレス、すなわち、“ｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ”のフォーマットを理解せず、その代わりに物理アドレスを要求する。ＡＲＰは、インターネットアドレスをそれの対応する物理アドレスに変換するための機構である。例えば、ＲＧ１３０がパブリックネットワーク１２０からインホームホスト１４０に対するパケットを受信した場合、ＲＧはＡＲＰを利用して、インターネットアドレスを物理アドレスに変換する。物理アドレスが先のＡＲＰの呼び出しからＲＧのキャッシュに保持されなかった場合、ＲＧは当該インターネットアドレスによりパケットを送信する。適切なホスト１４０がインターネットアドレスを認識し、それの物理アドレスにより応答する。本発明によると、当該ホスト１４０に送信されたインターネットアドレスは、それのプライベートアドレスである。パブリックアドレスは、当該アドレスがＲＧにより所有されているため、ＡＲＰに関連しない。
【００２３】
図３は、インホームホスト１４０が本発明による出力パケットを準備する一例となる方法を示す。インホームホスト１４０から送信されるデータが、ＴＣＰ／ＩＰレイヤのトップにあるアプリケーションレイヤから受信されるときは常に（ステップＳ３１０）、ピアデバイスの宛先アドレスが同一のサブネット上にあるかクエリされる（ステップＳ３２０）。当該クエリに対する応答は、各アドレスの要素間の比較を実行する“ネットマスク”として知られる小さなＬｉｎｕｘプログラムを実行することにより提供することが可能である。
【００２４】
回答が“Ｙｅｓ”であるとき、ホスト１４０はパケットを送信するため従来のステップに従う。まず、ホスト１４０は、パケットヘッダのソースＩＰアドレスとしてプライベートアドレスを使用する（ステップＳ３３０）。その後、ホスト１４０は、ＡＲＰ手順を呼び出すことによってピアのＭＡＣアドレスを決定する。本例で仮定される相対的にシンプルなネットワークでは、パケットは１回のホップでピアに到達する。
【００２５】
しかしながら、より一般には、中間ルータはパケット送信を受信するかもしれない。その後、図４を参照するに、それは典型的には、ステップＳ３２０において宛先アドレスにより示される受信者であるピアのアドレスについてＡＲＰを実行する最後の送信装置４４０となる（ステップＳ３４０）。すなわち、ピアへの送信のためパケットをラップ又は“カプセル化”する際、ピアから１ホップ離れた装置がＡＲＰを介し求められたアドレスをパケットに挿入する。再びシンプルなケースとして、装置がペイロードメッセージを含むＩＰパケットをＭＡＣヘッダにカプセル化し、このカプセル化されたパケットをピアに送信するホスト１４０であると仮定する（ステップＳ３５０）。
【００２６】
回答が“Ｎｏ”であるとき、ＩＰヘッダのソースアドレスフィールドは、ホスト１４０のパブリックＩＰアドレスにより充填される（ステップＳ３６０）。これは、ホストがルータのプライベートアドレスによりルータと通信している場合、ソースとしてそれのプライベートアドレスを利用する従来の状況とは異なっている。
【００２７】
上述されるように、ホスト１４０には、設定されることにより、ＲＧ１３０のプライベートＩＰアドレスが与えられている。従って、ホスト１４０はＡＲＰによる各自の物理アドレスを決定する。これは、２つのステップの１つを伴う可能性がある。この物理アドレスがすでに計算され、ホストのＡＲＰキャッシュに残っている場合、物理アドレスはキャッシュから単にコピーすることによって求められる。他方、当該物理アドレスがキャッシュから利用可能でない場合、ホストはＡＲＰリクエストを配信する。ＲＧ１３０は、ＲＧに属する多数の中の１つであるかもしれない自己のＩＰアドレスを認識し、それの物理ハードウェアアドレスをパケットに挿入した後、ＡＲＰリプライによりホスト１４０に応答する。従って、ホストは、２つの方法の適切な１つによって、同時にパケットに挿入又は追加されるべき物理ハードウェアアドレスを求めることができる（ステップＳ３７０）。次に、ホスト１４０は、ＩＰパケットをＭＡＣヘッダにラップする。ソースアドレスは、ホスト１４０のネットワークインタフェースの物理アドレスである。宛先アドレスは、ＲＧ１３０の決定された物理アドレスである。ホスト１３０は、ＲＧ１３０のカプセル化されたパケットを送信する（ステップＳ３８０）。
【００２８】
上記例では、通信はプライベートネットワーク１１０とパブリックネットワーク１２０との間のものであるが、本発明の意図される範囲は、１つのアドレス領域と他のアドレス領域との間である。
【００２９】
また、上記例は、ホスト１４０がパケットをＲＧ１３０に直接送信している比較的シンプルなサブネットを仮定している。しかしながら、より大規模なネットワークでは、上述されるように、送信は中間ルータなどを介し行われるかもしれない。一般的な意味では、ホスト１４０を含む１以上の装置のグループ４５０は、パケットをＲＧ１３０に送信することに関連するかもしれない。当該グループは、例えば、ＲＧ１３０から１ホップ離れたホスト１４０以外の装置４４０を含むかもしれない。従って、例えば、サブネット１１０の外部の通信のケースでは、グループは、宛先に基づき（ステップＳ３２０）、パケットのソースアドレスとして指定されるべきアドレスを決定し（ステップＳ３６０）、ＲＧ１３０のＩＰアドレスから、下位レベルのアドレスを求め、パケットをカプセル化するに際して求められたアドレスを追加し、サブネット外へのルーティングのため、ＲＧにカプセル化されたパケットを転送する。当該グループが単にホスト１４０から構成されている場合、ホストは、これらすべての機能を実行する。例えば、グループがまたＲＧ１３０から１ホップ離れた装置４４０を含む場合、ホスト１４０がパケットを生成し、最終的な宛先アドレスを決定し、当該アドレスをパケットのソースアドレスとして提供し、他方、装置４４０がＲＧの下位レベルアドレスを求め、当該アドレスをパケットをカプセル化する際に追加し、カプセル化されたパケットをＲＧに転送することが可能となるように、機能が分割されてもよい。他の中間ノードやルータなどサブネット１１０の１以上の他の装置４６０が、ホスト１４０からＲＧ１３０と１ホップ離れた装置４４０へのパケットのパス上に存在してもよい。
【００３０】
図５は、図３の手順により送信されるパケットの一例となるフォーマットを提供する。インターネット１２０を介しホストと通信する際に発行されるパケットの具体例として、まずインホームホスト１４０には図２のＤＨＣＰ処理によって、それに割り当てられたパブリックアドレス“２０．２０．２０．２０”２１２に係るポート“１００１”５０４が割り当てられていると仮定する。ホスト１４０は、“１３１．１．１．１”のアドレス５１２とポート“５５５５”５１６とを有するパブリックインターネット１２０を介しそれのピアにメッセージ５０８を送信することを所望する。ペイロードメッセージ５０８をカプセル化するパケットのＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）又はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ヘッダに、ポート番号５０４と５１６が現れる。ＩＰヘッダは、ＩＰソース及びデスティネーションアドレス２１２と５１２を含む。
【００３１】
ピアがインホームホスト１４０と同一のサブネット上にあるとき、ＩＰヘッダのソースアドレス２０８はプライベートアドレスである。インホームピアの宛先アドレス５２０は、本例では“１９２．１６８．１．２１”である。ソース及びデスティネーションポート５２４と５２８は、それぞれ“２１１１”と“２１”である。
【００３２】
インターネット１２０からＲＧ１３０に入力されるパケットは、必ずしもＩＰレイヤ情報、すなわち従来のＩＰアドレスだけに基づきルーティングされる必要はなく、任意的にはトランスポートレイヤ情報、より詳細にはＴＣＰ／ＵＤＰヘッダのポートに基づきルーティングされる。従って、複数のインホームホスト１４０が、１つのパブリックアドレスに多重化することが可能である。
【００３３】
図６は、本発明によるＲＧ１３０のルーティングテーブル６００の一例である。宛先アドレス６０４及びデスティネーションポート６０８からルーティングテーブル６００のプライベートアドレス領域６１２の宛先アドレスへのマッピングは、図２と同様のＤＨＣＰメッセージの交換によって確立及び更新することが可能である。
【００３４】
一例となるテーブル６００は、以下のカラムを有する。すなわち、宛先アドレス６０４と、デスティネーションポート６０８と、プレイベートアドレス領域６１２の宛先アドレスと、転送インタフェース６１６と、インタフェースＩＰアドレス６２０とを有する。最初の３つの行６２４、６２８及び６３２は、３つのホスト１４０にそれぞれ対応している。特に、それぞれは同一のＲＧにより所有されるパブリックプライベートアドレス２３２とパブリックアドレス２１２とを使用するが、各ポート５３６、５４０及び５４４によりインタフェースにおいて区別される。さらに、これら３つのホスト１４０は、サブネットワーク１１０の内部に各自のアドレス５４８、５５２及び５５６を有する。転送インタフェース６１６は、プライベートネットワークと接続するイーサネット（登録商標）インタフェースであり、第４の行６２０は転送インタフェースのためのプライベートアドレスである。
【００３５】
図７は、ＲＧ１３０においてインターネット１２０から受信されるパケットがどのように処理されるかの一例を示す。ステップ７１０において、到着したパケットは、ＲＧ１３０のパブリックアドレスである“２０．２０．２０．２０”の宛先アドレス２１２を有する。デスティネーションポート５４０は、“２００１”である。ステップ７２０において、ＲＧ１３０上のアプリケーションによってパケットを使用する前に、ルーティングテーブル６００の検索により、デスティネーションポート５４０に基づき、対応するインホームホストの宛先アドレス５５２、すなわち“１９２．１６８．１．２１”がデスティネーションポート５４０に基づき検出される。“２０．２０．２０．２０”、すなわち、パケットの宛先アドレスを介しＡＲＰを呼び出す従来のルータ処理と異なり、ＲＧ１３０は、検索されたプライベートアドレス“１９２．１６８．１．２１”を決定するためＡＲＰを呼び出す（ステップ７３０）。ステップ７４０において、デスティネーションホスト１４０のＭＡＣアドレスを求めた後、ルータ１３０はもとの入力ＩＰパケットをＭＡＣヘッダによりラップし、カプセル化されたパケットを受信パケットに指定されているデスティネーションホストに送信する。
【００３６】
出力パケットに関して上述された状況と同様に、より複雑なネットワークにおける入力パケットは、例えば、デスティネーションホスト１４０から１ホップ離れているかもしれない、又は離れていないかもしれない中間ルータを介し同様にして内部ルーティングされるかもしれない。図４を再び参照するに、ホスト１４０から１ホップ離れた装置４７０は、求められたアドレスによりカプセル化される。一般的なケースでは、ＲＧ１３０は、サブネット１１０の外部からパケットを受信し、受信したパケットに指定されているデスティネーションホストの第１のネットワークのアドレスを生成し、ＭＡＣアドレスを求め、求めたＭＡＣアドレスを追加するため受信したパケットをカプセル化し、カプセル化されたパケットをデスティネーションホストに送信する際に、任意的にサブネットワーク１１０の１以上の装置と共に、すなわち、“ゲートウェイグループ４８０”の一部として動作する。パケットを出力する際の類似の状況と同様に、サブネット１１０に入力するパケットが、１以上の中間ノード４９０をトラバースするＲＧ１３０から装置４７０へのパスに従うかもしれない。
【００３７】
インホームホスト１４０からインターネット１２０への出力パケットについて、ＲＧ１３０は、ソースＩＰアドレス２１２がＲＧが自らのパブリックインタフェース上で所有するＩＰアドレスの１つであるかもしれないときでさえ、パケットにおいて検出された宛先ＩＰアドレスについてルーティング決定をする通常のルータと異なるものでない。
【００３８】
本発明の好適な実施例と考えられているものが図示及び説明されたが、本発明の趣旨から逸脱することなく、形式又は詳細の各種改良及び変更が容易に可能であるということがもちろん理解される。従って、本発明は、図示及び説明された形式に限定されるものではなく、添付した請求項の範囲内にあるすべての改良をカバーすると解釈されるべきである。
【図面の簡単な説明】
【００３９】
【図１】図１は、パブリックインターネットとプライベートサブネットワークとの間のインタフェースの概略である。
【図２】図２は、本発明によるパブリック領域とレジデンシャルゲートウェイの後方のホストとの間の通信を確立するための１つの可能なプロトコルを表すフロー図である。
【図３】図３は、本発明によるレジデンシャルゲートウェイの後方のホストがパケットを出力する一例となる手順のフロー図である。
【図４】図４は、本発明による装置の機能グループ化とパケットフロートを示すフロー図である。
【図５】図５は、図３の手順により送信されるパケットのフォーマット図である。
【図６】図６は、本発明によるレジデンシャルゲートウェイにより使用される内部テーブルの一例である。
【図７】図７は、パブリックアドレス領域から入力されるパケットをレジデンシャルゲートウェイが所有する一例となるプロセスのフロー図である。
【図１】
2008527829.tif 000003
【図２】
2008527829.tif 000004
【図３】
2008527829.tif 000005
【図４】
2008527829.tif 000006
【図５】
2008527829.tif 000007
【図６】
2008527829.tif 000008
【図７】
2008527829.tif 000009
【国際調査報告】
2008527829.tif 000010
2008527829.tif 000011
2008527829.tif 000012