BGP／MPLS VPN

Network Working Group
RFC： 2547
分類：情報提供
E. Rosen
Y. Rekhter
Cisco Systems, Inc.
1999 年 3 月
BGP／MPLS VPN
このメモのステータス
このメモはインターネット業界に対する情報提供であり、いかなるインターネット標準も規定し
ない。このメモの配布は自由である。
著作権表示
c The Internet Society (1999). All Rights Reserved.
Copyright °
概要
このドキュメントは、IP バックボーンを持つサービスプロバイダが顧客に VPN（仮想プライ
ベートネットワーク）を提供するための手法について述べている。MPLS（マルチプロトコルラベ
ルスイッチング）はバックボーン上でのパケット転送に使用され、BGP（ボーダゲートウェイプ
ロトコル）はバックボーン上での経路配布に使用される。この手法の第 1 の目標は、企業ネット
ワークに対して IP バックボーンのアウトソーシングサービスをサポートすることである。この手
法は、企業にとって単純で、サービスプロバイダにとって規模拡張性と柔軟性を保つように行い、
一方でサービスプロバイダが付加価値を付けられるようにする。この技術を使用して、その VPN
自体が IP サービスを顧客に提供するような VPN を提供することもできる。
目次
1
序論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1
1.2
仮想プライベートネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
1.3
1.4
アドレス空間が重なる VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
同一システムへの異なる経路を持つ VPN
. . . . . . . . . . . . . . . . . . . . . .
4
4
1.5
1.6
PE における複数の転送テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . .
SP バックボーンルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
1.7
2
セキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
サイトと CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
3
PE におけるサイト別転送テーブル . . . . . . . . . . . . . . . . . . . . . . . . . .
6
エッジ装置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rosen & Rekhter
情報提供
［Page 1］
RFC 2547
3.1
4
4.1
4.2
4.2.1
4.2.2
BGP／MPLS VPN
1999 年 3 月
仮想サイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BGP による VPN 経路配布 . .
VPN-IPv4 アドレスファミリー
経路配布の制御 . . . . . . . . .
ターゲット VPN 属性 . . . . .
BGP による PE 間の経路配布 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.2.3
4.2.4
5
6
7
8
8.1
8.2
9
PE が CE から経路を学ぶ方法 . . . . . . . . .
CE が PE から経路を学ぶ方法 . . . . . . . . .
CE が MPLS をサポートする場合どうなるか
仮想サイト . . . . . . . . . . . . . . . . . . .
ISP VPN のスタブ VPN としての表現 . . . .
セキュリティ . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
12
14
15
15
15
15
9.1
9.2
10
11
12
13
14
15
16
17
CE ルータ間のポイントツーポイントセキュリティトンネル
マルチパーティセキュリティアソシエーション . . . . . . .
サービス品質 . . . . . . . . . . . . . . . . . . . . . . . . . .
規模拡張性 . . . . . . . . . . . . . . . . . . . . . . . . . . .
知的財産に関する配慮 . . . . . . . . . . . . . . . . . . . . .
セキュリティへの配慮 . . . . . . . . . . . . . . . . . . . . .
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
著者連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . .
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
著作権表明全文 . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
18
18
18
18
18
19
1.
1.1.
起源 VPN 属性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
7
7
8
8
9
ターゲット属性と起源属性を使用した VPN の構築 . . . . . . . . . . . . . . . . .
バックボーン内の転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
序論
仮想プライベートネットワーク
「バックボーン」と呼ぶことができる共有ネットワークに接続された「サイト」の集合を考え
る。この集合からいくつかの部分集合を作るために、あるポリシーを適用しよう。そして、2 つの
サイトがこの部分集合の 1 つ以上に含まれるときにだけバックボーン上で IP の相互接続性を持つ
ことができる、という規則を課してみよう。
我々が作ったこの部分集合は「仮想プライベートネットワーク」（VPN）である。2 つのサイト
を含むような VPN がある場合にのみ、それらのサイトは共有バックボーン上で IP の相互接続性
を持つ。また、2 つのサイトが共通の VPN を持たない場合は、そのバックボーン上で接続性を持
たない。
VPN 内の全サイトが同じ企業のものである場合、VPN は企業「イントラネット」である。ま
た、VPN 内の各サイトが異なる企業のものである場合、VPN は「エクストラネット」である。1
つのサイトは 2 つ以上の VPN に所属することもできる。例えば、イントラネットといくつかのエ
クストラネットに所属できる。一般的に、VPN という用語を使うときイントラネットとエクスト
ラネットの区別をしない。
Rosen & Rekhter
情報提供
［Page 2］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
バックボーンを 1 社以上のサービスプロバイダ（SP）が所有し、運用しているケースを考えた
い。サイトの所有者は SP の「顧客」である。サイトの集まりが VPN となるかどうかを決定する
ポリシーは顧客のポリシーである。一部の顧客はこのポリシーの実現を完全に SP 任せとしたいだ
ろう。別の顧客は、自らの手でこのポリシーを実現したい、あるいはこのポリシーの実現を SP と
分担したいと思うかもしれない。このドキュメントでは主に、このポリシーを実現するために使
用可能なメカニズムについて議論していく。我々が述べるメカニズムは十分一般的で、SP 単独で
も VPN 顧客と SP の共同でもこのポリシーの実現は可能である。しかし、議論の大部分は前者の
ケースに焦点を当てる。
このドキュメントで議論するメカニズムは、広範囲にわたるポリシーの実現を可能にする。例
えば、ある VPN の中で、全てのサイトが他の全てのサイトと直接の経路を持つようにもできるし
（「完全メッシュ」）、ある組み合わせのサイト同士はお互いへの直接の経路を持てないよう制限す
ることもできる（「部分メッシュ」）。
このドキュメントでは、共有バックボーンで IP サービスを提供するケースに特に関心がある。
我々は、契約関係の維持によって、企業がサービスプロバイダに、場合によっては複数のサービス
プロバイダにバックボーンをアウトソーシングするようなケースに一番関心がある。公衆インター
ネット上で VPN を提供することに関心は無い。
この序論の残りで、VPN が持つべきいくつかの特性を規定する。このドキュメントの以降の部
分で、このような特性を全て持っている VPN モデルのアウトラインを描く。このドキュメントの
VPN モデルは［4］で書かれているフレームワークの例となるものである。
1.2.
エッジ装置
各サイトに 1 つ以上の顧客エッジ（CE）装置があり、そのそれぞれがある種のデータリンク（例
えば、PPP、ATM、イーサネット、フレームリレー、GRE トンネルなど）を用いて 1 つ以上のプ
ロバイダエッジ（PE）ルータに接続されている。
あるサイトに 1 つホストがあるとき、そのホストが CE 装置でもよい。あるサイトに 1 つサブ
ネットがあるとき、その CE 装置はスイッチでもよい。一般的に CE 装置はルータであると考えて
良い。我々はこれを CE ルータと呼ぶ。
PE ルータがある VPN に属する CE 装置に接続されているとき、PE ルータはその VPN に接続
されていると言うことにする。同様に、PE ルータがあるサイトの CE 装置に接続されているとき、
そのサイトに接続されていると言うことにする。
CE 装置がルータであるとき、接続している PE のルーティングピアではあるが、他サイトの CE
ルータのルーティングピアではない。異なるサイトのルータ同士は、お互いに直接ルーティング情
報を交換することは無い。実際、お互いを知る必要すら全くない（セキュリティのために必要な場
合を除く、第 9 章参照）。その結果、非常に大規模な VPN（すなわち、非常に多数のサイトを持つ
VPN）のサポートが容易になり、個々のサイトのルーティング設計は非常に単純になる。
SP と顧客の管理上の境界をはっきりと守ることは大事である（［4］参照）。PE ルータと P ルー
タは SP 単独で管理されるべきで、SP の顧客がそれに対していかなる操作手段も持つべきでない。
また、CE 装置は（顧客が SP と外部運用サービスを契約していない限り）顧客単独で管理される
べきである。
Rosen & Rekhter
情報提供
［Page 3］
RFC 2547
1.3.
BGP／MPLS VPN
1999 年 3 月
アドレス空間が重なる VPN
2 つの交わらない VPN 同士（すなわち共通のサイトを持たない VPN 同士）は、アドレス空間
が重なっても構わない。同じアドレスを異なる VPN の異なるシステムに再利用可能である。エン
ドシステムが所属 VPN の範囲内でユニークなアドレスを持っている限り、そのエンドシステム自
身は VPN について何も知る必要が無い。
このモデルにおいて、VPN 所有者は管理するバックボーンを持っておらず、
「仮想バックボーン」
でさえも持っていない。SP は、各 VPN に対する個別のバックボーンも、
「仮想バックボーン」も
管理する必要が無い。
（VPN を作るのに使用するポリシーの制約内では）バックボーンにおけるサ
イト対サイトのルーティングが最も望ましく、このルーティングがトンネルの不自然な「仮想トポ
ロジー」で制限されることは全く無い。
1.4.
同一システムへの異なる経路を持つ VPN
サイトが複数の 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.
PE における複数の転送テーブル
各 PE ルータは、多くの別個の転送テーブルを保持する必要がある。この PE に接続されている
全てのサイトが、これらの転送テーブルの 1 つに対応付けられる必要がある。パケットをあるサイ
トから受信したときは、そのサイトに関する転送テーブルを調べ、どのようにパケットをルーティ
ングするかを決定する。あるサイト S に関する転送テーブルは、S と共通の VPN を 1 つ以上持つ
他サイトへの経路しか持たない。これによって、共通の VPN を持たないサイト同士が通信できな
いようになり、共通のサイトを持たない 2 つの VPN がお互いに重なるアドレス空間を使用できる
ようになる。
1.6.
SP バックボーンルータ
SP のバックボーンは PE ルータと、CE 装置に接続されていないそれ以外のルータ（P ルータ）
で構成される。
SP のバックボーンの全ルータが、SP がサポートする全 VPN のルーティング情報を持つ必要が
あるとすれば、このモデルは困難な規模拡張性の問題をはらむことになる。1 つのルータが保持で
Rosen & Rekhter
情報提供
［Page 4］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
きるルーティング情報の量によってサポート可能なサイトの数は制限されるだろう。したがって、
ある VPN に関するルーティング情報はその VPN が接続されている PE ルータにだけ存在すべき
だという要求は重要である。特に、P ルータはいかなる VPN 単位のルーティング情報も全く持た
なくてよいようにすべきである。
VPN が複数のサービスプロバイダにわたることもある。もっとも、PE ルータ間のパスが SP
ネットワーク間の境界を跨ぐような場合、それをプライベートピアリング協定で行うとする。ここ
では、2 つのプロバイダ間に相互信頼が存在するとする。特にそれぞれのプロバイダは、相手が正
しいルーティング情報だけを渡している、そして信頼できる送信元でラベルを付けられた（MPLS
［9］の言い方で）ラベル付きパケットだけを渡している、ということを信用しなければならない。
また、ラベルスイッチパスがサービスプロバイダ間の境界を跨ぐことが可能であることも仮定する。
1.7.
セキュリティ
VPN モデルは、暗号セキュリティの手段を使わないときでも、レベル 2 バックボーン（例えば
フレームリレー）使用時に得られるものと同等のセキュリティのレベルを提供すべきである。すな
わち、設定ミスをしたり意図的に異なる VPN を相互接続したりしない限り、ある VPN のシステ
ムが別の VPN のシステムへのアクセス手段を得ることはあるべきではない。
また、標準的なセキュリティの手段も使用可能であるべきである。
2.
サイトと CE
あるバックボーンネットワークから見て、IP システム同士がお互いに IP 相互接続性を持ち、そ
のシステム間の通信はバックボーンを使用せずに行われるなら、そのシステムの集合はサイトを
構成していると言える。一般的に、サイトは地理的に近いシステムの集合からなっているだろう。
しかし、それがいつも正しいとは限らない。専用線で結ばれた地理上の 2 つの拠点で OSPF が動
作している場合、これらは 1 つのサイトとなるだろう。なぜなら、2 つの拠点間の通信ではバック
ボーンが使用されないからである。
1 つの CE 装置がいつも 1 つのサイトにあると考えられる（後で見ていくように、サイトが複数
の「仮想サイト」からなっていることもあるが）。ただし、1 つのサイトが複数の VPN に所属する
こともできる。
1 つの PE ルータは、多数の異なるサイトに存在する CE 装置に接続してもよい。それらの CE
装置が同一の VPN なのか、別々の VPN なのかは問わない。信頼性のために、1 つの CE 装置が
複数の PE ルータと接続してもよい。それらの PE ルータは同一のサービスプロバイダかもしれな
いし、異なるサービスプロバイダかもしれない。CE 装置がルータである場合、PE ルータと CE
ルータはお互いにルータ隣接関係と見られるだろう。
相互接続の基本的な単位はサイトであるが、ここで述べるアーキテクチャは相互接続性の制御で
より高い粒度を許す。例えば、あるサイトの特定のシステムがイントラネットのメンバーとなるこ
とも、1 つ以上のエクストラネットのメンバーとなることも可能で、それに対して同じサイトの他
のシステムがイントラネットのメンバーにだけなれるよう制限することも可能である。
Rosen & Rekhter
情報提供
［Page 5］
RFC 2547
3.
BGP／MPLS VPN
1999 年 3 月
PE におけるサイト別転送テーブル
各 PE ルータは 1 つ以上の「サイト別転送テーブル」を持つ。PE に接続された全てのサイトは、
このテーブルの中のどれか 1 つに関連付けられている。あるパケットの宛先 IP アドレスがあるサ
イト別転送テーブル内でルックアップされるのは、そのテーブルに関連付けられたサイトからパ
ケットが直接到着した場合に限られる。
では、どのようにサイト別転送テーブルを内部に持っているのだろうか。
例として、PE1、PE2、PE3 が 3 つの PE ルータであるとし、CE1、CE2、CE3 が 3 つの CE
ルータであるとする。PE1 が、CE1 のサイトに到達可能な経路を CE1 から学んだと仮定する。PE2
と PE3 がそれぞれ CE2、CE3 に接続され、CE1、CE2、CE3 を含んだある VPN V が存在する
場合、PE1 は BGP を使用して CE1 から学んだ経路を PE2、PE3 に配布する。PE2、PE3 はこれ
らの経路を使用して、CE2 および CE3 のサイトに関するそれぞれの転送テーブルを内部に持つ。
VPN V に属さないサイトからの経路は、これらの転送テーブルに現れない。これは、CE2 や CE3
からのパケットが VPN V に属さないサイトに送信できないことを意味する。
あるサイトが複数の VPN に属している場合、そのサイトに関する転送テーブルはそのサイトが
メンバーである全ての VPN からの経路を持つことができる。
一般的に PE は、サイトと複数の接続を持つ場合でも、サイトごとに転送テーブルを 1 つだけ持
つ。複数のサイトで全く同じ経路の集合を使うつもりなら、それらのサイトが同一の転送テーブル
を共有することも可能である。
PE ルータがある直接接続のサイトからパケットを受信したが、そのパケットの宛先アドレスが
そのサイトに関する転送テーブルのどのエントリーにも一致しないときを考える。SP がインター
ネットアクセスをそのサイトに提供していない場合、そのパケットは配送不能として廃棄される。
SP がインターネットアクセスをそのサイトに提供している場合、PE のインターネット転送テー
ブルが調べられるだろう。つまり普通は、インターネットアクセスが提供されていても、インター
ネットからの経路を含む必要がある転送テーブルは PE ごとに 1 つだけである。
1 つの VPN が他の VPN から正しく分離されるようにするために、バックボーン内のルータが
隣接する非バックボーン装置からラベル付きパケットを受け入れないことが重要である。ただし、
（a）ラベルスタックの最上位ラベルがバックボーンルータが非バックボーン装置に実際に配布され
ている場合、
（b）そのラベルを使用すると、パケットがバックボーンから出てから、スタック中の
下位のラベルや IP ヘッダが検査されるようバックボーンルータが決定できる場合、を除く。これ
らの制限は、パケットが属していない VPN に入ってしまうことを防ぐために必要である。
PE 内のサイト別転送テーブルは、PE と直接接続しているサイトから到着したパケットにしか
使われない。SP バックボーンに属する別のルータから到着したパケットをルーティングする際に
は使われない。その結果、同じシステムへの異なる経路が複数存在することもあり、パケットが辿
る経路は、パケットがバックボーンに入ってくるサイトがどれかよって決まる。例えば、あるシス
テムに対してエクストラネットからのパケットが通る経路があり（ここではこの経路がファイア
ウォールへ向かっている）、同じシステムに対して（すでにファイアウォールを通過したパケット
を含む）イントラネットからのパケットが通る別の経路があるということもあり得る。
3.1.
仮想サイト
顧客によってサイトがいくつかの仮想サイトに分割されている場合がある。これはおそらく VLAN
を使用している。それぞれの仮想サイトは、異なる VPN のメンバーであってよい。そのとき PE
Rosen & Rekhter
情報提供
［Page 6］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
は各仮想サイトごとに別々の転送テーブルを持つ必要がある。例えば、CE が VLAN をサポート
していて、各 VLAN を異なる VPN に対応させたい場合、CE と PE の間で送信されるパケットは
そのサイトの VLAN カプセル化フレームに格納できる。これは、パケットをそれぞれの仮想サイ
トに割り当てるために、パケットを受信したインタフェースと併せて PE で使用される。
あるいは、インタフェースを複数の「サブインタフェース」に分け（特にフレームリレーや ATM
の場合）、到着したサブインタフェースに基づいてパケットを VPN に割り当てることもできる。
また、単純に仮想サイトごとに異なるインタフェースを使用することもできる。いずれにしても、
複数の仮想サイトがあろうと、CE ルータがサイトごとに 1 つだけ必要であるのは変わらない。も
ちろん、必要に応じて、各仮想サイトごとに異なる CE ルータを使用することも可能である。
このような場合は常に、どのトラフィックがどの VPN に入るかを制御するためのメカニズムは、
ポリシーと同様、顧客の責任となる。
あるホストを複数の仮想サイトに所属させたいなら、それぞれのパケットについて、どの仮想サ
イトとパケットを関連付けるか、そのホストが決めなければならない。これを行うには、例えば、
異なる VLAN 上にある異なる仮想サイトからのパケットを、異なるネットワークインタフェース
へ送信すればよい。
これらの方式は CE が MPLS をサポートしている必要はない。第 8 節では、CE が MPLS をサ
ポートしているとき、どのようにして複数の仮想サイトをサポートできるかを簡単に説明している。
4.
BGP による VPN 経路配布
PE ルータは BGP を使用して、VPN 経路をお互いに配布している（より正確に言えば、VPN
経路がお互いに配布されるようにしている）。
BGP スピーカは、あるアドレスプレフィックスへの経路を 1 つだけしかインストールおよび配
布できない。それでも我々は、各 VPN が固有のアドレス空間を持てるようにする。つまり、同一
のアドレスが複数の VPN で使用可能であることを意味する。ここで、それぞれの VPN でこのア
ドレスは異なるシステムを表す。要するに、BGP が 1 つの IP アドレスプレフィックスに対する複
数の経路をインストールおよび配布できるようにする必要があるということである。さらに、どの
サイトがどの経路を使用できるかを決めるために、ポリシーを使用できるようにしなければならな
い。もしこのような経路が複数、BGP でインストールされている場合、個々のサイト別転送テー
ブルには、そのうち 1 つだけが現れるようにしなければならない。
我々は、次に規定する新しいアドレスファミリーを使用してこの目標を達成する。
4.1.
VPN-IPv4 アドレスファミリー
BGP マルチプロトコル拡張［3］によって、BGP は複数の「アドレスファミリー」から経路を運
ぶことが可能になった。我々は「VPN-IPv4 アドレスファミリー」の概念を導入する。VPN-IPv4
アドレスは 12 バイトの数で、8 バイトの「ルート識別子（RD）」から始まり、4 バイトの IPv4 アド
レスで終わる。2 つの VPN が同じ IPv4 アドレスプレフィックスを使用する場合、PE はこれらを
ユニークな VPN-IPv4 アドレスプレフィックスに変換する。これは、同じアドレスが 2 つの VPN
で使用されているとき、そのアドレスに対して各 VPN に 1 つずつ計 2 つの完全に異なる経路がイ
ンストール可能であることを保証する。
RD 自身は意味を持っていない。経路の起源についての情報や経路が配布されるべき VPN につ
Rosen & Rekhter
情報提供
［Page 7］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
いての情報は何ら含んでいない。RD の目的は単に、共通の IPv4 アドレスプレフィックスへの複
数の経路を作成可能にすることだけである。どこに経路を再配布するかは、別の手段を使用する
（第 4.2 節を参照）。
RD を使用して、全く同じシステムに対して複数の異なる経路を作成することもできる。第 3 節で
は、あるサーバへの経路がイントラネットトラフィックとエクストラネットトラフィックとで異なっ
ていなければならないような例を挙げた。これは、IPv4 部が同じで RD が異なる 2 つの VPN-IPv4
経路を作成することで達成できる。これによって、BGP は同一のシステムに対して複数の異なる
経路をインストール可能になり、ポリシーで（第 4.2.3 節参照）どのパケットがどの経路を使用す
るかを決定できる。
全てのサービスプロバイダが、他のサービスプロバイダの割当てた RD と衝突しない独自の「番
号空間」を管理できる（すなわち、独自の RD 割当ができる）ように、RD の構成が決められてい
る。RD は、2 バイトのタイプフィールド、管理者フィールド、割当番号フィールドで構成されて
いる。タイプフィールドの値によって、他の 2 つのフィールドの長さと管理者フィールドの意味が
決まる。管理者フィールドで番号割当組織が分かる。そして、割当番号フィールドは、特定用途の
ためにその組織が割当てた番号を持っている。例えば、自律システム番号（ASN）を RD の管理
者フィールドに入れ、IANA によってその ASN が与えられている SP が割当てた番号を（4 バイト
の）番号フィールドに入れることもできる。RD がこの構成を与えられているのは、VPN バック
ボーンを提供している SP が必要なときにいつもユニークな RD を作れるためである。しかし、こ
の構成は何ら意味を持っていない。BGP がこのような 2 つのアドレスプレフィックス比較すると
きは、この構成を完全に無視する。
VPN-IPv4 アドレスの管理者サブフィールドと割当番号サブフィールドが両方とも全て 0 であ
る場合、VPN-IPv4 アドレスは、相当するグローバルにユニークな IPv4 アドレスと全く同じ意味
を持つと見なされる。特に、この VPN-IPv4 アドレスと相当するグローバルにユニークな IPv4 ア
ドレスは、BGP で等価に扱われるだろう。それ以外はいつも、VPN-IPv4 アドレスと相当するグ
ローバルにユニークな IPv4 アドレスは、BGP で違うものとして扱われるだろう。
サイト別フォワーディングテーブルは、全ての IPv4 アドレスプレフィックスに対して VPN-IPv4
の経路を各 1 つずつ持っている。パケットの宛先アドレスが VPN-IPv4 経路と一致するとき、IPv4
部分だけが実際に一致している。
PE は、CE に向かう経路を RD と関連付けるよう設定する必要がある。同じ CE に向かう全て
の経路を同じ RD に関連付けるよう、PE を設定できるし、あるいは、同じ CE に向かう経路でも、
異なる経路なら異なる RD に関連付けることができる。
4.2.
経路配布の制御
この節では、VPN-IPv4 経路の配布を制御する方法について議論する。
4.2.1.
ターゲット VPN 属性
全てのサイト別転送テーブルは 1 つ以上の「ターゲット VPN」属性と関連付けられる。
VPN-IPv4 経路が PE ルータによって作成されるとき、1 つ以上の「ターゲット VPN」属性と
関連付けられる。このターゲット VPN は BGP において経路の属性として運ばれる。
あるターゲット VPN T と関連する経路はいずれも、ターゲット VPN T に関する転送テーブル
を持っている全 PE ルータに配布する必要がある。このような経路が PE ルータで受信されたと
Rosen & Rekhter
情報提供
［Page 8］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
き、その経路は、その PE が持つターゲット VPN T に関するサイト別転送テーブルの各々にイ
ンストールされる資格がある（実際にインストールされるかどうかは、BGP の決定処理の結果に
よる）。
本質的に、ターゲット VPN 属性がサイトの集合を識別する。特定のターゲット VPN 属性と経
路とを関連付けることで、その経路を、対応するサイトからの受信トラフィックのルーティングに
使用するサイト別転送テーブルに入れることが許される。
PE ルータがサイト S からの受信経路と結びつけるターゲット VPN の集合がある。そして、別
の PE から受信した経路をサイト S に関する転送テーブルに入れるかを決定するのに PE ルータが
使用するターゲット VPN の集合がある。この 2 つの集合は区別され、同一である必要はない。
ターゲット VPN 属性によって実行される機能は、BGP コミュニティ属性によって実行される
ことと同様である。しかし、後者のフォーマットは 2 バイト分の番号空間しか許可されないため、
不十分である。BGP コミュニティ属性を拡張して、もっと大きい番号空間を提供するのがとても
簡単である。RD で述べたものと同様のフォーマット（第 4.1 節参照）の構成も可能であるべきで、
この場合、タイプフィールドは管理者フィールドの長さを定義し、残りの属性は指定された管理者
の番号空間からの番号となる。
BGP スピーカが 1 つの VPN-IPv4 プレフィックスに対して 2 つの経路を受信したときは、BGP
の経路優先規則に従って 1 つを選択する。
1 つの経路は、RD を 1 つしか持つことができないが、ターゲット VPN なら複数持てることに
注目しよう。BGP で、1 つの経路に複数の属性が付けられるならば、規模拡張性は向上する。こ
れは、経路を複数にする場合と対照的である。複数の経路を作成することで（すなわちより多くの
RD を使用することで）ターゲット VPN 属性をなくすことも可能だが、規模拡張性の面でより不
利になってしまうだろう。
PE は、経路に関連付けるターゲット VPN 属性をどのようにして決めるのだろうか。それには、
いくつかの異なるやり方が可能である。PE は、あるサイトに向かう全経路に 1 つのターゲット
VPN を関連付けることもできる。また PE は、あるサイトに向かう一部の経路に 1 つのターゲッ
ト VPN を関連付け、そして同じサイトに向かう別の経路に別のターゲット VPN を関連付けるこ
ともできる。また、CE ルータは、これらの経路を PE に配布するときに（第 6 節参照）、各経路
に対して 1 つ以上ターゲット VPN を指定できる。最後の方法は、VPN ポリシー実現に使用する
メカニズムの制御を、SP から顧客に転嫁している。この方法を使った場合、PE は自身の設定に
従って許可されないターゲット VPN を全て削除するようにしたり、自身の設定に従ってターゲッ
ト VPN をいくつか追加したりすることが望ましい。
あまり示唆的ではないが、この属性を「VPN ターゲット」属性と呼ぶ代わりに「ルートターゲッ
ト」属性と呼ぶ方が、より正確かもしれない。実際には、経路を使用できるサイトの集合を見分け
るだけで、それが直感的に VPN と呼べるものを構成するサイトかどうかにとらわれない。
4.2.2.
BGP による PE 間の経路配布
VPN の 2 サイトが接続されている PE が同一自律システムにある場合、PE 同士は、その間の
IBGP 接続を用いて VPN-IPv4 経路をお互いに配布することができる。そうする代わりに、各 PE
がルートリフレクタと IBGP 接続を持つこともできる。
VPN の 2 サイトが異なる自律システムにある場合（例えば、異なる SP と接続されているなど）、
PE ルータは IBGP を使用して。VPN-IPv4 経路を自律システム境界ルータ（ASBR）あるいは
ASBR をクライアントとするルートリフレクタに配布する必要がある。そのとき、この ASBR は
Rosen & Rekhter
情報提供
［Page 9］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
EBGP を使用してこの経路をもう 1 つの AS の ASBR に配布する必要がある。これによって、異な
る VPN サイトを異なるサービスプロバイダに接続することが可能になる。しかし、VPN-IPv4 経
路を受けるのは、信頼できる取り決めの 1 つとして、プライベートピアリングポイントでの EBGP
接続だけにするべきである。VPN-IPv4 経路は、公衆インターネットに配布すべきではないし、ま
た公衆インターネットから受け入れるベきでもない。
異なる自律システムに接続されているサイトを持つような VPN が多くある場合、この 2 つの AS
の間にある ASBR が単独で全ての VPN の全ての経路を保持する必要はない。複数の ASBR が存
在し、それぞれが全 VPN のサブセットに対する経路だけを保持するようにすることができる。
PE ルータが VPN-IPv4 経路を BGP で配布するとき、自身が持つアドレスを「BGP ネクスト
ホップ」として使用する。また、MPLS ラベルの割当と配布も行う（本来、PE ルータは VPN-IPv4
経路ではなく、ラベル付き VPN-IPv4 経路を配布する。
［8］参照）。このラベルがスタックの最上
位にある受信パケットを PE が処理するとき、PE はスタックをポップして、経路が向かうサイト
に直接そのパケットを送信する。これは通常、経路を学んだ CE ルータにパケットが送信されるこ
とになる。このラベルはデータリンクのカプセル化も決めることができる。
ほとんどの場合、PE が割当てたラベルによってパケットは CE に直接送信されて、ラベル付き
パケットを受信した PE がパケットの宛先アドレスを転送テーブルでルックアップすることはない
だろう。しかし、転送テーブルを暗黙のうちに示すようなラベルを PE が割り当てることも可能で
ある。この場合、このラベルを持つパケットを受信した PE は、転送テーブルの 1 つでパケットの
宛先アドレスをルックアップするだろう。これは状況によっては非常に便利ではあるが、この文書
ではこれ以上考えない。
この方法で配布される MPLS ラベルは、経路をインストールしたルータとその経路の BGP ネ
クストホップの間にラベルスイッチパスがあるときだけ使用できることに注意する。このラベル
スイッチパスを設定するために使用する手続きについて、我々は何も決めていない。このラベルス
イッチパスは、事前確率を原則として設定するか、ラベルスイッチパスを必要とする経路がインス
トールされたときに設定する。これは、「ベストエフォート」の経路であっても、トラフィックエ
ンジニアリングされた経路であっても構わない。ある PE ルータとある経路の BGP ネクストホッ
プの間には 1 つの LSP があるかもしれないし、複数の LSP かもしれない。複数の場合は、おそら
く異なる QoS 特性を持っているだろう。VPN アーキテクチャでは、ルータと BGP ネクストホッ
プの間に何かラベルスイッチパスが存在することだけでよい。
規模拡張性を向上させるためにルートリフレクタ［2］を使用する際に有用な技術、例えばルー
トリフレクタの階層化などは、全て利用可能である。ルートリフレクタを使用する場合、それぞれ
のルートリフレクタがバックボーンでサポートする全 VPN に対する全 VPN-IPv4 経路を知ってい
る必要は無い。ルートリフレクタを分けて、お互いに通信しないで、それぞれが VPN の全集合の
うちの一部をサポートするようにできる。
PE ルータが、ある経路が持つターゲット VPN と全く接続されていない場合、その経路は受け
取るべきではない。他の PE や、その PE に経路を配布するルートリフレクタは、無用な経路を送
信することを避けるために出力フィルタを適用するのがよい。PE ルータが BGP で経路を受信し
たが、その PE はその経路のターゲット VPN に全く接続されていない場合、PE は、その経路に
対する入力フィルタを適用して、インストールと再配布をしないようにするのが当然だろう。
全く VPN と接続されていないルータ、すなわち P ルータは、VPN-IPv4 経路を一切インストー
ルしてはいけない。
この配布規則によって、1 つのボックスがバックボーン上でサポートされる全ての VPN-IPv4 経
路を知らなければならない、ということはなくなる。その結果、バックボーン上でサポートできる
Rosen & Rekhter
情報提供
［Page 10］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
経路数の合計が 1 つの装置の性能によって制限されたりしなくなる。
4.2.3.
起源 VPN 属性
VPN-IPv4 経路は、オプションで起源 VPN 属性と関連付けることができる。この属性は、サイ
トの集合をユニークに特定し、その集合の中のサイトの 1 つから来ている対応する経路を識別す
る。この属性の典型的な使い方は、その経路の宛先となるサイトを持つ企業を特定することや、そ
のサイトのイントラネットを特定することが可能だろう。しかし、別の使い方も可能である。この
属性は拡張 BGP コミュニティ属性として符号化することができる。
ある経路の送信元を特定しないといけない状況では、この属性を使用しなければならず、RD は
使用しない。以下で述べるように VPN を「構築する」ときにこの属性が使用できる。
あまり示唆的ではないが、この属性を「起源 VPN」属性と呼ぶ代わりに「ルート起源」属性と
呼ぶ方がより正確かもしれない。実際には、経路があるサイトの集合の 1 つから来ていることだけ
を見分けられ、そのサイトの集合が実際に VPN を構成しているかどうかにとらわれない。
4.2.4.
ターゲット属性と起源属性を使用した VPN の構築
ターゲット VPN 属性および起源 VPN 属性を適切に設定することで、様々な VPN を構築する
ことができます。
あるサイトの集合を含む閉域ユーザグループ（CUG）を作成したいとする。これは、CUG を表
すターゲット VPN 属性値を作成することで実施できる。そしてこの値は、CUG の各サイトに対
するサイト別転送テーブルに関連付けられる必要があり、かつ CUG のサイトから学んだ全ての経
路と関連付けられる必要がある。このターゲット VPN 属性を持つ経路は全て再配布され、CUG
のサイトのいずれかに接続されている全 PE ルータに到着している必要がある。
あるいはまた、何らかの理由で「ハブアンドスポーク」型の VPN を作成したいとする。これは、
2 つのターゲット属性値を使用することで実行できる。1 つは「ハブ」を表し、1 つは「スポーク」
を表す。このとき、ハブからの経路がスポークに配布されないようにしながら、スポークからの経
路はハブに配布することができる。
イントラネットとエクストラネットに属しているいくつかのサイトと、イントラネットだけに属
しているいくつかのサイトがあると仮定する。このとき、イントラネットとエクストラネットの両
方の経路があり得て、これらはサイトの全体集合を示すターゲット VPN を持っている。イントラ
ネット経路だけを持つべきサイトは、「不適切」な起源 VPN を持つ全ての経路をフィルタリング
することができる。
この 2 つの属性は高い柔軟性を可能にし、様々なサイトの異なる集合の間でルーティング情報の
配布を制御可能にできる。その結果、これは VPN の構築に高い柔軟性を与えることになる。
5.
バックボーン内の転送
バックボーン内の中間経路が VPN への経路情報を持たない場合、どのようにしてある VPN サ
イトから別の VPN サイトにパケットが転送されるのだろうか。
これは、2 階層のラベルスタックを使った MPLS の手法によって実行される。
PE ルータ（と VPN-IPv4 アドレスを再配布する ASBR）は、自身の/32 アドレスプレフィック
Rosen & Rekhter
情報提供
［Page 11］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
スをバックボーンネットワークの IGP ルーティングテーブルに入れる必要がある。これによって、
バックボーンネットワークの各ノードで、MPLS が各 PE ルータへの経路に対応するラベルを割り
当てることが可能になる（バックボーンにラベルスイッチパスを設定する手続きによっては、/32
アドレスプレフィックスが無くても構わない）。
PE が CE 装置からパケットを受信したとき、そのパケットの宛先アドレスをルックアップする
ためのサイト別転送テーブルが選ばれる。ここでは、一致するものが見つかるものとする。
パケットが同一 PE に接続されている CE 装置宛である場合、そのパケットはその CE 装置に直
接送信される。
パケットが同一 PE に接続されている CE 装置宛でない場合、パケットの「BGP ネクストホッ
プ」と、この BGP ネクストホップがパケットの宛先アドレスに割当てたラベルを見つける。この
ラベルはパケットのラベルスタックにプッシュされ、最下位ラベルとなる。そして PE は BGP ネ
クストホップへの IGP 経路をルックアップし、これによって IGP ネクストホップと、この IGP ネ
クストホップが BGP ネクストホップのアドレスに割当てたラベルが決まる。このラベルはパケッ
トの最上位ラベルとしてプッシュされ、それからこのパケットは IGP ネクストホップに転送される
（しかし、BGP ネクストホップが IGP ネクストホップと同じである場合、2 番目のラベルがプッ
シュされる必要はないかもしれない）。
このとき、MPLS はパケットをバックボーンを通して適切な CE 装置に運ぶことになる。すなわ
ち、P ルータと PE ルータによる全ての転送決定は、このとき MPLS を使って行われ、パケット
の IP ヘッダはパケットが CE 装置に到着するまで再び参照されることは無い。最後の PE ルータ
は、パケットを CE 装置に送信する前に MPLS ラベルスタックから最後のラベルをポップするの
で、CE 装置はオリジナルの IP パケットを見ることになる（なお、CE がラベル付きパケットを受
信したいケースの議論の一部は第 8 章を参照せよ）。
パケットがあるサイトから PE ルータを通してバックボーンに入るとき、このパケットの経路は、
その PE ルータがそのサイトに関連付けた転送テーブルの内容によって決定される。パケットが
バックボーンから出ていく PE ルータの転送テーブルとは関係ない。その結果、同一のシステムに
向かう複数の経路を持つことができ、この場合、パケットに対して選ばれる経路はパケットがバッ
クボーンに入るサイトに基づくことになる。
P ルータから全ての VPN 経路を除去することを可能にしているのは 2 階層のラベル付けであり、
この結果、このモデルの規模拡張性が得られていることに注意する。バックボーンは CE への経路
でさえ持つ必要はなく、PE への経路だけが必要となる。
6.
PE が CE から経路を学ぶ方法
ある VPN に接続された PE ルータは、その VPN のサイトのそれぞれについて、VPN のどのア
ドレスがそれぞれのサイトにあるかを知っている必要がある。
CE 装置がホストまたはスイッチである場合、通常このアドレスの集合をその装置と接続されて
いる PE ルータに設定する。CE 装置がルータである場合、PE ルータがこのアドレスの集合を得
るための方法はいくつかある。
PE は、設定された RD を使用してこのアドレスを VPN-IPv4 アドレスに変換する。そして、PE
はこの VPN-IPv4 経路を BGP への入力として扱う。サイトからの経路がバックボーンの IGP へ
流れ込むことはあり得ない。
正確に言うと、どの PE／CE 経路配布技術が可能であるかは CE が属しているのが「トランジッ
Rosen & Rekhter
情報提供
［Page 12］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
ト VPN」であるかどうかに因る。「トランジット VPN」とは、「第三者」から（すなわち、VPN
内にないルータから）の経路を受信し、その経路を PE ルータに再配布するルータを含むものであ
る。トランジット VPN でない VPN は「スタブ VPN」である。およそ全てのグループ企業ネット
ワーク等を含めて、圧倒的多数の VPN がこの意味での「スタブ」であると思われる。
使用可能な PE／CE 配布技術は次のとおりである。
1. 静的ルーティング（すなわち設定）は使用可能である（おそらくこれはスタブ VPN でしか
役に立たないだろう）。
2. PE ルータと CE ルータが RIP ピアになり、CE は RIP を使用して PE ルータに CE ルータ
のサイトで到達可能なアドレスプレフィックスの集合を教えることができる。RIP を CE で
設定したときは、他のサイトからのアドレスプレフィックス（すなわち、PE ルータから CE
ルータが学んだアドレスプレフィックス）を決して PE に広報しないよう注意しなければな
らない。より正確に言うと次のようになる。PE ルータ PE1 が、VPN-IPv4 経路 R1 を受信
し、その結果 IPv4 経路 R2 を CE に配布した場合、R2 はその CE のサイトから PE ルータ
PE2 に戻すような配布をしてはならない（ここで、PE1 と PE2 は同一ルータかもしれない
し、異なるルータかもしれない）。ただし、PE2 が R2 を R1 とは異なる（すなわち、R1 と
は異なる RD を持った）VPN-IPv4 経路に対応付けている場合は除く。
3. PE ルータと CE ルータが OSPF ピアとなることができる。この場合、サイトは 1 つの OSPF
エリアであるべきで、CE はそのエリアの ABR であり、PE はそのエリア以外の ABR であ
るべきである。また、PE は同一サイトにある CE にこれ以外のルータリンクをレポートす
べきではない（この技術はスタブ VPN でのみ使うべきである）。
4. PE ルータと CE ルータが BGP ピアとなり、CE ルータは BGP（特に EBGP）を使用して、
PE ルータに CE ルータのサイトのアドレスプレフィックス集合を教えることができる（この
技術はスタブ VPN でもトランジット VPN でも使用できる）。
純粋に技術的な視点から見ると、これは以下で見るように断然良い技術である。
a） IGP の他の手段とは異なり、これは PE が複数の CE と話すために複数のルーティング
アルゴリズムインスタンスを実行する必要が無い。
b） BGP は、異なる管理で動作しているシステム間でルーティング情報を渡すという、ま
さにこの機能のためのものとして設計されている。
c）サイトが「BGP バックドア」、すなわち PE ルータ以外のルータと BGP 接続を持つ
ルータを含むときでも、このプロシージャは全ての状況で正しく動作するだろう。他の
プロシージャは、具体的な状況によって動作したりしなかったりする。
d） BGP を使用することで、経路の属性を CE から PE へ渡すことが容易になる。例えば、
CE は各経路に対して、PE が経路に付けることを許可したターゲット属性の中から、特
定のターゲットを使うように促すことができる。
一方で、顧客自身がすでにインターネットサービスプロバイダ（ISP）であるという場合を
除けば、BGP を使用することは、CE 管理者にとってほとんど未知のものとなるだろう。
サイトの属している VPN がトランジット VPN ではないなら、ユニークな自律システム番
号（ASN）を持つ必要がないことに注意する。トランジット VPN に属していないサイトの
CE は、全て同一の ASN を使用することができる。これはプライベート ASN 空間から選ぶ
Rosen & Rekhter
情報提供
［Page 13］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
ことができ、PE によって取り除かれる。ルーティングループは起源サイト属性（後述）を
使用することで防がれる。
あるサイトの集合がトランジット VPN を構成するとき、BGP コンフェデレーションとして
記述し、VPN の内部構造が VPN 外のルータから見えなくなるようにする方が都合がよい。
この場合、VPN 内の各サイトはバックボーンに対して 2 つの BGP 接続を必要とする。1 つ
はコンフェデレーションの内部で、1 つは外部である。バックボーンとサイトが異なるポリ
シーを持てることを考慮するために、従来のイントラコンフェデレーションプロシージャ
を多少修正する必要がある。バックボーンは 1 つの接続上ではコンフェデレーションのメン
バーであるが、他の接続上ではメンバーではない。この技術は VPN サービスの顧客が ISP
であるとき役に立つ可能性がある。この技術では、顧客が ISP であるの場合、自分の ISP ピ
アの 1 つから VPN バックボーンサービスを得ることができる。
（しかし、VPN の顧客が ISP 自身であり、CE ルータが MPLS をサポートしているなら、
もっと単純な技術が使用でき、ISP はスタブ VPN と見なされる。第 8 章参照）
PE がサイトのアドレスプレフィックスを知るための各種手法を区別しなくてよいとき、単純に
PE はそのサイトから経路を「学んで」いると言うことにする。
PE がサイトから学んだ VPN-IPv4 経路を再配布するには、その前に経路に属性を割り当てる必
要がある。このときの属性は次のとおり 3 つある。
• 起源サイト
この属性は、PE ルータが経路を学んだサイトをユニークに特定する。ある 1 つのサイトか
ら学んだ経路は、全て同一の起源サイト属性が割り当てられなければならない。たとえサイ
トが 1 つの PE に複数接続されていても、また複数の PE と接続されていてもである。異な
る起源サイト属性は、異なるサイトに使用されなければならない。この属性は拡張 BGP コ
ミュニティ属性として符号化される（第 4.2.1 節）。
• 起源 VPN
第 4.2.1 節参照。
• ターゲット VPN
第 4.2.1 節参照。
7.
CE が PE から経路を学ぶ方法
この節では、CE 装置がルータであることを仮定している。
一般的に PE は、CE から送られてきたパケットをルーティングするために使用する転送テーブ
ルに PE が入れた経路は全て、その CE に配布して構わない。ただし 1 つの例外がある。それは、
経路の起源サイト属性があるサイトを示しているとき、そのサイトの CE にはその経路を再配布し
てはならないということである。
しかし、ほとんどの場合、PE が単純に CE へデフォルトルートを配布するだけで十分であろう
（この場合、PE へ向けたデフォルトルートを CE に設定すれば十分でもある）。これは一般的に、
自身でデフォルトルートを他のサイトに配布する必要がないサイトならどこでも使えるだろう（例
えば、企業 VPN 内のあるサイトがその企業のインターネットへのアクセスを持っているとき、そ
Rosen & Rekhter
情報提供
［Page 14］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
のサイトはデフォルトを他のサイトに配布する必要があるかもしれないが、そのサイト自身に対し
てデフォルトを配布できない）。
CE から PE へ経路を配布するのに使用するプロシージャは全て、PE から CE へ経路を配布す
るのにも使用される。
8.
CE が MPLS をサポートする場合どうなるか
CE が MPLS をサポートし、かつ VPN からの経路全体を取り込んで構わないなら、PE はこの
経路のそれぞれのラベルを配布することができる。PE がこのようなラベルの付いたパケットを CE
から受信したとき、PE は（a）そのラベルを BGP で学んだ対応するラベルに置き換え、
（b）それ
に対応する経路への BGP ネクストホップに対するラベルをプッシュする。
8.1.
仮想サイト
CE／PE 経路配布が BGP で行われた場合、CE は MPLS を使用して複数の仮想サイトをサポー
トできる。CE 自身が各仮想サイトに対する個別の転送テーブルを持てる。このテーブルは、PE
から受信した経路の起源 VPN 属性とターゲット VPN 属性に従って格納されている。CE が経路
全体を PE から受信している場合、PE が CE から受信したパケットのアドレスルックアップは全
く必要ない。別の方法として、各 VPN ごとに 1 つの（ラベル付き）デフォルトルートを PE が CE
へ配布することが可能な場合もある。そのとき、PE はラベル付きパケットを CE から受信したと
き、どの転送テーブルを調べたらいいかを知っていることになる。CE がパケットに付けたラベル
によって、パケットが入ってきた仮想サイトだけが識別されるのである。
8.2.
ISP VPN のスタブ VPN としての表現
ある VPN は実は ISP であるのだが、その CE ルータが MPLS をサポートしている場合、その
VPN は実際にスタブ VPN として扱うことができる。CE ルータと PE ルータは、VPN の内部の経
路だけを交換する必要がある。PE ルータは、この経路のそれぞれに対するラベルを CE ルータに
配布するだろう。このとき、VPN 内の異なるサイトのルータ同士は BGP ピアとなれる。CE ルー
タがパケットの宛先アドレスをルックアップするとき、ルーティングルックアップは常に内部アド
レスで解決される。これは通常、パケットの BGP ネクストホップのアドレスとなる。CE はパケッ
トに適切なラベル付けをして PE にパケットを送信する。
9.
セキュリティ
以下の条件
a）バックボーンルータは、信頼できないまたは不確かな起源からラベル付きパケットを受け入
れない。ただし、IP ヘッダやスタック中の下位ラベルを調べずに、そのパケットをバック
ボーンから送出する場合は除く。
b）ラベル付き VPN-IPv4 経路は、信頼できない、あるいは不確かな起源から受け入れない。
Rosen & Rekhter
情報提供
［Page 15］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
が満たされているなら、このアーキテクチャが提供するセキュリティはフレームリレーや ATM バッ
クボーンが VPN に提供するセキュリティと実質同等となる。
注目すべきは、MPLS を使わずに IP-within-IP トンネリングの形式のどれかを使ってこのレベ
ルのセキュリティを提供できるようにするよりも、MPLS を使用して提供する方がずっと簡単だ
ということである。上記条件の 1 番目が当てはまらない場合に、ラベル付きパケットの受信を拒
否するというのは簡単である。IP パケットが IP-within-IP トンネリングされたパケットの場合、
ルータに「誤った」場所に向かっているパケットを受信拒否させる設定はかなり難しい。
MPLS を使用することで、IPv4 ルーティング情報のドメイン間配布による方法に頼らずに、VPN
が複数の SP を跨がるようにできる。
VPN ユーザがトンネルモード IPSEC［5］を使用して、セキュリティを高めることも可能であ
る。これはこの節の以降で議論する。
9.1.
CE ルータ間のポイントツーポイントセキュリティトンネル
セキュリティを意識している VPN ユーザは、バックボーンを通るようなパケットの一部あるい
は全てに認証や暗号化を適用したいと考えるかもしれない。現在、この機能を得るための標準的な
やり方は、IPSEC トンネルモードを使用して、VPN の CE ルータのあらゆる組合せに「セキュリ
ティトンネル」を作ることだろう。
しかし、これまで述べてきた手法では、パケットを送信する CE ルータが、パケットを送るべき
次の CE ルータがどれか決定できない。いまだに、この情報は IPSEC トンネルモードを使用する
ために必要なのである。したがって、このような情報を利用できるようにするために、我々はこの
手法を拡張しなければならない。
これを実行する方法は［6］に示されている。全ての VPN-IPv4 経路は、その経路を通るとき通
過する次の CE ルータを判別する属性を持つことができる。この情報が VPN 内の全ての CE ルー
タに提供されれば、標準的な IPSEC トンネルモードを使用することができる。
CE と PE が BGP ピアの場合は、この情報を BGP 属性として提供するのが自然である。
IPSEC を使用する各 CE はアドレスプレフィックスの集合を設定して、このアドレスのいずれ
かへ危険なトラフィックが送信されるのを全て禁止すべきである。これは、何かの理由で必要な情
報を得ることに失敗したとき、CE が危険なトラフィックを送信することを防ぐ。
MPLS を使用して IPSEC トンネルの 2 つのエンドポイント間でパケットを運ぶとき、IPSEC の
外側ヘッダは実際には何も機能しない。MPLS 使用時に外側ヘッダを省略できる IPSEC トンネル
モードの方式を作ることは有益かもしれない。
9.2.
マルチパーティセキュリティアソシエーション
CE ルータの各ペアの間でセキュリティトンネルを設定する代わりに、単一のマルチパーティセ
キュリティアソシエーションを設定することは都合が良いこともある。このセキュリティアソシ
エーションでは、ある VPN に所属する全ての CE ルータが同一のセキュリティパラメータを共有
する（例えば、同じ秘密鍵、同じアルゴリズムなど）。そして、入口 CE は、どれがデータを受け
取る次の CE かを知る必要が無くなり、どの VPN にデータが行くかを知るだけでよくなる。複数
の VPN に所属する CE は、それぞれに対して異なるセキュリティパラメータを使うことができ、
したがって、例えばイントラネットパケットがエクストラネットに晒されることなどを防ぐ。
Rosen & Rekhter
情報提供
［Page 16］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
このようなやり方の場合、標準的なトンネルモード IPSEC は使用できない。なぜなら、「外側
ヘッダ」の IP 宛先アドレスフィールドに埋める方法が無いからである。しかし、実際には MPLS
を転送に使用する際、この外側ヘッダを処理する必要は無い。トンネルのエンドポイントの IP ア
ドレスを知らなくても、PE ルータは MPLS を使用してそのエンドポイントにパケットを送ること
ができる。「内側ヘッダ」の IP 宛先アドレスだけを知っていればよいのである。
このようなやり方の大きな利点は、ルーティングの変更（特に、あるアドレスプレフィックスに
対する出口 CE の変更）がセキュリティメカニズムに対して透過的になることである。これは、マ
ルチプロバイダ VPN の場合に特に重要となることがある。マルチプロバイダのとき、セキュリ
ティメカニズムをサポートするためだけに、このようなルーティング変更の情報を配布しないとい
けないというのは、規模拡張性の問題を引き起こしてしまう可能性がある。
もう 1 つの利点は、外側 IP ヘッダの必要性が無くなることである。なぜなら、MPLS カプセル
化がその役目を実行するからである。
10.
サービス品質
この文書の焦点ではないが、どの VPN サービスでもサービス品質は鍵となる要素である。MPLS
／BGP VPN では、シムヘッダ［10］の「試験」ビットを使用して、あるいはバックボーンに ATM
を使用している場合は ATM QoS 機能を使用して、既存の L3 QoS 機能をラベル付きパケットに
適用できる。
［1］で議論されているトラフィックエンジニアリングの動作は MPLS／BGP VPN に
直接適用可能である。必要ならトラフィックエンジニアリングを使って、特定のサイトの組み合わ
せの間で、特定の QoS 特性を持った LSP を確立することができる。MPLS／BGP VPN が複数の
SP を跨ぐ場合、
［7］に記述されているアーキテクチャが有効な場合もある。SP は統合サービスか
差別化サービスかのどちらか相応しい方の機能を、VPN に適用することができる。
11.
規模拡張性
この文書を通して規模拡張性の問題を議論してきた。この節では、規模拡張性に関して我々のモ
デルの主な特性を簡単にまとめる。
サービスプロバイダのバックボーンネットワークは（a）PE ルータ、（b）BGP ルートリフレク
タ、（c）（PE ルータでもルートリフレクタでもない）P ルータ、そしてマルチプロバイダ VPN の
場合の（d）ASBR で構成される。
P ルータは VPN の経路を一切保持しない。VPN トラフィックを正しく転送するために、P ルー
タは PE ルータと ASBR への経路だけを保持すればよい。2 階層のラベル付けを使用することで、
VPN 経路を P ルータから排除できるのである。
PE ルータは VPN 経路を保持するが、直接接続されている VPN だけを維持している。
ルートリフレクタや ASBR は、VPN の中でパーティショニングすることができ、それぞれの
パーティションはそのサービスプロバイダが提供する VPN のうち一部の VPN の経路だけを運ぶ。
したがって、1 つのルートリフレクタまたは ASBR が全 VPN の経路を保持する必要はない。
結果として、サービスプロバイダネットワーク内の 1 つの構成要素が全ての VPN の全ての経路
を保持する必要はない。よって、VPN 数増加に対応するためのネットワークの性能の合計は、個々
の構成要素の性能に限られない。
Rosen & Rekhter
情報提供
［Page 17］
RFC 2547
12.
BGP／MPLS VPN
1999 年 3 月
知的財産に関する配慮
Cisco Systems は、このドキュメントで発表された全ての技術に対して特許または他の知的財産
保護を求めることができる。この文書から生じた標準が Cisco Systems に委譲された 1 つ以上の特
許権によって保護されている、あるいは保護される予定の場合、Cisco はこの特許を開示し、妥当
かつ無差別な条件で使用を許諾する意向がある。
13.
セキュリティへの配慮
このメモ全体でセキュリティ問題を議論してきた。
14.
謝辞
Ravi Chandra、Dan Tappan、Bob Thomas には本作業への多大なる貢献をいただいた。
15.
著者連絡先
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
EMail: erosen@cisco.com
Yakov Rekhter
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
EMail: yakov@cisco.com
16.
参考文献
［1］ Awduche, Berger, Gan, Li, Swallow, and Srinavasan, “Extensions to RSVP for LSP Tun-
nels”, Work in Progress.
［2］ Bates, T. and R. Chandrasekaran, “BGP Route Reflection: An alternative to full mesh
IBGP”, RFC 1966, June 1996.
［3］ Bates, T., Chandra, R., Katz, D. and Y. Rekhter, “Multiprotocol Extensions for BGP4”,
RFC 2283, February 1998.
［4］ Gleeson, Heinanen, and Armitage, “A Framework for IP Based Virtual Private Networks”,
Work in Progress.
Rosen & Rekhter
情報提供
［Page 18］
RFC 2547
BGP／MPLS VPN
1999 年 3 月
［5］ Kent and Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, Novem-
ber 1998.
［6］ Li, “CPE based VPNs using MPLS”, October 1998, Work in Progress.
［7］ Li, T. and Y. Rekhter, “ A Provider Architecture for Differentiated Services and Traffic
Engineering (PASTE)”, RFC 2430, October 1998.
［8］ Rekhter and Rosen, “Carrying Label Information in BGP4”, Work in Progress.
［9］ Rosen, Viswanathan, and Callon, “Multiprotocol Label Switching Architecture”, Work in
Progress.
［10］ Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, “MPLS Label Stack En-
coding”, Work in Progress.
17.
著作権表明全文
c The Internet Society (1999). All Rights Reserved.
Copyright °
本ドキュメントとその翻訳を他者へ複製、提供して構わない。また本ドキュメントの解説や説
明もしくは実装段階で補足するような派生物は、上記著作権表示とこの段落を含めて提供すること
で、全部または一部をいかなる制限も設けずに作成、複製、出版、配布してもよい。しかし、本ド
キュメント自身には、著作権表示の削除や、Internet Society や他のインターネット団体への参照
を削除など、いかなる修正も許されない。ただし、インターネット標準の開発目的に必要な場合を
除く。この場合、インターネット標準化過程で定義される著作権に対する手続きに従わなければな
らない。また、英語以外の言語に翻訳する際に必要な場合も除く。
上記で認められた制限付きの許可は永久的なものであり、Internet Society や、それを継続また
は譲渡された者によって破棄されることはない。
本文書およびその中に含まれる情報は、
「無保証」を原則に提供され、Internet Society と Internet
Engineering Task Force は、明示的・暗示的な全ての保証を放棄する。この保証には、文中の情
報を使用することがいかなる権利も侵害しないという保証、また商用利用や特定の目的に対する適
合性の暗黙の保証も含まれるが、それに限らない。
Rosen & Rekhter
情報提供
［Page 19］

Download Report