Network Working Group E. Rosen
Request for Comments: 4365 Cisco Systems, Inc.
Category: Informational February 2006
Applicability Statement for BGP/MPLS IP
Virtual Private Networks (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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section.
この文書は、RFC 4364および参考文献のセクションに記載されている他の文献に記載された仮想プライベートネットワーク（VPN）ソリューションの適用性に関する声明を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. SP Provisioning Model ...........................................4
3. Supported Topologies and Traffic Types ..........................6
4. Isolated Exchange of Data and Routing Information ...............7
5. Access Control and Authentication ...............................9
6. Security Considerations .........................................9
6.1. Protection of User Data ....................................9
6.2. SP Security Measures ......................................10
6.3. Security Framework Template ...............................12
7. Addressing .....................................................18
8. Interoperability and Interworking ..............................19
9. Network Access .................................................19
9.1. Physical/Link Layer Topology ..............................19
9.2. Temporary Access ..........................................19
9.3. Access Connectivity .......................................20
10. Service Access ................................................21
10.1. Internet Access ..........................................21
10.2. Other Services ...........................................21
11. SP Routing ....................................................22
12. Migration Impact ..............................................22
13. Scalability ...................................................23
14. QoS, SLA ......................................................26
15. Management ....................................................27
15.1. Management by the Provider ...............................27
15.2. Management by the Customer ...............................28
16. Acknowledgements ..............................................28
17. Normative References ..........................................29
18. Informative References ........................................29
This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in [BGP-MPLS-IP-VPN] and other documents listed in the References section. We refer to these as "BGP/MPLS IP VPNs", because Border Gateway Protocol (BGP) is used to distribute the routes, and Multiprotocol Label Switching (MPLS) is used to indicate that particular packets need to follow particular routes. The characteristics of BGP/MPLS IP VPNs are compared with the requirements specified in [L3VPN-REQS].
この文書では、[BGP-MPLS-IP-VPN]を参照のセクションに記載されている他の文献に記載仮想プライベートネットワーク（VPN）ソリューションの適用に関する声明を提供します。私たちは、ボーダーゲートウェイプロトコル（BGP）はルートを配布するために使用されているので、「BGP / MPLS IP VPN」を、これらを参照し、マルチプロトコルラベルスイッチング（MPLS）は、その特定のパケットが特定の経路をたどる必要がある示すために使用されます。 BGP / MPLS IP VPNの特性は[L3VPN-REQS]で指定された要件と比較されます。
A VPN service is provided by a Service Provider (SP) to a customer (sometimes referred to as an enterprise). BGP/MPLS IP VPNs are intended for the situation in which:
VPNサービスは、顧客（時には企業と呼ぶ）にサービスプロバイダ（SP）によって提供されます。 BGP / MPLS IP VPNは、状況のために意図されています。
- The customer:
- 顧客：
* uses the VPN only for carrying IP packets.
*のみIPパケットを運ぶためのVPNを使用しています。
* does not want to manage a routed backbone; the customer may be using routing within his sites, but wishes to outsource the inter-site routing to the SP.
*ルーティングされたバックボーンを管理する必要はありません。顧客が自分のサイト内のルーティングを使用しますが、SPへのルーティングサイト間を外部委託することを希望することができます。
* wants the SP to make the backbone and its routing completely transparent to the customer's own routing.
* SPは顧客自身のルーティングへのバックボーンとそのルーティングは完全に透明にしたいと考えています。
If the customer has a routed infrastructure at his sites, he does not want his site routing algorithms to need to be aware of any part of the SP backbone network, other than the Provider Edge (PE) routers to which the sites are attached. In particular, the customer does not want his routers to need to be aware of either the native structure of the SP backbone or an overlay topology of tunnels through the SP backbone.
顧客が自分のサイトでルーティングされたインフラを持っている場合、彼は彼のサイトのルーティングアルゴリズムは、サイトが結合しているプロバイダーエッジ（PE）ルータ以外の、SPのバックボーンネットワークの任意の部分を意識する必要はしたくありません。具体的には、顧客が自分のルータがSPバックボーンの天然の構造やSPのバックボーンを通してトンネルのオーバーレイ・トポロジーのいずれかを意識する必要がしたくありません。
- The Service Provider:
- サービスプロバイダー：
* has an IP backbone, with MPLS-enabled edge routers, and
possibly (though not necessarily) with MPLS-enabled core
routers.
* wants to provide a service that meets the customer requirements above.
*上記の顧客の要件を満たすサービスを提供したいと考えています。
* does not want to maintain a distinct overlay topology of tunnels for each customer.
*各顧客のためのトンネルの明確なオーバーレイ・トポロジーを維持する必要はありません。
The basic principle is to model each VPN as a self-contained "internet", where each site makes one or more access connections to an SP, sends the SP its routing information, and then relies on the SP to distribute routing information to and from the other sites in that same VPN. The service differs from Internet service, however, in that the SP strictly controls the distribution of this routing information so that routes from within a VPN are not sent outside the VPN, unless that is explicitly authorized by the customer. In fact, even within the VPN, the distribution of routes may be controlled by the SP so as to meet some policy of the customer.
基本的な原理は、各サイトは、SPへの1つ以上のアクセス接続を行い、そのルーティング情報SPを送信し、その後にしてからルーティング情報を配布するためにSPに依存している自己完結型の「インターネット」、各VPNをモデル化することです同じVPN内の他のサイト。それが明示的に顧客によって承認されない限り、サービスは、SPは厳密にVPN内のルートがVPN外に送信されないように、このルーティング情報の配布を制御することで、しかし、インターネットサービスとは異なります。顧客のいくつかのポリシーを満たすように、実際には、さらにVPN内で、ルートの分布は、SPによって制御することができます。
The routers at a given customer site need not be routing peers of the routers at other customer sites, and indeed need not know anything about the internal structure of other customer sites. In fact, different routing protocols may run at the different sites, with each site using whatever protocol is most appropriate for that particular site.
特定の顧客サイトでのルータは、他の顧客サイトでルータのルーティングピアである必要はなく、実際に他の顧客サイトの内部構造について何も知る必要はありません。実際には、異なるルーティングプロトコルは、その特定のサイトのために最も適切なものは何でもプロトコル使用して各サイトで、別のサイトで実行することができます。
If EBGP (the BGP procedures used between BGP speakers from different Autonomous Systems) is used on the access links that connect a Provider Edge router (PE router) to a Customer Edge router (CE router), then the SP and the customer do NOT peer in any Interior Gateway Protocol (IGP), i.e., intra-domain routing algorithm).
EBGP（BGP手順が異なる自律システムからのBGPスピーカ間で使用される）は、カスタマーエッジルータ（CEルータ）へのプロバイダーエッジルータ（PEルータ）に接続するアクセスリンクで使用されている場合、SPと顧客がピアをしないでくださいどんなインテリアゲートウェイプロトコル（IGP）で、すなわち、ドメイン内ルーティングアルゴリズム）。
BGP/MPLS IP VPNs are optimized for the situation in which a customer (an enterprise) expects a service provider to operate and maintain the customer's "backbone" (i.e., the customer's inter-site routing). As such, the service provider becomes a "business partner" of the enterprise. The technical mechanisms accommodate the case in which a number of closely cooperating SPs can jointly offer the VPN service to a customer, in that the BGP-based route distribution mechanisms can operate between different SPs. If a set of SPs has sufficient agreements with respect to Quality of Service (QoS), Service Level Agreement (SLA), etc., then the customer's VPN could have sites attached to different SPs from that set.
BGP / MPLS IP VPNは、顧客（企業）は、サービスプロバイダが動作し、お客様の「バックボーン」（すなわち、顧客のサイト間ルーティング）を維持することを期待する状況に合わせて最適化されています。そのため、サービスプロバイダは、企業の「ビジネスパートナー」となります。技術的なメカニズムは、密接に協働のSPの数が共同で、顧客にVPNサービスを提供できるようにBGPベースのルート配布メカニズムが異なるSP間で動作可能な場合に対処します。 SPのセットは、などのサービス品質（QoS）、サービスレベル契約（SLA）、に対して十分な協定を結んでいる場合には、顧客のVPNは、そのセットは異なるSPに取り付けたサイトを持つことができます。
[BGP-MPLS-IP-VPN] specifies the inter-AS (Autonomous System) mechanisms that allow a single VPN to have sites attached to different SPs. However, the design center is not an environment where a given VPN is spread among a very large number (e.g., hundreds) of SPs.
[BGP-MPLS-IP-VPNは単一のVPNが異なるSPに取り付けられた部位を有することを可能にするインターAS（自律システム）の機構を指定します。しかし、デザイン・センターは、指定されたVPNはSPの非常に多数の（例えば、数百）に分散されている環境ではありません。
In cases where remote offices, individual telecommuters, etc., must use the public Internet to access the VPN, it is possible to "tunnel" the remote traffic to a PE router, and the PE router will treat the traffic as if it had arrived over an interface connected to the PE. Remote Point-to-Point Protocol (PPP) connections can be tunneled via Layer 2 Tunneling Protocol (L2TP) to a PE router; IPsec tunnels can also be used to tunnel traffic to a PE router across the public Internet. Of course, when the public Internet is used, issues such as QoS and SLAs must be carefully considered.
リモートオフィス、個々の在宅勤務などのケースでは、VPNにアクセスするために公共のインターネットを使用する必要があり、それは「トンネル」にPEルータへのリモートトラフィック可能であり、それが到着したかのようにPEルータは、トラフィックを処理しますPEに接続されたインタフェースを介し。リモートポイントツーポイントプロトコル（PPP）接続は、PEルータにレイヤ2トンネリングプロトコル（L2TP）を介してトンネリングすることができます。 IPsecトンネルは、公衆インターネット経由でPEルータにトンネルトラフィックにも使用することができます。公共のインターネットが使用されている場合は、当然、そのようなQoSとSLAなどの問題を慎重に考慮しなければなりません。
Some customers want to connect their sites over the public Internet, creating a VPN "virtual backbone", purchasing connectivity for a given site from whatever Internet Service Provider (ISP) offers the best price for connecting that site. A BGP/MPLS IP VPN is not an appropriate solution for such customers; they instead need to consider solutions (either customer-managed or provider-managed) that interconnect their sites via an overlay of secure tunnels across the Internet. (See, for example, [IPSEC-VPN].)
一部のお客様には、そのサイトを接続するための最良の価格を提供していますどのようなインターネットサービスプロバイダ（ISP）から指定したサイトの接続を購入し、VPN「仮想バックボーン」を作成、公共のインターネット上で自分のサイトを接続したいです。 BGP / MPLS IP VPNは、このような顧客のための適切なソリューションではありません。彼らは代わりにインターネットを介してセキュアなトンネルのオーバーレイを経由して自分のサイトを相互接続ソリューション（顧客管理やプロバイダの管理のいずれか）を検討する必要があります。 （例えば、[IPSEC-VPN]を参照）。
Some customers who do not want to connect their sites via secure site-to-site tunnels across the Internet may nevertheless want to maintain complete control over the routing in their VPN backbone. These customers will not want a "managed routing service" such as is provided by BGP/MPLS IP VPNs, since that hides all details of the backbone routing and topology from the customer. Rather, they may prefer a "virtual router" service, in which the tunnels through the SP networks are visible as links to the customer's routing algorithm. (See, for example, [VR-VPN].)
インターネットを介した安全なサイトツーサイトトンネルを経由して自分のサイトを接続したくない一部のお客様には、それにもかかわらず、彼らのVPNバックボーンにおけるルーティングを完全に制御を維持することができます。 BGP / MPLS IP VPNのによって提供されるようなことは、顧客からのバックボーン・ルーティングとトポロジのすべての詳細を隠すため、これらの顧客は、「管理対象ルーティングサービス」を望んでいます。むしろ、彼らは、SPネットワークを介したトンネルは、顧客のルーティングアルゴリズムへのリンクとして表示される「仮想ルーター」サービスを、好むかもしれません。 （例えば、[VR-VPN]を参照）。
If a particular VPN attaches to a particular PE router, the SP must configure that PE router with a VPN Routing and Forwarding table (VRF), a routing table that is specific to the specified VPN. (This is known as a VPN Forwarding Instance (VFI) in the language of [L3VPN-REQS] and [L3VPN-FRMWRK].) Each interface or sub-interface at that PE that attaches to a site in the specified VPN (i.e., each local access link of that VPN) must be configured so as to be associated with that VRF. Each such interface may be unnumbered or may be assigned an address that is unique within the VPN's address space. In general, a routing algorithm needs to be run on each of these links (though static routing can be used instead). The routing algorithm can be EBGP, or an IGP such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). (IF OSPF is used, the procedures of [VPN-OSPF] MUST be implemented.) If an IGP is run on the access links, the IGP MUST be a separate IGP instance, different than the IGP instance running among the backbone routers, and different than the IGP instance running on the access links of any other VPN. Static routing is also allowed.
特定のVPNは、特定のPEルータに接続されている場合、SPは、VPNルーティングおよび転送テーブル（VRF）、指定されたVPNに固有のルーティングテーブルとそのPEルータを設定しなければなりません。指定されたVPN（すなわち、中の部位に付着することPEで（これは[L3VPN-REQS]および[L3VPN-FRMWRK]の言語にVPN転送インスタンス（VFI）として知られている。）それぞれのインターフェースまたはサブインターフェースそのVRFに関連付けられるように、そのVPNの各ローカルアクセスリンク）を設定する必要があります。それぞれのそのようなインターフェイスは、アンナンバードであってもよいし、VPNのアドレス空間内で一意のアドレスを割り当てることもできます。 （スタティックルーティングを代わりに使用することができるが）一般的に、ルーティングアルゴリズムは、これらのリンクの各々で実行される必要があります。ルーティングアルゴリズムはEBGP、またはIGPなどのルーティング情報プロトコル（RIP）またはオープン最短パスファースト（OSPF）とすることができます。 （OSPFを使用する場合、[VPN-OSPF]の手順が実施されなければならない。）IGPは、アクセスリンク上で実行される場合、IGPは、バックボーンルータ間で実行中のIGPインスタンスとは異なる別個のIGPのインスタンスである必要があり、そして他のVPNのアクセスリンク上で実行されているIGPインスタンスとは異なります。また、スタティックルーティングは許可されています。
The VRF is populated automatically with routes distributed from locally attached CE routers via whatever routing algorithm is run on the PE/CE links. It is also populated automatically with routes distributed from other VRFs via BGP. Standard routing decision processes are used to automatically select the proper routes. Static configuration of routes in the VRF is optional.
VRFは、PE / CEリンク上で実行されるどのようなルーティングアルゴリズムを介してローカルに接続されたCEルータから配信ルートが自動的に入力されます。また、BGPを介して他のVRFから配信ルートが自動的に入力されます。標準的なルーティングの決定プロセスは、自動的に適切な経路を選択するために使用されます。 VRF内のルートの静的な構成は任意です。
Each PE router must run BGP, and must be pre-configured with the identities of a small set of BGP Route Reflectors, with which it is to peer via IBGP. ("IBGP" refers to the BGP procedures used between BGP speakers from the same Autonomous System.)
各PEルータは、BGPを実行する必要があり、それはIBGPを介してピアにしているBGPルートリフレクタの小さな集合のアイデンティティで事前に構成されなければなりません。 （「IBGP」は、同じ自律システムのBGPスピーカ間で使用されるBGP手順をいいます。）
In lieu of using Route Reflectors, one could configure each PE with the identities of all the other PEs, and set up a full mesh of IBGP connections. While this might be adequate for small networks, it would not scale well to large networks; the use of Route Reflectors is necessary to achieve scalability. See section 4.3.3 of [BGP-MPLS-IP-VPN] for a more complete discussion of the use of Route Reflectors, and related scalability mechanisms such as Outbound Route Filtering.
ルートリフレクタを使用する代わりに、1は、他のすべてのPEのアイデンティティと各PEを構成し、IBGP接続のフルメッシュを設定することができます。これは小さなネットワークには十分かもしれませんが、それは大規模ネットワークにうまくスケールではないでしょう。ルートリフレクタを使用すると、スケーラビリティを達成するために必要です。ルートリフレクタの使用のより完全な議論、およびそのような往路フィルタリングなどの関連する拡張性メカニズムは[BGP-MPLS-IP-VPN]のセクション4.3.3を参照。
Each VRF must be configured with three parameters:
各VRFには、三つのパラメータを設定する必要があります。
- A Route Distinguisher. This is a globally unique 8-byte value. Each VRF may have a unique Route Distinguisher (RD), or there may be a single unique RD for an entire VPN. When BGP is used to distribute VPN routing information across the SP backbone, this value is prepended to the VPN's IPv4 address prefixes, creating a new address family, the VPN-IPv4 address family. Thus, even when two VPNs have overlapping IPv4 address spaces, they have unique VPN-IPv4 address spaces.
- ルート識別子。これは、グローバルに一意の8バイトの値です。各VRFは、一意のルート識別子（RD）を有していてもよく、または全体のVPNのための単一の一意RDがあってもよいです。 BGPがSPのバックボーンでVPNルーティング情報を配信するために使用されている場合、この値は新しいアドレスファミリを作成し、VPNのIPv4アドレスのプレフィックスの前に追加され、VPN-IPv4アドレスファミリ。このように、2つのVPNが重なったIPv4アドレス空間を持っている場合でも、彼らは独自のVPN-IPv4アドレス空間を持っています。
- One or more Export Route Targets. A Route Target (RT) is a globally unique 8-byte value that BGP carries, as the Extended Communities Route Target attribute, along with routes that are exported form the VRF.
- 1つの以上のエクスポートルートターゲット。ルートターゲット（RT）は、BGPはVRF形態エクスポートされる経路とともに、拡張コミュニティルートターゲット属性として、担持グローバルに一意の8バイトの値です。
- One or more Import Route Targets. This RT is used to select routes to be imported from other VRFs into this VRF.
- 1つの以上のインポートルートターゲット。このRTは、このVRFに他のVRFからインポートするルートを選択するために使用されます。
In the simplest cases and most common cases, the Export RT, Import RT, and RD can be identical, and all VRFs in the same VPN will distribute routes to each other (a typical intranet). In more complex cases, they can be set differently, allowing a very fine degree of control over the distribution of routes among VRFs. This can be used to create extranets or to enforce various customer policies. In complicated cases, particular Export RTs can be assigned to particular routes using router management mechanisms. One advantage to not requiring the RD to be the same as any RT is that this may allow an RD value to be automatically determined for each VRF; RT values, on the other hand, must always be configured.
最も単純なケースであり、最も一般的なケースでは、エクスポートRT、インポートRT、およびRDは、同一であってもよく、同じVPN内のすべてのVRFは互いに（典型的イントラネット）へのルートを配布します。より複雑なケースでは、彼らはのVRF間でのルートの分布を制御する非常に細かい程度をできるように、別々に設定することができます。これは、エクストラネットを作成したり、様々な顧客のポリシーを適用するために使用することができます。複雑なケースでは、特定のエクスポートのRTは、ルータ管理メカニズムを使用して、特定のルートに割り当てることができます。一つの利点は、任意RTこれはRD値が自動的に各VRFについて決定されることを可能にすることであるように同じになるようにRDを必要としないために。 RT値は、他の一方で、必ず設定する必要があります。
Adding a new site to a VPN is a matter of attaching the site's CE router to a PE router, configuring the interface, and, if a VRF for that VPN already exists in the PE router, associating that interface with the VRF. If a VRF for that VPN does not already exist in the PE, then one must be configured as specified above. Changes to the configuration of a PE are automatically reflected via BGP to the other PEs.
VPNに新しいサイトを追加すると、そのVPNのためのVRFが既にVRFとそのインターフェイスを関連付け、PEルータに存在する場合、インターフェイスの設定、PEルータにサイトのCEルータを取り付けるの問題であり、そして。そのVPNのためのVRFが既にPEに存在しない場合、上記指定され、その後、一方が構成されなければなりません。 PEの構成の変更は自動的に他のPEへのBGPを介して反射されます。
The RTs and RDs are made unique by being structured as an SP identifier followed by a number which is assigned by the identified SP. SPs may be identified by their AS numbers, or by a registered IP address owned by that SP.
RTSとRDSは、識別されたSPによって割り当てられた番号に続くSP識別子として構成されることにより、一意にされています。 SPは自分のAS番号によって、またはそのSPが所有する登録IPアドレスによって識別することができます。
Although RTs are encoded as BGP Extended Communities, the encoding itself distinguishes them from any other kind of BGP Extended Community.
RTがBGP拡張コミュニティとしてエンコードされていますが、エンコード自体はコミュニティ拡張BGPの他の種類からそれらを区別します。
The scheme is optimized for full inter-site connectivity, in the sense that this is what the simplest configurations provide.
スキームは、これは最も単純な構成が提供するものであるという意味で、完全なサイト間接続用に最適化されています。
However, the SP has full control, through the mechanism of Route Targets, of the distribution of routing information among the set of VRFs. This enables the SP to provide hub-and-spoke or partial mesh connectivity as well as full mesh connectivity.
しかし、SPは、VRFの一連の間でルーティング情報の配布のルートターゲットの機構を介して、完全な制御を有しています。これは、ハブアンドスポークまたは部分的にメッシュ接続だけでなく、フルメッシュ接続性を提供するために、SPを可能にします。
Note that, strictly speaking, the scheme does not create a topology, as it does not create layer 2 connections among the sites. It does, however, allow for control over the IP connectivity among the sites. It is also possible to constrain the distribution of routing in arbitrary ways, e.g., so that data from site A to site B must travel through a third site C. (In fact, if it is desired to do so, this level of control can be specified at the granularity of a single route.)
それはサイト間のレイヤ2つの接続を作成しないようなお、厳密に言えば、スキームは、トポロジを作成しません。それは、しかし、サイト間のIP接続を制御するために認めていません。サイトBにサイトAからのデータは、実際には第三のサイトC.（通って移動しなければならないので、そうすることが所望される場合、このレベルの制御ができ、例えば、任意の方法でルーティングの分布を制限することも可能です単一経路の単位で指定されます。）
It is possible for some of the routes from a particular customer site A to be distributed to one set of remote sites, while other routes from site A are distributed to a different set of remote sites. This is done with the Route Target mechanism previously described.
サイトAから他のルートがリモートサイトの異なるセットに分配している間、特定の顧客サイトAからのルートのいくつかは、リモートサイトの一組に配布することが可能です。これは、前述のルートターゲット機構が行われます。
Unicast IP traffic is fully supported. Customer IP packets are passed transparently.
ユニキャストIPトラフィックは完全にサポートされています。お客様のIPパケットは透過的に渡されます。
Multicast IP traffic is optionally supported, if the SP provides the optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are, however, scaling implications to the use of these mechanisms. Discussion of these implications is deferred.
SPは、[BGP-MPLS-MCAST-VPN]の任意のメカニズムを提供する場合、マルチキャストIPトラフィックは、必要に応じて、サポートされています。これらのメカニズムの使用に影響をスケーリング、しかし、があります。これらの影響の議論は延期されます。
Non-IP traffic is not supported. If support for non-IP traffic is necessary, either the SP must additionally provide a layer 2 tunneling service or the customer must use IP tunneling.
非IPトラフィックはサポートされていません。非IPトラフィックのサポートが必要な場合は、いずれかのSPは、さらにレイヤ2トンネリングサービスを提供しなければならないか、顧客がIPトンネリングを使用する必要があります。
In general, customer routers at different sites do not become routing peers. However, a customer may, if he so desires, allow routers at different sites to be routing peers over a link that is NOT part of the VPN service. Such peering relationships are known as "IGP backdoors". To ensure the proper operation of routing when IGP backdoors are present, each VPN route that is distributed by the SP is distributed along with a corresponding routing metric. This enables the customer's IGP to compare the "backdoor routes" properly with the routes that use the SP backbone. In the particular case where a customer running OSPF within his sites wishes to have IGP backdoors, he should run OSPF on the PE/CE link, and the PEs should run the procedures of [VPN-OSPF]. (The CEs do NOT require any special OSPF procedures.)
一般的に、異なるサイトでの顧客のルータは、ルーティングピアにはなりません。しかし、顧客は、彼がそう望むならば、異なるサイトでのルータがVPNサービスの一部ではありませんリンク上のピアをルーティングできるようにすることができます。このようなピアリング関係は「IGPバックドア」として知られています。 IGPバックドアが存在しているルーティングの適切な動作を保証するために、SPによって配布される各VPN経路は、対応するルーティングメトリックと共に配布されます。これはSPのバックボーンを使用したルートを適切に「バックドアのルートを」比較するために、顧客のIGPを可能にします。彼のサイト内OSPFを実行している顧客はIGPバックドアを持っているしたい特定のケースでは、彼はPE / CEリンク上でOSPFを実行する必要があり、およびPEは、[VPN-OSPF]の手順を実行する必要があります。 （CEは、特別なOSPFの手続きを必要としません。）
The Route Target mechanism is used to control the distribution of routing information, so that routes from one VPN do not get sent to another. VPN routes are treated by BGP as a different address family than general Internet routes. Routes from a VRF do not get leaked to the Internet unless the VRF has been explicitly configured to allow it (and this is NOT the default).
ルートターゲット機構は、一つのVPNからのルートが別に送信されないように、ルーティング情報の配布を制御するために使用されます。 VPNルートは、一般的なインターネットルートとは異なるアドレスファミリとしてBGPによって処理されています。 VRFは、明示的に許可するように設定されていない限り、VRFからのルートは、インターネットに流出されません（これはデフォルトではありません）。
The way in which a particular VPN is divided into sites, or the topology of any particular VPN site, is hidden from the Internet and from other VPNs. (Of course, if a particular site can receive Internet traffic, and if it responds to traceroute probes from the Internet, then any user of the Internet can learn something about the site topology. The fact that the site is in a VPN does not make this any easier or any harder.)
特定のVPNは、サイトに分割する方法、または特定のVPNサイトのトポロジーは、インターネットから、その他のVPNから隠されています。 （もちろん、特定のサイトには、インターネットトラフィックを受信することができ、そしてそれは、インターネットからのプローブをトレースルート応答した場合、その後、インターネットのすべてのユーザーがサイトトポロジについて何かを学ぶことができます。サイトはVPNであるという事実はなりません。このいずれかの簡単に、または任意難しいです。）
Similarly, Internet routes do not get leaked into the VPN, unless a VRF of that VPN is explicitly configured to import the Internet routes.
そのVPNのVRFを明示的にインターネットのルートをインポートするように設定されていない限り、同様に、インターネットのルートは、VPNに漏洩しません。
Proper configuration is essential to maintaining the isolation. In particular, each access link must be associated with the proper VRF for that access link, and each VRF must be configured with the proper set of RTs.
適切な構成は、分離を維持するために不可欠です。具体的には、各アクセスリンクは、アクセスリンクのための適切なVRFに関連付けられている必要があり、各VRFは、RTSの適切なセットで構成されなければなりません。
A number of means for exchanging reachability information between the PE and CE devices are supported: static routing, EBGP, and RIP are supported by the procedures of [BGP-MPLS-IP-VPN]. If the procedures of [VPN-OSPF] and [OSPF-2547-DNBIT] are implemented, OSPF may be used. If OSPF is used between two VPN sites that are in the same OSPF area, and if it is desired for routes over the VPN backbone to be preferred to the OSPF intra-site routes, then the "sham link" procedures of [VPN-OSPF] must be used.
PEとCEデバイス間の到達可能性情報を交換するための手段の数は、サポートされている：スタティックルーティング、EBGP、及びRIPは[BGP-MPLS-IP-VPN]の手順により支持されています。 [VPN-OSPF]の手順および[OSPF-2547-DNBIT]が実装されている場合、OSPFを使用してもよいです。 OSPFは、同じOSPFエリアにある2つのVPNサイトの間で使用される場合、OSPFイントラサイトのルートに好ましいことがVPNバックボーン上のルートのために所望される場合、[VPN-OSPF、次いで「偽リンク」手順]を使用する必要があります。
The routing protocols used among the customer routers are not in any way restricted by the VPN scheme, as whatever IGP is used within the VPN, the PE/CE access links may run EBGP, or may otherwise be in a different routing domain than the site's internal links.
どんなIGPは、VPN内で使用されたとして、顧客のルータ間で使用されるルーティングプロトコルは、VPNスキームによって制限どのような方法ではありませんが、PE / CEアクセスリンクは、EBGPを実行することができる、またはそれ以外のサイトのとは別のルーティングドメインであってもよく、内部リンク。
BGP is used for passing routing information among SPs. BGP may be authenticated by use of the TCP MD5 option, or by operating through an IPsec tunnel.
BGPは、SPS間ルーティング情報を渡すために使用されます。 BGPは、TCP MD5オプションの使用によって、またはIPsecトンネルを介して操作することにより認証することができます。
Data traveling between two customer sites is encapsulated while in transit through the backbone. The encapsulation contains sufficient information to ensure that the packet is sent to the proper PE router, and then, in conjunction with the VRF and related information at that PE, to the proper CE routers.
2つの顧客サイト間を移動するデータは、バックボーンを通じて輸送中にしばらく時間が封入されています。カプセル化は、パケットが適切なCEルータに、そのPEでVRFおよび関連情報と併せて、次に適切なPEルータに送信され、そしてされることを保証するために十分な情報を含みます。
If two VPNs attach to the same PE, there is strict separation of forwarding at that PE, as well as strict separation of the routing information.
2つのVPNが同じPEに接続した場合、そのPEに転送の厳密な分離、ならびにルーティング情報の厳格な分離が存在します。
Isolation of traffic is similar to that provided by classical L2 VPNs which are based on Frame Relay or Asynchronous Transfer Mode (ATM). As in classical L2 VPNs, the customer must rely on the SP to properly configure the backbone network to ensure proper isolation and to maintain the security of his communications gear.
トラフィックの分離は、フレームリレー、非同期転送モード（ATM）に基づいている古典的なL2のVPNによって提供されるものと同様です。古典L2 VPNのと同じように、顧客が適切に適切な絶縁を確保するために、彼のコミュニケーションギアのセキュリティを維持するために、バックボーンネットワークを構成するためにSPに依存しなければなりません。
No particular means of PE/CE authentication is specified for BGP/MPLS IP VPNs. PE/CE mutual authentication may be done via any mechanism supported by the routing protocol in which the CE and PE are peers (e.g., use of the TCP MD5 authentication when the PE/CE protocol is BGP), or by any other mechanism that may be desired. With such mechanisms in place, a CE may not join a VPN until the CE authenticates itself to the Service Provider.
PE / CE認証の特別手段はBGP / MPLS IP VPNのために指定されていません。 PE / CE相互認証は、CEおよびPEは、ピア（例えば、PE / CEプロトコルがBGPであるTCP MD5認証の使用）、または任意の他の機構によってそのかもしれされたルーティングプロトコルがサポートする任意のメカニズムを介して行われてもよいです望まれます。 CEは、サービスプロバイダに対して自身を認証するまで、代わりにそのようなメカニズムでは、CEは、VPNに参加しないことがあります。
There is, however, no standardized method that requires a CE to authenticate itself to the customer network (rather than to the SP) before the CE is allowed to join the VPN. This is for further study.
CEは、VPNへの参加を許可される前に（むしろSPより）顧客のネットワークに自身を認証するためにCEを必要と標準化の方法は、しかし、ありません。これは今後の検討課題です。
No particular means is specified for controlling which user data packets can be forwarded by BGP/MPLS IP VPNs. BGP/MPLS IP VPNs are compatible with Access Control Lists (ACLs) and any other filtering features that are supported on the PE routers. Routing can be set up so that extranet traffic is directly through a firewall, if that is desired.
特段の手段は、データパケットがBGP / MPLS VPNのIPによって転送可能なユーザ制御するために指定されていません。 BGP / MPLS IP VPNは、アクセス制御リスト（ACL）とPEルータでサポートされている任意の他のフィルタリング機能と互換性があります。それが望まれる場合にはエクストラネットのトラフィックは、ファイアウォールを介して直接になるようにルーティングを設定することができます。
It is possible for various sorts of "tunnel interfaces" to be associated with a VRF. In this case, whatever authentication is natively used in the establishment of the tunnel interface may be used. For example, an IPsec tunnel can be used as an "access link" to attach a remote user or site to a VRF. The authentication procedure in this case is part of IPsec, not part of the VPN scheme.
「トンネルインターフェイス」の各種のVRFに関連付けられることが可能です。この場合には、どのような認証がネイティブに使用することができるトンネルインターフェイスの確立に使用されます。例えば、IPsecトンネルは、VRFへのリモートユーザーまたはサイトを接続する「アクセスリンク」として使用することができます。この場合の認証手順は、IPsec、VPN方式の一部ではないの一部です。
Where L2TP is used, each PPP session carried in an L2TP tunnel can be associated with a VRF. The SP's Authentication, Authorization, and Accounting (AAA) server can be used to determine the VPN to which the PPP session belongs, and then the customer's AAA server can be given the opportunity to authenticate that session as well.
L2TPが使用される場合、L2TPトンネルで運ば各PPPセッションは、VRFに関連付けることができます。 SPの認証、認可、アカウンティング（AAA）サーバは、PPPセッションが属するVPNを決定するために使用することができ、その後、顧客のAAAサーバは、同様に、そのセッションを認証する機会を与えることができます。
No particular means of ensuring user data security is specified for BGP/MPLS IP VPNs.
ユーザデータのセキュリティを確保することのない特定の手段は、BGP / MPLS IP VPNのために指定されていません。
The optional procedures of [MPLS/BGP-IPsec] may be used to provide authentication and/or encryption of user data as it travels from the ingress PE to the egress PE. However, the data is exposed at those two PEs, as well as on the PE/CE access links.
[MPLS / BGP-のIPsec]の任意の手順は、出口PEへの入口PEから移動するとき、認証および/またはユーザデータの暗号化を提供するために使用され得ます。しかし、データは、これら二つのPEで、ならびにPE / CEアクセスリンクに露出しています。
The customer may provide his own user data security by using IPsec tunnels that terminate within the customer sites. Such tunnels are transparent to the VPN scheme. Schemes that discover the remote tunnel endpoints automatically and then set up the tunnels automatically as needed are the best fit with this VPN technology. Note that there is no requirement in general that IPsec tunnels between customer sites terminate at CE routers.
顧客は、顧客サイト内に終了IPsecトンネルを使用することによって、彼自身のユーザーデータのセキュリティを提供することができます。このようなトンネルはVPNスキームに対して透過的です。自動的にリモートトンネルエンドポイントを発見し、必要に応じて自動的にトンネルを設定スキームは、このVPN技術と最高のフィット感です。顧客サイト間のIPsecトンネルがCEルータで終端することを一般的には必要はないことに注意してください。
The use of end-to-end transport mode IPsec by the customer is also transparent to the VPN scheme. In fact, the VPN scheme is compatible with any use of security by the customer, as long as a cleartext IP header is passed from CE to PE.
顧客によるエンドツーエンドのトランスポートモードのIPsecの使用はまた、VPNスキームに対して透過的です。実際には、VPN方式であれば平文IPヘッダがCEからPEに送られるように、顧客によるセキュリティの使用と互換性があります。
When data must cross the Internet to reach the ingress PE router, IPsec tunnels between the end user and the PE router can be used; the PE router must then associate each IPsec tunnel with the proper VRF. This association would have to be based on user-specific information provided by the Internet Key Exchange (IKE) protocol, such as a VPN-id.
データは入口PEルータに到達するためにインターネットを横断しなければならない場合、エンドユーザとPEルータ間のIPsecトンネルを使用することができます。 PEルータは、次いで、適切なVRFと各IPsecトンネルを関連付ける必要があります。この関連付けは、VPN-IDなどのインターネット鍵交換（IKE）プロトコルによって提供されるユーザ固有の情報に基づいてされなければなりません。
If data is going from one SP network to another, and must cross the public Internet to get between those two networks, IPsec tunnels can be used to secure the data. This would require bilateral agreement between the two SPs. BGP connections can also be passed through an IPsec tunnel if this is deemed necessary, in order to protect user data, by a pair of SPs. QoS/SLA factors would have to be carefully considered in this case.
データを別のSPネットワークから起こっている、そしてこれら2つのネットワーク間を取得するために公共のインターネットを横切らなければならない場合は、IPsecトンネルは、データを保護するために使用することができます。これは、2つのSP間の二国間の合意が必要となります。これが必要と判断された場合、BGP接続ものSPのペアによって、ユーザデータを保護するために、IPsecトンネルを通過させることができます。 QoSの/ SLAの要因は、慎重に、この場合に考慮しなければならないでしょう。
The SP is responsible for preventing illegitimate traffic from entering a VPN. VPN traffic is always encapsulated while traveling on the backbone, so preventing illegitimate traffic is a matter of ensuring that the PE routers to the encapsulation/decapsulation correctly and that encapsulations have not been "spoofed", i.e., that the encapsulated packets were actually encapsulated by PE routers.
SPは、VPNに入るの違法なトラフィックを防止する責任があります。バックボーン上を移動しながら、VPNトラフィックは常にカプセル化されているので、違法なトラフィックを防止することが正しくカプセル化は、カプセル化されたパケットが実際によってカプセル化されたこと、すなわち、「詐称」されていないことをカプセル化/カプセル化解除にPEルータことを確実にすることの問題ですPEルータ。
This requires the SP to take various security measures. The PE and P routers must themselves be secure against break-ins (either from someone physically present or from the Internet), and neither P nor PE routers should form routing adjacencies to other P or PE routers without benefit of some kind of security. This may be authentication in the IGP, or physical security.
これは、さまざまなセキュリティ対策を取るためにSPが必要です。 PEとPルータは、自身がブレークイン（どちらか物理的に存在するか、インターネットからの誰かから）に対して安全でなければならない、とどちらもPもPEルータはセキュリティのいくつかの種類の恩恵なしに、他のPまたはPEルータにルーティング隣接関係を形成しなければなりません。これは、IGPにおける認証、または物理的なセキュリティかもしれません。
The PE/CE access link should be secured in some manner, though the provider may make it the responsibility of the customer to ensure that the CE is secure from compromise. If the PE/CE access link is a tunnel over the Internet, then of course some sort of authentication protocol should always be used.
プロバイダがCEは妥協から安全であることを確実にするために、お客様の責任にするかもしれませんがPE / CEアクセスリンクは、いくつかの方法で固定しなければなりません。 PE / CEアクセスリンクはインターネット経由でのトンネルである場合には、当然のことながら、認証プロトコルのいくつかの並べ替えを常に使用する必要があります。
Label Distribution Protocol (LDP) sessions and BGP sessions between PE and/or P routers should be authenticated. This can be done via the TCP MD5 option or by use of IPsec.
PE及び/又はPルータ間のラベル配布プロトコル（LDP）セッションおよびBGPセッションが認証されなければなりません。これは、TCP MD5オプションを介して、またはのIPsecを使用することによって行うことができます。
If the SP is providing the VPN service over an MPLS backbone, it should not accept MPLS packets from its external interfaces (i.e., interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system from which the packet is being received. If the packet's incoming interface leads to a different SP (rather than to a customer), an appropriate trust relationship must also be present, including the trust that the other SP also provides appropriate security measures.
SPは、MPLSバックボーン上でVPNサービスを提供している場合、パケットのトップラベルが合法的にシステムに配布された場合を除き、それは、その外部インタフェース（すなわち、インタフェースCEデバイスまたは他のプロバイダのネットワークへ）からMPLSパケットを受け入れるべきではありませんそこからパケットが受信されています。パケットの着信インターフェイスが（むしろ顧客へより）異なるSPにつながる場合には、適切な信頼関係は、他のSPはまた、適切なセキュリティ対策を提供し、信頼を含め、存在しなければなりません。
If the SP is providing the VPN service by using an IP (rather than an MPLS) encapsulation, or if it accepts IP-encapsulated VPN packets from other SPs, it should apply filtering at its borders so that it does not accept from other SPs or from customers any IP packets that are addressed to the PE routers, unless appropriate trust relationships are in place.
SPは、（むしろMPLSより）カプセル化をIPを使用してVPNサービスを提供している、またはそれは他のSPからIPカプセル化VPNパケットを受け入れる場合、それは、他のSPから受け付けないように、その境界にフィルタリングを適用する必要がある場合、または顧客からの適切な信頼関係がない限り、PEルータに宛てされているすべてのIPパケットが整備されています。
Cryptographic authentication of the encapsulated data packets is certainly advantageous when there are multiple SPs providing a single VPN.
単一のVPNを提供する複数のSPが存在する場合、カプセル化されたデータ・パケットの暗号化認証は確かに有利です。
When a dynamic routing protocol is run on the link between a CE router and a PE router, routing instability in the private network may have an effect on the PE router. For example, an unusually large number of routing updates could be sent from the CE router to the PE router, placing an unusually large processing load on the PE router. This can potentially be used as a Denial-of-Service (DoS) attack on the PE router.
動的ルーティングプロトコルはCEルータとPEルータ間のリンク上で実行されたときに、プライベートネットワーク内のルーティングの不安定性は、PEルータに影響を与えることができます。例えば、ルーティング更新の異常に多数のPEルータで異常に大きな処理負荷をかける、PEルータにCEルータから送信することができます。これは、潜在的にPEルータのサービス拒否（DoS）攻撃として使用することができます。
This issue can be mitigated via resource partitioning in the PE, in order to limit the amount of resources (e.g., CPU and memory) that any one VPN is permitted to use in PE routers. Also, rate limits may be applied to the routing traffic sent from the CE to the PE. Alternately, when this problem is detected, the CE-to-PE interface may be shut down.
この問題は、いずれかのVPNがPEルータで使用することが許可されているリソースの量（例えば、CPUおよびメモリ）を制限するために、PEに資源分割を介して緩和することができます。また、レート制限は、PEにCEから送信されたルーティング・トラフィックにも適用することができます。この問題が検出されたときに交互に、CE-に-PEインターフェイスがシャットダウンされてもよいです。
Network management traffic from the CE to the PE may be rate limited (for example, to prevent network management traffic from CE to PE to be used in a DoS attack).
PEへのCEからネットワーク管理トラフィックレート（例えば、DoS攻撃で使用するPEにCEからネットワーク管理トラフィックを防ぐために）制限されてもよいです。
Section 9 of [L2VPN-SEC-FRMWRK] provides "a brief template that may be used to evaluate and summarize how a given PPVPN [Provider-Provisioned Virtual Private Network] approach (solution) measures up against the PPVPN Security Framework". It further states "an evaluation using this template should appear in the applicability statement for each PPVPN approach". The purpose of this subsection is to provide the information in the form required by this template. Security requirements that are relevant only to L2VPNs are not applicable and are not further discussed.
[L2VPN-SEC-FRMWRK]のセクション9は、「評価し、与えられたPPVPN [プロバイダ-プロビジョニングされた仮想プライベートネットワーク]のアプローチ（解決策）はPPVPNセキュリティフレームワークに対して、最大測定方法を要約するために使用することができる簡単なテンプレート」を提供します。 「このテンプレートを使用した評価は、各PPVPNアプローチのための適用性声明に表示されます」それはさらに状態。本項の目的は、このテンプレートによって要求される形式で情報を提供することです。唯一のL2VPNに関連するセキュリティ要件は適用されず、さらに議論されていません。
- Does the approach provides complete IP address space separation for each L3VPN?
- アプローチは、各L3VPNのための完全なIPアドレス空間の分離を提供していますか？
Yes.
はい。
The IP address prefixes from a particular VPN appear in their native form only in routing tables that are specific to the particular VPN. They are distributed in their native form only by routing instances that are specific to the particular VPN. When address prefixes from different VPNs are combined into a common table, or distributed by a common mechanism, the address prefixes are first prepended with a Route Distinguisher (RD). The RD is a 64-bit quantity, structured so that globally unique RD values can easily be created by an SP. As long as no two VPNs are assigned the same RD value, complete IP address space separation is provided. It is however possible for an SP to misconfigure the RD assignments.
特定のVPNからのIPアドレスのプレフィックスは、特定のVPNに固有のルーティングテーブルにその本来の形で表示されます。彼らは、特定のVPNに固有のインスタンスをルーティングすることによって、それらの天然の形態で分布しています。異なるVPNからのアドレスプレフィックスが共通のテーブルにまとめ、または共通のメカニズムによって配布された場合、アドレスプレフィックスが最初のルート識別子（RD）を用いて付加されます。 RDは、グローバルに一意のRD値を容易SPによって作成することができるように構成され、64ビット量です。限り何の2つのVPNが同じRD値を割り当てられていないとして、完全なIPアドレス空間の分離が提供されます。 SPは、RDの割り当てを誤って設定することはしかし可能です。
- Does the approach provide complete IP route separation for each L3VPN?
- アプローチは、各L3VPNのための完全なIPルートの分離を提供していますか？
Yes.
はい。
The distribution of routes is controlled by assigning import and export Route Targets (RTs). A route that is exported from a VRF carries an RT specified by the SP as an export RT for that VRF. The route can be imported into other VRFs only if the RT that it carries has been configured by the SP as an import RT for those other VRFS. Thus, the SP has complete control over the set of VRFs to which a route will be distributed. It is of course possible for the SP to misconfigure the RT assignments.
ルートの分布は、インポートおよびエクスポートルートターゲット（RTS）を割り当てることによって制御されます。 VRFからエクスポートされたルートは、そのVRFのエクスポートRTとしてSPで指定されたRTを運びます。ルートは、これらの他のVRFのインポートRTとしてSPで構成された搬送するだけRTあれば、他のVRFにインポートすることができます。したがって、SPは、ルートが配布されるためのVRFのセットを完全に制御しています。 SPは、RTの割り当てを誤って設定することがもちろん可能です。
- Does the approach provide a means to prevent improper cross-connection of sites in separate VPNs?
- アプローチは、別のVPN内のサイトの不適切なクロス接続を防止するための手段を提供していますか？
This requirement is addressed in a way that is beyond the scope of the VPN mechanisms.
この要件は、VPNの仕組みの範囲を超えての方法で対処されます。
In BGP/MPLS IP VPNs, an SP makes a particular site part of a particular VPN by configuring the PE router's interface to that site to be associated with a particular VRF in that PE. The VRF is configured with import and export RTs, and it is the way in which VRFs are configured with RTs in the various PEs that results in a particular set of sites being connected as a VPN.
BGP / MPLS IP VPNのでは、SPはそのPE内の特定のVRFに関連していることがそのサイトにPEルータのインターフェイスを設定することによって、特定のVPNの特定のサイトの一部になります。 VRFは、インポートおよびエクスポートのRTで構成され、それはのVRFは、VPNのように接続されているサイトの特定のセットをもたらす種々のPEでのRTで設定されている方法です。
Connecting the sites properly in this way is regarded as a network management function, and the VPN scheme itself does not provide a means to prevent misconfiguration.
このように、適切にサイトを接続するには、ネットワーク管理機能とみなされ、VPNの仕組み自体は、設定ミスを防止するための手段を提供していません。
The VPN scheme does not provide any particular method for ensuring that a given interface from a PE leads to the CE that is expected to be there. If a routing algorithm is run on a particular PE/CE interface, any security procedures that the routing algorithm provides (e.g., MD5 authentication of BGP sessions) can be used; this is outside the scope of the VPN scheme. Also, a CE can attach to a PE via an IPsec tunnel, if this is desired, for a greater degree of security.
VPN方式は、PEから与えられたインタフェースが存在することが予想されるCEをもたらすことを確実にするための任意の特定の方法を提供しません。ルーティングアルゴリズムは、特定のPE / CEインターフェイス上で実行される場合、ルーティングアルゴリズムが提供する任意のセキュリティ手順は、（例えば、BGPセッションのMD5認証）を使用することができます。これは、VPNスキームの範囲外です。これが所望される場合にも、CEは、セキュリティのより大きな程度については、IPsecトンネルを介してPEに取り付けることができます。
- Does the approach provide a means to detect improper cross-connection of sites in separate VPNs?
- アプローチは、別のVPN内のサイトの不適切なクロス接続を検出するための手段を提供していますか？
The base specifications for BGP/MPLS IP VPNs do not provide a means for detecting that a site has been connected to the wrong VPN. However, the optional procedure specified in [CE-VERIF] does provide such a means. Basically, each PE obtains, via protocol, a secret from each CE to which it is directly attached. When the routes from a given CE are distributed, the secret from that CE is attached as an attribute of the route. This secret will ultimately be distributed to any other CE that receives any route from the given CE. A CE that is not supposed to be part of a given VPN will not know the right secret, and if it is connected to the given VPN the other CEs in that VPN will realize that a CE that doesn't know the proper secret has been connected to the VPN.
BGP / MPLS IP VPNの基本仕様は、サイトが間違ったVPNに接続されたことを検出するための手段を提供していません。しかし、[CE-VERIF]で指定されたオプションの手順は、そのような手段を提供します。基本的に、各PEは、それが直接結合されている各CEからプロトコル、秘密を介して取得します。所与のCEからルートが分散されている場合、そのCEから秘密は、ルートの属性として付加されています。この秘密は、最終的に与えられたCEから任意の経路を受け、他のCEに配布されます。与えられたVPNの一部であることが想定されていないCEは、右の秘密を知ることができません、それは与えられたVPNに接続された場合には、VPN内の他のCEは、適切な秘密を知らないCEがされていることを理解するであろうVPNに接続されています。
- Does the approach protect against the introduction of unauthorized packets into each VPN?
- アプローチは、各VPNへの不正パケットの導入から保護していますか？
We must look separately at the various points at which one might attempt to introduce unauthorized packets.
我々は1つが不正なパケットを導入しようとするかもしれないで様々なポイントで別々に見なければなりません。
* Packets arriving at a PE over a PE/CE interface
*パケットは、PE / CEインタフェース上EPに到達します
If a given PE is directly connected to a given CE, the PE will accept any packets that the CE sends it. The VPN scheme has no special procedures for determining that these packets actually came from the CE. However, various means of securing the PE/CE connection can be used (for instance, the PE and CE can be connected by an IPsec tunnel) if desired. That is, this aspect of the requirement can be addressed by means that are outside the scope of the VPN specification.
所与のPEを直接与えCEに接続されている場合、PEは、CEは、それを送信するすべてのパケットを受け入れます。 VPN方式は、これらのパケットが実際にCEから来たことを判断するための特別な手続きはありません。しかし、PE / CE接続を確保する様々な手段は、必要に応じて（例えば、PEとCEは、IPsecトンネルによって接続することができる）を使用することができます。つまり、要件のこの態様は、VPNの仕様の範囲外である手段によって対処することができます。
Once a packet has been accepted from a CE by a PE, the packet is routed according to the VRF associated with that PE's interface to that CE. Such packets can only be sent along routes that are in that VRF. There is no way a packet from a CE can be routed to an arbitrary VPN. In particular, there is nothing a VPN user can do to cause any particular packet to be sent to the wrong VPN. So this aspect of the requirement is fully addressed.
パケットがPEによってCEから受け付けされた後、パケットはそのCEへのPEのインターフェイスに関連付けられたVRFに従ってルーティングされます。このようなパケットは、唯一そのVRFにあるルートに沿って送信することができます。 CEからのパケットは、任意のVPNにルーティングすることができる方法はありません。具体的には、間違ったVPNに送信するVPNユーザが任意の特定のパケットを引き起こすことができることは何もありません。だから、要件のこの側面は完全に対処されます。
* Packets arriving at a PE over an interface from the backbone
*パケットは、バックボーンからインターフェイスを介してPEに到着します
The optional procedures of [MPLS/BGP-IPsec] can be used to ensure that a packet that is received by a PE from the backbone will not be recognized as a VPN packet unless it actually is one. Those procedures also ensure that a received VPN packet came from a particular PE and that it carries the MPLS label that that PE put on it. These procedures protect the packet from ingress PE to egress PE, but do not protect the PE/CE interfaces.
[MPLS / BGP-のIPsec]の任意の手順は、それが実際には1つでなければ骨格からPEによって受信されたパケットは、VPNパケットとして認識されないことを保証するために使用することができます。これらの手順は、受信したVPNパケットが特定のPEから来ていることを確認し、そのPEがそれを置くMPLSラベルを運ぶこと。これらの手順は、入口PEから出力PEにパケットを保護するが、PE / CEインターフェイスを保護しません。
If the optional procedures of [MPLS/BGP-IPsec] are not used, then the following considerations apply.
[MPLS / BGP-のIPsec]の任意の手順が使用されない場合は、次の考慮事項が当てはまります。
Undetected corruption of the routing information carried in a packet's VPN encapsulation can result in misdelivery of the packet, possibly to the wrong VPN.
パケットのVPNのカプセル化で運ばれたルーティング情報の未検出の破損は、おそらく間違ったVPNに、パケットの誤配信が発生することができます。
If a packet enters an SP's network on an interface other than a PE/CE interface, the SP should ensure that the packet either does not look like a VPN packet or else is not routed to a PE router. This can be done in a variety of ways that are outside the scope of the VPN scheme. For example, IP packets addressed to the PE routers can be filtered, MPLS packets (or, e.g., MPLS-in-IP) from outside the SP network can be refused, etc.
パケットはPE / CEインターフェイス以外のインターフェイス上のSPのネットワークに入る場合は、SPは、パケットがVPNパケットのように見えないか、他のPEルータにルーティングされていないかということを確認する必要があります。これは、VPN方式の範囲外である種々の方法で行うことができます。例えば、IPパケットをフィルタリングすることができるPEルータ、MPLSパケット（又は、例えば、MPLS-で-IP）SPネットワークの外部からの拒否することができる、等宛て
In the case of a multi-provider L3VPN backbone, the SP will have to know which interfaces lead to SPs that are VPN partners, so that VPN packets can be allowed to flow on those interfaces.
マルチプロバイダL3VPNバックボーンの場合に、SPは、VPNパケットがそれらのインターフェイス上で流すことができるように、VPNのパートナーであるSPにつながるインターフェースかを知る必要があります。
If the public Internet is used as the L3VPN backbone, protection against unauthorized packets cannot be achieved by the above measures. IPsec tunnels should always be used to carry VPN traffic across the public Internet.
公共のインターネットはL3VPNバックボーンとして使用されている場合、不正なパケットに対する保護は、上記の対策によって達成することができません。 IPsecトンネルは、常に公共のインターネットを介したVPNトラフィックを運ぶために使用されるべきです。
- Does the approach provide confidentiality (secrecy) protection, sender authentication, integrity protection, or protection against replay attacks for PPVPN user data?
- アプローチは、機密性（秘密）保護、送信者認証、完全性保護、またはPPVPNのユーザデータのリプレイ攻撃に対する保護を提供していますか？
If these are desired, they must be provided by mechanisms that are outside the scope of the VPN mechanisms. For instance, the users can use secure protocols on an end-to-end basis, e.g., IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.
これらが所望される場合、それらはVPNメカニズムの範囲外であるメカニズムによって提供されなければなりません。例えば、ユーザは、等、エンドツーエンドベースでセキュアなプロトコル、例えば、IPsecの、セキュアシェル（SSH）、Secure Sockets Layer（SSL）を使用することができ
- Does the approach provide protection against unauthorized traffic pattern analysis for PPVPN user data?
- アプローチはPPVPNユーザデータの不正なトラフィックパターン分析に対する保護を提供していますか？
Preventing an observer from obtaining traffic pattern analysis from the SP network is beyond the scope of the VPN mechanisms.
SPネットワークからトラフィックパターン分析を得るからオブザーバを防止するVPNメカニズムの範囲を超えています。
- Do the control protocol(s) used for each of the following functions provide for message integrity and peer authentication?
- 以下の機能のそれぞれに使用される制御プロトコル（単数または複数）は、メッセージの完全性及びピア認証を提供していますか？
* VPN membership discovery
* VPNのメンバーシップの発見
This requirement is fully satisfied. Membership discovery is done by means of BGP. Control message integrity and peer authentication in BGP may be achieved by use of the TCP MD5 option.
この要件は、完全に満足しています。会員の発見は、BGPによって行われます。 BGPでの制御メッセージの整合性とピア認証は、TCP MD5オプションを使用することによって達成することができます。
* Tunnel establishment
*トンネルの確立
The answer to this question depends of course on the tunnel protocol and tunnel establishment protocol; a variety of different tunneling schemes can be used in BGP/MPLS IP VPNs. Thus, this question is out of scope.
この質問への答えは、トンネルプロトコルとトンネル確立プロトコルにもちろん依存します。異なるトンネリングスキームのさまざまなBGP / MPLS IP VPNの中で使用することができます。したがって、この質問は適用範囲外です。
In the common case where the tunnels are MPLS Label Switching Routers (LSRs) established by LDP, then control message integrity and peer authentication may be achieved by use of the TCP MD5 option.
トンネルがMPLSラベルスイッチングルータ（LSRの）は、LDPによって確立されている一般的なケースでは、メッセージの整合性を制御し、ピア認証はTCP MD5オプションを使用することによって達成することができます。
* VPN topology and reachability advertisement
* VPNトポロジと到達可能性広告
With respect to PE-PE interactions, the relevant control protocol is BGP, so control message integrity and peer authentication can be achieved by use of the TCP MD5 option.
PE-PE間の相互作用に関しては、関連する制御プロトコルがので、メッセージの完全性とピア認証がTCP MD5オプションを使用することによって達成することができる制御、BGPです。
With respect to CE-PE interactions, the answer depends on the protocol used for exchanging information between PE and CE, as the security mechanisms (if any) of those protocols would need to be used. In the common case where the PE/CE protocol is BGP, the TCP MD5 option can be used.
これらのプロトコルのセキュリティメカニズムは、（もしあれば）を使用する必要があるであろうようにCE-PEの相互作用に関して、答えは、PEとCEの間で情報を交換するために使用されるプロトコルに依存します。 PE / CEプロトコルがBGPである一般的なケースでは、TCP MD5オプションを使用することができます。
* VPN provisioning and management
* VPNのプロビジョニングと管理
The protocols procedures for provisioning VPNs and managing the PE routers are outside the scope of the VPN scheme.
PEルータをVPNをプロビジョニングおよび管理するためのプロトコル手順は、VPN方式の範囲外です。
* VPN monitoring and attack detection and reporting
* VPNの監視および攻撃検出および報告
The protocols and procedures for monitoring the VPNs are outside the scope of the VPN scheme.
VPNを監視するためのプロトコルおよび手順は、VPN方式の範囲外です。
- What protection does the approach provide against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks)?
- アプローチはPPVPN特有のDoS攻撃（すなわち、相互の信頼できるゾーンDoS攻撃）に対して、どのような保護を提供していますか？
* Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in a
private (PPVPN user) network and aimed at PPVPN mechanisms.
The PE/CE interfaces of a given VPN will generally be addressable from within that VPN. Apart from that, a user within an L3VPN has no more access to the service provider infrastructure than does any user of the Internet. Therefore, we will focus in this section on possible DoS attacks against a PE router that may occur when traffic from within a VPN is addressed to a PE router.
与えられたVPNのPE / CEインターフェイスは、一般的に、そのVPN内からアドレス可能であろう。それとは別に、L3VPN内のユーザは、インターネットの任意のユーザの場合よりも、サービスプロバイダーインフラストラクチャへのこれ以上のアクセス権を持っています。したがって、我々は、VPN内からのトラフィックはPEルータにアドレス指定されたときに発生する可能性があり、PEルータに対して実行される可能性のあるDoS攻撃に、このセクションに焦点を当てます。
A user within the VPN may address traffic to a PE router and may attempt to send an excessive amount of traffic to it. Presumably, the PE routers will not accept unauthorized TCP connections or Simple Network Management Protocol (SNMP) commands, so such traffic will be thrown away; the danger is that the PE may need to use a significant proportion of its capacity to discard such traffic. However, this case is no different than the case of any SP access router that attaches to subscriber equipment. The presence of the VPN mechanisms does not make the PE any more or less vulnerable to DoS attacks from arbitrary end users.
VPN内のユーザは、PEルータにトラフィックに対処することができるし、それへのトラフィックの過剰な量を送信することを試みることができます。おそらく、PEルータは、不正なTCP接続または簡易ネットワーク管理プロトコル（SNMP）コマンドを受け付けませんので、このようなトラフィックが離れてスローされます。危険なのは、PEは、このようなトラフィックを破棄する能力のかなりの割合を使用する必要があるかもしれないということです。しかし、この場合には、加入者装置に接続するすべてのSPのアクセスルータの場合よりも違いはありません。 VPNメカニズムの存在は、任意のエンドユーザからのDoS攻撃に任意多少脆弱PEを行いません。
* Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
*データプレーンや制御プレーンDoS攻撃に対するサービスプロバイダーインフラストラクチャの保護は、インターネットで発信されPPVPNメカニズムを目的としました。
DoS attacks of this sort can be prevented if the PE routers are not addressable from the Internet. Alternatively, an SP can apply address filtering at its boundaries so that packets from the Internet are filtered if they are addressed to a PE router.
PEルータは、インターネットからアドレス指定されていない場合は、この種のDoS攻撃を防止することができます。また、SPは、それらがPEルータにアドレス指定された場合、インターネットからのパケットがフィルタリングされているように、その境界でアドレスフィルタリングを適用することができます。
* Protection of PPVPN users against Data Plane or Control Plane DoS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms.
*データプレーンや制御プレーンDoS攻撃に対するPPVPN利用者の保護は、インターネットからまたは他のPPVPNのユーザーから発信されPPVPNメカニズムを目的としました。
Mechanisms already discussed prevent users in a VPN from receiving packets from the Internet, unless this is specifically allowed. In the case where it is specifically allowed, it is no different than any other situation in which a network is connected to the Internet, and there is no special vulnerability to DoS attacks due to the L3VPN mechanisms.
既に論じた機構は、これは、具体的に許可されていない限り、インターネットからパケットを受信することからVPNのユーザーを防止します。それが具体的に許可されている場合には、ネットワークがインターネットに接続されている任意の他の状況よりも違いはありません、そして起因L3VPN機構へのDoS攻撃に対する特別な脆弱性が存在しません。
There is nothing to prevent a user in a VPN from mounting a DoS attack against other users in the VPN. However, the L3VPN mechanisms make this neither more nor less likely.
VPN内の他のユーザーに対してDoS攻撃をマウントからVPNでユーザを防ぐためには何もありません。しかし、L3VPNメカニズムは、この過不足なくそうします。
- Does the approach provide protection against unstable or malicious operation of a PPVPN user network?
- アプローチはPPVPNユーザネットワークの不安定や悪意のある操作に対する保護を提供していますか？
* Protection against high levels of, or malicious design of,
routing traffic from PPVPN user networks to the service
provider network.
If a dynamic routing algorithm is running on the PE/CE interface, it can be used to mount an attack on the PE router, by having the CE present the PE with an excessive number of routing events. If an end user within a VPN successfully attacks the routing algorithm of the VPN, that might also result in an excessive number of routing events being seen by the PE router. This sort of attack can be ameliorated by having the PE limit the amount of its resources that can be expended processing routing events from a particular VPN. If the PE/CE routing algorithm is BGP, then such mechanisms as route flap damping may be appropriate as well.
ダイナミックルーティングアルゴリズムは、PE / CEインターフェイス上で実行されている場合、CEは、ルーティングイベントの過剰な数のPEを提示有することによりPEルータの攻撃をマウントするために使用することができます。 VPN内のエンドユーザが成功VPNのルーティングアルゴリズムを攻撃した場合、それはまた、ルーティングイベントの過剰な数がPEルータによって見られることをもたらすかもしれません。この種の攻撃は、PEは、特定のVPNからの処理ルーティングイベントを消費することができ、そのリソースの量を制限有することによって改善することができます。 PE / CEルーティング・アルゴリズムは、BGPの場合、ルートフラップダンピングなどの機構も同様に適切であり得ます。
* Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
*高レベル、またはサービスプロバイダのネットワークへのPPVPNユーザネットワークからの悪意のあるの設計、ネットワーク管理トラフィックに対する保護。
A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send management traffic to the service provider network.
BGP / MPLS IP VPN内のユーザーは、サービスプロバイダのネットワークへの管理トラフィックを送信するすべてのインターネットユーザーよりも多くの能力を持っていません。
* Protection against worms and probes originated in the PPVPN user networks, sent towards the service provider network.
*ワームやプローブに対する保護は、サービスプロバイダのネットワークに向けて送信PPVPNユーザネットワークに由来しました。
A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send worms or probes to the service provider network.
BGP / MPLS IP VPN内のユーザーは、サービスプロバイダのネットワークにワームまたはプローブを送信するために任意のインターネットユーザーよりも多くの能力を持っていません。
Overlapping customer addresses are supported. There is no requirement that such addresses be in conformance with [RFC1918]. There is no requirement that customer VPN addresses be distinct from addresses in the SP network.
重複顧客のアドレスがサポートされています。そのようなアドレスは[RFC1918]に準拠してある必要はありません。顧客のVPNアドレスは、SPネットワーク内のアドレスと区別である必要はありません。
Any set of addresses used in the VPN can be supported, irrespective of how they are assigned, how well they aggregate, and whether they are public or private. However, the set of addresses that are reachable from a given site must be unique.
VPNで使用されているアドレスのいずれかのセットは関係なく、どのように彼らは、彼らが集計方法も、割り当てられている、サポートすることができ、そして、彼らは、パブリックまたはプライベートであるかどうか。ただし、特定のサイトから到達可能なアドレスのセットは一意である必要があります。
Network address translation for packets leaving/entering a VPN is possible and is transparent to the VPN scheme.
VPNに入る/離れるパケットのためのネットワークアドレス変換が可能であり、VPNスキームに対して透過的です。
There is nothing in the architecture to preclude the mechanisms from being extended to support IPv6, provided that the appropriate IPv6- capable routing algorithms are in place. That is, PE/CE routing must support IPv6, and the PE-PE BGP must support the labeled IPv6 address family. The latter has not been specified, but its specification is obvious from the specification of the labeled IPv4 address family. The IGP used in the SP backbone need not be IPv6 capable in order to support customer IPv6 networks.
IPv6をサポートするように拡張されるの機構を排除するためのアーキテクチャでは何も存在しない、適切なIPv6-可能なルーティングアルゴリズムが適所にあることを条件とします。すなわち、PE / CEルーティングがIPv6をサポートしなければならない、そしてPE-PE BGPは、標識されたIPv6アドレスファミリをサポートしなければなりません。後者は、指定されていないが、その仕様は、標識されたIPv4アドレスファミリの仕様から明らかです。 SPのバックボーンで使用されるIGPは、顧客のIPv6ネットワークをサポートするために、IPv6対応である必要はありません。
In theory, the same could be said of other network layers, but in practice a customer who has non-IP traffic to carry must expect to carry it either in site-to-site IP tunnels or using some additional service (such as a layer 2 service) from the SP.
理論的には、同じことが他のネットワーク層の言うことができたが、実際に運ぶために非IPトラフィックを持っている顧客は、いずれかで、サイトツーサイトIPトンネルまたはいくつかの追加サービスを使用して（そのような層としてそれを運ぶことを期待しなければなりませんSPから2サービス）。
Layer 2 addresses and identifiers are never carried across the SP backbone.
レイヤ2つのアドレスと識別子は、SPバックボーン全体に運ばれることはありません。
No restrictions are placed on the customer's addressing schemes or policies. Note though that the SP may place restrictions on the number of routes from a given customer site, or may charge differentially depending on the number of such routes, and such restrictions may have implications for the customer's addressing scheme. In particular, addressing schemes that facilitate route aggregation on a per-site basis will result in the most efficient use of the SP's resources, and this may be reflected in SP charging policies.
何の制限は、顧客のアドレス指定方式またはポリシーに置かれていません。 SPが与えられた顧客サイトからのルートの数に制限を置くこと、またはそのようなルートの数に応じて、差動充電することができ、そのような制限は、顧客のアドレス指定方式のための含意を有していてもよいけれども注意してください。具体的には、サイトごとにルート集約を促進するアドレス指定方式は、SPのリソースを最も効率的に使用になりますと、これはSPの充電政策に反映することができます。
Interoperability should be ensured by proper implementation of the published standards.
相互運用性は、公開されている標準の適切な実施により確保されなければなりません。
Direct PE-PE interworking over the SP backbone with other VPN solutions is not supported.
他のVPNソリューションとSPのバックボーン上で直接PE-PEインターワーキングはサポートされていません。
As all the different types of L3VPNs are IP networks, they can of course interwork in the same way that any two IP networks can interwork. For example, a single site can contain a CE router of one VPN scheme and a CE router of another VPN scheme, and these CE routers could be IGP peers, or they might even be the same CE router. This would result in the redistribution of routes from one type of VPN to the other, providing the necessary interworking.
L3VPNsのすべての異なるタイプがIPネットワークがあるので、それらは同じように当然のインターワークの任意の2つのIPネットワークが相互に作用できることを。例えば、単一のサイトは1つのVPNスキームと他のVPN方式でのCEルータのCEルータを含むことができ、これらのCEルータはIGPピア可能性があり、または彼らも同じCEルータであるかもしれません。これは、必要なインターワーキングを提供し、他のVPNの一種からのルートの再分配をもたらします。
The architecture and protocols do not restrict the link layer or the physical layer in any manner.
アーキテクチャとプロトコルは、リンク層またはいずれかの方法で、物理層を制限するものではありません。
Temporary access via PPP is possible, using industry standard PPP-based authentication mechanisms. For example:
PPPを介した一時的なアクセスは、業界標準のPPPベースの認証メカニズムを使用して、可能です。例えば：
- A dial-up user (or other PPP user) is authenticated by the PE, using the SP's AAA server, based on a login string or on the number dialed.
- ダイヤルアップユーザ（または他のPPPユーザ）がログイン文字列またはダイヤルされた番号に基づいて、SPのAAAサーバを使用して、PEによって認証されます。
- The SP's AAA server returns a VPN-id to PE.
- SPのAAAサーバは、PEにVPN-IDを返します。
- The PE assigns the user to a VRF, based on that VPN-id.
- PEは、VPN-IDに基づいて、VRFにユーザを割り当てます。
- The user is then authenticated by a AAA server within the VPN (i.e., managed by the customer rather than by the SP). This AAA server would typically be addressed through the VRF (i.e., may be in VPN's private address space).
- ユーザは、次いで、VPN内のAAAサーバによって認証される（すなわち、顧客がなくSPによって管理されます）。このAAAサーバは、一般的に（つまり、VPNのプライベートアドレス空間であってもよい）VRFによって対処されるだろう。
- The user gets disconnected if either authentication step is unsuccessful.
- いずれかの認証ステップが失敗した場合、ユーザーは切断されます。
IPsec access to a VRF is also possible. In this case, the security association is between the end user and the SP.
VRFへのIPsecのアクセスも可能です。この場合、セキュリティアソシエーションは、エンドユーザとSPとの間です。
In these ways, a user can access a BGP/MPLS IP VPN via the public Internet.
これらの方法では、ユーザーは、公衆インターネット経由でBGP / MPLS IP VPNにアクセスすることができます。
There is no explicit support for mobility, other than what is stated above.
上記記載されているもの以外のモビリティのための明示的なサポートはありません。
Homing of a CE to two or more PEs is fully supported, whether or not the PEs are on the same SP network.
二つ以上のPEへのCEのホーミングは完全にPEが同じSPネットワーク上にあるかどうか、サポートされています。
If a CE is connected to two or more PEs, all its PE/CE links can be used to carry traffic in both directions. In particular, traffic from different ingress PEs to a particular CE may arrive at that CE over different PE/CE links. This depends on the backbone network routing between the CE and the various ingress PEs.
CEは、2つの以上のPEに接続されている場合、そのすべてのPE / CEリンクは両方向のトラフィックを搬送するために使用することができます。具体的には、特定のCEに異なる入口のPEからのトラフィックは、異なるPE / CEリンクを介してそのCEに到達することができます。これは、CE、様々な入口PE間のバックボーンネットワークのルーティングに依存します。
If a VRF on a particular ingress PE contains several routes to a particular destination, then traffic from that ingress PE can be split among these routes. If these routes end with different PE/CE links, then traffic from that ingress PE will be split among those links.
特定の入口PE上のVRFは、特定の宛先へのいくつかの経路が含まれている場合は、その入口PEからのトラフィックは、これらの経路の間で分割することができます。これらのルートは異なるPE / CEリンクで終わる場合、その入口PEからのトラフィックは、これらのリンク間で分割されます。
BGP contains a multitude of knobs that allow an SP to control the traffic sent on one PE/CE link as opposed to the other. One can also make use of the Link Bandwidth extended community [BGP-EXT-COMM] to control how traffic is distributed among multiple egress PE/CE links.
BGPは、SPが対向するように、1つのPE / CEリンク上で送信されるトラフィックを制御することを可能にするノブを多数含んでいます。一つは、トラフィックが複数の出力PE / CEリンクの間で分配される方法を制御するためにリンク帯域幅拡張コミュニティ[BGP-EXT-COMM]を利用することができます。
The VPN scheme is of course compatible with the use of traffic engineering techniques, Resource Reservation Protocol - Traffic Engineering (RSVP-TE) based or otherwise, in the backbone network.
VPN方式はトラフィックエンジニアリング技術の使用と互換性はもちろんである、リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）は、バックボーンネットワークで、それ以外の場合はベースまたは。
Internet access and VPN access are possible from the same site. This is even possible over the same interface, as long as the VPN's internal addresses are distinct from the addresses of the systems that must be reached via the Internet. This requires only that Internet routes as well as VPN routes be imported into the VRF associated with that interface. This may be as simple as putting a default route to the Internet into that VRF.
インターネットアクセス、VPNアクセスが同じサイトから可能です。これは、VPNの内部アドレスは、インターネットを介して到達しなければならないシステムのアドレスは異なっている限り、同じインターフェイス上でも可能です。これは、そのインターネットルートだけでなく、VPNルートそのインターフェイスに関連付けられているVRFにインポートすることが必要です。これは、そのVRFにインターネットへのデフォルトルートを置くのと同じくらい簡単かもしれません。
The "route to the Internet" that is in a particular VRF need not lead directly to the Internet; it may lead to a firewall or other security device at another site of the VPN. The VPN customer can cause this to happen simply by exporting a default route from the site with the firewall. Generally, a site with a firewall will use a different virtual interface for Internet access than for VPN access, since the firewall needs to distinguish the "clean interface" from the "dirty interface".
インターネットに直接つながる必要はないが、特定のVRFにある「インターネットへのルート」。それは、VPNの別のサイトのファイアウォールやその他のセキュリティデバイスにつながる可能性があります。 VPNの顧客は、これは、ファイアウォールを持つサイトからデフォルトルートをエクスポートするだけで起こることがあります。ファイアウォールが「ダーティインターフェース」から「クリーンなインターフェイスを」区別する必要があるため、一般的に、ファイアウォールを持つサイトでは、VPNアクセスのためのよりインターネットアクセスのための別の仮想インターフェイスを使用します。
In such a configuration, the customer would export his routes to the Internet via the firewall's dirty interface, but would export the same routes to the VPN via the clean interface. Thus, all traffic from the Internet would come through the dirty interface, then through the firewall, and possibly go to another VPN site though the clean interface. This also allows any necessary Network Address Translation (NAT) functionality to be done in the firewall.
このような構成では、顧客は、ファイアウォールの汚れインタフェースを介してインターネットに彼のルートをエクスポートするだろうが、クリーンなインタフェースを介してVPNに同じルートをエクスポートします。このように、インターネットからのすべてのトラフィックは、ファイアウォールを介して、汚れたインタフェースを介して来る、そしておそらくクリーンなインターフェイスしかし、別のVPNサイトにアクセスしてください。これはまた、任意の必要なネットワークアドレス変換（NAT）機能をファイアウォールで行うことを可能にします。
Any externally provided service can be accessed from the VPN, provided that it can be addressed with an address that is not otherwise in use within the VPN. Access can be firewalled or non-firewalled. If the client accessing the service does not have a globally unique IP address, and a single server provides a service to multiple VPNs, NAT will have to be applied to the client's packets before they reach the server. This can be done at a customer site, or by a VRF-specific NAT function in a PE router.
任意の外部に提供されるサービスは、VPNからアクセスすることができ、それはVPN内での使用にはそうではないアドレスで対処することができることを提供します。アクセスは、ファイアウォールまたは非ファイアウォールすることができます。サービスにアクセスするクライアントは、グローバルに一意のIPアドレスを持っていないし、単一のサーバが複数のVPNにサービスを提供する場合、NATは、彼らがサーバに到達する前に、クライアントのパケットに適用する必要があります。これは、顧客サイトでの、またはPEルータでVRF固有のNAT機能によって行うことができます。
Routing through the backbone is independent of the VPN scheme and is unaffected by the presence or absence of VPNs. The only impact is that the backbone routing must carry routes to the PE routers.
バックボーンを経由してVPN方式とは無関係であり、VPNの存在または不在によって影響を受けません。唯一の影響は、バックボーンルーティングがPEルータへのルートを運ばなければならないということです。
The VPN routes themselves are carried in BGP as a distinct address family, different than the address family that is used to carry "ordinary" IP routes. These routes are passed from PE router to Route Reflector to PE router, and are never seen by the P routers. The Route Reflectors that carry the VPN routes can be entirely separate from the Route Reflectors that carry the "ordinary" IP routes.
VPNルート自体は「普通の」IPルートを運ぶために使用されたアドレスファミリとは異なる個別のアドレスファミリとしてBGPに運ばれます。これらのルートはPEルータにPEルータからのルートリフレクタに渡され、およびPルータで見たことはありません。 VPNルートを搬送ルートリフレクタは、「通常の」IPルートを搬送ルートリフレクタから完全に分離することができます。
The fact that two PE routers support a common VPN does not require those PE routers to form an IGP routing adjacency between themselves. The number of adjacencies in the backbone IGP is independent of and unrelated to the number of VPNs supported by any set of PE routers.
2つのPEルータが共通のVPNをサポートしているという事実は、それ自体との間のIGPルーティング隣接関係を形成するために、これらのPEルータを必要としません。骨格IGPにおける隣接の数は、独立したPEルータの任意のセットでサポートされているVPNの数とは無関係です。
No VPN-specific protection and restoration mechanisms are needed; these are general routing considerations, and the VPN scheme is compatible with any protection and restoration mechanisms that may be available.
いいえVPN固有の保護と回復のメカニズムは必要ありません。これらは、一般的なルーティングの考慮事項であり、VPN方式が利用可能である任意の保護及び修復メカニズムと互換性があります。
The SP does not manage the customer's IGP in any way, and routes are never leaked between the SP's IGP and any customer's IGP.
SPは、どのような方法で、顧客のIGPを管理していない、とルートはSPのIGPと任意の顧客のIGPの間でリークされることはありません。
If the PE/CE protocol is EBGP, the SP and the customer do not ever participate in a common IGP.
PE / CEプロトコルがEBGPの場合、SPと顧客は、これまでの一般的なIGPに参加しません。
Generally, this means replacement of an existing legacy backbone with VPN backbone. The general migration mechanism would be to hook up the sites one at a time to the VPN backbone, and to start giving the routes via the VPN backbone preference to routes via the legacy backbone. Details depend on the legacy backbone's IGP. In general, one would have to manipulate the IGP metrics to provide the proper route preference.
一般的に、これは、VPNバックボーンを持つ既存のレガシーバックボーンの交換を意味しています。一般的な移行メカニズムは、VPNバックボーンに一度のサイト1をフックすると、従来のバックボーンを経由してルートにVPNバックボーンの好みを経由してルートを与えて起動することです。詳細は、従来のバックボーンのIGPに依存しています。一般に、一方が適切な経路設定を提供するために、IGPメトリックを操作しなければなりません。
If the legacy backbone routing protocol is OSPF, then migration is best done with OSPF as the PE/CE protocol and the PE supporting the [VPN-OSPF] procedures, OR with BGP as the PE/CE protocol, and the CE supporting the BGP/OSPF interaction specified in [VPN-OSPF].
レガシーバックボーンルーティングプロトコルがOSPFである場合、移行が最良、OR BGP有するPE / CEプロトコルと[VPN-OSPF]手順をサポートPEとしてOSPFを用いて行われるPE / CEプロトコル、およびBGPをサポートCEとして[VPN-OSPF]で指定された/ OSPF相互作用。
With other legacy backbone routing protocols, the proper metrics must be set at the point (PE or CE) where the BGP routes from the SP network are being redistributed into the legacy IGP.
他の従来のバックボーンルーティングプロトコルを用いて、適切なメトリックは、SPネットワークからBGPルートがレガシーIGPに再配布されている点（PEまたはCE）に設定されなければなりません。
There is no upper limit on the number of VPNs per SP network, as there is no one box in the SP network that needs to know of all VPNs. Knowledge of a particular VPN is confined to the PE routers that attach to sites in that VPN, and to the BGP Route Reflectors that receive routing data from those PEs; other systems maintain no state at all for the VPN. Note though that there is no need for any one Route Reflector to know of all VPNs.
すべてのVPNのかを知る必要があり、SPネットワークには1箱がないので、SPのネットワークごとのVPNの数に上限はありません。特定のVPNの知識はそのVPNのサイトに、それらのPEからのルーティングデータを受信するBGPルートリフレクタに取り付けるPEルータに限定されます。他のシステムは、すべてのVPNのための状態を維持しません。いずれかのルートリフレクタは、すべてのVPNを知る必要がないことのに注意してください。
If the SP is providing the VPN service over an MPLS backbone, then the backbone IGP must carry a host route for every Label Switched Path (LSP) egress node within the routing domain. Every PE router in the routing domain is an LSP egress node. If there are VPNs attached to PE routers that are within the routing domain, as well as PE routers that are in some second routing domain, then the border routers leading towards the second routing domain will also be LSP egress nodes. Thus, the sum of the number of PE routers plus number of border routers within a routing domain is limited by the number of routes that can be carried within the domain's IGP. This does not seem to create any practical scalability issue.
SPは、MPLSバックボーン上でVPNサービスを提供している場合は、バックボーンIGPは、ルーティングドメイン内のすべてのラベルスイッチパス（LSP）出口ノードのホストルートを運ばなければなりません。ルーティングドメイン内のすべてのPEルータがLSPの出口ノードです。いくつかの第2のルーティングドメイン内にあるルーティングドメイン内にあるPEルータに取り付けられたVPN、ならびにPEルータが存在する場合、第2のルーティングドメインに向け主要境界ルータはまた、LSPの出口ノードであろう。従って、PEルータプラスルーティングドメイン内の境界ルータの数の数の合計は、ドメインのIGP内で実施することができる経路の数によって制限されます。これは、任意の実用的なスケーラビリティの問題を作成していないようです。
There is no upper limit on the number of site interfaces per VPN, as state for a particular interface is maintained only at the PE router to which that interface attaches. The number of site interfaces per VPN at a given PE router is limited only by the number of interfaces that that PE router can support.
特定のインターフェイスのための状態のみ、そのインターフェイスが添付のPEルータで維持されるようにVPN当たりサイトインターフェイスの数に上限は存在しません。所与のPEルータでVPN当たりサイトインターフェースの数は、そのPEルータがサポートできるインターフェイスの数によって制限されます。
The number of routes per VPN is constrained only by the number of routes that can be supported in BGP, the number of routes that can be maintained in the PEs that attach to that VPN, and the number of routes that can be maintained in the BGP Route Reflectors that hold the routes of that VPN.
VPNあたりのルートの数は、BGPでサポートすることができる経路の数、そのVPNに接続するPEに維持することができる経路の数、およびBGPに維持することができる経路の数によって制約されますそのVPNのルートを保持するルートリフレクタ。
The major constraint in considering scalability is the number of routes that a given PE can support. In general, a given PE can support as many VPNs as it has interfaces (including virtual interfaces or "sub-interfaces", not just physical interfaces), but it is constrained in the total number of routes it can handle. The number of routes a given PE must handle depends on the particular set of VPNs it attaches to, and the number of routes in each such VPN, and the number of "non-VPN" Internet routes (if any) that it must also handle.
スケーラビリティを考慮に主要な制約は、所与のPEをサポートすることができる経路の数です。それは（仮想インターフェイスまたは「サブインターフェース」を含むだけでなく、物理インターフェイス）インターフェイスを有するように、一般的に、所与のPEは、多くのVPNをサポートすることができ、それは、それが処理できるルートの合計数に制約されます。所与のPEが処理しなければならない経路の数はそれに付着VPNの特定のセット、およびそのような各VPN内のルートの数、そしてそれはまた、処理しなければならないことは、「非VPN」インターネットルート（もしあれば）の数に依存します。
The SP may need to engage in significant planning to ensure that these limits are not often reached. If these limits are reached, it may be necessary either to replace the PE with one of larger capacity or to reorganize the way in which access links lead from CEs to PEs, in order to better concentrate the set of access links from sites that are in the same VPN. Rehoming a site to a different PE may not involve actual rewiring; if the access technology is switched, this is a matter of provisioning, but may still be a significant undertaking. If it is necessary to have downtime while performing the rehoming, the customer is impacted as well. Rehoming can also be done "virtually", by creating a layer 2 tunnel from a CE's "old" PE to its "new" PE.
SPは、これらの制限が頻繁に達していないことを保証するために重要な計画に従事する必要があるかもしれません。これらの制限に達した場合、より良いしているサイトからのアクセスリンクのセットを集中するために、大容量のものにPEを交換するか、リンクがのCEからPEにつながるアクセスする方法を再編成するのいずれかが必要な場合があり同じVPN。別のPEにサイトをリホームすることは、実際の再配線を伴わない場合があります。アクセス技術が切り替えられた場合、これは、プロビジョニングの問題ですが、それでも重要な仕事かもしれません。それはリホームを行いながら、ダウンタイムを持っていることが必要であるならば、顧客も同様に影響を受けています。リホームはまた、「新しい」PEへのCEの「古い」PEからレイヤ2トンネルを作成することにより、「事実」に行うことができます。
An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN routes. This is unlike the case of the Internet, where the Internet BGP system must carry all the Internet routes. The difference stems from the fact that all Internet addresses must be reachable from each other, but a given VPN address is only supposed to be reachable from other addresses in the same VPN.
覚えておくべき重要な考慮事項は、1つのVPNルートを運ぶ独立BGPシステムの任意の番号を持つことです。これは、インターネットBGPシステムは、すべてのインターネットルートを運ばなければならないインターネットの場合とは異なります。違いは、すべてのインターネットアドレスが互いに到達可能でなければならないという事実から生じるが、与えられたVPNアドレスは、同じVPN内の他のアドレスから到達可能であると考えられます。
Scalability is also affected by the rate of changes in the reachability advertisements from CE to PE, as changes reported by a CE to its attached PE may be propagated to the other PEs. BGP mechanisms to control the rate of reported changes should be used by the SP.
その添付のPEにCEによって報告された変更が他のPEに伝播することができるように、スケーラビリティはまた、CEからPEへの到達可能性広告の変化の速度に影響されます。報告された変化の速度を制御するためにBGPメカニズムはSPによって使用されるべきです。
Another constraint on the number of VPNs that can be supported by a particular PE router is based on the number of routing instances that the PE router can support. If the PE/CE routing is static, or is done by BGP, the number of routing protocol instances in a PE device does not depend on the number of CEs supported by the PE device. In the case of BGP, a single BGP protocol instance can support all CEs that exchange routing information using BGP. If the PE/CE router is done via RIP or OSPF, then the PE must maintain one RIP or OSPF instance per VRF. Note that the number of routing instances that can be supported may be different for different routing protocols.
特定のPEルータによってサポートすることができるVPNの数の別の制約は、PEルータがサポートすることができるルーティングインスタンスの数に基づいています。 PE / CEルーティングが静的であるか、またはBGPによって行われる場合、PE装置におけるルーティングプロトコルのインスタンスの数は、PEデバイスによってサポートされるCEの数に依存しません。 BGPの場合には、単一のBGPプロトコルインスタンスは、BGPを使用してルーティング情報を交換するすべてのCEをサポートすることができます。 PE / CEルータがRIPやOSPFを介して行われている場合、PEはVRFごとに1つのRIPやOSPFインスタンスを維持しなければなりません。サポートすることができるルーティングインスタンスの数が異なるルーティングプロトコルのために異なっていてもよいことに留意されたいです。
Inter-AS scenarios constructed according to option (b) of section 10 of [BGP-MPLS-IP-VPN] require BGP "border routers" to hold the routes for a set of VPNs. If two SPs share in a small number of VPNs, a single border router between them provides adequate capacity. As the number of shared VPNs increases, additional border routers may be needed to handle the increased number of routes. Again, no single border router would handle all the routes from all the VPNs, so an increase in the number of VPNs can always be supported by adding more border routers.
[BGP-MPLS-IP-VPN]のセクション10のオプションに従って構成されたインターASシナリオ（B）は、VPNのセットのルートを保持するためにBGP「ボーダールーター」を必要とします。 2つのSPは、VPNの少数で共有している場合は、それらの間の単一の境界ルータには十分な容量を提供します。共有のVPNの数が増加するように、追加の境界ルータは経路数の増加に対処するために必要とされてもよいです。ここでも、単一の境界ルータは、そのVPNの数の増加は、常により多くの境界ルータを追加することによりサポートすることができ、すべてのVPNからのすべてのルートを処理しないだろう。
Inter-AS scenarios constructed according to option (c) of section 10 of [BGP-MPLS-IP-VPN] eliminate the need for border routers to contain VPN routes (thus improving scalability in that dimension), but at the cost of requiring that each AS have a route to the PEs in the others.
[BGP-MPLS-IP-VPN]のセクション10の間ASオプションに従って構成シナリオ（c）は（従ってその次元に拡張性を向上）境界ルータは、VPNルートを含むようにする必要性を排除する、それを必要とするコストで各ASは、他でのPEへのルートを持っています。
(Inter-AS scenarios constructed according to option (a) of section 10 of [BGP-MPLS-IP-VPN] do not scale well.)
（（A）BGP-MPLS-IP-VPN]のセクション10のオプションに従って構成されたインターASシナリオはうまくスケーリングしません。）
The solution of [BGP-MPLS-IP-VPN] is intended to simplify CE and site operations, by hiding the structure of the rest of the VPN from a site, and by hiding the structure of the backbone. Thus, CEs need have only a single sub-interface to the backbone, CEs at one site need not even be aware of the existence of CEs at another, and CEs at one site need not be routing peers of CEs at another. CEs are never routing peers of P routers. These factors help to scale the customer's network, but limiting the number of adjacencies each CE must see, and by limiting the total number of links that the customer's IGP must handle.
[BGP-MPLS-IP-VPN]の溶液は、および骨格の構造を非表示にすることで、サイトからのVPNの残りの部分の構造を非表示にすることにより、CEおよびサイト運営を簡素化することを意図しています。このように、CEがバックボーンにのみ単一のサブインターフェイスを持つ必要がある、一つのサイトでのCEは、さらに別のCEの存在を意識する必要はなく、一つのサイトでのCEは、別のCEのピアをルーティングする必要はありません。 CEはPルータのルーティングピアされることはありません。これらの要因は、顧客のネットワークを拡張するのに役立ちますが、各CEは見なければならない、と顧客のIGPは、処理しなければならないリンクの総数を制限することで、隣接の数を制限します。
The solution of [BGP-MPLS-IP-VPN] is also intended to simplify the SP's VPN provisioning, so that potentially the SP will have to do little more than say which sites belong to which VPNs. However, as the system scales up, planning is needed to determine which PEs should home which VPNs, and which BGP RRs should take which VPNs' routing information.
[BGP-MPLS-IP-VPN]の溶液はまた、潜在的にSPがどのVPNに属するサイトと言うより少しを行う必要がありますように、SPのVPNのプロビジョニングを簡素化することを意図しています。システムがスケールアップしかし、計画がどのPEがなければならない家庭たVPNを、どのBGPのRRは、VPNのルーティング情報を取るべきかを決定するために必要とされます。
P routers maintain NO per-VPN state at all; the only requirement on them is to maintain routes to the PE routers. When MPLS is used, a P router must also maintain one multipoint-to-point LSP for each such route.
Pルータは全く当たり-VPN状態を維持していません。それらの唯一の要件は、PEルータへのルートを維持することです。 MPLSを使用した場合、Pルータはまた、そのような各経路に対して1つのマルチポイント・ツー・ポイントLSPを維持しなければなりません。
However, certain VPN multicast schemes require per-multicast-group state in the P routers, summed over all VPNs. Others require only no state in the P routers at all, but will result in sending more unnecessary traffic. The complete set of tradeoffs for multicast is not that well understood yet.
しかし、特定のVPNマルチキャスト方式は、すべてのVPNを超える合計、Pルータに当たりマルチキャストグループの状態を必要とします。その他には、すべてのPルータでのみなし状態を必要としないが、より多くの不要なトラフィックを送信になります。マルチキャストのためのトレードオフの完全なセットは、まだよく理解されていません。
Note that as the scaling of a particular PE is primarily a matter of the total number of routes that it must maintain, scalability is facilitated if the addresses are assigned in a way that permits them to be aggregated (i.e., if the customers have a sensible addressing plan).
顧客が賢明なを持っている場合、アドレスは、（すなわち集約するためにそれらを許可するように割り当てられている場合、特定のPEのスケーリングは、主に、それは維持しなければならないルートの合計数の問題であるとして、スケーラビリティが促進されることに注意してください）計画に取り組みます。
When a dynamic routing protocol is run on the link between a CE router and a PE router, routing instability in the private network may have an effect on the PE router. For example, an unusually large number of routing updates could be sent from the CE router to the PE router, placing an unusually large processing load on the PE router.
動的ルーティングプロトコルはCEルータとPEルータ間のリンク上で実行されたときに、プライベートネットワーク内のルーティングの不安定性は、PEルータに影響を与えることができます。例えば、ルーティング更新の異常に多数のPEルータで異常に大きな処理負荷をかける、PEルータにCEルータから送信することができます。
This issue can be mitigated via resource partitioning in the PE, in order to limit the amount of resources (e.g., CPU and memory) that any one VPN is permitted to use in PE routers. Also, rate limits may be applied to the routing traffic sent from the CE to the PE.
この問題は、いずれかのVPNがPEルータで使用することが許可されているリソースの量（例えば、CPUおよびメモリ）を制限するために、PEに資源分割を介して緩和することができます。また、レート制限は、PEにCEから送信されたルーティング・トラフィックにも適用することができます。
Alternately, when this problem is detected, the CE-to-PE interface may be shut down.
この問題が検出されたときに交互に、CE-に-PEインターフェイスがシャットダウンされてもよいです。
The provision of appropriate QoS capabilities may require any combination of the following:
適切なQoS機能の提供は、以下のいずれかの組み合わせを必要とするかもしれません。
- QoS in the access network.
- アクセスネットワークにおけるQoSの。
- Admission control (policing) by the PE router on the ingress access links.
- アドミッション制御（ポリシング）イングレス・アクセスリンク上のPEルータによります。
- Traffic conditioning (shaping) by the PE router on the ingress access links.
- イングレスアクセスリンク上のPEルータによってトラフィック調整（整形します）。
- Traffic engineering in the backbone.
- バックボーンにおけるトラヒックエンジニアリング。
- Intserv/diffserv classification by the PE, for traffic arriving from the CE. Once the PE classifies the user packets, this classification needs to be preserved in the encapsulation (MPLS or IP) used to send the packet across the backbone.
- CEから到着するトラフィックのためのPEによるイントサーブ/ DiffServの分類、。 PEは、ユーザパケットを分類すると、この分類は、バックボーン上のパケットを送信するために使用されるカプセル化（MPLS又はIP）に保存する必要があります。
- Differentiated Services Codepoint (DSCP) mapping.
- 差別化サービスコードポイント（DSCP）のマッピング。
- DSCP transparency.
- DSCP透過性。
- Random Early Discard in the backbone.
- バックボーンにおけるランダム早期廃棄。
None of these features are VPN-specific. The ability to support them depends on whether the features are available on the edge and core platforms, rather than on any particular VPN scheme.
これらの機能はいずれも、VPN固有ではありません。それらをサポートする能力は、機能ではなく、任意の特定のVPN方式に比べて、エッジおよびコアプラットフォーム上で利用可能であるかどうかに依存します。
MPLS support for differentiated services is detailed in RFC 3270 [MPLS-DIFFSERV]. DSCP mapping and transparency are covered in section 2.6 of that document.
差別化サービスのためのMPLSのサポートは、RFC 3270 [MPLS-DIFFSERV]に詳述されています。 DSCPマッピングと透明性は、そのドキュメントのセクション2.6で説明されています。
It is possible to use traffic engineering to provide, e.g., guaranteed bandwidth between two PEs for the traffic of a given VPN. The VRF entries for that VPN in each PE need to be modified so that the traffic to the other PE is directed onto the traffic-engineered path. How this is done is a local matter.
与えられたVPNのトラフィックのための2つのPE間、例えば、保証された帯域幅を提供するために、トラフィックエンジニアリングを使用することが可能です。各PEでそのVPNのためのVRFエントリが他のPEへのトラフィックは、トラフィックエンジニアリングパス上に向けられるように改変される必要があります。これはどのように行われているローカルの問題です。
BGP/MPLS IP VPNs can support both the "hose model" and the "pipe model" of QoS. In the "pipe model", a particular quality of service (e.g., a guaranteed amount of bandwidth) would be applied to all or some of the packets traveling between a given pair of CEs. In the "hose model", a particular quality of service (e.g., a guaranteed amount of bandwidth) would be applied to all traffic to or from a particular CE, irrespective of which other CE the traffic is going to or coming from. Since BGP/MPLS IP VPNs do not usually make use of CE-CE tunnels, the hose model is the more natural fit. Providing the pipe model would require the use of traffic engineering to explicitly create the necessary tunnels.
BGP / MPLS IP VPNは、「ホースモデル」とQoSの「パイプモデル」の両方をサポートすることができます。 「管モデル」、サービスの特定の品質（例えば、帯域幅の保証量）でCEの所定の対間を移動するパケットの全部または一部に適用されます。 「ホース・モデル」、サービスの特定の品質（例えば、帯域幅の保証量）にかかわらずトラフィックに行くか、から来ている他のどのCEの、または特定のCEからのすべてのトラフィックに適用されます。 BGP / MPLS IP VPNは通常、CE-CEトンネルを利用していないので、ホースモデルは、より自然なフィット感です。パイプモデルを提供することは、明示的に必要なトンネルを作成するために、トラフィックエンジニアリングの使用を必要とします。
Many of the requirements specified in [L3VPN-REQS] stipulate that the Network Monitoring System (NMS) should support SLA monitoring and verification between the SP and the various customers by measurement of the indicators defined within the context of the SLA. The measurement of these indicators (i.e., counters) can be achieved when BGP/MPLS IP VPNs are used by employing a combination of the Management Information Base (MIB) module designed for BGP/MPLS IP VPNs [L3VPN-MIB] as well as other standard MIB modules such as the IF-MIB [IF-MIB]. Devices supporting these MIB modules can calculate SLAs based on real-time performance measurements using indicators and threshold crossing alerts. Devices can make these thresholds configurable either via a management interface such as SNMP.
[L3VPN-REQS]で指定された要件の多くは、ネットワーク監視システム（NMS）はSLAのコンテキスト内で定義された指標の測定によってSPと様々な顧客との間のSLAの監視と検証をサポートする必要があることを規定しています。 BGP / MPLS IP VPNのは、他と同様にBGP / MPLS IP VPNの[L3VPN-MIB]のために設計された管理情報ベース（MIB）モジュールの組み合わせを使用することによって使用されるときにこれらの指標（すなわち、カウンタ）の測定を達成することができますこのようなIF-MIB [IF-MIB]のような標準的なMIBモジュール。これらのMIBモジュールをサポートするデバイスは、指標としきい値超過アラートを使用してリアルタイムのパフォーマンス測定値に基づいてSLAを計算することができます。デバイスは、これらの閾値は、いずれかの設定可能なSNMPなどの管理インタフェースを介して行うことができます。
The L3VPN Requirements document [L3VPN-REQS] stipulates that the term "Provider Provisioned VPN" refers to VPNs for which the service provider participates in management and provisioning of the VPN. RFC BGP/MPLS IP VPNs can be provisioned and managed to meet these requirements. The following subsections will outline how devices supporting BGP/MPLS IP VPNs can satisfy these requirements.
L3VPN要件文書[L3VPN-REQS]用語「プロバイダプロビジョニングVPN」は、サービス・プロバイダがVPNの管理およびプロビジョニングに参加するためのVPNを指すことを規定しています。 RFC BGP / MPLS IP VPNは、プロビジョニングおよびこれらの要件を満たすために管理することができます。以下のサブセクションでは、BGP / MPLS IP VPNをサポートするデバイスは、これらの要件を満たすことができる方法を概説します。
The SP manages all the VPN-specific information in the PE device. This can be done using the MIB designed for BGP/MPLS IP VPNs [L3VPN-MIB], in combination with other standard MIB modules such as IF-MIB [IF-MIB], and other MPLS MIB modules [LSRMIB], [LDPMIB], [TEMIB], [FTNMIB].
SPは、PEデバイス内のすべてのVPNに固有の情報を管理します。これは、IF-MIB [MIB-IF]、及び他のMPLS MIBモジュール[LSRMIB]、[LDPMIB]のような他の標準MIBモジュールと組み合わせて、BGP / MPLS IP VPNのために設計されたMIB [L3VPN-MIB]を用いて行うことができます[TEMIB]、[FTNMIB]。
Devices supporting BGP/MPLS IP VPNs that employ the management interface characteristics described above will also support the ITU-T Telecommunications Management Network Model "FCAPS" functionalities as required in the L3VPN Requirements document. These include Fault, Configuration, Accounting, Provisioning, and Security.
また、ITU-T電気通信管理ネットワークモデル「FCAPS」L3VPN要件文書に必要とされる機能をサポートしています上記の管理インターフェイスの特性を利用しBGP / MPLS IP VPNをサポートするデバイス。これらは、障害、設定、アカウンティング、プロビジョニング、およびセキュリティが含まれます。
In BGP/MPLS IP VPNs, the SP is not required to manage the CE devices. However, if it is desired for the SP to do so, the SP may manage CE devices from a central site, provided that a route to the central site is exported into the CE's VPN, and the central site is in a VPN into which the routes to the managed CE devices have been imported.
BGP / MPLS IP VPNのでは、SPは、CEデバイスを管理するために必要とされていません。それはそうするSPが望まれる場合には、中央サイトからCEデバイスを管理するSPは、中央サイトへのルートは、CEのVPNにエクスポートされていることを提供し、中央サイトは、VPNであり、その中に管理CEデバイスへのルートは、インポートされています。
This is a form of extranet.
これは、エクストラネットの形です。
If the central site is managing CE devices from several VPNs, those CE devices must have mutually unique addresses. Note that this does not enable the CE devices from different VPNs to reach each other.
中央サイトは、いくつかのVPNからCEデバイスを管理している場合は、それらのCEデバイスが相互に固有のアドレスを持っている必要があります。これはお互いに到達するために異なるVPNからCEデバイスを有効にしないことに注意してください。
The CE devices have no VPN-specific information in them. Hence the fact that they are connected together into a VPN does not require them to have any VPN-specific management MIB modules or capabilities.
CEデバイスは、それらにはVPN固有の情報を持っていません。したがって、それらはVPNに一緒に接続されているという事実は、任意のVPN固有の管理のMIBモジュールや機能を持つためにそれらを必要としません。
CE devices may be managed from within the VPN, transparently to the SP. The CE devices have no VPN-specific information in them, and the fact that they are tied together into a VPN does not impact the customer's management of them.
CEデバイスは、透過的にSPに、VPN内から管理することができます。 CEデバイスは、それらにはVPN固有の情報を持っていない、と彼らはVPNに一緒に結びついているという事実は、彼らの顧客の経営に影響を与えません。
Customer access to a PE device is totally at the discretion of the SP, but is not required by the solution. The PE device is a routing peer of a CE device, and can be pinged, etc.
PEデバイスへのお客様のアクセスは完全にSPの裁量であるが、解決策によって必要とされていません。 PEデバイスは、CEデバイスのルーティングピアであり、pingを実行することができる、等
If a customer is permitted to access the PE router for management purposes, the functions available to any particular customer need to be strictly controlled, and the use of resource partitioning may be appropriate.
顧客は、管理目的のためにPEルータにアクセスすることを許可されている場合、任意の特定の顧客に利用可能な機能を厳密に制御する必要があり、資源分割の使用が適切であり得ます。
Network management traffic from the CE to the PE may be rate limited (for example, to prevent network management traffic from CE to PE to be used in a DoS attack).
PEへのCEからネットワーク管理トラフィックレート（例えば、DoS攻撃で使用するPEにCEからネットワーク管理トラフィックを防ぐために）制限されてもよいです。
Many thanks to Jeremy De Clercq, Luyuan Fang, Dave McDysan, Ananth Nagarajan, Yakov Rekhter, and Muneyoshi Suzuki, for their comments, criticisms, and help in preparing this document. Thanks also to Thomas Nadeau for his help with the section on management, to Francois LeFaucheur for his help with the section on QoS, and to Ross Callon for his review of the document.
多くの彼らのコメントのためのジェレミー・デ・Clercq、Luyuan牙、デイブMcDysan、Ananth Nagarajan、ヤコフ・レックター、および宗悦鈴木のおかげで、批判し、この文書を作成するには役立ちます。文書の彼のレビューのためにも、トーマスナドーへの管理上のセクションで彼の助けのために、QoSの上の部分で彼の助けのためのフランソワLeFaucheurに、とロスCallonに感謝します。
[BGP-EXT-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
サングリ、S.、タッパン、D.、およびY. Rekhterは、 "BGP拡張コミュニティ属性" [BGP-EXT-COMM]、RFC 4360、2006年2月。
[BGP-MPLS-IP-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[BGP-MPLS-IP-VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[L3VPN-FRMWRK] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[L3VPN-FRMWRK] Callon、R.とM.鈴木、 "レイヤのためのフレームワーク3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4110、2005年7月。
[L3VPN-REQS] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[L3VPN-REQS] Carugi、M.とD. McDysan、 "レイヤ3プロバイダプロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのサービスの要件"、RFC 4031、2005年4月。
[L2VPN-SEC-FRMWRK] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[L2VPN-SEC-FRMWRK]牙、L.、 "プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのセキュリティフレームワーク"、RFC 4111、2005年7月。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Work in Progress, February 2004.
[VPN-OSPF]ローゼン、E.、Psenak、P.、およびP. Pillay-Esnault、進歩、2004年2月に、ワーク "OSPF PE / CEのBGP / MPLS VPNの中のプロトコルとして"。
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Work in Progress, March 2004.
進歩、2004年3月に、仕事を "BGP / MPLS IP VPNの中でループを防止するためにLSAオプションビットを使用する" [OSPF-2547-DNBIT]ローゼン、E.、Psenak、P.、およびP. Pillay-Esnault、。
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., and C. Sargor, "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in Progress, March 2004.
[MPLS / BGP-のIPsec]ローゼン、E.、デClercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、「BGP / MPLSにおけるPE-PEのIPsecトンネルを使用するためのアーキテクチャIP VPN」を、進歩、2004年3月での作業。
[BGP-MPLS-MCAST-VPN] Rosen, E., Cai, Y., and IJ. Wijsnands, "Multicast in MPLS/BGP VPNs", Work in Progress, May 2004.
[BGP-MPLS-MCAST-VPN]ローゼン、E.、カイ、Y.、およびIJ。 Wijsnands、 "MPLS / BGP VPNのでマルチキャスト"、進歩、2004年5月での作業。
[CE-VERIF] Bonica, R., Rekhter, Y., Raszuk, R., Rosen, E., and D. Tappan, "CE-to-CE Member Verification for Layer 3 VPNs", Work in Progress, September 2003.
[CE-VERIF] Bonica、R.、Rekhter、Y.、Raszuk、R.、ローゼン、E.、およびD.タッパン、 "CE-に-CEレイヤ3のためのメンバーの検証VPN" を進行中で働いて、2003年9月。
[FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
【FTNMIB]ナドー、T.、スリニヴァサン、C.、およびA. Viswanathanの、 "マルチプロトコルラベルスイッチング（MPLS）、転送等価クラスへのネクストホップラベル転送エントリ（FEC-TO-NHLFE）管理情報ベース（MIB）"、RFC 3814、2004年6月。
[IPSEC-VPN] De Clercq, J., Paridaens, O., Krywaniuk, A., and C. Wang, "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress, February 2004.
[IPSEC-VPN]デClercq、J.、Paridaens、O.、Krywaniuk、A.、およびC.王、 "IPsecを使用してプロバイダによるCEベースの仮想プライベートネットワークのためのアーキテクチャ"、進歩、2004年2月に作業。
[LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[LDPMIB] Cucchiara、J.、Sjostrand、H.、およびJ.ルチアーニ、RFC 3815、2004年6月 "マルチプロトコル・ラベル・スイッチング（MPLS）、ラベル配布プロトコル（LDP）のための管理オブジェクトの定義"。
[LSRMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[LSRMIB]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルータ（LSR）管理情報ベース（MIB）"、RFC 3813、2004年6月。
[MPLS-DIFFSERV] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPLS-DIFFSERV]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月。
[L3VPN-MIB] Nadeau, T. and H. Van Der Linde, "MPLS/BGP Virtual Private Network Management Information Base Using SMIv2", Work in Progress, August 2004.
[L3VPN-MIB]ナドー、T.とH.ヴァン・デアリンデ、 "SMIv2のを使用したMPLS / BGPバーチャル・プライベート・ネットワーク管理情報ベース"、進歩、2004年8月での作業。
[IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[IF-MIB] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[TEMIB]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[VR-VPN] Knight, P., Ould-Brahim, H., and B. Gleeson, "Network Based IP VPN Architecture using Virtual Routers", Work in Progress, April 2004.
[VR-VPN]騎士、P.、ウルド・ブライム、H.、およびB.グリーソン、 "仮想ルーターを使用して、ネットワークベースのIP VPNアーキテクチャ"、進歩、2004年4月に作業。
Author's Address
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。