JP2004519928A - アドレス変換器 - Google Patents

アドレス変換器 Download PDF

Info

Publication number
JP2004519928A
JP2004519928A JP2002571683A JP2002571683A JP2004519928A JP 2004519928 A JP2004519928 A JP 2004519928A JP 2002571683 A JP2002571683 A JP 2002571683A JP 2002571683 A JP2002571683 A JP 2002571683A JP 2004519928 A JP2004519928 A JP 2004519928A
Authority
JP
Japan
Prior art keywords
network
address
alias
host
assigned
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002571683A
Other languages
English (en)
Other versions
JP4001820B2 (ja
Inventor
ホベル、ピーター
キング、ジョン、ロバート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of JP2004519928A publication Critical patent/JP2004519928A/ja
Application granted granted Critical
Publication of JP4001820B2 publication Critical patent/JP4001820B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/251Translation of Internet protocol [IP] addresses between different IP versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015Access to distributed or replicated servers, e.g. using brokers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/101Server selection for load balancing based on network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1014Server selection for load balancing based on the content of a request
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Machine Translation (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

【課題】第1のネットワーク内のネットワーク装置と第2のネットワーク内のネットワーク装置間の通信を提供する装置を提供する。
【解決手段】第1のネットワークは第1の通信プロトコルに従って動作し、第2のネットワークは第2の通信プロトコルに従って動作する。装置は、1)第1のネットワーク内のターゲットネットワーク装置へエイリアスを割当てる第1の手段であって、該エイリアスは第2のネットワークの通信プロトコルと互換性がある手段と、2)該エイリアスをターゲットネットワーク装置に関するアドレスに該割当てられたエイリアスを変換する第2の手段であって、該変換されたアドレスは第1のネットワークの通信プロトコルと互換性がある手段とを具備する。
【選択図】図4

Description

【0001】
【発明の属する技術分野】
本発明はアドレストランスレータに関し、特に、しかしながら排他的ではなく、異なるネットワーク間のアドレストランスレータに適している。
【0002】
【従来の技術】
現在、すべての商業インターネットプロトコル(IP)ネットワークはIPv4ネットワークである。しかしながら、将来のある時点においては、商業IPネットワークはIPv6ネットワークになるであろう。その間には移行期間があり、その移行期間では商業IPネットワークはIPv4とIPv6ネットワークの混合からなるであろう。IPv6は全体的にIPv4とは異なるプロトコルであり、基本的にはIPv4とは互換性がない。それゆえに、少なくとも移行期間中は、ネットワーク装置及び/又はネットワークは、IPv4アドレスを有するIPv4ネットワークにおけるノード(node)及び/又はホスト(host)に、IPv6アドレスを有するIPv6ネットワークにおけるノード及び/又はホストとの通信を可能にするメカニズムを必要とするであろう。
【0003】
いくつかの移行(migration)メカニズムが開発されてきている。例えば、2000年11月にInternet Engineering Task Force (IETF)によって刊行された書類であって、http://www.ietf.org/internet−drafts/draft−ietf−ngtrans−introduction−to−ipv6−transition−05.txt
においてIETFから利用可能であり、「インターネットにおけるIPv6の導入の概観」と題した、W.Biemoltらの著作による、IETF Status : Draft working towards informational RFCの書類を見なさい。本質的に、これらの方法は「積極的短期間(aggressive, short term)」方法、或いは「保守的長期間(conservative, long term)」方法としてカテゴリー分けすることができる。
【0004】
【発明が解決しようとする課題】
知られた移行(migration)方法の少なくともいくつかに伴う問題は、それらがテスト環境において設計され動作されてきたことであり、そして商業IPネットワークにおいて経験されるトラフィック量に従ってこなかったことである。それ故に、商業的にスケーラブル(scalable)で確固たる(robust)移行方法の設計に関してはわずかの努力(work)しか実行されてこなかった。IPv4とIPv6間の移行が長くになると予想され、IPトラフィック量が引続き増加するならば、これは深刻な問題になり得るであろう。
【0005】
以下の記載では、「ホスト(host)」、「ネットワーク装置(network device)」、アドレスのプール「(pool of addresses)」及び「ノード(node)」なる用語が使用され、次のように定義される。
【0006】
「ノード」:ネットワークに接続されるすべての装置(equipment)であって、ルータ(routers)、スイッチ(switches)、リピータ(repeaters)、ハブ(hubs)、クライアント、サーバを含み、「ノード」、「装置(device)」、及び「ネットワーク装置(network device)」は互換可能に用いられる。
【0007】
「ホスト」:処理アプリケーションに関する装置であり、どの装置もサーバかクライアントのいずれかであり、またファイアウォール装置を含んでもよい。
【0008】
「アドレスのプール」:ある目的に利用可能な一群のアドレスである。アドレスは、全体的にユニーク(unique)なIPv4アドレス或いはネットワーク、例えばVLAN、の中の個人的なアドレスを含み得る。
【0009】
【課題を解決するための手段】
本発明の第1の態様によると、第1のネットワーク内のネットワーク装置と第2のネットワーク内のネットワーク装置間の通信を提供する装置が提供され、第1のネットワークは第1の通信プロトコルに従って動作し、第二のネットワークは第二の通信プロトコルに従って動作する。
【0010】
該装置は、
(1)エイリアス(alias)を第1のネットワーク内のターゲットネットワーク装置に割当てる第1の手段であって、該エイリアスは第二のネットワークの通信プロトコルと互換性がある手段と、
(2)該割当てられたエイリアスを該ターゲットネットワーク装置に関するアドレスに変換する第二の手段であって、該変換されたアドレスは第1のネットワークの通信プロトコルと互換性がある手段とを具備する。
【0011】
該第1の手段と該第二の手段は、該ネットワークの1或いは両方内にて別々にアドレス指定可能であり、該割当てられたエイリアスは第2の手段のアドレスに対応し、その結果、第2のネットワーク内のネットワーク装置が1又はそれ以上の伝送(communications)を該割当てられたエイリアスを含むアドレスを用いて送信するときに、該或いは各伝送は第2の手段へルート付けされ(routed)て、それによって第2の手段は該エイリアスを第1のネットワーク内のターゲットネットワーク装置のアドレスに変換し、該伝送を第1のネットワーク内へ送信する。
【0012】
特に、本発明の有利な実施形態は、IPv4ネットワークとIPv6ネットワーク間に適用されて、その結果第1のネットワークはIPv4ネットワークになり、第2のネットワークはIPv6ネットワークになる。
【0013】
好ましくは、該エイリアスはネットワークアドレスを有して、伝送がIPv6ネットワークへ送信されているときには、該ネットワークアドレスは第2の手段を表す識別子を含む。
【0014】
便利なことに、第2の手段は複数のさらなる装置を具備する。こうして、ターゲットネットワーク装置に対するエイリアスの割当てに対して、第1の手段によって、効果的にその後の伝送が複数のさらなる装置の1を介して生じ得る。複数の装置を有することにより、障害許容力(resilience)、スケーラビリティ(scalability)及びネットワークローディング(loading)の効果的な管理を有利に導入することができる。
【0015】
有利なことに、該或いは各さらなる装置は1又はそれ以上のエイリアスのグループにアクセスし、各グループを記憶装置内に記憶することができる。代わりに、2或いはそれ以上のグループを記憶装置内に記憶することができる。
【0016】
好ましくは、実施形態は複数のさらなる装置の1つを装置特性のような所定の判断基準に従って選択する選択手段を含む。有利なことに、選択手段は装置特性を監視するように動作可能であり、その結果装置の選択は現在の装置パフォーマンスに基づくことができる。監視される装置特性は、装置の動作状態、装置のローディング(loading)、及び/又は装置に利用可能なエイリアスの少なくとも1つを含む。
【0017】
好ましい実施形態において、選択手段は第1の手段と動作上関連しており、その結果、第1の手段はさらなる装置に利用可能なエイリアスを検索するように動作可能であり、検索されたエイリアスは該割当てられたエイリアスである。
【0018】
便利なことに、実施形態は該割当てられたエイリアスと該エイリアスに割当てられたネットワーク装置間のマッピング(mappings)を記憶するマッピング記憶装置を含む。マッピング記憶装置は第1の手段、データベース、或いはさらなる装置によって管理され得る。記憶されたマッピングの管理者の選択は一般にネットワークトラフィック、ネットワーク装置のオーナーシップ(ownership)、及び送信経路(paths)のような判断基準に従う。
【0019】
本発明の第2の形態によると、上述の装置に対応して、第1のネットワーク内のネットワーク装置と第2のネットワーク内のネットワーク装置との間の伝送を提供する方法が提供される。
【0020】
【発明の実施の形態】
この発明の更なる形態、特徴、利点は、本発明の好ましい実施形態の次の説明から明らかになり、また、以下添付の図面に言及して説明していく。
【0021】
本発明の実施形態は、IPv4ネットワークからIPv6ネットワークへの移行(migration)に関する問題に関係する。特に、本発明の実施形態は移行(migration)方法のスケーラビリティ(scalability)面に関係する。上述の通り、現在動作しているほとんどすべてのIPv6ネットワークは「テスト」ネットワークであり、商業IPネットワークを介して通過するIPトラフィックの量に従っていない。こうして商業環境内の移行方法のパフォーマンスは容認できない程低いかもしれない。
【0022】
本発明の1実施形態は、ネットワークアドレストランスレータ(Network Address Translator)−プロトコルトランスレータ(NAT−PT)方法に関係し、それはIETFによって「コメント要求(Request for Comments)」RFC2766において書面にされており、http://www.ietf.org/rfc/rfc2766.txtにおいてIETFから利用可能である。NAT−PTはIPv6からIPv4への及びその逆のIPヘッダとIPアドレスの両方を変換するメカニズムである。NAT−PTによって、明白なマッピング(mappings)は任意のIPv4アドレスとIPv6アドレス間で維持され、その結果、アドレスを変換するときに、NAT−PTは予め構成されたテーブル参照して他のプロトコルを用いて使用すべき対応するアドレスを判断することができる。RFC2766の導入部においてNAT−PTと共に記載されているように、IPv4ホストとIPv6ホスト間のセッションの一部であるパケットは同一のNAT−PT実体(entity)を介して動かなければならない。というのは、アドレスマッピングはNAT−PT内で保持されるが共有されないからである。これはNAT−PTの変換メカニズムの結果である。NAT−PTはステートフルな(stateful)変換プロセスであり、各個別のセッションを変換できるように保持されなければならない特定の情報があることを意味している。
【0023】
こうしてアドレス変換は、従来のネットワークアドレス変換(NAT)装置でなされたのときわめて同じ方法で、IPv6アドレスをIPv4アドレスでエイリアシング(aliasing)することによって実行される。あるNAT−PTの実行はDNSアプリケーションレベルゲートウエイ(DSN Application Level Gateway)(DNS ALG)を含み、それはDNSの要求と応答を変換する。
【0024】
図1は、IPv4ネットワークであり得る第1のネットワークNW1と、IPv6ネットワークであり得る第2のネットワークNW2との間の動作におけるNAT−PTの従来の実施を表す。該実施は単一のトランスレータ101を含み、該トランスレータはIPv6/v4アドレスの割当てを管理するプロセス102を含む。このようなプロセス102はDNSアプリケーションレベルゲートウエイを含む。さらにトランスレータ101はIPv4アドレスのプール103にアクセスし、プール103はIPv6ノード(nodes)への割当てに用いられる。さらに、図1は2つのDNSサーバ104と106とを表し、第1のサーバ104はIPv4ネームを記憶して「A」レコードの形式でマッピングをアドレス付けし、第2のサーバ106はIPv6ネームを記憶して「AAAA」レコードの形式でマッピングをアドレス付けする。
【0025】
トランスレータ101は一般に境界(border)ルータ上に位置し、IPv6ネットワークNW2に関して進入(ingress)インタフェースと称される。
【0026】
この知られたNAT−PTの実行の従来の動作は、図2に表されている。一般的なシナリオでは、IPv4ネットワーク内のホストCはIPv6ネットワーク内のホストAに関するネームルックアップ(name lookup)要求を送信する(202)。このルックアップ要求は“A”タイプDNS要求と定義される。この要求はトランスレータ101によって受信され(204)、トランスレータ101はこの要求にIPv6レコード(record)要求としてタグ付けする(206)。その結果、この要求は“AAAA”タイプDNS要求になり、このタグ付けされた要求をDNSサーバ106へ送信する(208)。
【0027】
DNSサーバ106はIPv6ネットワークアドレスをトランスレータ101へ戻しながら応答し(210)、トランスレータ101はプロセス102と協同してアドレスのプールからIPv4アドレスを戻されたIPv6アドレスへ割当てる(212)。トランスレータ101は割当てられたIPv4アドレスと戻されたIPv6アドレス間のマッピングを記憶し(214)、割当てられたIPv4アドレスを要求しているホストCへ送信する(216)。
【0028】
ホストCとホストA間のその後の通信において、また図3に示されるように、ホストCは目的地アドレスを出て行くパケットに関して割当てられたIPv4アドレスになるよう設定し(302)、該パケットをホストAの割当てられたIPv4アドレスへ送信し(304)、従来のIPルーティング(routing)は該パケットがトランスレータ101へ決まったルートで送信されることを保証する。そしてトランスレータ101は割当てられたIPv4アドレスとIPv6アドレス間のマッピングをルックアップしてホストAのIPv6アドレスを検索し(306)、これを該パケットの目的地アドレスにする(308)。
【0029】
トランスレータ101からホストAへルート付けされるパケットに関して、トランスレータ101は、ノードCのIPv4アドレスである該パケットのソース(source)アドレスをIPv6アドレスへ変更しなければならない。これはホストCのIPv4アドレスをトランスレータ101を表すプレフィックス(prefix)での拡張を含む(310)。よく知られているように、IPv4アドレスは32ビット長であり、一方IPv6アドレスは128ビット長である。上述の通り、IPv6ホストはIPv4アドレスを解釈できず、逆もまた同様であり、これはアドレス長における差異による。こうしてIPv4パケットがトランスレータ101に到達するときに、トランスレータ101を示す96ビットのプレフィックスが該パケットのソースアドレス(32ビット)に加えられて、IPv6アドレス(128ビット)を作成する。このIPv6アドレスへ送信されたパケットはトランスレータ101へルート付けされるであろう。(例えば、トランスレータ101に到達するIPv4ソースアドレス10.10.10.10はプレフィックス2001:618:1:2::を与えられる。その結果ソースIPv4ホストはIPv6の世界における次のアドレス2001:618:1:2::10.10.10.10を持つことができる。このアドレスへ送信されたIPv6パケットはトランスレータ101へ進むであろう。これはプレフィックス2001:628:1:2::がトランスレータ101へルート付けるからである。)
そしてトランスレータ101は該パケットを拡張されたIPv6アドレスを用いて送信する(312)。ホストAとホストC間のすべてのその後の通信はトランスレータ101に記憶されたマッピングを使用する。
【0030】
ホストAによって、IPv6ネットワーク内で、開始された通信は同様のアドレス割当てを含む。実際の例に関して、リーダー(reader)は上記にて詳述されたRFCに照会される。
【0031】
いったんIPv6アドレスが割当てられると、トランスレータ101は、パケットがIPv4ネットワーク内のホスト(C)とIPv6ネットワーク内のホスト(A)の間を通過するにつれて、パケットを変換し、こうして前記ホストAとホストC間のすべての通信に関する媒体として動作することが、上記より明らかになる。この構成にともなう問題は、集中化されたアドレス割当てと通信処理が、IPv6ネットワークが主流になるときに、スケーラビリティ(scalability)問題を表すことである。
【0032】
本発明の実施形態の本質は、初期のアドレス割当て(図2)の機能性が割当てられたアドレスを使用する次の事象から分けれていることである。(例えば、図3に示されるように、パケットがホストAからホストCへ通過するようなパケットエンキャプシュレーション(packet encapsulation)。これは、RFC2766に記載されたNAT−PT法の特に予期されぬ発展である。NAT−PTはステートフル(stateful)であるため、アドレス指定と割当ては1のかつ同じ装置で実行されるべきと、即ちそれらは分離できないことをRFCは要求する。
【0033】
本発明の1実施形態では、図4に示されるように、トランスレータ400は本質的に2つの部品、コントローラ(controller)401と複数の装置403a、403b、・・・403n(今後403iと総称する)からなる。IPv“他の”ネットワークにおけるホストとの通信する要求はコントローラ401にて受信され、コントローラは装置403iをポーリングして該要求にサービスできる(service)能力を有する1の装置を識別できる。そのように識別された装置はその後IPv6とIPv4におけるホスト間のすべてのその後の通信に対処して、該その後の通信はそれ故にコントローラの動作から独立している。これらの部品の構成と機能性は以下にてさらに詳述される。
【0034】
こうして本発明の実施形態においては、アドレス割当てはIPv4ネットワークとIPv6ネットワークにおけるホスト間のその後の通信事象から分離されている(例えば、該割当てられたアドレスを用いてパケットを変換すること)。加えて、コントローラ401はアドレス割当てに関して複数の装置から選ぶことができる。
【0035】
本実施形態に関連していくつかの有利な点がある。
・第1に、装置はアドレス割当てフェーズ(図2)において受動的であり、これはある装置が失敗した場合にそれが新たな要求のサービスに影響しないことを意味する(例えば、コントローラ401は別の装置を選ぶことができる)。
・第2に、トランスレータ400は、装置を要求にしたがって容易に追加できるので、スケーラブル(scalable)である。
・第3に、IPv4ネットワークとIPv6ネットワーク内の装置間の通信はアドレス割当てから独立して継続でき、その結果(1)アドレス割当ての問題によるコントローラ401の失敗はIPv4ネットワークとIPv6ネットワーク内のホスト間で既に確立された通信には影響しないし(2)IPv4ホストとIPv6ホスト間の通信に対応するネットワーク問題はコントローラに影響しないし、そして(3)コントローラはその後の通信事象に責任を持つ或いは予定する必要もない。
・第4に、IPv6がIPv4を脱し始めるにつれて、装置は要求される通りに、再度の大きな変換サービスの中断なしに、任務を終了できる
・第5に、「IPv6のみの」サービスによりIPv6ネットワークを展開するIPネットワークプロバイダにとっては、ある種の変換能力を提供することが必要であり、それによってIPv4ネットワークのユーザはIPv6サービスにアクセスできるとともに、IPv6ユーザも既存のIPv4に基づくサービスにアクセスできる。ここで記載された実施形態は、商業サービスプロバイダにIPv6ネットワークの次元(dimensions)によってアドレス変換サービスを動的に拡大する能力を与えることができる。
【0036】
図4の参照に戻って、トランスレータ400の構成は今さらに詳細に記載される。
【0037】
コントローラ401はIPv4ネットワークかIPv6ネットワークのいずれか内のホストによって開始されるDNS要求を受信し、上述の方法で、該要求の点では、DNSルックアップ(lookups)を管理する。それぞれのDNSサーバ104、106から戻されたIPvnアドレスを受信して、コントローラ401は装置403iを識別し、該装置は要求しているホスト(上記例ではホストC)と目的地ホスト(上記例ではホストA)間のその後の通信を取り次ぐ。各装置は全体的にルート付けできる(routable)プレフィックス(即ち、該装置に関して定められたパケットの目的地アドレスに添えられるプレフィックス)を持ち、IPv4アドレスに添えられたときには、該プレフィクスによってパケットは該装置に到達できる(上述の通り)。
【0038】
1の実施形態では、装置403iの識別は装置403iが終了しているか動作しているかを判断することからなる。さらに、コントローラ401は、装置403iに利用可能なフリーなアドレスがあるかどうか、且つ現在のローディング、或いはある装置によって現在処理されている通信の数を識別する。便利なことに、コントローラ401はプログラム411を動作させ、該プログラムは所定の間隔で各装置403iをポーリングして(polls)、現在のローディング、動作状態、及びその装置にアクセス可能なIPアドレスを判断する。プログラム411は該ローディングとアドレス利用可能データを装置403iから集めて、例えば、記憶装置内のリストとしてそれを記憶する。コントローラ401は、所定の間隔で、例えば毎秒とか、或いは装置403iへの変化を捉えるのに必要とされるような頻度で、プログラム411を動作してもよい。
【0039】
コントローラ401はまた該リストから装置403aを選択する選択アルゴリズムを動作させてもよい。例えば、典型的な選択アルゴリズム412は動作中の装置に関するリストをサーチし、該動作中の装置は少なくとも1のフリーなIPv4アドレスへのアクセスを持ちかつ所定の閾値以下のローディングを持つ。もし1以上の装置がこれらの基準を満足すれば、最低のローディングを持つ装置が選択される。この例に関しては多くの変形が可能であり、当業者には明らかであろう。
【0040】
1の実施形態では、各装置403iは従来のルータであってもよく、それによってコントローラ401は、装置403a上のローディングを、単純ネットワーク管理プロトコル(Simple Network Management Protocol)(SNMP)メッセージを該ルータ上で維持される管理情報ベース(Management Information Base)(MIB)へ発することによって導出することができる。SNMPは知られたTCP/IPネットワークソフトウエアの一部であり、MIB或いは管理情報ベースはデータアイテムを特定する標準であり、該標準をホスト、ルータ或いはスイッチはそれぞれに許された動作と共に保持しなければならない。SNMPはMIBから情報を引き出せるようにするプロトコルであり、当業者に知られている。さらなる詳細については、Request for Comments (RFC) 2037/2737, Entity MIB, McCloghnie et al 1996/1999, Internet Engineering Task Force (IETF) によって出版された(http://www.ietf.orgから利用可能である)か、或いはDavid Perkins, Evan McGinnis, Prentice HallによるUnderstanding SNMP MIBs 第1版(1996年12月3日)を見よ。
【0041】
実施形態の1によれば、装置403iの各々はIPv4アドレスのプール405にアクセスし、IPアドレスのどんな単一の装置403aに対する利用可能性もそれぞれの装置403上で記録される。コントローラ405はそれ故に装置403毎のアドレス利用可能性をそのアドレス利用可能性の記録をレビューすることにより決定できるであろう。当業者はそのような記録は装置自身の上に記憶される必要はないが、中枢に、例えばデータベースに保持できると認識するであろう。
【0042】
プール405は、図4に示されたように、中央プールで装置403iのすべてによってアクセス可能か、或いは複数のプールであって、それぞれ装置403iの限られた数にアクセスできるものからなるかのいずれかになろう。例えば、図5aに示されるように、装置403i毎に1のプール405が存在してもよいし、或いは図5b及び5cに示されるように、n個の装置403i毎に1のプール405が存在してもよい。
【0043】
本質的に、コントローラ401は従来のクライアント又はサーバコンピュータのような処理装置上で動作する1又はそれ以上のプログラムからなる得る。代わりに、コントローラ401はルータ上で動作し得る。いずれかの構成では、コントローラ401は専用のリンクを介して或いはインターネットを介して装置403iのそれぞれに接続できよう。もしセキュリティが考慮すべき事柄であれば、専用リンクがより適している。代わりとして、IPsecのようなセキュリティプロトコル、それはIPv6の不可欠な部分であるが、がコントローラ401と装置403i間の通信に使用できるであろう。プログラムはソケットプロセスを含み、該プロセスは入来するDNSルックアップ要求に傾聴しかつ装置403iからの要求に傾聴する。
【0044】
好ましい実施形態では、コントローラ401はFIFO(先入れ先出し)ベースで入来する要求を処理する。即ち、コントローラ401はキューイングディシプリン(queuing discipline)を実現し、エンティティ(ここでは要求、入来するパケット)がキュー内(又はスタック内)に記憶されて、エンティティが到着するのと同じ順にサービスされる。代わりとして、コントローラ401はLIFO(後入れ先出し)によって要求を処理することができて、そこでは最も直近の要求が次に処理されて、最も古い要求はキュー上で(或いはスタック内の)唯一残っている要求になるまで処理されない。
【0045】
他のスケジュール方法(scheduling policies)も可能である。例えば、コントローラ401が制約に従うときに、適したスケジュール方法は、制約基準を満足するように要求をスケジュールする(schedule)試みにおいて、ある種の帰納的な方法(或いは帰納的な方法の複合)を活用することができる。更なる代替として、スケジュール方法はIPv6ヘッダに含まれるサービスの品質(Quality of Service)情報を使用することができる。IPヘッダ内のあるビットは要求の優先度を示して、コントローラ401はこれらのビット(図示されていないが)を審査する手段を含むことができる。コントローラ401は複数のキューを持つことができて、それぞれのキューは異なる優先度レベルに対応し、コントローラ401は該レベルで、例えば連続的なベースで動作する。
【0046】
IPv4ネットワーク内のホストCによって開始される通信(ホストAと通信するために)を管理するトランスレータ400に関するフローチャートが図6〜8に示されている。またIPv6ネットワーク内のホストAによって開始される通信(ホストCと通信するために)を管理するトランスレータに関するフローチャートが図9〜11に示されている。
【0047】
図6と9はそれぞれ、それぞれのフローチャートの左手側で主ループを示し、入来する開始要求に関して実行されるプロセスを表している。それぞれのフローチャートの右手側では、サブ−ループがあり、コントローラ401と装置403i間で実行されるプロセスを表す。
【0048】
最初に、図6に示されたケースを考察すると、IPv4ネットワーク内のホストCはIPv6ネットワーク内のホストAに関するネームルックアップ要求(name lookup request)を送信する(602)。この要求はコントローラ401によって受信され(604)、コントローラ401は、該要求を“AAAA”レコード要求へ変更することによって、該要求にIPv6レコード要求としてタグ付けし(606)、該タグ付けされた要求をDNSサーバ106へ送信する(608)。DNSサーバ106は、IPv6ネットワークアドレスをコントローラ401へ戻しながら、応答する(610)。
【0049】
そしてコントローラ401は通信を取り次ぐために、デバイス403aを識別しようとする。このプロセスは図6の右手側のループ内で示されて、次のステップから構成される。コントローラ401は装置403iのリストにアクセスし(612)、該リストは、各装置403iに関して、該装置上のローディング(loading)とその装置にアクセスできるIPアドレスを詳述する。このようなリストは、上述のように、メモリに記憶可能である。コントローラ401はそして上述のような選択アルゴリズム412を該リストに適用して(614)、現在の要求に関する装置を識別する。一旦装置403aが識別されると(616)、その装置403aに利用可能なIPv4アドレスが選択されてコントローラ401へ戻される(618)。(上述の装置403iの自動ポーリング(polling)に加えて、或いはその代わりに、プロセス411が装置がそのように識別されるたびに自動的に引き起こされてもよい。)
コントローラはステップ618で戻されたIPv4アドレスをステップ610で戻されたIPv6アドレスに割当てて(620)、2つの間のマッピング(mapping)を保存する。割当てられたIPv4アドレスはそしてホストCへ送信される(622)。一般に、装置に利用可能な多くのIPアドレスはその装置のインタフェースへ予め割当てられるであろう(当業者に知られた方法で)、その結果単一のインタフェースが効果的に複数のIPアドレスを持つことができる。こうしてパケットが割当てられたIPv4アドレスの目的地(destination)アドレスを持ちつつホストCから送信されるときは、該パケットは装置403aの対応するインタフェースにルート付けされるであろう。
【0050】
この時点でホストCはホストAに関するIPv4アドレスをもち、ホストCは該アドレスを用いてパケットをホストAへルート付けすることができる。図7はパケットをホストAへ送信する(702)ホストCのシナリオを示す。該パケットは該割当てられたIPv4アドレスにセットされた目的地アドレスとホストCのIPv4アドレスにセットされたソースアドレスを有する。該割当てられたアドレスが該識別されたデバイス403aへルート付け可能であるので(上記パラグラフで記載されたように)、パケットは装置403aに到達するであろう。その上で装置403aは要求を該パケットの目的地アドレスに対応するIPv6アドレスに関してコントローラ401へ送信する(704)。(該目的地アドレスはステップ620で割当てられたIPv4アドレスである)。コントローラ401はその記憶されたマッピングのルックアップを実行し(706)、該戻されたIPv6アドレスを装置403aへ送信する(708)。この時点で装置403aはホストAとホストC間のさらなる通信を自主的に取り次ぐことができるように要求される情報のすべてを受信している。
【0051】
装置403aはそして、該ソースアドレスを拡張してホストCのIPv4アドレスと共に装置403aのIPv6プレフィックスを含み(上述の通り)、該戻されたIPv6アドレスへ該目的地アドレスを設定して、ホストCによって送信された該パケットのソースアドレスと目的地アドレスを変更する(710)。装置403aはそしてホストAによって受信されてIPv6ネットワーク内へ該パケットを送信する(712)。
【0052】
図8を参照して、もしホストAがホストCへ応答を送信すれば、ホストAは、ホストCのIPv4アドレスと共に目的地アドレスとして装置403aのIPv6プレフィックスと、ソースアドレスとしてそれ自身のIPv6アドレス(これはもとろんステップ610で戻されたIPv6アドレスである)とを有する1又はそれ以上のパケットを送信する(802)。装置403aは該パケット或いは各パケットを受信し(804)、到来するパケットのIPv6ソースアドレスに対応するIPv4アドレスに関してコントローラ401へ問い合わせる(806)。
【0053】
コントローラ401は該対応するIPv4アドレスを装置403aへ戻すが(808)、該IPv4アドレスは(ステップ620から)該割当てられたIPv4アドレスである。該403a装置上で該或いは各到来するパケットのソースアドレスは該割当てられたIPv4アドレスで置き換えられる(810)。加えて装置403aは、装置403aのIPv6プレフィックスを取り除いてホストCのIPv4アドレスを残して、該目的地アドレスを変更する(812)。最後に、装置403aは該或いは各パケットをIPv4ネットワーク内へ送信する(814)。
【0054】
第2に、図9に示されたケースを考察すると、IPv6ネットワーク内のホストAがIPv4ネットワーク内のホストCに関するネームルックアップ要求を送信する(902)。この要求はコントローラ401によって受信されて(904)、コントローラ401は、該要求を“A”レコード要求へ変更することによって、該要求にIPv4レコード要求としてタグ付けし(906)、該タグ付けされた要求をIPv4DNSサーバ104へ送信する(908)。DNSサーバ104は、IPv4ネットワークアドレスをコントローラ401へ戻しながら、応答する(910)。
【0055】
コントローラ401はそして通信を取り次ぐために装置403bを識別しようとする。このプロセスは図9の右手側のループに示され、次のステップから構成される。コントローラ401は上述の装置のリストにアクセスし(912)、現在の要求に関する装置を識別するために選択アルゴリズム412を該リスト上の装置に適用する(914)。一旦装置403bが識別されたら(916)、コントローラ401は該識別された装置403bにアクセスできるプール405からIPv4アドレスを保存する(918)。コントローラ401はそしてホストAの該保存されたIPv4アドレスとIPv6アドレス間のマッピングを保存する(920)。最後に、コントローラ401は(上述の通り)該識別された装置403bのプレフィックス識別子をステップ910で戻されたIPv4アドレスに付けて(922)、これをホストAへ送信する(924)。
【0056】
この時点で装置403bはホストAとホストC間のさらなる通信を自主的に取り次ぐことができるように要求される情報のすべてを受信している。
【0057】
図10がパケットをホストCへ送信する(1002)ホストAのシナリオを示す。該パケットはステップ924で送信されたIPv6アドレスに設定された目的地アドレスを有する。このアドレスは該識別された装置403bに全体的にルート付けできるので(上述の通り)、該パケットは装置403bに到達するであろう。そこで装置403bは、ホストCのIPv4アドレスを残して、該プレフィックスを該目的地アドレスから取り除く(1004)。
【0058】
装置403bはステップ922で保存されたIPv4アドレスに関する要求を送信し(1006)、そこでコントローラ401は該保存されたアドレスを送信する(1008)。装置403bは、ホストCのIPv4アドレスに該ソースアドレスを設定し、該保存されたIPv4アドレスに該目的地アドレスを設定して、ホストAによって送信された該パケットのソースアドレスと目的地アドレスを変更する(1010)。装置403bはそしてホストCによる受信に関してIPv4ネットワーク内へ該パケットを送信する(1012)。
【0059】
図11を参照して、もしホストCがホストAへの応答を送信すれば(1102)、このような応答は、目的地アドレスとして該保存されたIPv4アドレスとソースアドレスとしてそれ自身のIPv4アドレスとを有する1又はそれ以上のパケットから構成されてもよい。装置403bは該或いは各パケットを受信して(1104)、該パケットの目的地アドレスに対応するIPv6アドレスに関してコントローラ401に問い合わせる(1106)。コントローラ401はその記憶されたマッピングのルックアップを実行してIPv6アドレスを戻す(1108)。このIPv6アドレスはホストAのIPv6アドレスである。
【0060】
装置403bはそのプレフィックスを該パケットのソースアドレス(ホストCのIPv4アドレス)に加えて(1110)、上述のように、IPv6アドレスを形成して、該パケットの目的地アドレスはステップ1108で戻されたIPv6アドレス(即ち、ホストAを起動するIPv6アドレス)で置き換えられる(1112)。最後に、装置403bはIPv6ネットワーク内へ該パケットを送信する(1114)。
【0061】
第2の実施形態:
第2の実施形態は第1の実施形態に関して述べられた特徴のすべてを含むが、コントローラ401上に記憶されているアドレスのマッピングの代わりに、該マッピングは離れたデータベース或いは同様のものの上に記憶される。該データベースはコントローラ401と装置403iの両方にアクセスできる。こうしてこの実施形態では、装置403iは、一旦初期のアドレス割当てが確立されたならば、コントローラ401と全く通信する必要がない。
【0062】
第3の実施形態:
第3の実施形態は第1の実施形態に関して述べられた特徴のすべてを含むが、装置403aはある所定の期間メモリ内にアドレスをキャッシュ(cache)する。この実施形態は図6から図11で示されたシナリオに特に適しており、ここではIPv4ネットワーク内のホストは伝送を生じさせて、伝送の集中した期間がホストAとホストC間で起きている。もし装置403aがマッピング情報を局所的にキャッシュするならば、装置403aはコントローラからアドレスマッピング情報を継続的に要求する必要はない。それ故に、これはコントローラ401から完全に独立したホストAとホストC間の伝送を維持し、ネットワークトラフィックを最少にし、アドレス変換に依存した伝送が他の実施形態においてよりも早く進行できるようにする。
【0063】
第4の実施形態:
第4の実施形態は第1の実施形態に関して述べられた特徴のすべてを含むが、マッピングは、コントローラ401内よりむしろアドレスプール405に記憶される。第2と第3の実施形態に関して、装置403iは、一旦初期のアドレス割当てが確立されたならば、コントローラ401と全く通信する必要はない。
【0064】
第5の実施形態
第5の実施形態は第1の実施形態に関して述べられた特徴のすべてを含むが、アドレスプール405からのIPv4アドレスの割当ては、装置403iによってよりもむしろ、コントローラ401によって管理される。このように状況では、第1と第2の選択アルゴリズムは装置403iを識別するときにIPアドレス利用可能性をリビューすることは含まない。この実施形態では、アドレスプール405はダイナミックホストコンフィグレーションプロトコル(Dynamic Host Configuration Protocol)(DHCP)サーバ上に記憶されて、その結果コントローラ401はDHCPに従ってIPv4アドレスを要求することができる。この状況(IPv4アドレスの割当てがコントローラ401によって管理されている)では、割当てられたアドレスは該識別された装置403iのIPv4のインタフェース内に構成されなければならない、即ち、アドレスはアドレスプール405から選ばれ、アドレスプール405は識別された装置403iにそのアドレスを与える。
【0065】
この実施形態は第2、第3、第4のいずれかと結合して使用され得るであろう。
【0066】
第6の実施形態:
第6の実施形態は上記実施形態のどれとも結合して使用され得る。この実施形態はコントローラ401に関する障害許容力(resilience)問題に関する。コントローラ401が動作的に不活性であるか、コントローラ上のローディングが許容できない程高い場合に、ある種の「バックアップ」システムが要求される。
【0067】
第6の実施形態は第2の、或いはミラー(mirror)、コントローラを提供し、それは所定の判断基準に従ってコントローラ401の動作状態とローディングを監視する。コントローラ401が該判断基準の1またはそれ以上を満足できないことをミラーコントローラが検出した場合には、ミラーコントローラはすべての制御を該ミラーコントローラへ切換え、その後上述の方法で要求にサービスするか、或いはミラーコントローラは該ミラーコントローラとコントローラ401間の制御を均衡させる。好ましくは警告(alert)がトランスレータ400を動作しているものに送信される。
【0068】
コントローラ401iの縦続された(cascaded)構成は、要求の数がIPv6ネットワークの導入と比べると予想される事実の点から、好ましい構成になり得る。コントローラ401がセッションを装置403iに動的に割当てるので、トランスレータ400は上述の構成に何ら重大な変化を要求することなく複数の動作しているコントローラを含むことができる。さらに、DNSサーバ104、106は所与のコントローラが動作しない事態において要求を次に利用可能なコントローラへ送信するように構成することができる。(DNSサーバの特徴の1つは該サーバがあるドメインネームに関する要求を1以上の他のDNSサーバへ送信するように構成することが可能であることである。この特徴はコントローラに関係して採用されて、上述の効果を達成する。
【0069】
IETFによって出版された書類で述べられ、上記を参照されるように、(http://www.ietf.org/internet−drafts/draft−ietf−ngtrans−introduction−to−ipv6−transition−05.txtで利用可能である)、他のミグレーション(migration)方法は以下を含む。
・Automatic Tunnels
・Configured Tunnels
・Tunnel Broker
・6 over 4
・6 to 4
・Dual stack transition mechanism (DSTM)
・Stateless IP/ICMP Translation Algorithm (SIIT)
・Bump−In−the−Stack” Technique (BIS)
・SOCKS64
これらの方法のいくらかは、SIITのように、本質的にスケーラブル(scalable)である。それは、これがステートレス(stateless)メカニズムとBISであるからであり、アドレス変換がホストに取って代わるからである。しかしながら、他の方法、DSTMのような、NAT−PTに関して識別されるものと同様なスケーラビリティ(scalability)問題を欠点として持つ。本発明の実施形態はDSTMアーキテクチャの特徴に統合することができてそれらのスケーラビリティを改善する。
【0070】
DSTMと共に、そして当業者に知られているように、デュアルスタックホスト(dual stack host)はIPv6ネットワーク上のIPv4パケットをIPv4/IPv6の境界線でDSTMボーダールータ(border router)へトンネルし(tunnels)、そこでは該パケットはIPv4パケットに2次的に包含されていない。デュアルスタックホストは動的にDHCPサーバによってIPv4アドレスを割当てられる(該アドレスはIPv4ネットワーク内に送信されるどんなパケットに関してソースアドレスとして使用されることになる)。加えて、DHCPサーバはボーダールータのIPv6アドレスのデュアルスタックホストを伝える(“トンネルエンドポイント(tunnel endpoint)”と称される)。本発明の実施形態は、DHCPサーバが利用可能なボーダールータ上でローディング等に従ってIPv6トンネルエンドポイントアドレス(ボーダールータ)を割当てるように、DSTM方法に統合することができる。
【0071】
こうして、上述の実施形態の要素によって、コントローラ401はDHCPサーバと協働し、装置403iはDSTMボーダールータになるであろう。
【図面の簡単な説明】
【図1】
図1は第1と第2のネットワークと第1と第2のネットワーク間の伝送を容易にする知られた手段を表す概略図である。
【図2】
図2は、図1の第1と第2のネットワーク内に位置するホスト間の通信を開始するときに、知られたアドレス変換プロセスによって実行されるステップを表すフロー図である。
【図3】
図3は、データが図1の第1のネットワーク内に位置するホストから第2のネットワーク内に位置するホストに送信されるときに、知られたアドレス変換プロセスによって実行されるステップを表すフロー図である。
【図4】
図4は本発明の1実施形態によるアドレストランスレータを表す概念図である。
【図5】
図5aは図4にて表されたアドレストランスレータの一部を含むアドレスプールの構成を表す概念図である。図5bは図4にて表されたアドレストランスレータの一部を含むアドレスプールの別の構成を表す概念図である。図5cは図4にて表されたアドレストランスレータの一部を含むアドレスプールのさらに別の可能な構成を表す概念図である。
【図6】
図6は、第1のネットワーク内のホストによって扇動された伝送を開始するときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。
【図7】
図7は、データが図6の扇動ホストから第2のネットワーク内のホストに送信されるときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。
【図8】
図8は、データが第2のネットワーク内のホストから戻されるときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。
【図9】
図9は、第2のネットワーク内のホストによって扇動された伝送を開始するときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。
【図10】
図10は、データが図9の扇動ホストから第1のネットワーク内のホストへ送信されるときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。
【図11】
図11は、データが第1のネットワーク内のホストから戻されるときに、図4にて表されたアドレストランスレータの実施形態によって実行されるステップを表すフロー図である。

Claims (19)

  1. 第1のネットワーク内のネットワーク装置と第2のネットワーク内のネットワーク装置間の通信を提供する装置であって、第1のネットワークは第1の通信プロトコルに従って動作し、第2のネットワークは第2の通信プロトコルに従って動作する装置において、該装置は、
    (1)エイリアス(alias)を第1のネットワーク内のターゲットネットワーク装置に割当てる第1の手段であって、該エイリアスは第2のネットワークの通信プロトコルと互換性がある手段と、
    (2)該割当てられたエイリアスを該ターゲットネットワーク装置に関するアドレスに変換する第2の手段であって、該変換されたアドレスは第1のネットワークの通信プロトコルと互換性がある手段とを具備し、
    該第1の手段と該第2の手段は、該ネットワークの1或いは両方内にて別々にアドレス指定可能であり、該割当てられたエイリアスは第2の手段のアドレスに対応し、その結果、第2のネットワーク内のネットワーク装置が1又はそれ以上の伝送(communications)を該割当てられたエイリアスを含むアドレスを用いて送信するときに、該或いは各伝送を第2の手段へルート付けする(routed)ことができ、それによって第2の手段は該エイリアスを第1のネットワーク内のターゲットネットワーク装置のアドレスに変換し、該伝送を第1のネットワークへ送信する。
  2. 請求項1に記載された装置において、該エイリアスはネットワークアドレスを有する。
  3. 請求項2に記載された装置において、該ネットワークアドレスは第2の手段を表す識別子を含む。
  4. 請求項3に記載された装置において、第2の手段は複数のさらなる装置を有する。
  5. 請求項4に記載された装置において、前記或いは各さらなる装置は1又はそれ以上のグループのエイリアスにアクセスする。
  6. 請求項5に記載された装置において、各グループは記憶装置内に記憶される。
  7. 請求項5に記載された装置において、2又はそれ以上のグループが記憶装置内に記憶される。
  8. 請求項4乃至請求項7のいずれか1項に記載の装置は、所定の判断基準に従って複数のさらなる装置の1を選択する選択手段を有する。
  9. 請求項8に記載された装置において、該所定の判断基準は装置特性を含む。
  10. 請求項9に記載された装置において、該選択手段は装置特性を監視するよう動作可能である。
  11. 請求項9または請求項10に記載された装置において、該装置特性は、装置の動作状態、装置のローディング(loading)、及び装置に利用可能なエイリアスの少なくとも1つを含む。
  12. 請求項8乃至請求項11のいずれか1項に記載された装置において、該選択手段は第1の手段に動作的に関連している。
  13. 請求項4乃至請求項12のいずれか1項に記載された装置において、第1の手段は該さらなる装置に利用可能なエイリアスを検索するように動作可能であり、検索されたエイリアスが該割当てられたエイリアスである。
  14. 請求項4乃至請求項13のいずれか1項に記載された装置は、該割当てられたエイリアスと該エイリアスに割当てられたターゲットネットワーク装置との間のマッピング(mappings)を記憶するマッピング記憶装置を含む。
  15. 請求項14に記載された装置において、該マッピング記憶装置は第1の手段によって管理される。
  16. 請求項14に記載された装置において、該マッピング記憶装置はデータベースによって管理される。
  17. 請求項14に記載された装置において、該マッピング記憶装置は該さらなる装置によって管理される。
  18. 第1のネットワーク内のネットワーク装置と第2のネットワーク内のネットワーク装置間の通信を提供する方法であって、第1のネットワークは第1の通信プロトコルに従って動作し、第2のネットワークは第2の通信プロトコルに従って動作する方法において、該方法は、
    (1)所定の判断基準に従って複数のさらなる装置からさらなる装置を選択するステップと、
    (2)ネットワークの1つ内のネットワーク装置に対して割当てる該選択されたさらなる装置にアクセス可能なネットワークアドレスを検索するステップであって、該検索されたネットワークアドレスは他のネットワークの通信プロトコルと互換可能なステップと、
    (3)該検索されたネットワークアドレスを該ネットワーク装置に対するエイリアスとして割当てるステップと、
    (4)該割当てられたエイリアスを該ネットワーク装置から送信された1又はそれ以上の伝送に適用するステップと、
    (5)該或いは各伝送を送信するステップと、
    を具備する。
  19. 請求項18に記載された方法は、
    該または各さらなる装置の装置特性を監視するステップと、
    該監視された装置特性を該所定の判断基準と比較して該さらなる装置を選択できるようにするステップと、をさらに含む。
JP2002571683A 2001-03-08 2002-03-05 アドレス変換器 Expired - Fee Related JP4001820B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP01302109 2001-03-08
PCT/GB2002/000970 WO2002073933A1 (en) 2001-03-08 2002-03-05 Address translator

Publications (2)

Publication Number Publication Date
JP2004519928A true JP2004519928A (ja) 2004-07-02
JP4001820B2 JP4001820B2 (ja) 2007-10-31

Family

ID=8181772

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002571683A Expired - Fee Related JP4001820B2 (ja) 2001-03-08 2002-03-05 アドレス変換器

Country Status (7)

Country Link
US (1) US8046452B2 (ja)
EP (1) EP1366613B1 (ja)
JP (1) JP4001820B2 (ja)
AT (1) ATE409385T1 (ja)
CA (1) CA2435985C (ja)
DE (1) DE60229042D1 (ja)
WO (1) WO2002073933A1 (ja)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7296155B1 (en) * 2001-06-08 2007-11-13 Cisco Technology, Inc. Process and system providing internet protocol security without secure domain resolution
CA2455492C (en) * 2001-08-24 2010-10-12 John Robert King Apparatus and method of coordinating network events
US7284056B2 (en) * 2001-10-04 2007-10-16 Microsoft Corporation Resolving host name data
KR100451552B1 (ko) * 2002-01-08 2004-10-08 삼성전자주식회사 인터넷 프로토콜 주소 변환장치 및 이를 이용한 통신 방법
JP3972733B2 (ja) * 2002-05-30 2007-09-05 株式会社日立製作所 アドレス変換装置、アドレス変換システム、及びsipサーバ
US7356045B2 (en) 2002-10-22 2008-04-08 Cisco Technology, Inc. Shared port address translation on a router behaving as NAT & NAT-PT gateway
US20040088385A1 (en) * 2002-11-01 2004-05-06 Hexago Inc. Method and apparatus for connecting IPV4 devices through an IPV6 network using a tunnel setup protocol
US7305481B2 (en) * 2003-01-07 2007-12-04 Hexago Inc. Connecting IPv6 devices through IPv4 network and network address translator (NAT) using tunnel setup protocol
US20040153502A1 (en) * 2003-02-04 2004-08-05 Luliang Jiang Enhanced DNS server
KR100560737B1 (ko) * 2003-02-18 2006-03-13 삼성전자주식회사 듀얼스택을 이용한 아이피브이4 - 아이피브이6 전환 장치및 그 방법
CN100334858C (zh) * 2003-07-14 2007-08-29 中国科学院计算技术研究所 一种利用双重隧道机制穿透nat的方法
US7440466B2 (en) * 2003-08-05 2008-10-21 Intel Corporation Method, apparatus and system for accessing multiple nodes on a private network
US7340746B2 (en) 2003-08-07 2008-03-04 Sharp Laboratories Of America, Inc. Apparatus and methods for providing communication between systems having different protocol versions
US20050076141A1 (en) * 2003-09-19 2005-04-07 Williams Aidan Michael Use of an autoconfigured namespace for automatic protocol proxying
KR20050079420A (ko) * 2004-02-05 2005-08-10 삼성전자주식회사 터널링 서비스 방법 및 시스템
US7529852B2 (en) * 2004-05-17 2009-05-05 Cisco Technology, Inc. Method and apparatus for handling IPv4 DNS PTR queries across IPv4 and IPv6 networks
JP4027347B2 (ja) * 2004-06-04 2007-12-26 キヤノン株式会社 情報処理装置、データ通信方法、プログラム及び記録媒体
KR100636186B1 (ko) * 2004-10-28 2006-10-19 삼성전자주식회사 양방향 터널 설정 방법 및 시스템
US8145908B1 (en) * 2004-10-29 2012-03-27 Akamai Technologies, Inc. Web content defacement protection system
KR100666987B1 (ko) * 2004-11-15 2007-01-10 삼성전자주식회사 이중스택 전환 메커니즘을 이용한 IPv4-IPv6 전환시스템 및 그 방법
US20060146870A1 (en) * 2004-12-30 2006-07-06 Harvey George A Transparent communication with IPv4 private address spaces using IPv6
CN1870569B (zh) * 2005-05-25 2012-02-08 国际商业机器公司 网络系统及其管理方法、通信终端和报文发送方法
JP4327142B2 (ja) * 2005-09-29 2009-09-09 パナソニック株式会社 情報処理システム、トンネル通信装置、トンネル通信方法、代理応答装置、及び代理応答方法
US7903585B2 (en) 2006-02-15 2011-03-08 Cisco Technology, Inc. Topology discovery of a private network
US8788706B2 (en) * 2006-02-27 2014-07-22 Vudu, Inc. Method and system for managing data transmission between devices behind network address translators (NATs)
ES2348043T3 (es) * 2006-04-28 2010-11-29 Koninklijke Kpn N.V. Conexion en cascada de servicios externos.
KR100757881B1 (ko) * 2006-09-20 2007-09-11 삼성전자주식회사 Nat를 이용한 자동 터널링 방법 및 그 시스템
US20080172493A1 (en) * 2007-01-11 2008-07-17 Ericsson, Inc. Method, system and host for telecommunications involving IPv4 and IPv6
US8489716B2 (en) * 2007-02-02 2013-07-16 Silver Spring Networks, Inc. Method and system of providing network addresses to in-premise devices in a utility network
WO2010139194A1 (zh) * 2009-06-03 2010-12-09 中国移动通信集团公司 具有IPv4应用的主机进行通信的方法及设备
GB0910388D0 (en) * 2009-06-16 2009-07-29 Icera Inc Data transmission
US8509244B2 (en) 2009-08-14 2013-08-13 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for providing host node awareness for multiple NAT64 environments
US8516141B2 (en) * 2009-09-01 2013-08-20 Konica Minolta Laboratory U.S.A., Inc. Method and system for modifying and/or changing a MAC ID utilizing an IPv6 network connection
US8509185B2 (en) 2010-02-26 2013-08-13 Telefonaktiebolaget Lm Ericsson Enabling IPV6 mobility with NAT64
US9276901B2 (en) * 2010-05-21 2016-03-01 Brian Heder Method, system, and apparatus for transitioning from IPv4 to IPv6
US8504722B2 (en) * 2010-06-14 2013-08-06 Telefonaktiebolaget Lm Ericsson Enhancing DS-lite with private IPV4 reachability
US8406232B2 (en) 2010-06-17 2013-03-26 Microsoft Corporation 4to6 network stack for IPv4 applications
CN102347993B (zh) * 2010-07-28 2014-03-26 中国移动通信集团公司 一种网络通信的方法和设备
US8484666B2 (en) 2010-09-13 2013-07-09 Microsoft Corporation Optimizations for implementing multi-stack stack hosts
US10142160B1 (en) 2011-10-04 2018-11-27 Big Switch Networks, Inc. System and methods for managing network hardware address requests with a controller
US8856384B2 (en) * 2011-10-14 2014-10-07 Big Switch Networks, Inc. System and methods for managing network protocol address assignment with a controller
US9621495B1 (en) * 2012-12-10 2017-04-11 Jeffrey Brian Shumate Anonymous messaging proxy
US20140258491A1 (en) * 2013-03-11 2014-09-11 Bluebox Security Inc. Methods and apparatus for hostname selective routing in dual-stack hosts
US9241292B2 (en) * 2013-09-25 2016-01-19 Google Inc. Seamless application connectivity
US10873564B2 (en) * 2018-09-20 2020-12-22 Palo Alto Research Center Incorporated Cloud-based device manager based on message queues
KR20210050874A (ko) * 2019-10-29 2021-05-10 삼성전자주식회사 Dns 쿼리-응답 시간 단축 방법 및 이를 지원하는 전자 장치

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI90710C (fi) * 1992-05-29 1994-03-10 Icl Personal Systems Oy Menetelmä paikallisverkkoon tarkoitetun TCP/IP-ohjelmiston sovittamiseksi etäyhteydelle
JP3531367B2 (ja) * 1996-07-04 2004-05-31 株式会社日立製作所 トランスレータ
US7088726B1 (en) * 1996-07-04 2006-08-08 Hitachi, Ltd. Translator for IP networks, network system using the translator, and IP network coupling method therefor
US6690669B1 (en) * 1996-11-01 2004-02-10 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus
EP0840482B1 (en) 1996-11-01 2007-04-25 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus
US6172986B1 (en) * 1997-05-13 2001-01-09 Hitachi, Ltd. Mobile node, mobile agent and network system
US6745243B2 (en) * 1998-06-30 2004-06-01 Nortel Networks Limited Method and apparatus for network caching and load balancing
US6490289B1 (en) * 1998-11-03 2002-12-03 Cisco Technology, Inc. Multiple network connections from a single PPP link with network address translation
US6427174B1 (en) * 1998-11-12 2002-07-30 Cisco Technology, Inc. Dynamic IP addressing and quality of service assurance
US6781991B1 (en) * 1999-02-26 2004-08-24 Lucent Technologies Inc. Method and apparatus for monitoring and selectively discouraging non-elected transport service over a packetized network
US6751191B1 (en) * 1999-06-29 2004-06-15 Cisco Technology, Inc. Load sharing and redundancy scheme
WO2001006734A2 (en) 1999-07-16 2001-01-25 3Com Corporation Mobile internet protocol (ip) networking with home agent and/or foreign agent functions distributed among multiple devices
US6772333B1 (en) * 1999-09-01 2004-08-03 Dickens Coal Llc Atomic session-start operation combining clear-text and encrypted sessions to provide id visibility to middleware such as load-balancers
JP4505168B2 (ja) * 1999-09-24 2010-07-21 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー パケットネットワークのインターフェイシング
EP1087575A1 (en) * 1999-09-24 2001-03-28 BRITISH TELECOMMUNICATIONS public limited company Packet network interfacing
US6708219B1 (en) * 1999-10-26 2004-03-16 3Com Corporation Method and system for dual-network address utilization
JP4501230B2 (ja) * 2000-05-30 2010-07-14 株式会社日立製作所 IPv4−IPv6マルチキャスト通信方法および装置
US6892245B1 (en) * 2000-09-22 2005-05-10 Nortel Networks Limited Management information base for a multi-domain network address translator

Also Published As

Publication number Publication date
JP4001820B2 (ja) 2007-10-31
WO2002073933A1 (en) 2002-09-19
DE60229042D1 (de) 2008-11-06
EP1366613A1 (en) 2003-12-03
CA2435985C (en) 2009-10-13
US20040093434A1 (en) 2004-05-13
ATE409385T1 (de) 2008-10-15
US8046452B2 (en) 2011-10-25
EP1366613B1 (en) 2008-09-24
CA2435985A1 (en) 2002-09-19

Similar Documents

Publication Publication Date Title
JP4001820B2 (ja) アドレス変換器
EP1488610B1 (en) System for selecting a connectivity mechanism
KR100317443B1 (ko) 인터넷프로토콜필터
US8526467B2 (en) Facilitating transition of network operations from IP version 4 to IP version 6
US6708219B1 (en) Method and system for dual-network address utilization
Srisuresh et al. Load sharing using IP network address translation (LSNAT)
JP4351449B2 (ja) Ipテレフォニーを実行するためのシステムおよび方法
EP1164754B1 (en) Methods and arrangements in a telecommunications system
KR100650843B1 (ko) 임의의 어플리케이션 타입이 있는 ip 네트워크에서네트워크 주소 변환을 사용하기 위한 방법 및 시스템
US20030154306A1 (en) System and method to proxy inbound connections to privately addressed hosts
US7161897B1 (en) Communications system, apparatus and method therefor
US9654540B2 (en) Load balancing among network servers
JP4712481B2 (ja) 通信方法および装置
Shah et al. An examination of next generation IP migration techniques: Constraints and evaluation
US7356031B1 (en) Inter-v4 realm routing
Berkowitz Router renumbering guide
KR101124635B1 (ko) IPv4/IPv6 연동 게이트웨이
KR100562390B1 (ko) 호스트 라우팅과 IP Aliasing 기법을 이용한 네트워크 데이터 플로우 식별 방법 및 시스템
US20210320859A1 (en) An architecture for managing ipv4 based customer premisses equipments through ipv6
JP2000156710A (ja) Ipアドレス変換装置
US20230388397A1 (en) Resolving Overlapping IP Addresses in Multiple Locations
Adewale et al. IP Tunneling and Stateless DHCPv6 Implementation in an Enterprise Network
Feng et al. Load balance and fault tolerance in NAT-PT
Johansson Evaluation of prerequisites for an IPv4 to IPv6 transition
Ng et al. A Distributed Waypoint Service Approach to Connect Heterogeneous Internet Address Spaces

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060620

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060920

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20061117

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070116

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070516

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20070628

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070717

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070815

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100824

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4001820

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110824

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120824

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130824

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees