JP2004357292A - ＩＰ交換網上で伝達されるデータをＩＰｖ４ベースからＩＰｖ６ベースに変換するシステム - Google Patents

Abstract

【課題】ＩＰｖ４プロトコルベースのデータパケットをＩＰｖ６プロトコルベースのデータパケットに変換して、データ伝送システム中の仮想プライベートネットワークに送出するシステムを提供する。
【解決手段】ＳＴ１（２０），ＳＴ２（２６）はＩＰｖ４プロトコルベースで動作し、ＩＰ交換網２５はＩＰｖ６プロトコルベースで動作する。ＳＴ１（２０）とＩＰ交換網２５の間に設けられたＰＢ１（２２）はＳＴ１（２０）から受け取ったＩＰｖ４プロトコルベースのデータパケットをＩＰｖ６プロトコルベースのデータパケットに変換しＩＰ交換網２５に送出する。ＩＰ交換網２５とＳＴ２（２６）の間に設けられたＰＢ２（２８）はＩＰ交換網から受け取ったＩＰｖ６プロトコルベースのデータパケットをＩＰｖ４プロトコルベースのデータパケットに変換しＳＴ２（２６）に送信する。
【選択図】図１

Description

本発明は、一般に、ＭＰＬＳ(Multi-Protocol Label Switching)ネットワーク等のＩＰ交換網内におけるデータパケットの伝達に関する。本発明は、特に、その種のネットワーク上で伝達されるデータをＩＰｖ４ベースからＩＰｖ６ベースに変換するシステムに関する。

デバイス間のプライベート通信を可能にするため、その一部分又は全体に亘り公衆網を用いて、数多くの仮想プライベートネットワーク（ＶＰＮ）が構築されている。多くのＶＰＮは、レイヤ３たるＩＰプロトコルルールと、ＩＰプロトコルの主としてＩＰｖ４フレーバとをサポートするよう、構築されている。

今日、ＩＰｖ４プロトコルにおける問題としては、周知となっているＩＰｖ４内におけるアドレス空間制約に加え、ＩＰｖ４のフォワーディングルールにおける問題が注目されている。後者の問題は、即ち、ルーティングアクションが宛先アドレスに基づいており発信元アドレスからは何ら影響を受けないことである。ＩＰｖ４ネットワークは世界中のどこにでも存在しうるため、ルータはアクティブなネットワークに関する記録をことごとく保持しなければならない。これはインターネットだけでなくＶＰＮ、イントラネット及びエクストラネットにも当てはまる問題である。

これらの問題点に対する現実的で長視野的な解決は、アドレス空間を拡張し、より多くをアドレス指定できるようにし、割当ポリシーを切迫したものでなくし、ルーティングをより効率的なものにすることであろう。これこそがＩＰｖ６により提供されるものであり、バックボーンとしての使用を魅力的なものにしている。ＩＰスケーラビリティ及び管理の容易性も、ＩＰｖ６の目標のうちである。しかし、すべてのデバイスがｖ６であるわけではないので、今日においてｖ６を利用するための機構を見つける必要がある。加えて、現在におけるＩＰｖ６ヘッダの推奨使用形態は、ＭＰＬＳのようなプロトコルのラベルスイッチング能力及びＶＰＮサポート能力とは、何ら関連づけられていない。

ＶＰＮの構築及びＶＰＮ同士の接続にルートフィルタリングを使用した場合、ルックアップの対象とすべきアドレスフィールドが長いため、ＩＰｖ６アドレスフィールドのみに基づくＩＰｖ６のネイティブ使用はＩＰｖ４より更に複雑である。このような“ルートフィルタリング”によってルートプロパゲーションの制御、即ち特定のネットワークがその関心あるコミュニティ（即ちＶＰＮ）内にある他のネットワークへのルートを受信できるようにする制御を、実現できる。

ルートフィルタリングは、ＶＰＮをサポートしている基礎ＩＰ網（例えばインターネット）におけるあるネットワークサブセットが実際にＶＰＮを形成する、という条件に基づいている。このネットワークサブセットに係るルートは、そのＶＰＮを形成するネットワークサブセットに接続されている他のネットワーク（群）に対してアナウンスされないよう、フィルタリングされる。逆に、他の非ＶＰＮルートはそのネットワークサブセットに対してはアナウンスされない。ここに、ＩＰｖ４上でのルートフィルタリングは互いに異なるアドレス空間を用いるＶＰＮを含むものである。ＩＰｖ６においては、ＶＰＮがＩＰアドレス空間内で識別されるためこのフィルタリングが単純化されるが、セキュリティホールが開いてしまう。

ネットワーク層上におけるサービスのプライバシーのため、ルートフィルタリングＶＰＮは何れのＶＰＮホストもそのＶＰＮ外からの送信元アドレスを含むパケットに応答しないよう（或いは当該応答が制限されるよう）、実現される。このような応答制限はＡＣＬ(access control list)に基づくものであり、ＡＣＬは各ユーザがどのアクセス権を有しているのかをデバイスに教えるテーブルである。即ち、ＡＣＬは、個人又はグループに対する特定のアクセス権を付与又は否定するエントリのリストである。

しかしながら、ルートフィルタリングＶＰＮは、各種の問題点を有している。例えば、許容すべきでないパケットを間違って許容してしまったり及び／又は許容すべきパケットを拒絶してしまうといった構成が間違って構築されてしまうことがある。ルートフィルタリングに伴うもう一つの問題点は、ゲートウェイ又はファイアウォールの背後に構築したときに、加入者網がゲートウェイ／ファイアウォール外のルータをデフォルトルータとして規定でき、（仮に通知されていなくとも）当該デフォルトルータのアドレスを知っている限り、ゲートウェイ／ファイアウォール背後のＶＰＮのユーザが外部ネットワークに到達できることである。この技術の更なる欠点としては、管理上のミス、設計の静的性質及び提供されるセキュリティの制限が含まれる。加えて、全ルールの定義及び保持の複雑さが非常に顕著であり、この技術の拡張は好適且つ容易には進まない。

共有ＩＰバックボーンを用いてＶＰＮを構築する際に相異なるレベルのネットワークプライバシーを達成するため、様々な解決策が提案されている。これらの解決策の多くは分離したＶＰＮ毎のフォワーディング能力を要求しており、バックボーンに設けたＩＰ又はＭＰＬＳベースのトンネルを使用する。その種のトンネルは特にトンネルピアデバイスにおけるオーバヘッド及び管理上の複雑さを増加させる。また、ＶＰＮドメイン内においては、ルーティングの瞬間がルータ間ＶＰＮ伝達可能性情報を頒布するのに使用される。何れのルーティングプロトコルも使用できるが、ＶＰＮ到達可能性を達成するのに、ＶＰＮ関連での変形乃至エクステンションは必要とされない。

上述の技術（又は他の公知技術）がＶＰＮを形成するのに用いられているかどうかにかかわらず、理解されるべきことに、関心事となるのはネットワークセキュリティである。実際、ＶＰＮは別にしても多くのコンテキストにおいてネットワークセキュリティは関心事であり、一般に、公衆網を介したリモートアクセスや事業所間通信のためのインターネットアクセスの増大は、セキュリティ技術進化の主たる推進力となっている。

ネットワークセキュリティ向けの多くの技術はファイアウォールの利用をめぐるものである。一般に、ファイアウォールとして知られるハードウエアとソフトウエアの結合は、２個又はそれ以上の個数のネットワーク間でのネットワークトラフィックを管理或いは抑制する、というセキュリティポリシーを実現するためのものである。ここでいう２個又はそれ以上の個数のネットワークのうちいくつかは、（例えば組織的ネットワークのように）管理制御下に置かれ、またいくつかは、（例えばインターネットのように）管理制御外に置かれる。

使用しているルーティング技術とはかかわりなく、ルーティング機構は普通はセキュリティポリシーを実現するためには使用されない。即ち、ルーティング機構は、セキュリティ機能を実行するには動的すぎ、信頼しにくい、としばしば考えられている。ルーティング機能及びサポート構造は一義的にはパケットを効率的に且つ信頼性よくルーティングできるよう設計されており、セキュリティは当該一義的な考慮の外にある。そのため、セキュリティを目的としファイアウォール（及び／又はルータ）の動作と関連して実現されたフィルタリング技術が存在し、その例としてはパケットフィルタリング、アプリケーションプロキシ、並びにダイナミックフィルタリング（stateful inspection）がある。フィルタリングが適用されるフィールドは確証されたフィールドでなければならず、ＩＰｖ４ヘッダタイプを安易に用いることはできない。必要なフィールドの一つとしては、ＶＰＮ ＩＤフィールドがある。

個別のＶＰＮにセキュリティを付与する技術は上述のように多くあるけれども、ＶＰＮに対しては、ユーザへのサービスを犠牲にすることなしに（例えば２個又はそれ以上の個数のＶＰＮ間での或いは特定のＶＰＮ内での伝達上のセキュリティを減ずることなしに）相互通信できるようにしたい、という更なる要請がある。

本発明の主たる目的は、ＩＰｖ４ベースのデータをＩＰｖ６ベースのデータに変換し変換したデータをＩＰ交換網を介し伝達するシステムを提供すること、特に、共有ＩＰバックボーンを用いてＶＰＮを構築するに当たって、ルートフィルタリング等に係る上述した問題点を除去しネットワークセキュリティを改善したシステムを提供することにある。

即ち、本発明はデータパケットをＩＰｖ４プロトコルベースからＩＰｖ６プロトコルベースに変換し、データ伝送システム中の複数の仮想プライベートネットワーク（ＶＰＮ）を備えたインフラストラクチャを介して伝達させるシステムに関するものである。当該データ伝送システムはＩＰ交換網を含み、このＩＰ交換網には第１のワークステーションが第１のプロバイダエッジ（ＰＥ）デバイスを介して、また第２のワークステーションが第２のＰＥデバイスを介して接続されている。これらのワークステーションはＩＰｖ４プロトコルにて動作するが、ＩＰ交換網はＩＰｖ６プロトコルにて動作する。本発明に係るシステムは、第１のワークステーションとＩＰ交換網との間に設けられた第１のパケットビルダを備える。第１のパケットビルダは、第１のワークステーションから受信したＩＰｖ４プロトコルベースのデータをすべてＩＰｖ６プロトコルに変換してＩＰ交換網に送信する（その逆も行う）。本発明に係るシステムは、第２のワークステーションとＩＰ交換網との間に設けられた第２のパケットビルダを備える。第２のパケットビルダは、ネットワークから受信したＩＰｖ６プロトコルベースのデータをすべてＩＰｖ４プロトコルに変換して第２のワークステーションに送信する（その逆も行う）。

図１に、本発明に係るシステムを示す。このシステムにおいては、２個のワークステーションＳＴ１ ２０及びＳＴ２ ２６がＩＰ交換網２５を介してデータを交換している。好適な実施形態においては、ＩＰ交換網２５はＭＰＬＳ（Multi-Protocol Label Switching）プロトコルベースのネットワークである。ＭＰＬＳプロトコルは、プロバイダエッジ（ＰＥ）デバイスを規定するＩＰ技術である。ＰＥデバイスは、各カスタマフローについてネットワークを介した物理的経路を規定するデバイスである。ＰＥデバイスにより規定される経路は、進入ＰＥ例えばＰＥ１ ２４から退出ＰＥ例えばＰＥ２ ３０へと向かう経路に沿ってスワップされる一組のラベルとして、定義される。

既述の通りＭＰＬＳネットワークであることが望ましいＩＰ交換網２５においては、いくつかのＶＰＮがエッジデバイスＰＥ１ ２４とエッジデバイスＰＥ２ ３０との間に実現される。本発明に係る環境は、例えばＩＰｖ６プロトコルにて提唱されているレイヤ３機構を用い、特定のＶＰＮをどのようにして確立できるか及び安全に識別できるか、に関するものである。

ここに、各ワークステーション２０及び２６から送出されるデータパケットがＩＰｖ４に基づいているものとする。即ち、ワークステーションＳＴ１ ２０及びＳＴ２ ２６はそれぞれＩＰｖ４ネットワーク２１又は２７に接続されているものとする。ワークステーションＳＴ１ ２０からのＩＰｖ４データフローは後述の如くパケットビルダＰＢ１ ２２によりＩＰｖ６データフローに変換される。それらのパケットはＩＰｖ６ネットワーク２３を介して進入ＰＥ即ちＰＥ１ ２４に送られ、そして網２５を介して伝達される。この網２５がＭＰＬＳネットワークであれば、当該伝達に際してラベルスイッチングが行われる。

網２５の出口においては、ＩＰｖ６のデータパケットがＰＥ２ ３０により受信され、ＩＰｖ６ネットワーク２９を介してパケットビルダＰＢ２ ２８へと転送される。それらのパケットは、後述するようにＩＰｖ６からＩＰｖ４へと変換され、ＩＰｖ４ネットワーク２７を介してワークステーションＳＴ２ ２６へと転送される。勿論、このデータフローと逆のデータフロー、即ちワークステーションＳＴ２ ２６からワークステーションＳＴ１ ２０への流れも可能である。

本発明の原理は、図２Ａに示すようにＲＦＣ２３７３及びＲＦＣ２３７４においてＩＥＴＦ（Internet Engineering Task Force）により提案されたＩＰヘッダから、使用するＩＰヘッダを導き出すことにある。集約（aggregation）可能なグローバルユニキャストアドレスのフォーマットは、現プロバイダ集約及び交換用に用いる新たな集約の双方をサポートするよう、設計されている。この組合せにより、プロバイダに直接接続されている両サイトについて効率的なルーティング集約が可能になる。サイトは何れかのタイプの集約点を選んで接続できる。

グローバルには、図２Ａに示したアドレスフォーマットにおいて、最初の４８ビットがパブリック、次の１６ビットがサイト内配置、残りの６４ビットがインタフェース識別子に係るものである。フィールドの内訳は次の通りである：

・ＦＰ フォーマットプレフィックス（３ビット）。集約可能なグローバルユニキャストアドレス用
・ＴＬＡ ＩＤ トップレベル集約識別子
・ＲＥＳ 将来使用のためリザーブ
・ＮＬＡ ＩＤ 次レベル集約識別子
・ＳＬＡ ＩＤ サイトレベル集約識別子
・ＩＮＴＥＲＦＡＣＥ ＩＤ インタフェース識別子

アドレスルックアップ（ロンゲストプレフィックスマッチ）等、ＩＰｖ６機構のトランスペアレントな使用のため、基本的な構造は再利用できる。しかし、残念なことに、ＩＰｖ４フォーマットからＩＰｖ６を構築するのに使用される機構は静的でありエッジデバイスにおいてマニュアルで設定される。

そこで、本発明においては、図２Ｂに示すように、新しいタイプのＩＰｖ６フォーマットを提案する。本発明に係るフォーマットにおける各フィールドの内訳は次の通りである：

・ＰＲＯ ＩＤ プロバイダＩＤ（例えばＡＴ＆Ｔ）
・ＰＥ ＩＰ交換網に接続されているＰＥデバイス（例えば２４，３０）の個数。ＰＥフィールドの定義方法もまた本願による提案の一部でありいくつかの方法を含むものである。例えば、ネットワーク管理ツールにより提供される既知のアクティブトポロジー、ＩＰレベルの発見：トレースルート＋ダイナミック又はレギュラー更新技術付きＰＥデータベース、ＭＰＬＳツールにより所与、強制又は所定。
・ＶＰＮ ＩＤ 階層的ＶＰＮ構造を提供するためエリア分割することができる。
・ＬＯＣ ＩＤ サイトの幾何学的配置
・ＨＯＳＴ ＩＤ 対応するＩＰｖ４アドレスを使用するデバイスを参照するＩＤ。このホストはサーバ、クライアント、ルータ、ファイアウォールになりうる。また、異なるルールを適用できる。好適な実施形態においては、もしＭＡＣアドレスを発見及びチェックできたならばそのＭＡＣアドレスがＨＯＳＴ ＩＤとなる。補助的なプライバシー情報を与えるユニーク識別を提供する。ＩＰｖ６アドレスフィールド上のＨＯＳＴ ＩＤは、ＩＰｖ４アドレスに対応するＭＡＣアドレス又は等価なＩＤ及びローカルに保持されている両者の対応関係を含むことができる。
・ＩＰｖ４ ＡＤＤ 入ってくるパケット内に存在する送信元又は宛先のＩＰｖ４アドレス。

本発明の主たる利点は、ラベル頒布及びＶＰＮ（ＭＰＬＳ ＶＰＮ）の管理を単純化できることである。それは、宛先ＰＥが本発明に係る新しいＩＰｖ６ヘッダの宛先アドレスフィールド内に含まれているからである。ＭＰＬＳ ＶＰＮにおいてやられているようなデュアルラベル実施の必要がない限りにおいて、フロー毎のＶＰＮラベルはラベル内へのフロー集約の代わりに使用できる。この方法を用いることにより、例えばＰＥ１上にてＭＰＬＳネットワーク２５に入るパケットは、直接そのＩＰｖ６ヘッダ内において宛先ＰＥ例えばＰＥ２を指し示すことができる。ＰＥ１がＰＥ２への到達の仕方を知っているのならば、特別な経路識別は必要でない。

最後に、ＩＰ交換網内におけるルーティングのためアドレスフィールドのＭＳＢバイトのみが使用され、アクセスにはＬＳＢバイトのみが使用される。これは、アドレスルックアップ機構をＰＥレベルにおいてさえも単純化する。従来のＩＰｖ６においては、通常１２８ビットのアドレスルックアップが必要でありアドレスルックアップ機構が複雑であることが、問題の一つであった。ＩＰｖ６を入力プロトコルとしてサポートしている現在のＰＥを使用できるが、それを改善して使用することもできる。即ち、ＩＰｖ６アドレスフィールドのＭＳＢ部分においてサブフィールドを識別することにより、ルーティングするパケットのＰＥアドレスとして直接使用することができる。

ＶＰＮ ＩＤを含むＩＰｖ６ヘッダによりプライバシーが保証されていることから、ＭＰＬＳネットワークはＭＰＬＳ ＶＰＮの様な格別のＶＰＮ機能を伴って実施される必要がない。このＶＰＮ ＩＤフィールドはユーザにより設定されるのではなくパケットビルダデバイスＰＢ１又はＰＢ２により設定される。そのため、ユーザにより定義されたＩＰｖ６フローによりスプーフされるリスクがなくなる。これはセキュリティ上の改善であり、ネイティブなＩＰｖ６入力フローについてさえも用いる価値がある。すべての安全なフィールドはネットワークの進入ノードにおいて確証され、付加され又は置換されるべきである。もしフィルタリングにも使用しているのであれば、それらのフィールドには、ＰＲＯ ＩＤフィールド、ＰＥフィールド、ＶＰＮ ＩＤフィールド、ＬＯＣ ＩＤフィールド及びＨＯＳＴ ＩＤフィールドが含まれる。ＩＰｖ６パケットを受信したとき、そのヘッダ構造がローカルルールにマッチしていることを認証すべく解析が行われ、ＩＰｖ６スプーフィングが防止される。もしマッチしていなければ、フィールド及びルールにより、修正又は無視される。もし修正されたならば、ステートフル機構等、ネットワークから入ってくるパケット用にオリジナルのアドレスフィールドを再構築するため、スワップテーブルが構築される。その場合、それは、提唱されているルールと明白にマッチしないＩＰｖ６フローを変換するＩＰｖ６ＮＡＴのように働く。その変換はＰＢデバイスにより実行される。

本発明はルーティングスケーラビリティを改善する。ＩＰヘッダがフローの管理に必要なすべてのフィールドを含んでいるため、片側にＩＰｖ４、もう片側にＭＰＬＳという構成を採る場合、その実施によるネットワーク管理はより単純である。これはまた、改善されたセキュリティをも提供する。

ＭＰＬＳを考える限りでは、現在のベンダ及び標準化機構はｖ４ ＭＰＬＳ ＶＰＮ機構を再利用する６ＰＥと呼ばれるＭＰＬＳを介してＩＰｖ６につき検討している。本発明はｖ４ベースのＭＰＬＳ及びＢＧＰ機構をネイティブな（しかしなおかつ６ＰＥソリューションともコンパチブルな）ｖ６機構によって置き換える中間挿入実施という構成を有している。ＩＰｖ６ヘッダ中にＭＰＬＳ ＶＰＮ知識を導入する利点は、ネットワーク上の様々な点で必要とされるすべての情報を含んだ単一の送信要素に収束することである。ＭＰＬＳ−ＭＰＬＳ間動作はまた、ＩＰｖ６ヘッダが必要なクロスオーバ情報を含んでおりラベルレベルでのブリッジが必要でない限りにおいて、より安全なやり方で実施及び管理することがより簡単になっている。

本発明を実施するためには、送信元及び宛先アドレスのための各フィールドの値を安全なやり方で与えるサーバを用いる必要がある。ＩＰｖ６アドレスを安全に与えるため、その種のサーバには、ＤＮＳ、Ｗｈｏｉｓ、ルートリフレクタ、更にはＣＡ（Certificate Authority）が含まれる。図３に、パケットビルダ２２又は２８とサーバ３１〜３７の論理的接続を示す。図中の仮想ネットワーク３９はＩＰｖ４ネットワーク２１又は２７、ＩＰｖ６ネットワーク２３又は２９、ＭＰＬＳネットワーク２５、その他これらのネットワークに接続された或いはパケットビルダに直接接続されたネットワークである。

ＩＰｖ６の送信元又は宛先アドレス再構成は、ＩＰｖ４パケットを用いてＩＰｖ６パケットを構成する方法である。

・ＤＮＳサーバ３１上の逆ＤＮＳルックアップ及びサーバ３２上のＷｈｏｉｓルックアップは宛先デバイス及びオーナ（ＩＳＰ／顧客）のロケーションの識別に使用される。両者はＬＯＣ ＩＤフィールド及びＶＰＮ ＩＤフィールドの設定に使用される。

・ＣＡサーバ３３からの認証要求は送信元及び／又は宛先ＩＰアドレスＩＰｖ４ ＡＤＤ及びＨＯＳＴ ＩＤを確証するセキュリティ目的で使用される。これはＤＮＳ及びＷｈｏｉｓサーバに加え又はこれに代えて使用できる。

・ディレクトリサーバ３４は許可されたサブネット及び認証されたＨＯＳＴ ＩＤを含むが代替認証方法としては認証を使用しない。もし１個より多いＶＰＮがインタフェース上でサポートされているならば、このサーバ又はＣＡはまたＶＰＮ ＩＤを提供する。さもなくば、ＶＰＮ ＩＤは、今日単一のＶＰＮに対応する１個の物理的又は論理的（一般には仮想的）回路により行われているように、１対１マッピングスタティックテーブルを用いてインタフェースにより定義される。

・ルートリフレクタＲＲ３５は宛先アドレス用のＰＥフィールド値を提供する。送信元アドレスはローカルで付したＰＥ識別フィールドで埋める。ＲＲは、ＩＰ交換インフラストラクチャを介したルーティングであって、ＶＰＮグループ又はフロータイプのルーティングを提供することを許す各種のルーティング技術を用いたルーティングを、解決する。

・ネットワーク管理ツール３６は、必要であれば動的に適用することができるフィルタリングルールを提供する。ＰＢは、例えばスプーフィングを回避するために、侵入点においてフィルタリングルールを配置するための適切な場所である。ＮＭは宛先ネットーワークへの攻撃を容易に識別し、どの侵入点からこれらのパケットが送られてきたのかを容易に検出し、適切な処置を容易に施すことができる。

・ＡＲＰプロキシＡＰ３７は、もしこの機能がセキュリティの改善及びデバイスの識別に使用された場合、送信元デバイスのＭＡＣアドレスを提供する。ある種のケースでは、その間に他のルータがないとき、プロキシはちょうどデフォルトアクセスルータの如くである。その場合、そのルータはＡＲＰリクエストに対して応えることが可能であるべきである。ＭＡＣアドレスをＤＮＳ乃至ディレクトリサーバ内に又は認証内に予め格納しておいてもよい。ＡＲＰプロキシ又はＡＲＰリクエストのデフォルトルータに対する利点はＭＡＣアドレスがフローにおける送信元ＩＰアドレスに対して動的に確証されることである。そして、例えば、既知のＭＡＣアドレスは、レギュラーＬＡＮネットワーク上に接続されていない場合でさえも付与される。全サーバからの未知のＭＡＣアドレスはルールの他の例たる何らかのネットワークへの接続のため秘匿される。

このようにして満たされるＩＰｖ６フィールドは、送信元アドレス及び宛先アドレスを含んでいる。図に示したのは双方のＰＢデバイスがすべてのサーバにアクセスし送信元及び宛先アドレスフィールド双方についての情報を得る実施形態である。これに代わる実施形態は、ＰＢ１が宛先情報をサーバからではなくＰＢ２から直接に入手するためＰＥ２が宛先として与えられたときローカルルートリフレクタが宛先パケットビルダ（例えばＰＢ２）のＩＰアドレスを提供する実施形態である。その種の実施形態の利点は能力である。なぜなら、各パケットビルダデバイスがすべてのローカルにアクセス可能なデバイスのリストをそれと関連するパラメタと共に保持しているからである。従って、リモートＰＢに対する１回の呼において、すべての情報が提供されうる。もしリモートＰＢがこのデバイスをそのキャッシュ内に有していないのであれば、それを得るべくサーバに加入しに行く。この分析は１回のフロー毎に１回のみ（第１のパケットについて）行われ、実行される分析のレベルはパケットが送られるべきネットワークに依存している。実際、送信元部（又は新たなものなら宛先部）が処理されキャッシュ内に情報が保たれている限りにおいて、１フロー当たり１回未満である。これによりその種の情報の能力インパクトが最小化される。

他の実施形態によれば、図４に示すように、パケットビルダはＰＥデバイスと一体化される。この場合においては、図１に示した一般的な実施形態に存在していたＩＰｖ６ネットワークは勿論存在しない。その代わりに、パケットビルダ及びＰＥデバイスは単一ブロックを構成している。即ちＰＢ１ ２２及びＰＥ１ ２４に代えブロックＶ６ＰＥ１ ４１が、ＰＢ２ ２８及びＰＥ２ ３０に代えブロックＶ６ＰＥ２ ４２が、存在している。

この推奨実施形態はまた、ＰＥそれ自体の機能をより効率的に実行するのにも使用される。それは、アドレスのＰＥフィールドが、追加経路探索なしで且つＭＰＬＳ ＶＰＮ上でのようなラベルのレベル追加なしでＭＰＬＳコアへと先送りするために、ＰＥにより直接用いられるからである。実際、フルＩＰｖ６ヘッダの送信に代わりラベルが圧縮されたヘッダとして使用され、送信フロー毎に１ラベルとなることを意味する。双方の送信（ラベルとそれに続くフルＩＰｖ６ヘッダの送信）は、冗長ではあるが可能である。いくつかのコンパチブルな実施形態を、ＩＰ交換ラベルを用いたパケット伝達用のコアにおいて使用することができる。退出ＰＥ又はＰＢにおいて各パケットのオリジナルＩＰｖ６ヘッダを回復させることが必要である。

送信したワークスステーションから受信するワークステーションに至るフローに沿ったデータパケットの変化を、図５Ａに示す。ワークステーション２０においては、データパケットは標準的なＩＰｖ４パケットフォーマットであり、ＩＰｖ４ヘッダ及びデータペイロードを有している。このパケットはステップ６１においてＰＢ１デバイスに送られる。パケットビルダはＩＰｖ４ヘッダフィールドを確証し、図３に示したサーバと協働して、対応するＩＰｖ６ヘッダを構成するのに用いるフィールド値を決める（見つける）。それは、主として、ＩＰｖ６宛先アドレス及びＩＰｖ６送信元アドレスである。ＰＢ１は、もし規定されているならば、追加的にフィルタリングを実行することができる。

作成された新たなパケットはステップ６２にてＰＥ１に送られる。ＰＥ１は宛先ＰＥを識別しそのパケットをステップ６３においてＰＥ２へと先送りする。ＰＥ１は、コアにおけるパケット交換を改善するため、ＭＰＬＳラベル等のラベルを追加できる。ＰＥ２はそのパケットを受け取り（もし存在するなら）交換ラベルを除去する。ＰＥ２はそのパケットをステップ６４にてＰＢ２に送る。ＰＢ２はまずフィルタリングを実行できる。ＰＢ２は更にＩＰｖ６ヘッダを除去して簡単にＩＰｖ４ヘッダを再構成する。これが可能であるのは、ＩＰｖ６ヘッダがすべての必要なフィールドを含んでいるためである。このＩＰｖ４パケットはステップ６５において宛先ワークステーション２６へと更に先送りされる。

このプロセスは複雑に見えるが実際にはすべてＰＢ１及びＰＢ２にて１回実行されるだけであることに、留意されたい。他のパケットが同じフローを通るときは、ヘッダフィールドを同じフィールド値を用いてスワッピングする必要があるだけである。そのためには、スワップテーブルをパケットビルダ上に構成しておけばよい。そうすれば、ヘッダをスワッピングする速度が高まる。

チェックサムを再構成し又は付加すること及び他のＩＰｖ４ヘッダを再構成することはここでは詳細には述べない。それは、それらの機能が、例えばＲＦＣ２７６６その他のＩＥＴＦ ＲＦＣ又はその草案において、標準ルール及びトランスレーション機構を用いて行われているからである。

パケットビルダの機能がＰＥデバイスに一体化されている第２実施形態を用いるときは、データパケットのフロー（及びそれに伴う構造変化）は図５Ｂに示すように単純化されるが、本質的には第１実施形態におけるデータフローと同様のものとなる。

本発明を実施したデータ伝送システムの第１実施形態を示す図である。 ＩＰｖ６の集約可能なグローバルユニキャストアドレス及び本発明を実施するに当たってそれに施した変形を示す図である。 ＩＰｖ６の集約可能なグローバルユニキャストアドレス及び本発明を実施するに当たってそれに施した変形を示す図である。 仮想ネットワークを介し情報サーバに接続された本発明によるパケットビルダを示す図である。 パケットビルダの機能をＰＥデバイスに組み込んだ本発明の第２実施形態を示す図である。 本発明の第１及び第２実施形態において送信元から宛先へと流れていくときのデータパケット構造の変化を示す図である。 本発明の第１及び第２実施形態において送信元から宛先へと流れていくときのデータパケット構造の変化を示す図である。

符号の説明

２０，２６ ワークステーション、２１，２７ ＩＰｖ４ネットワーク、２２，２８ パケットビルダ、２３，２９ ＩＰｖ６ネットワーク、２４，３０ プロバイダエッジ（ＰＥ）デバイス、２５ ＩＰ交換網、３１〜３７ サーバ、３９ 仮想ネットワーク、４１，４２ パケットビルダ内蔵ＰＥ。

Claims (12)

1. ＩＰｖ４プロトコルをベースとしたデータパケットをＩＰｖ６プロトコルをベースとしたデータパケットに変換しデータ伝送システム中の複数の仮想プライベートネットワーク即ちＶＰＮインフラストラクチャ上で伝達させるシステムであって、上記データ伝送システムが、第１のワークステーション（２０）が第１のプロバイダエッジ即ちＰＥデバイス（２４）を介して接続され第２のワークステーション（２６）が第２のＰＥデバイス（３０）を介して接続されたＩＰ交換網（２５）を含み、上記第１及び第２のワークステーションがＩＰｖ４プロトコルで、また上記ＩＰ交換網がＩＰｖ６プロトコルでそれぞれ動作するシステムにおいて、
   上記第１のワークステーションと上記ＩＰ交換網との間に設けられ、第１のワークステーションから受け取ったＩＰｖ４プロトコルベースのデータパケットをＩＰｖ６プロトコルベースのデータパケットに変換して上記ＩＰ交換網に送出し、またその逆方向の変換も行う第１のパケットビルダ（２２）と、上記ＩＰ交換網と上記第２のワークステーションとの間に設けられ、上記ＩＰ交換網から受け取ったＩＰｖ６プロトコルベースのデータパケットをＩＰｖ４プロトコルベースのデータパケットに変換して上記第２のワークステーションに送出し、またその逆方向の変換も行う第２のパケットビルダ（２８）とを、備えることを特徴とするシステム。
2. 請求項１記載のシステムにおいて、更に、少なくとも、第１及び第２のパケットビルダ（２２，２８）によりアクセスされ、第１及び第２のパケットビルダに対してＩＰｖ４プロトコルベースのデータパケットからＩＰｖ６プロトコルベースのデータパケットへの変換に必要な情報を提供するサーバ（３１〜３７）を備えるシステム。
3. 請求項２記載のシステムにおいて、上記パケットビルダ（２２，２８）のうち一つによりＩＰｖ６プロトコルベースに変換されるデータパケットに含まれるパケットヘッダが、変換前に上記パケットヘッダにあったＩＰｖ４アドレスに加えて、送信元ＰＥ又は宛先ＰＥとして用いられるＰＥ（２４又は３０）に対応するＰＥフィールドと、ＶＰＮ識別フィールドと、を含むシステム。
4. 請求項３記載のシステムにおいて、上記パケットビルダ（２２，２８）のうち一つによりＩＰｖ６プロトコルベースに変換されるデータパケットが、更に、サイトの幾何学的配置を参照するＬＯＣ識別フィールドと、そのデータパケットを送信したワークステーション（２０，２６）を参照するＨＯＳＴ識別フィールドと、を含むシステム。
5. 請求項２記載のシステムにおいて、ＩＰｖ４プロトコルベースのデータパケットからＩＰｖ６プロトコルベースのデータパケットへの変換に必要な情報を提供するサーバ（３１〜３７）が、上記第１及び第２のパケットビルダにより仮想ネットワーク（３９）を介してアクセスされるシステム。
6. 請求項５記載のシステムにおいて、上記サーバが、ドメインネームサーバ（３１）、Ｗｈｏｉｓサーバ（３２）、認証機関サーバ（３３）、ディレクトリサーバ（３４）、ルートリフレクタ（３５）、ネットワーク管理ツール（３６）及びプロキシ（３７）のうち一つを含むシステム。
7. 請求項１乃至６の何れか一項に記載のシステムにおいて、上記パケットビルダ（２２又は２８）が上記ＰＥデバイス（２４又は３０）とＩＰｖ６プロトコルベースのネットワーク（２３又は２９）により接続されたシステム。
8. 請求項１乃至６の何れか一項に記載のシステムにおいて、上記パケットビルダ（２２又は２８）が上記ＰＥデバイス（２４又は３０）と一体化されたシステム。
9. ＩＰｖ４プロトコルをベースとしたデータパケットをＩＰｖ６プロトコルをベースとしたデータパケットに変換しデータ伝送システム中の仮想プライベートネットワーク即ちＶＰＮを介して伝達させる方法であって、上記データ伝送システムが、第１のワークステーション（２０）が第１のプロバイダエッジ即ちＰＥデバイス（２４）を介して接続され第２のワークステーション（２６）が第２のＰＥデバイス（３０）を介して接続されたＩＰ交換網（２５）を含み、上記第１及び第２のワークステーションがＩＰｖ４プロトコルで、また上記ＩＰ交換網がＩＰｖ６プロトコルでそれぞれ動作する方法において、
   上記ＩＰ交換網への送信前に外部サーバから提供される情報を用いてＩＰｖ４プロトコルベースのデータパケットをＩＰｖ６プロトコルベースのデータパケットに変換するステップと、
   上記ＩＰ網から供給されるＩＰｖ６プロトコルベースのデータパケットを上記第１又は第２のワークステーションへの送信前にＩＰｖ４プロトコルベースのデータパケットに変換するステップとを、
   有することを特徴とする方法。
10. 請求項９記載の方法において、ＩＰｖ６プロトコルベースに変換されるデータパケットに含まれるパケットヘッダが、変換前に上記パケットヘッダにあったＩＰｖ４アドレスに加えて、送信元ＰＥ又は宛先ＰＥとして用いられるＰＥ（２４又は３０）に対応するＰＥフィールドと、ＶＰＮ識別フィールドと、を含む方法。
11. 請求項１０記載の方法において、ＩＰｖ６プロトコルベースに変換されるデータパケットが、更に、サイトの幾何学的配置を参照するＬＯＣ識別フィールドと、そのデータパケットを送信したワークステーション（２０，２６）を参照するＨＯＳＴ識別フィールドと、を含む方法。
12. 請求項１１記載の方法において、上記外部サーバが、ドメインネームサーバ（３１）、Ｗｈｏｉｓサーバ（３２）、認証機関サーバ（３３）、ディレクトリサーバ（３４）、ルートリフレクタ（３５）、ネットワーク管理ツール（３６）及びプロキシ（３７）のうち一つを含む方法。

Images