JP4595647B2 - トランスレータ - Google Patents

Description

本発明は，Internet Protocol Version 4（IPv4）アドレスと，Internet Protocol Version 6（IPv6）との間のアドレス変換方式に関する。

プロトコルとしてInternet Protocol version 4を使用する網（以下IPv4網と呼ぶ)とInternet Protocol version 6を使用する網（以下IPv6網と呼ぶ)とを接続する方式としてNAT-PT(http://www.ietf.org/rfc/rfc2766.txtのpp6-18,およびrfc2765.txtのpp9-22参照)，SOCKS64(http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-socks-gateway-05.txt参照)等が知られている。

いずれも基本的にはIPパケットのフォーマットをIPv4とIPv6との間で相互変換を行う。例えば，IPv4アドレスとIPv6アドレスとの間の変換を行う。以下では，この変換を行う装置をトランスレータと呼ぶ。トランスレータには，IPv4アドレスとIPv6アドレスとの対応関係を保持しておく必要がある。この対応関係を通信が発生するたびに動的に作成する場合に，そのきっかけとしてドメインネームシステム（DNS）の名前解決が利用される(アスキー出版，インターネットRFC事典，pp323-329を参照)。

DNSはウェブのURLのような人間にわかりやすい名前(文字列)を，IPアドレスに変換するシステムである。以下名前をIPアドレスに変換する操作を名前解決と呼ぶ。今日ではインターネット上のほぼすべてのアプリケーションがこのDNSを利用して通信相手のIPアドレスを取得している。

トンラスレータは，通信開始にあたってやり取りされるDNSのメッセージを常に監視しており，名前解決の要求メッセージを変換情報(IPアドレスの対応関係等)を作成するきっかけとする。具体的には，IPv6端末がある名前について名前解決を行ったとき，その応答であるIPアドレスがIPv4アドレスであった場合，このIPv4アドレスをIPv6アドレスに書き換えてIPv6端末に送り返す。そして，書き換える前のIPv4アドレスと書き換えたIPv6アドレスを対応付ける。つまり，名前解決の応答メッセージを横取りして書き換え，この書き換える前と書き換えた情報をもとに変換情報を作成する。ここで動的に作成された変換情報は一時的なものであるから，通信が終了すると廃棄される。

アスキー出版，インターネットRFC事典，pp323-329を参照

上記従来技術では，端末が移動することを前提としていないため，IPv4アドレスとIPv6アドレスの対応関係をトランスレータ内部でのみ管理しており，複数のトランスレータ相互間で，これら対応関係をやりとりされない。

各トランスレータはある一定のサービス領域をもち，各装置がもっているIPv4アドレスとIPv6アドレスの対応関係をやりとりできないため，変換サービスを受けている端末が，各トランスレータのサービス領域をまたがって移動すると通信が断絶してしまう。

また，すでに説明したようにIPv4アドレスとIPv6アドレスの対応関係は通信終了とともに廃棄され，通信ごとに異なるものが使用される。すなわち，名前解決の応答メッセージを書き換える内容が通信ごとに異なる。したがって，名前解決を要求した端末から見ると，同じ名前に対して異なるIPアドレスを取得することになる。通常DNSでは一度名前解決を行った名前に対しては，そのIPアドレスを一定期間記憶しておくキャッシュ機能があるが，従来のプロトコル変換方式では名前解決のたびにその名前に対するIPアドレスが異なるので，このキャッシュ機能を使用できない。

そこで，本発明では，ある端末が属する網と通信相手の端末が属する網のプロトコルが異なり，両網の接続点でプロトコルの変換が必要な場合において，片方，あるいは両方の端末が移動しても通信が断絶せず継続することを可能にする。
また，プロトコルの変換に必要な変換情報を動的に作成する場合のきっかけとなる，DNSを利用した名前解決の際にDNSキャッシュ機能を利用可能にする。

本発明の一実施例では，トランスレータは，第１のプロトコルに従ってデータを転送する第１のネットワークと，第２のプロトコルに従ってデータを転送する第２のネットワークと，他のトランスレータが接続される変換サーバとに接続されており，前記第１のプロトコルと前記第２のプロトコルとの間のプロトコル変換を行うための変換情報を保持している。前記トランスレータは，前記第１のネットワークに収容される第１の移動端末から，前記第２のネットワークに収容される端末のアドレス問い合わせを検出すると，前記端末に与えられている前記第２のプロトコルにおける第１のアドレスに対応する，前記第１のプロトコルにおける第２のアドレスを生成する。そして，前記第１のアドレスと前記第２のアドレスとの対応を，前記変換情報として保持するとともに，前記第１のアドレスと前記第２のアドレスとの対応を，前記変換サーバに登録する。

前記他のトランスレータを介して，前記端末と通信をしていた第２の移動端末が移動した結果，前記第２の移動端末から，送信元アドレスが前記第２の端末に与えられている前記第１のプロトコルにおけるアドレスで，宛先アドレスが前記第２のアドレスのパケットを受信した場合，トランスレータは前記変換サーバに前記端末のアドレス情報を問い合わせる。トランスレータは，前記サーバから，前記他のトランスレータにより登録された前記第１のアドレスと前記第２のアドレスとの対応を受信し，前記宛先アドレスを前記第１のアドレスに書き替える。
その書き替えたパケットを前記端末に送信する。

また，本発明の他の実施例では，第１のプロトコルに従ってデータを転送する第１のネットワークに接続されるアドレス変換サーバは，第１のプロトコルに従ってデータを転送する第２のネットワークに収容される端末の名前と，前記名前に対応する前記第２のプロトコルにおけるアドレスと，前記アドレスに対応して生成された前記第１のプロトコルにおけるアドレスとの対応関係を保持するテーブルを保持する。

そのアドレス変換サーバは，前記第１のネットワークに収容される端末から前記名前に対するアドレス問い合わせを受信すると，前記第１のプロトコルにおけるアドレスを前記端末に送信する。

その他の解決手段は，発明の実施の形態の欄で詳述される。

本発明により，移動端末がIPv4の場合，IPv6の場合のいずれにおいてもプロトコルを変換しつつ移動後も通信を継続することができる。かつ，移動端末が発信する場合，着信する場合のいずれにおいてもプロトコルを変換しつつ移動後も通信を継続することができる。また，移動端末がホーム網にいる場合，在圏網にいる場合のいずれにおいてもプロトコルを変換しつつ移動後も通信を継続することができる。さらに，Mobile IPと連携し，経路最適化を行った場合においても，プロトコルを変換しつつ移動後も通信を継続することができる。

また，変換サーバとしてDNSサーバを利用する場合，プロトコル変換が必要な場合においてもDNSキャッシュを利用できる。

図1は，IPv6網とIPv4網とが接続されたネットワークの構成の説明するための図である。網1及び網2はIPv6網であり，網3はIPv4網である。網1はIPv6移動端末41のホーム網であり，移動端末41が位置qに移動した場合，網2は移動端末41の在圏網となる。以下では，網1をホーム網，網2を在圏網，網3をIPv4網と呼ぶ。参照番号11，12及び13はトランスレータ，21は変換サーバ，22，23及び24はDNSサーバ，31はホームエージェント（HA）,42はIPv4端末である。DNSサーバ22及び23，トランスレータ11，12及び13は，IPv4及びIPv6の双方で通信可能であり，IPv4アドレスとIPv6アドレスが与えられている。また，変換サーバ21，DNSサーバ24にはIPv4アドレスが，ホームエージェント31にはIPv6アドレスが和与えられている。トランスレータ11，12及び13は，それぞれサービス領域を持っている。例えば，位置pにいる端末に対するサービスはトランスレータ11が行い，位置qにいる端末に対するサービスはトランスレータ12が行う。

トランスレータ11，12及び13の一実施例を図19に示す。図19はトランスレータの機能ブロック図を示している。図示していないが，トランスレータは，ハードウェアとしては，プロセッサ，記憶装置及びネットワークと接続するための通信制御装置とを有している。入力パケット選別処理，変換サーバ問い合わせ処理100，DNSメッセージ変換・処理102，Mobile IPメッセージ変換処理103，データパケット変換・処理104はソフトウェアにより構成され，プロセッサで実行される。これらをハードウェアで構成することも可能ある。また，変換表101，変換サーバアドレスは，記憶装置に保持される。入力パケット選別処理は，入力パケットを，変換サーバ問い合わせ処理100，DNSメッセージ変換・処理102，Mobile IPメッセージ変換処理103又はデータパケット変換・処理104に振り分ける。図22は，変換表101の一実施例を示している。変換表100及びトランスレータが行うその他の処理については後述する。

変換サーバ21の一実施例を図20に示す。図20は，変換サーバの機能ブロック図を示している。図示していないが，変換サーバ21は，ハードウェアとしては，プロセッサ，記憶装置及びネットワークと接続するための通信制御装置とを有している。入力パケット選別処理，変換情報登録要求処理111及び変換情報問い合わせ処理112はソフトウェアにより構成され，プロセッサで実行される。これらをハードウェアで構成することも可能ある。また，変換情報110は記憶装置に保持される。入力パケット選別処理は，入力パケットを，変換情報登録要求処理111又は変換情報問い合わせ処理112に振り分ける。変換情報110は，各トランスレータに保持されている変換表100の内容を集めたものであり，テーブルに記述される項目は図22に示した変換表100の項目と同じである。したがって，変換情報110のテーブルは図示しない。変換情報110の登録の仕方，及び変換サーバ21が行うその他の処理については後述する。

DNSサーバ22，23及び24は従来技術と同様の構成である。

図2は，移動端末41が在圏網2においてIPv4端末42と通信を開始する場合の通信経路を示している。端末41から送信された端末42宛のパケットは，トランスレータ12を介して端末42に到達する。一方，端末42から送信された端末41宛のパケットは，トランスレータ12及びホームエージェント31を介して，端末41に送信される。ホームエージェント31に移動端末41のホームアドレス（端末41が在圏網に移動した場合には気付アドレス）が登録されているため，後述する経路最適化を行った場合を除き，端末42から端末41宛のパケットは必ずホームエージェントを通る。図3は，移動端末42が，位置qから位置rに移動した場合の通信経路を示す。
端末41から送信された端末42宛のパケットは，トランスレータ13を介して端末42に到達する。一方，端末42から送信された端末41宛のパケットは，トランスレータ13及びホームエージェント31を介して，端末41に送信される。図2及び図3の状態において通信経路の最適化を行った場合の通信経路をそれぞれ図4及び図5に示す。通信経路の最適化を行うと，端末42から送信された端末41宛のパケットはホームエージェント31を介することなく端末41に到達する。なお，端末41が在圏網において端末42に送信開始後に経路最適化を行う処理と，端末41がホーム網1から在圏網2に移動した場合の経路最適化を行う処理とは同様であるため，図4では，後者の例を示している。

図2,3及び5における動作手順を図24,25及び26に示す。図24,25及び26において，矢印の上の3つ並んだ四角はIPパケットを表しており，それぞれ四角は，パケットの進行方向先頭から順に着信先IPアドレス，送信元IPアドレス，IPペイロードを表している。また，四角が5つ並んだ場合は，それぞれ四角は，先頭から順に気付けIPアドレス，ホームエージェントのIPアドレス，着信先IPアドレス，送信元IPアドレス，IPペイロードを表している。また，例えば，図24に示されているように，端末41に２つのIPアドレス，t6とp6が記されているが，左側のアドレスは，端末41に与えられたホームIPアドレス（IPv6アドレス）であり，右側のアドレスは，在圏網2から与えられた気付けアドレス（IPv6アドレス）である。また，変換サーバ21にはx4（IPv4アドレス），DNSサーバ23にはv6（IPv6アドレス）とv4（IPv4アドレス），DNSサーバ24にはc4（IPv4アドレス），トランスレータ11にはn6（IPv6アドレス）とn4（IPv4アドレス），トランスレータ12にはl6（IPv6アドレス）とl4（IPv4アドレス），トランスレータ13にはm6（IPv6アドレス）とm4（IPv4アドレス），そして端末42にはr4（IPv4アドレス）が与えられている。

図24は，移動端末41が在圏網2においてIPv4端末42と通信を行うための動作手順を示す。トランスレータ12は，DNSメッセージ変換・処理102において，すべてのDNS問い合わせ(アスキー出版，インターネットRFC事典，pp323-329を参照)を監視している。通信開始にあたり，端末41は端末42の名前(Rとする)からIPv6アドレスを得るために，DNSサーバ23に対してDNS問い合わせを行う。DNSサーバ23は，名前Rに対応するIPアドレスを知らないため，DNSサーバ24に対してDNS問い合わせを行う。このパケットフォーマットを図54,56及び57に示す。トランスレータ12はこの問い合わせパケットを検出し(シーケンス300)，DNSサーバ24からの応答を待つ。図55,56,58にDNS応答パケットのフォーマットを示す。本実施例では，DNSサーバ24からの応答パケットにおいて，図58の先頭部分に名前R，最後の部分にはその名前に対応するIPv4アドレスr4が記述される。トランスレータ12は，DNSサーバ24からの応答パケットを検出すると，そのIPv4アドレスr4を，以後の変換のために，IPv6アドレスs6へ書き換える(シーケンス301)。このIPv6アドレスは名前Rに対する仮想的なものであるので，以後，着信先仮想アドレスと呼ぶ。この処理は，トランスレータ12内のDNSメッセージ変換・処理102で行われる。この書換時に，r4とs6との対応付けのためのエントリーが，トランスレータ12内の変換表101（図22中のエントリ#1参照）に準備される。実際の着信先アドレスr4から着信先仮想アドレスs6に書き換えられたDNS応答パケットは，DNSサーバ23経由で端末41に届く。

DNS応答パケットを受信した端末41は，端末42へ向けてIPパケットを送信し始める。これらのパケットの着信先アドレスはs6，送信元アドレスは端末のIPv6アドレスであるt6である。端末41が送信したIPパケットがトランスレータ12に到着すると，そのパケットは，トランスレータ12内のデータパケット変換・処理104に送られる。データパケット変換・処理104は，着信先アドレスs6を検索キーとして，変換表管理部101を検索する。すると，先程準備したエントリ（図22のエントリ#1）がみつかるので，このパケットの送信元アドレスt6，トランスレータ12のIPv4アドレスl4，送信元ポート番号，着信先ポート番号等が当該エントリに書き込まれる（図22のエントリ#1）。l4は，送信元アドレスt6に対する仮想的なもので，以降送信元仮想アドレスと呼ぶ。これにより，変換規則の作成を完了する(シーケンス302)。変換表101の項目「エントリ残り寿命」は，エントリをどの位の時間保持しておくかを示すものである。また，変換表101の項目「送信元ポート番号」及び「着信先ポート番号」は，例えば，端末41から送信されたパケットのヘッダに記述されているポート番号から，当該パケットがWebアクセスであるとわかった場合，当該パケットをプロキシサーバに送信する等の処理に使うことが考えられる。これらの情報はなくてもてもよい。本実施例では，「送信元ポート番号」及び「着信先ポート番号」は使用してない。

トランスレータ12は，こうして作成した変換規則を変換表101に記憶するとともに，変換サーバ21に，その変換規則を登録する(シーケンス303)。この登録処理は，トランスレータ12内の変換サーバ問い合わせ処理100が行う。このとき，変換サーバのアドレスをどうやって知るかが問題となるが，本実施例では装置の起動時に初期設定するものとする。図59,62にこの登録メッセージのフォーマットを示す。図59の変換情報251の部分に作成した変換規則が記述される。

登録メッセージを受信した変換サーバ21では，変換情報登録要求処理111が変換情報を取り出し，それを変換情報記憶部110へ格納する。

トランスレータ12のデータパケット変換・処理104ではパケット内のIPv6アドレスt6とs6をそれぞれl4，r4へ書き換え(シーケンス304)，端末42へ向けて送る。変換の際にはIPアドレスだけでなく，パケットフォーマットもIPv6パケットフォーマットからIPv4パケットフォーマットに変換する。このフォーマット変換も，トランスレータ12内のデータパケット変換・処理103が行う。参考のため，図49にIPv6パケット，図46にIPv4パケットのフォーマットを示す。

一方，トランスレータ12は，端末42から送られてきたIPv4パケットに対しても，作成した変換規則に従い送信元アドレスr4をs6，送信先アドレスl4をt6に書き換えるともに，IPv4パケットをIPv6パケットに変換する(シーケンス305)。変換されたパケットは端末41へ送信される。

図25は，端末41が位置rに移動した後，端末41と端末42とが通信を行うまでの動作手順を示す。移動に伴い，端末41には，在圏網2から新たな気付けアドレスq6（IPv6）が与えられる。また，位置rにいる端末に対する変換サービスは，トランスレータ13が行う。

端末41は，まずMobile IPのホームエージェント31に対して位置登録を行う(http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txtのpp9-11参照)。このパケットフォーマットを図49,50及び51に示す。端末41は現在位置として，気付けIPv6アドレスq6をホームエージェント31に登録する。その後，端末41は端末42へ向けてパケットを送信する。このパケットはトランスレータ13へ届き，図19のデータパケット変換・処理104に送られる。データパケット変換・処理104は，着信先仮想アドレスs6を検索キーとして，変換表101を検索する。
しかし，この時点では，トランスレータ13内には，変換規則が存在しないため，IPアドレスの書き換えができない(シーケンス306)。このことが，トランスレータ13内の変換サーバ問い合わせ処理100に伝えられと，変換サーバ問い合わせ処理100は，変換サーバ21に変換情報の問い合わせを行う(シーケンス307)。図60,63及び64にその問い合わせパケットフォーマットの一実施例を示す。図60の最初の部分に問い合わせたい変換情報の検索キーである，着信先仮想アドレスのs6を記述する。なお，データパケット変換・処理104では，変換できないパケットを一定期間保持しておく。

変換サーバ21内の変換情報問い合わせ処理112は，問い合わせパケットから検索キーs6を取り出す。次にs6を検索キーとして変換情報110を検索する。上述したように，変換情報110には，着信先仮想アドレスs6に対応する変換規則（t6とl4との対応，s6とr4との対応等）が登録されている。変換情報110から検索された変換情報を変換情報問い合わせ処理112に返す。変換情報問い合わせ処理112では受け取った変換情報を図61,63及び65に示すフォーマットに格納してトランスレータ13へ応答する(シーケンス308)。変換情報は図65の最後の部分へ格納する。

トランスレータ13は，変換サーバ問い合わせ処理100により，変換サーバ21からの応答より変換情報を取り出し，それを変換表101に記憶する。その後，データパケット変換・処理104は，保持しておいたパケットを変換情報に従って，IPv6アドレスt6とs6をそれぞれl4，r4へ書き換え(シーケンス304)，端末42へ向けて送る。変換の際にはIPアドレスだけでなく，パケットフォーマットもIPv6パケットフォーマットからIPv4パケットフォーマットに変換する。このフォーマット変換も，トランスレータ12内のデータパケット変換・処理103が行う。

一方，トランスレータ13は，端末42から送られてきたIPv4パケットに対しても，変換表101に従い，送信元アドレスr4をs6，送信先アドレスl4をt6に書き換えるともに，IPv4パケットをIPv6パケットに変換する(シーケンス305)。変換されたパケットはホームエージェント31を介して端末41に送信される。

図26は，図6で説明した経路最適化(http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txtのpp87-89参照)を行う場合の動作手順を示す。

図25の手順が終了後，移動端末は経路最適化を行うかどうか選択することができる。もし経路最適化を行う場合，HAに対して現在位置を登録したのと同様にして，通信相手である端末42に対して，現在位置として在圏網2から与えられた気付けIPv6アドレスq6を登録する。トランスレータ13は，DNSメッセージの時と同様に，端末41から端末42宛の位置登録メッセージを監視する。トランスレータ13は，端末41から端末42宛のIPv6で記述された位置登録メッセージを検出すると，入力パケット選別処理により，そのメッセージはMobile IPメッセージ変換処理103に送られる。Mobile IPメッセージ変換処理103は，送信元アドレスt6と気付けアドレスq6との組に対して送信元仮想アドレスm4を対応付け，s6とr4とを対応づける変換規則を作成し，変換表101に保持する(図22の#4エントリ参照)。それとともに，Mobile IPメッセージ変換処理103は，位置登録メッセージに記述されている気付けアドレスq6をm4に変換し，それを端末42に送信する。なお，現在位置情報は，IPv4 Mobile IPでは，パケットのペイロードに記述されるが，IPv6 Mobile Ipでは，パケットのヘッダに記述される。したがって，Mobile IPメッセージ変換処理103は，アドレスの書き換えだけではなく，フォーマット変換も行った後，位置登録メッセージを端末42に送信する。

経路最適化を実行後，移動端末41は，端末42にパケットを送信する際，送信元アドレスとして，気付けアドレスq6を使用する。そして，本来のアドレスはIPv6の拡張ヘッダ部分(図49)に記述される。トランスレータ13は，データパケット変換・処理104においてパケットを変換する際に，IPヘッダの送信元アドレス(気付けアドレス)，着信先アドレス(着信先仮想アドレス)だけでなく，拡張ヘッダ内のアドレス(本来の送信元アドレス)を検索キーとして変換表100に検索をかける。そうすることで，経路最適化を行う前のエントリを検索してしまうことを防ぐ。検索キーとして拡張ヘッダ内のアドレスを使用するかどうかは，拡張ヘッダがあるかないかで判断する。つまり，拡張ヘッダ内に本来の送信元アドレスが入っていたら，必ず検索キーに加える。こうして，端末が移動しても変換情報に従ってパケットを変換することが可能となる。

以上の実施例では，移動端末41から端末42に送信する場合について説明した。
図27は，その逆で，端末42が，位置qにいる端末41に通信を開始する場合の手順を示している。この手順は，端末42が問い合わせるDNSサーバ等が異なるものの，図24で説明した手順から容易に理解できるものであるから，詳細な説明は省略する。端末41の名前Tに対応するIPアドレスは，ホームアドレスt6と対応づけられているため，端末42からのDNS問い合わせが，DNSサーバ24を介してDNSサーバ22に行く点，それ故，トランスレータ11が，t6と着信先仮想アドレスf4とを対応づける変換規則を作成する点，及び端末41から端末42宛のパケットはトランスレータ12を経由するため，トランスレータ11は，変換規則を作成する際に，送信元仮想アドレスをトランスレータ12のIPv6アドレスl6とし，r4とl6とを対応づける点に特徴がある。なお，図27では，DNSサーバ22には，i6（IPv6アドレス）とi4（IPv4アドレス）とが与えられている。

図28は，端末41が位置rに移動した後，端末42と端末41とが通信を行うまでの動作手順を示す。この手順は，図25で説明した手順から容易に理解できるものであるから，説明は省略する。

図29は，図28の手順が終了後，経路を最適化する手順を示す。この手順は，図26で説明した手順から容易に理解できるものであるから，詳細な説明は省略する。図26で説明した手順では，端末41は，位置登録メッセージをトランスレータ13を介して端末42に現在位置を登録した後，端末42宛のパケットを送信し始めるが，図29に示す手順では，位置登録メッセージは，端末42宛のパケットとともに送信される。そして，トランスレータ13において，図26に説明したのと同様な処理により，端末42に現在位置を登録した後，当該パケットの送信元アドレスを書き換え，それを端末42に送信する。

図6は，移動端末41がホーム網1においてIPv4端末42と通信を開始する場合の通信経路を示した図である。

図7は，移動端末が在圏網2（位置q）へ移動した場合の通信経路を示している。 図30及び図31は，それぞれ，図6及び図7の通信手順を示したものである。図24では端末41が通信を開始してから，実際に端末42とデータのやり取りを行うまで，図25では端末41が移動してからデータのやり取りを行うまでの動作手順を示している。これらの手順は，関与するDNSサーバ及びトランスレータの違いはあるものの，図24及び図25を用いて説明した手順と同様である。念のため説明すると，これらの手順では，ホームアドレスt6とトランスレータのIPv4アドレスn4とを対応づけているので，端末42から端末41に送信されるパケットは，トランスレータ11を経由する点が，図24及び図25で説明した手順と異なる。

図8は，端末41が，位置qから位置pに移動した場合の通信経路を示す。図32は，その場合の動作手順を示している。この手順は，関与するトランスレータの違いはあるものの，図25で説明したものと同様である。

上述した図4は，端末41が位置pから位置qに移動後に経路最適化をした場合の通信経路をも示している。また，上述した図5は，この経路最適化後に，さらに位置qから位置rに移動した場合の通信経路をも示している。図33及び図34は，それぞれの場合の動作手順を示している。これの手順は，関与するトランスレータの違いはあるものの，図26で説明したものと同様である。

図35は，図6において端末42から移動端末41へ通信を開始する場合の通信手順を示す。図36は，図7に示すように端末41が移動した場合に，端末42から移動端末41へ通信する動作手順を示す。図37は，図7の状態から，端末41が図8に示す位置に移動した場合における，端末42から移動端末41へ通信する動作手順を示す。
図38は，図7の状態から図4の状態に経路最適化を行った場合における，端末42から移動端末41へ通信の動作手順を示す。そして，図39は，図8の状態から図5の状態に経路最適化を行った場合における，端末42から移動端末41へ通信の動作手順を示す。これらの手順は，図27から図29で説明した手順とほぼ同様であるので，説明は省略する。

次に，IPv4移動端末が在圏網においてIPv6端末と通信を開始し，移動した場合，およびその際に経路最適化(http://search.ietf.org/draft-ietf-mobileip-optim-10.txtのpp1-4，http://www.ietf.org/rfc/rfc2002.txtのpp24-32参照)した場合について説明する。

図9は，IPv4網4及び5とIPv6網6とが接続されたネットワークの構成の説明するための図である。網4はIPv4移動端末43のホーム網であり，網5は移動端末43の在圏網である。その他は，図1と同様の構成である。

図10はIPv4移動端末43が位置qにおいて，IPv6端末44との通信を開始する場合の通信経路を示している。図11は，端末43が位置qから位置rに移動した場合における通信経路を示している。図10及び図11の状態において通信経路の最適化を行った場合の通信経路をそれぞれ図12及び図13に示す。なお，端末41が在圏網において端末42に送信開始後に経路最適化を行う処理と，端末41がホーム網1から在圏網2に移動した場合の経路最適化を行う処理とは同様であるため，図13では，後者の例を示している。

図40,41及び42は，それぞれ図10,11及び13に示した通信経路で通信を行う際の通信手順を示す。以下，図40,41及び42について説明する。

図40はIPv4移動端末が在圏網におり，IPv6端末と通信する場合の手順を示している。IPv6移動端末がIPv4端末と通信する時の手順(図24)とまったく同様である。変換情報に関して言えば，アドレスのIPv4とIPv6がそっくり入れ替わった形になる。すなわち，トランスレータ12では，IPv4送信元アドレスに対してIPv6の送信元仮想アドレスを割り当て，IPv6の着信先アドレスに対してIPv4の着信先仮想アドレスを割り当てる。

図41は図40の手順が済んだあと，IPv4移動端末が移動した場合の手順である。
これも変換情報におけるアドレスがIPv4とIPv6と入れ替わっている点をのぞけばIPv6移動端末の時(図25)とまったく同じ手順である。

図42は図41の手順のあと，経路最適化を行う場合の手順である。経路最適化を行う時の位置登録を，移動端末ではなくホームエージェントが行う点が，IPv6移動端末の時と異なっている。そのため図42のシーケンス310においてトランスレータ13で変換情報を作成する場合に，移動端末の通信にはまったく関係ないが，移動端末の変換情報を作成するだけでなく，ホームエージェントに対する変換情報も必要になり，同時に作成される。そのほかはIPv6移動端末の場合と同様である。

図14は移動端末43がホーム網4にいて通信を行う場合の通信経路を示す。途中でトランスレータ11によりIPv4とIPv6の変換が行われる。ここで移動端末43が在圏網5へ移動した場合，本発明による変換方式により，移動後の通信経路は図15のようになる。この状態で，経路最適化した場合は，図12のようになる。さらに端末43が移動した場合の通信経路は図16のようになり，その状態から経路最適化した場合に，通信経路は図13のようになる。これらの手順は，図24から26で示した手順と同様である。

次に変換サーバがインターネットにおける電話帳(大規模分散データベース)の役割を果たすDNSサーバ機能を内蔵する場合の例を挙げる。

図21にDNSサーバ内蔵変換サーバの一実施例を示す。図21は，DNSサーバ内蔵変換サーバの機能ブロック図である。図示していないが，DNSサーバ内蔵変換サーバは，ハードウェアとしては，プロセッサ，記憶装置及びネットワークと接続するための通信制御装置とを有している。入力パケット選別処理，変換情報登録要求処理111，変換情報問い合わせ処理112及びIPアドレス問い合わせ処理113はソフトウェアにより構成され，プロセッサで実行される。これらをハードウェアで構成することも可能ある。また，名前，IPアドレス，変換情報114は記憶装置に保持される。入力パケット選別処理は，入力パケットを，変換情報登録要求処理111，変換情報問い合わせ処理112又はIPアドレス問い合わせ処理113に振り分ける。変換情報登録要求処理111は変換情報登録要求を処理し，取り出した変換情報を名前，IPアドレス，変換情報記憶部114へ格納する。IPアドレス問い合わせ処理113ではDNSの名前解決要求を処理し，取り出した名前で名前，IPアドレス，変換情報記憶部114を検索し，得られたIPアドレスを要求元へ送信する。また，変換情報問い合わせ処理112では，変換情報問い合わせを処理し，取り出した着信先仮想IPアドレス等で名前，IPアドレス，変換情報記憶部114を検索し，得られた変換情報を要求元へ送信する。

図43にDNSサーバ内蔵変換サーバ使用時に，IPv6移動端末が在圏網におり，通信を開始する場合の動作手順図を示す。

図43を通常の変換サーバ使用時(図24)と比較すると，変換サーバ21とDNSサーバ23がDNSサーバ内蔵変換サーバ23-1となったため，変換情報登録シーケンス303の着信先がDNSサーバ内蔵変換サーバ23-1に変わる。また，このシーケンスで登録されDNSサーバ内蔵変換サーバ23-1が保持する，変換情報および名前とIPアドレスの対応を組み合わせた変換情報の例を図23に示す(#1のエントリ)。

通常，プロトコル変換が必要な場合の名前解決では，DNSのキャッシュ機能は禁止されている。すなわち図34においては，DNSサーバ23は必ずDNSサーバ24に問い合わせを行い，その結果を自分が持ってはならない。これは，途中のトランスレータ12がDNS応答を書き換えているため，トランスレータ12が持っているIPアドレス書き換え情報とDNSサーバ23が保持しているキャッシュのIPアドレス情報の同一性が保証されないためである。

一方，本発明によるDNSサーバ内蔵変換サーバ23-1では，名前Rに対する名前解決要求に対し，着信先仮想IPv6アドレスs6を返すことにより，DNSキャッシュ機能を可能としている。これが可能な理由は，各トランスレータは新たに変換情報を作成した場合必ずDNSサーバ内蔵変換情報サーバ23-1に登録するため，変換情報に変更があれば必ずDNSサーバ内蔵変換情報サーバ23-1の変換情報が更新されることと，変換情報の寿命を管理できるため，各トランスレータが廃棄した変換情報はDNSサーバ内蔵変換サーバ23-1においても，該当の変換情報を廃棄することができることによる。こうすることにより，変換情報の寿命が尽きて廃棄されるまで，ある名前Rに対するIPアドレスは，ある1つの着信先仮想アドレスとなる。

また，プロトコル変換が必要ない名前(仮想アドレスの欄が空欄)にたいしては通常のDNSサーバと同様に名前に対するアドレスを返し，変換情報の問い合わせに対しては，着信先仮想アドレス，送信元アドレスで検索し，着信先アドレス，送信元仮想アドレスを返す。

このように，DNSサーバ内蔵変換情報サーバ23-1は，DNSサーバと変換サーバの両方の機能を実現することが可能となる

IPv6網とIPv4網とが接続されたネットワークの構成の説明するための図である。 IPv6移動端末が在圏網において通信開始した場合の通信経路を説明するための図である。 IPv6移動端末が図2に示した位置から移動した場合の通信経路を説明するための図である。 IPv6移動端末がホーム網から在圏網へ移動し経路最適化を実行した場合，またはIPv6移動端末が在圏網において通信開始後に経路最適化を実行した場合の通信経路を説明するための図である。 図4に示した経路最適化実行後，IPv6移動端末がさらに移動した場合の通信経路を説明するための図である。 IPv6移動端末がホーム網において通信開始した場合の通信経路を説明するための図である。 IPv6移動端末がホーム網から在圏網へ移動した場合の通信経路を説明するための図である。 IPv6移動端末が図7に示した位置からさらに移動した場合の通信経路を説明するための図である。 IPv4網とIPv6網とが接続された他のネットワークの構成を説明するための図である。 IPv4移動端末が在圏網において通信開始した場合の通信経路を説明するたの図である。 IPv4移動端末が，図10の位置から移動した場合の通信経路を説明するための図である。 IPv4移動端末がホーム網から在圏網へ移動し経路最適化を実行した場合，またはIPv4移動端末が在圏網において通信開始後に経路最適化を実行した場合の通信経路を説明するための図である。 図12に示した経路最適化実行後，IPv4移動端末がさらに移動した場合の通信経路を説明するための図である。 IPv4移動端末がホーム網において通信開始した場合の通信経路を説明するための図である。 IPv4移動端末がホーム網から在圏網へ移動した場合の通信経路を説明するための図である。 IPv4移動端末が，図15に示した位置からさらに移動した場合の通信経路を説明するための図である。 DNSサーバ内蔵変換サーバ利用時にIPv6移動端末が在圏網において通信を開始した場合の通信経路を説明するための図である。 IPv6移動端末が，図17に示した位置から移動した場合の通信経路を説明するための図である。 本発明のトランスレータの一実施例を説明するためのブロック図である。 本発明の変換サーバの一実施例を説明するためのブロック図である。 本発明のDNSサーバ内蔵変換サーバの一実施例を説明するためのブロック図である。 変換表１００の実施例を説明するための図である。 本発明のDNSサーバ内蔵変換サーバに保持される変換情報の実施例を説明するための図である。 在圏網にいるIPv6移動端末が発信する場合のシーケンス図である。 図24の手順終了後，IPv6移動端末が移動した場合のシーケンス図である。 IPv6移動端末が在圏網内で移動した場合において，経路最適化する場合のシーケンス図である。 在圏網にいるIPv6移動端末が着信する場合のシーケンス図である。 在圏網にいるIPv6移動端末が移動した場合のシーケンス図である。 図28に示す手順終了後に，経路最適化する場合のシーケンス図である。 IPv6移動端末がホーム網において発信した場合のシーケンス図である。 IPv6移動端末が，ホーム網から在圏網へ移動した場合のシーケンス図である。 IPv6移動端末が，在圏網においてさらに移動した場合のシーケンス図である。 図31の手順終了後，経路最適化する場合のシーケンス図である。 図32の手順終了後，経路最適化する場合のシーケンス図である。 ホーム網にいるIPv6移動端末が着信する場合のシーケンス図である。 図35の手順終了後，IPv6移動端末が在圏網へ移動した場合のシーケンス図である。 図36の手順終了後，IPv6移動端末がさらに在圏網内で移動した場合のシーケンス図である。 図36の手順終了後，経路最適化する場合のシーケンス図である。 図37の手順終了後，経路最適化する場合のシーケンス図である。 在圏網にいるIPv4移動端末が通信開始する場合のシーケンス図である。 図40の手順終了後に，IPv4移動端末が移動した場合のシーケンス図である。 図41の手順終了後に，経路最適化する場合のシーケンス図である。 DNSサーバ内蔵変換サーバ使用時において，在圏網にいるIPv6移動端末が通信を開始する場合のシーケンス図である。 図43の手順終了後に，IPv6移動端末が移動する場合のシーケンス図である。 図44の手順終了後に，IPv6移動端末から同一の相手と新たな通信を開始する場合のシーケンス図である。 IPv4パケットフォーマットを示す図である。 Mobile IPv4 Registration Request メッセージフォーマットを示す図である。 Mobile IPv4 Registration Replyメッセージフォーマットを示す図である。 IPv6 パケットフォーマットを示す図である。 IPv6 Destination Options Header フォーマットを示す図である。 Mobile IPv6 Binding Updateメッセージフォーマットを示す図である。 Mobile IPv6 Binding Acknowledge メッセージフォーマットを示す図である。 Mobile IPv6 Binding Request メッセージフォーマットを示す図である。 DNS問い合わせメッセージ構成を示す図である。 DNS応答メッセージ構成を示す図である。 DNS ヘッダ部(問い合わせ，応答共通)メッセージフォーマットを示す図である。 DNS質問部(図42)メッセージフォーマットを示す図である。 DNS 応答部(図43のR1，R2，R2共通)メッセージフォーマットを示す図である。 変換情報登録メッセージ構成を示す図である。 変換情報問い合わせメッセージ構成を示す図である。 変換情報応答メッセージ構成の実施例を示す図である。 変換情報登録メッセージヘッダ部メッセージフォーマットの実施例を示す図である。 変換情報問い合わせ，応答メッセージヘッダ部メッセージフォーマット 変換情報問い合わせ部メッセージフォーマットを示す図である。 変換情報応答部(図61のR1, R2, R3共通)メッセージフォーマットを示す図である。

符号の説明

1・・・IPv6ホーム網，2・・・IPv6在圏網，3・・・IPv4網，4・・・IPv4ホーム網，5・・・IPv4在圏網，6・・・IPv6網，11・・・ホームトランスレータ(XLT H)，12・・・在圏トランスレータ1(XLT V1)，13・・・在圏トランスレータ2(XLT V2)，21・・・変換サーバ，22・・・ホームDNSサーバ(DNSサーバH)，23・・・在圏DNSサーバ(DNSサーバV)，23-1・・・在圏のDNSサーバ内蔵変換サーバ，24・・・DNSサーバ(DNSサーバC)，31・・・ホームエージェント(HA)，41，44・・・移動IPv6端末，42，43IPv4端末。

Claims (4)

1. 第１のプロトコルに従ってデータを転送する第１のネットワークと、
   第２のプロトコルに従ってデータを転送する第２のネットワークと、さらに、
   前記第１のネットワーク、前記第２のネットワーク、第１のプロトコルに従ってデータを転送する第３のネットワーク及び、前記第２のネットワークと前記第３のネットワークに接続された他のトレンスレータ、に接続された変換サーバと、に接続されるトランスレータであって、
   前記第１のネットワーク、前記第２のネットワーク、及び前記変換サーバとの間でパケットを送受信するインタフェースと、
   前記第１のネットワークにおいて前記他のトランスレータを介して前記第２のネットワークの第２の端末と通信する第１端末の端末が、前記第３のネットワークに移動した場合に、
   前記第１の端末から、宛先アドレスが前記第１のプロトコルにおける第２の端末のアドレスである第１のアドレスであって、前記第１のネットワークにおいて前記第１の端末に与えられている前記第１のプロトコルにおける第３のアドレスと前記第３のネットワークにおいて前記第１の端末に与えられている前記第１のプロトコルにおける第４のアドレスとを含む第１のパケットを受信した場合、
   前記変換サーバに、前記第２の端末のアドレス情報を問い合わせ、
   前記第４のアドレスに対応する、前記第２のプロトコルにおける第５のアドレスを生成するプロセッサと、
   前記変換サーバから前記問い合わせに対して受信する、前記他のトレンスレータが該変換サーバに登録した、前記第２のネットワークにおいて前記第２の端末に与えられている前記第２のプロトコルにおける第２のアドレスと前記第１のアドレスの対応を示す第１の変換情報と、
   前記第３のアドレス、前記第４のアドレス、及び前記第５のアドレスを対応づけた第２の変換情報を保持する記憶部と、を備え、
   さらに、
   前記第１の端末から宛先アドレスが前記第１のアドレスであって、送信元アドレスが前記第４のアドレスであり、さらに、前記第３のアドレスが含まれる第２のパケットを受信すると、
   前記プロセッサは、
   前記第２のパケットに含まれる前記第１、第３、及び第４のアドレスを検索キーとして 前記記憶部に保持された前記第２の変換情報を検索し、
   前記第２の変換情報に基づいて前記第２のパケットの送信元アドレスを前記第４のアドレスから前記第５のアドレスに書き換え、
   前記インタフェースを介して、前記書き換えられた第２のパケットを前記第２の端末に送信するトランスレータ。
2. 請求項１記載のトランスレータであって、
   前記第１のプロトコルがIPv6であり、前記第２のプロトコルがIPv4であることを特徴とするトランスレータ。
3. 請求項１記載のトランスレータであって、
   前記第２のパケット内の第３のアドレスは前記第２のパケットの拡張ヘッダ内に格納されていることを特徴とするトランスレータ。
4. 請求項３記載のプロトコル変換方法であって、
   前記第２のパケットに拡張ヘッダがあるかないかによって、前記検索キーに前記第３のアドレスを含めるか否かを判断するステップをさらに有することを特徴とするトランスレータ。

Images