JP5607617B2 - ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ - Google Patents

ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ Download PDF

Info

Publication number
JP5607617B2
JP5607617B2 JP2011515565A JP2011515565A JP5607617B2 JP 5607617 B2 JP5607617 B2 JP 5607617B2 JP 2011515565 A JP2011515565 A JP 2011515565A JP 2011515565 A JP2011515565 A JP 2011515565A JP 5607617 B2 JP5607617 B2 JP 5607617B2
Authority
JP
Japan
Prior art keywords
ipv6
address
ipv4
data packet
destination address
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.)
Expired - Fee Related
Application number
JP2011515565A
Other languages
English (en)
Other versions
JP2011526756A5 (ja
JP2011526756A (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.)
Orange SA
Original Assignee
France Telecom SA
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=40527988&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP5607617(B2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of JP2011526756A publication Critical patent/JP2011526756A/ja
Publication of JP2011526756A5 publication Critical patent/JP2011526756A5/ja
Application granted granted Critical
Publication of JP5607617B2 publication Critical patent/JP5607617B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/251—Translation of Internet protocol [IP] addresses between different IP versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

本発明の分野は通信ネットワークであり、具体的には、送信元アドレスによって識別されるソース機器からのデータパケットを、宛先アドレスによって識別される宛先機器へ転送するIP通信ネットワークである。
この種の通信ネットワークは、複数の機器、接続、およびネットワークに接続された端末機器からのデータ転送専用の機能を組み合わせる。具体的には、転送機能は、ルーティングおよび伝送のプロトコルを活性化することにより実施され得る。業者(operator)によって管理された通信ネットワークは、ドメインとも称される。
IP接続サービスプロバイダは、端末機器ユーザが交信することを可能にするように専用の構成を配備する。IP接続サービスへのアクセスは、サービスプロバイダが、端末機器によってデータパケットの最終の宛先へ送られるデータパケットをルーティングするように、業者の通信ネットワークを用いて管理する。いくつかの環境では、前記サービスプロバイダは通信ネットワーク業者でもある。
この種のサービスプロバイダは、一般に、パブリックIPアドレスであるIPアドレスを、ホームネットワークと業者のパブリックネットワークすなわちIPドメインとの間のホームゲートウェイに割り当てる。ホームゲートウェイは、一般に、そのホームネットワークの端末にプライベートIPアドレスを割り当てる。
以下で、「ホームゲートウェイ」という表現は、プライベートネットワークとサービスプロバイダによって経営されるネットワークとを相互接続するための機器を指し、プライベートネットワークは、ホームネットワークまたは業務ネットワークのいずれかである。
サービスプロバイダによって経営されるネットワークは、以下でパブリックネットワークとも称される。
ホームゲートウェイは、ホームゲートウェイのプライベートホームネットワーク端末と業者のIPドメインとの間のデータパケットの経路上に配置され、当技術分野で知られているように、ホームゲートウェイがIPv4タイプのパブリックIPアドレスおよびパブリックネットワーク上の同一のゲートウェイのポートを用いてプライベートIPアドレスとその端末に関連したポートとを関連付けるテーブルを含む。
このテーブルは、NAT(ネットワークアドレス変換)テーブルとして当業者に知られている。例えば、対称、Full Cone、およびPort Restrictedといった様々なタイプのネットワークアドレス変換がある。
IPサービスプロバイダのコミュニティでは、IPv4パブリックアドレスが使い尽くされつつあると一般に受け取られている。この問題を回避するために、同コミュニティは、これまでに、インターネットプロトコルバージョン6(IPv6)として知られている新規のプロトコルの定義に通じる対応策をとっている。インターネットプロトコルのこの新バージョンは、多くのIPアドレスおよび階層型ルーティング構造をもたらし、改善された性能を提供する。プロバイダは、Internet Engineering Task Force (IETF)から最近発せられた警告、ことさらGlobal Routing Operations Working Group (GROW)に提示された、Internet Assigned Numbers Authority (IANA)の、2010年の終りまでにIPv4アドレスが使い尽くされるリスクに関するレポートで発せられた警告に無関心ではない。
しかし、実際上、このIPv6の解決策は、遷移および移行の複雑さの管理に関係する財務上の理由、戦略的理由、および技術的理由で、まだ業者によって広く採用されていない。
クライアントのインストールされたベースにIP接続サービスを提供するのに必要なIPv4パブリックアドレスの数を制限するために、Double NATまたはOperator NATとして知られている解決策が提案され、実施されている。この解決策は、ホームゲートウェイがそれらの発信のNATテーブルで(パブリックアドレスの代わりに)プライベートアドレスを用いるように、業者の通信ネットワーク内でNAT機能を活性化することを必然的に伴う。したがって、Operator NAT機能は、ホームゲートウェイのプライベートアドレスをパブリックアドレスへと変換し、これによって、サービスプロバイダは、IP接続サービスを提供するのに必要なIPv4パブリックアドレスのかなりの数を節約することができる。
Operator NATの解決策には、以下の欠点が含まれる。
・第2段階のアドレス変換が導入されるためにデータパケットを2度変更しなければならないので、IPデータパケットの処理が、より複雑になる。
・ドメイン名システム(DNS)プロトコル、ファイル転送プロトコル(FTP)、およびセッション初期化プロトコル(SIP)など従来型のアプリケーションレベルゲートウェイ(ALG)シグナリングプロトコルの実装形態を適合させる必要がある。ホームゲートウェイのNATテーブルを最新の状態に保つために、例えばSIPを採用すると、ボイスオーバーIPセッションをセットアップして維持するのに、NATセッションがアクティブなままにするように、再登録要求によるユーザ端末とパブリックネットワークとの間の頻繁な信号交換が必要になり、Double NATを用いると、そのような機構もOperator NAT機能をホスティングする機器に設けなければならず、さらに、端末に対して実際に用いられているパブリックアドレスおよびパブリックポートを、SIPアプリケーションに伝達する必要がある。
・具体的にはポート転送およびDynDNSなどの機能がOperator NATでは対応されないので、低品位のIP接続サービスを提供するパブリック通信ネットワーク業者は、はなはだ残念に思うしかない。
その上、そのような解決策は、IPv4のアドレスが使い尽くされる現象を防止するのではなく、遅らせることしかできない。したがって、中期的にIPv6への転換を提供する必要がある。そのような転換は、IPv6ドメインがIPv4ドメインと相互接続しなければならない過渡期を必然的にもたらす。現行のネットワークには、そのような相互接続を、効率的に、最適に、かつIP接続サービスを提供するのに使用されるネットワークノードにおける付加的状態の具体化なしで促進するための備えがない。
また、IPv6ドメインとIPv4ドメインとの間の簡単な相互接続メカニズムに基づくIPv4アドレッシングからIPv6アドレッシングへの漸進的移行、具体的には、クライアントターミナルを必要とせずにIPv4およびIPv6の両方を実施するいかなる解決策の備えもない。
本発明は、IPv4ドメインに接続されたIPv6ドメインでIPv6宛先アドレスおよびIPv6送信元アドレスを含むIPv6データパケットを受信するための受信方法を提供することにより、上記の状況を改善する。
本発明によれば、前記方法は、ユーザ端末を前記IPv6ドメインに接続するように適合されたホームゲートウェイで実行され、
・業者プレフィックス(operator prefix)、IPv4宛先アドレスおよび宛先ポート番号を連結することにより構成されたIPv6宛先アドレスを識別するステップと、
・必要に応じて、データパケットの少なくとも1つのアドレスを、前記アドレスで置換することにより正規化するステップであって、置換プロセスが、構成されたアドレスを固有アドレス(native address)で置換するステップ、固有アドレスを構成されたアドレスで置換するステップ、および正規化されたアドレスを用いてデータパケットを変更するステップを含む群に属するステップと、
・変更されたデータパケットを、その宛先へルーティングするステップとを含む。
IPv4からIPv6へ移行する状況では、IPv4データパケットのみ送受信することができる、IPv4ドメインの第1の端末機器を考える。これと同時に、IPv6ドメインの第2の端末機器は、IPv6データパケットのみ送受信することができる。本発明によれば、これらの機器のうち一方がデータパケットを他方へ送信しようとする場合、同機器はそれ自体のプロトコルを用いるが、データはIPv6ドメインでIPv6プロトコルを用いてルーティングされる。
したがって、データパケットはIPv4またはIPv6で送信され、IPv6ドメインでデータパケットをルーティングするように必要に応じてIPv6データパケットに変換され、必要に応じてIPv4データパケットに変換し直される。
そのような変換は、業者プレフィックス、このIPv4宛先アドレス、およびパケット宛先ポート番号を連結することにより、第1の端末のIPv4宛先アドレスからIPv6宛先アドレスを構成するための機構に依存する。IPv6ドメインとIPv4ドメインとを相互接続するための機器が、IPv4の宛先アドレスおよび宛先ポートからIPv6宛先アドレスを構成する状況を考えた。構成されたIPv6宛先アドレスは、IPv6ドメインでルーティングすることができ、IPv4データパケットによって搬送されるペイロード情報を含む。
この変換は、IPv6プロトコルを用いるが、「ダミーの」IPv4アドレスを有効にするために第2のユーザ端末を必要とし、同アドレスは、その機器自体のIPv4アドレス、またはその機器が接続されるホームネットワークを管理するホームゲートウェイのIPv4アドレスであり得る。IPv4ドメインから来るIPv4パケットの宛先アドレスとして用いられるこのアドレスは、相互接続機器によって上記で言及されたIPv6宛先アドレスを構成するのに用いられる。
反対に、そのような機構を用いて構成されたIPv6アドレス(すなわち、今しがた言及されたIPv6アドレスの構成形式に一致するもの)からIPv4のアドレスおよび送信元ポート番号を取得することが可能である。したがって、IPv4アドレスからIPv6アドレスへの変換テーブルを蓄積する必要性またはIPv4ドメインおよびIPv6ドメインの両方のアクセスノード(相互接続ノード)のセッションに関する状態を維持する必要性がない。したがって、本発明により、IPv4からIPv6への方向およびIPv6からIPv4への方向で、IPv4データパケットをその宛先へIPv6データパケットの形式でルーティングすることが可能になり、また、維持するのが困難な状態テーブルに頼ることなくパケットに含まれるペイロード情報をその宛先へ配送することが可能になる。
したがって、データパケットを受信または送信するユーザのIPv6端末および適用可能であれば同端末を管理するホームゲートウェイ、ならびにパケットをその宛先へルーティングするためのルータは、どれもIPv4プロトコルを解釈する必要がない。
しかし、固有のIPv6パケットと同様な、そのような変換からもたらされるIPv6データパケットのルーティングを可能にするために、前述のIPv6アドレスの構成形式に対して送信元アドレスおよび宛先アドレスを確認する必要がある。したがって、本発明の方法は、パケットの宛先または送信元をIPv4ドメインに属するものとして識別し、その結果として、それに対して適切な検証処理を適用する解決策を提案する。
本発明の一態様によれば、データパケットが前記ユーザ端末から来てIPv4ドメインへ行くとき、送信元アドレスを正規化するステップは、
・固有のIPv6送信元アドレスを識別するステップと、
・アドレス変換テーブルにエントリを生成するステップであって、前記エントリが、前記固有の送信元アドレスを、業者プレフィックス、ゲートウェイに割り当てられたIPv4アドレス、および前記ゲートウェイ向けに認証されたポート番号の範囲に属する送信元ポート番号を連結して構成された送信元アドレスに関連付けるステップと、
・データパケットの固有の送信元アドレスを構成された送信元アドレスで置換するステップとをさらに含む。
これは発信コールに関するものである。構成された宛先アドレスが識別されている場合、IPv4ドメインのユーザ端末向けにデータパケットがあることが推定され得る。この状況では、データパケットの送信元アドレスは、IPv6/IPv4ドメイン相互接続機器が、その後IPv4送信元アドレスを回復し、かつIPv6データパケットをIPv4データパケットに変換し直すことができるように、構成されたアドレスでなければならない。処理が達成されない場合、固有の送信元アドレスがIPv4送信元アドレス、すなわちパケットを送信した端末のダミーIPv4アドレスに関する情報を含まないので、相互接続ノードはパケットを処理することができない。
送信元アドレスが固有の送信元アドレスである場合、本発明の方法により、同アドレスを、ゲートウェイ向けに認証されたプレフィックスまたはIPv6送信元アドレス範囲に属する構成された送信元アドレスに置換することが可能になる。
このデータパケットに対する応答の受信を見込んで、固有の送信元アドレスと構成された送信元アドレスとの間の関連がホームゲートウェイのアドレス変換テーブルに追加される。
したがって、応答データパケットが、第1のデータパケットを送信したホームネットワークのユーザ端末へルーティングされ得る。
本発明の利点は、本発明のゲートウェイがパケットの宛先へのルーティングに必要なことを行うので、本発明により、IPv6ユーザ端末が、データパケットをIPv4ドメインへ送信するのに、その好みの送信元アドレスを用いることができることである。
本発明の一態様によれば、アドレス識別は、宛先アドレスに含まれる識別子を用いる。
この識別子は、アドレスが、固有のIPv6アドレスか、あるいはIPv4アドレスから構成されたIPv6アドレスか、ということ次第で別々の値を有することができる。これの利点の1つに、データパケットのアドレスの性質の簡単かつ迅速な識別が可能になることがある。この種の解決策により、業者間のIPv4/IPv6相互接続機器の相互扶助も可能になる。
本発明の別の態様によれば、この受信方法は、データパケットの送信元ポート番号と構成された送信元アドレスの送信元ポート番号との一致を確認するステップをさらに含む。
データパケットは、ISOモデルのトランスポート層に、送信元ポート番号を実際に含む。応答を、第1のパケットを送信した端末へネットワークによってルーティングするには、この転送レベルの送信元ポート番号が、データパケットの構成された送信元アドレスに含まれる送信元ポート番号と一致することが重要である。そうでない場合、本発明の方法により、2つの送信元ポート番号のマッチングが可能になる。
確認ステップと送信元アドレスを正規化するステップとが同時に実行され得ることに留意されたい。例えば、ゲートウェイのプレフィックスの中に構成された送信元アドレスの選択は、転送レベルの送信元ポート番号と等しい送信元ポート番号を有すること、といった制限を組み込むことができる。
本発明の一態様によれば、データパケットが、IPv4ドメインから来て前記ホームゲートウェイを経由してIUPv6ドメインに接続されたユーザ端末へ行くとき、宛先アドレスを正規化するステップは、
・前記宛先アドレスに固有の宛先アドレスを関連付けるエントリを求めて前記ゲートウェイのアドレス変換テーブルを探索するステップと、
・エントリが見つかった場合、データパケットの構成された宛先アドレスを、そのエントリからの固有の宛先アドレスで置換するステップとを含む。

宛先ポート番号もポートのポート番号で置換され、アドレス変換テーブルがホームゲートウェイによって維持されることに留意されたい。
上記の注釈は着信コールに関するものである。IPv6データパケットは、IPv6ドメインとIPv4ドメインとを相互接続するための機器によってIPv4パケットから構成されたものである。同データパケットは、ホームゲートウェイに接続されたユーザ端末によってあらかじめ送信されたデータパケットに対する応答でよい。したがって、ゲートウェイはそのアドレス変換テーブルを調べる。ゲートウェイが、受信したデータパケットから抽出された宛先アドレスと固有のIPv6宛先アドレスとの間の関連性をアドレス変換テーブルの中に見いだすと、ゲートウェイは、データパケットの構成された宛先アドレスおよび場合によっては構成された宛先ポート番号を、このテーブルエントリの固有のIPv6アドレスで置換し、変更されたパケットを宛先端末へルーティングする。
本発明の別の態様によれば、この受信方法は、データパケットの宛先ポート番号と構成された宛先に含まれる宛先ポート番号との一致を確認するステップをさらに含む。
そのような確認により、その転送レベルでのデータパケットの宛先ポート番号がパケットの構成された宛先アドレスからの番号と一致することを確信することが可能になる。ホームゲートウェイに割り当てられたダミーのIPv4アドレスが他の端末またはホームゲートウェイによって共有される場合、この確認は特に有益である。この状況では、これらの機器の区別は、用いられるポート番号の範囲に基づく。本発明によれば、IPv4端末によって前記ダミーアドレスへ送信されたパケットは、いかなるルーティング問題にも遭遇することなく関係するゲートウェイへルーティングされ得る。
この受信方法は、IPv4ドメインに接続されたIPv6ドメインで、IPv6宛先アドレスおよびIPv6送信元アドレスを含むデータパケットを受信するためのデバイスで用いられ得て、
・業者プレフィックス、IPv4宛先アドレス、および宛先ポート番号を連結することによって構成されたIPv6宛先アドレスを識別するステップと、
・必要に応じて、データパケットの少なくとも1つのアドレスを正規化し、正規化されたアドレスを用いてデータパケットを変更するステップと、
・変更されたデータパケットを、その宛先へルーティングするステップとを含むことを特徴とする。
本発明の特定の一実装形態では、データパケットの受信方法のステップは、コンピュータプログラムの命令によって決定される。
したがって、本発明は、受信デバイス、またはより一般的にはコンピュータで実行されるように適合された情報媒体上のコンピュータプログラムも提供し、このプログラムは、前述のように、送信、受信またはルーティングの方法のステップを実行するための命令を含む。
このプログラムは、任意のプログラミング言語を用いることができ、ソースコード、オブジェクトコード、または部分的にコンパイルされた形式などソースコードとオブジェクトコードとの中間コード、あるいは他の望ましい形式をとることができる。
本発明は、上記で言及されたようなコンピュータプログラムの命令を含むコンピュータ可読情報媒体も提供する。
この情報媒体は、プログラムを記憶することができる任意のエンティティまたはデバイスでよい。例えば、この媒体は、例えばCD ROMまたは超小型電子回路のROMであるROM、あるいは、例えばフロッピー(登録商標)ディスクまたはハードディスクといった磁気記憶装置手段などの記憶手段を含むことができる。
その上、この情報媒体は、電気ケーブルまたは光ケーブルを介して、無線または他の手段によってルーティングされ得る電気信号または光信号などの伝達可能な媒体でよい。本発明のプログラムは、具体的にはインターネットタイプのネットワークによってダウンロードされ得る。
あるいは、この情報媒体は、プログラムが組み込まれている集積回路でよく、この回路は、対象となっている方法を実行するように、もしくはその実行で用いられるように適合される。
本発明は、ユーザ端末をIPv4ドメインに接続されたIPv6ドメインに接続するように適合されたホームゲートウェイをさらに提供する。
本発明によれば、そのようなゲートウェイは、
・IPv4アドレス、前記ゲートウェイ向けに認証された範囲のポート番号、および前記ゲートウェイ向けに認証された範囲のIPv6アドレスを得るための手段であって、前記IPv6アドレスの範囲が、業者プレフィックス、前記IPv4アドレス、および認証されたIPv4ポート番号の範囲を連結することにより構成される手段と、
・IPv4ドメインに接続されたIPv6ドメインでIPv6データパケットを受信するための本発明のデバイスとを含む。
本発明によれば、そのようなゲートウェイはIPv6データパケットだけを処理する。しかし、同ゲートウェイには、IPv4ドメインの送信機によって識別され、かつ交信され得るように、IPv4アドレスが割り当てられている。ホームゲートウェイは、IPパケットを送信するのに前記アドレスを用いない。
ホームゲートウェイは、そのホームネットワークのユーザ端末を含む通信セッションに関する少なくとも1つの送信元アドレスに関連するエントリを含むアドレス変換テーブルを保持することができる。本発明によれば、前記ゲートウェイは、構成されたIPv6送信元アドレスおよび固有のIPv6送信元アドレスを前記エントリに記憶するように適合される。
本発明の他の利点および特徴は、例示的であって限定的でない例としてのみ提供された、本発明の1つの特定の実装形態の以下の説明および添付図を読み取ることで、より明らかになる。
本発明によって相互接続されたIPv6ドメインおよびIPv4ドメインを図解的に示す図である。 本発明によって構成されたIPv6アドレスプレフィックスの構成を示す図である。 本発明による、IPv4ドメインと相互接続されたIPv6ドメインでデータパケットを受信する方法のステップを図解的に示す図である。 IPv4の宛先アドレスおよび宛先ポートから構成されたIPv6アドレスの本発明の第1の実装形態の構成を示す図である。 本発明の第1の実装形態の受信方法を実施するためにIPv4の宛先アドレスおよび宛先ポートから構成されたIPv6宛先アドレスの本発明による構成を示す図である。 本発明の第1の実装形態の受信方法を実施するためにIPv4の送信元アドレスおよび送信元ポートから構成されたIPv6送信元アドレスの構成を示す図である。 IPv4の宛先アドレスおよび宛先ポートから構成されたIPv6アドレスの本発明の第2の実装形態の構成を示す図である。 本発明の第2の実装形態において、IPv4ドメインと相互接続されたIPv6ドメインでデータパケットを受信するステップを図解的に示す図である。 IPv6ドメインでデータパケットを受信するための本発明のデバイスの構成を図解的に示す図である。
本発明の一般的原理は、IPv4アドレス、所定の業者プレフィックス、およびポート番号から、IPv6アドレスを構成するステップに依存する。これによって、IPv6ドメインへのアクセスノードの中にIPv4アドレスとIPv6アドレスとの対応テーブルを維持する必要性なしで、IPv6ドメインに入るIPv4パケットと、IPv4ドメインへ行くためにIPv6ドメインを出るIPv6パケットとの変換が可能になる。
IPv6アドレスは、4バイト(32ビット)のIPv4アドレスと比較して、16バイト(128ビット)を備えることが思い起こされよう。したがって、IPv4アドレスの数と比較してIPv6アドレスの数は非常に大きくとることができる。IPv6アドレスには、
・ドメインのサブネットワークを識別する左寄りの部分(プレフィックス)と、
・サブネットワークに接続された装置を識別する右寄りの部分との2つの部分がある。
サブネットワークに割り当てられる最長のプレフィックスは、一般に「/64」プレフィックスであり、すなわちサブネットワークの識別用の64ビットを含む。次いで、右寄り64ビットのアドレスは、サブネットワークに属する特定の装置を識別するのに用いられる。プレフィックスをより短くすると(例えば「/56」または「/48」にさえ)、より多くのサブネットワークの識別が可能になり、サブネットワーク自体が多くの場合「/64」サブネットワークを含む。しかし、「/64」より長いプレフィックスの使用を禁止するIPv6規定があるわけではなく、したがって、例えば4096の装置を含み得るサブネットワークを識別する「/116」プレフィックスを考えることができる。
「/64」より長いプレフィックスに対する制約は、単に、対応するサブネットワークの背後の装置が、文献RFC 2462に説明された自動設定機構を用いることができなくなるだけであることに留意されたい。この機構によって、装置は、それ自体を構成するのにそのレベル2のアドレス(例えばそのMACイーサネット(登録商標)アドレス)を知ることができ、一定の条件下で、正確なアルゴリズムを用いて、そのレベル2のアドレスをIPv6アドレスの右寄り64ビットから導出する。しかし、この自動設定機構は必須のものではなく、例えばDHCPv6プロトコル(RFC 3315を参照されたい)に対応して、とりわけDHCPv6サーバからIPv6アドレスを得ることが可能になる他の機構が好ましいことがある。
次に、簡単なIPv6装置からIPv6ルータ(例えばIPv6ホームゲートウェイ)へ移って、そのような機器は、同機器によってパケットをルーティングされるサブネットワークを表す1つまたは複数のIPv6プレフィックス有する必要があることが知られている。したがって、IPv6ルータは、1つまたは複数のプレフィックスで構成されなければならない。
DHCPv6プロトコルの拡張により、1つまたは複数のIPv6プレフィックス(例えばホームゲートウェイ)を必要とするルータは、プレフィックスを委譲することができる機器(一般的には上流のルータ)からのプレフィックスを要求することができる。この拡張は、RFC 3633(動的ホスト設定プロトコル(DHCP)バージョン6用のIPv6プレフィックスオプション)に説明されており、委譲された1つまたは複数のプレフィックスを通過させるためのDHCPv6メッセージのプレフィックス委譲オプションに関するアイデンティティアソシエーションを規定する。要求しているルータが、1つまたは複数のIPv6プレフィックスを一旦委譲されると、同ルータは、同ルータが管理する1つまたは複数のプレフィックスにアドレスが記入されている装置との間で行き来するすべてのIPv6パケットをルーティングする。
以下で、図1を参照しながら、IPv6ドメイン1とIPv4ドメイン3とを相互接続する機器(すなわちIPv4ドメイン3へのIPv6/IPv4アクセスノード40を含むIPv6ドメイン1)、およびIPv6ドメイン1に接続されたホームゲートウェイ20との間を行き来するデータパケットをルーティングするように適合されたアクセスルータ30が説明される。この種のゲートウェイは、端末21および22が接続されるホームネットワーク2を管理する。
本発明の状況では、IPv6プロトコルだけを実施するホームゲートウェイが検討される。したがって、そのようなゲートウェイは、IPv6データパケットだけを処理する(具体的には送受信する)ことができる。
端末21および22は、モノバージョン(mono-version)のIPv6(すなわち純然たるIPv6(pure IPv6))端末であり、それらがIPv6プロトコルだけを実施することを意味する。以下で、本発明が、IPv6端末に対して、IPv6ドメインと少なくとも1つのIPv4ドメインとの相互接続を可能にする様子が説明される。
以下の「ハイブリッド」環境が考えられる。
・IPv4ドメイン3のユーザ端末によって送信された着信のIPv4データパケットを、IPv6ドメイン1に接続されたゲートウェイ20のホームネットワークのユーザ端末21、22へルーティングし、かつ
・IPv6ドメイン1のユーザ端末21、22によって送信された発信のIPv6データパケットを、IPv4ドメイン3のユーザ端末へルーティングする。
純然たるIPv6パケットまたは純然たるIPv4パケットの送信の詳細は当業者に既知であり、ここでより詳細に説明することはない。
ホームゲートウェイは、IPv6のドメインまたはネットワークへ結合することができるように、接続サービスプロバイダによって提供されたIP接続要素を有する。
しかし、本発明は、ホームゲートウェイを介したIP接続サービス(例えばインターネットまたはイントラネット)へのアクセスに限定されず、他のインターネットまたはイントラネットのネットワークへアクセスする状況におけるユーザ端末にも適合する。一実施例に、モバイルネットワークの簡単なモバイル端末またはゲートウェイとして働くことができる精巧なモバイル端末からIP接続サービスへのアクセスがあり、例えばブルートゥースを介してそのローカルエリアネットワーク内の他の端末と通信する。
本発明によれば、ホームゲートウェイ20は、
・以下で「@IPv4」と指定される標準的なIPv4アドレスであって、ゲートウェイがそのホームネットワークで純然たるIPv6クライアントターミナルをホスティングする場合、このIPv4アドレスがゲートウェイによってIPトラフィックを送信/受信するのに用いられないので「ダミー」アドレスと称され、本発明がIPv6アドレスを構成するのに用いられる(以下を参照されたい)IPv4アドレスと、
・認証されたポート番号の範囲(ports_pattern/length_of_unvariable)と、
・構成されたIPv6アドレスプレフィックス(IPv6_prefix_ports_range)と、
・固有のIPv6アドレスプレフィックス(IPv6_prefix_native)であって、この第2のプレフィックスは必須ではなく、構成されたIPv6プレフィックスがそのままで十分であるIPv6アドレスプレフィックスとのIP接続要素を有する。
@IPv4、IPv6_prefix_ports_rangeおよびIPv6_prefix_nativeの諸要素は、通常のIPv4およびIPv6の状況における標準的な情報要素である。
本発明によれば、情報要素IPv6_prefix_ports_rangeは、本来、要素@IPv4およびports_pattern/length_of_unvariableを含む。
本発明の一実装形態では、IPv4アドレス@IPv4は、IPv6ドメイン1の複数のホームゲートウェイによって共有されるアドレスshared@IPv4であり、ホームゲートウェイ20に関する認証されたポート番号の範囲は、そのゲートウェイ用に確保されたポート番号の範囲である。
ホームゲートウェイ間でパブリックアドレスshared@IPv4を明確に共有すると、用いられるIPv4アドレスの数を節約し、かつアドレスが使い尽くされる現象を遅らせることができる。その上、その使用は、IPv4ドメインとIPv6ドメインとの相互接続の必要性によって正当化される。この相互接続は、代表アドレスによって一般に達成される。IPv6クライアントのインストールされたベースが大きい場合、多くのIPv4代表アドレスが必要である。
同一のアドレスshared@IPv4を共有する様々なホームゲートウェイは、疑いもなく小さいにも関わらず同ホームゲートウェイのそれぞれに対して確保された隣接するポート番号の範囲の利益を有するので、それらが用いるポート番号によって一意に識別される。
本発明は、機能するのにIPv4アドレスの割当てを必要とする、したがって透過的なやり方で不均一な端末(すなわち、IPv4およびIPv6など、別々のアドレス指定プロトコルを実施する端末)間の接続の連続性を保証する、IPv6ドメインとIPv4ドメインとの相互接続を提案するものである。
したがって、IPv4アドレスが共有される本発明の実装形態の利点は、IPv6アドレス指定への移行を容易にするのと同時にIPv4アドレスを節約することである。IPv4アドレス指定モードとIPv6アドレス指定モードとの間の過渡の状況では、これによって、移行が終るまでアドレスの窮乏の回避を有利に可能にすることができる。別の利点は、(IPv6の能力の利用がクライアントの行為ではなく業者によるので)IPv6設備への投資に対する即時の収益である。
説明の残りで、ゲートウェイ20に割り当てられるIPv4アドレスは、共有アドレスshared@IPv4である。
図1を参照すると、ホームゲートウェイ20は、アクセスルータ30を介して業者のネットワークに接続される。これは、IPv6データパケットおよびIPv4データパケットがホームゲートウェイを出るときに出会う最初のルータである。
IPv6ルーティングレベルで採用されるネットワークアーキテクチャによれば、アクセスルータ30は、ネットワークの上流方向へ(すなわちIP接続サービスプロバイダのネットワーク1の方へ)、アクセスルータ30がルーティングするIPv6プレフィックスすなわちプレフィックスIPv6_prefix_ports_rangeおよびアクセスルータ30が扱うホームゲートウェイIPv6_prefix_nativeを知らせることができる。
アクセスルータ30は、アクセスルータ30がIPv6ネットワーク環境においてもっぱら通常のやり方で扱うホームゲートウェイのIPv6プレフィックスを得る。以下で2つの方法が説明される。
1)アクセスルータ30が、アクセスルータ30が扱うホームゲートウェイからIPv6ルーティングの通知(IPv6_prefix_ports_rangeおよびIPv6_prefix_native)を受信するもので、この目的のために、各ホームゲートウェイは、そのプレフィックス(IPv6_prefix_ports_rangeおよびIPv6_prefix_native)を上流方向に知らせる。または、
2)アクセスルータ30が、RFC 3633(動的ホスト構成プロトコル(DHCP)バージョン6用のIPv6プレフィックスオプション)に説明されているように、プレフィックス代表によってIPv6_prefix_ports_rangeおよびIPv6_prefix_nativeを得る。
ホームゲートウェイ20に割り当てられたプレフィックスIPv6_prefix_ports_rangeなど、本発明によって構成されたIPv6アドレスプレフィックスの一実施例が、図2を参照しながら以下で説明される。
このIPv6プレフィックスは、ゲートウェイ20用にIPv4パブリックアドレスshared_@IPv4の諸ビット(bits)と認証されたポート番号の範囲(ports_pattern/length_of_unvariable)とを組み合わせて、着信のIPv6パケットを宛先ホームゲートウェイに明確にルーティングすることを可能にする。IPv6ネットワークでルーティングすることができるのはIPv6プレフィックスである。IPv6プレフィックスは、ホームゲートウェイを提供するネットワーク業者のプレフィックスに記入されたプレフィックスに選択されたならば(特に境界ゲートウェイプロトコル(BGP)で通知されたならば)、IPv6ネットワークでルーティングすらされ得るはずである。図2の実施例では、このプレフィックスは、左から右へ、
・アクセスノード40に割り当てられたIPv6プレフィックスIPv6/IPv4_Access_Node_ prefixであって、地域インターネットレジストリ(RIR)によってIP接続サービスプロバイダに割り当てられたIPv6業者プレフィックスIPv6-provに記入されるように有利に選択され、したがってその最初の諸ビットにこの業者プレフィックスを含むIPv6プレフィックスと、
・本発明によって、業者への相互接続サービスIPv6/IPv4_Access_Nodeを識別する諸ビットIPv6/IPv4_Access_Node_Serviceであって、IPv6/IPv4_Access_Node_Serviceの諸ビットが後続する業者プレフィックスの諸ビットで構成されるシーケンスが、同サービスを識別するプレフィックスIPv6/IPv4_Access_Node_Service_prefixを構成する諸ビットと、
・ホームゲートウェイに働く特定のアクセスノードIPv6/IPv4_Access_Nodeを識別する補足的諸ビットであって、ロードバランシングの理由で、プレフィックスIPv6/IPv4_Access_Node_prefixが唯一のアクセスノードだけに特有ではないことがある補足的諸ビットと、
・ゲートウェイ20の32ビットのアドレスshared@IPv4と、
・0に設定された任意選択の予備の8ビットであって、別々のタイプのポート(UDP、TCP、SCTPなど)を区別するのに用いられ得て、UDP処理用に値「X」をとることができ、TCP処理用に値「Y」をとることができるなどの8ビットと、
・ゲートウェイ向けに認証されたポート番号の範囲(ゲートウェイ20のIPv4アドレスが複数のホームゲートウェイによって共有されない場合、認証されたポート番号の範囲がすべてのゲートウェイの最大かつ同一のサイズであることに留意されたい)を表す16ビット(ports_pattern)であって、左寄りに長さlength_of_unvariableの上位不変部分(より上位の諸ビット)を有する16ビットとを備える。
プレフィックスの長さIPv6_prefix_ports_rangeは、[128-16(IPv6アドレスの長さ-ポートのコーディングアドレス)=112ビット、これにlength_of_unvariable(認証された送信元ポートの範囲を表す不変ビットの長さ)を加えたもの]として確立される。
本発明によって構成されたプレフィックスIPv6_prefix_ports_rangeは、IPv6の展開のためのIPv6規格によって推奨されるプレフィックスより長いことに留意されたい。それにも関わらず、同プレフィックスはIPv6規格に準拠する。
図1を参照しながら説明されたIPv6ドメイン1は、本発明の少なくとも1つのアクセスノード40を含む。同アクセスノードが、本発明の他のアクセスノードを含み得ることに留意されたい。アクセスノード40(IPv6/IPv4_Access_Node)は特別なデュアルスタック(IPv4およびIPv6)ルータであり、すなわちIPv4プロトコルおよびIPv6プロトコルの両方を実施する。
ネットワーク1の中のアクセスノード40(IPv6/IPv4_Access_Node)は、図1に示されるように、一般に1つまたは複数のアクセスルータ30の上流(すなわち隣接したネットワークとの相互接続セグメントのネットワークコアの方向)にある。前記アクセスノードは、相互接続ノードとも称される。
IPv6ドメインでIPv6データパケットを受信する方法が、以下で図3を参照しながら説明される。この方法は、ゲートウェイ20などのIPv6ドメインに接続されたホームゲートウェイに含まれる受信デバイスによって有利に実行され、ホームゲートウェイ2から来るデータパケットおよびIPv4ドメイン3から来るデータパケットを処理する。この種の方法は、固有のIPv6宛先アドレスまたはアクセスノードプレフィックス、IPv4宛先アドレスおよびIPv4宛先ポート番号を連結することにより構成されたIPv6宛先アドレスとしてIPv6宛先アドレスを識別するステップR1を含む。ここでは、ゲートウェイ20が、例えば設定によって、このプレフィックスをあらかじめ得ているものと想定されている。
この方法は、次いで、データパケットのアドレスを正規化するステップR2を含む。ホームゲートウェイからIPv6ドメインへの方向では、このアドレスはパケットの送信元アドレスであり、IPv6ドメインからホームネットワークへの方向では、このアドレスはその宛先アドレスである。このステップは、データパケットの変更をもたらすことができる。次いで、変更されたデータパケットは、その宛先へルーティングされる(ステップR3)。
例えばインターネット上のIPv4ウェブサーバであるIPv4宛先へ発信コールが設定される本発明の第1の実装形態を考える。例えばゲートウェイ20に接続されたIPv6のPC 22であるホームゲートウェイ2のユーザ端末は、IPv4ドメイン3内のこのグループへデータパケットを送信する。この状況では、PC上で実行されるアプリケーションはIPv6ブラウザである。送信元のユーザ端末22が純然たるIPv6端末であることに留意する必要がある。
ユーザ端末22は、ユーザ端末22に割り当てられている構成されたIPv6アドレスに等しい送信元アドレスを用いてIPv6データパケットを送信する、あるいはユーザ端末22は、ユーザ端末22に割り当てられている固有のIPv6アドレスに等しい送信元アドレスを用いてIPv6データパケットを送信する、という状況が生じる。
明らかに、このデータパケットは、端末があらかじめ回復しなければならないIPv4宛先に対応するIPv6宛先アドレスを含む。
したがって、端末22のブラウザは宛先ウェブサーバのIPv6アドレスを知る必要がある。このウェブサーバは、IPv4でのみアクセス可能である。したがって、端末22は、(たとえ、実際には同ウェブサーバにはIPv4アドレスしかなくても)端末22がウェブサーバのアドレスと見なすIPv6アドレスを有する必要がある。
この目的のために、IP接続サービスプロバイダまたはサードパーティが、ウェブサーバのIPv4アドレスをIPv6アドレスへ変換する機能を実施しなければならない。この変換機能は、もう一方のグループ(この実施例ではウェブサーバ)のIPv4アドレスを含むように、IPv6アドレス構成の形式に準拠しなければならない。この変換機能は、以下で図4を参照しながら説明される。
ここではDNS_IPv4toIPv6で示されるこの種の変換機能は、例えばIPv6ドメイン1のアクセスノード40であるIPv6/IPv4_Access_Nodeによって実行され得るが、より一般的なレベルではドメイン1のDNSサーバによって実行される。機能DNS_IPv4toIPv6は、リクエスタ端末(requester terminal)によって送信されたDNS解決要求に対する交信のデフォルト点である。この機能は、デフォルトで、タイプ「AAAA」の最初のIPv6レコード、換言すれば固有のIPv6アドレスを調べる。レコードが既に存在する場合、次いで、応答がリクエスタ端末へ送信される。レコードが存在しない場合、A型解決要求は変換機能DNS_IPv4toIPv6によって達成される。DNSサーバから、もう一方のグループ(この実施例ではウェブサーバ)のIPv4アドレスを含む応答を受信すると、機能DNS_IPv4toIPv6は、受信した応答の中のIPv4アドレスを、図4を参照しながら説明された形式に準拠するIPv6アドレスへ変換し、この情報をそのキャッシュに保持する。
図4の実施例は、単に本発明の一実装形態を表すものであり、重要なのは、もう一方のグループ(ここではウェブサーバ)のIPv4アドレスが、IPv6アドレスに記入されていることであることに留意されたい。DNSサーバから応答が受信されない場合、リクエスタ端末へエラーメッセージが送信される。
このようにしてIPv6アドレスに変換された宛先アドレス(ここではウェブサーバのもの)は、以下ではIPv6_remote_Address_out_to_IPv4で示される。要求された端末は、例えばサーバから他の手段で交信されるリモートマシンからのIPv6アドレスを回復することができることに留意されたい。
いずれにしても、もう一方のグループ(ここではウェブサーバ)のIPv6アドレスは、固有のIPv6アドレスまたは本発明で導入された形式に準拠するIPv6アドレスであり得る。構成されたアドレスIPv6_remote_Address_out_to_IPv4の環境では、同IPv6アドレスはプレフィックスIPv6/IPv4_Access_Note_Service_prefixに含まれている。
図4を参照すると、最も右寄りの2バイトのシーケンスは「確保」と印を付けられ、デフォルトで0に設定されることに留意されたい。この位置は、ユーザ端末を意図したパケットのIPv6アドレスIPv4inIPv6_dest_addressのポートビットのそれに相当する。この位置は、特に、もう一方のグループ(ここではウェブサーバ)がコールされることを望むポートを示すことができるように確保されている。同ウェブサーバは、これも複数の他のグループ間で共有されるIPv4アドレスを割り当てられ、したがってすべての有効なポートにアクセスを有するわけではないIPv4の他のグループであり得る。
次いで、宛先アドレスIPv6_remote_Address_out_to_IPv4を含むIPv6データパケットが、端末22によって送信される。
本発明のホームゲートウェイ20は、データパケットを受信するための本発明のデバイスを含む。以下で図5を参照しながら説明されるように、このデバイスは、IPv6パケットを受信すると、IPv4ドメインに接続された装置を表すIPv6アドレスへIPv6パケットを伝送する本発明の第1の実装形態の方法を実行するように適合される。
この方法は、前述のIPv6宛先アドレス識別ステップR1を実行する。
本発明の一態様は、プレフィックスIPv4_Access_Node_Service_prefixの長さがホームゲートウェイ20に知られていることであり、ホームゲートウェイ20は、そのIPv6_prefix_ports_rangeの対応するビットを利用することにより、その値を容易に求めることができる。この種の識別は、プレフィックスIPv4_Access_Node_Service_prefixに記入されているIPv6宛先アドレスを構成されたアドレスとして分類し、このプレフィックスの中にないすべてのアドレスを固有アドレスと見なす。
この識別プロセスの利点は簡単なことである。
しかし、この識別方法は単一業者の状況でのみ有効である。IPv4ドメインとIPv6ドメインとの相互接続ノードの相互扶助を伴う広範囲の展開にとって、この方法はもはや適切ではない。
この種の識別は、その値が固有アドレスまたは構成されたアドレスを表し得る識別子またはタグを求めて宛先アドレスを探索するステップを必然的に伴うことになる。例えば、図4に示されるように、この種の識別子ADDR_TYPE_TAGは、それが固有アドレスまたは構成されたアドレスであることを示すための値0または1を有する僅か1ビットの長さしかなくてよい。読取りを容易にするために、識別子ADDR_TYPE_TAGは、例えば構成されたIPv6アドレスの初めに配置されてよく、もしくはIPv6/IPv4_Access_Node_Service_prefixとIPv4アドレスとの間に配置されてよい。
識別子ADDR_TYPE_TAGの利点は、それによって業者間でIPv4/IPv6相互接続設備の相互扶助が可能になり、したがってコストの分担が可能になることである。したがって、業者Oiは、領域Riに対して(IPv4プレフィックスのセットPiを用いて)IPv4-IPv6相互接続を提供することができる。もう一方の業者Ojについては、業者Oiによって構成されたアドレスだけを、(IPv4プレフィックスに基づいて)BGP通知(BGP advertisement)を介して認識できる。
明らかに、IPv6/IPv4以外のプレフィックスが存在し得るが、それらはこの接続サービスを提供するのに用いられず、それらに適用される処理は固有のIPv6パケットに対するものであり、すなわち、それらはIPv6アクセスルータ30へ直接ルーティングされる。
IPv6宛先アドレスが、構成されたアドレスとして分類される場合、本発明の伝送方法は、伝送されるパケットの送信元アドレスを正規化するステップR2を実行する。
本発明のこの第1の実装形態では、これは、ステップR21の中に、送信元アドレスが、構成されたアドレスまたは固有アドレスのどちらであるかということを識別するステップを必然的に伴う。アドレスは、IPv6/IPv4_Acess_Node_Service_prefixに記入されているIPv6送信元アドレスであれば構成されたアドレスと見なされ、このプレフィックスにないすべてのアドレスは固有の送信元アドレスと見なされる。識別子ADDR_TYPE_TAGが用いられる場合、識別子ADDR_TYPE_TAGが「1」に設定されていれば、アドレスは構成されたアドレスと識別される。
送信元アドレスが構成された場合、データパケットは、ステップR3でその宛先へルーティングされる。
IPv6送信元アドレスが固有アドレスとして分類される場合、本発明の方法は、このルーティングステップの前に、その送信元ポート番号がゲートウェイ20に割り当てられた認証範囲ports_pattern/length_of_unvariableにある、構成されたIPv6送信元アドレスを選択するステップR22を実行して、固有の送信元アドレスをこの構成されたアドレスで置換することによりデータパケットを変更する。本発明の方法は、ステップR24で、固有の送信元アドレスおよびこのようにして構成された送信元アドレスに関連するゲートウェイのアドレス変換テーブルにエントリを生成する。
本発明の方法は、ステップR23で、さらに、構成された送信元アドレスに含まれる送信元ポート番号とデータパケットの転送レベルの送信元ポート番号とが一致することを有利に確認することができる。図6を参照すると、これは、任意の128ビットのIPv6アドレスIPv6_prefix_ports_rangeを得て、その右寄りの16ビットの伝送されるデータパケットへ、使用される送信元ポート(端末22から受信したIPv6パケットのTCPまたはUDPのポート)のビットをコピーするステップを必然的に伴うことが理解される。
IPv6/IPv4アクセスノード40が、IPv6データパケットを、宛先のIPv4ドメインへルーティングする前にIPv4データパケットに変換することを可能にするには、このステップが必要であることは明白である。ホームゲートウェイ20に割り当てられたIPv4アドレスが、IPv6ドメイン1の複数のホームゲートウェイによって共有されるアドレスである場合、これは別の利点を有する。前述のように、ホームゲートウェイ20は、それ用に確保されたポート番号の限られた範囲に属する送信元ポート番号しか使用することができない。
ホームゲートウェイ20が、認証されたポート番号の範囲ports_pattern/length_of_unvariableにあるように送信元ポートを制限する場合、次の2点にも留意されたい。
・構成された送信元アドレスはIPv6_prefix_ports_rangeに記入される。
・構成された送信元アドレスの最後の16ビットは、ゲートウェイが端末から受信したIPv6パケットの送信元ポート番号と一致する。
このようにして形成されたIPv6送信元アドレスは、以下でIPv6_address_source_ports_rangeと示される。
制限されたIPv6送信元アドレスIPv6_address_source_ports_rangeを含むIPv6パケットは、ステップR3で、ゲートウェイに働くIPv6アクセスルータ30へルーティングされる。
IPv6アクセスルータ30は、IPv6送信元アドレスIPv6_address_source_ports_rangeがホームゲートウェイ20向けに認証されたことを確認する。換言すれば、IPv6アクセスルータ30は、スプーフィング(spoofing)がないこと、すなわちホームゲートウェイ20がその認証されたプレフィックス範囲IPv6_prefix_ports_rangeでIPv6パケットを送ることを確認する。このために、IPv6アクセスルータ30は、ゲートウェイ20から受信したIPv6パケットのIPv6送信元アドレスIPv6_address_source_ports_rangeがこのホームゲートウェイに割り当てられたプレフィックスIPv6_prefix_ports_rangeに記入されていることを確認する。
この確認は、固有のIPv6トラフィックに既に用いられている方式による標準的なやり方で達成される。
この確認の結果が確かであれば、IPv6アクセスルータ30は、IPv6パケットをその宛先へルーティングする。
IPv6宛先アドレスが、IPv6ドメインへのアクセスをもたらすノードIPv6/IPv4_Access_Node 40を特徴付けるプレフィックスIPv6/IPv4_Access_Node_prefixに記入されているので、データパケットはそのアクセスノードの方へルーティングされる。例えば、この種のノードは、IPv6ドメイン1内で、同ノードがデータパケットの1つまたは複数のIPv4ドメインへのルーティングを最適化するために働く、同ドメインのできるだけ近くに配置されると想定されるが、本発明はアクセスノード40のいかなるそのような位置にも限定されず、アクセスノード40は、ドメイン1内のどこに配置されてもよい。
IPv6パケットを受信すると、アクセスノードIPv6/IPv4_Access_Node 40は、以下のやり方で送信のデータパケットをIPv4ドメインへルーティングする。
・アクセスノード40は、IPv6宛先アドレスからIPv4の宛先アドレスおよび宛先ポートを抽出し、IPv6送信元アドレスからIPv4の送信元アドレスおよび送信元ポートを抽出する。
・次いで、アクセスノード40は、IPv6パケットを、以下の特性を有するIPv4パケットに変換する。
・IPv4パケットのIPv4送信元アドレスは、ホームゲートウェイ20のIPv4アドレスshared@IPv4である。伝送されたIPv4データパケットの宛先(すなわちウェブサーバ)は、このアドレスshared@IPv4を認識することになる。このIPv4アドレスshared@IPv4が、プレフィックスIPv6_prefix_ports_rangeに含まれており、したがってIPv6送信元アドレスIPv6_address_source_ports_rangeに含まれることに留意されたい。図8を参照すると、IPv4アドレスShares_@IPv4は、ビット24から55から抽出することができる。
・IPv4データパケットのIPv4宛先アドレスは、もう一方のグループのIPv4アドレスである。図4を参照すると、IPv4宛先アドレスは、アクセスノード40によって受信されたIPv6データパケットのアドレスIPv6_remoteAddress_out_to_IPv4のビット24から55から抽出され得る。
・変換されたIPv4データパケットの送信元ポート番号は、受信されたIPv6パケットの送信元ポート番号である。
・変換されたIPv4データパケットの宛先ポート番号は、IPv6パケットの宛先ポート番号である。
・IPv6パケットのペイロード部分は、変換されたIPv4パケットのペイロード部分である。
・最後に、アクセスノード40は、変換されたIPv4パケットをその宛先(この実施例ではIPv4ウェブサーバ)へルーティングする。
IPv6パケットのヘッダのフィールドは、例えばネットワークアドレス変換-プロトコル変換(NAT-PT)規格による標準的なやり方で、対応するIPv4のフィールドに変換されることに留意されたい。
明らかに、ホームゲートウェイ20に割り当てられたIPv4アドレスが複数のゲートウェイ間で共有されるパブリックアドレスである場合、受信されたデータパケットの中の構成されたIPv6送信元アドレスに含まれる送信元ポート番号は、このゲートウェイ向けに確保されたポート番号の範囲に属する必要があり、同IPv4アドレスがそうでなかったなら、アクセスノードは、伝送されるIPv6パケットをIPv4データパケットに変換することができるはずであるが、宛先エンティティによって送信されたいかなる応答パケットもホームゲートウェイに到達しないことになる。
アクセスノード40は、パケットのIPv6送信元アドレスの最後の16ビットがIPv6パケットの対応するTCPまたはUDPのフィールドの16ビットの送信元ポートと同一であることをチェックすることにより、ゲートウェイ20に割り当てられた送信元ポート番号の範囲に送信元ポートが属することを有利に確認する。この間接的確認は、その送信元アドレスがアクセスルータのプレフィックスにあるパケットをホームゲートウェイが送信したことをアクセスルータが確認するのに続いて実行されてよい。これら2つのステップの後、ホームゲートウェイ20がその認証されたポートの範囲に含まれる送信元ポートを含むデータパケットを送信しており、別のホームゲートウェイのポートを使用しなかったことは確実である。
本発明の第2の実装形態は、例えばユーザ端末21である宛先端末がIPv6ドメイン1にあるときに、データパケットIPv4-in-ptが、IPv4ドメインからIPv6ドメインに入る状況を扱う。ユーザ端末は、IPv4アドレス@IPv4またはshared@IPv4および認証されたポートの範囲ports_pattern/length_of_unvariableを有するホームゲートウェイ20の背後にある。
着信パケットIPv4-in-ptがホームゲートウェイ20のホームネットワークのユーザ端末21に向かうものである場合、着信パケットIPv4-in-ptは、IPv4宛先アドレスshared@IPv4およびホームゲートウェイ20の認証されたポート番号の範囲ports_pattern/length_of_unvariableに記入された宛先ポートを含む。
図2を参照しながら前述されたように、アドレスshared@IPv4およびポート番号の範囲ports_pattern/length_of_unvariableは、ホームゲートウェイ20のプレフィックスIPv6_prefix_ports_rangeの中に見いだされる。
パケットIPv4-in-ptは、アクセスノード40によって受信される。予備ステップで、IP接続プロバイダは、同プロバイダがインターフェイスを有するIPv4ドメインに、同プロバイダがIPv4パケットをルーティングする責任を負うドメイン1のホームゲートウェイに割り当てられたIPv4アドレスを通知する。同プロバイダは、この通知を、アクセスノード40を介して同プロバイダ自体で達成する、もしくは当業者に既知の技法を用いて自律システム境界ルータ(ASBR)によって達成する。
パケットIPv4-in-ptは、アクセスノード40によって管理された宛先アドレス@IPv4またはshared@IPv4ならびに宛先ポートdest-portを含む。アクセスノード40は、図7を参照しながら説明されるように、アクセスノード40のプレフィックスIPv6/IPv4_Access_Node_prefix、前記IPv4宛先アドレスshared@IPv4、および宛先ポート番号dest-portを連結することにより、IPv6宛先アドレスIPv4inIPv6_dest_addressを構成する。
宛先ポート番号dest-portは、IPv6に構成された宛先アドレスの右寄りの部分に挿入される。したがって、アクセスノード40は、受け取られたIPv4パケットの32ビットのIPv4宛先アドレスおよび16ビットの宛先ポートdest-portの両方を挿入して、構成されたIPv6宛先アドレスIPv4inIPv6_dest_addressを構成する。
アクセスノード40は、その後、構成されたIPv6宛先アドレスIPv4inIPv6_dest_addressおよび受け取ったIPv4データパケットから、IPv6データパケットIPv4inIPv6-ptを生成する。一実装形態では、受け取られたIPv4パケットは、IPv6パケットに変換され、
・同IPv6パケットのIPv6送信元アドレスは、アクセスノード40自体の(アクセスノード40のインターフェイスのうちの1つの)IPv6/IPv4_Access_Node 40に対して有効なIPv6アドレスのうちの1つであり、
・同IPv6パケットのIPv6宛先アドレスは、アドレスIPv4inIPv6_dest_addressである。
別の実装形態では、受け取られたIPv4パケットIPv4-in-ptはIPv6パケットに変換され、構成されたIPv6アドレスは、先ず、受け取られたIPv4パケットからその宛先IPv4アドレス、その宛先ポート、そのIPv4送信元アドレス、およびその送信元ポートを抽出した後、このIPv6パケットに関連付けられる。
構成されたIPv6宛先アドレスを用いて生成されたIPv6データパケットIPv4inIPv6-ptは、IPv6ドメイン1内でルーティングされる。次いで、同IPv6データパケットは、アクセスノード40であるIPv6/IPv4_Access_NodeのIPv6ルーティングコアに入る。
構成によって、同IPv6データパケットの宛先アドレスIPv4inIPv6_dest_addressは、ホームゲートウェイ20のプレフィックスIPv6_prefix_ports_rangeに記入される。パケットIPv4inIPv6-ptは、ホームゲートウェイ20に対応するIPv6ルートに働くアクセスノードIPv6/IPv4_Access_Node 40のインターフェイスへルーティングされる。
IPv4inIPv6_dest_addressがいかなるプレフィックスIPv6_prefix_ports_range(またはいかなる包含するプレフィックス)にも記入されていない場合、パケットは、いかなるプレフィックスIPv6_prefix_ports_rangeにもルーティングすることができず、したがっていかなるホームゲートウェイにもルーティングすることができないので、ルートの途中で破壊されることになる、ということに留意されたい。
宛先アドレスIPv4inIPv6_dest_addressがプレフィックスIPv6_prefix_ports_rangeに記入されている場合、パケットIPv4inIPv6-ptは、ホームネットワーク2の中のユーザ端末21をホスティングするホームゲートウェイ20に働くデュアルスタックアクセスルータ30へ到達する。パケットIPv4inIPv6-ptは、プレフィックスIPv6_address_source_ports_rangeへのルートを知っているデュアルスタックアクセスルータ30によってホームゲートウェイへルーティングされる。
本発明のこの第2の実装形態では、ホームゲートウェイ20は、データパケットIPv4inIPv6-ptを受信する本発明の方法を用いるデバイスを含む。この種の方法が、図8を参照しながら以下で説明される。
パケットIPv4inIPv6-ptがホームゲートウェイ20に到達したとき、同ゲートウェイは、宛先アドレスを識別する前述のステップR'1を実行する。
固有の宛先アドレスが識別された場合、データパケットは、ステップR'3で宛先ユーザ端末へ直接ルーティングされる。
例えば宛先アドレスに含まれる識別子の助けにより、構成された宛先アドレスが識別された場合、データパケットを受信する本発明の方法を正規化するステップは、構成された宛先アドレスを含むエントリを求めてホームゲートウェイの変換テーブルを探索するステップR'21を含む。この探索の結果が確かな場合、この種のエントリは、宛先端末の固有の宛先アドレスIPv6_address_native_Ueを構成された宛先アドレスに関連付ける。ステップR'23で、本発明の方法は、IPv6データパケットの中の構成された宛先アドレスをこの固有アドレスで置換する。データパケットIPv4-in-ptが、宛先端末21がその固有のIPv6送信元アドレスを用いてあらかじめ送信したデータパケットに対する応答の一部分である場合、この置換は特に有利であり、このことのために、ゲートウェイは、本発明の以前の実装形態を参照しながら説明されたように、データパケットを送信する前にこの固有のアドレスをそのNAT表に記憶する。そのとき、ゲートウェイは、その変換テーブルにエントリを生成し、構成されたアドレスで端末21の固有アドレスを置換して、アクセスノード40が送信のIPv6パケットをIPv4パケットに変換するとき、それからIPv4送信元アドレスを抽出することを可能にする。
本方法を正規化するステップは、有利には、データパケットの転送レベルの宛先ポートが、パケットの宛先アドレスに含まれる宛先ポート番号と一致することを確認するステップR'22をさらに含む。2つのポート番号が一致しない場合、パケットは拒否される。変換がアクセスノードによって達成された場合、このことが生じてはならないが、このステップは、アクセスノードから来るストリームの監視のために用いられ得る。
ステップR'3で、ゲートウェイは、そのホームネットワークの中の宛先端末へデータパケットをルーティングする。
図1を参照しながら説明された実施例では、本発明のホームゲートウェイ20は、図10を参照しながら以下で説明される、IPv6ドメインでデータパケットを受信するためのデバイス25を含む。デバイス25は、従来、標準コンピュータまたは専用ルータで見いだされるハードウェア要素、すなわちプロセッサ251、ランダムアクセスメモリ(RAM)252、読取り専用メモリ(ROM)253、およびネットワーク1と通信するための電気通信手段254を含む。
本発明によれば、デバイス25は、ドメイン1とそのホームネットワーク3との間のアドレス変換のためのアドレス変換テーブル(NATテーブル)が記憶されるデータベースを含むメモリ255を含む。
このメモリは、デバイス25がアクセス可能であるならデバイス25の外部に同等に存在し得ることに留意されたい。
読取り専用メモリ255は、本発明のコンピュータプログラムを記憶する本発明の記憶媒体を構成する。このプログラムは、図3、図5、および図8を参照しながら前述された、着信パケットを受信する本発明の方法のステップを実行するための命令を含む。
受信器デバイスは、接続サービスプロバイダのネットワーク1に直接接続されたユーザ端末の中に同等に含まれ得ることにも留意されたい。
要約すると、本発明により、以下の要因を考慮に入れたパケットルーティング機構を使用して、IP接続サービスをIPv6へ移行する第2段階が可能になる。
・主として、IPv6に切り替えることを「納得させる」べき多数の加入者、17,000を上回る多数の自律システム(AS)、および相互接続機構の多様性のために、IPv6へ最終的に移行するには複数年(最短の時間スケールが10年)かかる。その上、アドレスの問題は、業者にとってのみアプリオリな心配事であることを指摘しなければならない。クライアントには、彼らのローカルネットワークの構成を変更する理由がない。個々の企業には、そのFTP、HTTPなどのサーバをIPv6に移行する動機がない。業者は、IPv6への移行に長い道のりが伴うことを予期しなければならない。
・サービス業者は、前述のように、IPv4アドレスが使い尽くされる問題に悩む。
・所与のドメインを単純にIPv6へ移行することは、全体的な接続の問題の解決(インターネット上に存在するいかなるリモートマシンとも交信すること)にならない。したがって、IPv4界との相互接続が提供されなければならない。
・ステートレスではない(not stateless)NAT-PTに基づいた解決策は推奨することができない。これは、クライアントによって構成された転送ポートにリンクされた付加価値サービスがうまく機能しない恐れがあり、IPv4クラウドとIPv6クラウドとを相互接続する「ブラックボックス」の挙動に依存するはずであるので、提供されたサービスを劣化させることになる。
IPパケットをルーティングするための本発明の機構により、IPv6を作動させ、ネットワークに配置されたステートレスの(stateless)相互接続機能に基づくIPv6トラフィックを奨励することを可能にする解決策を提供するやり方で、IPv6プロトコルの使用を促進することが可能になる。本発明の解決策は、ホームゲートウェイのIPv6接続だけを用い、IPv6のホームゲートウェイおよびユーザ端末を使用することを意味する。このため、これらの機器は、IPv6データパケットだけを処理する(送受信する)立場にある。
本発明の解決策により、以下のことが可能になる。
・アクセスネットワークが純然たるIPv6であり得て、したがってアクセス業者は、IPv4ルーティングのアクセスを管理する必要がない。
・ホームゲートウェイにはIPv4の概念がなく、IPv6だけを管理すればよい。
・ホームゲートウェイのホームネットワークの端末はIPv6だけを用いる。
複数のホームゲートウェイ(またはホームインターネットアクセス以外の状況では他の機器)に対して、同一のIPv4アドレスを割り当てることができる。ホームゲートウェイがIPv4ルーティングを管理しないので、これはホームゲートウェイレベルでのダミーの割当てを意味する。基本原理は以下の通りである。
・送信コールのためのそれぞれのゲートウェイでの認証された送信元ポートの範囲
・特定のIPv6プレフィックスIPv6_prefix_ports_range
IPv6ドメインに入るIPv4パケットは、ホームゲートウェイへルーティングされるようにIPv6/IPv4_Access_Nodeによってカプセル化されるのではなく、IPv6パケットに変換される。
・送信コールについては、IPv4のコールされたグループのDNS解決で、IPv6アドレスは、コールされたグループのIPv4アドレスに基づいて構成されたイニシエータユーザ端末へ戻される。次いで、イニシエータユーザ端末は、データパケットを送信するのに、このIPv6宛先アドレスを用いる。イニシエータユーザ端末は、パケットを送信するのに、その固有のIPv6送信元アドレスまたは構成された送信元アドレスを用いることができる。
・イニシエータユーザ端末がその固有の送信元アドレスを用いる場合、ホームゲートウェイは、固有のIPv6送信元アドレスを、ゲートウェイと送信元ポート(認証されたソース範囲に記入されている)との間で共有されるそれ自体のIPv4アドレス(shared@IPv4)を含む構成されたIPv6送信元アドレスに変換する。
・IPv6ドメインとIPv4ドメインとを相互接続する機器は、送信元ポートのビットを含む送信元アドレスの部分とIPv6パケットのポートフィールドの中の送信元ポートとを比較することにより、ホームゲートウェイが、その認証された送信元ポートの範囲を用いていることを確認する。同機器は、IPv6パケットを、コールされたグループへ伝送するために、
・IPv4送信元アドレスについては、shared@IPv4を含むIPv6送信元アドレスのビットを用い、
・IPv4宛先アドレスについては、コールされたグループのIPv4アドレスを含むIPv6アドレスのビットを用いて、IPv4パケットに変換する。
1 IPv6ドメイン
2 ホームネットワーク
3 IPv4ドメイン
20 ホームゲートウェイ
21 端末
22 端末
25 デバイス
251 プロセッサ
252 ランダムアクセスメモリ
253 読取り専用メモリ
254 電気通信手段
255 読取り専用メモリ
30 アクセスルータ
31 端末
40 IPv6/IPv4アクセスノード
R1 ステップ
R2 ステップ
R21 ステップ
R22 ステップ
R23 ステップ
R24 ステップ
R3 ステップ
R'1 ステップ
R'21 ステップ
R'22 ステップ
R'23 ステップ
R'3 ステップ

Claims (10)

  1. IPv4ドメインに接続されたIPv6ドメインで、IPv6宛先アドレスおよびIPv6送信元アドレスを含むIPv6データパケットを受信するための受信方法であって、ユーザ端末を前記IPv6ドメインに接続するように適合されたホームゲートウェイで実行され、
    業者プレフィックス、IPv4宛先アドレスおよび宛先ポート番号を連結することによって構成されたIPv6宛先アドレスを識別するステップと、
    前記IPv6データパケットが前記ユーザ端末から来て前記IPv4ドメインへ行くとき、前記IPv6データパケットのIPv6宛先アドレスが構成されたIPv6宛先アドレスであり、かつ、前記IPv6データパケットのIPv6送信元アドレスがIPv6端末であるユーザ端末に固有である固有のIPv6送信元アドレスである場合、前記IPv6データパケットのIPv6送信元アドレスを正規化するステップ、又は、
    前記IPv6データパケットが前記IPv4ドメインから来て前記ユーザ端末へ行くとき、前記IPv6データパケットのIPv6宛先アドレスが構成されたIPv6宛先アドレスであり、かつ、前記IPv6データパケットのIPv6宛先アドレスが前記ホームゲートウェイのアドレス変換テーブルにエントリを有する場合、前記IPv6データパケットのIPv6宛先アドレスを正規化するステップと
    を含み、
    前記IPv6データパケットの前記IPv6送信元アドレス又は前記IPv6宛先アドレスを正規化するステップが、
    前記正規化されたアドレスを用いて前記IPv6データパケットを変更するステップと、
    前記変更されたIPv6データパケットを、その宛先へルーティングするステップと
    を含むことを特徴とする受信方法。
  2. 前記IPv6送信元アドレスを正規化するステップが、
    前記固有のIPv6送信元アドレスを識別するステップと、
    前記アドレス変換テーブルにエントリを生成するステップであって、前記エントリが、前記固有のIPv6送信元アドレスを、業者プレフィックス、前記ホームゲートウェイに割り当てられたIPv4アドレス、および前記ホームゲートウェイ向けに認証されたポート番号の範囲に属する送信元ポート番号を連結することにより構成されたIPv6送信元アドレスに関連付けるステップと、
    前記IPv6データパケットの前記固有のIPv6送信元アドレスを前記構成されたIPv6送信元アドレスで置換するステップと
    をさらに含むことを特徴とする請求項1に記載の受信方法。
  3. 前記IPv6宛先アドレスを識別することが、前記IPv6宛先アドレスに含まれ、かつ、前記構成されたIPv6宛先アドレス、又は、前記固有のIPv6宛先アドレスのどちらであるかということを示す識別子を用いることを特徴とする請求項1に記載の受信方法。
  4. 前記IPv6データパケットの前記送信元ポート番号と前記構成されたIPv6送信元アドレスの前記送信元ポート番号との一致を確認するステップをさらに含むことを特徴とする請求項2に記載の受信方法。
  5. 前記IPv6宛先アドレスを正規化するステップが、
    前記構成されたIPv6宛先アドレスに、IPv6端末であるユーザ端末に固有である固有のIPv6宛先アドレスを関連付けるエントリを求めて前記ホームゲートウェイのアドレス変換テーブルを探索するステップと、
    エントリが見つかった場合、前記IPv6データパケットの前記構成されたIPv6宛先アドレスをそのエントリからの前記固有のIPv6宛先アドレスで置換するステップと
    を含むことを特徴とする請求項1に記載の受信方法。
  6. 前記IPv6データパケットの前記宛先ポート番号と前記構成されたIPv6宛先アドレスに含まれる前記宛先ポート番号とが一致することを確認するステップをさらに含むことを特徴とする請求項5に記載の受信方法。
  7. IPv4ドメインに接続されたIPv6ドメインでIPv6宛先アドレスおよびIPv6送信元アドレスを含むIPv6データパケットを受信するためのデバイスであって、ユーザ端末を前記IPv6ドメインに接続するように適合されたホームゲートウェイで使用されるように意図されており、
    業者プレフィックス、IPv4宛先アドレスおよび宛先ポート番号を連結することによって構成されたIPv6宛先アドレスを識別するための手段と、
    前記IPv6データパケットが前記ユーザ端末から来て前記IPv4ドメインへ行くとき、前記IPv6データパケットのIPv6宛先アドレスが構成されたIPv6宛先アドレスであり、かつ、前記IPv6データパケットのIPv6送信元アドレスがIPv6端末であるユーザ端末に固有である固有のIPv6送信元アドレスである場合、前記IPv6データパケットのIPv6送信元アドレスを正規化する手段、又は、
    前記IPv6データパケットが前記IPv4ドメインから来て前記ユーザ端末へ行くとき、前記IPv6データパケットのIPv6宛先アドレスが構成されたIPv6宛先アドレスであり、かつ、前記IPv6データパケットのIPv6宛先アドレスが前記ホームゲートウェイのアドレス変換テーブルにエントリを有する場合、前記IPv6データパケットのIPv6宛先アドレスを正規化する手段と
    を含み、
    前記IPv6データパケットの前記IPv6送信元アドレス又は前記IPv6宛先アドレスを正規化する手段が、
    前記正規化されたアドレスを用いて前記IPv6データパケットを変更する手段と、
    前記変更されたIPv6データパケットを、その宛先へルーティングする手段と
    を含むことを特徴とするデバイス。
  8. ホームネットワークのユーザ端末を、IPv4ドメインに接続されたIPv6ドメインに接続するように適合されたホームゲートウェイであって、
    IPv4アドレス、前記ホームゲートウェイ向けに認証された範囲のポート番号、および前記ホームゲートウェイ向けに認証された範囲のIPv6アドレスを得るための手段であって、前記IPv6アドレスの範囲が、業者プレフィックス、前記IPv4アドレス、および認証されたIPv4ポート番号の範囲を連結することにより構成される手段と、
    前記IPv4ドメインに接続された前記IPv6ドメインでIPv6データパケットを受信するための請求項7に記載のデバイスと
    を含むことを特徴とするホームゲートウェイ。
  9. ホームゲートウェイであって、そのホームネットワークのユーザ端末を含む通信セッションに関する少なくとも1つのIPv6送信元アドレスに関連するエントリを含むアドレス変換テーブルを含み、前記ホームゲートウェイが、構成されたIPv6送信元アドレスおよび固有のIPv6送信元アドレスを前記エントリに記憶するように適合されることを特徴とする請求項8に記載のホームゲートウェイ。
  10. コンピュータにより実行可能な命令を備えたコンピュータプログラムであって、IPv6ドメインでデータパケットを受信する請求項1に記載の方法を実行するための命令を含むことを特徴とするコンピュータプログラム。
JP2011515565A 2008-06-30 2009-06-26 ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ Expired - Fee Related JP5607617B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0854405 2008-06-30
FR0854405 2008-06-30
PCT/FR2009/051228 WO2010004180A1 (fr) 2008-06-30 2009-06-26 Procede de reception d'un paquet de donnees dans un domaine ipv6, dispositif et passerelle residentielle associes

Publications (3)

Publication Number Publication Date
JP2011526756A JP2011526756A (ja) 2011-10-13
JP2011526756A5 JP2011526756A5 (ja) 2013-05-09
JP5607617B2 true JP5607617B2 (ja) 2014-10-15

Family

ID=40527988

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011515565A Expired - Fee Related JP5607617B2 (ja) 2008-06-30 2009-06-26 ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ

Country Status (7)

Country Link
US (1) US8451845B2 (ja)
EP (1) EP2297928B1 (ja)
JP (1) JP5607617B2 (ja)
CN (1) CN102132544B (ja)
AT (1) ATE557514T1 (ja)
ES (1) ES2387868T3 (ja)
WO (1) WO2010004180A1 (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9054943B2 (en) * 2009-12-23 2015-06-09 Citrix Systems, Inc. Systems and methods for mixed mode handling of IPv6 and IPv4 traffic by a virtual server
FR2958104A1 (fr) 2010-03-26 2011-09-30 France Telecom Serveur dns, passerelles et procedes pour la gestion d'un identifiant d'une plage de ports dans la transmission de donnees.
CN102859972A (zh) * 2010-04-26 2013-01-02 诺基亚公司 用于合成地址检测的方法和装置
US8406232B2 (en) * 2010-06-17 2013-03-26 Microsoft Corporation 4to6 network stack for IPv4 applications
EP2622813A1 (en) * 2010-09-30 2013-08-07 Telefonaktiebolaget L M Ericsson (PUBL) Load balancing among network servers
CN102447617A (zh) * 2010-10-09 2012-05-09 华为技术有限公司 IPv4网络中传输IPv6报文的方法、终端及网关
US8719449B2 (en) 2010-11-29 2014-05-06 Telefonaktiebolaget L M Ericsson (Publ) Identification of a private device in a public network
TWI439088B (zh) * 2011-06-01 2014-05-21 Accton Technology Corp 網域閘道控制系統及其方法
CN102263831B (zh) * 2011-09-06 2013-05-08 常熟理工学院 基于IPv6的车载网络通信系统的实现方法
CN102333118B (zh) * 2011-10-08 2013-06-12 常熟理工学院 一种车载网络IPv6地址自动配置的实现方法
US9049273B2 (en) * 2012-02-14 2015-06-02 Cable Television Laboratories, Inc. Selective network transmission
CN103457856B (zh) * 2012-06-05 2018-01-23 华为技术有限公司 报文处理方法、系统及路由设备
US9270692B2 (en) * 2012-11-06 2016-02-23 Mediatek Inc. Method and apparatus for setting secure connection in wireless communications system
CN103905312B (zh) * 2012-12-26 2017-06-16 中国电信股份有限公司 IPv6/IPv4协议翻译网关及数据报文处理方法
KR101466729B1 (ko) * 2013-05-28 2014-12-01 삼성에스디에스 주식회사 IPv6 환경에서의 단말 정보 통합 관리 장치 및 방법
WO2015131327A1 (zh) * 2014-03-04 2015-09-11 华为终端有限公司 IPv6地址分配方法及装置
US9806750B2 (en) * 2014-05-02 2017-10-31 Intel Corporation Bluetooth assisted remote discovery and wakeup
EP3143754A1 (en) * 2014-05-13 2017-03-22 Telefonaktiebolaget LM Ericsson (publ) System and method for providing ip address translation services
CN106302845B (zh) * 2015-05-29 2020-07-17 西安中兴新软件有限责任公司 数据通道产品的域名系统地址配置方法及装置
US10749840B2 (en) * 2016-07-08 2020-08-18 Waldemar Augustyn Network communication method and apparatus
US10506083B2 (en) 2017-06-27 2019-12-10 Cisco Technology, Inc. Segment routing gateway storing segment routing encapsulating header used in encapsulating and forwarding of returned native packet
US11876790B2 (en) * 2020-01-21 2024-01-16 The Boeing Company Authenticating computing devices based on a dynamic port punching sequence
WO2022046037A1 (en) * 2020-08-25 2022-03-03 Google Llc Expressing multicast groups using weave traits

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3876741B2 (ja) * 2002-03-27 2007-02-07 株式会社日立製作所 プロトコル変換方法及び装置
US7356045B2 (en) * 2002-10-22 2008-04-08 Cisco Technology, Inc. Shared port address translation on a router behaving as NAT & NAT-PT gateway
EP1420559A1 (en) 2002-11-13 2004-05-19 Thomson Licensing S.A. Method and device for supporting a 6to4 tunneling protocol across a network address translation mechanism
US7031328B2 (en) * 2003-03-10 2006-04-18 Cisco Technology, Inc. Arrangement for traversing an IPv4 network by IPv6 mobile routers
US7245622B2 (en) * 2003-03-27 2007-07-17 Microsoft Corporation Allowing IPv4 clients to communicate over an IPv6 network when behind a network address translator with reduced server workload
JP3900157B2 (ja) * 2004-01-05 2007-04-04 株式会社日立製作所 トランスレータ
CN100525295C (zh) * 2004-04-21 2009-08-05 华为技术有限公司 一种IPv4网络与IPv6网络通信的实现方法
US7443880B2 (en) * 2004-06-25 2008-10-28 Cisco Technology, Inc. Arrangement for reaching IPv4 public network nodes by a node in a IPv4 private network via an IPv6 access network
FR2898003A1 (fr) * 2006-02-28 2007-08-31 France Telecom Procede et systeme de caracterisation de noeuds de communication heterogenes
FR2903263A1 (fr) * 2006-06-30 2008-01-04 France Telecom Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes

Also Published As

Publication number Publication date
ES2387868T3 (es) 2012-10-03
US20110110375A1 (en) 2011-05-12
WO2010004180A1 (fr) 2010-01-14
EP2297928B1 (fr) 2012-05-09
CN102132544A (zh) 2011-07-20
CN102132544B (zh) 2014-04-09
EP2297928A1 (fr) 2011-03-23
ATE557514T1 (de) 2012-05-15
JP2011526756A (ja) 2011-10-13
US8451845B2 (en) 2013-05-28

Similar Documents

Publication Publication Date Title
JP5607617B2 (ja) ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ
JP5475763B2 (ja) ＩＰｖ４ドメインからのデータパケットをＩＰｖ６ドメインで受信する方法、ならびに関連するデバイスおよびアクセス機器
US9019965B2 (en) Methods and devices for routing data packets between IPv4 and IPv6 networks
US7533164B2 (en) Method and system for enabling connections into networks with local address realms
US7411967B2 (en) Private network gateways interconnecting private networks via an access network
US7443880B2 (en) Arrangement for reaching IPv4 public network nodes by a node in a IPv4 private network via an IPv6 access network
EP2253124B1 (en) Method and apparatus for communication of data packets between local networks
US7639686B2 (en) Access network clusterhead for providing local mobility management of a roaming IPv4 node
JP3793083B2 (ja) トンネリングおよび補償を使用するネットワーク・アドレス翻訳によりセキュリティを与えるための方法および装置
Atkinson et al. ILNP: mobility, multi-homing, localised addressing and security through naming
US20220311734A1 (en) Method and Device for Obtaining an IP Address
US8693369B2 (en) Method of routing a data packet in a network and an associated device
US9602333B2 (en) DNS server, gateways and methods for managing an identifier of a port range in the transmission of data
US7764686B1 (en) Migration to IPv6 using combination of globally significant and locally significant IPv4 addresses
US7356031B1 (en) Inter-v4 realm routing
Atkinson et al. A proposal for unifying mobility with multi-homing, NAT, & security
KR100562390B1 (ko) 호스트 라우팅과 IP Aliasing 기법을 이용한 네트워크 데이터 플로우 식별 방법 및 시스템
Huang et al. Enhancing Teredo IPv6 tunneling to traverse the symmetric NAT
Hughes IPv6 Core Protocols
Atkinson et al. A Proposal for Enhancing Internet Naming
Ren et al. IPv4+ 6
Bagnulo Braun et al. The NAT64/DNS64 Tool Suite for IPv6 Transition
Hunek NAT64/DNS64 in the Networks with DNSSEC
EP1554908A2 (en) Communication system and method of routing information
WO2010040420A1 (en) Security parameter index multiplexed network address translation

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120501

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130319

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130809

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130827

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131127

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140407

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140702

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: 20140804

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140828

R150 Certificate of patent or registration of utility model

Ref document number: 5607617

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees