JP2008541675A

JP2008541675A - ネットワークアドレス変換またはファイアウォール設備を越える方法及びシステム

Info

Publication number: JP2008541675A
Application number: JP2008512674A
Authority: JP
Inventors: ▲シン▼ 姚; 列丹 ▲ジュ▼
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-05-23
Filing date: 2006-05-23
Publication date: 2008-11-20
Anticipated expiration: 2026-05-23
Also published as: JP4705167B2; EP1865681A1; WO2006125383A1; CN1870568A; DE602006010525D1; AU2006251686B2; EP1865681A4; US20080037537A1; AU2006251686A1; EP1865681B1; ATE449501T1

Abstract

本願発明は、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を越える方法であって、ＮＡＴまたはＦＷ設備を介してアクセスする第１設備及び第２設備の間にＵＴＣ及びＵＴＳを配置するステップＡと、前記ＵＴＣ及びＵＴＳを利用して、前記第１設備及び第２設備の間にＵＤＰトンネルを確立するステップＢと、前記ＵＤＰトンネルを介して、第１設備及び第２設備のうちの一方からのパケットをＮＡＴまたはＦＷ設備を介して、第１設備及び第２設備のうちの他方に伝送するステップＣとを含む。ＮＡＴまたはＦＷ設備に対していかなる変更も加えずに、ＮＡＴまたはＦＷ設備を越えることが実現できる。

Description

本発明は通信技術分野に関し、特に、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を越える方法に関する。

近年、移動通信分野が最も競争の激しい業界の一つとなっており、電気通信事業者は、ますます差異化サービスによって自身の競争力を向上する必要に迫られている。ソフトスイッチングやパケットスイッチング技術を核心とする次世代ネットワーク（ＮＧＮ）技術は広い応用前景があり、また人々の多様化、個性化のサービスニーズを満たすことができて、業界で最も注目されるものになった。
しかしながら、目下、ＮＧＮの実際の応用において多くの問題に直面してしまった。例えば、ＮＧＮユーザのアクセス問題である。ＮＧＮはパケットネットワークに基づくベアラネットワークであって、ユーザのアクセスがすべてインターネットプロトコル（ＩＰ）アドレスによってアドレッシングされ、ＩＰアドレスの不足及びセキュリティなどの原因で、大量の企業内ネットワークや宅内ネットワークがプライベートＩＰアドレスを用いて出口のＮＡＴまたはＦＷ設備を介してパブリックネットワークにアクセスしている。

ＮＧＮネットワークの最大のメリットはユーザに豊かなサービスを提供でき、特に、企業ユーザに音声、データ、ビデオの融合のＩＰセントレックス（Ｃｅｎｔｒｅｘ）サービスを提供できることである。しかしながら、ＮＡＴまたはＦＷ設備ではすべてのネットワークアプリケーションプログラムが一種の標準方式、即ち、パケットヘッダでＩＰアドレスを使用する方式で通信を行うことが希望される。よって、Ｈ．３２３、セッション開始プロトコル（ＳＩＰ）、メディアゲートウェイコントロールプロトコル（ＭＧＣＰ）、Ｈ．２４８などのような、ＩＰに音声やビデオを搭載するプロトコルのコントロールチャネル・メディアチャネルが伝統的なＮＡＴまたはＦＷ設備を越えてパブリックネットワークと相互接続することが困難であり、言い換えると、従来のＮＡＴまたはＦＷ設備の多くはハイパーテクスト転送プロトコル（ＨＴＴＰ）のデータアプリケーションプロトコルの通過のみをサポートし、上記会話型サービス（ｃｏｎｖｅｒｓａｔｉｏｎａｌｓｅｒｖｉｃｅ）のコントロールやメディアの通過はサポートしない。したがって、プライベートネットワークアドレスに基づくＮＡＴまたはＦＷ設備の通過問題の解決を迫られており、現在、当該問題はＮＧＮネットワークサービス展開に対する最大の障害になっている。

従来技術に係るＮＡＴまたはＦＷ設備の通過技術を実現する方法はアプリケーションレベルゲートウェイ（ＡＬＧ）方法である。
ＡＬＧは指定ＩＰプロトコル（例えば、Ｈ．３２３、ＳＩＰまたはＭＧＣＰ）を識別できる設備である。ＡＬＧはパブリックネットワークとプライベートネットワークとの間に単独に接続されてもよく、ＮＡＴまたはＦＷ設備の内部に内蔵されてもよい。ＡＬＧはＮＡＴまたはＦＷ設備とのやりとりによってＮＡＴまたはＦＷ設備状態情報を確立し、その後、確立したＮＡＴまたはＦＷ設備状態情報を用いてＩＰパケットデータ部分にカプセル化された特定のデータを変更して、ＩＰパケットがその他の必要な動作を通じてＮＡＴまたはＦＷ設備を越えることを可能にする。

前記ＡＬＧ方法の主な欠点として、現在、ネットワークに存在する多くのＮＡＴまたはＦＷ設備がＡＬＧ能力を有しないため、これらのＮＡＴまたはＦＷ設備を入れ替え、またはアップデートしなければＡＬＧ方法を採用することができないという問題がある。しかしながら、普通、ユーザは、事業者が従来のＮＡＴまたはＦＷ設備を変更しなくても新しい会話型ＩＰサービスを提供できるように希望している。ＮＡＴまたはＦＷ設備に対していかなる変更も加えずに、ＮＡＴまたはＦＷ設備を越えることは、ＡＬＧ方法では不可能である。

本発明は上記の従来技術に鑑みてなされたものであって、ＮＡＴまたはＦＷ設備を越える方法を提供することによって、ＮＡＴまたはＦＷ設備に対していかなる変更も加えずに、ＮＡＴまたはＦＷ設備を越えることを実現できる。

本発明の目的が下記の解決手段によって実現される。
ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を越える方法であって、ＮＡＴまたはＦＷ設備の両側に位置する第１設備及び第２設備の間にユーザデータグラムプロトコル（ＵＤＰ）トンネルクライアント（ＵＴＣ）及びＵＤＰトンネルサーバ（ＵＴＳ）を配置するステップＡと、前記ＵＴＣ及びＵＴＳを利用して、前記第１設備及び第２設備の間にＵＤＰトンネルを確立するステップＢと、前記ＵＤＰトンネルを介して、第１設備及び第２設備のうちの一方からのパケットをＮＡＴまたはＦＷ設備を介して、第１設備及び第２設備のうちの他方に伝送するステップＣと、を含む。

前記ＵＴＣが、単独の設備であるか、またはプロキシ設備、ＮＡＴ設備、ファイアウォール、ルーターもしくはサーバに位置する。
前記ＵＴＳが、単独の設備であるか、またはプロキシ設備、ＮＡＴ設備、ファイアウォール、ルーターもしくはサーバに位置する。
前記ＵＴＣ及びＵＴＳを配置することは、前記ＵＴＣ及びＵＴＳをＮＡＴまたはＦＷ設備の両側に配置するか、または、ＵＴＣをＮＡＴまたはＦＷ設備の片側に配置し、ＵＴＳをＮＡＴまたはＦＷ設備に配置することである。
前記ＮＡＴまたはＦＷ設備が、次世代ネットワーク（ＮＧＮ）でのＮＡＴまたはＦＷ設備である。

前記ステップＢは、ＵＴＣが、前記第１設備からのパケットを受信し、前記第１設備からのパケットのインターネットプロトコル（ＩＰ）ヘッダの後にＵＤＰトンネルヘッダ（ＵＴＨ）を挿入し、その後、ＮＡＴまたはＦＷ設備を介して、当該パケットをＵＴＳに伝送するステップＢ１１と、ＵＴＳが、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信し、当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレスを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレスをＵＤＰトンネル情報の一つの記録項目として記憶し、前記ＵＤＰトンネルを確立するステップＢ１２と、を含む。

前記ステップＣは、ＵＴＳが前記新しい送信元ＩＰアドレスで前記ＵＴＣから送信されたパケットの送信元ＩＰアドレスを取り換え、かつＵＴＳがＵＴＣから送信されたパケットを第２設備に伝送するステップＣ１１と、を含む。
前記ステップＢ１２において、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されたパケットを受信した後、ＵＴＳがＵＴＣから送信されたパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索するステップをさらに含み、関連の記録項目が検出された場合、直接にステップＣ１１に進み、そうでない場合、ＵＴＳが当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレスを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレスをＵＤＰトンネル情報の一つの記録項目として記憶し、ステップＣ１１に進むことをさらに含む。

前記ステップＢは、ＵＴＣが、前記第１設備からのパケットを受信し、前記第１設備からのパケットのＩＰヘッダの後にＵＤＰトンネルヘッダ（ＵＴＨ）を挿入し、その後、ＮＡＴまたはＦＷ設備を介して、当該パケットをＵＴＳに伝送するステップＢ２１と、ＵＴＳが、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信し、当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレス及び新しい送信元ポートを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＤＰトンネルヘッダ負荷での送信元ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレス及び新しい送信元ポートをＵＤＰトンネル情報の一つの記録項目として記憶し、前記ＵＤＰトンネルを確立するステップＢ２２と、を含み、前記ステップＣは、ＵＴＳが前記新しい送信元ＩＰアドレスでＵＴＣから送信されたパケットの送信元ＩＰアドレスを取り換え、前記新しい送信元ポートでＵＤＰトンネルヘッダ負荷での送信元ポートを取り換え、ＵＴＣから送信されたパケットを第２設備に伝送するステップＣ２１と、を含む。

前記ステップＢ２２において、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信した後、ＵＴＳがＵＴＣから送信されたパケットの送信元ＩＰアドレス、送信元ポート、及びＵＤＰトンネルヘッダ負荷での送信元ポートをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索するステップをさらに含み、関連の記録項目が検出された場合、直接にステップＣ２１に進み、そうでない場合、ＵＴＳが当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレスと新しい送信元ポートを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＤＰトンネルヘッダ負荷での送信元ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレス及び新しい送信元ポート情報をＵＤＰトンネル情報の一つの記録項目として記憶し、ステップＣ２１に進むことをさらに含む。

前記ステップＣは、第２設備からのパケットを受信したＵＴＳが、第２設備からのパケットの送信先ＩＰアドレスをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索して、関連の記録項目が検出された場合、ステップＣ３２に進み、そうでない場合、当該第２設備からのパケットを無視し、プロセスを終了させるステップＣ３１と、ＵＴＳが、第２設備からのパケットの送信先ＩＰアドレスを関連の記録項目での送信元ＩＰアドレスに取り換え、当該記録項目でのＵＤＰトンネルヘッダの送信元ポートを送信先ポートとしＵＤＰトンネルヘッダの送信先ポートを送信元ポートとするＵＤＰトンネルヘッダを第２設備からのパケットのＩＰヘッダの後に挿入し、ＮＡＴまたはＦＷ設備を介して、第２設備からのパケットをＵＴＣに伝送するステップＣ３２と、ＵＴＣが、ＮＡＴまたはＦＷ設備を介してＵＴＳから送信されるパケットを受信し、ＵＴＳから送信されたパケットでのＵＤＰトンネルヘッダを削除し、ＵＴＳから送信されたパケットを第１設備に伝送するステップＣ３３と、をさらに含む。

前記ＵＤＰトンネルヘッダが、標準のＵＤＰヘッダと、もとのパケットに搭載されたパケットタイプを表すプロトコルフィールドと、を含む。
前記ＵＤＰトンネルヘッダが、ＵＤＰトンネルパケットタイプを表すタイプフィールドをさらに含む。

上記の本発明に提供された解決手段からわかるように、従来技術と比べて、本発明の利点は以下のようである。ＮＡＴまたはＦＷ設備を越える二つの設備のために一つのＵＤＰトンネルを確立し、確立したＵＤＰトンネルを利用してＮＡＴまたはＦＷ設備を越えることを実現している。よって、本発明では従来のＮＡＴまたはＦＷ設備に対していかなる変更を加えなくとも、Ｈ．３２３、ＳＩＰ、ＭＧＣＰ、Ｈ．２４８などのサービスのパケットがＮＡＴまたはＦＷ設備を越えることを可能にしている。同時に、本発明は従来のネットワークのセキュリティに影響を与えず、かつ、ネットワークにおける既存サービスのセキュリティ及びサービス品質要求にも影響を与えない。

本発明ではＮＡＴまたはＦＷ設備を越える方法を提供している。本発明の核心として、ＮＡＴまたはＦＷ設備を介してアクセスする設備の間にＵＤＰトンネルクライアント（ＵＤＰＴｕｎｅｌＣｌｉｅｎｔ，ＵＴＣ）及びＵＤＰトンネルサーバ（ＵＤＰＴｕｎｅｌＳｅｒｖｅｒ，ＵＴＳ）を配置し、ＮＡＴまたはＦＷ設備を越える二つの設備のために一つのＵＤＰトンネルを確立し、その後、確立したＵＤＰトンネルを利用してアプリケーションプロトコルパケットがＮＡＴまたはＦＷ設備を越えることを実現する。ここで、前記ＵＴＣ及びＵＴＳがＮＡＴまたはＦＷ設備の両側に配置されてもよく、ＵＴＣがＮＡＴまたはＦＷ設備の片側に配置され、ＵＴＳがＮＡＴまたはＦＷ設備に配置されてもよい。以下の実施形態ではＵＴＣ及びＵＴＳがＮＡＴ・ＦＷ設備の両側に配置されることを例として説明する。

まず、本発明ではＮＡＴまたはＦＷ設備の両側にＵＴＣ及びＵＴＳを配置する。ＵＴＣ及びＵＴＳは単独の設備であってよく、プロキシ（Ｐｒｏｘｙ）設備、ＮＡＴ設備、ファイアウォール、ルーター、サーバ（Ｓｅｒｖｅｒ）などの他のいかなる設備の一部分として実現されてもよい。ＮＡＴまたはＦＷ設備を越える二つの設備は、例えば、一つの端末及び一つのサーバ、二つの端末、二つのサーバ、二つのルーターなどのようないかなるネットワーク設備であってよい。ここで、端末やサーバがＵＴＣ及びＵＴＳを介してＮＡＴまたはＦＷ設備を越える図は図１に示すようである。

図１に示したネットワーク構成においては、ＵＴＣが端末側に配置され、かつＵＴＳがサーバ側に配置されている。本発明の前記方法として、端末とサーバとの間に一つのＵＤＰトンネルが確立され、ＵＤＰトンネルが確立された後、端末とサーバとの間で伝送される後続のすべてのパケットが当該ＵＤＰトンネルを介して伝送される。
図１に示したネットワーク構成において、伝送のパケットには、端末がＵＴＣ及びＵＴＳを介してサーバに送信するパケットと、サーバがＵＴＣ及びＵＴＳを介して端末に送信するパケットとが含まれ、前者は、端末をパケット送信設備とし、サーバをパケット受信設備とし、後者は、サーバをパケット送信設備とし、端末をパケット受信設備とする。ＵＤＰトンネルは、端末からサーバに送信されるパケットを通じて最初に確立される。

以下、図面を参照して本発明の第１実施形態を説明する。本発明の第１実施形態に係る端末がＵＴＣ及びＵＴＳを介してサーバにパケットを送信する具体的な処理プロセスは図２に示すようであり、その中には、ＵＴＣ及びＵＴＳがそれぞれパケットを処理する具体的な処理過程が含まれ、当該プロセスは下記のようなステップを含む。
ステップ２０１で、ＵＴＣは端末からのパケットにＵＤＰトンネルヘッダ（ＵＴＨ：ＵＤＰＴｕｎｅｌＨｅａｄｅｒ）を付加し、その後、ＮＡＴまたはＦＷ設備にパケットを伝送する。
ここで、端末からのパケットを受信したＵＴＣは、当該パケットのＩＰヘッダの後にＵＴＨを挿入する必要がある。

ＵＴＨの主な内容は下記を含む。
標準のＵＤＰヘッダ、これは必須である。
プロトコルフィールド、これは必須である。プロトコルフィールドは標準のＵＤＰヘッダの後に位置し、もとのＩＰパケットに搭載されたパケットのタイプを明示する。例えば、ＵＤＰ、転送コントロールプロトコル（ＴＣＰ）またはストリームコントロール転送プロトコル（ＳＣＴＰ）のパケットであることを明示する。
タイプフィールド、これは省略可能である。タイプフィールドは標準のＵＤＰヘッダの後に位置し、ＵＤＰトンネル自身のパケットタイプを明示する。

端末からのパケットを受信したＵＴＣは、もとのパケットのＩＰヘッダの後に前記ＵＴＨを挿入し、ここで、ＵＴＨのプロトコルフィールドはもとのＩＰヘッダのプロトコルフィールドに等しい。その後、ＵＴＣはチェックサムを改めて計算し、当該パケットをＮＡＴまたはＦＷ設備に伝送する。ＵＴＣからのパケットを受信したＮＡＴまたはＦＷ設備は、当該パケットをＵＴＳに転送する。
ＵＴＣが端末からのパケットのＩＰヘッダの後にＵＴＨを挿入する図は図３に示すようである。図３において、もとのパケットにはＩＰヘッダ、ＴＣＰ・ＵＤＰヘッダ、及びデータ（Ｄａｔａ）が含まれ、ステップ２０１において、ＵＴＣが当該パケットにＵＴＨを挿入して、図３に示したＵＴＨ挿入後のパケットが形成される。

ステップ２０２で、ＵＴＳは、ＮＡＴまたはＦＷ設備からのパケットがＵＤＰトンネルパケットであると決定し、パケットの中からパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートを取り出す。
ＮＡＴまたはＦＷ設備からのパケットを受信したＵＴＳは、まず、当該パケットにＵＴＨが含まれているかどうかによって当該パケットがＵＤＰトンネルパケットであるかどうかを判断する。そうである場合、パケットの中からパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートを取り出し、ステップ２０３に進み、そうでない場合、従来の普通のパケット処理プロセスに従って当該パケットを処理し、本プロセスを終了させる。

ステップ２０３で、ＵＴＳは取り出したパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートをインデックスとしてマッピングテーブル（ｍａｐｐｉｎｇｔａｂｌｅ）を検索する。
一般的に、同じＵＴＣからのＵＴＨの送信元ポートと、送信先ポートとが同じである。よって、本実施形態ではＵＴＨの送信元ポート、送信先ポート、パケットの送信元ＩＰアドレス、及び割り当てられた新しい送信元ＩＰアドレスの四つの情報を含むマッピングテーブルをＵＴＳに記録・記憶し、当該マッピングテーブル内の一つの記録項目によってＵＴＣとＵＴＳとの間の一つのＵＤＰトンネルを意味する。

ＵＴＳがパケットの中から取り出したパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートをインデックスとして上記マッピングテーブルを検索して、関連の記録項目が検出されなかった場合、ステップ２０４に進み、関連の記録項目が検出された場合、当該パケットの送信元ＩＰアドレスに対応するＵＴＣとＵＴＳとの間のＵＤＰトンネルが既に確立されて、直接に当該ＵＤＰトンネルを利用してパケットを伝送できることを示し、直接にステップ２０５に進む。

ステップ２０４で、パケットに新しい送信元ＩＰアドレスを割り当て、ＵＴＨの送信元ポート、送信先ポート、パケットの送信元ＩＰアドレス、及び新しい送信元ＩＰアドレスの情報をマッピングテーブルに記録する。
ステップ２０３で関連の記録項目が検出されなかった場合、当該パケットの送信元ＩＰアドレスに対応するＵＴＣとＵＴＳとの間のＵＤＰトンネルがまだ確立されていないことを示し、そして、ＵＴＳはパケットに新しい送信元ＩＰアドレスを割り当て、ＵＴＨの送信元ポート、送信先ポート、パケットの送信元ＩＰアドレス、及び新しい送信元ＩＰアドレスの情報を一つの記録項目に構成して前記マッピングテーブルに記憶する。これで、当該パケットの送信元ＩＰアドレスに対応するＵＴＣとＵＴＳとの間のＵＤＰトンネルが確立される。

ステップ２０５で、ＵＴＳは記録の中から新しい送信元ＩＰアドレスを取り出して、パケットの送信元ＩＰアドレスを取り換え、処理後のパケットをサーバに伝送する。
ここで、ＵＴＳは前記マッピングテーブルの相応の記録項目から新しい送信元ＩＰアドレスを取り出して、もとのパケットの送信元ＩＰアドレスを当該新しい送信元ＩＰアドレスに取り換える。その後、パケットでのＵＴＨを削除し、チェックサムを改めて計算し、パケットをサーバに伝送する。
本発明の第１実施形態に係るサーバが、ＵＴＳ及びＵＴＣを介して端末にパケットを送信する具体的な処理プロセスは図４に示すようであり、その中には、ＵＴＣ及びＵＴＳがそれぞれパケットを処理する具体的な処理過程が含まれ、当該プロセスは下記のようなステップを含む。

ステップ４０１で、サーバからのパケットを受信したＵＴＳは、パケットの送信先ＩＰアドレスを取り出す。
ステップ４０２で、ＵＴＳは送信先ＩＰアドレスをインデックスとしてマッピングテーブルを検索する。
ＵＴＳは、パケットの送信先ＩＰアドレスを取り出してインデックスとして、ＵＴＳに記憶された前記マッピングテーブルを検索し、前記マッピングテーブルに相応の記録項目が存在して、当該記録項目での新しい送信元ＩＰアドレスが、取り出したパケットの送信先ＩＰアドレスに等しい場合、ステップ４０４に進み、そうでない場合、ステップ４０３に進む。

ステップ４０３で、当該パケットを無視する。
前記マッピングテーブルで前記記録項目が検出されなかった場合、当該パケットがＵＴＳによって処理されるべきではないことを示し、そして、ＵＴＳは直接に当該パケットを無視し、プロセスを終了させる。
ステップ４０４で、ＵＴＳは記録されたパケットの送信元ＩＰアドレスを取り出して、パケットの送信先ＩＰアドレスを取り換え、パケットにＵＴＨを付加し、パケットをＮＡＴまたはＦＷ設備に伝送する。

前記マッピングテーブルで前記記録項目が検出された場合、当該パケットがＵＴＳによって処理されるべきであり、且つ相応のＵＤＰトンネルが既に確立されたことを示す。そして、ＵＴＳは検出された記録項目での送信元ＩＰアドレスを取り出して、パケットの送信先ＩＰアドレスを取り換え、且つ当該記録項目でのＵＴＨの送信元ポートをＵＴＨの送信先ポートとし、当該記録項目でのＵＴＨの送信先ポートをＵＴＨの送信元ポートとするＵＴＨをパケットのＩＰヘッダの後に挿入する。当該ＵＴＨのプロトコルフィールドはもとのＩＰヘッダでのプロトコルフィールドに等しい。新しいＩＰヘッダのプロトコルフィールドを、ＵＤＰプロトコルのポート値を意味する１７に更新する。その後、ＵＴＳはチェックサムを改めて計算し、パケットをＮＡＴまたはＦＷ設備に伝送する。ＵＴＳからのパケットを受信したＮＡＴまたはＦＷ設備は、当該パケットをＵＴＣに転送する。

ステップ４０５で、ＵＴＣは、ＮＡＴまたはＦＷ設備からのパケットがＵＤＰトンネルパケットであると決定し、パケットでのＵＴＨを削除し、パケットを端末に伝送する。
ＮＡＴまたはＦＷ設備からのパケットを受信したＵＴＣは、当該パケットにＵＴＨが含まれているかどうかによって当該パケットがＵＤＰトンネルパケットであるかどうかを判断し、そうである場合、パケットでのＵＴＨを削除し、パケットでの送信先ＩＰアドレスに基づいてパケットを相応の端末に送信し、そうでない場合、ＵＴＣは従来の普通のパケット処理プロセスに従って当該パケットを処理する。

ＵＴＳが割当できる十分なＩＰアドレスを有しない場合、本発明の第２実施形態によって別の解決手段が提出される。当該手段において、ＵＴＣがパケットを処理する具体的な処理過程は第１実施形態と同じであるが、ＵＴＳがパケットを処理する具体的な処理過程は第１実施形態と異なっている。例えば、ＵＴＳはＩＰアドレス及びポートをパケットに割り当てる。

第２実施形態に係る端末がＵＴＣ及びＵＴＳを介してサーバにパケットを送信する具体的な処理プロセスは図５に示すようであり、その中には、ＵＴＣ及びＵＴＳがそれぞれパケットを処理する具体的な処理過程が含まれ、当該プロセスは下記のようなステップを含む。

ステップ５０１で、ＵＴＣは端末からのパケットにＵＴＨを付加し、ＮＡＴまたはＦＷ設備にパケットを伝送する。
当該ステップは第１実施形態のステップ２０１と同じであって、端末からのパケットを受信したＵＴＣは、もとのパケットのＩＰヘッダの後に前記ＵＴＨを挿入し、ここで、ＵＴＨのプロトコルフィールドはもとのＩＰヘッダのプロトコルフィールドに等しい。その後、ＵＴＣはチェックサムを改めて計算し、当該パケットをＮＡＴまたはＦＷ設備に伝送する。ＵＴＣからのパケットを受信したＮＡＴまたはＦＷ設備は、当該パケットをＵＴＳに転送する。

ステップ５０２で、ＵＴＳは、ＮＡＴまたはＦＷ設備からのパケットがＵＤＰトンネルパケットであると決定し、パケットの送信元ＩＰアドレス、ＵＴＨの送信元ポート、及びＵＴＨ負荷での送信元ポートを取り出す。
ＮＡＴまたはＦＷ設備からのパケットを受信したＵＴＳは、まず、当該パケットにＵＴＨが含まれているかどうかによって、当該パケットがＵＤＰトンネルパケットであるかどうかを判断する。そうである場合、パケットの送信元ＩＰアドレス、ＵＴＨの送信元ポート、及びＵＴＨ負荷での送信元ポートを取り出し、ステップ５０３に進み、そうでない場合、従来の普通のパケット処理プロセスに従って当該パケットを処理し、本プロセスを終了させる。

ステップ５０３で、ＵＴＳは取り出したパケットの送信元ＩＰアドレス、ＵＴＨの送信元ポート、及びＵＴＨ負荷での送信元ポートをインデックスとして、マッピングテーブルを検索する。
第１実施形態と異なって、第２実施形態ではＵＴＳにＵＴＨの送信元ポート、送信先ポート、ＵＴＨ負荷での送信元ポート、パケットの送信元ＩＰアドレス、新しい送信元ＩＰアドレス、及び新しい送信元ポートの情報を含むマッピングテーブルを記録・記憶し、当該マッピングテーブルでの一つの記録項目によってＵＴＣとＵＴＳとの間の一つのＵＤＰトンネルを意味する。

ＵＴＳは、取り出したパケットの送信元ＩＰアドレス、ＵＴＨの送信元ポート、及びＵＴＨ負荷での送信元ポートをインデックスとして上記マッピングテーブルを検索して、関連の記録項目が検出されなかった場合、ステップ５０４に進み、関連の記録項目が検出された場合、ＵＤＰトンネルが既に確立されて、直接に当該ＵＤＰトンネルを利用してパケットを伝送できることを示し、直接にステップ５０５に進む。

ステップ５０４で、ＵＴＳは、新しい送信元ＩＰアドレス及び新しい送信元ポートをパケットに割り当て、ＵＴＨの送信元ポート、送信先ポート、ＵＴＨ負荷での送信元ポート、パケットの送信元ＩＰアドレス、新しい送信元ＩＰアドレス、及び新しい送信元ポートの情報をマッピングテーブルに記録する。

ＵＴＳは取り出したパケットの送信元ＩＰアドレス、ＵＴＨの送信元ポート、及びＵＴＨ負荷での送信元ポートをインデックスとして上記マッピングテーブルを検索して、関連の記録項目が検出されなかった場合、当該パケットの送信元ＩＰアドレスに対応する当該ＵＴＣとＵＴＳとの間のＵＤＰトンネルがまだ確立されていないことを示し、そして、ＵＴＳは新しい送信元ＩＰアドレス及び新しい送信元ポートをパケットに割り当て、ＵＴＨの送信元ポート、送信先ポート、ＵＴＨ負荷での送信元ポート、パケットの送信元ＩＰアドレス、新しい送信元ＩＰアドレス、及び新しい送信元ポートの情報を一つの記録項目に構成して前記マッピングテーブルに記憶する。これで、当該パケットの送信元ＩＰアドレスに対応するＵＴＣとＵＴＳとの間のＵＤＰトンネルが確立される。

ステップ５０５で、ＵＴＳは記録の中から新しい送信元ＩＰアドレスを取り出して、パケットの送信元ＩＰアドレスを取り換え、もとのＵＴＨ負荷での送信元ポートを新しい送信元ポートに取り換え、パケットをサーバに伝送する。
ＵＴＳは前記マッピングテーブルの相応の記録項目での新しい送信元ＩＰアドレス及び新しい送信元ポートを取り出して、もとのパケットの送信元ＩＰアドレスを当該新しい送信元ＩＰアドレスに取り換え、もとのＵＴＨ負荷での送信元ポートを新しい送信元ポートに取り換える。その後、ＵＴＳはパケットでのＵＴＨを削除し、チェックサムを改めて計算し、パケットをサーバに伝送する。
第２実施形態において、サーバがＵＴＳ及びＵＴＣを介して端末にパケットを送信する具体的な処理プロセスは第１実施形態と似ていて、ここでは説明を省略する。

図６は、第１実施形態及び第２実施形態において、端末とサーバとの間でデータを伝送する過程においてＵＴＨに含まれるデータの構成図である。図６に示すように、Ｔ及びＴＥは端末（Ｔｅｒｍｉｎａｌ）を表し、ＣはＵＴＣを表し、ＮはＮＡＴまたはＦＷ設備を表し、ＵはＵＴＳを表し、Ｓ及びＳｅｒｖｅｒはサーバを表す。ここで、「ｔ，ｓ」はＵＴＨ負荷での送信元ポート及び送信先ポートを表し、「Ｔ，Ｓ」は例えば端末のＩＰアドレスであるパケットの送信元ＩＰアドレスと、例えばＳｅｒｖｅｒのＩＰアドレスであるパケットの送信先ＩＰアドレスとを表し、「ｃ，ｕ」はＵＴＨの送信元ポート及び送信先ポートを表し、「ｎ，ｕ」はＮＡＴ処理後の送信元ポート及び送信先ポートを表す。

第１実施形態と同様に、第２実施形態において、ＵＴＣ及びＵＴＳが単独の設備であってよく、Ｐｒｏｘｙ設備、ＮＡＴ設備、ファイアウォール、ルーター、サーバなどのほかのいかなる設備で実現されてもよい。
ＵＴＳがＰｒｏｘｙ設備で実現される場合、ＵＴＳの機能と、Ｐｒｏｘｙ設備の既存機能とを結びつけることができ、Ｐｒｏｘｙ設備はパケットの送信先ＩＰアドレスを変更して、最終的に上記二つの実施形態おける処理を実現する。
ＵＴＳがＮＡＴまたはＦＷ設備で実現される場合、ＵＴＳの機能と、ＮＡＴまたはＦＷ設備の既存機能とを結びつけることができ、ＮＡＴまたはＦＷ設備はパケットの送信先ＩＰアドレスを変更して、最終的に上記二つの実施形態における処理を実現する。

上記は本発明の好ましい具体的な実施形態にすぎず、本発明の保護範囲を限定するものではない。本発明の精神及び原則内で行われる種々の修正、均等な変更、改良などは全て本発明の保護範囲内に含まれる。

端末やサーバがＵＴＣ及びＵＴＳを介してＮＡＴまたはＦＷ設備を越えることを示す図である。本発明の第１実施形態に係る端末がＵＴＣ及びＵＴＳを介してサーバにパケットを送信するフローチャートである。本発明の第１実施形態に係るＵＴＣが端末からのパケットのＩＰヘッダの後にＵＴＨを挿入することを示す図である。本発明の第１実施形態に係るサーバがＵＴＳ及びＵＴＣを介して端末にパケットを送信するフローチャートである。本発明の第２実施形態に係る端末がＵＴＣ及びＵＴＳを介してサーバにパケットを送信するフローチャートである。本発明に係る端末とサーバとの間でデータを伝送する過程においてＵＴＨに含まれるデータの構成図である。

Claims

ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を越える方法であって、
ＮＡＴまたはＦＷ設備の両側に位置する第１設備及び第２設備の間に、ユーザデータグラムプロトコル（ＵＤＰ）トンネルクライアント（ＵＴＣ）及びＵＤＰトンネルサーバ（ＵＴＳ）を配置するステップＡと、
前記ＵＴＣ及びＵＴＳを利用して、前記第１設備及び第２設備の間にＵＤＰトンネルを確立するステップＢと、
前記ＵＤＰトンネルを介して、第１設備及び第２設備のうちの一方からのパケットをＮＡＴまたはＦＷ設備を介して、第１設備及び第２設備のうちの他方に伝送するステップＣと、
を含むことを特徴とする方法。
前記ＵＴＣが、単独の設備であるか、または、プロキシ設備、ＮＡＴ設備、ファイアウォール、ルーター、もしくはサーバに位置することを特徴とする請求項１に記載の方法。
前記ＵＴＳが、単独の設備であるか、または、プロキシ設備、ＮＡＴ設備、ファイアウォール、ルーター、もしくはサーバに位置することを特徴とする請求項１に記載の方法。
前記ＵＴＣ及びＵＴＳを配置することは、前記ＵＴＣ及びＵＴＳをＮＡＴまたはＦＷ設備の両側に配置するか、または、ＵＴＣをＮＡＴまたはＦＷ設備の片側に配置し、ＵＴＳをＮＡＴまたはＦＷ設備に配置することを特徴とする請求項１に記載の方法。
前記ＮＡＴまたはＦＷ設備が、次世代ネットワーク（ＮＧＮ）でのＮＡＴまたはＦＷ設備であることを特徴とする請求項１に記載の方法。
前記ステップＢは、
ＵＴＣが、前記第１設備からのパケットを受信し、前記第１設備からのパケットのインターネットプロトコル（ＩＰ）ヘッダの後にＵＤＰトンネルヘッダ（ＵＴＨ）を挿入し、その後、ＮＡＴまたはＦＷ設備を介して、当該パケットをＵＴＳに伝送するステップＢ１１と、
ＵＴＳが、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信し、当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレスを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレスをＵＤＰトンネル情報の一つの記録項目として記憶し、前記ＵＤＰトンネルを確立するステップＢ１２と、を含み、
前記ステップＣは、ＵＴＳが前記新しい送信元ＩＰアドレスで前記ＵＴＣから送信されたパケットの送信元ＩＰアドレスを取り換え、ＵＴＳがＵＴＣから送信されたパケットを第２設備に伝送するステップＣ１１と、
を含むことを特徴とする請求項１に記載の方法。
前記ステップＢ１２において、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されたパケットを受信した後、ＵＴＳがＵＴＣから送信されたパケットの送信元ＩＰアドレス及びＵＴＨの送信元ポートをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索するステップをさらに含み、関連の記録項目が検出された場合、直接にステップＣ１１に進み、そうでない場合、ＵＴＳが当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレスを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレスをＵＤＰトンネル情報の一つの記録項目として記憶し、ステップＣ１１に進むことをさらに含むことを特徴とする請求項６に記載の方法。
前記ステップＢは、
ＵＴＣが、前記第１設備からのパケットを受信し、前記第１設備からのパケットのＩＰヘッダの後にＵＤＰトンネルヘッダ（ＵＴＨ）を挿入し、その後、ＮＡＴまたはＦＷ設備を介して、当該パケットをＵＴＳに伝送するステップＢ２１と、
ＵＴＳが、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信し、当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレス及び新しい送信元ポートを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＤＰトンネルヘッダ負荷での送信元ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレス及び新しい送信元ポートをＵＤＰトンネル情報の一つの記録項目として記憶し、前記ＵＤＰトンネルを確立するステップＢ２２と、を含み、前記ステップＣは、ＵＴＳが、前記新しい送信元ＩＰアドレスでＵＴＣから送信されたパケットの送信元ＩＰアドレスを取り換え、前記新しい送信元ポートでＵＤＰトンネルヘッダ負荷での送信元ポートを取り換え、ＵＴＣから送信されたパケットを第２設備に伝送するステップＣ２１と、
を含むことを特徴とする請求項１に記載の方法。
前記ステップＢ２２において、ＮＡＴまたはＦＷ設備を介してＵＴＣから送信されるパケットを受信した後、ＵＴＳが、ＵＴＣから送信されたパケットの送信元ＩＰアドレス及び送信元ポート、並びにＵＤＰトンネルヘッダ負荷での送信元ポートをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索するステップをさらに含み、関連の記録項目が検出された場合、直接にステップＣ２１に進み、そうでない場合、ＵＴＳが当該ＵＴＣから送信されたパケットに新しい送信元ＩＰアドレス及び新しい送信元ポートを割り当て、ＵＤＰトンネルヘッダの送信元ポート及び送信先ポート、ＵＤＰトンネルヘッダ負荷での送信元ポート、ＵＴＣから送信されたパケットの送信元ＩＰアドレス、並びにＵＴＣから送信されたパケットに割り当てた新しい送信元ＩＰアドレス及び新しい送信元ポート情報をＵＤＰトンネル情報の一つの記録項目として記憶し、ステップＣ２１に進むことをさらに含むことを特徴とする請求項８に記載の方法。
前記ステップＣは、
第２設備からのパケットを受信したＵＴＳが、第２設備からのパケットの送信先ＩＰアドレスをインデックスとして、ＵＴＳに記憶されたＵＤＰトンネル情報を検索して、関連の記録項目が検出された場合、ステップＣ３２に進み、そうでない場合、当該第２設備からのパケットを無視し、プロセスを終了させるステップＣ３１と、
ＵＴＳが、第２設備からのパケットの送信先ＩＰアドレスを関連の記録項目での送信元ＩＰアドレスに取り換え、当該記録項目でのＵＤＰトンネルヘッダの送信元ポートを送信先ポートとしＵＤＰトンネルヘッダの送信先ポートを送信元ポートとするＵＤＰトンネルヘッダを第２設備からのパケットのＩＰヘッダの後に挿入し、ＮＡＴまたはＦＷ設備を介して、第２設備からのパケットをＵＴＣに伝送するステップＣ３２と、
ＵＴＣが、ＮＡＴまたはＦＷ設備を介してＵＴＳから送信されるパケットを受信し、ＵＴＳから送信されたパケットでのＵＤＰトンネルヘッダを削除し、ＵＴＳから送信されたパケットを第１設備に伝送するステップＣ３３と、
をさらに含むことを特徴とする請求項６ないし９のいずれか１項に記載の方法。
前記ＵＤＰトンネルヘッダが、標準のＵＤＰヘッダと、もとのパケットに搭載されたパケットタイプを表すプロトコルフィールドと、を含むことを特徴とする請求項６ないし９のいずれか１項に記載の方法。
前記ＵＤＰトンネルヘッダが、ＵＤＰトンネルパケットタイプを表すタイプフィールドをさらに含むことを特徴とする請求項１１に記載の方法。