JP4339259B2 - ネットワークアドレス変換機構を通じた６−４トンネリングプロトコルをサポートする方法及び装置 - Google Patents

Description

本発明は、ネットワークアドレス変換機構を通じた6-4トンネリングプロトコル(6to4 tunneling protocol)をサポートする方法及び装置に関するものである。

IETFドキュメントのRFC1631、RFC2663及びRFC3022に記載されているように、ネットワークアドレス変換(‘NAT:Network Address Translation’)は、第１のアドレスドメインのIPv4アドレス(‘プライベートIPv4アドレス’)を第２のアドレスドメインのIPv4アドレス(‘パブリックIPv4アドレス’)に変換する。変換は、NATを通過する出力パケットのソースアドレスと、入力パケットの宛先アドレスとで実行される。一般的に、NATは、例えば異なる互換性のないIPアドレス機構を使用した２つのIPv4ネットワークを接続するルータに統合された機能である。

NATの２つの基本形式が存在する。１対１対応でアドレスを置換する処理(すなわち、それぞれの第１のドメインアドレスが固有の第２のドメインアドレスに関連付けられる)、又は単一の第２のドメインアドレスに複数の第１のドメインアドレスを関連付ける処理が存在する。この文献において、第１のNAT形式は、‘N:N NAT’と呼ばれ、第２の形式は‘X:Y NAT’と呼ばれる。

X:Y NATの使用に関連する問題は、変換中にX個のプライベートアドレスがY個のパブリックアドレス(ただしY<X)に変換され、その結果として情報の損失を生じるため、NATの変換テーブルが単に情報をマッピングするIPアドレスから構成される場合に、ソースホストを一意に特定することが不可能であるという点にある。従って、NATは、反対の変換を行い、双方向の通信をサポートすることができるようにするために、更なるセッション情報を使用する必要がある。しかし、セッションを明確に特定するためにはパケットのIPヘッダにフィールドが存在しないため、IPで動作する各プロトコルに“多重化／逆多重化識別子”
(この文献では更に多重化識別子と省略する)が定義される必要がある。TCPやUDPのようなプロトコルは、参照テーブルを作って逆変換を可能にするために、NATにより使用される‘ポート’の概念を有する。他のIP伝送プロトコル又は直接的にIPで動作するアプリケーションにとって、プロトコル毎に専用のセッション情報が特定されなければならない。NATをトランスペアレントに横断する“ポートレス・プロトコル”を作るために代替案が提案されている。例えば、C.Huitemaによる“Teredo:Tunneling IPv6 over UDP through NATs” (2002年9月17日のInternet Draft)というドキュメントは、NAT装置の背後にあるIPv6ノードにサービスを提供する代替方法について記載する。しかし、UDP上でIPv6を伝送することは更なるオーバーヘッドを導き、その結果、性能に影響を及ぼす。更に、ネットワークに更なる特有のサーバが導入されなければならず、IPv6ホストがアップグレードされなければならない。

他の代替案は、2001年10月のRFC3102“Realm Specific IP:Framework”に記載されている。しかし、前述のパラグラフに記載したプロトコルに関しては、更なるサーバが必要であり、ホストがアップグレードされる必要が生じる。

www.6to4.jp/settings/nat.htmlから利用可能なドキュメント‘Setup of 6to4(NAT version)’は、IPv4パケットにカプセル化されたIPv6パケットの6-4ヘッダのIPv4アドレス部分が、アウトバウンドパケットではパブリックIPv4アドレスで、インバウンドパケットではプライベートIPv4アドレスでアップグレードされるNAT機能について記載している。

本発明は、NATを通じてRFC3015に定められた6-4トンネリングプロトコル(ポートレス・プロトコルでもある)をサポートする方法に関する。6-4プロトコルは、明示的なトンネルの設定を行わずに、IPv6サイトがIPv4ネットワークで他のIPv6サイト又はネイティブのIPv6ネットワークと通信する機構を定める。

その方法は、
−IPv4パケットにカプセル化されたアウトバウンドIPv6パケットを受信するステップと、
−アウトバウンドパケットのIPv4ヘッダのプライベートIPv4ソースアドレスを、パブリックIPv4ソースアドレスに変換するステップと、
−変換したパケットをIPv4ネットワークで送信するステップと
を有し、
−インバウンドパケットの反対のアドレス変換のため、プライベートIPv4アドレスと6-4ソースアドレスのインタフェースID値との関連を格納するステップを更に有することを特徴とする。

インタフェース識別子の値は、応答パケットを返信する際に、宛先ホストにより保持される。それは、宛先アドレスを以前に格納したアドレスに変換することで、装置が入力パケットを正しいホストに送信することを可能にする多重化識別子として使用される。

本発明の特定の実施例によると、その方法は、
−IPv4ネットワークでインバウンドパケットを受信するステップと、
−インバウンドパケットがIPv6パケットをカプセル化しているか否かを決定するステップと、
−肯定的な場合には、カプセル化されたIPv6パケットの宛先アドレスのインタフェースIDを取り出し、対応の格納したプライベートIPv4アドレスを取り出すためにインタフェースIDを使用し、それに従ってIPv4ヘッダの宛先アドレスを更新するステップと、
−第１のネットワークで変更した6-4パケットを転送するステップと
を更に有する。

本発明の特定の実施例によると、その方法は、
−アウトバウンドパケットのIPv6ヘッダの6-4ソースアドレスのIPv4アドレス部分を、パブリックIPv4アドレスに変更するステップを更に有する。

本発明の特定の実施例によると、その方法は、
−インバウンドパケットの6-4宛先アドレスのIPv4アドレス部分を、対応するプライベートIPv4アドレスに変更するステップを更に有する。

図１は、各ルータを通じてIPv4ネットワークにより接続されている２つのIPv6ネットワークを表している。左側のネットワークルータは、N:N NAT形式であれ、X:Y NAT形式であれ、NATに接続又は統合されている。

例えば、図１において、ホスト3がホスト1により送信されたパケットに応答しようとする場合、ホスト3は、ルータr2から受信したIPv6パケットに含まれるIPv6ソースアドレスに、応答パケットの宛先アドレスの基礎を置く。このIPv6ソースアドレスは、ホスト1のプライベートIPv4アドレスを含む。

ルータr2は、このパケットのIPv6ヘッダから応答パケットのIPv4ヘッダを構築する。より正確には、IPv4宛先アドレスはホスト3のIPv6宛先アドレスから抽出される。すなわち、IPv4宛先アドレスはホスト1のプライベートIPv4アドレスと等しい。プライベートIPv4アドレスはIPv4ネットワークで適切に認識されないため、応答パケットは配信されない(又は誤ったルートになる)。

これは、前記の更なる特徴により解決され、その更なる特徴によると、アウトバウンド(6-4)パケットの内部IPv6ヘッダは、NAT処理により変更されて、外部IPv4ヘッダと一貫するように適合される。

本発明の特定の実施例によると、その方法は、チェックサム(checksum)のような少なくともIPv4ヘッダのフィールドを変更するステップを更に有し、その値は6-4ソースアドレスに依存する。

本発明の特定の実施例によると、インタフェースIDと第１のネットワークの6-4パケットのソースアドレスとの関連を格納するステップと、インタフェースIDの機能としてインバウンドパケットの宛先アドレスを変更するステップと、6-4アドレスのIPv4部分を変更するステップはそれぞれ、ネットワークアドレス変換機構を支援するアプリケーションレベルゲートウェイ(Application Level Gateway)により実行される。

本発明の他の対象は、NATを通じた6-4トンネリングプロトコルをサポートする装置であり、
−IPv6パケットをカプセル化するアウトバウンドIPv4パケットのプライベートソースアドレスを、パブリックソースアドレスに変更するネットワークアドレス変換機構を有し、
アウトバウンドパケットについて、IPv6ネットワークのホストの6-4ソースアドレスに含まれるプライベートIPv4アドレスを格納し、6-4宛先アドレスと同じインタフェースIDを有する格納したプライベートIPv4アドレスで、インバウンドパケットの6-4宛先アドレスを更新するアプリケーションを更に有することを特徴とする。

本発明の実施例によると、そのアプリケーションは、アウトバウンドパケットの更なる処理を実行するように更に適合され、更なる処理は、アウトバウンドパケットの6-4ソースアドレスのプライベートIPv4アドレス部分を、装置のパブリックIPv4アドレスに置換することを有する。

本発明の他の特徴および利点は、図面を用いて説明する非限定的な実施例の説明で明らかになる。

図１は、IPv4ネットワークを通じて接続されているIPv6ネットワークの図である。ネットワークAは、6-4ルータr1を通じてIPv4ネットワークに接続されている２つのホスト(それぞれ1及び2)を有する。同様に、ネットワークBは、２つのホスト3及び4と、6-4ルータr2とを有する。IPv6ネットワークとIPv4ネットワークとの間にIPv6/IPv4境界ルータを配置することにより、隔離したIPv6クラスタが、いわゆる6-4トンネルを介して連結され得る。

図２は、IPv6アドレスフォーマットを示している。各IPv6ネットワークは、3ビットのフォーマットプレフィックス(‘FP:format prefix’)と、IPv6最上位集約(‘TLA:Top Level Aggregator’)と呼ばれる13ビットの所定の識別子と、グローバルに一意のIPv4アドレス(‘V4ADDR’)と、16ビットのサイトレベル集約識別子(‘SLA ID:Site Level Aggregator Identifier’)と、最後に64ビットのリンクレベルホスト識別子(インタフェースID)とを有する一意の‘6-4フォーマットプレフィックス’を割り当てられている。最後の２つの識別子はホストのローカルで一意の識別子を形成する。インタフェースIDは、例えばホストのMACアドレスである。それは、例えばプライベートのローカルで一意のホストのIPv4アドレスと同じでもよい。

6-4ルータによるトンネルの確立は、パケットの宛先アドレスの特定のフィールドの所定の値を使用することにより調整される。2001年2月のRFC3056に記載されているように、FPとTLAのフィールドの連結は‘2002’の値を有さなければならない。

ネットワークA及びBの6-4アドレスプレフィックスは、それぞれ‘2002:V4ADDR-r1/48’と、‘2002:V4ADDR-r2/48’であり、V4ADDR-r1とV4ADDR-r2はトンネルの端点(それぞれルータr1及びルータr2)に割り当てられたグローバルに一意のIPv4アドレスである。

IPv6ネットワークのホストは、IPv6ネットワークに割り当てられた6-4プレフィックスと、ホストのローカルに一意の識別子(SLA/インタフェースID)とで構成されたIPv6アドレスで、ルータの広告を介して構成又は自動構成される。

6-4トンネルはまた、6-4ルータを通過せずに、隔離した6-4ホスト間で直接定められてもよい点に留意すべきである。その場合、トンネルの端点のIPv4アドレスは、ホストのIPv4アドレスである。

ネットワークの6-4プレフィックスと異なる6-4プレフィックスを含む宛先アドレスを有するIPv6ネットワークの全てのパケットは、6-4境界ルータに転送される。図３に示すように、ルータは、IPv6パケットをIPv4パケットにカプセル化する役割をする。IPv6をカプセル化するそのようなパケットのIPv4ヘッダは、‘外部’ヘッダと呼ばれ、カプセル化されたIPv6パケットのIPv6ヘッダは‘内部’ヘッダと呼ばれる。IPv4ヘッダは、トンネルの端点のIPv4のソース及び宛先アドレス(すなわち、ルータの‘V4ADDR’)を含む。IPv6ヘッダは、ホストのIPv6のソース及び宛先アドレスを含む。

宛先のルータにより受信されたカプセル化6-4パケットが抽出され、ネイティブのIPv6パケットが適切なホストに転送される。

図４は、このカプセル化機構のIPv4及びIPv6ヘッダを示している。6-4プロトコルでは、外部IPv4ヘッダの‘プロトコル’フィールドは‘41’の値を有する。IPv6ヘッダのフィールドの内容に関する更なる詳細は、RFC2460にある。‘変更’としてラベル付けされた項目が、本発明に従って行われたヘッダへの修正である点に留意すべきである。

従来のN:N NATとX:Y NATは、パケットの外部ヘッダでのみ動作するが(内部ヘッダのIPv4アドレスは不変のままである)、本発明によるNATはまた、内部ヘッダのレベルで変換を反映する。

図１に示すように、本発明によると、6-4プロトコルに必要な特定の処理のため、NATは“アプリケーションレベルゲートウェイ(Application Level Gateway)”により支援を受ける。RFC2663に記載のように、ALGは、１つのアドレス領域のホストのアプリケーションが、異なる領域のホストで動作する対応するものと接続することを可能にするアプリケーション特有の変換エージェントである。この例では、ALGはNATと共にルータに統合されている。

6-4ALGは、6-4プロトコルで動作するアプリケーションにより送信されたパケットで動作する。それはパケットの6-4プレフィックスを検出し、検出したパケットについて以下の処理を実行する。

(a)内部IPv6ヘッダにおいて、出力パケットで6-4プレフィックスのプライベートIPv4アドレス(‘V4ADDR’)をパブリックIPv4アドレスに置換し、入力パケットでその逆を行う。

(b)6-4プレフィックスに応じてフィールドを更新する。特にチェックサムが関係する。例えば、これはトランスポートヘッダのチェックサム(例えばTCP又はUDPヘッダ)に当てはまる。これはまた、FTPの場合のように6-4プレフィックスを組み込んだ如何なる上位レイヤフィールドにも当てはまる(例えば全体プレフィックスがFTPパケットのペイロード(EPTRフィールド)で置換される必要がある)。

次に、内部ヘッダと外部ヘッダとの間の一貫性が復元される。これは、不正確なパケット配信(特に、NAT機能を通過した6-4パケットに対する応答パケット)の問題を解決する。ホストの応答で、例えば図１のホスト3がホスト1に応答する場合、ルータ2は変更した6-4プレフィックスのパブリックIPv4アドレスを使用し、ホスト3の応答パケットのIPv4の宛先アドレスを生成する。応答パケットは正確にルータr1に送信される。

同じ理由で、不正確なDNSレコードや、誤って生成された転送データベース及びルーティングテーブルが避けられる。

(c)この実施例によると、6-4ALGは、インバウンド及びアウトバウンドのトラヒックパケットを一意に関連付けるタスクを更に有する。6-4ALGは以下の処理を実行する。NAT ALGは、リモートホストにより返信されるパケットについて、正確なプライベート6-4ホストアドレスに対するインバウンドパケットの6-4宛先アドレスのマッピングのリストを維持する。このマッピングが実行可能になるように、それはアウトバウンドパケットから‘多重化識別子’を取得する。

この実施例によると、多重化識別子は、アウトバウンドパケットのIPv6ヘッダのフィールドから取得される。実際に、この実施例によると、既にIPv6ヘッダに存在する識別子は、多重化識別子として選択される。この識別子は、リモートホストにより保持され、発信元ネットワークで一意であるという特徴に基づいて選択される。

この実施例によると、6-4ソースアドレスの‘インタフェースID’フィールドは、6-4ALGによるアウトバウンドパケットの始点の一意の識別子として使用される。このフィールドは、前述の一意性と保持基準とに対応する。‘保持’とは、識別子がヘッダ内の同じ位置に留まらなければならないことを意味するのではなく、6-4ALGがヘッダの所定の位置からそれを回復できることを単に意味する。この場合、当然のことながら、リモートホストは応答のソースアドレスと宛先アドレスとを交換するため、ヘッダ内の識別子の位置が変化する。

従って、6-4ALGは以下の内容を有するテーブルを維持する。

このテーブルはまた、6-4アドレスが既に識別子に含まれているため、6-4アドレスのリストの形式で格納されてもよい。

テーブルは、サイト1から開始されたアウトバウンドセッション毎に“6-4エントリー”を備えている。インバウンドパケット毎に、6-4ALGは、インバウンドパケットの宛先アドレスのインタフェースID識別子に基づいて、ローカルネットワークで有効な対応するIPv4アドレスを抽出し、ローカルネットワークでパケットを転送する前に、インバウンドパケットの宛先アドレスをこの抽出した値に置換する。

“6-4エントリー”は、NAT機能により管理されているセッションのタイムアウトが終了するまで、有効なままである。

この実施例はIPアドレスに関係するが、本発明の原理は例えばICMPやESPやGREのような他のポートレス・プロトコルにも適用され得る。多重化識別子の選択の基準は、この実施例のものと同じままである。ESPの場合、‘SPI’フィールドが使用可能であり、GREの場合、CallIDフィールドが適する。

本発明の実施例によるネットワークアドレス変換を使用したIPv4ネットワークを通じて接続されている２つのIPv6ネットワークの図 ‘6-4’アドレスフォーマットの従来技術の図 IPv6パケットがIPv4パケットにカプセル化される方法を示した従来技術の図 本発明に従ってIPv4ヘッダとカプセル化されたIPv6ヘッダに対して行われた変更を示す図

Claims (8)

1. ネットワークアドレス変換機構を通じた6-4トンネリングプロトコルをサポートする方法であって、
   −IPv4パケットにカプセル化されたアウトバウンドIPv6パケットを受信するステップと、
   −前記アウトバウンドパケットのIPv4ヘッダのプライベートIPv4ソースアドレスを、パブリックIPv4ソースアドレスに変換するステップと、
   −前記変換したパケットをIPv4ネットワークで送信するステップと
   を有し、
   −インバウンドパケットの反対のアドレス変換のため、前記プライベートIPv4アドレスと6-4ソースアドレスのインタフェースID値との関連を格納するステップを更に有することを特徴とする方法。
2. 請求項１に記載の方法であって、
   −前記IPv4ネットワークでインバウンドパケットを受信するステップと、
   −前記インバウンドパケットがIPv6パケットをカプセル化しているか否かを決定するステップと、
   −肯定的な場合には、カプセル化されたIPv6パケットの宛先アドレスのインタフェースIDを取り出し、対応の格納したプライベートIPv4アドレスを取り出すために前記インタフェースIDを使用し、それに従って前記IPv4ヘッダの宛先アドレスを更新するステップと、
   −第１のネットワークで変更した6-4パケットを転送するステップと
   を更に有する方法。
3. 請求項１又は２に記載の方法であって、
   −前記アウトバウンドパケットのIPv6ヘッダの6-4ソースアドレスのIPv4アドレス部分を、パブリックIPv4アドレスに変更するステップと、
   −インバウンドパケットの6-4宛先アドレスのIPv4アドレス部分を、対応するプライベートIPv4アドレスに変更するステップと
   を更に有する方法。
4. 請求項３に記載の方法であって、
   チェックサムのような少なくともIPv4ヘッダのフィールドを変更するステップを更に有し、その値は6-4ソースアドレスに依存する方法。
5. 請求項２に記載の方法であって、
   前記インタフェースIDと前記第１のネットワークの6-4パケットのソースアドレスとの関連を格納するステップと、前記インタフェースIDの機能としてインバウンドパケットの宛先アドレス又はアウトバウンドパケットのソースアドレスを変更するステップは、前記ネットワークアドレス変換機構を支援するアプリケーションレベルゲートウェイにより実行される方法。
6. 請求項３又は４に記載の方法であって、
   6-4アドレスのIPv4部分を変更するステップは、前記ネットワークアドレス変換機構を支援するアプリケーションレベルゲートウェイにより実行される方法。
7. ネットワークアドレス変換機構を通じた6-4トンネリングプロトコルをサポートする装置であって、
   −IPv6パケットをカプセル化するアウトバウンドIPv4パケットのプライベートソースアドレスを、パブリックソースアドレスに変更するネットワークアドレス変換機構(NAT)を有し、
   アウトバウンドパケットについて、IPv6ネットワークのホストの6-4ソースアドレスに含まれるプライベートIPv4アドレスを格納し、6-4宛先アドレスと同じインタフェースIDを有する格納したプライベートIPv4アドレスで、インバウンドパケットの6-4宛先アドレスを更新するアプリケーション(ALG)を更に有することを特徴とする装置。
8. 請求項７に記載の装置であって、
   前記アプリケーションは、アウトバウンドパケットの更なる処理を実行するように更に適合され、
   前記更なる処理は、アウトバウンドパケットの6-4ソースアドレスのプライベートIPv4アドレス部分を、前記装置のパブリックIPv4アドレスに置換することを有する装置。

Images