JP2008085470A - Ｉｐアプリケーションサービス提供システム - Google Patents

Abstract

【課題】ゲートウェイ装置の有無を意識せずサービスを提供する。
【解決手段】アウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽されかつ内部ネットワークに属する内部ノードと、外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信でのインバウンド通信も可能にするＩＰアプリケーションサービス提供方法であって；ゲートウェイ装置配下の内部ノードから外部ネットワーク上の接続支援装置に対し制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信するステップと；接続支援装置から内部ノードに対し制御チャネルを通して外部ノード対応の接続先アドレス及びポートを通知するステップと；通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンするステップを備える。
【選択図】図１４

Description

本発明は、ＩＰ(Internet Protocol)アプリケーションサービス提供システムに関し、
特にネットワークアドレス変換装置またはファイアウォール（ＮＡＴ／ＦＷ）等のゲートウェイ装置を経由してインターネット等のＩＰネットワークに接続されたノードが、ＮＡＴ／ＦＷの有無状態に拠らず容易にＩＰアプリケーション通信を可能とする接続支援技術に関する。

ＩＰｖ４ネットワークにおいては、グローバルＩＰアドレス節約の観点からネットワークアドレス変換装置（ＮＡＴ:Network Address Translation）が広く用いられている。ＮＡＴ、特にＮＡＰＴ（Network Address Port Translation）と呼ばれる装置では、企業内／ホームネットワークのプライベートアドレス及び送信元ポートをＮＡＰＴのグローバルアドレス及び送信元ポートに変換することにより（図１参照）、複数の内部ノードＡから外部ネットワークＯＮＷへのアクセスを可能としている。

また、ＩＰｖ６ネットワークにおいては、アドレス枯渇の問題は無くなるものの、セキュリティの観点から企業内／ホームネットワークを外部ネットワークＯＮＷから隠蔽し、内部から外部向け通信のレスポンスのみの透過を許容するファイアウォール（ＦＷ）機能（図２参照）は引き続き使用されるものと考えられる。

このようにＮＡＴ／ＦＷは、内部から外部トリガの通信（アウトバウンド通信）には有効である一方、外部から内部トリガの通信（インバウンド通信）においては、ＮＡＴ／ＦＷに通信を許可するエントリが存在しないため、ノードまでパケットが到達せず、ＮＡＴ／ＦＷ配下のノードにおいてサーバアプリケーションやＰ２Ｐ（Peer-to-Peer）アプリケーションを動作させる場合に大きな障壁となる（図３参照）。こうした問題は、一般に「ＮＡＴ越え問題」と呼ばれる。

これを解決する従来技術としては、（１）ＮＡＴに静的なエントリを設定（図４中のその１参照）、（２）ＵＰｎＰ（Universal Plug and Play）を用いてプロトコルによりエ
ントリを制御（図４中のその２参照）、（３）変換後のＮＡＴエントリを予測して擬似的にインバウンド通信を許可するエントリを作成（ＵＤＰ(User Datagram Protocol) Ｈｏｌｅ Ｐｕｎｃｈｉｎｇ，図４中のその３参照）等が考えられる。

従来技術（１）は、一般にＳｔａｔｉｃ ＮＡＴと呼ばれるもので、例えば、１９２．１６８．１．１：８０を１．１．１．１：８０に一意に変換するよう静的にＮＡＴエントリを設定することにより、外部ノードＢからはあたかもグローバルアドレス１．１．１．１にＷｅｂサーバが公開されているように見える。実際には、ＮＡＴ配下のプライベートアドレス１９２．１６８．１．１においてＷｅｂサーバが動作している。

従来技術（２）は、Ｓｔａｔｉｃ ＮＡＴを自動化したもので、ノードとＮＡＴ間でＵＰｎＰプロトコルを動作させ、ＡｄｄＰｏｒｔＭａｐｐｉｎｇメッセージにより、１９２．１６８．１．１：８０を１．１．１．１：８０にマッピングするように、ノードからＮＡＴを制御することにより、Ｓｔａｔｉｃ ＮＡＴと同様のエントリが設定される。

従来技術（３）は、ＮＡＴの内部ノードＡが変換後のグローバルＩＰアドレス：ポートをＲＦＣ３４８９で規定されるＳＴＵＮ（Simple Traversal of UDP through NATs）プロトコル（図９，図１０参照）等を用いて予測し、ダミーパケットによりＮＡＴエントリを
生成した上で相手のノードに通知して、外部ノードＢが変換後のＩＰアドレス：ポートに対して接続を開始することにより、内部ノードＡとの通信を可能にする、というものである。

しかし、これらの従来技術には、次のような問題がある。従来技術（１）では、アプリケーション毎にＮＡＴに対する詳細な設定や知識が必要である、つまり作業工数が大である。

従来技術（２）では、ノード及びＮＡＴともに同一プロトコルのサポートが必要であり、またノードとＮＡＴが同一セグメントでない場合（つまり、ＮＡＴが多段になっている場合や、ＮＡＴまでの経路にルータが存在する場合）には、ＵＰｎＰパケット（マルチキャストパケット）がＮＡＴまで到達できず制御不可能である。

従来技術（３）では、タイプによって適用できないＮＡＴが存在すること（後述）や、特にＴＣＰ（Transmission Control Protocol）通信の場合にはＮＡＴエントリ自体は作
成できてもインバウンドのＴＣＰ ＳＹＮ（接続要求）パケットをフィルタ（ステートフルインスペクション機能，図１３参照）してしまうケースが多く、環境によっては適用できない。

ＮＡＴは、大別すると、Ｃｏｎｅ ＮＡＴとＳｙｍｍｅｔｒｉｃ ＮＡＴとの２種類があり、さらにＣｏｎｅ ＮＡＴは３種類に分けられる（図５〜図８参照）が、Ｓｙｍｍｅｔｒｉｃ ＮＡＴの場合、宛先毎に別々のグローバルポートが割り当てられるため、ＳＴＵＮ及びＵＤＰ Ｈｏｌｅ Ｐｕｎｃｈｉｎｇのように変換後ポートを予測する技術では対応することができない（図１１，図１２参照）。

また、従来技術は、いずれも、如何にしてＮＡＴ／ＦＷの外部から内部に対してインバゥンド通信を開始しようとするかに着目しているため、任意のタイミングで通信ができない（つまり、ＮＡＴ配下からのアクションに同期を取らないと接続できない）場合があったり、ウェルノウンポートで提供されるサーバアプリケーションを動作させたい場合には、ノードやアプリケーション間でポート競合（グローバルポートの共有ができないため、同一グローバルポートにて複数アプリケーションの提供ができない）が発生する。

例えば、ＮＡＴ配下に２台のＷｅｂサーバを構築しようとしても、２台目のＷｅｂサーバはデフォルトの８０番ポートにて提供できない。正確には、Ｗｅｂサーバ自体は８０番ポートで動作しているのだが、１．１．１．１：８０へのマッピングがすでに使われてしまっているため、例えば、２台目のＷｅｂサーバ１９２．１６８．１．２：８０を外部に公開しようとすると、１．１．１．１：８１など８０番以外のポートにマッピングせざるを得ず、これは外部ノードＢからは予め別ポートで提供されていることを知っていて、かつ「ｈｔｔｐ：／／１．１．１．１：８１」等を入力しないと、Ｗｅｂページが閲覧できないことを意味する。８０番ポートで提供されている場合は、「ｈｔｔｐ：／／１．１．１．１」等ポート番号を省略することができる。

このように、ＮＡＴ／ＦＷが存在しない場合と比較すると、アプリケーション提供の制約が大きく、場合によってはＮＡＴ／ＦＷが存在するがためにアプリケーションの動作そのものを組み替える必要があるという課題がある。
特開２００５−２６０７１５号公報

本発明の課題は、ＮＡＴ／ＦＷなどのゲートウェイ装置の有無（介在状態）を意識せず
容易にＩＰアプリケーションサービスの提供を可能にする技術を提供することにある。

上記課題を解決するために、本発明のＩＰアプリケーションサービス提供システムは、内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供システムであって；
前記ゲートウェイ装置配下の前記内部ノードが、
前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
前記接続支援装置から前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と；
前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする手段とを備える。

本発明のＩＰアプリケーションサービス提供方法は、内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供方法であって；
前記ゲートウェイ装置配下の前記内部ノードから前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する第１のステップと；
前記接続支援装置から前記内部ノードに対し、前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートを通知する第２のステップと；
前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする第３のステップとを備える。

本発明によれば、ＮＡＴ／ＦＷなどのゲートウェイ装置の有無を意識せず（存在しても種類に拠らず、また任意のタイミングで）、ＩＰアプリケーションサービスの提供が可能となる。

本発明の他の課題、特徴及び利点は、図面及び特許請求の範囲とともに取り上げられる際に、以下に記載される明細書（実施の形態）を読むことにより明らかになるであろう。

以下、添付図面を参照して、本発明についてさらに詳細に説明する。図面には本発明の好ましい実施形態が示されている。しかし、本発明は、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本明細書の開示が徹底的かつ完全となり、当業者に本発明の範囲を十分に伝えるように提供される。全体を通じて同様の番号は同様の要素を指す。

［ＩＰアプリケーションサービス提供システムの構成及び機能］
本発明の一実施の形態におけるＩＰアプリケーションサービス提供システムの構成を示す図１４を参照すると、このシステムは、企業内またはホームネットワークとしての内部ネットワーク（非公開ネットワーク）ＩＮＷからインターネットまたはアプリケーションサービスネットワークなどの外部ネットワーク（公開ネットワーク）ＯＮＷに対して、内
部から外部向けの通信（アウトバウンド通信）のみを許容するように設定されているゲートウェイ装置としてのネットワークアドレス変換装置ＮＡＴ（単に、ＮＡＴと記載することもある）を介するネットワーク形態において、ＮＡＴにより外部ネットワークＯＮＷから隠蔽された内部ノードＡと外部ノードＢ間での意図するＩＰアプリケーション通信での外部から内部向けへの通信（インバウンド通信）も可能とする接続支援を行う。なお、監視ポートについては、予めインバウンド通信が許容されているゲートウェイ装置もある。

このＩＰアプリケーションサービス提供システムにおいて、ネットワークアドレス変換装置ＮＡＴまたはファイアウォールＦＷ（ＮＡＴ／ＦＷ）などのゲートウェイ装置の有無（介在状態）を意識せず容易にＩＰアプリケーションサービスの提供を可能とするためには、次の３つの条件が必要となる。
条件１：ＮＡＴのタイプを問わずに「ＮＡＴ越え」が可能であること。
条件２：ＮＡＴの有無により、アプリケーションのプロトコル仕様が変わらないこと。
条件３：外部ノードＢより任意のタイミングで接続できること。

これらの条件を充足するために、このＩＰアプリケーションサービス提供システムにおいては、ノードＡ，Ｂ間のＩＰアプリケーション通信を外部ネットワーク（サービスネットワーク）ＯＮＷの接続支援装置ＣＳが仲介し、基本的に、次の３つの処理を実行する。

第１の処理（第１のステップ）：ＮＡＴ配下のノード（内部ノード）Ａから接続支援装置ＣＳに対し、制御パケットを定期送信する。つまり、制御チャネルパスのＮＡＴエントリを維持する。制御パケットは、ＮＡＴによってＩＰアドレス：ポートが変換され、接続支援装置ＣＳにおいて受信される（図４中の丸数字３参照）。

第２の処理（第２のステップ）：接続支援装置ＣＳは、外部ノードＢからの接続要求を受け、内部ノードＡに対し、上記制御チャネルを用いて、外部ノードＢの接続先ＩＰアドレス：ポートを通知する。このとき、制御チャネルパスのＮＡＴエントリが維持されていれば、任意のタイミングで通知可能である（図４中の丸数字４，５参照）。

第３の処理（第３のステップ）：内部ノードＡは、通知を受けた接続先ＩＰアドレス：ポートに対し、トランスポート層プロトコル（ＴＣＰ（Transmission Control Protocol
）／ＵＤＰ(User Datagram Protocol)）接続を開始、すなわちＩＰアプリケーションデータチャネルをアクティブにオープンする。ＮＡＴの内部から外部に対してトランスポート層プロトコル接続を開始しているため、ＮＡＴに拠らず接続可能であり、またトランスポート層接続の方向はアプリケーション固有の処理には依存しないため、アプリケーション共通のアプリケーションプログラムインタフェースＡＰＩとして定義することが可能である（図４中の丸数字７参照）。

このシステムにおいて、内部ノードＡ及びＮＡＴは内部ネットワークＩＮＷに存在し、接続支援装置ＣＳは外部ネットワークＯＮＷのプロバイダ提供のサーバに存在する。

このＩＰアプリケーションサービス提供システムにおいては、制御チャネルプロトコルとしてＵＤＰを用いることが可能であり、コネクションレスプロトコルであることから、制御チャネルパスのＮＡＴエントリが維持されていれば、接続支援装置ＣＳから任意のタイミングで上記第２のステップを実行できる。すなわち、上記第１のステップにおけるＵＤＰパケットの送信元（ＮＡＴ変換後）がＩＰ（アドレス）：Ｐｏｒｔ＝Ａ：ａ、宛先（接続支援装置ＣＳ）がＩＰ：Ｐｏｒｔ＝Ｂ：ｂとすると、上記第２のステップでは、送信元ＩＰ：Ｐｏｒｔ＝Ｂ：ｂ、宛先ＩＰ：Ｐｏｒｔ＝Ａ：ａとすることで、ＮＡＴを越えて内部ノードＡに到達することを利用するものである（図１５参照）。

また、このシステムにおいては、制御チャネルプロトコルとしてＩＣＭＰ（Internet Control Message Protocol）を用いることが可能であり、コネクションレスプロトコルで
あることから、制御チャネルパスのＮＡＴエントリが維持されていれば、接続支援装置ＣＳから任意のタイミングで上記第２のステップを実行できる。ＩＣＭＰはＵＤＰ／ＴＣＰとは異なりポート番号が存在しないが、ほとんどのＮＡＰＴ（Network Address Port Translation）は、Ｐｉｎｇ（ＩＣＭＰ Ｅｃｈｏ）などについてはＩｄｅｎｔｉｆｉｅｒフィールド（実装によってはＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒフィールドも）をポート番号同様にＮＡＴエントリとして管理することで、内部ノードＡ及び外部ノードＢ間のＰｉｎｇを可能としている。この特性を利用し、接続支援装置ＣＳは、上記第１のステップで受信したＩＣＭＰパケットのＩｄｅｎｔｉｆｉｅｒを記憶し、上記第２のステップで用いることで内部ノードＡに到達する（図１６参照）。

さらに、制御チャネルプロトコルとしてＴＣＰを用いることが可能であり、ＴＣＰはコネクションオリエンテッドプロトコルであり、制御チャネルのコネクションを保持する必要があるが、それだけ制御チャネルの信頼性が高まる（図１７参照）。

このシステムにおいては、制御チャネルプロトコルとしてＵＤＰあるいはＩＣＭＰを用いることで、上記第１のステップと上記第２のステップとが非同期にて実行できる。これによると、接続支援装置ＣＳで制御チャネルのコネクションを保持する必要が無いため処理負荷が軽い。それぞれのステップをトランザクション（リクエストに対してレスポンスを返すことで完結する）を実行することで、例えば、レスポンスが返ってこない場合は再送を行うことが可能で、信頼性を高めることができる。もちろん、トランザクションを行わなければそれだけ処理負荷が軽減できる（図１８参照）。

また、上記第１のステップにて送信する制御パケットに対する応答として上記第２のステップを実行することが可能である。つまり、上記第１のステップと上記第２のステップが一連のトランザクションとして同期して動作する。上記第２のステップは、外部ノードＢから接続要求がない場合は、上記第１のステップに対して応答を返さないか、ヌル（ＮＵＬＬ）応答を返し、要求があった場合は、応答メッセージに外部ノードＢの接続先ＩＰアドレス：ポートを含める（図１９参照）。

このシステムにおいては、制御パケットの送信元認証を行ったり、ペイロード（例えば、上記第２のステップで通知する外部ノードＢのＩＰアドレス：ポート）を暗号化したり、改竄防止（検知）のため電子署名を行う等、悪意のある第三者からの不正アクセスを防止する機構を取り入れ、セキュリティ耐性を持つ（図２０参照）。

このシステムにおいては、内部ノードＡ自身がＮＡＴ／ＦＷ配下に位置するか否かによって、上記第１から第３のステップを実施するかどうかを判断する。これは、ＮＡＴ／ＦＷ配下でない場合には、該ステップを実施せずともＩＰアプリケーション通信が可能であることによる。なお、ＮＡＴ／ＦＷ配下に位置するか否かを検査する処理（ステップ）は、例えばＲＦＣ３４８９にて規定されているＳＴＵＮ（Simple Traversal of UDP through NATs）プロトコルのような技術を使うことも可能である。ただし、ＳＴＵＮのようにＮＡＴのタイプまでを判別する必要は無く、ＮＡＴ／ＦＷの有無のみを判断できれば良い（図２１参照）。

このシステムにおいては、内部ノードＡのＮＡＴ検査部１０がＮＡＴ／ＦＷのエントリタイマを検査することで、上記第１のステップでの制御パケット定期送信間隔を最適化する。エントリタイマを検査する処理（ステップ）としては、例えば内部ノードＡから接続支援装置ＣＳに対し、レスポンスを返すまでの待ち時間を含めたリクエストメッセージを送信し、接続支援装置ＣＳはその時間だけ待ってレスポンスを返すといった動作を、レス
ポンスが受信できなくなるまで待ち時間を徐々に広げていくことで調べることができる。なお、ＮＡＴによってはＴＣＰとＵＤＰとでエントリタイマ値が異なる場合があるため、それぞれについて検査を行う（図２２参照）。

このシステムにおいては、上記第１のステップに記載する、制御チャネルポートの通知及び制御チャネルパスのＮＡＴ／ＦＷエントリ維持を目的とする制御パケットの定期送信を行う処理機能を内部ノードＡの接続制御部２０が通信プログラムモジュールとして有している。なお、このプログラムモジュールは各ＩＰアプリケーション３０とは独立（別プロセス）して動作し、複数のＩＰアプリケーションの制御を可能とする（図２３参照）。

このシステムにおいては、上記第２のステップに記載する、上記第１のステップにて通知を受けた制御チャネルポートを管理し、ＩＰアプリケーション通信要求が発生した際に、制御チャネルを用いて接続先アドレス：ポートを通知する機能を接続支援装置ＣＳのノード管理部４０が通信プログラムモジュールとして有している（図２３参照）。

このシステムにおいては、上記第３のステップに記載する、上記第２のステップにて制御チャネル経由で接続先アドレス：ポートの通知を受け、ＩＰアプリケーションデータチャネルをアクティブオープンする機能をアプリケーション３０が通信プログラムモジュールとして有している。なお、本プログラムモジュールは、本来はパッシブオープンするアプリケーション（例えば、サーバアプリケーション）に対しても適用（拡張）でき、例えば同一ＮＡＴ配下の内部ノードＡからの接続は、従来どおりパッシブオープンにて接続することができる。また、アプリケーション固有の処理には依存しないため、アプリケーション共通のＡＰＩ（Ａｃｔｉｖｅ Ｏｐｅｎ ＡＰＩ）として定義することが可能である（図２３参照）。

このシステムにおいては、ＮＡＴ／ＦＷの有無及びＮＡＴ／ＦＷエントリタイマを検査する機能を内部ノードＡのＮＡＴ検査部１０が通信プログラムモジュールとして更に有している（図２３参照）。

上記接続制御部２０及びＩＰアプリケーション３０の有する機能（通信プログラムモジュール）は、内部ノードＡがＮＡＴ／ＦＷ配下でなければ動作させる必要のない機能である。ＮＡＴ検査部１０は、ＮＡＴ／ＦＷの有無を検査し、存在する場合にのみ、ＣＰＵ及びメモリに通信プログラムモジュールをロードしてプロセスを機能させるプログラムモジュール管理機構である（図２５参照）。

上記接続制御部２０及びＩＰアプリケーション３０の有する機能（通信プログラムモジュール）は、内部ノードＡがＮＡＴ／ＦＷ配下でなければ動作はおろか、記憶領域（ＨＤＤ等）に保持する必要がない。ＮＡＴ検査部１０は、ＮＡＴ／ＦＷの有無を検査し、存在する場合にのみ、接続支援装置ＣＳなどから指定されたダウンロード先からダウンロードして機能させるプログラムモジュール管理機構である（図２６参照）。

上記内部ノードＡ自身がＮＡＴ／ＦＷ配下に位置するか否かを検査するステップを、ＩＰアドレスの取得を契機として実施することが可能である。ＩＰアドレス取得の契機とは、例えば内部ノードＡが起動した際や、インタフェースがリンクアップした際、また手動あるいはＤＨＣＰ（Dynamic Host Configuration Protocol）等自動でＩＰアドレスが変
更された際などが考えられ、このタイミングでネットワーク構成変更等によりＮＡＴ／ＦＷが挿入あるいは除去される可能性がある。前者の場合は、これまで動作させていなかったＩＰアプリケーション３０の通信プログラムモジュールを動作させる必要があるし、後者の場合は、逆に必要がなくなるため、このモジュールの動作を停止させるトリガとなる。

また、上記内部ノードＡ自身がＮＡＴ／ＦＷ配下に位置するか否かを検査するステップを、ＮＡＴを越えて接続したい特定ＩＰアプリケーション３０の起動を契機として実施することも可能である。

［ＩＰアプリケーションサービス提供システムの具体例］
次に、本発明の一実施の形態のＩＰアプリケーションサービス提供システムの具体例について説明する。

ここでは、外部ノードＢ対応のコンテンツ配布サーバＳＶを所有するあるコンテンツプロバイダが、ユーザＡ，Ｂ，ＣにサービスゲートウェイＳＧＷ（ＳＧＷ＃１〜＃３）を提供し、リアルタイムで最新コンテンツを配信（アップロード）するケースを考える（図２７参照）。

この場合、ＮＡＴ／ＦＷが存在しなければ、オンデマンドでＴＣＰコネクションを確立することができるが、ＮＡＴ／ＦＷが存在する場合は、前述のとおりＴＣＰコネクションを確立することができない。Ｓｔａｔｉｃ ＮＡＴにより静的にＮＡＴエントリを設定することは可能ではあるが、設定に不慣れなユーザには難しく、サービスを提供する上で大きな障壁となる。

サービスゲートウェイＳＧＷから定期的にコンテンツをポーリングしてコンテンツが最新であればダウンロードする、という手法も可能ではあるが、ポーリング間隔によってはリアルタイム性に欠け、またＮＡＴ／ＦＷの有無でコンテンツを提供するためのアプリケーションプロトコル（ＮＡＴ無：アップロード、ＮＡＴ有：ダウンロード）が異なってしまい、それぞれのためにアプリケーション開発が必要となる。

そこで、サービスゲートウェイＳＧＷには、ＩＰアドレス取得時（電源ＯＮなど）に初期登録としてＳＧＷ管理サーバ（接続支援装置ＣＳ）ＣＳ−ＳＶにアクセスするよう予め設定しておき、その際、自身がＮＡＴ／ＦＷ配下に位置するか否かを確認する。ＮＡＴ／ＦＷが存在しなければ、その後、特にアクションは起こさず、コンテンツが配信される（ＴＣＰ接続要求）のを待つ（図２９参照）。

ＮＡＴ／ＦＷが存在する場合には、サービスゲートウェイＳＧＷはＳＧＷ管理サーバＣＳ−ＳＶから接続制御モジュール及びＡｃｔｉｖｅ Ｏｐｅｎ ＡＰＩ（通信プログラムモジュール）をダウンロードし、インストールを行う。そして、サービスゲートウェイＳＧＷはＳＧＷ管理サーバＣＳ−ＳＶに対し、定期的に制御パケットを送信して制御チャネルを維持する。なお、送信間隔はＮＡＴエントリが維持される間隔で送信すれば良く（一般に１分〜５分間隔）、ＳＧＷ管理サーバＣＳ−ＳＶの処理負荷にはならない。

ＮＡＴ／ＦＷエントリタイマを検査するステップを実行することで、送信間隔を最適化することも可能である。ＳＧＷ管理サーバＣＳ−ＳＶは、初期登録時にサービスゲートウェイＳＧＷのＩＰアドレスを管理するとともに、制御パケットを受信したサービスゲートウェイＳＧＷはＮＡＴ／ＦＷ配下に位置すると判断し、ＮＡＴ ｆｌａｇ及び制御チャネルポートも合わせて管理する（図２８参照）。

コンテンツを配信する際、コンテンツ配布サーバＳＶはＳＧＷ管理サーバＣＳ−ＳＶに問い合わせを行い、各サービスゲートウェイＳＧＷのＩＰアドレス及びＮＡＴ／ＦＷの有無を照会する。照会の結果、ＮＡＴ無のサービスゲートウェイＳＧＷ＃１，＃２には、コンテンツ配布サーバＳＶから直接ＴＣＰ接続要求を行うが、ＮＡＴ有のサービスゲートウェイＳＧＷ＃３は、待受ＩＰ：ＰｏｒｔとともにＳＧＷ管理サーバＣＳ−ＳＶ経由でサー
ビスゲートウェイＳＧＷからのＴＣＰ接続要求を依頼する。サービスゲートウェイＳＧＷ＃３はこの要求を受け、コンテンツ配布サーバＳＶに対してＴＣＰ接続を開始する。

なお、この要求が正規のもの、つまりＳＧＷ管理サーバＣＳ−ＳＶから送付されたもので、改竄などが行われていないことを確認するため、認証や暗号化及び電子署名等と組み合わせても良い。そして、ＴＣＰコネクションが確立した後は、ＮＡＴ有無によらず最新コンテンツをサービスゲートウェイＳＧＷに対してアップロードする。つまり、ＮＡＴの有無によってアプリケーション自体の動作は組み替えることなく、かつ任意のタイミングでアクセスを行うことが可能となる。

上述した一実施の形態によれば、ＮＡＴ／ＦＷなどのゲートウェイ装置の有無を意識せず（存在しても種類に拠らず、また任意のタイミングで）、ＩＰアプリケーションサービスの提供が可能となる。

また、制御部が各ＩＰアプリケーション部と独立しており、かつアプリケーション固有の処理に依存しない拡張を行うため、汎用性が高い。

また、ＮＡＴ／ＦＷの配下に複数の同一ポートで提供されるアプリケーションが存在した場合、例えば上述した一実施の形態で言うと、ＮＡＴ／ＦＷ配下に複数台のサービスゲートウェイＳＧＷがある場合においても、それぞれのサービスゲートウェイＳＧＷからコンテンツ配布サーバＳＶに対してアクティブにＴＣＰコネクション確立を行うため、サービスゲートウェイＳＧＷの使用するポートが同一であってもポート競合の問題は発生しない。

［変形例］
上述した一実施の形態における処理はコンピュータで実行可能なプログラムとして提供され、ＣＤ−ＲＯＭやフレキシブルディスクなどの記録媒体、さらには通信回線を経て提供可能である。

また、上述した一実施の形態における各処理はその任意の複数または全てを選択し組合せて実施することもできる。

［その他］
（付記１）内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供方法であって；
前記ゲートウェイ装置配下の前記内部ノードから前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する第１のステップと；
前記接続支援装置から前記内部ノードに対し、前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートを通知する第２のステップと；
前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする第３のステップと；
を備えるＩＰアプリケーションサービス提供方法。（２）
（付記２）前記制御チャネルのプロトコルとして、ＵＤＰ、ＩＣＭＰ、及びＴＣＰのいずれかを使用する付記１記載のＩＰアプリケーションサービス提供方法。（３）
（付記３）前記第１のステップと前記第２のステップとが非同期で遂行され、前記第１のステップにおける前記制御パケットの送信タイミングに拠らず前記第２のステップを実
行する付記１記載のＩＰアプリケーションサービス提供方法。（４）
（付記４）前記第１のステップにおいて定期送信される前記制御パケットに対する応答として前記第２のステップを遂行する付記１記載のＩＰアプリケーションサービス提供方法。（５）
（付記５）前記第１のステップ及び前記第２のステップにおいて、正当性、機密性、及び完全性を併せて確認することにより、セキュリティ耐性を有する付記１記載のＩＰアプリケーションサービス提供方法。

（付記６）前記ゲートウェイ装置の有無を検査する第４のステップを更に備え、前記内部ノードが前記ゲートウェイ装置の配下に位置すると判明した場合のみ前記第１、第２及び第３のステップを実行する付記１記載のＩＰアプリケーションサービス提供方法。（６）
（付記７）前記ゲートウェイ装置の通信許容エントリタイマを検査する第５のステップを更に備え、タイマ値に応じて前記第１のステップにおける前記制御パケットの送信間隔を最適化する付記１記載のＩＰアプリケーションサービス提供方法。（７）
（付記８）内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供システムであって；
前記ゲートウェイ装置配下の前記内部ノードが、
前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
前記接続支援装置から前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と；
前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする手段とを備える
ＩＰアプリケーションサービス提供システム。（１）

ＮＡ（Ｐ）Ｔの動作原理説明図である。 ＦＷの動作原理説明図である。 発明の背景（ＮＡＴの課題）を示す。 従来技術とその課題を示す。 ＮＡＴの種類（Ｆｕｌｌ Ｃｏｎｅ ＮＡＴ）を示す。 ＮＡＴの種類（Ｒｅｓｔｒｉｃｔｅｄ Ｃｏｎｅ ＮＡＴ）を示す。 ＮＡＴの種類（Ｐｏｒｔ Ｒｅｓｔｒｉｃｔｅｄ Ｃｏｎｅ ＮＡＴ）を示す。 ＮＡＴの種類（Ｓｙｍｍｅｔｒｉｃ ＮＡＴ）を示す。 ＳＴＵＮの動作説明図である。 ＳＴＵＮフローチャートを示す。 ＳＴＵＮとＵＤＰ Ｈｏｌｅ Ｐｕｎｃｈｉｎｇを使った接続成功例を示す。 ＳＴＵＮとＵＤＰ Ｈｏｌｅ Ｐｕｎｃｈｉｎｇを使った接続失敗例を示す。 ステートフルインスペクションの説明図である。 本発明の一実施の形態のシステムの構成を示すブロック図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 ＯＳＩ参照モデルの説明図である。 本発明の一実施の形態のシステムの説明図である。 本発明の一実施の形態のシステムの説明図である。 具体例の説明図である。 具体例の説明図である。 具体例の説明図である。

符号の説明

ＩＮＷ 内部ネットワーク
ＯＮＷ 外部ネットワーク
ＮＡＴ ネットワークアドレス変換装置
ＣＳ 接続支援装置
１０ ＮＡＴ検査部
２０ 接続制御部
３０ ＩＰアプリケーション

Claims (7)

1. 内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供システムであって；
   前記ゲートウェイ装置配下の前記内部ノードが、
   前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
   前記接続支援装置から前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と；
   前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする手段とを備える
   ＩＰアプリケーションサービス提供システム。
2. 内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供方法であって；
   前記ゲートウェイ装置配下の前記内部ノードから前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する第１のステップと；
   前記接続支援装置から前記内部ノードに対し、前記制御チャネルを通して前記外部ノード対応の接続先アドレス及びポートを通知する第２のステップと；
   前記通知を受けた接続先アドレス及びポートに対してＩＰアプリケーションのデータチャネルをアクティブにオープンする第３のステップと；
   を備えるＩＰアプリケーションサービス提供方法。
3. 前記制御チャネルのプロトコルとして、ＵＤＰ、ＩＣＭＰ、及びＴＣＰのいずれかを使用する請求項２記載のＩＰアプリケーションサービス提供方法。
4. 前記第１のステップと前記第２のステップとが非同期で遂行され、前記第１のステップにおける前記制御パケットの送信タイミングに拠らず前記第２のステップを実行する請求項２記載のＩＰアプリケーションサービス提供方法。
5. 前記第１のステップにおいて定期送信される前記制御パケットに対する応答として前記第２のステップを遂行する請求項２記載のＩＰアプリケーションサービス提供方法。
6. 前記ゲートウェイ装置の有無を検査する第４のステップを更に備え、前記内部ノードが前記ゲートウェイ装置の配下に位置すると判明した場合のみ前記第１、第２及び第３のステップを実行する請求項２記載のＩＰアプリケーションサービス提供方法。
7. 前記ゲートウェイ装置の通信許容エントリタイマを検査する第５のステップを更に備え、タイマ値に応じて前記第１のステップにおける前記制御パケットの送信間隔を最適化する請求項２記載のＩＰアプリケーションサービス提供方法。

Images