[要約] RFC 2547は、BGP/MPLS VPNsの設計と実装に関するガイドラインを提供します。このRFCの目的は、異なるサイト間で仮想的なプライベートネットワークを構築するためのプロトコルとアーキテクチャを定義することです。
Network Working Group E. Rosen
Request for Comments: 2547 Y. Rekhter
Category: Informational Cisco Systems, Inc.
March 1999
BGP/MPLS VPNs
BGP/MPLS VPNS
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.
このドキュメントでは、IPバックボーンを持つサービスプロバイダーが顧客にVPN（仮想プライベートネットワーク）を提供できる方法について説明します。MPLS（マルチプロトコルラベルスイッチング）は、バックボーン上のパケットの転送に使用され、BGP（Border Gateway Protocol）は、バックボーン上のルートの分布に使用されます。この方法の主な目標は、エンタープライズネットワーク向けのIPバックボーンサービスのアウトソーシングをサポートすることです。エンタープライズにとって簡単な方法で、サービスプロバイダーにとってスケーラブルで柔軟性があり、サービスプロバイダーが価値を追加できるようにします。これらの手法は、顧客にIPサービスを提供するVPNを提供するためにも使用できます。
Table of Contents
目次
1 Introduction ....................................... 2
1.1 Virtual Private Networks ........................... 2
1.2 Edge Devices ....................................... 3
1.3 VPNs with Overlapping Address Spaces ............... 4
1.4 VPNs with Different Routes to the Same System ...... 4
1.5 Multiple Forwarding Tables in PEs .................. 5
1.6 SP Backbone Routers ................................ 5
1.7 Security ........................................... 5
2 Sites and CEs ...................................... 6
3 Per-Site Forwarding Tables in the PEs .............. 6
3.1 Virtual Sites ...................................... 8
4 VPN Route Distribution via BGP ..................... 8
4.1 The VPN-IPv4 Address Family ........................ 9
4.2 Controlling Route Distribution ..................... 10
4.2.1 The Target VPN Attribute ........................... 10
4.2.2 Route Distribution Among PEs by BGP ................ 12
4.2.3 The VPN of Origin Attribute ........................ 13
4.2.4 Building VPNs using Target and Origin Attributes ... 14
5 Forwarding Across the Backbone ..................... 15
6 How PEs Learn Routes from CEs ...................... 16
7 How CEs learn Routes from PEs ...................... 19
8 What if the CE Supports MPLS? ...................... 19
8.1 Virtual Sites ...................................... 19
8.2 Representing an ISP VPN as a Stub VPN .............. 20
9 Security ........................................... 20
9.1 Point-to-Point Security Tunnels between CE Routers . 21
9.2 Multi-Party Security Associations .................. 21
10 Quality of Service ................................. 22
11 Scalability ........................................ 22
12 Intellectual Property Considerations ............... 23
13 Security Considerations ............................ 23
14 Acknowledgments .................................... 23
15 Authors' Addresses ................................. 24
16 References ......................................... 24
17 Full Copyright Statement............................. 25
Consider a set of "sites" which are attached to a common network which we may call the "backbone". Let's apply some policy to create a number of subsets of that set, and let's impose the following rule: two sites may have IP interconnectivity over that backbone only if at least one of these subsets contains them both.
「バックボーン」と呼ばれる一般的なネットワークに接続されている「サイト」のセットを考えてみましょう。そのセットのいくつかのサブセットを作成するためにいくつかのポリシーを適用しましょう。次のルールを課しましょう。2つのサイトには、これらのサブセットの少なくとも1つが両方が含まれている場合にのみ、そのバックボーン上にIP相互接続性がある場合があります。
The subsets we have created are "Virtual Private Networks" (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN which contains them both. Two sites which have no VPN in common have no connectivity over that backbone.
作成したサブセットは、「仮想プライベートネットワーク」（VPNS）です。2つのサイトには、両方を含むVPNがある場合にのみ、一般的なバックボーン上のIP接続があります。VPNが共通していない2つのサイトには、そのバックボーン上の接続性がありません。
If all the sites in a VPN are owned by the same enterprise, the VPN is a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN is an "extranet". A site can be in more than one VPN; e.g., in an intranet and several extranets. We regard both intranets and extranets as VPNs. In general, when we use the term VPN we will not be distinguishing between intranets and extranets.
VPN内のすべてのサイトが同じ企業が所有している場合、VPNは企業の「イントラネット」です。VPN内のさまざまなサイトが異なる企業が所有している場合、VPNは「エクストラネット」です。サイトは複数のVPNである可能性があります。たとえば、イントラネットといくつかのエクストラネットで。イントラネットとエクストラネットの両方をVPNと見なしています。一般に、VPNという用語を使用する場合、イントラネットとエクストラネットを区別しません。
We wish to consider the case in which the backbone is owned and operated by one or more Service Providers (SPs). The owners of the sites are the "customers" of the SPs. The policies that determine whether a particular collection of sites is a VPN are the policies of the customers. Some customers will want the implementation of these policies to be entirely the responsibility of the SP. Other customers may want to implement these policies themselves, or to share with the SP the responsibility for implementing these policies. In this document, we are primarily discussing mechanisms that may be used to implement these policies. The mechanisms we describe are general enough to allow these policies to be implemented either by the SP alone, or by a VPN customer together with the SP. Most of the discussion is focused on the former case, however.
バックボーンが1つ以上のサービスプロバイダー（SPS）が所有および運営されているケースを検討したいと考えています。サイトの所有者は、SPSの「顧客」です。サイトの特定のコレクションがVPNであるかどうかを決定するポリシーは、顧客のポリシーです。一部の顧客は、これらのポリシーの実装が完全にSPの責任であることを望むでしょう。他の顧客は、これらのポリシーを自分で実装するか、SPとこれらのポリシーを実装する責任を共有したい場合があります。このドキュメントでは、これらのポリシーを実装するために使用できるメカニズムについて主に議論しています。私たちが説明するメカニズムは、これらのポリシーをSPのみ、またはSPと一緒にVPN顧客によって実装できるようにするのに十分な一般的です。ただし、議論のほとんどは前者のケースに焦点を当てています。
The mechanisms discussed in this document allow the implementation of a wide range of policies. For example, within a given VPN, we can allow every site to have a direct route to every other site ("full mesh"), or we can restrict certain pairs of sites from having direct routes to each other ("partial mesh").
このドキュメントで説明されているメカニズムにより、幅広いポリシーの実装が可能になります。たとえば、特定のVPN内で、すべてのサイトが他のすべてのサイト（「フルメッシュ」）への直接ルートを持つことを許可することも、特定のサイトのペアを互いに直接ルートにすることを制限することもできます（「部分メッシュ」）。
In this document, we are particularly interested in the case where the common backbone offers an IP service. We are primarily concerned with the case in which an enterprise is outsourcing its backbone to a service provider, or perhaps to a set of service providers, with which it maintains contractual relationships. We are not focused on providing VPNs over the public Internet.
このドキュメントでは、一般的なバックボーンがIPサービスを提供する場合に特に興味があります。当社は主に、企業がバックボーンをサービスプロバイダーにアウトソーシングしている場合、またはおそらく契約関係を維持しているサービスプロバイダーのセットに関心を持っています。私たちは、パブリックインターネットを介してVPNを提供することに焦点を合わせていません。
In the rest of this introduction, we specify some properties which VPNs should have. The remainder of this document outlines a VPN model which has all these properties. The VPN Model of this document appears to be an instance of the framework described in [4].
この紹介の残りの部分では、VPNが必要とするいくつかのプロパティを指定します。このドキュメントの残りの部分は、これらすべてのプロパティを備えたVPNモデルの概要を示しています。このドキュメントのVPNモデルは、[4]で説明されているフレームワークのインスタンスであると思われます。
We suppose that at each site, there are one or more Customer Edge (CE) devices, each of which is attached via some sort of data link (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers.
各サイトには、1つ以上の顧客エッジ（CE）デバイスがあり、それぞれが何らかのデータリンク（PPP、ATM、イーサネット、フレームリレー、GREトンネルなど）を介して添付されていると考えています。またはそれ以上のプロバイダーエッジ（PE）ルーター。
If a particular site has a single host, that host may be the CE device. If a particular site has a single subnet, that the CE device may be a switch. In general, the CE device can be expected to be a router, which we call the CE router.
特定のサイトに単一のホストがある場合、そのホストはCEデバイスである可能性があります。特定のサイトに単一のサブネットがある場合、CEデバイスがスイッチになる可能性があります。一般に、CEデバイスはルーターになると予想され、CEルーターと呼ばれます。
We will say that a PE router is attached to a particular VPN if it is attached to a CE device which is in that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device which is in that site.
そのVPNにあるCEデバイスに接続されている場合、PEルーターは特定のVPNに接続されていると言います。同様に、PEルーターがそのサイトにあるCEデバイスに接続されている場合、PEルーターが特定のサイトに接続されていると言います。
When the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but is not a routing peer of CE routers at other sites. Routers at different sites do not directly exchange routing information with each other; in fact, they do not even need to know of each other at all (except in the case where this is necessary for security purposes, see section 9). As a consequence, very large VPNs (i.e., VPNs with a very large number of sites) are easily supported, while the routing strategy for each individual site is greatly simplified.
CEデバイスがルーターである場合、それは接続されているPEのルーティングピアですが、他のサイトのCEルーターのルーティングピアではありません。さまざまなサイトのルーターは、ルーティング情報を互いに直接交換しません。実際、彼らはお互いをまったく知る必要さえありません（これがセキュリティ目的で必要な場合を除き、セクション9を参照）。結果として、非常に大きなVPN（つまり、非常に多数のサイトを持つVPN）は簡単にサポートされますが、個々のサイトのルーティング戦略は非常に簡素化されます。
It is important to maintain clear administrative boundaries between the SP and its customers (cf. [4]). The PE and P routers should be administered solely by the SP, and the SP's customers should not have any management access to it. The CE devices should be administered solely by the customer (unless the customer has contracted the management services out to the SP).
SPとその顧客の間の明確な管理境界を維持することが重要です（[4]を参照）。PEおよびPルーターはSPのみが管理する必要があり、SPの顧客は管理アクセスを持たないはずです。CEデバイスは、顧客のみが管理する必要があります（顧客がSPに管理サービスを契約していない限り）。
We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs.
2つの非交差するVPN（つまり、共通のサイトのないVPN）には、アドレス空間が重複している可能性があると想定しています。同じアドレスが、さまざまなシステムで異なるVPNで再利用される場合があります。特定のエンドシステムに、それが属するVPNの範囲内で一意のアドレスがある限り、エンドシステム自体はVPNについて何も知る必要はありません。
In this model, the VPN owners do not have a backbone to administer, not even a "virtual backbone". Nor do the SPs have to administer a separate backbone or "virtual backbone" for each VPN. Site-to-site routing in the backbone is optimal (within the constraints of the policies used to form the VPNs), and is not constrained in any way by an artificial "virtual topology" of tunnels.
このモデルでは、VPNの所有者には、「仮想バックボーン」さえも、管理するバックボーンがありません。また、SPSは、各VPNに個別のバックボーンまたは「仮想バックボーン」を管理する必要もありません。バックボーンのサイト間ルーティングは最適です（VPNを形成するために使用されるポリシーの制約内）、トンネルの人工的な「仮想トポロジ」によって決して制約されていません。
Although a site may be in multiple VPNs, it is not necessarily the case that the route to a given system at that site should be the same in all the VPNs. Suppose, for example, we have an intranet consisting of sites A, B, and C, and an extranet consisting of A, B, C, and the "foreign" site D. Suppose that at site A there is a server, and we want clients from B, C, or D to be able to use that server. Suppose also that at site B there is a firewall. We want all the traffic from site D to the server to pass through the firewall, so that traffic from the extranet can be access controlled. However, we don't want traffic from C to pass through the firewall on the way to the server, since this is intranet traffic.
サイトは複数のVPNにある可能性がありますが、そのサイトの特定のシステムへのルートがすべてのVPNで同じである必要があるとは限りません。たとえば、サイトa、b、cで構成されるイントラネットと、a、b、c、および「外部」サイトDで構成されるエクストラネットがあるとします。B、C、またはDのクライアントにそのサーバーを使用できるようにします。また、サイトBにファイアウォールがあると仮定します。サイトDからサーバーへのすべてのトラフィックがファイアウォールを通過するようにして、エクストラネットからのトラフィックを制御できるようにしたいと考えています。ただし、これはイントラネットトラフィックであるため、サーバーに向かう途中のファイアウォールをCからトラフィックを通過させたくありません。
This means that it needs to be possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A.
これは、サーバーに2つのルートをセットアップできる必要があることを意味します。サイトbとcで使用される1つのルートは、トラフィックをサイトAに直接移動します。サイトDで使用される2番目のルートは、代わりにトラフィックをサイトBのファイアウォールに連れて行きます。サイトBから来るトラフィックになり、サイトAへのルートに従うこと
Each PE router needs to maintain a number of separate forwarding tables. Every site to which the PE is attached must be mapped to one of those forwarding tables. When a packet is received from a particular site, the forwarding table associated with that site is consulted in order to determine how to route the packet. The forwarding table associated with a particular site S is populated only with routes that lead to other sites which have at least one VPN in common with S. This prevents communication between sites which have no VPN in common, and it allows two VPNs with no site in common to use address spaces that overlap with each other.
各PEルーターは、多数の個別の転送テーブルを維持する必要があります。PEが接続されているすべてのサイトは、それらの転送テーブルのいずれかにマッピングする必要があります。特定のサイトからパケットが受信されると、パケットをルーティングする方法を決定するために、そのサイトに関連付けられた転送テーブルが相談されます。特定のサイトSに関連付けられている転送テーブルは、少なくとも1つのVPNが共通している他のサイトにつながるルートのみが入力されます。これにより、VPNが共通していないサイト間の通信が防止され、サイトなしで2つのVPNが許可されます。共通して、互いに重複するアドレススペースを使用します。
The SP's backbone consists of the PE routers, as well as other routers (P routers) which do not attach to CE devices.
SPのバックボーンは、CEデバイスに接続しない他のルーター（Pルーター）だけでなく、PEルーターで構成されています。
If every router in an SP's backbone had to maintain routing information for all the VPNs supported by the SP, this model would have severe scalability problems; the number of sites that could be supported would be limited by the amount of routing information that could be held in a single router. It is important to require therefore that the routing information about a particular VPN be present ONLY in those PE routers which attach to that VPN. In particular, the P routers should not need to have ANY per-VPN routing information whatsoever.
SPのバックボーン内のすべてのルーターが、SPによってサポートされているすべてのVPNのルーティング情報を維持する必要がある場合、このモデルには深刻なスケーラビリティの問題があります。サポートできるサイトの数は、単一のルーターに保持できるルーティング情報の量によって制限されます。したがって、特定のVPNに関するルーティング情報は、そのVPNに付着するPEルーターにのみ存在することを要求することが重要です。特に、Pルーターには、VPNごとのルーティング情報がまったく含まれている必要はありません。
VPNs may span multiple service providers. We assume though that when the path between PE routers crosses a boundary between SP networks, it does so via a private peering arrangement, at which there exists mutual trust between the two providers. In particular, each provider must trust the other to pass it only correct routing information, and to pass it labeled (in the sense of MPLS [9]) packets only if those packets have been labeled by trusted sources. We also assume that it is possible for label switched paths to cross the boundary between service providers.
VPNは、複数のサービスプロバイダーにまたがる場合があります。ただし、PEルーター間のパスがSPネットワーク間の境界を通過すると、2つのプロバイダーの間に相互の信頼が存在するプライベートピアリングアレンジメントを介して行うと想定しています。特に、各プロバイダーは、他のプロバイダーが正しいルーティング情報のみを渡すように信頼し、それらのパケットが信頼できるソースによってラベル付けされている場合にのみ（MPLS [9]）パケットのラベルを付けるように渡す必要があります。また、ラベルスイッチ付きパスがサービスプロバイダー間の境界を越えることが可能であると仮定します。
A VPN model should, even without the use of cryptographic security measures, provide a level of security equivalent to that obtainable when a level 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of different VPNs, it should not be possible for systems in one VPN to gain access to systems in another VPN.
VPNモデルは、暗号化セキュリティ対策を使用しなくても、レベル2バックボーン（フレームリレーなど）が使用された場合に得られるセキュリティと同等のレベルのセキュリティを提供する必要があります。つまり、異なるVPNの誤解や意図的な相互接続がない場合、あるVPNのシステムが別のVPNのシステムにアクセスできるようにすることはできません。
It should also be possible to deploy standard security procedures.
標準的なセキュリティ手順を展開することも可能です。
From the perspective of a particular backbone network, a set of IP systems constitutes a site if those systems have mutual IP interconnectivity, and communication between them occurs without use of the backbone. In general, a site will consist of a set of systems which are in geographic proximity. However, this is not universally true; two geographic locations connected via a leased line, over which OSPF is running, will constitute a single site, because communication between the two locations does not involve the use of the backbone.
特定のバックボーンネットワークの観点から見ると、IPシステムのセットは、これらのシステムが相互IP相互接続性を備えている場合にサイトを構成し、それらの間の通信はバックボーンを使用せずに発生します。一般に、サイトは地理的に近接している一連のシステムで構成されます。ただし、これは普遍的に真実ではありません。OSPFが実行されているリースラインを介して接続された2つの地理的位置は、2つの場所間の通信にはバックボーンの使用が含まれないため、単一のサイトを構成します。
A CE device is always regarded as being in a single site (though as we shall see, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs.
CEデバイスは常に単一のサイトにあると見なされます（ただし、サイトは複数の「仮想サイト」で構成される場合があります）。ただし、サイトは複数のVPNに属している場合があります。
A PE router may attach to CE devices in any number of different sites, whether those CE devices are in the same or in different VPNs. A CE device may, for robustness, attach to multiple PE routers, of the same or of different service providers. If the CE device is a router, the PE router and the CE router will appear as router adjacencies to each other.
PEルーターは、これらのCEデバイスが同じVPNであるかどうかにかかわらず、任意の数の異なるサイトのCEデバイスに接続する場合があります。CEデバイスは、堅牢性のために、同じまたは異なるサービスプロバイダーの複数のPEルーターに取り付けることができます。CEデバイスがルーターの場合、PEルーターとCEルーターは互いにルーターの隣接として表示されます。
While the basic unit of interconnection is the site, the architecture described herein allows a finer degree of granularity in the control of interconnectivity. For example, certain systems at a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only.
相互接続の基本単位はサイトですが、ここで説明するアーキテクチャは、相互接続性の制御においてより細かい程度の粒度性を可能にします。たとえば、サイトの特定のシステムは、イントラネットのメンバーと1つ以上のエクストラネットのメンバーである場合がありますが、同じサイトの他のシステムはイントラネットのメンバーのみに制限される場合があります。
Each PE router maintains one or more "per-site forwarding tables". Every site to which the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular per-site forwarding table only if that packet has arrived directly from a site which is associated with that table.
各PEルーターは、1つ以上の「サイトごとの転送テーブル」を維持します。PEルーターが取り付けられているすべてのサイトは、これらのテーブルの1つに関連付けられています。特定のパケットのIP宛先アドレスは、そのパケットがそのテーブルに関連付けられているサイトから直接到着した場合にのみ、特定の敷地ごとの転送テーブルで検索されます。
How are the per-site forwarding tables populated? As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes which are reachable at CE1's site. If PE2 and PE3 are attached respectively to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes which it has learned from CE1. PE2 and PE3 use these routes to populate the forwarding tables which they associate respectively with the sites of CE2 and CE3. Routes from sites which are not in VPN V do not appear in these forwarding tables, which means that packets from CE2 or CE3 cannot be sent to sites which are not in VPN V.
サイトごとの転送テーブルはどのように人数化されていますか？例として、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にないサイトに送信できません。
If a site is in multiple VPNs, the forwarding table associated with that site can contain routes from the full set of VPNs of which the site is a member.
サイトが複数のVPNにある場合、そのサイトに関連付けられた転送テーブルには、サイトがメンバーであるVPNの完全なセットからのルートを含めることができます。
A PE generally maintains only one forwarding table per site, even if it is multiply connected to that site. Also, different sites can share the same forwarding table if they are meant to use exactly the same set of routes.
通常、PEは、サイトに接続されている場合でも、サイトごとに1つの転送テーブルのみを維持します。また、まったく同じルートセットを使用することを目的としている場合、異なるサイトは同じ転送テーブルを共有できます。
Suppose a packet is received by a PE router from a particular directly attached site, but the packet's destination address does not match any entry in the forwarding table associated with that site. If the SP is not providing Internet access for that site, then the packet is discarded as undeliverable. If the SP is providing Internet access for that site, then the PE's Internet forwarding table will be consulted. This means that in general, only one forwarding table per PE need ever contain routes from the Internet, even if Internet access is provided.
特定の直接添付のサイトからPEルーターによってパケットが受信されているが、パケットの宛先アドレスがそのサイトに関連付けられた転送テーブルのエントリと一致しないとします。SPがそのサイトにインターネットアクセスを提供していない場合、パケットは配信不能として破棄されます。SPがそのサイトにインターネットアクセスを提供している場合、PEのインターネット転送テーブルに相談します。これは、一般に、たとえインターネットアクセスが提供されていても、PEごとに1つの転送テーブルのみがインターネットからのルートを含む必要があることを意味します。
To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a labeled packet from any adjacent non-backbone device unless (a) the label at the top of the label stack was actually distributed by the backbone router to the non-backbone device, and (b) the backbone router can determine that use of that label will cause the packet to leave the backbone before any labels lower in the stack will be inspected, and before the IP header will be inspected. These restrictions are necessary in order to prevent packets from entering a VPN where they do not belong.
あるVPNの適切な分離を別のVPNから維持するために、（a）ラベルスタックの上部にあるラベルが実際にバックボーンルーターによって分散されていない限り、隣接する非骨骨デバイスからラベル付きパケットをバックボーンに受け入れることがないことが重要です。バックボーン以外のデバイス、および（b）バックボーンルーターは、そのラベルを使用すると、スタック内のラベルが低くなる前に、IPヘッダーが検査される前にパケットがバックボーンを離れることを決定できます。これらの制限は、パケットがVPNが属していない場合にVPNを入力するのを防ぐために必要です。
The per-site forwarding tables in a PE are ONLY used for packets which arrive from a site which is directly attached to the PE. They are not used for routing packets which arrive from other routers that belong to the SP backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. E.g., one may have one route to a given system for packets from the extranet (where the route leads to a firewall), and a different route to the same system for packets from the intranet (including packets that have already passed through the firewall).
PE内のサイトごとの転送テーブルは、PEに直接接続されているサイトから届くパケットにのみ使用されます。これらは、SPバックボーンに属する他のルーターから届くパケットをルーティングするためには使用されません。その結果、同じシステムへの複数の異なるルートがあり、その後のルートに続いて特定のパケットが続くことは、パケットがバックボーンに入るサイトによって決定されます。たとえば、エクストラネット（ルートがファイアウォールにつながる）からパケット用の特定のシステムへの1つのルートと、イントラネットからのパケット用の同じシステムへの異なるルート（すでにファイアウォールを通過しているパケットを含む）がある場合があります。。
In some cases, a particular site may be divided by the customer into several virtual sites, perhaps by the use of VLANs. Each virtual site may be a member of a different set of VPNs. The PE then needs to contain a separate forwarding table for each virtual site. For example, if a CE supports VLANs, and wants each VLAN mapped to a separate VPN, the packets sent between CE and PE could be contained in the site's VLAN encapsulation, and this could be used by the PE, along with the interface over which the packet is received, to assign the packet to a particular virtual site.
場合によっては、特定のサイトは、おそらくVLANの使用によって、顧客によっていくつかの仮想サイトに分割される場合があります。各仮想サイトは、VPNの異なるセットのメンバーである場合があります。PEは、各仮想サイトに個別の転送テーブルを含める必要があります。たとえば、CEがVLANをサポートし、各VLANを個別のVPNにマッピングしたい場合、CEとPEの間に送信されるパケットはサイトのVLANカプセル化に含まれる可能性があり、これはPEが使用できます。パケットを受信して、パケットを特定の仮想サイトに割り当てます。
Alternatively, one could divide the interface into multiple "sub-interfaces" (particularly if the interface is Frame Relay or ATM), and assign the packet to a VPN based on the sub-interface over which it arrives. Or one could simply use a different interface for each virtual site. In any case, only one CE router is ever needed per site, even if there are multiple virtual sites. Of course, a different CE router could be used for each virtual site, if that is desired.
または、インターフェイスを複数の「サブインターフェイス」（特にインターフェイスがフレームリレーまたはATMの場合）に分割し、到着するサブインターフェイスに基づいてパケットをVPNに割り当てることができます。または、仮想サイトごとに別のインターフェイスを使用するだけです。いずれにせよ、複数の仮想サイトがある場合でも、サイトごとに1つのCEルーターのみが必要です。もちろん、それが必要な場合は、各仮想サイトに別のCEルーターを使用できます。
Note that in all these cases, the mechanisms, as well as the policy, for controlling which traffic is in which VPN are in the hand of the customer.
これらすべての場合、メカニズムは、VPNが顧客の手にあるトラフィックを制御するためのメカニズムとポリシーであることに注意してください。
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, our out different network interfaces.
特定のホストを複数の仮想サイトに置くことが望ましい場合は、そのホストがパケットが関連付けられている仮想サイトごとに決定する必要があります。これを行うことができます。たとえば、さまざまなVLAN上の異なる仮想サイトからパケットを送信することで、異なるネットワークインターフェイスです。
These schemes do NOT require the CE to support MPLS. Section 8 contains a brief discussion of how the CE might support multiple virtual sites if it does support MPLS.
これらのスキームでは、MPLSをサポートするためにCEが必要としません。セクション8には、MPLSをサポートしている場合、CEが複数の仮想サイトをどのようにサポートするかについての簡単な説明が含まれています。
PE routers use BGP to distribute VPN routes to each other (more accurately, to cause VPN routes to be distributed to each other).
PEルーターはBGPを使用してVPNルートを相互に配布します（より正確には、VPNルートを互いに分布させます）。
A BGP speaker can only install and distribute one route to a given address prefix. Yet we allow each VPN to have its own address space, which means that the same address can be used in any number of VPNs, where in each VPN the address denotes a different system. It follows that we need to allow BGP to install and distribute multiple routes to a single IP address prefix. Further, we must ensure that POLICY is used to determine which sites can be use which routes; given that several such routes are installed by BGP, only one such must appear in any particular per-site forwarding table.
BGPスピーカーは、特定のアドレスプレフィックスに1つのルートのみをインストールして配布できます。しかし、各VPNに独自のアドレススペースがあることを許可します。つまり、各VPNでは、アドレスが異なるシステムを示す任意の数のVPNで同じアドレスを使用できます。そのため、BGPが単一のIPアドレスプレフィックスに複数のルートをインストールして配布できるようにする必要があります。さらに、ポリシーがどのルートを使用できるかを決定するために使用されることを確認する必要があります。このようなルートがBGPによって設置されていることを考えると、特定のサイトごとの転送テーブルに表示される必要があるのは1つだけです。
We meet these goals by the use of a new address family, as specified below.
以下に指定されているように、新しいアドレスファミリーを使用することにより、これらの目標を達成します。
The BGP Multiprotocol Extensions [3] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. If two VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.
BGPマルチプロトコル拡張[3]により、BGPは複数の「アドレスファミリ」からルートを運ぶことができます。「VPN-IPV4アドレスファミリ」の概念を紹介します。VPN-IPV4アドレスは12バイトの数量で、8バイトの「Route Distiminguriuther（RD）」から始まり、4バイトのIPv4アドレスで終了します。2つのVPNが同じIPv4アドレスプレフィックスを使用する場合、PESはこれらを一意のVPN-IPV4アドレスプレフィックスに変換します。これにより、同じアドレスが2つの異なるVPNで使用されている場合、そのアドレスに2つの完全に異なるルートをインストールすることができます。
The RD does not by itself impose any semantics; it contains no information about the origin of the route or about the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine where to redistribute the route (see section 4.2).
RDは、それ自体をセマンティクスを課していません。ルートの起源に関する情報や、ルートが配布されるVPNのセットに関する情報は含まれていません。RDの目的は、一般的なIPv4アドレスプレフィックスへの異なるルートを作成できるようにすることだけです。他の手段は、ルートの再配布先を決定するために使用されます（セクション4.2を参照）。
The RD can also be used to create multiple different routes to the very same system. In section 3, we gave an example where the route to a particular server had to be different for intranet traffic than for extranet traffic. This can be achieved by creating two different VPN-IPv4 routes that have the same IPv4 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used (see section 4.2.3) to decide which packets use which route.
RDは、まったく同じシステムに複数の異なるルートを作成するためにも使用できます。セクション3では、特定のサーバーへのルートがイントラネットトラフィックの場合とは異なるものでなければならなかった例を示しました。これは、同じIPv4パーツを持つが異なるRDを持つ2つの異なるVPN-IPV4ルートを作成することで実現できます。これにより、BGPは複数の異なるルートを同じシステムにインストールでき、ポリシーを使用して（セクション4.2.3を参照）、どのパケットを使用するかを決定します。
The RDs are structured so that every service provider can administer its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other service provider. An RD consists of a two-byte type field, an administrator field, and an assigned number field. The value of the type field determines the lengths of the other two fields, as well as the semantics of the administrator field. The administrator field identifies an assigned number authority, and the assigned number field contains a number which has been assigned, by the identified authority, for a particular purpose. For example, one could have an RD whose administrator field contains an Autonomous System number (ASN), and whose (4-byte) number field contains a number assigned by the SP to whom IANA has assigned that ASN. RDs are given this structure in order to ensure that an SP which provides VPN backbone service can always create a unique RD when it needs to do so. However, the structuring provides no semantics. When BGP compares two such address prefixes, it ignores the structure entirely.
RDSは構造化されているため、すべてのサービスプロバイダーが独自の「番号付けスペース」を管理できる（つまり、RDの割り当てを作成できます）。RDは、2バイト型フィールド、管理者フィールド、および割り当てられた番号フィールドで構成されています。タイプフィールドの値は、他の2つのフィールドの長さと、管理者フィールドのセマンティクスを決定します。管理者フィールドは、割り当てられた番号当局を識別し、割り当てられた番号フィールドには、特定された当局によって割り当てられた番号が特定の目的で含まれています。たとえば、管理者フィールドに自律システム番号（ASN）が含まれているRDを持つことができ、その（4バイトの）番号フィールドには、IANAがそのASNを割り当てたSPによって割り当てられた数値が含まれています。RDSには、VPNバックボーンサービスを提供するSPが必要に応じて常に一意のRDを作成できるようにするために、この構造が与えられます。ただし、構造化はセマンティクスを提供しません。BGPがそのような2つのアドレスプレフィックスを比較すると、構造を完全に無視します。
If the Administrator subfield and the Assigned Number subfield of a VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is considered to have exactly the same meaning as the corresponding globally unique IPv4 address. In particular, this VPN-IPv4 address and the corresponding globally unique IPv4 address will be considered comparable by BGP. In all other cases, a VPN-IPv4 address and its corresponding globally unique IPv4 address will be considered noncomparable by BGP.
管理者サブフィールドとVPN-IPV4アドレスの割り当てられた番号サブフィールドが両方ともすべてのゼロに設定されている場合、VPN-IPV4アドレスは、対応するグローバルに一意のIPv4アドレスとまったく同じ意味を持つと見なされます。特に、このVPN-IPV4アドレスと対応するグローバルに一意のIPv4アドレスは、BGPによって同等のものと見なされます。他のすべての場合、VPN-IPV4アドレスとそれに対応するグローバルに一意のIPv4アドレスは、BGPによって比較できないと見なされます。
A given per-site forwarding table will only have one VPN-IPv4 route for any given IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched.
特定のサイト転送テーブルには、特定のIPv4アドレスプレフィックスに対して1つのVPN-IPV4ルートのみがあります。パケットの宛先アドレスがVPN-IPV4ルートと一致する場合、IPv4部品のみが実際に一致します。
A PE needs to be configured to associate routes which lead to particular CE with a particular RD. The PE may be configured to associate all routes leading to the same CE with the same RD, or it may be configured to associate different routes with different RDs, even if they lead to the same CE.
特定のRDに特定のCEにつながるルートを関連付けるようにPEを構成する必要があります。PEは、同じCEにつながるすべてのルートを同じRDに関連付けるように構成されている場合があります。または、たとえ同じCEにつながる場合でも、異なるルートを異なるRDに関連付けるように構成される場合があります。
In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled.
このセクションでは、VPN-IPV4ルートの分布が制御される方法について説明します。
Every per-site forwarding table is associated with one or more "Target VPN" attributes.
すべてのサイト転送テーブルは、1つ以上の「ターゲットVPN」属性に関連付けられています。
When a VPN-IPv4 route is created by a PE router, it is associated with one or more "Target VPN" attributes. These are carried in BGP as attributes of the route.
VPN-IPV4ルートがPEルーターによって作成されると、1つ以上の「ターゲットVPN」属性に関連付けられます。これらは、ルートの属性としてBGPで運ばれます。
Any route associated with Target VPN T must be distributed to every PE router that has a forwarding table associated with Target VPN T. When such a route is received by a PE router, it is eligible to be installed in each of the PE's per-site forwarding tables that is associated with Target VPN T. (Whether it actually gets installed depends on the outcome of the BGP decision process.) In essence, a Target VPN attribute identifies a set of sites. Associating a particular Target VPN attribute with a route allows that route to be placed in the per-site forwarding tables that are used for routing traffic which is received from the corresponding sites.
ターゲットVPN Tに関連付けられているルートは、ターゲットVPN Tに関連付けられた転送テーブルを持つすべてのPEルーターに分散する必要があります。そのようなルートがPEルーターによって受信される場合、PEの各サイトごとに設置する資格がありますターゲットVPN Tに関連付けられた転送テーブル（実際にインストールされるかどうかは、BGP決定プロセスの結果によって異なります。）本質的に、ターゲットVPN属性は一連のサイトを識別します。特定のターゲットVPN属性をルートに関連付けることにより、そのルートを、対応するサイトから受け取ったトラフィックをルーティングするために使用されるサイトごとの転送テーブルに配置できます。
There is a set of Target VPNs that a PE router attaches to a route received from site S. And there is a set of Target VPNs that a PE router uses to determine whether a route received from another PE router could be placed in the forwarding table associated with site S. The two sets are distinct, and need not be the same.
PEルーターがサイトSから受信したルートに接続するターゲットVPNのセットがあり、PEルーターが別のPEルーターから受信したルートを転送テーブルに配置できるかどうかを判断するために使用するターゲットVPNのセットがありますサイトSに関連付けられています。2つのセットは明確であり、同じである必要はありません。
The function performed by the Target VPN attribute is similar to that performed by the BGP Communities Attribute. However, the format of the latter is inadequate, since it allows only a two-byte numbering space. It would be fairly straightforward to extend the BGP Communities Attribute to provide a larger numbering space. It should also be possible to structure the format, similar to what we have described for RDs (see section 4.1), so that a type field defines the length of an administrator field, and the remainder of the attribute is a number from the specified administrator's numbering space.
ターゲットVPN属性によって実行される関数は、BGPコミュニティ属性によって実行される関数と類似しています。ただし、後者の形式は2バイトの番号付けスペースのみを可能にするため、不十分です。BGPコミュニティ属性を拡張して、より大きな数字のスペースを提供することはかなり簡単です。また、RDSについて説明したものと同様に形式を構成することも可能である必要があります（セクション4.1を参照）。タイプフィールドは管理者フィールドの長さを定義し、属性の残りは指定された管理者の数字です。番号付けスペース。
When a BGP speaker has received two routes to the same VPN-IPv4 prefix, it chooses one, according to the BGP rules for route preference.
BGPスピーカーが同じVPN-IPV4プレフィックスに2つのルートを受け取った場合、ルートの好みのためのBGPルールに従って1つを選択します。
Note that a route can only have one RD, but it can have multiple Target VPNs. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Target VPN attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
ルートには1つのRDしか持てませんが、複数のターゲットVPNを持つことができることに注意してください。BGPでは、複数のルートとは対照的に、複数の属性を持つ単一のルートがある場合、スケーラビリティが向上します。より多くのルートを作成することでターゲットVPN属性を排除することができます（つまり、より多くのRDSを使用する）が、スケーリングプロパティはあまり好ましくありません。
How does a PE determine which Target VPN attributes to associate with a given route? There are a number of different possible ways. The PE might be configured to associate all routes that lead to a particular site with a particular Target VPN. Or the PE might be configured to associate certain routes leading to a particular site with one Target VPN, and certain with another. Or the CE router, when it distributes these routes to the PE (see section 6), might specify one or more Target VPNs for each route. The latter method shifts the control of the mechanisms used to implement the VPN policies from the SP to the customer. If this method is used, it may still be desirable to have the PE eliminate any Target VPNs that, according to its own configuration, are not allowed, and/or to add in some Target VPNs that according to its own configuration are mandatory.
PEは、特定のルートに関連するターゲットVPN属性をどのように決定しますか？さまざまな方法があります。PEは、特定のターゲットVPNを持つ特定のサイトにつながるすべてのルートを関連付けるように構成されている場合があります。または、特定のサイトにつながる特定のルートを1つのターゲットVPNで関連付け、特定のルートを別のルートで特定するようにPEを構成する場合があります。または、CEルーターがこれらのルートをPEに分配する場合（セクション6を参照）、各ルートの1つ以上のターゲットVPNを指定する場合があります。後者の方法は、VPNポリシーをSPから顧客に実装するために使用されるメカニズムの制御をシフトします。この方法を使用する場合、独自の構成に応じて許可されていないターゲットVPNをPEに排除することが望ましい場合があります。
It might be more accurate, if less suggestive, to call this attribute the "Route Target" attribute instead of the "VPN Target" attribute. It really identifies only a set of sites which will be able to use the route, without prejudice to whether those sites constitute what might intuitively be called a VPN.
「VPNターゲット」属性の代わりに、この属性を「ルートターゲット」属性と呼ぶ方が、より正確である場合があります。それは、それらのサイトが直感的にVPNと呼ばれるものを構成するかどうかを偏見なく、ルートを使用できるサイトのセットのみを実際に識別します。
If two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. Alternatively, each can have an IBGP connection to a route reflector.
VPNの2つの部位が同じ自律システムにあるPESに接続する場合、PESはそれらの間のIBGP接続によってVPN-IPV4ルートを互いに配布できます。または、それぞれがルートリフレクターへのIBGP接続を持つことができます。
If two sites of VPN are in different Autonomous Systems (e.g., because they are connected to different SPs), then a PE router will need to use IBGP to redistribute VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR will then need to use EBGP to redistribute those routes to an ASBR in another AS. This allows one to connect different VPN sites to different Service Providers. However, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet.
VPNの2つの部位が異なる自律システムにある場合（例：異なるSPに接続されているため）、PEルーターはIBGPを使用してVPN-IPV4ルートを自律システムの境界ルーター（ASBR）、またはASBRがクライアントであるルートリフレクター。ASBRは、EBGPを使用して、これらのルートを別のASのASBRに再分配する必要があります。これにより、異なるVPNサイトをさまざまなサービスプロバイダーに接続できます。ただし、SPS間の信頼できる配置の一部として、VPN-IPV4ルートは、プライベートピアリングポイントでのEBGP接続でのみ受け入れられる必要があります。VPN-IPV4ルートは、パブリックインターネットに配布したり、受け入れたりするべきではありません。
If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.
さまざまな自律システムに接続されたサイトを持っている多くのVPNがある場合、すべてのVPNのすべてのルートを保持するこれら2つのASEの間に単一のASBRが必要ではありません。複数のASBRがあり、それぞれがVPNSの特定のサブセットのルートのみを保持しています。
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and send the packet directly to the site from to which the route leads. This will usually mean that it just sends the packet to the CE router from which it learned the route. The label may also determine the data link encapsulation.
PEルーターがBGPを介してVPN-IPV4ルートを配布すると、独自のアドレスを「BGP Next Hop」として使用します。また、MPLSラベルを割り当てて配布します。（基本的に、PEルーターはVPN-IPV4ルートではなく、VPN-IPV4ルートとラベル付けされています。Cf。[8]）PEがスタックの上部にこのラベルを持つ受信パケットを処理すると、PEはスタックをポップします。ルートがリードするサイトに直接パケットを送信します。これは通常、ルートを学んだCEルーターにパケットを送信することを意味します。ラベルは、データリンクのカプセル化を決定する場合もあります。
In most cases, the label assigned by a PE will cause the packet to be sent directly to a CE, and the PE which receives the labeled packet will not look up the packet's destination address in any forwarding table. However, it is also possible for the PE to assign a label which implicitly identifies a particular forwarding table. In this case, the PE receiving a packet that label would look up the packet's destination address in one of its forwarding tables. While this can be very useful in certain circumstances, we do not consider it further in this paper.
ほとんどの場合、PEによって割り当てられたラベルはパケットをCEに直接送信し、ラベル付きパケットを受信したPEは転送テーブルのパケットの宛先アドレスを検索しません。ただし、PEが特定の転送テーブルを暗黙的に識別するラベルを割り当てることもできます。この場合、PEは、そのラベルが転送テーブルの1つでパケットの宛先アドレスを検索するパケットを受信します。これは特定の状況では非常に有用ですが、この論文ではこれ以上考えていません。
Note that the MPLS label that is distributed in this way is only usable if there is a label switched path between the router that installs a route and the BGP next hop of that route. We do not make any assumption about the procedure used to set up that label switched path. It may be set up on a pre-established basis, or it may be set up when a route which would need it is installed. It may be a "best effort" route, or it may be a traffic engineered route. Between a particular PE router and its BGP next hop for a particular route there may be one LSP, or there may be several, perhaps with different QoS characteristics. All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists.
この方法で配布されるMPLSラベルは、ルートをインストールするルーターとそのルートの次のホップをインストールするルーターの間にラベルが切り替えられたパスがある場合にのみ使用可能であることに注意してください。そのラベルスイッチされたパスをセットアップするために使用される手順について仮定しません。事前に確立されたベースでセットアップされるか、インストールする必要があるルートが設定される場合があります。それは「最善の努力」ルートかもしれませんし、トラフィックエンジニアリングルートかもしれません。特定のPEルーターとそのBGPの間には、次の特定のルートが1つのLSPがあるか、おそらく異なるQoS特性があるいくつかのLSPがある場合があります。VPNアーキテクチャにとって重要なのは、ルーターとそのBGPの次のホップの間にあるラベルが切り替えられたパスが存在することです。
All the usual techniques for using route reflectors [2] to improve scalability, e.g., route reflector hierarchies, are available. If route reflectors are used, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone. One can have separate route reflectors, which do not communicate with each other, each of which supports a subset of the total set of VPNs.
ルートリフレクター[2]を使用してスケーラビリティを向上させるためのすべての通常の手法、たとえばルートリフレクター階層が利用可能です。ルートリフレクターを使用する場合、バックボーンでサポートされているすべてのVPNのすべてのVPN-IPV4ルートを1つのルートリフレクターに知る必要はありません。互いに通信しない別々のルートリフレクターを持つことができ、それぞれがVPNの合計セットのサブセットをサポートします。
If a given PE router is not attached to any of the Target VPNs of a particular route, it should not receive that route; the other PE or route reflector which is distributing routes to it should apply outbound filtering to avoid sending it unnecessary routes. Of course, if a PE router receives a route via BGP, and that PE is not attached to any of the route's target VPNs, the PE should apply inbound filtering to the route, neither installing nor redistributing it.
特定のルートのターゲットVPNのいずれかに与えられたPEルーターが接続されていない場合、そのルートを受け取ってはなりません。ルートを配布している他のPEまたはルートリフレクターは、不要なルートを送信しないようにアウトバウンドフィルタリングを適用する必要があります。もちろん、PEルーターがBGPを介してルートを受信し、そのPEがルートのターゲットVPNのいずれにも接続されていない場合、PEはルートにインバウンドフィルタリングを適用し、それをインストールしたり再配布したりしないでください。
A router which is not attached to any VPN, i.e., a P router, never installs any VPN-IPv4 routes at all.
VPNに接続されていないルーター、つまりPルーターは、VPN-IPV4ルートをまったくインストールしません。
These distribution rules ensure that there is no one box which needs to know all the VPN-IPv4 routes that are supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bound by the capacity of any single device, and therefore can increase virtually without bound.
これらの配布ルールにより、バックボーンでサポートされているすべてのVPN-IPV4ルートを知る必要があるボックスがないことが保証されます。その結果、バックボーン上でサポートできるそのようなルートの総数は、単一のデバイスの容量に拘束されず、したがって、拘束されずに実質的に増加する可能性があります。
A VPN-IPv4 route may be optionally associated with a VPN of Origin attribute. This attribute uniquely identifies a set of sites, and identifies the corresponding route as having come from one of the sites in that set. Typical uses of this attribute might be to identify the enterprise which owns the site where the route leads, or to identify the site's intranet. However, other uses are also possible. This attribute could be encoded as an extended BGP communities attribute.
VPN-IPV4ルートは、オプションのVPNにオプションで関連付けられている場合があります。この属性は、一連のサイトを一意に識別し、対応するルートをそのセットのサイトの1つから来たものと識別します。この属性の典型的な用途は、ルートがリードするサイトを所有する企業を識別したり、サイトのイントラネットを特定することです。ただし、他の用途も可能です。この属性は、拡張されたBGPコミュニティ属性としてエンコードできます。
In situations in which it is necessary to identify the source of a route, it is this attribute, not the RD, which must be used. This attribute may be used when "constructing" VPNs, as described below.
ルートのソースを特定する必要がある状況では、使用する必要があるのはRDではなく、この属性です。この属性は、以下で説明するように、VPNを「構築」するときに使用できます。
It might be more accurate, if less suggestive, to call this attribute the "Route Origin" attribute instead of the "VPN of Origin" attribute. It really identifies the route only has having come from one of a particular set of sites, without prejudice as to whether that particular set of sites really constitutes a VPN.
これを示唆していない場合は、この属性を「vpn of ogin」属性の代わりに「ルート起源」属性と呼ぶ方がより正確かもしれません。それは、特定のサイトのセットが実際にVPNを構成するかどうかについての偏見なしに、特定のサイトのセットの1つからのみルートが得られたルートを実際に識別します。
By setting up the Target VPN and VPN of Origin attributes properly, one can construct different kinds of VPNs.
ターゲットVPNとOrigin属性のVPNを適切に設定することにより、異なる種類のVPNを構築できます。
Suppose it is desired to create a Closed User Group (CUG) which contains a particular set of sites. This can be done by creating a particular Target VPN attribute value to represent the CUG. This value then needs to be associated with the per-site forwarding tables for each site in the CUG, and it needs to be associated with every route learned from a site in the CUG. Any route which has this Target VPN attribute will need to be redistributed so that it reaches every PE router attached to one of the sites in the CUG.
特定のサイトセットを含む閉じたユーザーグループ（CUG）を作成することが望ましいとします。これは、CUGを表すために特定のターゲットVPN属性値を作成することで実行できます。この値は、CUGの各サイトのサイトごとの転送テーブルに関連付ける必要があり、CUGのサイトから学習したすべてのルートに関連付ける必要があります。このターゲットVPN属性を持つルートは、CUGの1つのサイトに接続されたすべてのPEルーターに到達するように、再配布する必要があります。
Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Target Attribute values, one meaning "Hub" and one meaning "Spoke". Then routes from the spokes could be distributed to the hub, without causing routes from the hub to be distributed to the spokes.
あるいは、何らかの理由で、「ハブと話す」種類のVPNを作成する必要があると仮定します。これは、2つのターゲット属性値を使用することで実行できます。1つは「ハブ」を意味し、1つの意味「スポーク」を意味します。その後、スポークからのルートは、ハブからのルートをスポークに配布することなく、ハブに配布できます。
Suppose one has a number of sites which are in an intranet and an extranet, as well as a number of sites which are in the intranet only. Then there may be both intranet and extranet routes which have a Target VPN identifying the entire set of sites. The sites which are to have intranet routes only can filter out all routes with the "wrong" VPN of Origin.
イントラネットとエクストラネットにある多くのサイトと、イントラネットのみにある多くのサイトがあるとします。次に、サイトのセット全体を識別するターゲットVPNを持つイントラネットルートとエクストラネットルートの両方があります。イントラネットルートを持つサイトは、「間違った」原点VPNですべてのルートのみをフィルタリングできます。
These two attributes allow great flexibility in allowing one to control the distribution of routing information among various sets of sites, which in turn provides great flexibility in constructing VPNs.
これらの2つの属性により、さまざまなサイトセット間のルーティング情報の配布を制御できるようにするための柔軟性が非常に高くなり、VPNの構築に大きな柔軟性が提供されます。
If the intermediate routes in the backbone do not have any information about the routes to the VPNs, how are packets forwarded from one VPN site to another?
バックボーンの中間ルートにVPNへのルートに関する情報がない場合、パケットはあるVPNサイトから別のVPNサイトにどのように転送されますか？
This is done by means of MPLS with a two-level label stack.
これは、2レベルのラベルスタックを備えたMPLSによって行われます。
PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. (Certain procedures for setting up label switched paths in the backbone may not require the presence of the /32 address prefixes.)
PEルーター（およびVPN-IPV4アドレスを再配布するASBR）は、バックボーンのIGPルーティングテーブルに自分自身のアドレスプレフィックスを挿入する必要があります。これにより、Backboneネットワークの各ノードでMPLSが各PEルーターに対応するラベルを割り当てることができます。（バックボーンにラベルスイッチされたパスを設定するための特定の手順では、 /32アドレスプレフィックスの存在を必要としない場合があります。）
When a PE receives a packet from a CE device, it chooses a particular per-site forwarding table in which to look up the packet's destination address. Assume that a match is found.
PEがCEデバイスからパケットを受信すると、パケットの宛先アドレスを検索する特定のサイトごとの転送テーブルを選択します。一致が見つかったと仮定します。
If the packet is destined for a CE device attached to this same PE, the packet is sent directly to that CE device.
パケットがこの同じPEに接続されたCEデバイス用に運命づけられている場合、パケットはそのCEデバイスに直接送信されます。
If the packet is not destined for a CE device attached to this same PE, the packet's "BGP Next Hop" is found, as well as the label which that BGP next hop assigned for the packet's destination address. This label is pushed onto the packet's label stack, and becomes the bottom label. Then the PE looks up the IGP route to the BGP Next Hop, and thus determines the IGP next hop, as well as the label assigned to the address of the BGP next hop by the IGP next hop. This label gets pushed on as the packet's top label, and the packet is then forwarded to the IGP next hop. (If the BGP next hop is the same as the IGP next hop, the second label may not need to be pushed on, however.)
パケットがこの同じPEに接続されたCEデバイスに運命づけられていない場合、パケットの「BGP Next Hop」と、BGP Next Hopがパケットの宛先アドレスに割り当てたラベルが見つかります。このラベルは、パケットのラベルスタックに押し込まれ、下のラベルになります。次に、PEはBGP Next HopへのIGPルートを調べ、IGP Next HopとIGP Next HopによるBGP Next Hopのアドレスに割り当てられたラベルを決定します。このラベルは、パケットのトップラベルとして押し出され、パケットはIGP Next Hopに転送されます。（BGPの次のホップがIGP Next Hopと同じ場合、2番目のラベルをプッシュする必要がない場合があります。）
At this point, MPLS will carry the packet across the backbone and into the appropriate CE device. That is, all forwarding decisions by P routers and PE routers are now made by means of MPLS, and the packet's IP header is not looked at again until the packet reaches the CE device. The final PE router will pop the last label from the MPLS label stack before sending the packet to the CE device, thus the CE device will just see an ordinary IP packet. (Though see section 8 for some discussion of the case where the CE desires to received labeled packets.)
この時点で、MPLSはバックボーンを横切って適切なCEデバイスにパケットを運びます。つまり、PルーターとPEルーターによるすべての転送決定がMPLSによって作成され、パケットのIPヘッダーはパケットがCEデバイスに到達するまで再び見られません。最終的なPEルーターは、PACKETをCEデバイスに送信する前にMPLSラベルスタックの最後のラベルをポップします。したがって、CEデバイスには通常のIPパケットが表示されます。（ただし、CEがラベル付きパケットを受け取ることを望んでいる場合のいくつかの議論については、セクション8を参照してください。）
When a packet enters the backbone from a particular site via a particular PE router, the packet's route is determined by the contents of the forwarding table which that PE router associated with that site. The forwarding tables of the PE router where the packet leaves the backbone are not relevant. As a result, one may have multiple routes to the same system, where the particular route chosen for a particular packet is based on the site from which the packet enters the backbone.
パケットが特定のPEルーターを介して特定のサイトからバックボーンに入ると、パケットのルートは、そのサイトに関連付けられたPEルーターが転送テーブルの内容によって決定されます。パケットがバックボーンを離れるPEルーターの転送テーブルは関連性がありません。その結果、同じシステムへの複数のルートがあり、特定のパケットに選択された特定のルートは、パケットがバックボーンに入るサイトに基づいています。
Note that it is the two-level labeling that makes it possible to keep all the VPN routes out of the P routers, and this in turn is crucial to ensuring the scalability of the model. The backbone does not even need to have routes to the CEs, only to the PEs.
すべてのVPNルートをPルーターから排除することを可能にするのは2レベルのラベル付けであり、これがモデルのスケーラビリティを確保するために重要であることに注意してください。バックボーンは、PESにのみCESへのルートを持つ必要さえありません。
The PE routers which attach to a particular VPN need to know, for each of that VPN's sites, which addresses in that VPN are at each site.
特定のVPNに接続するPEルーターは、そのVPNの各サイトについて、各サイトにあるそのVPNの各サイトについて知る必要があります。
In the case where the CE device is a host or a switch, this set of addresses will generally be configured into the PE router attaching to that device. In the case where the CE device is a router, there are a number of possible ways that a PE router can obtain this set of addresses.
CEデバイスがホストまたはスイッチである場合、このアドレスのセットは通常、そのデバイスに接続するPEルーターに構成されます。CEデバイスがルーターである場合、PEルーターがこの一連のアドレスを取得できる方法はいくつかあります。
The PE translates these addresses into VPN-IPv4 addresses, using a configured RD. The PE then treats these VPN-IPv4 routes as input to BGP. In no case will routes from a site ever be leaked into the backbone's IGP.
PEは、これらのアドレスを構成されたRDを使用してVPN-IPV4アドレスに変換します。PEは、これらのVPN-IPV4ルートをBGPへの入力として扱います。サイトからのルートは、バックボーンのIGPに漏れません。
Exactly which PE/CE route distribution techniques are possible depends on whether a particular CE is in a "transit VPN" or not. A "transit VPN" is one which contains a router that receives routes from a "third party" (i.e., from a router which is not in the VPN, but is not a PE router), and that redistributes those routes to a PE router. A VPN which is not a transit VPN is a "stub VPN". The vast majority of VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense.
正確にどのPE/CEルート分布技術が可能であるかは、特定のCEが「トランジットVPN」にあるかどうかによって異なります。「Transit VPN」は、「サードパーティ」からルートを受信するルーター（つまり、VPNにないがPEルーターではないルーターから）を含むルーターを含むものであり、それらのルートをPEルーターに再配置するものです。。トランジットVPNではないVPNは「スタブVPN」です。ほぼすべての企業エンタープライズネットワークを含むVPNの大部分は、この意味で「スタブ」になると予想されます。
The possible PE/CE distribution techniques are:
可能なPE/CE分布技術は次のとおりです。
1. Static routing (i.e., configuration) may be used. (This is likely to be useful only in stub VPNs.)
1. 静的ルーティング（つまり、構成）を使用できます。（これは、スタブVPNSでのみ役立つ可能性があります。）
2. PE and CE routers may be RIP peers, and the CE may use RIP to tell the PE router the set of address prefixes which are reachable at the CE router's site. When RIP is configured in the CE, care must be taken to ensure that address prefixes from other sites (i.e., address prefixes learned by the CE router from the PE router) are never advertised to the PE. More precisely: if a PE router, say PE1, receives a VPN-IPv4 route R1, and as a result distributes an IPv4 route R2 to a CE, then R2 must not be distributed back from that CE's site to a PE router, say PE2, (where PE1 and PE2 may be the same router or different routers), unless PE2 maps R2 to a VPN-IPv4 route which is different than (i.e., contains a different RD than) R1.
2. PEおよびCEルーターはRIPピアである可能性があり、CEはRIPを使用して、CEルーターのサイトで到達可能なアドレスプレフィックスのセットをPEルーターに伝えることができます。RIPがCEで構成されている場合、他のサイトのアドレスプレフィックス（つまり、PEルーターからCEルーターによって学習したアドレスプレフィックス）がPEに宣伝されないことを確認するために注意する必要があります。より正確には、PEルーター（たとえばPE1がVPN-IPV4ルートR1を受信し、その結果、IPv4ルートR2をCEに分配する場合、R2をそのCEのサイトからPEルーターに戻してはなりません。、（PE1とPE2は同じルーターまたは異なるルーターである場合があります）。PE2はR2をVPN-IPV4ルートにマッピングしない限り（つまり、RDとは異なるRDが含まれています）。
3. The PE and CE routers may be OSPF peers. In this case, the site should be a single OSPF area, the CE should be an ABR in that area, and the PE should be an ABR which is not in that area. Also, the PE should report no router links other than those to the CEs which are at the same site. (This technique should be used only in stub VPNs.)
3. PEルーターとCEルーターはOSPFピアである場合があります。この場合、サイトは単一のOSPFエリアである必要があり、CEはその領域のABRである必要があり、PEはその領域にないABRである必要があります。また、PEは、同じサイトにあるCESにルーターリンク以外のルーターリンクを報告しないでください。（この手法は、スタブVPNでのみ使用する必要があります。）
4. The PE and CE routers may be BGP peers, and the CE router may use BGP (in particular, EBGP to tell the PE router the set of address prefixes which are at the CE router's site. (This technique can be used in stub VPNs or transit VPNs.)
4. PEルーターとCEルーターはBGPピアである可能性があり、CEルーターはBGPを使用できます（特に、EBGPはCEルーターのサイトにあるアドレスプレフィックスのセットをPEルーターに伝えます。トランジットVPNS。）
From a purely technical perspective, this is by far the best technique:
純粋に技術的な観点から、これは断然最高のテクニックです。
a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs
a) IGPの代替品とは異なり、これはPEが複数のCESと話すために複数のルーティングアルゴリズムインスタンスを実行する必要はありません
b) BGP is explicitly designed for just this function: passing routing information between systems run by different administrations
b) BGPは、この機能のためだけに明示的に設計されています。さまざまな管理者によって実行されるシステム間でルーティング情報を渡す
c) If the site contains "BGP backdoors", i.e., routers with BGP connections to routers other than PE routers, this procedure will work correctly in all circumstances. The other procedures may or may not work, depending on the precise circumstances.
c) サイトに「BGPバックドア」、つまりPEルーター以外のルーターにBGP接続を備えたルーターが含まれている場合、この手順はあらゆる状況で正しく機能します。他の手順は、正確な状況に応じて機能する場合と機能しない場合があります。
d) Use of BGP makes it easy for the CE to pass attributes of the routes to the PE. For example, the CE may suggest a particular Target for each route, from among the Target attributes that the PE is authorized to attach to the route.
d) BGPを使用すると、CEがルートの属性をPEに簡単に渡すことができます。たとえば、CEは、PEがルートに付着することが許可されているターゲット属性の中から、各ルートの特定のターゲットを提案する場合があります。
On the other hand, using BGP is likely to be something new for the CE administrators, except in the case where the customer itself is already an Internet Service Provider (ISP).
一方、BGPの使用は、顧客自体がすでにインターネットサービスプロバイダー（ISP）である場合を除き、CE管理者にとって新しいものになる可能性があります。
If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site which is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin Attribute (see below).
サイトがトランジットVPNにない場合は、一意の自律システム番号（ASN）が必要ではないことに注意してください。トランジットVPNにないサイトが同じASNを使用できるすべてのCE。これは、プライベートASNスペースから選択でき、PEによって剥ぎ取られます。ルーティングループは、原点属性のサイトを使用することにより防止されます（以下を参照）。
If a set of sites constitute a transit VPN, it is convenient to represent them as a BGP Confederation, so that the internal structure of the VPN is hidden from any router which is not within the VPN. In this case, each site in the VPN would need two BGP connections to the backbone, one which is internal to the confederation and one which is external to it. The usual intra-confederation procedures would have to be slightly modified in order to take account for the fact that the backbone and the sites may have different policies. The backbone is a member of the confederation on one of the connections, but is not a member on the other. These techniques may be useful if the customer for the VPN service is an ISP. This technique allows a customer that is an ISP to obtain VPN backbone service from one of its ISP peers.
一連のサイトがトランジットVPNを構成する場合、それらをBGP連合として表すことができます。これにより、VPNの内部構造はVPN内にないルーターから隠されています。この場合、VPN内の各サイトには、バックボーンへの2つのBGP接続が必要です。バックボーンとサイトに異なるポリシーがある可能性があるという事実を考慮するために、通常のコンフェデレーション内手順をわずかに変更する必要があります。バックボーンは、接続の1つの連合のメンバーですが、他方のメンバーではありません。これらの手法は、VPNサービスの顧客がISPである場合に役立つ場合があります。この手法により、ISPである顧客がISPピアの1つからVPNバックボーンサービスを取得できます。
(However, if a VPN customer is itself an ISP, and its CE routers support MPLS, a much simpler technique can be used, wherein the ISP is regarded as a stub VPN. See section 8.)
（ただし、VPNの顧客自体がISPであり、そのCEルーターがMPLSをサポートする場合、ISPはスタブVPNと見なされるはるかに簡単な手法を使用できます。セクション8を参照）
When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes which exist at a given site, we will simply say that the PE has "learned" the routes from that site.
特定のサイトに存在するアドレスプレフィックスをPEに通知できるさまざまな方法を区別する必要がない場合、PEがそのサイトからルートを「学習」したと言うだけです。
Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign certain attributes to the route. There are three such attributes:
PEがサイトから学習したVPN-IPV4ルートを再配布する前に、特定の属性をルートに割り当てる必要があります。そのような属性は3つあります。
- Site of Origin
- 原産地のサイト
This attribute uniquely identifies the site from which the PE router learned the route. All routes learned from a particular site must be assigned the same Site of Origin attribute, even if a site is multiply connected to a single PE, or is connected to multiple PEs. Distinct Site of Origin attributes must be used for distinct sites. This attribute could be encoded as an extended BGP communities attribute (section 4.2.1).
この属性は、PEルーターがルートを学習したサイトを一意に識別します。特定のサイトから学習したすべてのルートには、サイトが単一のPEに接続されているか、複数のPEに接続されている場合でも、同じ原点属性のサイトを割り当てる必要があります。個別のサイトの属性の個別のサイトは、個別のサイトに使用する必要があります。この属性は、拡張されたBGPコミュニティ属性としてエンコードできます（セクション4.2.1）。
- VPN of Origin
- 原産地のvpn
See section 4.2.1.
セクション4.2.1を参照してください。
- Target VPN
- ターゲットVPN
See section 4.2.1.
セクション4.2.1を参照してください。
In this section, we assume that the CE device is a router.
このセクションでは、CEデバイスがルーターであると仮定します。
In general, a PE may distribute to a CE any route which the PE has placed in the forwarding table which it uses to route packets from that CE. There is one exception: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site.
一般に、PEは、PEがそのCEからパケットをルーティングするために使用する転送テーブルにPEが配置したルートをCEに配布する場合があります。1つの例外があります。ルートのOriginのサイト属性が特定のサイトを識別する場合、そのルートをそのサイトのCEに再配布してはなりません。
In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site which does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.)
ただし、ほとんどの場合、PEがデフォルトルートをCEに単純に配布するだけで十分です。（場合によっては、CEがPEを指すデフォルトルートでCEを構成するだけで十分かもしれません。）これは通常、デフォルトルートを他のサイトに配布する必要がないサイトで機能します。（たとえば、企業のVPNの1つのサイトが企業のインターネットへのアクセスを持っている場合、そのサイトでは他のサイトにデフォルトを配布する必要があるかもしれませんが、そのサイト自体にデフォルトを配布することはできません。）
Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE.
CEからPEにルートを配布するために使用される手順は、PEからCEにルートを配布するためにも使用されます。
In the case where the CE supports MPLS, AND is willing to import the complete set of routes from its VPNs, the PE can distribute to it a label for each such route. When the PE receives a packet from the CE with such a label, it (a) replaces that label with the corresponding label that it learned via BGP, and (b) pushes on a label corresponding to the BGP next hop for the corresponding route.
CEがMPLSをサポートし、VPNからルートの完全なセットをインポートすることをいとわない場合、PEはそのようなルートごとにラベルを配布できます。PEがこのようなラベルでCEからパケットを受信すると、（a）は、そのラベルをBGPを介して学習した対応するラベルに置き換え、（b）対応するルートの次のホップに対応するBGPに対応するラベルをプッシュします。
If the CE/PE route distribution is done via BGP, the CE can use MPLS to support multiple virtual sites. The CE may itself contain a separate forwarding table for each virtual site, which it populates as indicated by the VPN of Origin and Target VPN attributes of the routes it receives from the PE. If the CE receives the full set of routes from the PE, the PE will not need to do any address lookup at all on packets received from the CE. Alternatively, the PE may in some cases be able to distribute to the CE a single (labeled) default route for each VPN. Then when the PE receives a labeled packet from the CE, it would know which forwarding table to look in; the label placed on the packet by the CE would identify only the virtual site from which the packet is coming.
CE/PEルート分布がBGPを介して実行される場合、CEはMPLSを使用して複数の仮想サイトをサポートできます。CE自体には、各仮想サイトの個別の転送テーブルが含まれている場合があります。これは、PEから受け取るルートの原点およびターゲットVPN属性によって示されるように定められています。CEがPEからルートの完全なセットを受信した場合、PEはCEから受信したパケットでアドレスルックアップを行う必要はありません。あるいは、PEは、各VPNの単一（ラベル付き）デフォルトルートをCEに配布できる場合があります。次に、PEがCEからラベル付きパケットを受信すると、どの転送テーブルを調べるかがわかります。CEによってパケットに配置されたラベルは、パケットが来る仮想サイトのみを識別します。
If a particular VPN is actually an ISP, but its CE routers support MPLS, then the VPN can actually be treated as a stub VPN. The CE and PE routers need only exchange routes which are internal to the VPN. The PE router would distribute to the CE router a label for each of these routes. Routers at different sites in the VPN can then become BGP peers. When the CE router looks up a packet's destination address, the routing lookup always resolves to an internal address, usually the address of the packet's BGP next hop. The CE labels the packet appropriately and sends the packet to the PE.
特定のVPNが実際にISPであるが、そのCEルーターがMPLSをサポートしている場合、VPNは実際にスタブVPNとして扱うことができます。CEルーターとPEルーターには、VPNの内部の交換ルートのみが必要です。PEルーターは、これらの各ルートのCEルーターAラベルに配布されます。VPNのさまざまなサイトのルーターは、BGPピアになります。CEルーターがパケットの宛先アドレスを検索すると、ルーティングの検索は常に内部アドレス、通常はパケットのBGP次のホップのアドレスに解決します。CEはパケットを適切にラベル付けし、パケットをPEに送信します。
Under the following conditions:
次の条件下で：
a) labeled packets are not accepted by backbone routers from untrusted or unreliable sources, unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected, and
a) ラベル付きパケットは、IPヘッダーまたはスタックの低いラベルが検査される前にバックボーンを離れることがわかっていない限り、信頼できないソースまたは信頼できないソースからのバックボーンルーターによって受け入れられません。
b) labeled VPN-IPv4 routes are not accepted from untrusted or unreliable sources,
b) ラベル付きVPN-IPV4ルートは、信頼できないソースまたは信頼できないソースから受け入れられません。
the security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones.
このアーキテクチャによって提供されるセキュリティは、フレームリレーまたはATMバックボーンによってVPNSに提供されるものとほぼ同じです。
It is worth noting that the use of MPLS makes it much simpler to provide this level of security than would be possible if one attempted to use some form of IP-within-IP tunneling in place of MPLS. It is a simple matter to refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure the a router to refuse to accept an IP packet if that packet is an IP-within-IP tunnelled packet which is going to a "wrong" place.
MPLSを使用すると、MPLSの代わりに何らかの形のIP-Within-IPトンネルを使用しようとした場合よりも、このレベルのセキュリティを提供することがはるかに簡単になることは注目に値します。上記の条件の最初の条件が適用されない限り、ラベル付きパケットを受け入れることを拒否することは簡単な問題です。そのパケットが「間違った」場所に行くIP-Within-IPトンネルパケットである場合、AルーターをIPパケットの受け入れを拒否するように構成することはかなり困難です。
The use of MPLS also allows a VPN to span multiple SPs without depending in any way on the inter-domain distribution of IPv4 routing information.
MPLSを使用すると、VPNはIPv4ルーティング情報のドメイン間分布に依存することなく、複数のSPSに及ぶことができます。
It is also possible for a VPN user to provide himself with enhanced security by making use of Tunnel Mode IPSEC [5]. This is discussed in the remainder of this section.
また、VPNユーザーがトンネルモードIPSECを使用することにより、セキュリティの強化を提供することも可能です[5]。これについては、このセクションの残りの部分で説明します。
A security-conscious VPN user might want to ensure that some or all of the packets which traverse the backbone are authenticated and/or encrypted. The standard way to obtain this functionality today would be to create a "security tunnel" between every pair of CE routers in a VPN, using IPSEC Tunnel Mode.
セキュリティ対象のVPNユーザーは、バックボーンを横断するパケットの一部またはすべてが認証および/または暗号化されていることを確認することをお勧めします。今日この機能を取得する標準的な方法は、IPSECトンネルモードを使用して、VPN内のCEルーターのすべてのペア間に「セキュリティトンネル」を作成することです。
However, the procedures described so far do not enable the CE router transmitting a packet to determine the identify of the next CE router that the packet will traverse. Yet that information is required in order to use Tunnel Mode IPSEC. So we must extend those procedures to make this information available.
ただし、これまでに説明されている手順では、パケットを送信するCEルーターがパケットが通過する次のCEルーターの識別を決定することはできません。しかし、トンネルモードIPSECを使用するには、その情報が必要です。したがって、この情報を利用できるようにするために、これらの手順を拡張する必要があります。
A way to do this is suggested in [6]. Every VPN-IPv4 route can have an attribute which identifies the next CE router that will be traversed if that route is followed. If this information is provided to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be used.
これを行う方法は[6]で提案されています。すべてのVPN-IPV4ルートには、次のCEルーターを識別する属性を持つことができます。この情報がVPNのすべてのCEルーターに提供される場合、標準のIPSECトンネルモードを使用できます。
If the CE and PE are BGP peers, it is natural to present this information as a BGP attribute.
CEとPEがBGPピアである場合、この情報をBGP属性として提示することは自然です。
Each CE that is to use IPSEC should also be configured with a set of address prefixes, such that it is prohibited from sending insecure traffic to any of those addresses. This prevents the CE from sending insecure traffic if, for some reason, it fails to obtain the necessary information.
IPSECを使用する各CEは、アドレスプレフィックスのセットで構成されているため、これらのアドレスのいずれかに安全でないトラフィックを送信することが禁止されているようにする必要があります。これにより、何らかの理由で必要な情報を取得できない場合、CEが安全でないトラフィックを送信することを防ぎます。
When MPLS is used to carry packets between the two endpoints of an IPSEC tunnel, the IPSEC outer header does not really perform any function. It might be beneficial to develop a form of IPSEC tunnel mode which allows the outer header to be omitted when MPLS is used.
MPLSを使用して、IPSECトンネルの2つのエンドポイント間にパケットを運ぶ場合、IPSEC外側ヘッダーは実際には機能を実行しません。MPLSを使用したときに外側のヘッダーを省略できるようにするIPSECトンネルモードの形式を開発することが有益かもしれません。
Instead of setting up a security tunnel between each pair of CE routers, it may be advantageous to set up a single, multiparty security association. In such a security association, all the CE routers which are in a particular VPN would share the same security parameters (.e.g., same secret, same algorithm, etc.). Then the ingress CE wouldn't have to know which CE is the next one to receive the data, it would only have to know which VPN the data is going to. A CE which is in multiple VPNs could use different security parameters for each one, thus protecting, e.g., intranet packets from being exposed to the extranet.
CEルーターの各ペア間にセキュリティトンネルをセットアップする代わりに、単一のマルチパーティセキュリティ協会をセットアップすることが有利かもしれません。このようなセキュリティ協会では、特定のVPNにあるすべてのCEルーターは、同じセキュリティパラメーター（.e.g。、同じ秘密、同じアルゴリズムなど）を共有します。その後、侵入CEは、データを受信するために次のCEであるCEを知る必要はありません。データがどのVPNになるかを知る必要があります。複数のVPNにあるCEは、それぞれに異なるセキュリティパラメーターを使用する可能性があるため、イントラネットパケットがエクストラネットに公開されるのを防ぎます。
With such a scheme, standard Tunnel Mode IPSEC could not be used, because there is no way to fill in the IP destination address field of the "outer header". However, when MPLS is used for forwarding, there is no real need for this outer header anyway; the PE router can use MPLS to get a packet to a tunnel endpoint without even knowing the IP address of that endpoint; it only needs to see the IP destination address of the "inner header".
このようなスキームでは、「外側ヘッダー」のIP宛先アドレスフィールドに入力する方法がないため、標準のトンネルモードIPSECを使用できませんでした。ただし、MPLSが転送に使用される場合、とにかくこの外側のヘッダーの実際の必要はありません。PEルーターは、MPLSを使用して、そのエンドポイントのIPアドレスを知らなくても、トンネルエンドポイントにパケットを取得できます。「内側ヘッダー」のIP宛先アドレスを見る必要があります。
A significant advantage of a scheme like this is that it makes routing changes (in particular, a change of egress CE for a particular address prefix) transparent to the security mechanism. This could be particularly important in the case of multi-provider VPNs, where the need to distribute information about such routing changes simply to support the security mechanisms could result in scalability issues.
このようなスキームの重要な利点は、ルーティングの変更（特に、特定のアドレスプレフィックスの出力CEの変更）をセキュリティメカニズムに透過的にすることです。これは、マルチプロバイダーVPNSの場合に特に重要である可能性があります。この場合、セキュリティメカニズムをサポートするためにそのようなルーティングの変更に関する情報を配布する必要があると、スケーラビリティの問題が発生する可能性があります。
Another advantage is that it eliminates the need for the outer IP header, since the MPLS encapsulation performs its role.
別の利点は、MPLSカプセル化がその役割を実行するため、外側のIPヘッダーの必要性を排除することです。
Although not the focus of this paper, Quality of Service is a key component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header [10], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [1] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish LSPs with particular QoS characteristics between particular pairs of sites, if that is desirable. Where an MPLS/BGP VPN spans multiple SPs, the architecture described in [7] may be useful. An SP may apply either intserv or diffserv capabilities to a particular VPN, as appropriate.
このペーパーの焦点ではありませんが、サービス品質はVPNサービスの重要な要素です。MPLS/BGP VPNSでは、既存のL3 QoS機能を、Shimヘッダー[10]の「実験的」ビットを使用して、ATMがバックボーンとして使用されている場合、ATM QOS機能を使用して使用される場合、ラベル付きパケットに適用できます。。[1]で議論されているトラフィックエンジニアリング作業は、MPLS/BGP VPNにも直接適用できます。トラフィックエンジニアリングを使用して、特定のサイトのペア間で特定のQoS特性を持つLSPを確立することもできます。MPLS/BGP VPNが複数のSPSにまたがる場合、[7]で説明されているアーキテクチャが役立つ場合があります。SPは、必要に応じて、特定のVPNにINTSERVまたはDiffServ機能のいずれかを適用する場合があります。
We have discussed scalability issues throughout this paper. In this section, we briefly summarize the main characteristics of our model with respect to scalability.
この論文全体でスケーラビリティの問題について説明しました。このセクションでは、スケーラビリティに関してモデルの主な特性を簡単に要約します。
The Service Provider backbone network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (which are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.
サービスプロバイダーバックボーンネットワークは、（a）PEルーター、（b）BGPルートリフレクター、（c）Pルーター（PEルーターでもルートリフレクターでもない）、およびマルチプロバイダーVPNSの場合（D）で構成されています。ASBRS。
P routers do not maintain any VPN routes. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. The use of two levels of labeling is what makes it possible to keep the VPN routes out of the P routers.
PルーターはVPNルートを維持しません。VPNトラフィックを適切に転送するには、PルーターはPEルーターとASBRへのルートのみを維持する必要があります。2つのレベルの標識を使用することは、VPNルートをPルーターから締め出すことを可能にするものです。
A PE router to maintains VPN routes, but only for those VPNs to which it is directly attached.
VPNルートを維持するためのPEルーターは、直接接続されているVPNのみです。
Route reflectors and ASBRs can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs provided by the Service Provider. Thus no single Route Reflector or ASBR is required to maintain routes for all the VPNs.
ルートリフレクターとASBRをVPN間で分割できるため、各パーティションはサービスプロバイダーが提供するVPNのサブセットのみのルートのみを運ぶことができます。したがって、すべてのVPNのルートを維持するために、単一のルートリフレクターまたはASBRは必要ありません。
As a result, no single component within the Service Provider network has to maintain all the routes for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
その結果、サービスプロバイダーネットワーク内の単一のコンポーネントは、すべてのVPNのすべてのルートを維持する必要はありません。したがって、VPNの数の増加をサポートするネットワークの総容量は、個々のコンポーネントの容量によって制限されません。
Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms.
Cisco Systemsは、このドキュメントで開示されているすべての技術のいくつかについて、特許またはその他の知的財産保護を求める場合があります。この文書から生じる基準がCisco Systemsに割り当てられた1つ以上の特許によって保護されている場合、または保護されている場合、Ciscoはこれらの特許を開示し、合理的かつ非差別的な条件でライセンスを取得する予定です。
Security issues are discussed throughout this memo.
このメモ全体でセキュリティの問題について説明します。
Significant contributions to this work have been made by Ravi Chandra, Dan Tappan and Bob Thomas.
この作業への多大な貢献は、ラビ・チャンドラ、ダン・タッパン、ボブ・トーマスによって行われました。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
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
Yakov Rekhter Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134
EMail: yakov@cisco.com
[1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.
[1] Awduche、Berger、Gan、Li、Whallow、およびSrinavasan、「LSPトンネルのRSVPへの拡張」が進行中です。
[2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[2] Bates、T。およびR. Chandrasekaran、「BGPルートリフレクション：フルメッシュIBGPの代替」、RFC 1966、1996年6月。
[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[3] Bates、T.、Chandra、R.、Katz、D。およびY. Rekhter、「BGP4のマルチプロトコル拡張」、RFC 2283、1998年2月。
[4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.
[4] Gleeson、Heinanen、Armitage、「IPベースの仮想プライベートネットワークのフレームワーク」が進行中です。
[5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] ケントとアトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.
[6] Li、「MPLSを使用したCPEベースのVPN」、1998年10月、進行中の作業。
[7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[7] Li、T。およびY. Rekhter、「差別化されたサービスと交通工学のプロバイダーアーキテクチャ（ペースト）」、RFC 2430、1998年10月。
[8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.
[8] RekhterとRosen、「BGP4でラベル情報を運ぶ」、進行中の作業。
[9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[9] Rosen、Viswanathan、およびCallon、「Multiprotocolラベルスイッチングアーキテクチャ」は、進行中の作業です。
[10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.
[10] Rosen、Rekhter、Tappan、Farinacci、Fedorkow、Li、およびConta、「MPLSラベルスタックエンコーディング」、進行中の作業。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。