JP5477449B2 - 名前解決システム、方法及びプログラム - Google Patents

Description

本発明は、名前解決システム、方法及びプログラムに関し、例えば、ＩＰｖ４通信網において、グローバルアドレスの枯渇を抑制するため、複数のアクセスノードにて１つのグローバルアドレスを共用する際のアドレス変換を実現する方式に関するものである。

従来、複数のプライベートアドレスを持つノード群をレイヤ４のヘッダ情報に含まれるポート番号にマッピングして１つのグローバルアドレスを共用する方法として、ＮＡＴ（Network Address Translation）やＮＡＰＴ（Network Address Port Translation）による方式が一般的に用いられている（非特許文献１及び２参照）。

特開２００６−５７５４号公報

ＲＦＣ７９１，「INTERNET PROTOCOL」 ＲＦＣ３０２２，「Traditional IP Network Address Translator（Traditional NAT）」

近年、ネットワークの普及により、グローバルアドレスとして割り当てるＩＰｖ４アドレスが枯渇し、ＩＰｖ６アドレスの必要性及び普及が話題となっている。

しかし、現実的には、ＩＰｖ４にしか対応できない端末が広く普及しており、ユーザー負担を考えると、キャリア側としてもＩＰｖ６対応機器のリプレースを簡単には強制できないという実情がある。

そのため、ＩＰｖ６環境へ移行する期間においても、ＩＰｖ４環境とＩＰｖ６環境とが混在し、これからの将来においても、ＩＰｖ４アドレスが引き続き使用され、重要なポジションを占めることが考えられる。

そしてまた、インターネットへのアクセスコントロール部分でＮＡＴを利用し、エンドユーザーにプライベートなＩＰｖ４アドレスを与える仕組みが求められている。

しかし、従来のＮＡＴ方式の場合、１つのグローバルＩＰｖ４アドレスを複数のユーザー間で共有しなければならないので、ポート数に限界が生じ得る。例えば、６万５５３５個のポート数を複数のユーザーで共有しなければならず、例えば、２０００ユーザーで共有する場合には、１ユーザー当たり２５〜３０個のセッション数しか利用できなくなってしまう。

例えば画像を取得する場合、画像毎にセッションを使用するマルチセッションを採用するが、取得する画像数が多くなるとセッション数も多くなる。ＧｏｏｇｌｅＭａｐｓで米国サンフランシスコ周辺の画像を取得する場合は通常３０セッションで表示できるが、１５セッションだと半分程度の画像しか表示できず、５セッションだと「サーバが見つかりませんでした」というエラーが出てしまう。その他の例だと、Ｙａｈｏｏ（登録商標）のトップページで１０〜２０セッション、ｉＴｕｎｅｓ（登録商標）で２３０〜２７０セッション、ＹｏｕＴｕｂｅ（登録商標）で９０セッション、楽天（登録商標）で５０〜６０セッション程度が必要とされる。

このように、マルチセッションで短時間に大量の情報を送受するＷｅｂアプリケーションに対応可能なＩＰｖ４環境を提供するには、キャリアグレードなアドレス変換方式が必要となる。

また、従来のアドレス変換技術（例えばＮＡＴ）は、グローバルアドレスを有効利用する技術であるが、近年のピア・ツー・ピア通信のアプリケーションやＶｏＩＰ通信のアプリケーション等といったエンド・ツー・エンド型のアプリケーションは利用できず、アプリケーションが制約されるという課題もある。

そのため、「１万ユーザー以上に対応でき、１ユーザ当たり１００セッション利用できること」、「例えばＳＯＨＯで利用しているルータのように、基本的にアプリケーションを妨害しないオープンな仕様であること」、「高い可用性があること」、「ｅｎｄ−ｔｏ−ｅｎｄでの双方向通信のサポートを実現できること」を要件とした名前解決システム、方法及びプログラムが求められている。

かかる課題を解決するため、第１の本発明の名前解決システムは、問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決システムにおいて、（１）複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段と、（２）クライアントからの問い合わせを受信する問い合わせ受信手段と、（３）問い合わせに係るホスト名又はホストのアドレス情報に基づいてアドレス情報記録手段を参照し、問い合わせを受けたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名の検索を行う検索手段と、（４）検索手段により検索されたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名を上記クライアントに通知を行う通知手段とを備えることを特徴とする。

第２の本発明の名前解決方法は、問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決方法において、名前解決システムが、複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段と、問い合わせ受信手段と、検索手段と、通知手段とを備え、（１）問い合わせ受信手段が、クライアントからの問い合わせを受信する問い合わせ受信工程と、（２）検索手段が、問い合わせに係るホスト名又はホストのアドレス情報に基づいてアドレス情報記録手段を参照し、問い合わせを受けたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名の検索を行う検索工程と、（３）通知手段が、検索手段により検索されたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名をクライアントに通知を行う通知工程とを有することを特徴とする。

第３の本発明の名前解決プログラムは、問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決プログラムにおいて、コンピュータを、（１）複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段、（２）クライアントからの問い合わせを受信する問い合わせ受信手段、（３）問い合わせに係るホスト名又はホストのアドレス情報に基づいてアドレス情報記録手段を参照し、問い合わせを受けたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名の検索を行う検索手段、（４）検索手段により検索されたホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又はホスト名を上記クライアントに通知を行う通知手段として機能させることを特徴とする。

本発明によれば、高い透過性、高い接続確立性、公平性の確保、高スループット、高可用性を実現でき、できる限り通信を阻害しないオープンな仕様を提供できる。

第１の実施形態のネットワークへの接続構成を示す構成図である。 第１の実施形態のアドレス変換通信装置の内部構成を示す内部構成図である。 第１の実施形態のアドレス変換通信装置のグローバルアドレス割り当て範囲を説明する図である。 ＩＰヘッダ領域を示す構成図である。 第１の実施形態のオプション領域に付与するエクステンションオプションヘッダの構成を説明する図である。 第１の実施形態のノードの内部構成を示す内部構成図である。 第１の実施形態のＤＮＳサーバの登録データのレコード例を示す図である。 第１の実施形態のプライベートネットワークからネットワークへのパケット転送時のアドレス変換処理を示すフローチャートである。 第１の実施形態のネットワークからプライベートネットワークへのパケット転送時のアドレス変換処理を示すフローチャートである。

（Ａ）第１の実施形態
以下では、本発明の名前解決システム、方法及びプログラムの第１の実施形態について図面を参照しながら説明する。

（Ａ−１）第１の実施形態の構成
（Ａ−１−１）ネットワーク接続構成
図１は、第１の実施形態のネットワークへの接続構成を示す構成図である。図１において、第１の実施形態の構成は、ネットワーク２に接続するＤＮＳサーバ３、ノードＡ〜Ｃ、アドレス変換通信装置１−１及び１−２を少なくとも有して構成されるものである。

図１に示すネットワーク構成は、ＩＰｖ４を使用した通信網であり、ノードＡとノードＣとの間のトラフィック、ノードＢとノードＣとの間のトラフィック、ノードＡとノードＢとの間のトラフィックが、必ずネットワーク２を経由して行われるものとする。

ネットワーク２は、例えばインターネットに相当するネットワークであり、通信プロトコルとしてはＩＰ（Internet protocol）を採用し、ネットワーク２上ではグローバルＩＰｖ４アドレスが用いられる。また、ネットワーク２は、有線網、無線網のいずれも適用することができる。

ノードＡ及びノードＢは、それぞれのプライベートネットワークに接続するノードであり、それぞれのプライベートネットワークにおいては、アドレスリソースの節約のために、ローカルＩＰｖ４アドレスを用いるものとする。

ノードＣは、ネットワーク２に接続するノードであり、グローバルアドレスが直接割り当てられているノードである。

アドレス変換通信装置１−１及び１−２は、ノードＡ及びノードＢの属するプライベートネットワーク側とネットワーク２側との間のアドレス変換を行うものである。アドレス変換通信装置１−１は、ノードＡの属するプライベートネットワークとネットワーク２とに接続するものであり、アドレス変換通信装置１−２は、ノードＢの属するプライベートネットワークとネットワーク２とに接続するものである。

アドレス変換通信装置１−１及び１−２によるアドレス変換方法は、ネットワーク２上ではグローバルアドレスを利用するように、送信元ＩＰアドレス及び宛先ＩＰアドレスを変換処理すると共に、プライベートネットワークに属するノードのプライベートアドレスをオプションに挿入する処理を行う方法を採用する。

例えば、ノードＡからノードＣへのパケットについては、ノードＡからのパケットヘッダに含まれる送信元ＩＰアドレスをグローバルアドレスに変換すると共に、当該パケットの送信元ＩＰアドレスをオプションに挿入する。

逆に、ノードＣからノードＡへのパケットについては、ノードＣからのパケットに含まれる宛先ＩＰアドレス（グローバルアドレス）を、ノードＡのプライベートアドレスに変換する。

このように、アドレス変換情報をレイヤ３のネットワーク層に閉じているため、ＩＰｖ４でＮＡＴを利用しても、トランスポート層のポート数に関する制約が無く、グローバルアドレスで接続している際と同様に利用することができる。

ＤＮＳサーバ３は、ＤＮＳリゾルバから問い合わせを受けたホストのＩＰアドレスを調べて通知する名前解決システムである。

（Ａ−１−２）アドレス変換装置の内部構成
図２は、アドレス変換通信装置１（１−１及び１−２）の内部構成を示す内部構成図である。なお、アドレス変換通信装置１−１及び１−２はいずれも対応する機能を備えるから、図２では、アドレス変換通信装置１と表記する。

図２において、アドレス変換通信装置１は、アドレス変換処理部１１、グローバルアドレス設定部１２、ネットワーク側インタフェース部１３、構内網側インタフェース部１４を有して構成される。

ネットワーク側インタフェース部１３は、ネットワーク２側と接続するインタフェースであり、ネットワーク２からパケットを受信すると受信パケットをアドレス変換処理部１１に与え、又アドレス変換処理部１１から送信パケットを受け取ると送信パケットをネットワーク２に向けて送信するものである。

構内網側インタフェース部１４は、ノードＡ、ノードＢが属するプライベートネットワークに接続するインタフェースであり、ノードＡ、ノードＢの属するプライベートネットワークからパケットを受信すると受信パケットをアドレス変換処理部１１に与え、又アドレス変換処理部１１から送信パケットを受け取ると送信パケットをプライベートネットワークに向けて送信するものである。

グローバルアドレス設定部１２は、ネットワーク２上で使用するグローバルアドレスを保持するものである。このとき、グローバルアドレス設定部１２は、グローバルアドレスのサービス毎の割り当て範囲が設定されている。

図３は、グローバルアドレス設定部１２に設定されるグローバルアドレスの割り当て範囲を示すグローバルアドレス割り当てテーブルである。

図３に示すように、グローバルアドレス割り当てテーブルは、サービス項目とグローバルアドレス項目とを備え、例えば、サービスＡについては、「10.0.0.0〜10.255.255.255」のグローバルアドレスを使用し、サービスＢについては、「192.168.0.0〜192.168.255.255」のグローバルアドレスを使用することを設定する。

アドレス変換処理部１１は、ネットワーク側インタフェース部１３又は構内網側インタフェース部１４から受け取ったパケットのヘッダ変換処理を行うものである。

ここで、図４は、パケットのＩＰヘッダ領域を示す構成図である。図４に示すように、ＩＰヘッダ領域は、バージョン（Version）、ＩＨＬ（Internet Header Length）、ＴｏＳ（Type Of Service）、パケット長、Identification、Flags、フラグメントオフセット、ＴＴＬ（Time To Live）、プロトコル、ヘッダチェックサム、送信元アドレス、宛先アドレス、オプション及びパディングからなる。

バージョン（Version）は、ＩＰバーションを示す領域であり、第１の実施形態ではＩＰｖ４を示す４が挿入される。ＩＨＬ（Internet Header Length）は、ＩＰｖ４ヘッダの長さ及びペイロードの先頭を示す領域であり、ＴｏＳ（Type Of Service）は、サービスタイプを示す領域であり、又パケット長は、ペイロードのデータ長を示す領域である。

また、Identificationは、フラグメントの組立に関する識別値を示す領域であり、Flags及びフラグメントオフセットは、フラグメントする際に利用される領域である。

また、ＴＴＬ（Time To Live）は、データの最大寿命を指示する領域であり、この値が０になると、データは破棄される。プロトコルは、ＩＰの次の階層のプロトコルを指示する領域であり、ヘッダチェックサムは、ヘッダの信頼性を保証するために、ＩＰｖ４ヘッダ内のすべての１６ビットワードの合計を対象に計算されたチェックサムが挿入される。

オプションは、拡張機能を指定する可変長領域である。第１の実施形態では、アドレス変換処理部１１が、プライベートネットワークからネットワーク２に向けてパケットを送信する際に、送信元ノードのプライベートアドレスをオプション領域に転記する際に利用する。パディングは、ヘッダ長を３２ビット単位に調整するデータ領域である。

アドレス変換処理部１１は、構内網側インタフェース部１４からパケットを受け取ると、グローバルアドレス設定部１２に設定されているグローバルアドレスを参照しながら、当該パケットヘッダの変換処理を行う。この場合の具体的な処理として、アドレス変換処理部１１は、ヘッダ情報に含まれている送信元アドレスをグローバルアドレスに書き換える書換処理、送信元アドレス（プライベートアドレス）をオプション領域に付与する送信元アドレスエクステンションオプションヘッダの付与処理、ＩＨＬの書換処理、ホップ数を減算してＴＴＬを書き換える書換処理、ヘッダチェックサムの再計算及び書換処理を行う。

ここで、アドレス変換処理部１１によるアドレスエクステンションオプションヘッダの付与処理について図５を参照して説明する。

図５は、オプション領域に挿入するエクステンションオプションヘッダの構成を示す構成図である。図５に示すように、エクステンションオプションヘッダは、オプションタイプ、オプション長、オプションデータ（前半及び後半）を有して構成される。

オプションタイプは、オプションタイプを示す領域であり、例えば８ビットからなる。

第０ビット目（Copied Flag：1bits）は、フラグメント分割される際、アドレス変換処理とフラグメント結合処理が独立となるよう、全てのフラグメントパケットに同じオプション内容がコピーされる必要があるため、例えば固定値１を取る。

第１ビット目〜第２ビット目（Option Class：2bits）は、制御用として、例えば固定値０を取る。

第３ビット目〜第７ビット目（Option Number：5bits）は、送信元アドレスエクステンションオプション又は宛先アドレスエクステンションオプションを利用することを示すオプション番号を挿入する領域である。

Option Numberとしては、例えば現在未使用の２６、２７をそれぞれ送信元アドレスエクステンションオプション、宛先アドレスエクステンションオプションを示すオプション番号として利用し得る（参考文献：ＩＰオプション番号，http://www.iana.org/assignments/ip-parameters）。

例えば、送信元アドレスエクステンションオプションのオプションタイプ値を「１５４」、宛先アドレスエクステンションオプションのオプションタイプ値を「１５５」とすることができる。

オプション長は、該当するオプション領域（オプションタイプ、オプション長、データ部の合計）のデータ長をオクテット単位で表現するものであり、例えば固定値６を取る。

オプションデータは、プライベートアドレスの値がそのまま転記される領域である。

また、送信元アドレスエクステンションオプションヘッダの付与を行うためヘッダ長が大きくなるので、アドレス変換処理部１１は、パケットサイズがＭＴＵ（Maximum Transmission Unit）を超えたか否かを判断し、パケットサイズがＭＴＵを超えた場合フラグメント処理を行う。

このとき、アドレス変換処理部１１は、図４のヘッダ領域のFlags及びフラグメントオフセットの領域について次のような処理を行う。

Flagsは、３ビットの制御フラグを示す領域であり、当該領域の左から第０ビット目は予約領域であり０を挿入し、第１ビット目はフラグメントをする又はしないを示す領域であり、第２ビット目はフラグメントの終了か否かを示す領域である。また、フラグメントオフセットは、当該フラグメントデータが元のデータのどこに属するかを示す領域である。

アドレス変換処理部１１は、フラグメント処理を行う場合、Flagsの第１ビット目の制御ビットを、フラグメントを行うことを示す情報とし、フラグメントされたパケットに応じて第２ビット目を変換する。

上記のようにしてヘッダ変換処理をしたパケットを、アドレス変換処理部１１はネットワーク側インタフェース部１３に与える。

また、アドレス変換処理部１１は、ネットワーク側インタフェース部１３からパケットを受け取ると、当該パケットヘッダの変換処理を行う。この場合の具体的な処理として、アドレス変換処理部１１は、宛先アドレス領域をプライベートアドレスに書き換える書換処理、オプション領域に付与されている宛先アドレスエクステンションオプションヘッダの削除処理、ＩＨＬの書換処理、ホップ数を減算してＴＴＬを書き換える書換処理、ヘッダチェックサムの再計算及び書換処理を行う。

なお、宛先アドレスエクステンションオプションヘッダについては、上記のように図５を用いて説明したエクステンションオプションヘッダである。

そして、アドレス変換処理部１１は、ネットワーク２側から受け取ったパケットヘッダの変換処理を行うと、構内網側インタフェース部１４に与える。

（Ａ−１−３）ノードの内部構成
次に、ノードの内部構成について図６を参照しながら説明する。

図６は、ノードの内部構成を示す内部構成図である。図６に示すように、ノードは、送受信部５１、パケット形成部５２を有して構成される。

送受信部５１は、ネットワーク２からのパケットを受信したり、又はパケット形成部５２により形成されたパケットを送信するものである。

パケット形成部５２は、送信パケットを形成するものであり、エクステンションオプションヘッダ付与部５３を有する。

エクステンションオプションヘッダ付与部５３は、宛先ノードがグローバルアドレスとプライベートアドレスの組み合わせにより一意に指定される場合に、当該パケットヘッダのオプション領域にプライベートアドレスを付与するものである。このようにすることで、ネットワーク２上に送出するパケットの宛先ＩＰアドレスをグローバルアドレスとし、オプション領域にプライベートアドレスを含むヘッダ情報を形成することができる。

また、エクステンションオプションヘッダ付与部５３は、対向ノードからパケットを受信した場合、受信パケットヘッダのオプション領域に含まれている送信元アドレスエクステンションオプションヘッダを用いて、宛先アドレスエクステンションオプションヘッダを作成することで実現できる。

なお、オプション領域に付与するエクステンションオプションヘッダの構成は、図５に示す構成と同じであり、エクステンションオプションヘッダ付与部５３は、プライベートアドレスの付与の際に、エクステンションオプションヘッダ付与部５３は、オプションタイプの書換処理を行う。

（Ａ−１−４）ＤＮＳサーバの構成
ＤＮＳサーバ３は、上述したように、ＤＮＳリゾルバから問い合わせを受けたホストのＩＰアドレスを調べて返信するものである。

図７（Ａ）は、ＤＮＳサーバ３の内部構成を示す内部構成図である。図７（Ａ）に示すように、ＤＮＳサーバ３は、問い合わせ受信部３１、検索部３２、登録データ記録部３３、通知部３４を少なくとも有して構成される。

問い合わせ受信部３１は、ＤＮＳリゾルバから名前解決の問い合わせを受信するものである。

検索部３２は、登録データ記録部３３を参照しながら、問い合わせ対象のホスト名からＩＰアドレスを検索するものである。また、検索部３２は、検索したＩＰアドレスを通知部３４に与えるものである。

通知部３４は、検索部３２により検索されたＩＰアドレスを問い合わせ元のＤＮＳリゾルバに対して通知するものである。

登録データ記録部３３は、登録データをレコードする記憶領域又はデータベースである。

図７（Ｂ）は、ＤＮＳサーバ３の登録データ記録部３３に登録される登録データの例を示す。図７（Ｂ）に例示するレコードは、グローバルＩＰｖ４アドレス（３２ビット）及びプライベートＩＰｖ４アドレス（３２ビット）がホスト名に対応付けられて定義される。ここでは、オプション領域を使用するので「Ｏレコード」と呼ぶことにする。

例えば、図７に示すＯレコードは、ホスト名「www.xyz.com」のグローバルＩＰｖ４アドレス「162.162.162.11」及びプライベートＩＰｖ４アドレス「192.168.0.1」がレコードされる。

このように定義することで、宛先ＩＰアドレスを知ることができると共に、オプション領域に付与する宛先のプライベートアドレスも取得することができる。その結果、ＮＡＴトラバーサル等の技術を用いなくても、ｅｎｄ−ｔｏ−ｅｎｄで双方向通信を行え、高い透過性を提供できる。

なお、図７（Ｂ）は、ホスト名からＩＰアドレスを調べる正引きの登録データをレコードする場合を示すが、ＩＰアドレスからホスト名を調べる逆引きの登録データをレコードするようにしてもよい。

（Ａ−２）第１の実施形態の動作
次に、第１の実施形態のアドレス変換処理の動作について図面を参照しながら説明する。なお、以下では、ノードＡとノードＣとの間のトラフィックについて、アドレス変換通信装置１−１がアドレス変換処理を行う場合を説明する。

図８は、プライベートネットワーク側からネットワーク側へのパケットに対するアドレス変換通信装置１−１の処理を示すフローチャートである。

まず、ノードＡがノードＣに向けて送信したパケットは、アドレス変換通信装置１−１に与えられる（ステップＳ１０１）。このときのパケットヘッダ情報は、宛先ＩＰアドレスにはノードＣのグローバルアドレスが挿入され、送信元ＩＰアドレスにはノードＡのプライベートアドレスが挿入されている。

パケットがアドレス変換通信装置１−１に与えられると、アドレス変換通信装置１−１において、パケットヘッダ情報の変換処理が行われる（ステップＳ１０２）。

このとき、アドレス変換通信装置１−１のアドレス変換処理部１１は、送信元ＩＰアドレス（ノードＡのプライベートアドレス）を含む送信元エクステンションオプションヘッダを付与する。また、アドレス変換処理部１１は、ＩＨＬの書換及びホップ数の減算・ヘッダチェックサムの再計算及び書換を行う。

次に、アドレス変換処理部１１は、送信元エクステンションオプションヘッダの付与に伴い、パケット長が大きくなるため、パケットサイズがＭＴＵを超えていないかを判断する（ステップＳ１０３）。

そして、パケットサイズがＭＴＵを超えていない場合、アドレス変換通信装置１−１は、アドレス変換したパケットをネットワーク２に向けて送出する（ステップＳ１０４）。

一方、パケットサイズがＭＴＵを超えている場合、アドレス変換処理部１１は、形成したパケットを分割するフラグメント処理を行う（ステップＳ１０５）。

このとき、アドレス変換処理部１１は、パケットヘッダのIndication、Flags及びフラグメントオフセットの書換処理を行い、分割したパケットをネットワーク２に向けて送出する（ステップＳ１０４）。

図９は、ネットワーク２側からプライベートネットワーク側へのパケットに対するアドレス変換通信装置１−１の処理を示すフローチャートである。

まず、ノードＣは、宛先ＩＰアドレスをノードＡのグローバルアドレス及び送信元ＩＰアドレスをノードＣのグローバルアドレスとし、オプション領域にノードＡのプライベートアドレスを付与したパケットを形成し、このパケットをノードＡに向けて送信する。

このとき、ノードＣがノードＡから受信したパケットを受信した場合、受信パケットの送信元ＩＰアドレス（グローバルアドレス）を宛先ＩＰアドレスに書き換えると共に、受信したＩＰヘッダのオプション領域に含まれているノードＡのプライベートアドレスを用いて、宛先アドレスエクステンションオプションヘッダを付与してパケットを形成する。

また、ノードＡからのパケットを受信しない場合、ノードＣはＤＮＳサーバ３に対してノードＡのＩＰアドレスを問い合わせ、ノードＡのグローバルアドレス及びプライベートアドレスを取得し、このグローバルアドレス及びプライベートアドレスに基づいて、宛先ＩＰアドレスをノードＡのグローバルアドレスとし、ノードＡのプライベートアドレスを含む宛先アドレスエクステンションオプションヘッダを付与してパケットを形成する。

ノードＣからノードＡ宛のパケットがアドレス変換通信装置１−１に与えられると（ステップ２０１）、アドレス変換通信装置１−１のアドレス変換処理部１１が受信パケットのヘッダ変換処理を行う（ステップ２０２）。

このとき、アドレス変換処理部１１は、受信パケットのＩＰヘッダの宛先ＩＰアドレスをオプション領域に含まれている宛先アドレスエクステンションオプションヘッダに記述されたノードＡのプライベートアドレスに書き換え、オプション領域に含まれている宛先アドレスエクステンションオプションヘッダを削除する。また、アドレス変換処理部１１は、ＩＨＬの書換及びホップ数の減算・ヘッダチェックサムの再計算及び書換を行う。この処理に伴うパケット長の増大の恐れはないため、この後は、チェック不要で、構内網側インタフェースへパケットが送出されることになる（ステップＳ２０３）。

上記では、ノードＡとノードＣとの間のトラフィックを例示して説明したが、ノードＢとノードＣとの間のトラフィックについても、アドレス変換通信装置は上記同様の処理を行う。

（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、アドレス変換情報がレイヤ３のネットワーク層に閉じているため、ＩＰｖ４でＮＡＴを利用しても、トランスポート層のポート数に関する制約がなく、グローバルアドレスで接続しているときと同様に利用することができる。

また、第１の実施形態によれば、ノードの識別子としてプライベートアドレスをそのまま識別情報領域に転記するため、アドレス変換通信装置でアドレス変換処理（ＮＡＴ処理）のマッピングを行うための記憶領域又はデータベースを保持する必要がない。

さらに、第１の実施形態によれば、ＤＮＳの拡張仕様としてエクステンション情報の送受の仕組みを提供することにより、Ｅｎｄ−ｔｏ−Ｅｎｄでの疎通も行うことができるため、ＮＡＴトラバーサルのための特別なプロトコル利用が不要となる。

（Ｂ）第２の実施形態
次に、本発明の名前解決システム、方法及びプログラムの第２の実施形態について図面を参照しながら説明する。

第１の実施形態では、ノードＡ又はノードＢとノードＣとの間のトラフィックを例示したが、第２の実施形態では、ノードＡとノードＢとの間のトラフィックを例示して説明する。

（Ｂ−１）第２の実施形態の構成及び動作
第２の実施形態の構成は第１の実施形態の構成と同じであるので、第２の実施形態でも図１を用いて説明する。

また、アドレス変換装置１−１及び１−２の内部構成も第１の実施形態と同じであり、第２の実施形態でも図２を用いて説明する。

図１において、ノードＡ及びノードＢはそれぞれ異なるプライベートネットワークに属するノードであり、両ノード間で通信を行う場合、交換されるトラフィックは必ずネットワーク２を経由するものとする。

ノードＡとノードＢとの間で通信を行う場合のアドレス変換処理について、図８及び図９を参照しながら説明する。

まず、ノードＡからノードＢに向けてパケットを送信する場合、ノードＡは、送信元ＩＰアドレスをノードＡのプライベートアドレス、宛先ＩＰアドレスをノードＢのグローバルアドレスとすると共に、オプション領域にノードＢのグローバルアドレスを含む宛先アドレスエクステンションオプションヘッダを付与してパケットを形成して送信する。

このとき、ノードＡがノードＢのプライベートアドレスを知らない場合には、ＤＮＳサーバ３に問い合わせをして、ノードＢのグローバルアドレス及びプライベートアドレスを取得し、パケットを形成する。

プライベートネットワークを介してノードＡの送信パケットがアドレス変換通信装置１−１に与えられると（図８のステップＳ１０１）、アドレス変換通信装置１−１のアドレス変換処理部１１は、受信パケットのヘッダ変換処理を行う（ステップＳ１０２）。

アドレス変換処理部１１は、第１の実施形態と同様に、送信元ＩＰアドレスをグローバルアドレスに変換すると共に、送信元アドレスエクステンションオプションヘッダを付与する。

このとき、オプション領域には、宛先アドレスエクステンションオプションヘッダが付与されているので、これとは別に送信元アドレスエクステンションオプションヘッダが付与されることになる。

また、アドレス変換処理部１１は、第１の実施形態と同様に、ＩＨＬの書換及びホップ数の減算・ヘッダチェックサムの再計算及び書換を行う。

次に、アドレス変換処理部１１は、送信元エクステンションオプションヘッダ及び宛先エクステンションオプションヘッダの付与するため、パケットサイズがＭＴＵを超えていないかを判断し（ステップＳ１０３）、パケットサイズがＭＴＵを超えていない場合、当該パケットをネットワーク２に向けて送出し（ステップＳ１０４）、パケットサイズがＭＴＵを超えている場合、形成したパケットに対してフラグメント処理を行い（ステップＳ１０５）、分割したパケットをネットワーク２に送出する（ステップＳ１０５）。

ネットワーク２を経由して送信されたパケットがノードＢの属するアドレス変換通信装置１−２に与えられると（図９のステップＳ２０１）、アドレス変換通信装置１−２のアドレス変換処理部１１により、受信パケットのヘッダ変換処理が行われる（Ｓ２０２）。

このとき、アドレス変換処理部１１は、受信パケットの宛先ＩＰアドレスをオプション領域に含まれている宛先アドレスエクステンションオプションヘッダに記述されたノードＢのプライベートアドレスに変換すると共に、オプション領域の宛先アドレスエクステンションオプションヘッダを削除する。

また、アドレス変換処理部１１は、ＩＨＬの書換及びホップ数の減算・ヘッダチェックサムの再計算及び書換を行う。この処理に伴うパケット長の増大の恐れはないため、この後は、チェック不要で、構内網側インタフェースへパケットが送出されることになる（ステップＳ２０３）。

（Ｂ−２）第２の実施形態の効果
以上のように、第２の実施形態によれば、それぞれ異なるプライベートネットワークに属するノード間の通信についても、第１の実施形態と同様の効果を得ることができる。

１−１及び１−２…アドレス変換通信装置、１１…アドレス変換処理部、１２…グローバルアドレス設定部、１３…ネットワーク側インタフェース部、１４…構内網側インタフェース、２…ネットワーク、３…ＤＮＳサーバ、５１…送受信部、５２…パケット形成部、５３…エクステンションオプションヘッダ付与部。

Claims (3)

1. 問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決システムにおいて、
   複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段と、
   クライアントからの問い合わせを受信する問い合わせ受信手段と、
   上記問い合わせに係るホスト名又はホストのアドレス情報に基づいて上記アドレス情報記録手段を参照し、問い合わせを受けた上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名の検索を行う検索手段と、
   上記検索手段により検索された上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名を上記クライアントに通知を行う通知手段と
   を備えることを特徴とする名前解決システム。
2. 問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決方法において、
   名前解決システムが、複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段と、問い合わせ受信手段と、検索手段と、通知手段とを備え、
   問い合わせ受信手段が、クライアントからの問い合わせを受信する問い合わせ受信工程と、
   検索手段が、上記問い合わせに係るホスト名又はホストのアドレス情報に基づいて上記アドレス情報記録手段を参照し、問い合わせを受けた上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名の検索を行う検索工程と、
   通知手段が、上記検索手段により検索された上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名を上記クライアントに通知を行う通知工程と
   を有することを特徴とする名前解決方法。
3. 問い合わせを受けたホストのアドレス情報又はホスト名のいずれかを検索して通知する名前解決プログラムにおいて、
   コンピュータを、
   複数のホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報として記録するアドレス情報記録手段、
   クライアントからの問い合わせを受信する問い合わせ受信手段、
   上記問い合わせに係るホスト名又はホストのアドレス情報に基づいて上記アドレス情報記録手段を参照し、問い合わせを受けた上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名の検索を行う検索手段、
   上記検索手段により検索された上記ホストのグローバルアドレス及びプライベートアドレスを有するアドレス情報又は上記ホスト名を上記クライアントに通知を行う通知手段
   として機能させることを特徴とする名前解決プログラム。

Images