JP2007507962A - クライアントにより要求される外部アドレスマッピング - Google Patents

Abstract

パブリックネットワークへのアクセスが、ローカルホストによりリクエストされる。パブリックネットワークへのアクセスに用いられるパブリックアドレスが決定される。ローカルホストに対応するローカルアドレスが、パブリックアドレスにマッピングされる。パブリックアドレスは、ローカルホストに返される。アウトバウンドアクセスがローカルネットワーク又はパブリックネットワークへのものであるか決定される。アウトバウンドアクセスがパブリックネットワークへのものであるとき、パブリックネットワークへのアクセスがリクエストされる。当該リクエストに応答して、パブリック情報が受信される。パブリック情報は、アウトバウンドアクセスに対して生成される１以上のパケットのペイロード部分に配置される。パブリック情報は一般には、少なくともパブリックポートを有するが、パブリックアドレスもまた有するようにしてもよい。当該リクエストは、パブリック情報のパブリックポートが一般にはローカルポートに従うようにローカルポートを供給するようにしてもよい。

Description

本発明は、一般に通信システムに関し、より詳細には、通信システムにおけるメッセージに関するアドレッシングに関する。

ネットワークに接続される装置には、しばしばインターネットプロトコル（ＩＰ）のバージョンにより規定されるアドレスなどのアドレスが割り当てられている。これらのアドレスは、ネットワーク内の情報が正確な送信先装置にルーティングされることを可能にする。典型的には、「ローカル」アドレスと「パブリック」アドレスが存在する。これらのアドレスは、例えば、ネットワークをプライベート領域とパブリック領域にそれぞれ分離するのに利用される。プライベート領域の装置は、当該領域の他の装置と比較的に自由にやりとりする。プライベート領域の装置がパブリック領域の装置に接続しようとするとき、あるいはその反対にパブリック領域の装置がプライベート領域の装置に接続しようとするときは常に、一般にはいくつかの制約が接続に課される。例えば、セキュリティ制限は、あるタイプの送信又は受信がプライベート領域とパブリック領域との間で行われることを許可しないかもしれない。

制限を設け、プライベートとパブリック領域の分離を可能にするため、ゲートウェイが典型的には利用される。ゲートウェイにより実行される１つの分離機能は、アドレス変換である。いくつかのローカルアドレスがプライベート領域に対して設けられる。ゲートウェイは、一般にはこれらのローカルアドレスを、パブリック領域（インターネットなど）において有効な少数のパブリックアドレスに変換する。パブリック領域の送信先は、ゲートウェイにより供給されたパブリックアドレスを利用し、ゲートウェイは、送信先から受信したメッセージをプライベート領域の適当な装置にマッピングする。通常、ネットワークアドレス変換（ＮＡＴ）と呼ばれる上記アドレス変換の１つの理由は、利用可能なアドレス数が制限されているために生じる。

ＩＰのバージョンでは、インターネットアドレスは、特定のフォーマットを有する。このフォーマットは、理論的には極めて多数の装置をアドレスするのに利用することが可能である。しかしながら、これらのアドレスの大きなブロックは、様々な理由により保留される。例えば、企業は割り当てられたアドレスのうち比較的少数のものしか利用しないが、アドレスブロックを割り当てられているかもしれない。また、社内用などプライベートの利用に保留されているアドレスブロックも存在する。従って、インターネット上のアドレスはアドレスの不足が生じている。ＮＡＴがこの問題を改善するが、ＮＡＴはまたある適用を処理する際に問題を有する。

従って、ネットワークを介した通信に適したアドレスマッピングを提供する技術が、当該技術分野において必要とされる。クライアントにより要求された外部アドレスマッピングの技術が提供される。

本発明の第１の特徴では、パブリックネットワークにアクセスするためのリクエストが、ローカルホストから受信される。パブリックネットワークにアクセスするのに利用されるパブリックアドレスが決定される。ローカルホストに対応するローカルアドレスが、パブリックアドレスにマッピングされる。当該パブリックアドレスが、ローカルホストに返される。

さらに、パブリックネットワークからローカルホスト、又はローカルホストからパブリックネットワークへのアクセスが可能である。１以上のヘッダと１以上のペイロードエリアを有するパケットが生成されてもよい。パブリックアドレスは、１以上のペイロードエリアの与えられた１つに置かれるかもしれない。さらに、ローカルホストは、アクセスのためのグローバルポートを要求し、グローバルポートは、アクセスのためローカルホストにマッピングされてもよい。

本発明の第２の特徴では、アウトバウンドアクセス（ｏｕｔｂｏｕｎｄ ａｃｃｅｓｓ）がローカルネットワーク又はパブリックネットワークへのものであるか判断される。アウトバウンドアクセスがパブリックネットワークへのものであるとき、パブリックネットワークへのアクセスが要求される。当該要求に応答して、パブリック情報が受信される。パブリック情報は、アウトバウンドアクセスに対して生成された１以上のパケットのペイロード部分に置かれる。パブリック情報は、一般に少なくとも１つのパブリックポートを有するが、さらにパブリックアドレスを有するものであってもよい。当該要求は、パブリック情報のパブリックポートが一般にローカルポートに従うものとなるようにローカルポートを供給するようにしてもよい。

本発明と共に、本発明のさらなる特徴及び効果のより完全なる理解は、以下の詳細な説明と図面を参照することにより取得される。

参照が容易となるように、詳細な説明は、イントロダクション、装置及び方法例及びメソッドの定義例というタイトルの３つのセクションに分割される。

イントロダクション
上述のように、インターネット上ではアドレスが不足している。特に、インターネットプロトコルのバージョン４（ＩＰｖ４）は、規定されるＩＰアドレスによりこの不足を生じさせるのに寄与する。アドレスの不足に対応して、この不足を解決するためいくつかの解決策が講じられている。これらの解決策のうち、ネットワークアドレス変換（ＮＡＴ）又はネットワークアドレスポート変換（ＮＡＰＴ）技術が、最も一般的に利用されている。

ＮＡＴ及びＮＡＰＴは、社内の「プライベート」ネットワーク内で使用されるようなプライベート領域内のアドレスを、パブリックのインターネット内で使用されるようなパブリック領域内の１以上のアドレスにマッピングすることを可能にする。一般的に利用されているが、ＮＡＴ及びＮＡＰＴは、（１）インバウンドアクセス（ｉｎｂｏｕｎｄ ａｃｃｅｓｓ）は設定時間において決定される設定に基づく場合のみ可能である、（２）プライベートネットワークとパブリックインターネットの境界を横断するのに必要なプロトコルは、当該プロトコルがアドレッシング情報を有する場合、アプリケーションレイヤゲートウェイ（ＡＬＧ）を必要とする、などを少なくとも含むいくつかの問題を有する。

ＮＡＴ及びＮＡＰＴの適切な代わりとなるものとして、ＩＰｖ４アドレス不足を解決する可能性を有するＲＳＩＰ（Ｒｅａｌｍ−Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルがある。ＲＳＩＰの効果は、それが動的にインバウンドアクセスと、アプリケーションへの変更なくＡＬＧが存在ないことをサポートするということである。ＲＳＩＰの大きな問題点は、それが現在インストールされているアプリケーションベースに互換性を有さず、主要なネットワーキング関連メーカーによりサポートされていないということである。

さらに、アプリケーションがアドレス変換装置を検出又は制御し、これにより、ＡＬＧの必要性を解消し、及び／又はインバウンドアクセスを可能にするプロトコルが存在する。このようなプロトコルの一例として、アプリケーションがアドレスマッピングをクエリすることを可能にするＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）ゲートウェイ仕様があげられる。当該プロトコルの問題点は、アプリケーションがアドレス変換が実行されている事実を認識すべきであるということである。従って、新たなアプリケーションには適しているが、既存のアプリケーションには適していない。

本発明は、上記問題に対する解決策を提供する。特に、本発明は、ＡＬＧを必要とすることなく利用可能である。本発明は、一実施例において、パブリックネットワークへのアクセスを要求するローカルホストをパブリックアドレス及びパブリックポートに提供する。ローカルホストからパブリックネットワーク、及び／又はパブリックネットワークからローカルホストへのアクセスが可能であろう。このとき、ローカルホストは、パケットのペイロードを充填する際に、パブリックアドレスとパブリックポートを使用する。ペイロードを充填するのに利用される情報は、ローカルホスト上のアプリケーションからのものである。従来のＡＬＧを用いたシステムでは、ローカルホストは、ローカルアドレス及びローカルポートによりパケットのペイロードを充填する。このとき、ＡＬＧは、ペイロードのローカルアドレスとローカルポートをパブリックアドレスとパブリックポートと置換するのに利用される。本発明の一例となる特徴では、ローカルホストはすでに有効なパブリックアドレスとパブリックポートを有するため、本発明を用いて生成されるパケットのペイロード部分は、パブリックアドレスとパブリックポートを有することとなり、ＡＬＧは必要とされない。

本発明は、少なくとも以下の効果を提供する。（１）インバウンドアクセスがＡＬＧを利用することなく可能となる。（２）多くのユーザが操作する家電機器（ＣＥ）オペレーティングシステムにより制御又は維持可能な安定的なアドレス変換装置が生成される。（３）設定が不要となる。（４）ＡＬＧの必要がなくなる。（５）既存のアプリケーション又はプロトコルが、変更することなく可能となる。（６）現在インストールされているベースが利用可能である。（７）ＵＰｎＰとの協調が可能である。（８）セキュリティを向上することができる。（９）ＣＥ装置の一例となる実現形態を軽量化できる。

ここで図１を参照するに、本発明の一実施例に従って、プライベート領域とパブリック領域が通信する。プライベート領域は、２つのローカルホスト１０５−１と１０５−２（ＣＲＥＡＭクライアントとも呼ばれる）、及びローカルネットワーク１６５を介し通信するゲートウェイシステム１３５（ＣＲＥＡＭサーバとも呼ばれる）を有する。プライベート領域の各装置は、ローカルアドレス１７０−１、１７０−２又は１７０−３（ローカルアドレス又はアドレス１７０とも呼ばれる）を有する。パブリック領域は、パブリックネットワーク１６０を介し通信するゲートウェイシステム１３５及びリモートホスト１５０を有する。パブリック領域の各装置は、パブリックアドレス１８０−１又は１８０−２（パブリックアドレス又はアドレス１８０と呼ばれる）を有する。本例では、ゲートウェイシステム１３５は、ローカルアドレス１７０−３とパブリックアドレス１８０−１の両方を有する。ゲートウェイシステム１３５は、それに割り当てられた複数のプライベートアドレス１７０とパブリックアドレス１８０を有することができる。

ローカルホスト１０５−１及び１０５−２は、同様のものであると予想されるが、簡単化のため、ローカルホスト１０５−１のみが詳細に示される。ローカルホスト１０５−１は、プロセッサ１０６とメモリ１０７を有する。メモリ１０７は、アプリケーション１０８、オペレーティングシステム１０９、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ−Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）スタック１１０、ＣＲＥＡＭソケット１１１、ローカルサブネットリスト１１２及びポート１１３を有する。一般に、ＴＣＰ／ＩＰスタック１１０とＣＲＥＡＭソケット１１１は、オペレーティングシステム１０９の一部であるが、説明の簡単化のため、それらは別々に図示される。ＣＲＥＡＭソケット１１１は、従来のソケットと区別するため名付けられている。一実施例では、本発明の機能は、ＴＣＰ／ＩＰスタック１１０のレイヤ３とレイヤ４（図示せず）内で動作するようにしてもよい。ゲートウェイシステム１３５は、メモリ１３７に接続されるプロセッサ１３６を有する。メモリ１３７は、ＣＲＥＡＫゲートウェイ１３８、サブネットリスト１３９、アドレス、ポート及び識別を有する１つのエントリ１４５を示すアドレスマッピング情報１４０（以下で詳細に説明される）、及びアドレストランスレータ１４６を有する。ＣＲＥＡＭゲートウェイ１３８は、従来のゲートウェイと区別するため名付けられている。リモートホスト１５０は、ポート１５５を有する。

図１の例では、ローカルホスト１０５−１（例えば）とゲートウェイシステム１３５の間で通信されるパケット１２０−１がある。パケット１２０−１は、ヘッダ１２１−１とペイロード１２２−１を有する。ヘッダ１２１−１は、ソースアドレス１２５−１、ソースポート１２６−１、デスティネーションアドレス１２７−１及びデスティネーションポート１２８−１を有することが可能なヘッダアドレス情報１２３−１を有する。ペイロード１２２−１は、ペイロードアドレス情報（アドレス１２９−１とポート１３０−１を有する）とデータ１３１−１を有する。ゲートウェイシステム１３５を通過した後のパケット１２０−２が示される。

本開示が説明するアドレス情報は２つのアドレス情報セットが存在する。１つのセットはヘッダアドレス情報１２３であり、他のセットはペイロードアドレス情報１２４である。本発明の一例となる特徴は、例えば、ＡＬＧを利用することなく既存のアプリケーションを使用することを可能にするため、当該アドレスセットを処理する。しかしながら、本発明は所望の場合、ＡＬＧと共に利用されてもよいということに留意すべきである。

本発明の実施例の一例となる動作が、具体例を通じて最も良く説明される。ヘッダアドレス情報１２３を処理する一例となる技術の広範な説明が与えられる。同様に、ペイロードアドレス情報１２４を処理する一例となる技術の広範な説明が、与えられる。その後、同様の詳細な説明が与えられる。

ヘッダアドレス情報１２３に関して、ローカルホスト１０５−１は、プライベート又はパブリック領域に存在する可能性のあるデスティネーションと通信するためのものである。例えば、ローカルホストは、アプリケーション１０８により生成されるメッセージ（図示せず）をデスティネーションに通信するようにしてもよい。当該メッセージは、ローカルホスト１０５−１によりパケット１２０−１に構成することができる。

使用されるヘッダ１２１のタイプは、使用されるプロトコルにより決定される。例えば、ＴＣＰを利用するとき、パケット１２０は、ヘッダ１２１にＩＰヘッダとＴＣＰヘッダを有するであろう。他の例として、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を利用するとき、パケット１２０は、ヘッダ１２１にＩＰヘッダとＵＤＰヘッダを有するであろう。ＩＰヘッダは、一般にはソースＩＰアドレス１２５とデスティネーションＩＰアドレス１２７を有する。ＴＣＰ及びＵＤＰヘッダは、ソースポート１２６とデスティネーションポート１２８を有する。他の例として、ＩＰセキュリティエクステンション（ＩＰｓｅｃ）カプセル化セキュリティプロトコル（ＥＳＰ）の場合、ＩＰヘッダはＩＰｓｅｃヘッダに後続する。従って、ヘッダ１２１の正確な構成は、利用されるプロトコルに応じて可変とされる。簡単化のためここでは、本発明の技術は多数の異なるヘッダタイプと対応するプロトコルに適しているが、ヘッダアドレス情報１２３は図１に示されるようなものと仮定される。例えば、ローカルホスト１０５とパブリックネットワーク１６５の間のアクセスは、以下のプロトコルの何れか、すなわち、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）９５９、Ｈ．３２３ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）規格、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２５４３、ＲＳＩＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２２０５、ＩＰｓｅｃ−ＥＳＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２４０２、ｋｅｒｂｅｒｏｓ４、ｋｅｒｂｅｒｏｓ５，ｔｅｌｎｅｔＲＦＣ８５４、ｒｌｏｇｉｎＲＦＣ１２８２を利用することができる。

使用されるプロトコルに関係なく、ＴＣＰ／ＩＰスタック１１０は、一般には、ペイロード１２２のスペース及びそれのヘッダ１２１とパケット１２０を生成するプロセスである。アプリケーション１０８は、一般には、ペイロード１２２−１を充填するのに利用される情報を提供する、又はペイロード１２２−１に情報を充填するエンティティである。以下の説明では、ＴＣＰ／ＩＰスタック１１０はヘッダアドレス情報１２３を生成していると仮定しているということは理解されるであろう。例えば、以下に図示されるオブジェクト相互作用図では、ヘッダ１２１を生成するＴＣＰ／ＩＰスタック１１０への呼び出しは、簡単化のため図示されないが、行われると仮定される。

アプリケーション１０８は、リモートホスト１５０にメッセージ（図示せず）を送信し、このため、パブリックネットワーク１６０へのアクセスを要求すると仮定する。アプリケーション１０８は、オペレーティングシステム１０９、ＴＣＰ／ＩＰスタック１１０及びＣＲＥＡＭソケット１１１により動作し、パケット１２０−１が生成される。アプリケーション１０８は、ペイロード１２５−１を充填するのに用いられる情報を提供する。ペイロード１２２−１が、以下で説明される。パケット１２０−１は、ゲートウェイシステム１３５に送信される。ゲートウェイシステム１３５は、パケット１２０−１を受付け、パケット１２０−１をＣＲＥＡＫゲートウェイ１３８に与える。ＣＲＥＡＭゲートウェイ１３８は、一般には、以下の詳細な説明において、図２を参照することによってソースアドレス１２５−１とソースポート１２６−１を変更する。本発明の実施例では、ソースアドレス１２５−１はローカルアドレス１７０−１であり、ソースポートは、ＣＲＥＡＭゲートウェイ１３８との交渉を通じて決定されているポート１１３に対応する番号であろう。パケット１２０−１のデスティネーションアドレス１２７−１はパブリックアドレス１８０−２であり、デスティネーションポートは、一般にはポート１５５に対応する番号となる。

ＣＲＥＡＭゲートウェイ１３８は、ソースアドレス１２５−１をパケット１２０−２のソースアドレス１２５−２と置換する。ソースアドレス１２５−２は、一般にはパブリックアドレス１８０−１である。ソースポート１２６−１は、一般には不変とされ、ソースポート１２６−２として出力される。同様に、参照番号１２６〜１３１は、パケット１０２−１と１２０−２の間で不変とされる。従って、ＣＲＥＡＭゲートウェイ１３８は、「ローカル」ソースアドレス１２５−１（ローカルアドレス１７０−１など）を「パブリック」ソースアドレス１２５−２（パブリックアドレス１８０−１など）に変更することによって、ローカルアドレス１７０をパブリックアドレス１８０に置換する。

ＣＲＥＡＭゲートウェイ１３８は、ローカルソースアドレス１２５−１をパブリックソースアドレス１２５−２にマッピングするのに利用されるアドレスマッピング１４０を維持する。このマッピングは、参照番号１４５により示され、以下でより詳細に説明されるアドレス、ポート及び識別を有する。一般に、ローカルソースポート１２６−１とパブリックソースポート１２６−２は、本発明の一例となる特徴では同一のものである。

アドレストランスレータ１４６は、ローカルアドレス１７０をパブリックアドレス１８０に変換するため、ＣＲＥＡＭゲートウェイ１３８により利用される。サブネットリスト１３９は、ヘッダアドレス情報１２３が変更されるべきか判断し、何れのアドレスがローカルアドレスであるか、パブリックアドレスであるか規定するため利用される。例えば、ローカルホスト１０５−１がパケット１２０−１をローカルホスト１０５−２に送信している場合、ゲートウェイシステム１３５は、ヘッダアドレス情報１２３がローカルアドレス１７０を有するとき、アドレスマッピングを実行する必要はない。一般に、ゲートウェイシステム１３５は、ローカルホスト１０５−１と１０５−２の間のパケット１２０−１の通信に関与せず、ゲートウェイシステム１３５は、ローカルホスト１０５−１とローカルホスト１０５−２が異なるサブネット上にある場合、ルータ（図示せず）を有するようにしてもよい。ルータはサブネット間の通信を行う。ローカルホスト１０５は、以下で詳細に説明されるように、各種メソッドコールを通じてアドレスマッピングを要求することに留意すべきである。サブネットリスト１１２は、アドレス変換が必要であるか判断するため、ローカルホスト１０５−１により利用されてもよい。本開示では、アドレス変換は、アドレスマッピング１４０などのアドレスマッピングに従って、アドレスを変更するプロセスとみなされる。

ペイロードアドレス情報１２４に関して、従来のシステムでは、アドレス１２９とポート１３０は、ローカルアドレス１７０とローカルポートとすることができる。この場合、ＡＬＧは、典型的には、アドレスマッピングを生成し、アドレス１２９とポート１３０を決定されたアドレスとポートに置換するため、ゲートウェイシステム１３５の一部として利用される。ＡＬＧの動作方法は、以下の通りである。（１）アドレス１２９−１がローカルアドレスである場合、又はポート１３０−１がローカルポートである場合、ＡＬＧは、アドレス１２９−１又はポート１３０−１をパブリック領域に存在するアドレス又はポートと置換するためマッピングを生成する。（２）アドレス１２９−１がパブリックアドレスである場合、又はポート１３０−１がパブリック領域において有効なポートである場合、ＡＬＧは実行されない。ＡＬＧは、一般には、マッピングを構成するため、ＮＡＴルールを生成する。このことは、従来のゲートウェイシステムの一部として、ＡＬＧ（図１に図示されない）１３５が使用されている各プロトコルに必要であることを意味する。上述のように、これは不十分であり、新しいプロトコルが開発され、又は古いプロトコルが変更されるときは常に、新たなＡＬＧが生成されることを意味する。

対照的に、本発明の一例となる特徴では、ＣＲＥＡＭゲートウェイ１３８は、パブリック領域において、適切なパブリックアドレス１８０と適切なパブリックポート（ポート１５５など）を決定するであろう。ＣＲＥＡＭゲートウェイ１３８は、アプリケーション１０８により要求されると、適切なパブリックアドレス１８０と適切なポートを決定し、これらをアプリケーション１０８に与える。従って、アプリケーションは、変更される必要のないアドレス１２９−１とポート１３０−１によりペイロードアドレス情報１２４を占有するのに用いられる情報を生成する。ＣＲＥＡＭゲートウェイ１３８は、アドレスマッピング１４０において、適切なパブリックアドレス１８０と適切なパブリックポートのマッピングを維持する。現在インストールされているアプリケーション１０８のベースは、本発明による利用に適しており、アプリケーション１０８を変更する必要はない。

ゲートウェイシステム１３５とローカルホスト１０５−１は、単一のコンピュータシステムに組み込むことが可能であるということに留意すべきである。実際、ローカルホスト１０５−１、ゲートウェイシステム１３５及びリモートホスト１５０は、すべて単一のコンピュータシステムに組み込まれてもよい。ローカルホスト１０５−１とリモートホスト１５０は共に、クライアントアプリケーション、サーバアプリケーション、及びポイント・ツー・ポイント（ｐ２ｐ）アプリケーションをホストするようにしてもよい。アプリケーションのタイプに関係なく、ローカルホストとリモートホストの両方がそれらの間の通信を開始することができることが重要である。

また、相互接続され、ネストされた複数のネットワークが存在するかもしれないということに留意すべきである。例えば、ＣＲＥＡＭゲートウェイ２を介しプライベートネットワーク１と分離されたプライベートネットワーク２が存在する可能性がある。ＣＲＥＡＭゲートウェイ１は、インターネットなどのパブリックネットワークからプライベートネットワーク１を分離する。この指定されたネットワーク構成を利用して、プライベートネットワーク２のホストがインターネットのホストと通信することを所望する場合、プライベートネットワーク２の内部で、ＣＲＥＡＭゲートウェイ２にアウトバウンドアクセス要求が行われる。デスティネーションアドレスを見ることにより、ＣＲＥＡＭゲートウェイ２は、さらなるアドレス変換がなされるべきであることを認識し、プライベートネットワーク１のＣＲＥＡＭゲートウェイ１においてアウトバウンドアクセス要求を実行する。このようにして、ネストされた「プライベート」ネットワークのサポートが利用可能となる。ＣＲＥＡＭに対応するプライベートネットワークが、ＣＲＥＡＭに対応しないプライベートネットワークの内部でネストされる場合、当該ＣＲＥＡＭ非対応プライベートネットワークは、パブリックネットワークと非ＣＲＥＡＭ対応プライベートネットワークとの間の境界を横断するプロトコルのため、ＡＬＧの利用などアドレス変換機能を担当し続ける。

アプリケーション１０８は、ペイロード１２２−１に配備されるアドレス１２９−１及び／又はポート１３０−１を有するデータを生成する任意のアプリケーションとすることができる。例えば、アプリケーション１０８は、ピア・ツー・ピアアプリケーション、アドレスマッピングの維持を要求するアプリケーション、リモートシェル（ＲＳＨ）アプリケーション、Ｘウィンドウシステムアプリケーション、Ｘ−ｔｅｒｍアプリケーションの１以上とすることができる。

ここで説明される本発明は、例えば、実行時に本発明の実施例を実現する１以上のプログラムを有するメモリ１０７又は１３７の一部として、マシーン可読媒体を有する製造物として実現されるかもしれない。例えば、マシーン可読媒体は、ＣＲＥＡＭソケット１１１及び／又はＣＲＥＡＭゲートウェイ１３８の各ステップを実行するよう構成されるプログラムを有するものであってもよい。マシーン可読媒体は、例えば、ハードドライブ、光又は磁気ディスク、電子メモリ又は他の記憶装置などの記録可能媒体であってもよい。

ここで図２を参照するに、テーブルが図示され、プライベート領域の社内ホストとインターネット上のホストとの間の通信中に、ヘッダアドレス情報１２３がどのように変更されるか説明するのに利用される。図２の例では、ローカルホスト１０５−１は社内ホストであり、リモートホスト１５０はインターネット内のホストである。２行目は、社内ホストから開始され、インターネットのホストで終了する通信を示す。この通信では、社内ホストのローカルＩＰアドレスは、ゲートウェイのパブリックＩＰアドレスに変更される（例えば、図１のＣＲＥＡＭゲートウェイ１３８により）。ソースポートは、交渉中に一度だけ効果的に決定されていると、不変とされる。所望の場合、ソースポートは変更することができる。３行目は、インターネットのホストから開始され、社内ホストにおいて終了する通信を示す。この通信では、デスティネーションＩＰアドレスは、社内ホストのローカルアドレスに変更される（例えば、図１のＣＲＥＡＭゲートウェイ１３８により）。デスティネーションポートは、不変とされる。

図３〜１１のオブジェクト相互作用図は、適切なペイロードアドレス情報１２４を提供し、（必要に応じて）ヘッダアドレス情報１２３を提供及び変更するための一例となる技術を説明する。図３〜１１のオブジェクト相互作用図のメソッドコールの多くは、従来のシステムにおいてすでに規定され、本開示は、本発明の一例となる特徴を実現するため利用されるコールの具体的の変更を指摘する。アプリケーション１０８の観点から、アプリケーション１０８は、単に現在実行しているメソッドコールを実行することができるだけであり、本発明の一例となる特徴は、アプリケーション１０８がすでにパブリックアドレスとパブリックポートを有することとなり、ＡＬＧが不要となるように、適切なパブリックアドレスとパブリックポートを自動的に決定する。

アドレス変換の開始前、ＣＲＥＡＭクライアントがＣＲＥＡＭゲートウェイ１３８において登録されることが効果的である。一実施例では、ＣＲＥＡＭクライアント１０５は一度は登録される必要があるが、この登録は特定の時間に限定される。この登録時間は、ＣＲＥＡＭゲートウェイ１３８によりモニタされ、ＣＲＥＡＭクライアント１０５のポール（ｐｏｌｌ）の成功後、ゲートウェイ１３８により延長される。登録時間の最大値は、ゲートウェイにおいて設定される。

図３は、ＣＲＥＡＭ対応オペレーティングシステム（ＯＳ）１０９を介したＣＲＥＡＭクライアント１０５の登録のためのオブジェクト相互作用図を示す。ＣＲＥＡＭクライアント１０５の開始中、ＯＳ１０９は、ＣＲＥＡＭゲートウェイ１３８において自らをＣＲＥＡＭクライアント１０５として登録する（シーケンス１）。ＣＲＥＡＭゲートウェイ１３８はこの登録を確認する（シーケンス２）。確認中、ＣＲＥＡＭゲートウェイ１３８は、ローカルサブネットリスト１１２を有する。この情報は、アドレス変換が必要であるか決定するため、ＣＲＥＡＭクライアント１０５により利用されてもよい。登録成功後、ＣＲＥＡＭクライアント１０５は、ゲートウェイ１３８からアドレス及びポートマッピングをリースすることができる。

一定間隔で、ゲートウェイ１３８は、ＯＳ１０９を開始登録延長のためＣＲＥＡＭクライアント１０５をポールする（シーケンス３）。この延長登録中、ゲートウェイ１０５は、それのＯＳ１０９を介し、ローカルサブネットにおいて変更がなされる場合、新たなローカルサブネットリスト１１２を有することが可能である。ＣＲＥＡＭクライアント１０５が登録に応答しない場合、当該ＣＲＥＡＭクライアント１０５のリースされたアドレス及びポートマッピングは破棄される。ＣＲＥＡＭクライアント１０５がＯＳ１０９を介し要求される時間内に登録に応答する場合（シーケンス４）、リースされたアドレス及びポートマッピングは延長される。

ＣＲＥＡＭクライアント１０５のＯＳ１０９がシャットダウンされると、ＣＲＥＡＭクライアント１０５は、ＯＳ１０９を利用することによりゲートウェイにおいて登録解除される（シーケンス５）。ゲートウェイ１３８は、登録解除要求を確認する（シーケンス６）。

図４は、ＣＲＥＡＭソケット１１１の生成のための一例となるオブジェクト相互作用図を示す。登録されたＣＲＥＡＭクライアント１０５において実行されるアプリケーション１０８は、ＯＳ１０９を用いてＣＲＥＡＭソケット１１１を生成する（シーケンス１）。ＯＳ１０９は、ＣＲＥＡＭソケット１１１の新たなインスタンスを生成し（シーケンス２）、アプリケーション１０９に（ＣＲＥＡＭソケット１１１を指示する）ハンドルを返す。まだ通信は行われていないということに留意すべきである。

図５は、ＣＲＥＡＭソケット１１１をバインド（ｂｉｎｄ）する一例となるオブジェクト相互作用図を示す。ＣＲＥＡＭソケット１１１とある受信ポートと関連付けるため、アプリケーション１０８は、登録されているＣＲＥＡＭクライアント１０５のＣＲＥＡＭソケット１１１においてバインドを実行する（シーケンス１）。バインドコール中、ＣＲＥＡＭソケット１１１は、ＣＲＥＡＭゲートウェイ１３８においてＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴリクエストを実行する（シーケンス２）。ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭに従って（シーケンス３）、バンドコールが成功又は不成功となる。

ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭは、パブリック領域で使用されるパブリックアドレスと、アプリケーション１０８により使用されるポートを返すことに留意すべきである。従って、アプリケーション１０８は、適切なパブリックアドレスとポートを有し、ペイロード情報１２２に変換されるそれのメッセージを有効なパブリックアドレスとポートにより占有する。従って、ローカルアドレッシング情報をパブリックアドレッシング情報と置換するため、ＡＬＧがペイロード１２２を解析する必要がなくなる。

ＣＲＥＡＭソケット１１１の使用後、ＣＲＥＡＭソケット１１１の寿命は、任意的なシャットダウンコール（シーケンス４）と一般的に必須のクローズコール（シーケンス５）を用いて終了される。クローズコール中、ソケットは、ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴを用いてＣＲＥＡＭゲートウェイ１３８における使用されているすべてのリソースを解放する（シーケンス６）。ＣＲＥＡＭゲートウェイ１３８は、ＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭを用いて応答する（シーケンス７）。

図６は、ＣＲＥＡＭソケット１１１を接続するための一例となるオブジェクト相互作用図を示す。ＣＲＥＡＭソケット１１１のエンドポイントを規定するため、登録されたＣＲＥＡＭクライアント１０５において実行されるアプリケーション１０８は、ＣＲＥＡＭソケット１１１において接続機能をコールする（シーケンス１）。この接続コール中、ＣＲＥＡＭソケット１１１は、デスティネーションアドレスがゲートウェイ内にあるか（すなわち、ローカルアドレス）、又はゲートウェイの外部にあるか（すなわち、パブリックアドレス）、ＣＲＥＡＭゲートウェイ１３８から以前に受信したローカルサブネットリスト１１２を利用してチェックする。デスティネーションアドレスがゲートウェイの外部にある場合（すなわち、パブリックアドレス）、ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴが実行される（シーケンス２）。このリクエストの結果は、ＣＲＥＡＭゲートウェイ１３８から受信される（シーケンス３）。すべてのリクエストが成功すると、当該接続コールは良好に返される。デスティネーションアドレスがゲートウェイの内部にある場合（すなわち、デスティネーションアドレスがローカルアドレスである）、又は、ＣＲＥＡＭソケット１１１がすでにバインドされた場合、ＣＲＥＡＭゲートウェイ１３８にＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴはされない。ＣＲＥＡＭソケット１１１がすでにバインドされ、デスティネーションアドレスがローカルである場合、要求されたアドレス及びポートマッピングを解放することができる。

ＣＲＥＡＭソケット１１１のクローズ中（シーケンス５）、ＣＲＥＡＭゲートウェイ１３８は、リースされたアドレス及びポートマッピングを解放するよう要求される（シーケンス６）。これは、ＣＲＥＡＭゲートウェイ１３８により確認される（シーケンス７）。

データを受信すると、すでに規定されているアプリケーションにより実行可能なコールがいくつか存在する。例えば、アプリケーションは、ｌｉｓｔｅｎ（）、ａｃｃｅｐｔ（）、ｒｅｃｖ（）及びｒｅｃｖｆｒｏｍ（）コールを実行することができる。ｌｉｓｔｅｎ（）の実現形態については、現在のところ変化は予想されない。ａｃｃｅｐｔ（）の実現形態については、現在のところ変化は予想されない。ｒｅｃｖ（）は接続されたソケットについてのみ利用可能であるが、ソケットが接続及び／又はバインドされている場合に限って、ｒｅｃｖ（）とｒｅｃｖｆｒｏｍ（）の両方が典型的には機能する。従って、ＣＲＥＡＭリースは一般には常に利用可能である。

図７は、データを受信するための一例となるオブジェクト相互作用図を示す。パブリックインターネット内で、送信者（本例ではリモートホスト１５０）は、ＣＲＥＡＭゲートウェイ１３８のリースされたアドレスとポートにデータを送信する（シーケンス１）。当該データは、パケット１２０−２として送信される。ＣＲＥＡＭゲートウェイ１３８は、アドレス及びポートマッピングを有するリースに従って、アドレスマッピング及び／又はポートマッピングを実行する（シーケンス２）。図１及び２を参照して上述されるように、アドレス及びポートマッピングは、パブリックアドレスとパブリックポートをヘッダアドレス情報１２４のローカルアドレスとポートに変換する。このマッピングされたパケット１２０−１は、プライベートネットワーク１６５を介し送信される（シーケンス３）。ＣＲＥＡＭパケット１１１は、パケット１２０−１を受信し、受信したパケット１２０−１をそれのバッファに追加する（シーケンス４）。アプリケーション１０８は、ある時点においてバッファから当該パケット１２０−１を読み出す（シーケンス５）。読み出し後、パケット１２０−１はバッファから削除される（シーケンス６）。

一般に、ｓｅｎｄ（）メソッドは、接続されたＣＲＥＡＭソケット１１１においてのみ利用可能である。パブリックＩＰアドレスとパブリックポートにデータを送信するとき、要求されるＣＲＥＡＭリースはすでに実行されている。ＣＲＥＡＭリースは、アプリケーション１０８とリモートホスト１５０との間のマッピングを有する。このマッピングは、一般には図１のアドレスマッピング１４０に格納されている。従って、ＣＲＥＡＭクライアント１０５のＯＳ１０９は、パケット１２０−１をＣＲＥＡＭゲートウェイ１３８に送信するだけでよい。ＣＲＥＡＭゲートウェイ１３８は、ローカルアドレス及び／又はローカルポートをリースされたアドレスとポート（すなわち、パブリックアドレスとパブリックポート）に置換し、変更されたヘッダアドレス情報１２３を有するパケット１２０−２を意図する受信者に送信する。

図８は、ｓｅｎｄ（）メソッドを用いてデータを送信するための一例となるオブジェクト相互作用図を示す。アプリケーション１０８は、パブリックインターネット内に存在する受信者（リモートホスト１５０など）にデータを送信する（シーケンス１）。当該データのＴＣＰ／ＵＤＰヘッダは、送信者のローカルアドレスと（ソースアドレス１２５−１におけるものなど）、受信者のパブリックアドレス（デスティネーションアドレス１２７−１におけるものなど）を有する。パケット１２５−１は、デフォルト経路を用いてローカルネットワーク１６５を介し送信される（シーケンス２）。ＣＲＥＡＭゲートウェイ１３８がパケット１２５−１を受信すると、ローカルアドレッシング情報は、リースされたアドレス又はポートマッピングと置換され（シーケンス３）、残りのパケット１２５−２がインターネットを介し送信される（シーケンス４）。図２を参照して説明されたように、リースされたアドレス又はポートマッピングは、一般にソースアドレス１２５−１をゲートウェイ１３５のインターネットアドレス（パブリックアドレス１８０−１など）に変換し、ポートは一般に同じままである。

ｓｅｎｄｔｏ（）は、接続プロトコル（ＵＤＰなど）が利用されるときに限って利用可能である。データがローカルＩＰアドレスに送信される場合、すでに利用可能でなければ、ＣＲＥＡＭリースが取得される。このことは、ｓｅｎｄｔｏ（）を使用すると、当該ソケットのアドレスマッピングの以前の使用とは独立に、アドレスマッピングが使用されているかのチェックに応じて、ＩＰアドレスの位置に対してチェックが実行されるべきであるということに留意すべきである。

図９は、ｓｅｎｄｔｏ（）メソッドを用いてデータを送信するための一例となるオブジェクト相互作用図を示す。アプリケーション１０８は、特定のポートとＩＰアドレスにデータを送信する（シーケンス１）。まず、デスティネーションアドレス１２７−１がローカルサブネットリスト１１２に従ってローカル又はパブリックであるかチェックされる。デスティネーションアドレス１２７−１がパブリックであり、まだリースされていない場合（例えば、ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴ又はＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴなど）、ＣＲＥＡＭゲートウェイ１３８からリースが取得される（シーケンス２及び応答シーケンス３）。ローカルアドレス情報を有するパケットが生成され、ＣＲＥＡＭゲートウェイ１３８に送信される（シーケンス４）。ＣＲＥＡＭゲートウェイ１３８は、ローカルアドレス情報及び／又はポート情報をリースされたアドレスとポートの組み合わせに置換し（シーケンス５）、パブリックネットワークを介しパケット１２０−２を送信する（シーケンス６）。

ソケットのクローズ後（シーケンス７）、取得されたＣＲＥＡＭリースが解放される（シーケンス８及び確認シーケンス９）。

本発明の一効果は、パケットのペイロード内のアドレッシング情報を含めることができるということである。しかしながら、いくつか検討すべき点がある。正しいアドレッシング情報を取得するため、アプリケーション１０８は、適切な時点において適切な関数をコールすべきである。さらに、これらの関数に対する適切な動作は、ＯＳ１０９により実現されるべきである。

アドレッシング情報を返すｇｅｔｓｏｃｋｎａｍｅ（）、ｇｅｔｈｏｓｔｎａｍｅ（）及びｇｅｔａｄｄｒｉｎｆｏ（）などのすべての関数は、ローカルＣＲＥＡＭクライアント１０５のポートとＩＰアドレスに対する以下の値を返すべきである。
（１）ＣＲＥＡＭソケット１１１がパブリックＩＰアドレスによりピアと接続する場合、ＣＲＥＡＭクライアント１０５のＩＰアドレスは、リースされたＩＰアドレスである。ポート番号は、リースされたポート番号である。
（２）ＣＲＥＡＭソケット１１１がプライベートＩＰアドレスによりピアと接続する場合、ＣＲＥＡＭクライアント１０５のＩＰアドレスは、自らのローカルＩＰアドレスである。ポート番号は、ローカルポート番号である。
（３）接続されていないソケットの場合、有効なＩＰアドレスは返されるべきでない（有効なＩＰアドレスは、プライベート又はリースされたＩＰアドレスであるが、当該ピアに依存する）。この場合、ｎｕｌｌの値が返される。

ＩＰアドレスは一般にはピアのＩＰアドレスに従って決定することができるという事実により、ＩＰアドレスがペイロードの内部に含まれるとき、ＣＲＥＡＭクライアント１０５のＩＰアドレスは、ペイロードを有するパケットの受信者にバインドされるＣＲＥＡＭソケット１１１から決定されるべきであるということをアプリケーションは認識すべきである。

本発明によるアドレスマッピングのユーザは、アプリケーション１０８である。アプリケーション１０８は、例えば、サーバアプリケーション又はＣＲＥＡＭクライアントアプリケーションとすることができる。社内通信の性質により、主要なユーザは、通常はサーバアプリケーションがインターネット内に存在するＣＲＥＡＭクライアントアプリケーションである。ＣＲＥＡＭクライアントアプリケーションの代わりに、本発明はまた、ＣＲＥＡＭクライアントアプリケーションがインターネット内に存在するサーバアプリケーションに利用することができる。しかしながら、この最後のユーザカテゴリは、ある制限にバインドされるかもしれない。

図１０は、ＣＲＥＡＭクライアントアプリケーションを使用する場合のための一例となるオブジェクト相互作用図を示す。この図において、ＣＲＥＡＭクライアントアプリケーション１０８が、ＣＲＥＡＭゲートウェイ１３８の境界を横断するため本技術を利用して（すなわち、プライベート領域からパブリック領域に）、サーバアプリケーション（パブリックホスト１５０上など）に接続するときのやりとりの具体例が与えられる。本例では、ＣＲＥＡＭクライアントアプリケーション１０８はプライベートネットワーク１６５内に配置され、サーバアプリケーションはインターネット（パブリックネットワーク１６０など）内に配置される。

ＣＲＥＡＭクライアント１０５のＯＳ１０９の開始中、ＣＲＥＡＭクライアント１０５は、ＣＲＥＡＭゲートウェイ１３８において自らを登録した（シーケンス１及び２）。

パブリックホスト１５０を介しサーバアプリケーションと通信するため、アプリケーション１０８は、ＣＲＥＡＭソケット１１１を生成する（シーケンス３）。ＣＲＥＡＭソケット１１１の生成後、アプリケーション１０８は、ＣＲＥＡＭソケット１１１を利用してサーバに接続する（シーケンス４）。アプリケーション１０８は、任意のポートからリモートホスト１５０のサーバアプリケーションと通信することができるため、ＣＲＥＡＭソケット１１１を明示的にバインドしない。ＣＲＥＡＭソケット１１１が実際にリモートホスト１５０に接続可能となる前に、まず、サーバアプリケーションがプライベートネットワーク１６５又はインターネット（パブリックネットワーク１６０など）内に存在するかチェックする必要がある。本例では、このチェックは、ローカルサブネットリスト１１２を用いて実行される。本例では、デスティネーションＩＰアドレスはパブリックであり、このため、ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴが実行される（シーケンス５及び６）。ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴの成功後、ｃｏｎｎｅｃｔ（）メソッドに関するデフォルト動作が実行可能である。アプリケーション１０８がソースサイドにおいて生成されたＣＲＥＡＭソケット１１１のポートとＩＰアドレスを要求する場合、リースされたＩＰアドレスとポート番号が返される。一般に、リースされたＩＰアドレスとポート番号は、ローカルＩＰアドレスと異なり、ローカルに使用されるポートとも異なる可能性がある。

一定の間隔により、ＣＲＥＡＭゲートウェイ１３８は、ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＩＮＤＩＣＡＴＩＯＮを実行することによりリース時間を延長することができ（シーケンス７）、このことはＣＲＥＡＭクライアント１０５からのＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭをトリガーする（シーケンス８）。

アプリケーション１０８がサーバにデータを送信すると（シーケンス９）、ＣＲＥＡＭソケット１１１は、ＩＰアドレスとＴＣＰ／ＵＤＰヘッダ内のローカルアドレッシング情報を利用して、当該データをサーバアプリケーションに送信する（シーケンス１０）。ＣＲＥＡＭゲートウェイ１３８は、パケットを傍受し、ＩＰヘッダ及びＴＣＰ／ＵＤＰヘッダ（ヘッダアドレス情報１２３など）内のローカルアドレッシング情報を置換し（シーケンス１１）、それをパブリックリモートホスト１５０を介しサーバアプリケーションに送信する（シーケンス１２）。

アプリケーション１０８がＣＲＥＡＭソケット１１１をクローズするとき（シーケンス１３）、又は、ＯＳ１０９がＣＲＥＡＭソケット１１１をクローズするときでさえ、ＣＲＥＡＭソケット１１１は、リースされたＩＰアドレスとポートの組み合わせを解放する（シーケンス１４及び１５）。

ＣＲＥＡＭクライアント１０５のＯＳ１０９がシャットダウンされているとき、ＣＲＥＡＭクライアント１０５は、ＣＲＥＡＭゲートウェイ１３８において登録解除される（シーケンス１６及び１７）。

図１１は、サーバアプリケーション１０８の使用する場合のための一例となるオブジェクト相互作用図を示す。この図において、サーバアプリケーション１０８がリスニングポートをオープンし、社内クライアントアプリケーション１０５−２とパブリッククライアントアプリケーション１５０が当該サーバアプリケーション１０８に接続するときのやりとりの具体例が与えられる。本例では、サーバアプリケーション１０８は、プライベートネットワーク１６５の内部に配置され、ローカルホスト１０５−１の一部であり、１つのクライアントアプリケーション（パブリックホスト１５０の一部として）はインターネット（パブリックネットワーク１６０など）の内部に配置され、１つのクライアントアプリケーション（ローカルホスト１０５−２の一部として）がプライベートネットワーク１６５の内部に配置される。簡単化のため、パブリックホスト１５０の一部であるクライアントアプリケーションは、「クライアントアプリケーション１５０」と呼ばれる。同様に、ローカルホスト１０５−２の一部であるクライアントアプリケーションは、「クライアントアプリケーション１０５−２」と呼ばれる。サーバアプリケーション１０８は、ここで提供される技術を利用して、インターネットの内部に存在するクライアントアプリケーション１５０と通信する。

ＯＳ１０９の開始時に、ＣＲＥＡＭクライアント１０５−１が、ＣＲＥＡＭゲートウェイ１３８において登録される（シーケンス１及び２）。

入力される通信を受信するため、サーバアプリケーション１０８は一般にＣＲＥＡＭソケット１１１を生成する（シーケンス３）。ＣＲＥＡＭソケット１１１の生成後、サーバアプリケーション１０８は、ＣＲＥＡＭソケット１１１を利用して、指定されたポートにおいて入力されたメッセージを聞き、これにより、サーバアプリケーション１０８は、ＣＲＥＡＭソケット１１１をポートにバインドする（シーケンス４）。このバインドが内部のポート番号及び／又は外部のポート番号に対して行われるべきかＣＲＥＡＭソケット１１１は判断することができないかもしれないという事実により、ＣＲＥＡＭソケット１１１は、内部及び外部ポートの両方にバインドされる。ＣＲＥＡＭソケット１１１を外部ポートにバインドするため、ポートとアドレスの組み合わせが、ＣＲＥＡＭクライアントによりＣＲＥＡＭゲートウェイ１３８においてリースされる（シーケンス５及び６）。ポートのリースに用いられるポート番号は、バインドリクエスト内で用いられるものと同じであり、このため、既知のポートの規定が破られることはない。ポート番号が指定されていない場合、ＣＲＥＡＭゲートウェイ１３８はポート番号を割り当てる。内部ポートと外部ポートのポート番号は一般には同じに維持され、このため、潜在的なポートマッピングコンフリクトは解消される。

一定の間隔により、ＣＲＥＡＭゲートウェイ１３８は、ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＩＮＤＩＣＡＴＩＯＮを実行することによりリース時間を延長することができる（シーケンス７）。これは、ＣＲＥＡＭクライアント１０５−１からのＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭをトリガーする（シーケンス８）。アプリケーション１０８は、リスニング状態においてＣＲＥＡＭソケット１１１を設定する（シーケンス９）。

ローカル社内クライアントアプリケーション１０５−２は、データをサーバアプリケーション１０８に送信する（シーケンス１０）。この通信がローカルであるという事実により、アドレス又はポートマッピングは実行されない。ＣＲＥＡＭソケット１１１は、パケットをそれのバッファに追加する（シーケンス１１）。サーバアプリケーション１０８は、ａｃｃｅｐｔ（）メソッドを利用して、ローカルホスト１０５−２からのローカルクライアントアプリケーションとの接続を受け入れる（シーケンス１２）。サーバアプリケーション１０８は、ｒｅｃｖ（）コールを用いてそれのキューを読み出し（シーケンス１３）、ＣＲＥＡＭソケット１１１は、パケットをサーバアプリケーション１０８に与えるため、パケットをそれのバッファから削除する（シーケンス１４）。

パブリックインターネット内のクライアントアプリケーション１５０は、データをサーバアプリケーション１０８に送信する（シーケンス１５）。ＩＰヘッダ及びＴＣＰ／ＵＤＰヘッダに含まれるリースされたアドレス及びポートの組み合わせは、ＣＲＥＡＭゲートウェイ１３８によりローカルアドレスとポートの組み合わせにマッピングされ（シーケンス１６）、パケットはローカルサーバアプリケーション１０８に送信される（シーケンス１７）。ＣＲＥＡＭソケット１１１は、リマッピングされたパケットをそれのバッファに追加する（シーケンス１８）。サーバアプリケーション１０８は、ａｃｃｅｐｔ（）メソッドを用いて、パブリックホスト１５０からのパブリッククライアントアプリケーションとの接続を受け入れる（シーケンス１９）。サーバアプリケーションは、ｒｅｃｖ（）を呼び出すことによりキューからデータを読み出し（シーケンス２０）、ＣＲＥＡＭソケット１１１は、サーバアプリケーション１０８への転送のため、パケットをそれのバッファから削除する（シーケンス２１）。

ＯＳ１０９がシャットダウンされると、ＣＲＥＡＭクライアント１０５−１はＣＲＥＡＭゲートウェイ１３８において登録解除される（シーケンス２２及び２３）。

本発明の技術が効果的となる他の具体的ケースが存在する。さらにいくつかのケースが後述される。

ローカルホスト登録は、以下のように実行されるかもしれない。何れかのＣＲＥＡＭクライアント１０５のＯＳ１０９の開始中、ＣＲＥＡＭクライアント１０５は、一般にはＣＲＥＡＭゲートウェイ１３８において登録される。ＣＲＥＡＭゲートウェイ１３８は、この登録を受け入れるか、あるいは、ＣＲＥＡＭクライアント１０５がすでに登録されていることを示す。

前者のケースでは（登録が受け入れられるなど）、ＣＲＥＡＭクライアント１０５に対してリースは行われていない。後者のケースでは（ＣＲＥＡＭクライアント１０５がすでに登録されているなど）、ＣＲＥＡＭクライアント１０５に関する現在のリースに対して変更はされない。何れのケースでも、ＣＲＥＡＭクライアント１０５が登録される。ＣＲＥＡＭクライアント１０５のＯＳ１０９が既存のリースを認識していない場合、ＣＲＥＡＭクライアント１０５は、再度登録される前にリソースが解放されるように、まず登録解除すべきである。

本発明の一例となる特徴では、登録確認中、ローカルアドレス範囲を示すテーブルが返される。このテーブルはまた、すでに登録された表示中に含まれる。

ローカルホストの登録解除又はシャットダウンの例は、以下のようなものである。ＯＳ１０９のシャットダウン中、ＣＲＥＡＭクライアント１０５は、ＣＲＥＡＭゲートウェイ１３８において登録解除する。ＣＲＥＡＭゲートウェイ１３８は、ＣＲＥＡＭクライアント１０５が登録解除されることを確認するか、あるいは、ＣＲＥＡＭクライアント１０５が登録されていなかったことを示す。何れの場合でも、ＣＲＥＡＭゲートウェイ１３８において当該ＣＲＥＡＭクライアント１０５に対してリソースはもはや使用されない。

リスニングポートは、以下のように生成することができる。ＣＲＥＡＭクライアント１０５は、インバウンドアクセスのためアドレスとポートの組み合わせをリースするため、ＣＲＥＡＭゲートウェイ１３８においてＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴを実行する。ローカルポート番号とリースされたポート番号は、必ずしも必要ではないが、ＣＲＥＡＭゲートウェイ１３８により等しいと仮定される。

ＣＲＥＡＭクライアント１０５は、リースされるポート番号（例えば、ｈｔｔｐサーバについてはポート８０など）を指定することができ、この場合、ＣＲＥＡＭゲートウェイ１３８はリースを確認するか、拒絶する。

ＣＲＥＡＭクライアント１０５はまた、何れのポート番号も指定しないことも可能である。この場合、ＣＲＥＡＭゲートウェイ１３８は、ポート番号を指定し、リースを確認する。同じローカルポート番号が利用可能でない場合、ＣＲＥＡＭクライアント１０５は、リースを解放し、インバウンドアクセスポートをリースするよう再試行すべきである。

ポートリース処理の性質により、ＴＣＰタイムアウト後、再びリースに対してポートが利用可能であり、これは、ＴＣＰ接続の所望されない再接続を回避するのに効果的である。

送信ポートを生成する例は、以下のようなものである。ＣＲＥＡＭローカルホスト１０５は、アウトバウンドアクセスのためアドレスとポートの組み合わせをリースするため、ＣＲＥＡＭゲートウェイ１３８においてＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴを実行する。ＣＲＥＡＭローカルホスト１０５は、リースされるポート番号を指定することができ、この場合、ＣＲＥＡＭゲートウェイ１３８は、リースを確認又は拒絶する。

ＣＲＥＡＭローカルホスト１０５はまた、何れのポート番号も指定しないことが可能であり、この場合、ＣＲＥＡＭゲートウェイ１３８は、ポート番号を指定し、リースを確認する。

ポートリース処理の性質により、ＴＣＰタイムアウト後、再びリースに対してポートが利用可能であり、これは、ＴＣＰ接続の所望されない再接続を回避するのに効果的である。

ピアを解消する例は、以下の通りである。ＣＲＥＡＭローカルホスト１０５は、登録要求内に含まれるテーブルを利用するか、及び／又は、ピアがインターネット又はローカルネットワーク内に存在するか判断するため、ＲＥＳＯＬＶＥ＿ＰＥＥＲ＿ＲＥＱＵＥＳＴ関数を利用する。

選択されたリソースを解放する例は、以下の通りである。登録されているＣＲＥＡＭローカルホスト１０５は、ＣＲＥＡＭゲートウェイ１３８にマッピングに関するリースされたアドレス又はポートを規定することにより、１以上のアドレス及びポートマッピングを解放するよう要求することができる。さらに、すべてのリソースは、登録解除確認後に解放される。

一例となるメソッド定義
以下で使用される定義は、以下の通りである。

ホスト ＩＰアドレスを有する任意の装置
ＣＲＥＡＭローカルホスト ＣＲＥＡＭプロトコルをサポートするホスト
ＣＲＥＡＭゲートウェイ ＣＲＥＡＭプロトコルをサポートするゲートウェイ
リモートホスト パブリックインターネット上のホスト
ローカルホスト プライベートネットワーク上のプライベート領域内のＩＰアドレスを有するホスト
ローカルアドレス プライベート領域内のＩＰアドレス
パブリックアドレス インターネットのパブリック領域内のＩＰアドレス
以下で使用される略語は、以下の通りである。

ＣＲＥＡＭ クライアントにより要求される外部アドレスマッピング（Ｃｌｉｅｎｔ Ｒｅｑｕｅｓｔｅｄ Ｅｘｔｅｒｎａｌ Ａｄｄｒｅｓｓ Ｍａｐｐｉｎｇ）
ＡＬＧ アプリケーションレベルゲートウェイ（Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ）
ＮＡＴ ネットワークアドレス変換（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）
ＮＡＰＴ ネットワークアドレスポート変換（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）
全体的な記号法は、以下の通りである。シンタックスについては、以下の記号法が使用される。各パラメータは、以下のように定義される。

全体的なパケットの説明：

この記号法を用いて、パケット部分ａは、以下のシンタックスを有する。

Ｌｅｎｇｔｈ１は、所定の固定長である（例えば、０ｘ０２など）。Ｖａｌｕｅ１は、所定の固定値である（例えば、０ｘ０１など）。ネームＮａｍｅ１は、パケットコンテンツに依存する（例えば、Ｍｙ１ｓｔＶａｒｉａｂｌｅなど）。この情報を利用して、先頭の２バイトである、バイト０と１は、固定値（０ｘ０１）と固定長（０ｘ０２）を有する変数Ｍｙ１ｓｔＶａｒｉａｂｌｅを有する。

第１記号例：

Ｌｅｎｇｔｈ２は、所定の固定長である（例えば、０ｘ０４など）。Ｖａｌｕｅ２は、ブラケットにより識別されるような変数である（例えば、文字列の文字数など）。ネームＮａｍｅ２は、パケットコンテンツに依存する（例えば、ＬｅｎｇｔｈＯｆＮａｍｅなど）。この情報を利用して、バイト２〜５は、固定長（０ｘ０４）の値である＃ＣｈａｒｓＳｔｒｉｎｇを有する変数ＬｅｎｇｔｈＯｆＮａｍｅを有する。

第２記号例：

Ｖａｌｕｅ２は、所定の変数であり、この場合は、変数Ｎａｍｅ２（「ＬｅｎｇｔｈＯｆＮａｍｅ」と前に名付けられた文字列の長さを規定する）であり、これはブラケットにより示される。Ｖａｌｕｅ３は値であり、長さに依存する（例えば、Ｖａｌｕｅ２の文字を有する文字列など）。Ｎａｍｅ３は、パラメータの名前を表す。ネームＮａｍｅ３は、パケットコンテンツに依存する（例えば、Ｌｏｃａｌ ｈｏｓｔＮａｍｅなど）。この情報を利用して、バイト６〜（＃ＣｈａｒｓＳｔｒｉｎｇ＋５）は、＃ＣｈａｒｓＳｔｒｉｎｇ文字帳の変数Ｌｏｃａｌ ｈｏｓｔＮａｍｅを表す文字列を有する。

第３記号例：

Ｐａｒａｍｅｔｅｒ１は、所定のパラメータである（例えば、Ｖｅｒｓｉｏｎなど）。このパラメータは、自らの内部シンタックス及びセマンティックスを有する。％符号の間のパラメータは、当該パラメータが必須であることを示す。この情報を利用して、変数Ｌｏｃａｌ ｈｏｓｔＮａｍｅは、パラメータＶｅｒｓｉｏｎに続く。

第４記号例：

Ｐａｒａｍｅｔｅｒ２はまた、所定のパラメータである（例えば、Ａｄｄｒｅｓｓなど）。しかしながら、ブラケットは、当該パラメータが任意的なものであることを示す。この情報を利用して、Ｖｅｒｓｉｏｎパラメータは、Ａｄｄｒｅｓｓパラメータに続くことが可能である。

第５記号例：

全体的なパラメータ定義
ＣＲＥＡＭ内のすべてのパラメータは、以下の記号法を用いて定義される。

Ｔｙｐｅ：Ｔｙｐｅの値は、パラメータのタイプを規定する。正確な値は、パラメータのタイプに依存し、パラメータ定義中に指定される。

Ｌｅｎｇｔｈ：ｖａｌｕｅを含むバイト数を規定する。Ｖａｌｕｅは、実際のパラメータデータを有し、ｌｅｎｇｔｈは、タイプとコンテンツに依存する。

Ｖｅｒｓｉｏｎ（０ｘ００）：ｖｅｒｓｉｏｎフィールドは、ＣＲＥＡＭプロトコルのバージョンを特定する。

Ｖｅｒｓｉｏｎ：当該ＶＲＥＡＭプロトコルのバージョンを有する。現在、ｖｅｒｓｉｏｎ１のみが記載されている。トータルバージョンＴＬＶの長さは固定され、ＣＲＥＡＭプロトコルのすべてのバージョンについて不変とされるべきである。

Ａｄｄｒｅｓｓ（０ｘ０１）
ａｄｄｒｅｓｓフィールドは、アドレッシング情報を有する、以下のアドレスタイプがサポートされている。

ＩＰｖ４：

ＩＰｖ４ネットマスク：

ＩＰｖ６：

ＦＱＤＮ：

ＦＱＤＮは、終了文字が含まれないＡＳＣＩＩ文字列として表される。

Ｐｏｒｔ（０ｘ０２）：ｐｏｒｔフィールドは、１以上のＴＣＰ又はＵＤＰポートを有する。ｐｏｒｔパラメータ内で、Ｎｕｍｂｅｒ＿Ｏｆ＿Ｐｏｒｔｓフィールドは、含まれるポート数を指定する。Ｎｕｍｂｅｒ＿Ｏｆ＿Ｐｏｒｔｓの値は、Ｌｅｎｇｔｈフィールドから導出可能である。

ＩＰｖ４：

以下のＰｒｏｔｏｃｏｌの値がサポートされる。

Ｐｏｒｔ Ｍａｐｐｉｎｇ（０ｘ０３）：
ｐｏｒｔ ｍａｐｐｉｎｇパラメータは、ローカルポートと外部ポートの間のマッピングを有する。ポートマッピングパラメータ内において、Ｎｕｍｂｅｒ＿Ｏｆ＿Ｐｏｒｔ＿Ｍａｐｐｉｎｇｓフィールドは、含まれるポートマッピング数を指定する。Ｎｕｍｂｅｒ＿Ｏｆ＿Ｐｏｒｔ＿Ｍａｐｐｉｎｇｓの値は、Ｌｅｎｇｔｈフィールドから導出可能である。

ＩＰｖ４：

以下の状態コードがサポートされる。

Ｐｒｏｔｏｃｏｌフィールドに対してサポートされる値は、Ｐｏｒｔ ＭａｐｐｉｎｇのＰｒｏｔｏｃｏｌの値（０ｘ０３）に関して上記テーブルに規定されている。

Ｌｏｃａｌ ｈｏｓｔＩＤ（０ｘ０４）：
Ｌｏｃａｌ ｈｏｓｔＩＤパラメータは、ＣＲＥＡＭローカルホストＩＤを指定する。Ｌｏｃａｌ ｈｏｓｔＩＤは、ＣＲＥＡＭローカルホストを区別するのにＣＲＥＡＭゲートウェイにより使用される。

ＬｅａｓｅＩＤ（０ｘ０５）：
ＬｅａｓｅＩＤパラメータは、ＣＲＥＡＭリースＩＤを指定する。ＬｅａｓｅＩＤは、ＣＲＥＡＭバインドを区別するのにＣＲＥＡＭローカルホストとＣＲＥＡＭゲートウェイにより使用される。

Ｌｏｃａｌ Ｓｕｂｎｅｔ Ｌｉｓｔ（０ｘ０６）：
Ｌｏｃａｌ Ｓｕｂｎｅｔ Ｌｉｓｔは、ローカルサブネット群の定義を含む。

Ｍｅｓｓａｇｅ Ｔｙｐｅ（０ｘ１０）：
メッセージタイプは、メッセージのタイプを規定する。メッセージに応じて、これは、パケットのコンテンツを規定し、及び／又は以前に送信されたパケットを表す。

以下のメッセージタイプが規定される。

メッセージタイプＴＬＶの長さは固定され、ＣＲＥＡＭバージョンのすべてに対し不変とされるべきである。

ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、ＣＲＥＡＭゲートウェイにおいてＣＲＥＡＭローカルホストを登録するのに使用される。

Ｓｙｎｔａｘ：

セマンティックスは以下の通りである。

Ｖｅｒｓｉｏｎ：上記バージョン情報を参照されたい。

Ｍｅｓｓａｇｅ＿Ｔｙｐｅ：メッセージタイプは、ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴメッセージを示すべきである。

Ｌｅｎｇｔｈ：パッケージのトータルの残りの長さは、本バージョンでは０ｘ００に等しい。

登録するため、ＣＲＥＡＭゲートウェイは、使用されているＣＲＥＡＭプロトコルのタイプとメッセージのコンテンツを知っているべきである（ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴ）。ＣＲＥＡＭローカルホストは、ローカルホストが登録されていないとき、ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴを送信することが許可されるにすぎない。

Ｂｅｈａｖｉｏｒ：
ＣＲＥＡＭゲートウェイは、ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭ又はＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮメッセージにより応答すべきである。

ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、ＣＲＥＡＭローカルホストの登録を確認するのに使用される。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョンを規定する。

Ｍｅｓｓａｇｅ Ｔｙｐｅ：メッセージタイプを規定する。指定されるメッセージは、ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭであるべきである。

Ｌｅｎｇｔｈ：このメッセージの残りのトータルの長さを規定する。

Ｌｏｃａｌ ｈｏｓｔＩＤ：Ｃｒｅａｍゲートウェイにより割り当てられるものとしてＬｏｃａｌ ｈｏｓｔＩＤを規定する。この値は、ＣＲＥＡＭローカルホストとＣＲＥＡＭゲートウェイの間のさらなる通信に使用されるべきである。

Ｌｏｃａｌ Ｓｕｂｎｅｔ Ｌｉｓｔ：アドレス変換なしに到達可能なローカルサブネットを規定する。定義の具体例については上記を参照されたい。

ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭメッセージを利用することにより、ＣＲＥＡＭゲートウェイは、ＣＲＥＡＭローカルホストのＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴを認める。当該メッセージ内において、ＣＲＥＡＭゲートウェイとＣＲＥＡＭローカルホストの間のさらなる通信に利用されるべきＬｏｃａｌ ｈｏｓｔＩＤが割り当てられる。

また、メッセージ内において、ローカルサブネットのリストが規定される。ＣＲＥＡＭローカルホストは、このリストを用いて、通信のためインバウンド／アウトバウンドアクセスリクエストがなされるべきか決定すべきである。このリストの内部に少なくともＣＲＥＡＭローカルホストのローカルサブネットが含まれる。

Ｂｅｈａｖｉｏｒ：
このメッセージを受信することにより、ローカルホストは、それがＣＲＥＡＭローカルホストとして登録解除されることを所望する場合、登録解除リクエストを送信すべきである。さらに、このメッセージを受信した後、定期的なポールがこのＣＲＥＡＭローカルホストの寿命をチェックすることが期待できる。

ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＩＮＤＩＣＡＴＩＯＮ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、登録されているＣＲＥＡＭローカルホストの寿命をポールするのに使用される。さらに、ローカルサブネットリストの更新が、このメッセージに含めることができる。

Ｓｙｎｔａｘ：

Ｓｅｍａｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョンを規定する。

Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＩＮＤＩＣＡＴＩＯＮとなるべきこのメッセージのメッセージタイプを規定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：このＣＲＥＡＭローカルホストに以前に割り当てられたＬｏｃａｌ ｈｏｓｔＩＤと同じ値を有すべきＬｏｃａｌ ｈｏｓｔＩＤを有する。

Ｌｏｃａｌ Ｓｕｂｎｅｔ Ｌｉｓｔ：任意的なパラメータ。含まれる場合には、アドレス変換を必要としない新たなローカルサブネットリストを含む。含まれない場合、古いリストが存在する。

Ｂｅｈａｖｉｏｒ：
Ｌｏｃａｌ ｈｏｓｔＩＤが登録中に受信したものと同じであり、ローカルホストがまだ登録されている場合、ＣＲＥＡＭローカルホストは、ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥメッセージにより当該メッセージに応答すべきである。Ｌｏｃａｌ Ｓｕｂｎｅｔ Ｌｉｓｔパラメータが含まれる場合、この新たなリストは受信時にアクティブとなる。しかしながら、追加されたローカルサブネット内のすでに開始されたホストとの通信は、アドレス変換されたままである。競争状態の存在により、ＣＲＥＡＭローカルホストが新たなローカルサブネットを認識するまでに、ローカルホストの２つの間の通信が存在することが発生しうる。この場合、当該通信は、効果的にアドレス変換として留まるようにしてもよい。これは、Ｂｅｒｋｌｅｙソケットインタフェースのセマンティックスとの決別を回避するのに実行される。

ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、登録されているローカルホストの寿命のポール成功を認めるのに使用される。このメッセージを送信することにより、ＣＲＥＡＭローカルホストは、それが登録されていることを認める。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ｂｅｈａｖｉｏｒ：
ローカルホストは、適切なＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＩＮＤＩＣＡＴＩＯＮが受信された場合、ＥＸＴＥＮＤ＿ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥを送信すべきである。

ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、ＣＲＥＡＭゲートウェイにおいて登録解除するためＣＲＥＡＭローカルホストにより使用される。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴであるべきメッセージのタイプを特定する
Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
ＣＲＥＡＭローカルホストは、このメッセージを送信するため登録されるべきである。対応するＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭ又はＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮが受信されるまで、ＣＲＥＡＭローカルホストは登録されたままである。

Ｂｅｈａｖｉｏｒ：
このメッセージは、ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭメッセージにより認められるか、あるいは、拒絶理由を規定するＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮにより拒絶されるべきである。

ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴを認める。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＣＯＮＦＩＲＭであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
このメッセージを受信した後、ＣＲＥＡＭローカルホストは、もはや登録されず、ＣＲＥＡＭローカルホストがＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴを送信したと仮定すると、このローカルホストのすべてのリースが削除される（存在する場合）。

Ｂｅｈａｖｉｏｒ：
ＤＥ−ＲＥＧＩＳＴＲＡＴＩＯＮ＿ＲＥＱＵＥＳＴを送信せずこのメッセージが受信される場合、ローカルホストは、ＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮを送信すべきである。

ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴ
Ｄｅｓｃｒｉｐｔｉｏｎ：
登録されたＣＲＥＡＭローカルホストは、このメッセージを利用して、インバウンドアクセスポートマッピングを要求する。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ａｄｄｒｅｓｓ（ローカル）：これは、インバウンドアクセスが要求されるローカルネットワーク内のホストのローカルアドレスである。このパラメータは任意的なものであり、含まれない場合、ＣＲＥＡＭローカルホストのローカルアドレスが、ＣＲＥＡＭゲートウェイにより仮定される。

Ｎｏｔｅ：異なるローカルアドレスを指定することによって、ＣＲＥＡＭローカルホストは、他のローカルホストのアドレスマッピングを要求することができる。しかしながら、ＣＲＥＡＭローカルホストは、リースの寿命の責任を維持する。

Ｐｏｒｔ（ローカル）：これは、マッピングが要求されるローカルポートである。このパラメータは、任意的なものである。このパラメータが含まれない場合、１つのマッピングがＣＲＥＡＭゲートウェイにより選択される。

インバウンドポートマッピングを要求することにより、ホストは（ＣＲＥＡＭローカルホスト又はローカルアドレスにより指定されるような他のローカルホスト）、ローカルペイロード内のアドレス情報のアドレス変換の責任を維持する。従って、ＣＲＥＡＭローカルホスト以外のホストに対するインバウンドアクセスを要求すると、警告がとられるべきである。このような場合、ペイロードのＩＰアドレス情報のないプロトコル又はＮＡＴ ＡＬＧなどの技術が利用されるべきである。

インバウンドアクセスリクエストに対して、ＣＲＥＡＭゲートウェイは、ＣＲＥＡＭゲートウェイのポートｘから意図するホストにおけるポートｘへのマッピングを意味する一対一マッピングを常に割り当てる（ただし、ｘは同一のものである）。

ポート番号が含まれているとき、ＣＲＥＡＭゲートウェイは、これを周知のポート（例えば、ｈｔｔｐについては８０など）としてスレッドし、外部の同地宇野ポート番号を割り当てようとする。このポートは一度しか割当て可能でないということに留意されたい。

Ｂｅｈａｖｉｏｒ：
ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴは、ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭ又はＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮにより応答されるべきである。

ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭ
Ｄｅｓｃｒｉｐｔｉｏｎ：
これは、ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴに対する応答である。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
ＬＥＡＳＥ ＩＤ：この特定のポートマッピング群に割り当てられたリースＩＤ。このＩＤはさらなる参照に利用されるべきである。

Ａｄｄｒｅｓｓ：外部ネットワークとの通信に利用されるアドレス。これは、インターネットのパブリック領域内で有効なアドレスである。

Ｐｏｒｔ Ｍａｐｐｉｎｇ：生成されるポートマッピング群
ポートマッピング群に少なくとも１つの有効なマッピングが含まれている場合、Ｌｅａｓｅ ＩＤは、マッピングがもはや必要とされない場合に、このマッピングを解放するのに利用されるべきである。有効なマッピングが含まれていない場合、Ｌｅａｓｅ ＩＤを無視することができる。有効なマッピングは、成功する状態コードによるマッピングとして規定される。状態コードがすでに利用可能な値のマッピングを規定する場合、このマッピングは、ＣＲＥＡＭ以外の方法（ＮＡＴ ＡＬＧ又はＵＰｎＰなど）を用いて生成されたものである。

Ｂｅｈａｖｉｏｒ：
Ｌｅａｓｅ ＩＤにより識別されるようなすべてのマッピング群が、ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴにより明示的に解放されるべきである。

ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭが当該ＣＲＥＡＭローカルホストによるまず対応するＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴを送信することなく受信される場合、ＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮが送信されるべきである。

ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴ
Ｄｅｓｃｒｉｐｔｉｏｎ：
登録されているＣＲＥＡＭローカルホストは、このメッセージを利用してアウトバウンドアクセスポートマッピングを要求する。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｍｅｓｓａｇｅ＿Ｔｙｐｅ：ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴであるべきメッセージのタイプを特定する。

Ｍｅａａｓｇｅ ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ａｄｄｒｅｓｓ（ローカル）：任意的なマッピングがリクエストされるホストのローカルアドレス。このパラメータが含まれていない場合、マッピングがＣＲＥＡＭローカルホストを要求するため生成される。

Ｐｏｒｔ（ローカル）：マッピングが要求されるローカルポート番号群
Ａｄｄｒｅｓｓ（リモートホスト）：任意的なリモートホストのアドレス。このパラメータが含まれている場合、マッピングされるポート群の通信は、与えられたアドレスによってのみ実行可能である。

Ｐｏｒｔ（リモートホスト）：任意的な通信が制限されるリモートポート番号群。このパラメータが含まれる場合、通信は規定されたポート番号に制限される。

Ｂｅｈａｖｉｏｒ：
リモートアドレス（ＩＰアドレス又はＦＱＤＮ）が指定されている場合、通信は、当該リモートアドレスのみを有するリモートホストとの通信に制限される。

リモートポート（ポート群）が指定されている場合（例えば、｛８０，８０８０｝など）、通信は、指定されたポート群の中のリモートホストのポートとの通信に制限される。リモートアドレスとリモートポートの組み合わせを用いて、ある範囲のポートと指定されたリモートホストの通信に対して制限が可能である。

ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭ
Ｄｅｓｃｒｉｐｔｉｏｎ：
これは、ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴに対する応答である。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ｌｅａｓｅ ＩＤ：この特定のポートマッピング群に割り当てられたリースＩＤ。このＩＤはさらなる参照に利用されるべきである。

Ａｄｄｒｅｓｓ：外部ネットワークとの通信に利用されるアドレス。これは、インターネットのパブリック領域内で有効なアドレスである。

Ｐｏｒｔ Ｍａｐｐｉｎｇ：生成されるポートマッピング群
Ｂｅｈａｖｉｏｒ：
ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴにより明示的に解放されるべきＬｅａｓｅ ＩＤにより識別されるようなすべてのマッピング群
ＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＣＯＮＦＩＲＭが当該ＣＲＥＡＭローカルホストによるまず対応するＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴを送信することなく受信される場合、ＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮが送信されるべきである。

ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴ
Ｄｅｓｃｒｉｐｔｉｏｎ：
登録されたＣＲＥＡＭローカルホストは、このメッセージを利用して、ＩＮＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳ又はＯＵＴＢＯＵＮＤ＿ＡＣＣＥＳＳ＿ＲＥＱＵＥＳＴにより生成されるポートマッピング群を解放する。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ｌｅａｓｅ ＩＤ：解放されるべきこの特定のポートマッピング群に割り当てられたリースＩＤ
Ｂｅｈａｖｉｏｒ：
ＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴを送信した後、ＣＲＥＡＭローカルホストは、送信用にはポートマッピングを使用することをもはや許されない。対応するＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭの受信後、リースＩＤに関連するパスを利用して、メッセージがもはや受信されないことが保証される。

ＣＲＥＡＭゲートウェイが登録されていないＣＲＥＡＭローカルホストからＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴを受信し、又は未知のＬｅａｓｅ ＩＤを有する場合、対応するＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮが送信される。

ＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、成功したＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴに対する応答であり、特定されたポートマッピング群が解放されることを確認する。

Ｓｙｎｔａｘ：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｌｏｃａｌ ｈｏｓｔＩＤ：登録中に割り当てられるＣＲＥＡＭローカルホストのＩＤ
Ｌｅａｓｅ ＩＤ：解放されたポートマッピング群のリースＩＤ
Ｂｅｈａｖｉｏｒ：
ＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭを受信した後、関連するポートマッピングはもはや存在しない。従って、何れのパケットも、特定されたポートマッピングに関するパスによっては到達しない。ＣＲＥＡＭローカルホストが対応するＦＲＥＥ＿ＬＥＡＳＥ＿ＲＥＱＵＥＳＴを送信せず、又は、未知のＬｏｃａｌ ｈｏｓｔＩＤ又はＬｅａｓｅ ＩＤを有することなく、ＦＲＥＥ＿ＬＥＡＳＥ＿ＣＯＮＦＩＲＭを受信した場合、対応するＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮが送信されるべきである。

ＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮ
Ｄｅｓｃｒｉｐｔｉｏｎ：
このメッセージは、エラーを示すものであり、ＣＲＥＡＭローカルホストとＣＲＥＡＭゲートウェイにより送信することができる。

Ｓｙｎｔａｘ：

推奨されるエラーコードのテーブル：

Ｓｅｍａｎｔｉｃｓ：
Ｖｅｒｓｉｏｎ：ＣＲＥＡＭプロトコルのバージョン
Ｍｅｓｓａｇｅ Ｔｙｐｅ：ＥＲＲＯＲ＿ＩＮＤＩＣＡＴＩＯＮであるべきメッセージのタイプを特定する。

Ｌｅｎｇｔｈ：バイト単位によるこのメッセージの残りのトータルの長さ
Ｅｒｒｏｒ＿Ｒｅｓｐｏｎｓｅ＿Ｃｏｄｅ：エラー応答コード。定義のための上のテーブルを参照されたい。

Ｌｏｃａｌ ｈｏｓｔＩＤ：任意的な登録中に割り当てられるようなＣＲＥＡＭローカルホストのＩＤ。このメッセージがＣＲＥＡＭゲートウェイにより送信される場合、これは、わかっている場合には、アクションを引き起こしたＣＲＥＡＭローカルホストを特定する。このメッセージがＣＲＥＡＭローカルホストにより送信される場合、割り当てられていれば、これはローカルホストを特定する
Ｐａｒａｍｅｔｅｒ＿Ｔｙｐｅ：任意的なものであり、エラーを生じさせたパラメータのタイプを特定する。

Ｂｅｈａｖｉｏｒ：
このメッセージはエラーを示す。

ここで図示及び説明された実施例及び変形は、本発明の原理を単に例示したものであり、本発明の趣旨及び範囲から逸脱することなく、様々な変更が当業者により実現可能であるということは、理解されるべきである。

図１は、本発明の効果的な実施例により通信するプライベート及びパブリック領域を示す。 図２は、本発明の効果的な実施例によるインターネット上のホストとプライベート領域の社内ホストとの間の通信中に、ヘッダアドレス情報がどのように変更されるか記述するのに利用されるテーブルである。 図３は、本発明の効果的な実施例によるクライアントにより要求された外部アドレスマッピング（ＣＲＥＡＭ）ローカルホストの登録のためのオブジェクト相互作用図を示す。 図４は、本発明の効果的な実施例によるＣＲＥＡＭソケットの生成のための一例となるオブジェクト相互作用図を示す。 図５は、本発明の効果的な実施例によるＣＲＥＡＭソケットをバインドするための一例となるオブジェクト相互作用図を示す。 図６は、本発明の効果的な実施例によるＣＲＥＡＭソケットと接続するための一例となるオブジェクト相互作用図を示す。 図７は、本発明の効果的な実施例によるデータを受信するための一例となるオブジェクト相互作用図を示す。 図８は、本発明の効果的な実施例によるｓｅｎｄ（）を用いてデータを送信するための一例となるオブジェクト相互作用図を示す。 図９は、本発明の効果的な実施例によるｓｅｎｄｔｏ（）を用いてデータを送信するための一例となるオブジェクト相互作用図を示す。 図１０は、本発明の効果的な実施例によるクライアントアプリケーションの使用ケースのための一例となるオブジェクト相互作用図を示す。 図１１は、本発明の効果的な実施例によるサーバアプリケーションの使用ケースのための一例となるオブジェクト相互作用図を示す。

Claims (22)

1. クライアントにより要求される外部アドレスマッピングのための方法であって、
   ローカルホストからパブリックネットワークへのアクセスに対するリクエストを受信するステップと、
   前記パブリックネットワークへのアクセスに利用されるべきパブリックアドレスを決定するステップと、
   前記ローカルホストに対応するローカルアドレスを前記パブリックアドレスにマッピングするステップと、
   前記パブリックアドレスを前記ローカルホストに返すステップと、
   を有することを特徴とする方法。
2. 請求項１記載の方法であって、
   前記リクエストされるアクセスは、前記パブリックネットワークから前記ローカルホストへのものであることを特徴とする方法。
3. 請求項１記載の方法であって、
   前記リクエストされるアクセスは、前記ローカルホストから前記パブリックネットワークへのものであることを特徴とする方法。
4. 請求項１記載の方法であって、
   前記パブリックアドレスは、前記パブリックネットワーク上のリモートホストに対応するアドレスであることを特徴とする方法。
5. 請求項１記載の方法であって、さらに、
   前記アクセスに利用されるものであって、１以上のヘッダと１以上のペイロードエリアを有するパケットを生成するステップと、
   前記１以上のペイロードエリアの与えられた１つのペイロードエリアに少なくとも前記パブリックアドレスを配置するステップと、
   を有することを特徴とする方法。
6. 請求項５記載の方法であって、
   前記１以上のヘッダと前記１以上のペイロードエリアの１以上が暗号化されることを特徴とする方法。
7. 請求項１記載の方法であって、
   前記パブリックネットワークは、１以上のアドレス群により規定されることを特徴とする方法。
8. 請求項７記載の方法であって、
   前記１以上のアドレス群は、１以上のサブネットリストにより規定されることを特徴とする方法。
9. 請求項１記載の方法であって、
   前記パブリックアドレスを決定するステップはさらに、パブリックポートを決定するステップを有し、
   前記マッピングするステップはさらに、前記パブリックポートを前記ローカルホストにマッピングするステップを有し、
   前記パブリックアドレスを返すステップはさらに、前記パブリックポートを前記ローカルホストに返すステップを有する、
   ことを特徴とする方法。
10. 請求項１記載の方法であって、
    前記パブリックネットワークへのアクセスをリクエストするステップはさらに、該アクセス中に使用されるべきポートをリクエストするステップを有し、
    前記マッピングするステップはさらに、前記リクエストされたポートを前記ローカルホストにマッピングするステップを有し、
    前記パブリックアドレスを返すステップはさらに、前記リクエストされたポートを前記ローカルホストに返すステップを有する、
    ことを特徴とする方法。
11. 請求項１記載の方法であって、
    前記マッピングするステップはさらに、前記ローカルホストの識別を決定するステップと、前記識別を前記ローカルホストに返すステップを有することを特徴とする方法。
12. 請求項１記載の方法であって、
    前記マッピングするステップはさらに、前記ローカルホストのローカルサブネットリストを決定するステップと、前記ローカルサブネットリストを前記ローカルホストに返すステップを有することを特徴とする方法。
13. 請求項１２記載の方法であって、
    前記ローカルサブネットリストは、ローカルネットワークを規定し、これにより、前記ローカルネットワークと前記パブリックネットワークとを区別することを特徴とする方法。
14. 請求項１記載の方法であって、
    前記アクセスは、前記ローカルホストから前記パブリックネットワークへのものであり、
    前記アクセスは、前記ローカルアドレスとローカルポートを有し、
    当該方法はさらに、
    前記ローカルアドレスが前記パブリックアドレスとなるよう変更するステップと、
    必要に応じて、前記ローカルポートをパブリックホストに対応するパブリックポートとなるよう変更するステップと、
    を有する、
    ことを特徴とする方法。
15. 請求項１記載の方法であって、
    前記アクセスは、前記パブリックネットワークから前記ローカルホストへのものであり、
    前記アクセスは、第２のパブリックアドレスとパブリックポートを有し、
    当該方法はさらに、
    前記第２のパブリックアドレスが前記ローカルアドレスとなるよう変更するステップと、
    必要に応じて、前記パブリックポートを前記ローカルホストに対応するローカルポートとなるよう変更するステップと、
    を有する、
    ことを特徴とする方法。
16. クライアントにより要求される外部アドレスマッピングのためのシステムであって、
    メモリと、
    前記メモリに結合され、ローカルホストからパブリックネットワークへのアクセスに対するリクエストを受信し、前記パブリックネットワークへのアクセスに利用されるべきパブリックアドレスを決定し、前記ローカルホストに対応するローカルアドレスを前記パブリックアドレスにマッピングし、前記パブリックアドレスを前記ローカルホストに返すよう動作する少なくとも１つのプロセッサと、
    を有することを特徴とするシステム。
17. クライアントにより要求される外部アドレスマッピングのための方法であって、
    アウトバウンドアクセスがローカルネットワーク又はパブリックネットワークへのものであるか判断するステップと、
    前記アウトバウンドアクセスがパブリックネットワークへのものであるとき、前記パブリックネットワークへのアクセスをリクエストし、前記リクエストに応答して、パブリック情報を受信し、前記アウトバウンドアクセスに対して生成された１以上のパケットの１以上のペイロード部分に前記パブリック情報を配置するステップと、
    を有することを特徴とする方法。
18. 請求項１７記載の方法であって、
    前記パブリック情報は、パブリックアドレスを有することを特徴とする方法。
19. 請求項１７記載の方法であって、
    前記パブリック情報は、パブリックポートを有することを特徴とする方法。
20. 請求項１７記載の方法であって、
    前記パブリックネットワークへのアクセスをリクエストするステップはさらに、ローカルポートをリクエストするステップを有し、
    前記パブリック情報をペイロードに配置するステップはさらに、前記リクエストされたローカルポートを前記ペイロードに配置するステップを有する、
    ことを特徴とする方法。
21. 請求項１７記載の方法であって、さらに、
    前記パブリックネットワークへのアウトバウンドアクセスを実行するステップを有し、
    前記アウトバウンドアクセスは、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）９５９、Ｈ．３２３ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）規格、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２５４３、ＲＳＩＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２２０５、ＩＰｓｅｃ−ＥＳＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）ＲＦＣ２４０２、ｋｅｒｂｅｒｏｓ４、ｋｅｒｂｅｒｏｓ５，ｔｅｌｎｅｔＲＦＣ８５４、ｒｌｏｇｉｎＲＦＣ１２８２、のプロトコルの１以上を利用する、
    ことを特徴とする方法。
22. 請求項１７記載の方法であって、
    アプリケーションが、判断、リクエスト、受信及び配置するステップを実行し、ピア・ツー・ピアアプリケーション、アドレスマッピングの維持を要求するアプリケーション、リモートシェル（ＲＳＨ）アプリケーション、Ｘウィンドウシステムアプリケーション、Ｘ−ｔｅｒｍアプリケーションの１以上であることを特徴とする方法。

Images