1. Introduction (はじめに)

このドキュメントは、サービスプロバイダが IP バックボーンを使用して、顧客に IP 仮想プライベートネットワーク (Virtual Private Networks, VPN) を提供する方法について説明します。この方法では、顧客のエッジルータ (CE ルータ) がルートをサービスプロバイダのエッジルータ (PE ルータ) に送信する「ピアリングモデル」を使用します。Border Gateway Protocol (BGP) [BGP, BGP-MP] は、サービスプロバイダが、特定の VPN に接続されている PE ルータ間でその VPN のルートを交換するために使用されます。これは、2 つの VPN が重複するアドレス空間を持っていても、異なる VPN からのルートが明確に区別され、分離されたままになるように行われます。PE ルータは、特定の VPN 内の他の CE ルータからのルートを、その VPN 内の CE ルータに配布します。CE ルータ同士はピアリングしないため、VPN のルーティングアルゴリズムから見える「オーバーレイ」はありません。「IP VPN」という用語における「IP」は、PE が CE から IP データグラムを受け取り、その IP ヘッダを検査し、それに応じてルーティングすることを示しています。

VPN 内の各ルートには、Multiprotocol Label Switching (マルチプロトコルラベルスイッチング, MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] ラベルが割り当てられます。BGP が VPN ルートを配布するとき、そのルートの MPLS ラベルも配布します。顧客のデータパケットがサービスプロバイダのバックボーンを通過する前に、パケットの宛先アドレスに最も一致する顧客の VPN ルートに対応する MPLS ラベルでカプセル化されます。この MPLS パケットはさらにカプセル化されます (たとえば、別の MPLS ラベル、または IP や Generic Routing Encapsulation (総称ルーティングカプセル化, GRE) トンネルヘッダ [MPLS-in-IP-GRE] を使用)。これにより、バックボーンを介して正しい PE ルータまでトンネリングされます。したがって、バックボーンコアルータは VPN ルートを知る必要がありません。

この方法の主な目的は、クライアントが、契約関係にある 1 つ以上のサービスプロバイダから IP バックボーンサービスを取得する状況をサポートすることです。クライアントは、企業、エクストラネットを必要とする企業のグループ、インターネットサービスプロバイダ、アプリケーションサービスプロバイダ、同じ方法を使用して独自の顧客に VPN を提供する別の VPN サービスプロバイダなどである可能性があります。この方法により、クライアントがバックボーンサービスを使用することは非常に簡単になります。また、サービスプロバイダにとっては非常にスケーラブルで柔軟であり、サービスプロバイダが付加価値を追加することを可能にします。

1.1. Virtual Private Networks (仮想プライベートネットワーク)

共通のネットワーク (これを「バックボーン」と呼びます) に接続されている「サイト」のセットを考えます。このセットのいくつかのサブセットを作成し、次のルールを課すポリシーを適用します: 2 つのサイトは、それらが少なくとも 1 つのサブセットに含まれている場合にのみ、このバックボーンを介して IP 接続を持つことができます。

これらのサブセットが仮想プライベートネットワーク (VPN) です。2 つのサイトは、両方のサイトを含む VPN がある場合にのみ、共通のバックボーン上で IP 接続を持ちます。共通の VPN を持たない 2 つのサイトは、そのバックボーン上で接続性を持ちません。

VPN 内のすべてのサイトが同じ企業によって所有されている場合、その VPN は企業の「イントラネット (intranet)」と見なすことができます。VPN 内のさまざまなサイトが異なる企業によって所有されている場合、その VPN は「エクストラネット (extranet)」と見なすことができます。1 つのサイトは複数の VPN に存在することができます。たとえば、イントラネットといくつかのエクストラネットになどです。一般に、用語「VPN」を使用する場合、イントラネットとエクストラネットを区別しません。

サイトの所有者を「顧客」と呼びます。バックボーンの所有者/運用者を「サービスプロバイダ」 (SP) と呼びます。顧客は SP から「VPN サービス」を取得します。

顧客は、単一の企業、企業のグループ、インターネットサービスプロバイダ、アプリケーションサービスプロバイダ、同種の VPN サービスを独自の顧客に提供する別の SP などである可能性があります。

特定のサイトの集合が VPN であるかどうかを決定するポリシーは、顧客のポリシーです。一部の顧客は、SP がこれらのポリシーの実装に全責任を負うことを望んでいます。他の顧客は、これらのポリシーの実装に対する責任を SP と共有したいと考えるかもしれません。このドキュメントでは、これらのポリシーを実装するために使用できるメカニズムを指定します。私たちが説明するメカニズムは十分に一般的であり、これらのポリシーを SP 単独で実装することも、VPN 顧客と SP が共同で実装することも可能です。ただし、議論の大部分は前者に焦点を当てています。

このドキュメントで説明するメカニズムは、幅広いポリシーの実装を可能にします。たとえば、特定の VPN 内で、各サイトが他のすべてのサイトへの直接ルートを持つことを許可できます (「フルメッシュ」)。あるいは、特定のサイト間のトラフィックが第 3 のサイトを経由してルーティングされるように強制することもできます。これは、たとえば、あるサイト間のトラフィックが第 3 のサイトにあるファイアウォールを通過することを望む場合に役立ちます。

このドキュメントでは、顧客が SP または VPN サービスを提供するために協力することに同意した SP のセットから VPN サービスを明示的に購入する場合に議論を限定します。つまり、顧客は SP から単にインターネットアクセスを購入しているだけでなく、VPN トラフィックは相互接続された SP ネットワークのランダムなコレクションを通過しません。

また、バックボーンが顧客に IP サービスを提供する場合に議論を限定します。フレームリレー、Asynchronous Transfer Mode (非同期転送モード, ATM)、イーサネット、High Level Data Link Control (ハイレベルデータリンク制御手順, HDLC)、または Point-to-Point Protocol (ポイントツーポイントプロトコル, PPP) などのレイヤ 2 サービスではありません。顧客は、これらの (またはその他の) レイヤ 2 サービスのいずれかによってバックボーンに接続できますが、レイヤ 2 サービスはバックボーンの「エッジ」で終了し、そこで顧客の IP データグラムはレイヤ 2 カプセル化から取り出されます。

このはじめにの残りの部分では、VPN が持つべきいくつかのプロパティを指定します。このドキュメントの残りの部分では、これらすべてのプロパティを持つ VPN モデルを提供するために展開できる一連のメカニズムを指定します。このセクションでは、このドキュメントの残りの部分で使用されるいくつかの技術用語も紹介します。

1.2. Customer Edge and Provider Edge (カスタマーエッジとプロバイダエッジ)

ルータは、さまざまな方法で相互に接続したり、エンドシステムに接続したりできます: PPP 接続、ATM 仮想回線 (VC)、フレームリレー VC、イーサネットインターフェース、イーサネットインターフェース上の Virtual Local Area Networks (仮想 LAN, VLAN)、GRE トンネル、Layer 2 Tunneling Protocol (レイヤ 2 トンネリングプロトコル, L2TP) トンネル、IPsec トンネルなどです。「アタッチメント回線 (attachment circuit)」という用語を使用して、ルータへの接続手段を指します。アタッチメント回線は、一般に「データリンク」と見なされる種類の接続である場合もあれば、何らかのトンネルである場合もあります。重要なのは、2 つのデバイスがアタッチメント回線を介してネットワーク層のピアになることができるということです。

各 VPN サイトには、1 つ以上の Customer Edge (カスタマーエッジ, CE) デバイスが含まれている必要があります。各 CE デバイスは、何らかのアタッチメント回線を介して 1 つ以上の Provider Edge (プロバイダエッジ, PE) ルータに接続されます。

CE デバイスに接続されていない SP ネットワーク内のルータは、「P ルータ」と呼ばれます。

CE デバイスは、ホストまたはルータにすることができます。典型的なケースでは、サイトには 1 つ以上のルータが含まれており、そのうちのいくつかは PE ルータに接続されています。PE ルータに接続するサイトルータは CE デバイス、または「CE ルータ」です。ただし、非ルーティングホストが PE ルータに直接接続することを妨げるものは何もありません。その場合、そのホストは CE デバイスです。

PE ルータに物理的に接続されているのがレイヤ 2 スイッチである場合があります。その場合、レイヤ 2 スイッチは CE デバイスとは言いません。むしろ、CE デバイスは、レイヤ 2 スイッチを介して PE ルータと通信するホストおよびルータです。レイヤ 2 インフラストラクチャは透過的です。レイヤ 2 インフラストラクチャがマルチポイントサービスを提供する場合、複数の CE デバイスが同じアタッチメント回線を介して PE ルータに接続できます。

CE デバイスは、論理的には顧客 VPN の一部です。PE および P ルータは、論理的には SP ネットワークの一部です。

データパケットが CE から PE に移動するときに通過するアタッチメント回線は、そのパケットの「入力アタッチメント回線」と呼ばれ、その PE はパケットの「入力 PE」と呼ばれます。データパケットが PE から CE に移動するときに通過するアタッチメント回線は、そのパケットの「出力アタッチメント回線」と呼ばれ、その PE はパケットの「出力 PE」と呼ばれます。

PE ルータが特定の VPN サイトに属する CE デバイスに接続している場合、その PE ルータはその VPN に接続されていると言います。同様に、PE ルータが特定のサイトに属する CE デバイスに接続している場合、その PE ルータはそのサイトに接続されていると言います。

CE デバイスがルータである場合、それは接続されている PE のルーティングピアですが、他のサイトの CE ルータのルーティングピアではありません。異なるサイトのルータは、ルーティング情報を直接交換しません。実際、それらは互いを知っている必要さえありません。したがって、顧客には管理すべきバックボーンや「仮想バックボーン」がなく、サイト間ルーティングの問題に対処する必要もありません。言い換えれば、このドキュメントで説明するスキームでは、VPN は SP ネットワーク上の「オーバーレイ」ではありません。

エッジデバイスの管理に関して、SP とその顧客の間には明確な管理境界が維持されています。顧客は管理目的で PE または P ルータにアクセスする必要はなく、SP は管理目的で CE デバイスにアクセスする必要もありません。

1.3. VPNs with Overlapping Address Spaces (重複するアドレス空間を持つ VPN)

2 つの VPN に共通のサイトがない場合、それらは重複するアドレス空間を持っている可能性があります。つまり、あるアドレスが VPN V1 ではシステム S1 のアドレスとして使用され、VPN V2 ではまったく異なるシステム S2 のアドレスとして使用される可能性があります。これは、各 VPN が RFC 1918 プライベートアドレス空間を使用する場合によくある状況です。もちろん、各 VPN 内では、各アドレスは一意でなければなりません。

共通のサイトを持つ 2 つの VPN であっても、そのようなアドレスを持つシステムが共通サイト内のシステムと通信する必要がない限り、重複するアドレス空間を持つことができます。

1.4. VPNs with Different Routes to the Same System (同じシステムへの異なるルートを持つ VPN)

1 つのサイトが複数の VPN に存在する可能性がありますが、必ずしもすべての VPN でそのサイトの特定のシステムへのルートが同じである必要はありません。たとえば、サイト A、B、C で構成されるイントラネットと、A、B、C、および「外部」サイト D で構成されるエクストラネットがあるとします。サイト A にサーバーがあり、B、C、または D からのクライアントがサーバーを使用できるようにしたいとします。また、サイト B にファイアウォールがあるとします。サイト D からサーバーへのすべてのトラフィックがファイアウォールを通過するようにして、エクストラネットトラフィックにアクセス制御を適用できるようにしたいとします。ただし、C からのトラフィックはイントラネットトラフィックであるため、サーバーへ向かう途中でファイアウォールを通過させたくありません。

サーバーへの 2 つのルートを設定できます。1 つのルートはサイト B と C で使用され、トラフィックを直接サイト A に運びます。2 つ目のルートはサイト D で使用され、トラフィックをサイト B のファイアウォールに運びます。ファイアウォールがトラフィックの通過を許可する場合、その後はサイト B からのトラフィックのように見え、サイト A へのルートに従います。

1.5. SP Backbone Routers (SP バックボーンルータ)

SP のバックボーンは、PE ルータと、CE デバイスに接続されていない他のルータ (「P ルータ」) で構成されます。

SP バックボーン内のすべてのルータが、SP がサポートするすべての VPN のルーティング情報を維持しなければならない場合、深刻なスケーラビリティの問題が発生します。サポート可能なサイトの数は、単一のルータが保持できるルーティング情報の量によって制限されます。したがって、特定の VPN に関するルーティング情報は、その VPN に接続されている PE ルータにのみ存在することが重要です。特に、P ルータは VPN ごとのルーティング情報を一切持つ必要がありません。(マルチキャストルーティングを検討する場合、この条件は少し緩和する必要があるかもしれません。これについてはここでは詳しく説明しませんが、[VPN-MCAST] で検討されています。)

したがって、VPN 所有者が管理するバックボーンまたは「仮想バックボーン」がないのと同様に、SP 自体も各 VPN に個別のバックボーンまたは「仮想バックボーン」を管理しません。バックボーン内のサイト間ルーティングは最適であり (VPN を形成するために使用されるポリシーの制約内で)、トンネルの人工的な「仮想トポロジ」によって制約されません。

セクション 10 では、バックボーンが複数のサービスプロバイダにまたがる場合に発生するいくつかの特別な問題について説明します。

1.6. Security (セキュリティ)

ここで説明するような VPN は、暗号化セキュリティ対策を使用していなくても、レイヤ 2 バックボーン (フレームリレーなど) を使用して得られるのと同等のセキュリティレベルを提供することを目的としています。つまり、設定ミスや意図的な VPN 間の相互接続がない限り、ある VPN 内のシステムが別の VPN 内のシステムへのアクセス権を取得することは不可能です。もちろん、ここで説明する方法自体は、プライバシーのためにデータを暗号化したり、データが転送中に改ざんされたかどうかを判断する方法を提供したりするものではありません。これらの機能が必要な場合は、さらに暗号化対策を適用する必要があります (たとえば、[MPLS/BGP-IPsec] を参照)。セキュリティについては、セクション 13 で詳しく説明します。