[要約] RFC 4365は、BGP/MPLS IP VPNsの適用性に関する声明であり、BGP/MPLS IP VPNsの設計と展開に関するガイドラインを提供します。このRFCの目的は、BGP/MPLS IP VPNsの利点と制約を明確にし、ネットワークエンジニアが効果的なVPNソリューションを実装できるようにすることです。
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)
BGP/MPLS IP仮想ネットワーク（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).
Copyright（c）The Internet Society（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/MPLS IP VPNS」と呼びます。これは、境界ゲートウェイプロトコル（BGP）を使用してルートの分布に使用され、マルチプロトコルラベルスイッチング（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.
* MPLS対応のエッジルーターを備えたIPバックボーンがあり、MPLS対応コアルーターを備えた（必ずしもそうではありませんが）。
* 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.
基本原則は、各VPNを自己完結型の「インターネット」としてモデル化することです。各サイトでは、SPへの1つ以上のアクセス接続を行い、SPをルーティング情報を送信し、SPに依存してルーティング情報を配布します。同じ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).
プロバイダーエッジルーター（PEルーター）をカスタマーエッジルーター（CEルーター）に接続するアクセスリンクでEBGP（さまざまな自律システムのBGPスピーカー間で使用されるBGP手順）が使用されている場合、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は、顧客（エンタープライズ）がサービスプロバイダーが顧客の「バックボーン」（つまり、顧客間の敷地間ルーティング）を操作および維持することを期待する状況に最適化されています。そのため、サービスプロバイダーは企業の「ビジネスパートナー」になります。技術メカニズムは、多くの密接に協力するSPSが、BGPベースのルート分布メカニズムが異なるSPS間で動作できるという点で、顧客にVPNサービスを共同で提供できる場合に対応しています。SPSのセットがサービス品質（QOS）、サービスレベル契約（SLA）などに関して十分な契約を結んでいる場合、顧客のVPNはそのセットから異なるSPSに接続されている可能性があります。
[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が非常に多数（たとえば、数百）のSPSに広がる環境ではありません。
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に接続されたインターフェイス上。リモートポイントツーポイントプロトコル（PPP）接続は、レイヤー2トンネリングプロトコル（L2TP）を介してPEルーターにトンネリングできます。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].)
一部の顧客は、パブリックインターネット上でサイトを接続し、VPNの「仮想バックボーン」を作成したいと考えています。インターネットサービスプロバイダー（ISP）から特定のサイトの接続を購入すると、そのサイトを接続するのに最適な価格を提供します。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 VPNSによって提供されるような「管理されたルーティングサービス」を望まないでしょう。むしろ、彼らは「仮想ルーター」サービスを好むかもしれません。そこでは、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に固有のルーティングテーブルであるVPNルーティングおよび転送テーブル（VRF）でそのPEルーターを構成する必要があります。（これは、[L3VPN-REQS]および[L3VPN-FRMWRK]の言語でVPN転送インスタンス（VFI）として知られています。）指定されたVPNのサイトに付着するPEの各インターフェイスまたはサブインターフェイス（つまり、。そのVPNの各ローカルアクセスリンク）は、そのVRFに関連付けられるように構成する必要があります。このようなインターフェイスはそれぞれ、VPNのアドレススペース内で一意のアドレスを割り当てられていない場合があります。一般に、これらの各リンクでルーティングアルゴリズムを実行する必要があります（代わりに静的ルーティングを使用できます）。ルーティングアルゴリズムは、EBGP、またはルーティング情報プロトコル（RIP）などのIGPまたは最初の最短パス（OSPF）などのIGPです。（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を実行する必要があり、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.
ルートリフレクターを使用する代わりに、他のすべてのPEのアイデンティティで各PEを構成し、IBGP接続の完全なメッシュを設定できます。これは小規模なネットワークには適しているかもしれませんが、大規模なネットワークには十分に拡張されません。スケーラビリティを実現するには、ルートリフレクターの使用が必要です。[BGP-MPLS-IP-VPN]のセクション4.3.3を参照してください。ルートリフレクターの使用と、アウトバウンドルートフィルタリングなどの関連するスケーラビリティメカニズムについてのより完全な議論を参照してください。
Each VRF must be configured with three parameters:
各VRFは、3つのパラメーターで構成する必要があります。
- 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を使用してVPNルーティング情報をSPバックボーン全体に配布する場合、この値は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）は、拡張コミュニティのルートターゲット属性として、VRFの形式でエクスポートされるルートとともに、BGPが携帯するグローバルに一意の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をルーター管理メカニズムを使用して特定のルートに割り当てることができます。RDがRTと同じであることを要求しないことの1つの利点は、これが各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に追加することは、サイトのCEルーターをPEルーターに接続し、インターフェイスを構成し、そのVPNのVRFがPEルーターに既に存在し、そのインターフェイスをVRFに関連付けることの問題です。そのVPNのVRFがPEにまだ存在していない場合、上記で指定して構成する必要があります。PEの構成の変更は、BGPを介して他のPESに自動的に反映されます。
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の識別子として構造化されることにより、一意に作成されます。SPSは、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接続性を制御できます。また、サイトAからサイトBへのデータが3番目のサイトCを移動する必要があるように、任意の方法でルーティングの分布を制約することも可能です（実際、そうすることが望ましい場合、このレベルの制御はCAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN CAN単一のルートの粒度で指定されます。）
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からの一部のルートが1つのリモートサイトのセットに配布される可能性があり、サイト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.
[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ルートは、対応するルーティングメトリックとともに分布しています。これにより、顧客のIGPは、「バックドアルート」をSPバックボーンを使用するルートと適切に比較できます。サイト内でOSPFを実行している顧客がIGPバックドアを希望する特定のケースでは、PE/CEリンクでOSPFを実行する必要があり、PESは[VPN-OSPF]の手順を実行する必要があります。（CESは特別な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に送信されません。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から隠されています。（もちろん、特定のサイトがインターネットトラフィックを受け取ることができ、インターネットからTracerouteプローブに応答した場合、インターネットのユーザーはサイトトポロジについて何かを学ぶことができます。サイトが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サイト間で使用されている場合、およびVPNバックボーン上のルートがOSPF内部ルートに優先されることが望ましい場合は、[VPN-OSPFの「SHAMリンク」手順]使用する必要があります。
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.
顧客ルーター間で使用されるルーティングプロトコルは、VPNで使用されていても、PE/CEアクセスリンクがEBGPを実行する可能性があるため、VPNスキームによって制限されていません。内部リンク。
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つの顧客サイト間を移動するデータは、バックボーンを通過中にカプセル化されています。カプセル化には、パケットが適切なPEルーターに送信され、その後、そのPEのVRFおよび関連情報と組み合わせて適切なCEルーターに送信されるように十分な情報が含まれています。
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 VPNSと同様に、顧客は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.
BGP/MPLS IP VPNSには、PE/CE認証の特定の手段は指定されていません。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ではなく）カスタマーネットワークに自己認証する必要がある標準化された方法はありません。これはさらなる研究のためです。
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 IP VPNSによって転送できるかを制御するための特定の手段は指定されていません。BGP/MPLS IP VPNは、アクセス制御リスト（ACLS）および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に接続するための「アクセスリンク」として使用できます。この場合の認証手順は、VPNスキームの一部ではなく、IPSECの一部です。
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 VPNSにユーザーデータセキュリティが指定されていることを保証する特定の手段はありません。
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に移動する際に、ユーザーデータの認証および/または暗号化を提供するために使用できます。ただし、データはこれら2つのPESと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スキームに対して透過的です。実際、CELTEXT IPヘッダーがCEからPEに渡される限り、VPNスキームは、顧客によるセキュリティの使用と互換性があります。
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.
データがインターネットを横断してIngress PEルーターに到達する必要がある場合、エンドユーザーとPEルーターの間のIPSECトンネルを使用できます。PEルーターは、各IPSECトンネルを適切なVRFに関連付ける必要があります。この関連付けは、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つのSPS間の二国間合意が必要です。BGP接続は、ユーザーデータを保護するために、SPSのペアによって必要とみなされる場合、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.
PE/CEアクセスリンクは何らかの方法で保護する必要がありますが、プロバイダーは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ではなく）カプセル化を使用してVPNサービスを提供している場合、または他のSPからのIPカプセル化VPNパケットを受け入れる場合、他のSPSまたは他の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ルーターに影響を与える可能性があります。たとえば、異常に多数のルーティングアップデートをCEルーターからPEルーターに送信でき、PEルーターに異常に大きな処理荷重を配置します。これは、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.
この問題は、PEルーターでの使用が許可されているリソースの量（CPUやメモリなど）を制限するために、PEでのリソースパーティションを介して軽減できます。また、CEからPEに送信されたルーティングトラフィックにレート制限を適用することができます。あるいは、この問題が検出されると、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).
CEからPEへのネットワーク管理トラフィックは、レートに制限される場合があります（たとえば、DOS攻撃で使用するCEからPEへのネットワーク管理トラフィックを防ぐため）。
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アプローチのapplicabilityステートメントに表示されるはずです」と述べています。このサブセクションの目的は、このテンプレートで必要な形式の情報を提供することです。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は64ビットの数量で、グローバルに一意のRD値をSPによって簡単に作成できるように構造化されています。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によって構成されている場合にのみ、他のVRFSにインポートできます。したがって、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 VPNSでは、SPは、そのPEの特定のVRFに関連付けられるように、そのサイトにPEルーターのインターフェイスを構成することにより、特定のVPNの特定のサイトを作成します。VRFはインポートおよびエクスポートRTSで構成されており、VRFがVPNとして接続されている特定のサイトセットになるさまざまなPEのRTSでVRFを構成する方法です。
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の他のCESは、適切な秘密を知らない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.
不正なパケットを導入しようとする可能性のあるさまざまなポイントを個別に検討する必要があります。
* Packets arriving at a PE over a PE/CE interface
* PE/CEインターフェイス上にPEに到着するパケット
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]のオプションの手順は、バックボーンからPEが受信したパケットが実際に1つない限り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スキームの範囲外のさまざまな方法で実行できます。たとえば、PEルーターにアドレス指定されたIPパケットはフィルタリングできます。MPLSパケット（または、MPLS-in-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パートナーであるSPSにつながるかを知る必要があり、VPNパケットをそれらのインターフェイスに流すことができます。
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メカニズムの範囲外のメカニズムによって提供されなければなりません。たとえば、ユーザーはセキュアプロトコルをエンドツーエンドベースで使用できます。
- 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 VPNSでは、さまざまな異なるトンネルスキームを使用できます。したがって、この質問は範囲外です。
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.
トンネルがLDPによって確立されたMPLSラベルスイッチングルーター（LSR）である一般的なケースでは、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相互作用に関しては、関連する制御プロトコルはBGPであるため、TCP MD5オプションを使用することでメッセージの整合性とピア認証を制御できます。
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.
VPNをプロビジョニングし、PEルーターを管理するためのプロトコル手順は、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.
* データプレーンまたはコントロールプレーンDOS攻撃に対するサービスプロバイダーインフラストラクチャの保護は、プライベート（PPVPNユーザー）ネットワークで発生し、PPVPNメカニズムを対象としています。
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メカニズムの存在は、PEが任意のエンドユーザーからのDOS攻撃に対して多かれ少なかれ脆弱になることはありません。
* 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.
この種のDOS攻撃は、PEルーターがインターネットからアドレス指定できない場合、防止できます。あるいは、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のユーザーがVPNの他のユーザーに対するDOS攻撃をマウントすることを妨げるものは何もありません。ただし、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.
* PPVPNユーザーネットワークからサービスプロバイダーネットワークへのルーティングトラフィックの高レベルまたは悪意のある設計に対する保護。
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ルーターで見られるルーティングイベントが過剰になる可能性があります。この種の攻撃は、特定のVPNからの処理ルーティングイベントを消費できるリソースの量をPEに制限することにより、改善できます。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ネットワークをサポートするために有能である必要はありません。
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トンネルまたは追加のサービスを使用することを期待する必要があります（レイヤーなど。2サービス）spから。
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.
すべての異なるタイプのL3VPNはIPネットワークであるため、2つのIPネットワークがインターワークできるのと同じ方法で、もちろんインターワークできます。たとえば、単一のサイトには、1つのVPNスキームのCEルーターと別のVPNスキームの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サーバーは、VPN-IDをPEに返します。
- 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サーバーは通常、VRFを介してアドレス指定されます（つまり、VPNのプライベートアドレススペースにある場合があります）。
- 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が同じSPネットワーク上にあるかどうかにかかわらず、CEの2つ以上のPESへのホーミングは完全にサポートされています。
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つ以上のPESに接続されている場合、そのすべてのPE/CEリンクを使用して、トラフィックを両方向に運ぶことができます。特に、異なる侵入PESから特定のCEへのトラフィックは、異なる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が他のPE/CEリンクで送信されたトラフィックを制御できるようにする多数のノブが含まれています。また、リンク帯域幅拡張コミュニティ[BGP-Ext-Comm]を使用して、複数の出口PE/CEリンク間でトラフィックがどのように分布するかを制御することもできます。
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の顧客は、ファイアウォールを使用してサイトからデフォルトルートをエクスポートするだけでこれを発生させる可能性があります。一般に、ファイアウォールを備えたサイトでは、ファイアウォールは「Clean Interface」と「Dirty Interface」を区別する必要があるため、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をサポートしているという事実では、これらのPEルーターがIGPルーティングの隣接を形成する必要はありません。バックボーン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である場合、PE/CEプロトコルとしてOSPFおよび[VPN-OSPF]手順をサポートするPE、またはBGPとしてPE/CEプロトコルとしてのPEで移行が最適に行われ、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.
SPネットワークには、すべてのVPNを知る必要があるSPネットワークに1つのボックスがないため、SPネットワークあたりのVPNの数に上限はありません。特定のVPNの知識は、そのVPNのサイトに付着するPEルーターと、それらのPEからルーティングデータを受け取るBGPルートリフレクターに限定されます。他のシステムは、VPNの状態をまったく維持していません。ただし、1つのルートリフレクターがすべての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）Egressノードのホストルートを運ぶ必要があります。ルーティングドメイン内のすべてのPEルーターは、LSP Egressノードです。ルーティングドメイン内にあるPEルーターに接続されているVPNと、いくつかの2番目のルーティングドメインにあるPEルーターがある場合、2番目のルーティングドメインに向かうボーダールーターもLSP Egressノードです。したがって、ルーティングドメイン内の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に付着するPESで維持できるルートの数、および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のルート数、およびそれが処理する必要がある「存在しない」インターネットルート（存在する場合）の数に依存します。。
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をより大きな容量のいずれかに置き換えるか、アクセスリンクがCESからPESへのリードの方法を再編成する必要がある場合があります。同じVPN。別のPEにサイトを再保持すると、実際の再配線が含まれない場合があります。アクセステクノロジーが切り替えられている場合、これはプロビジョニングの問題ですが、それでも重要な事業である可能性があります。リホームの実行中にダウンタイムが必要な場合は、顧客も影響を受けます。CEの「古い」PEから「新しい」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.
覚えておくべき重要な考慮事項は、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.
スケーラビリティは、CEから接続された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を使用してルーティング情報を交換するすべてのCESをサポートできます。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のオプション（b）に従って構築されたAS Inter-ASシナリオは、VPNのセットのルートを保持するためにBGP「Border Routers」が必要です。2つのSPSが少数の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のオプション（c）に従って構築されたAS Inter-ASシナリオは、ボーダールーターがVPNルートを含む必要性を排除します（したがって、その次元でのスケーラビリティを改善します）が、それが必要なコストでそれぞれが他のペスへのルートを持っています。
(Inter-AS scenarios constructed according to option (a) of section 10 of [BGP-MPLS-IP-VPN] do not scale well.)
（[BGP-MPLS-IP-VPN]のセクション10のオプション（a）に従って構築されたAS Inter-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およびサイト操作を簡素化することを目的としています。したがって、CESにはバックボーンに単一のサブインターフェイスしかなく、あるサイトのCESは別のサイトでCESの存在を認識する必要さえなく、あるサイトのCESが別のサイトでCESのピアをルーティングする必要はありません。CESは、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を故郷にするべきか、どの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ルーターに影響を与える可能性があります。たとえば、異常に多数のルーティングアップデートをCEルーターからPEルーターに送信でき、PEルーターに異常に大きな処理荷重を配置します。
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.
この問題は、PEルーターでの使用が許可されているリソースの量（CPUやメモリなど）を制限するために、PEでのリソースパーティションを介して軽減できます。また、CEからPEに送信されたルーティングトラフィックにレート制限を適用することができます。
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.
- IngressアクセスリンクのPEルーターによる入場制御（ポリシング）。
- Traffic conditioning (shaping) by the PE router on the ingress access links.
- Ingressアクセスリンクの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によるintserv/diffserv分類。PEがユーザーパケットを分類すると、この分類は、バックボーン全体にパケットを送信するために使用されるカプセル化（MPLSまたはIP）に保存する必要があります。
- Differentiated Services Codepoint (DSCP) mapping.
- 差別化されたサービスCodePoint（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 VPNSは、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 VPNS [L3VPN-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固有の情報を管理します。これは、BGP/MPLS IP VPNS [L3VPN-MIB]用に設計されたMIBを使用して、IF-MIB [IF-MIB]、および他のMPLS MIBモジュール[LSRMIB]、[LDPMIB]などの他の標準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.
上記の管理インターフェイス特性を採用するBGP/MPLS IP VPNをサポートするデバイスは、L3VPN要件ドキュメントで必要なITU-T Telecommunications Management Networkモデル「FCAPS」機能もサポートします。これらには、障害、構成、会計、プロビジョニング、セキュリティが含まれます。
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 VPNSでは、CEデバイスを管理するためにSPは必要ありません。ただし、SPがそうすることが望まれる場合、SPは中央サイトへのルートがCEのVPNにエクスポートされ、中央サイトがVPNにある場合、中央サイトからCEデバイスを管理する場合があります。管理された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デバイスは、VPN内からSPに透過的に管理できます。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).
CEからPEへのネットワーク管理トラフィックは、レートに制限される場合があります（たとえば、DOS攻撃で使用するCEからPEへのネットワーク管理トラフィックを防ぐため）。
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.
Jeremy de Clercq、Luyuan Fang、Dave McDysan、Ananth Nagarajan、Yakov Rekhter、およびSuzuki Muneyoshiにコメント、批判、およびこの文書の準備に役立ち、ありがとうございました。トーマス・ナドーにも、経営陣に関するセクションを手伝ってくれたこと、QoSに関するセクションの助けを借りてくれたFrancois Lefaucheur、およびドキュメントのレビューをしてくれたRoss Callonにも感謝します。
[BGP-EXT-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-EXT-COMM] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities属性」、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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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. Suzuki、「レイヤー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] Fang、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] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「BGP/MPLS VPNSのPE/CEプロトコルとしてのOSPF」、2004年2月の進行中。
[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.
[OSPF-2547-DNBIT] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「LSAオプションビットを使用してBGP/MPLS IP VPNSでのループを防ぐ」、2004年3月の作業。
[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] Rosen、E.、De Clercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、 "BGP/MPLSでのPE-PE IPSECトンネルの使用のためのアーキテクチャIP VPNS "、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] Rosen、E.、Cai、Y。、およびIJ。Wijsnands、「MPLS/BGP VPNSのマルチキャスト」、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.、Rosen、E。、およびD. Tappan、「レイヤー3 VPNSのCE-CE-CE-CEメンバー検証」、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] Nadeau、T.、Srinivasan、C。、およびA. Viswanathan、「マルチプロトコルラベルスイッチング（MPLS）転送等価クラスへの次のホップラベル転送エントリ（FEC-to-NHLFE）管理情報ベース（MIB）、RFC3814、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] De Clercq、J.、Paridaens、O.、Krywaniuk、A。、およびC. Wang、「IPSECを使用したプロバイダープロビジャープロビジョニングベースの仮想プライベートネットワークのアーキテクチャ」、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. Luciani、「マルチプロトコルラベルスイッチング（MPLS）の管理オブジェクトの定義、ラベル分布プロトコル（LDP）」、RFC 3815、2004年6月。
[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] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J。Heinanen、「Multi-Protocol差別化されたサービスのラベルスイッチング（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] Nadeau、T。およびH. van der Linde、「MPLS/BGP仮想プライベートネットワーク管理情報ベースをSMIV2を使用して」、2004年8月、進行中の作業。
[IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[if-mib] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group 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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Knight、P.、Oould-Brahim、H。、およびB. Gleeson、「仮想ルーターを使用したネットワークベースのIP VPNアーキテクチャ」、2004年4月、進行中の作業。
Author's Address
著者の連絡先
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。