RFC4365 日本語訳
4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks(VPNs). E. Rosen. February 2006. (Format: TXT=77924 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rosen Request for Comments: 4365 Cisco Systems, Inc. Category: Informational February 2006
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 4365年のシスコシステムズInc.カテゴリ: 情報の2006年2月
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)インターネット協会(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.
このドキュメントはRFC4364で説明されたVirtual兵士のNetwork(VPN)解決とReferences部でリストアップされた他のドキュメントにApplicability Statementを供給します。
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
1. 序論…2 2. モデルに食糧を供給するSP…4 3. Topologiesとトラフィックタイプであるとサポートされます…6 4. データと経路情報の孤立交換…7 5. コントロールと認証にアクセスしてください…9 6. セキュリティ問題…9 6.1. 利用者データの保護…9 6.2. SPセキュリティは測定します…10 6.3. セキュリティフレームワークテンプレート…12 7. 扱います。18 8. 相互運用性であって織り込むこと…19 9. アクセスをネットワークでつないでください…19 9.1. 物理的な/リンクレイヤトポロジー…19 9.2. 一時的なアクセス…19 9.3. 接続性にアクセスしてください…20 10. アクセスを修理してください…21 10.1. インターネットアクセス…21 10.2. 他のサービス…21 11. SPルート設定…22 12. 移行影響…22 13. スケーラビリティ…23 14. QoS、SLA…26
Rosen Informational [Page 1] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[1ページ]のRFC4365適用性証明
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
15. 管理…27 15.1. プロバイダーによる管理…27 15.2. 顧客による管理…28 16. 承認…28 17. 標準の参照…29 18. 有益な参照…29
1. Introduction
1. 序論
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]とReferences部でリストアップされた他のドキュメントで説明されたVirtual兵士のNetwork(VPN)ソリューションにApplicability Statementを提供します。 私たちは「BGP/MPLS IP VPNs」にこれらについて言及します、ボーダ・ゲイトウェイ・プロトコル(BGP)がルートを分配するのに使用されて、Multiprotocol Label Switching(MPLS)が特定のパケットが、特定のルートに従う必要であるのを示すのに使用されるので。 BGP/MPLS IP VPNsの特性は[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サービスはService Provider(SP)によって顧客(時々企業と呼ばれる)に提供されます。 BGP/MPLS IP VPNsが状況のために中で意図する、どれ、:
- 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.
顧客が彼のサイトに発送されたインフラストラクチャを持っているなら、彼は、彼のサイトルーティング・アルゴリズムに、SPバックボーンネットワークのどんな部分も意識している必要であって欲しくはありません、サイトが付けているProvider Edge(PE)ルータを除いて。 顧客は、彼のルータに、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によって可能にされた縁のルータ、およびことによると(必ずはありませんが)MPLSによって可能にされたコアルータがあるIPバックボーンを持っています。
Rosen Informational [Page 2] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[2ページ]のRFC4365適用性証明
* 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にアクセスするところでルーティング情報を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).
EBGP(BGPスピーカーの間で異なったAutonomous Systemsから用いられたBGP手順)がProvider Edgeルータを接続するアクセスリンクの上に使用されるなら(PEルータ) 次に、Customer Edgeルータへの(CEルータ)、SP、および顧客はすなわち、どんなInteriorゲートウェイプロトコル(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 VPNsは顧客(企業)が、サービスプロバイダーが顧客の「バックボーン」(すなわち、顧客の相互サイトルーティング)を運用して、維持すると予想する状況のために最適化されます。 そういうものとして、サービスプロバイダーは企業の「ビジネスパートナー」になります。 技術的機構は多くの密接に協力関係を持っているSPsが共同で顧客に対するVPNサービスを提供できる場合を収容します、BGPベースのルート分配メカニズムが異なったSPsの間で動作できるので。 Service(QoS)、サービス・レベル・アグリーメント(SLA)などのQualityに関してSPsの1セットに十分な協定があるなら、顧客の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が異なったSPsにサイトを添付させることができる相互AS(自治のSystem)メカニズムを指定します。 しかしながら、デザインセンターは与えられたVPNが多くのSPs(例えば、数百)の中で広げられる環境ではありません。
Rosen Informational [Page 3] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[3ページ]のRFC4365適用性証明
In cases where remote offices, individual telecommuters, etc., must use the public Internet to access the VPN, it is possible to "tunnel" the remote traffic to a PE router, and the PE router will treat the traffic as if it had arrived over an interface connected to the PE. Remote Point-to-Point Protocol (PPP) connections can be tunneled via Layer 2 Tunneling Protocol (L2TP) to a PE router; IPsec tunnels can also be used to tunnel traffic to a PE router across the public Internet. Of course, when the public Internet is used, issues such as QoS and SLAs must be carefully considered.
地理的に分散したオフィス、個々の在宅勤務者などがVPNにアクセスするのに公共のインターネットを使用しなければならない場合では、リモートトラフィックがPEルータに「トンネル」であることが可能であり、PEルータはまるでPEに接続されたインタフェースの上で到着したかのようにトラフィックを扱うでしょう。 PEルータへのLayer2Tunnelingプロトコル(L2TP)でPointからポイントへのリモートプロトコル(PPP)接続にトンネルを堀ることができます。 また、公共のインターネットの向こう側にPEルータへのトンネルトラフィックにIPsecトンネルを使用できます。 もちろん、公共のインターネットが使用されているとき、慎重に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]。)
2. SP Provisioning Model
2. モデルに食糧を供給するSP
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
特定のVPNが特定のPEルータに付くなら、SPはVPNルート設定とForwardingテーブル(VRF)(指定されたVPNに特定の経路指定テーブル)でそのPEルータを構成しなければなりません。 (これは[L3VPN-REQS]と[L3VPN-FRMWRK]の言葉を借りて言えばVPN Forwarding Instance(VFI)として知られています。) そのVRFに関連しているように指定されたVPN(そのVPNのすなわちそれぞれの地方のアクセスリンク)のサイトに付くそのPEのそれぞれのインタフェースかサブインタフェースを構成しなければなりません。 そのような各インタフェースは無数であるかもしれない、またはVPNのアドレス空間の中でユニークなアドレスを割り当てられるかもしれません。 一般に、ルーティング・アルゴリズムは、それぞれのこれらのリンクに実行される必要があります(代わりにスタティックルーティングを使用できますが)。 ルーティング・アルゴリズムは、EBGP、ルーティング情報プロトコルなどのIGP(RIP)またはオープンShortest Path Firstであるかもしれません(OSPF)。 (IF OSPFが使用されている、[VPN-OSPF]の手順を実装しなければなりません。) IGPがアクセスリンク、IGP MUSTの上で作業することであるなら、別々のIGPインスタンスで、異なってください。
Rosen Informational [Page 4] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[4ページ]のRFC4365適用性証明
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のアクセスリンクでも走るIGPインスタンスと異なる中で稼働する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.
ルートが局所的に添付のCEルータからPE/CEリンクに実行されるどんなルーティング・アルゴリズムでも分配されている状態で、VRFは自動的に居住されます。 また、ルートがBGPを通して他のVRFsから分配されている状態で、それは自動的に居住されます。 標準のルーティング決定プロセスは、自動的に適切なルートを選択するのに使用されます。 VRFでのルートの静的な構成は任意です。
Each PE router must run BGP, and must be pre-configured with the
identities of a small set of BGP Route Reflectors, with which it is
to peer via IBGP. ("IBGP" refers to the BGP procedures used between
BGP speakers from the same Autonomous System.)
それぞれのPEルータをBGPを実行しなければならなくて、それがIBGPを通してじっと見ることになっているBGP Route Reflectorsの小さいセットのアイデンティティであらかじめ設定しなければなりません。 ("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.
Route Reflectorsを使用することの代わりに、1つは、他のすべてのPEsのアイデンティティで各PEを構成して、IBGP接続の完全なメッシュをセットアップするかもしれません。 小さいネットワークに、これは適切であるかもしれませんが、大きいネットワークによく比例しないでしょう。 Route Reflectorsの使用が、スケーラビリティを達成するのに必要です。 Route Reflectorsの使用の、より完全な議論、およびOutbound Route Filteringなどの関連するスケーラビリティメカニズムに関して.3セクション4.3[BGP-MPLS IP VPN]を見てください。
Each VRF must be configured with three parameters:
3つのパラメタで各VRFを構成しなければなりません:
- A Route Distinguisher. This is a globally unique 8-byte value.
Each VRF may have a unique Route Distinguisher (RD), or there may
be a single unique RD for an entire VPN. When BGP is used to
distribute VPN routing information across the SP backbone, this
value is prepended to the VPN's IPv4 address prefixes, creating a
new address family, the VPN-IPv4 address family. Thus, even when
two VPNs have overlapping IPv4 address spaces, they have unique
VPN-IPv4 address spaces.
- ルートDistinguisher。 これはグローバルにユニークな8バイトの値です。 各VRFにはユニークなRoute Distinguisher(RD)があるかもしれませんか、または全体のVPNのための独身のユニークなRDがあるかもしれません。 BGPがSPバックボーンの向こう側にVPNルーティング情報を分配するのに使用されるとき、この値はVPNのIPv4アドレス接頭語にprependedされます、新しいアドレスファミリー(VPN-IPv4アドレスファミリー)を創設して 2VPNsに重なっている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.
- 1Export Route Targets。 Route Target(RT)はBGPが運ぶグローバルにユニークな8バイトの値です、Extended Communities Route Target属性としてエクスポートされるルートと共にVRFを形成してください。
- One or more Import Route Targets. This RT is used to select
routes to be imported from other VRFs into this VRF.
- 1Import Route Targets。 このRTは、ルートが他のVRFsからこの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
最も簡単なケースとほとんどのよくある例では、Export RT、Import RT、およびRDは同じである場合があります、そして、同じVPNのすべてのVRFsが互い(典型的なイントラネット)にルートを分配するでしょう。 より複雑な場合では、まさしくその罰金を許容して、それらを異なって設定できます。
Rosen Informational [Page 5] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[5ページ]のRFC4365適用性証明
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.
VRFsの中のルートの分配の上の統制度。 エクストラネットを作成するか、または様々な顧客方針を実施するのにこれを使用できます。 複雑な場合では、特定のExport RTsを特定のルートにルータ管理メカニズムを使用することで割り当てることができます。RDがどんなRTとも同じであることが必要でないことの1つの利点はこれが、RD値が各VRFのために自動的に決定するのを許容するかもしれないということです。 他方では、いつも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の構成への変化は他のPEsへのBGPを通して自動的に反映されます。
The RTs and RDs are made unique by being structured as an SP identifier followed by a number which is assigned by the identified SP. SPs may be identified by their AS numbers, or by a registered IP address owned by that SP.
特定されたSPによって割り当てられる数に従ってSP識別子が従ったので構造化されることによって、RTsとRDsをユニークにします。 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.
RTsはBGP Extended Communitiesとしてコード化されますが、コード化自体はBGP Extended Communityのいかなる他の種類とも彼らを区別します。
3. Supported Topologies and Traffic Types
3. Topologiesとトラフィックタイプであるとサポートされます。
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には、完全なコントロールがあります、Route Targets、VRFsのセットの中のルーティング情報の分配のメカニズムを通して。 これは完全なメッシュの接続性としてハブとスポークを提供する同じくらい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を通って移動しなければならないように。(事実上、そうするのが必要であるなら、ただ一つのルートの粒状でこの管理水準を指定できます。)
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からの他のルートが異なったリモートサイトに分配されますが。 Route Targetメカニズムが以前に説明されている状態で、これをします。
Rosen Informational [Page 6] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[6ページ]のRFC4365適用性証明
Unicast IP traffic is fully supported. Customer IP packets are passed transparently.
ユニキャストIPトラフィックは完全にサポートされます。 顧客IPパケットは透過的に通過されます。
Multicast IP traffic is optionally supported, if the SP provides the optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are, however, scaling implications to the use of these mechanisms. Discussion of these implications is deferred.
SPが[BGP-MPLS-MCAST-VPN]の任意のメカニズムを提供するなら、マルチキャストIPトラフィックは任意にサポートされます。 しかしながら、これらのメカニズムの使用へのスケーリング含意があります。これらの含意の議論は延期されます。
Non-IP traffic is not supported. If support for non-IP traffic is necessary, either the SP must additionally provide a layer 2 tunneling service or the customer must use IP tunneling.
非IPトラフィックはサポートされません。 非IPトラフィックのサポートが必要であるなら、SPはさらに、2トンネリングサービスか顧客が使用しなければならない層にIPトンネリングを供給しなければなりません。
In general, customer routers at different sites do not become routing peers. However, a customer may, if he so desires, allow routers at different sites to be routing peers over a link that is NOT part of the VPN service. Such peering relationships are known as "IGP backdoors". To ensure the proper operation of routing when IGP backdoors are present, each VPN route that is distributed by the SP is distributed along with a corresponding routing metric. This enables the customer's IGP to compare the "backdoor routes" properly with the routes that use the SP backbone. In the particular case where a customer running OSPF within his sites wishes to have IGP backdoors, he should run OSPF on the PE/CE link, and the PEs should run the procedures of [VPN-OSPF]. (The CEs do NOT require any special OSPF procedures.)
一般に、異なったサイトの顧客ルータはルーティング同輩になりません。 しかしながら、彼がそう望んでいるなら、顧客は、異なったサイトのルータがVPNサービスの一部でないリンクの上のルーティング同輩であることを許すかもしれません。 そのようなじっと見る関係は「IGP裏口」として知られています。 IGP裏口が存在しているとき、ルーティングの適切な操作を確実にするために、SPによって分配されるそれぞれのVPNルートは対応するルーティングと共にメートル法で分配されます。 これは、顧客のIGPが適切にSPバックボーンを使用するルートと「裏口のルート」を比べるのを可能にします。 彼のサイトの中の顧客の実行しているOSPFがIGP裏口を持ちたがっている特定の場合では、彼はPE/CEリンクにOSPFを実行するべきです、そして、PEsは[VPN-OSPF]の手順を実行するはずです。 (CEsはどんな特別なOSPF手順も必要としません。)
4. Isolated Exchange of Data and Routing Information
4. データと経路情報の孤立交換
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).
Route Targetメカニズムはルーティング情報の分配を制御するのに使用されます、1VPNからのルートが別のものに送られないように。 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サイトのトポロジーもインターネットと他のVPNsから隠されます。 (もちろん、特定のサイトがインターネットトラフィックを受けることができて、インターネットからトレースルート徹底的調査に応じるなら、インターネットのどんなユーザもサイトトポロジーに関して何かを学ぶことができます。 サイトが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に漏らされません、そのVPNのVRFがインターネットがルートであるとインポートするために明らかに構成されない場合。
Rosen Informational [Page 7] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[7ページ]のRFC4365適用性証明
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に特に、関連していなければなりません、そして、RTsの適切なセットで各VRFを構成しなければなりません。
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]の「にせのリンク」手順を用いなければなりません。
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体系によって何らかの方法で制限されません、何でもIGPがVPNの中で使用されて、PE/CEアクセスリンクはEBGPを実行するか、またはそうでなければ、サイトの内部のリンクと異なった経路ドメインにあるかもしれないとき。
BGP is used for passing routing information among SPs. BGP may be authenticated by use of the TCP MD5 option, or by operating through an IPsec tunnel.
BGPは、ルーティング情報をSPsに通過するのに使用されます。 BGPは、TCP MD5オプションの使用、またはIPsecトンネルを通って作動することによって、認証されるかもしれません。
Data traveling between two customer sites is encapsulated while in transit through the backbone. The encapsulation contains sufficient information to ensure that the packet is sent to the proper PE router, and then, in conjunction with the VRF and related information at that PE, to the proper CE routers.
2つの顧客サイトの間を移動するデータはトランジットにはある間、バックボーンを通してカプセル化されます。 カプセル化はパケットが適切な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.
2VPNsが同じ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.
トラフィックの分離はFrame RelayかAsynchronous Transfer Mode(ATM)に基づいている古典的なL2 VPNsによって提供されたそれと同様です。 古典的なL2 VPNsのように、顧客は、適切な分離を確実にして、彼のコミュニケーションギヤのセキュリティを維持するために適切にバックボーンネットワークを構成するためにSPを当てにしなければなりません。
Rosen Informational [Page 8] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[8ページ]のRFC4365適用性証明
5. Access Control and Authentication
5. アクセスコントロールと認証
No particular means of PE/CE authentication is specified for BGP/MPLS IP VPNs. PE/CE mutual authentication may be done via any mechanism supported by the routing protocol in which the CE and PE are peers (e.g., use of the TCP MD5 authentication when the PE/CE protocol is BGP), or by any other mechanism that may be desired. With such mechanisms in place, a CE may not join a VPN until the CE authenticates itself to the Service Provider.
PE/CE認証のどんな特定の手段もBGP/MPLS IP VPNsに指定されません。 CEとPEが同輩(例えば、PE/CEプロトコルがBGPであることのTCP MD5認証の使用)であるルーティング・プロトコル、または望まれるかもしれないいかなる他のメカニズムによってもサポートされたどんなメカニズムでもPE/CEの互いの認証をするかもしれません。 そのようなメカニズムが適所にある場合、CEがService Providerにそれ自体を認証するまで、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が顧客ネットワークにそれ自体を認証するのを必要とする標準化法が全くない、(むしろ、SP) 以前、CEはVPNを接合できます。 さらなる研究にはこれがあります。
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 VPNsはPEルータでサポートされるAccess Control Lists(ACLs)といかなる他のフィルタリング機能とも互換性があります。 それが望まれているなら、ファイアウォール直接を通してエクストラネットトラフィックがあるように、ルート設定をセットアップできます。
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に関連しているのは、可能です。 この場合、トンネルのインタフェースの設立にネイティブに使用されるどんな認証も使用されるかもしれません。 例えば、リモート・ユーザーかサイトをVRFに添付するのに「アクセスリンク」としてIPsecトンネルを使用できます。 この場合、認証手順は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に関連づけることができます。 PPPセッションが属するVPNを決定するのにSPのAuthentication、Authorization、およびAccounting(AAA)サーバを使用できます、そして、次に、また、そのセッションを認証する機会を顧客のAAAサーバに与えることができます。
6. Security Considerations
6. セキュリティ問題
6.1. Protection of User Data
6.1. 利用者データの保護
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まで移動するとき利用者データの認証、そして/または、暗号化を提供するのに用いられるかもしれません。 しかしながら、データはそれらの2PEsにおいてPE/CEアクセスリンクの上に暴露されます。
Rosen Informational [Page 9] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[9ページ]のRFC4365適用性証明
The customer may provide his own user data security by using IPsec tunnels that terminate within the customer sites. Such tunnels are transparent to the VPN scheme. Schemes that discover the remote tunnel endpoints automatically and then set up the tunnels automatically as needed are the best fit with this VPN technology. Note that there is no requirement in general that IPsec tunnels between customer sites terminate at CE routers.
顧客は、顧客サイトの中で終わるIPsecトンネルを使用することによって、彼自身のユーザデータ機密保護を提供するかもしれません。 そのようなトンネルはVPN体系に透明です。 自動的に遠く離れたトンネル終点を発見して、次に自動的にトンネルを設立する体系は必要に応じてこのVPN技術がある最良適合です。 顧客サイトの間のIPsecトンネルがCEルータで終わるという一般に、要件が全くないことに注意してください。
The use of end-to-end transport mode IPsec by the customer is also transparent to the VPN scheme. In fact, the VPN scheme is compatible with any use of security by the customer, as long as a cleartext IP header is passed from CE to PE.
また、顧客による終わりから終わりへの交通機関IPsecの使用もVPN体系にわかりやすいです。 事実上、VPN体系は顧客によるセキュリティのどんな使用とも互換性があります、cleartext IPヘッダーがCEからPEまで渡される限り。
When data must cross the Internet to reach the ingress PE router, IPsec tunnels between the end user and the PE router can be used; the PE router must then associate each IPsec tunnel with the proper VRF. This association would have to be based on user-specific information provided by the Internet Key Exchange (IKE) protocol, such as a VPN- id.
データがイングレスPEルータに達するようにインターネットに交差しなければならないとき、エンドユーザとPEルータの間のIPsecトンネルを使用できます。 そして、PEルータはそれぞれのIPsecトンネルを適切なVRFに関連づけなければなりません。 この協会はインターネット・キー・エクスチェンジ(IKE)プロトコルによって提供されたユーザ特殊情報に基づかなければならないでしょう、VPNイドのように。
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.
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.
6.2. SP Security Measures
6.2. SP Security Measures
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.
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.
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.
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.
Rosen Informational [Page 10] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 10] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
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.
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.
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.
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.
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.
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.
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.
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.
Cryptographic authentication of the encapsulated data packets is certainly advantageous when there are multiple SPs providing a single VPN.
Cryptographic authentication of the encapsulated data packets is certainly advantageous when there are multiple SPs providing a single VPN.
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.
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.
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.
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.
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).
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).
Rosen Informational [Page 11] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 11] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
6.3. Security Framework Template
6.3. Security Framework Template
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.
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.
- Does the approach provides complete IP address space separation
for each L3VPN?
- Does the approach provides complete IP address space separation for each L3VPN?
Yes.
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.
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.
- Does the approach provide complete IP route separation for each
L3VPN?
- Does the approach provide complete IP route separation for each L3VPN?
Yes.
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.
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.
Rosen Informational [Page 12] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 12] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
- Does the approach provide a means to prevent improper cross-
connection of sites in separate VPNs?
- Does the approach provide a means to prevent improper cross- connection of sites in separate VPNs?
This requirement is addressed in a way that is beyond the scope
of the VPN mechanisms.
This requirement is addressed in a way that is beyond the scope of the VPN mechanisms.
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.
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.
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.
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.
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.
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.
- Does the approach provide a means to detect improper cross-
connection of sites in separate VPNs?
- Does the approach provide a means to detect improper cross- connection of sites in separate VPNs?
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.
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.
- Does the approach protect against the introduction of
unauthorized packets into each VPN?
- Does the approach protect against the introduction of unauthorized packets into each VPN?
We must look separately at the various points at which one might
attempt to introduce unauthorized packets.
We must look separately at the various points at which one might attempt to introduce unauthorized packets.
Rosen Informational [Page 13] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 13] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
* Packets arriving at a PE over a PE/CE interface
* Packets arriving at a PE over a PE/CE interface
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.
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.
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.
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.
* Packets arriving at a PE over an interface from the backbone
* Packets arriving at a PE over an interface from the backbone
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.
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.
If the optional procedures of [MPLS/BGP-IPsec] are not used,
then the following considerations apply.
If the optional procedures of [MPLS/BGP-IPsec] are not used, then the following considerations apply.
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.
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.
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.
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.
Rosen Informational [Page 14] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 14] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
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.
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.
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.
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.
- Does the approach provide confidentiality (secrecy) protection,
sender authentication, integrity protection, or protection
against replay attacks for PPVPN user data?
- Does the approach provide confidentiality (secrecy) protection, sender authentication, integrity protection, or protection against replay attacks for PPVPN user data?
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.
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.
- Does the approach provide protection against unauthorized traffic
pattern analysis for PPVPN user data?
- Does the approach provide protection against unauthorized traffic pattern analysis for PPVPN user data?
Preventing an observer from obtaining traffic pattern analysis
from the SP network is beyond the scope of the VPN mechanisms.
Preventing an observer from obtaining traffic pattern analysis from the SP network is beyond the scope of the VPN mechanisms.
- Do the control protocol(s) used for each of the following
functions provide for message integrity and peer authentication?
- Do the control protocol(s) used for each of the following functions provide for message integrity and peer authentication?
* VPN membership discovery
* VPN membership discovery
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.
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.
* Tunnel establishment
* 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.
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.
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.
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.
Rosen Informational [Page 15] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 15] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
* VPN topology and reachability advertisement
* VPN topology and reachability advertisement
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.
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.
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.
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.
* VPN provisioning and management
* VPN provisioning and management
The protocols procedures for provisioning VPNs and managing
the PE routers are outside the scope of the VPN scheme.
The protocols procedures for provisioning VPNs and managing the PE routers are outside the scope of the VPN scheme.
* VPN monitoring and attack detection and reporting
* VPN monitoring and attack detection and reporting
The protocols and procedures for monitoring the VPNs are
outside the scope of the VPN scheme.
The protocols and procedures for monitoring the VPNs are outside the scope of the VPN scheme.
- What protection does the approach provide against PPVPN-specific
DoS attacks (i.e., inter-trusted-zone DoS attacks)?
- What protection does the approach provide against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks)?
* 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.
* Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms.
The PE/CE interfaces of a given VPN will generally be
addressable from within that VPN. Apart from that, a user
within an L3VPN has no more access to the service provider
infrastructure than does any user of the Internet.
Therefore, we will focus in this section on possible DoS
attacks against a PE router that may occur when traffic from
within a VPN is addressed to a PE router.
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.
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.
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.
Rosen Informational [Page 16] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 16] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
* Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in the
Internet and aimed at PPVPN mechanisms.
* Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
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 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.
* 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.
* 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.
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.
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.
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.
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.
- Does the approach provide protection against unstable or
malicious operation of a PPVPN user network?
- Does the approach provide protection against unstable or malicious operation of a PPVPN user network?
* Protection against high levels of, or malicious design of,
routing traffic from PPVPN user networks to the service
provider network.
* Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network.
If a dynamic routing algorithm is running on the PE/CE
interface, it can be used to mount an attack on the PE
router, by having the CE present the PE with an excessive
number of routing events. If an end user within a VPN
successfully attacks the routing algorithm of the VPN, that
might also result in an excessive number of routing events
being seen by the PE router. This sort of attack can be
ameliorated by having the PE limit the amount of its
resources that can be expended processing routing events from
a particular VPN. If the PE/CE routing algorithm is BGP,
then such mechanisms as route flap damping may be appropriate
as well.
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.
Rosen Informational [Page 17] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 17] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
* Protection against high levels of, or malicious design of,
network management traffic from PPVPN user networks to the
service provider network.
* Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
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.
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.
* Protection against worms and probes originated in the PPVPN
user networks, sent towards the service provider network.
* Protection against worms and probes originated in the PPVPN user networks, sent towards the service provider network.
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.
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.
7. Addressing
7. Addressing
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.
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.
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.
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.
Network address translation for packets leaving/entering a VPN is possible and is transparent to the VPN scheme.
Network address translation for packets leaving/entering a VPN is possible and is transparent to the VPN scheme.
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.
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.
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.
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.
Layer 2 addresses and identifiers are never carried across the SP backbone.
Layer 2 addresses and identifiers are never carried across the SP backbone.
Rosen Informational [Page 18] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 18] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
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.
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.
8. Interoperability and Interworking
8. Interoperability and Interworking
Interoperability should be ensured by proper implementation of the published standards.
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.
Direct PE-PE interworking over the SP backbone with other VPN solutions is not supported.
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.
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.
9. Network Access
9. Network Access
9.1. Physical/Link Layer Topology
9.1. Physical/Link Layer Topology
The architecture and protocols do not restrict the link layer or the physical layer in any manner.
The architecture and protocols do not restrict the link layer or the physical layer in any manner.
9.2. Temporary Access
9.2. Temporary Access
Temporary access via PPP is possible, using industry standard PPP- based authentication mechanisms. For example:
Temporary access via PPP is possible, using industry standard PPP- based authentication mechanisms. For example:
- 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.
- 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.
- The SP's AAA server returns a VPN-id to PE.
- The SP's AAA server returns a VPN-id to PE.
- The PE assigns the user to a VRF, based on that VPN-id.
- The PE assigns the user to a VRF, based on that VPN-id.
Rosen Informational [Page 19] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
Rosen Informational [Page 19] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
- 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).
- 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).
- The user gets disconnected if either authentication step is
unsuccessful.
- 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.
IPsec access to a VRF is also possible. In this case, the security association is between the end user and the SP.
In these ways, a user can access a BGP/MPLS IP VPN via the public Internet.
In these ways, a user can access a BGP/MPLS IP VPN via the public Internet.
There is no explicit support for mobility, other than what is stated above.
There is no explicit support for mobility, other than what is stated above.
9.3. Access Connectivity
9.3. Access Connectivity
Homing of a CE to two or more PEs is fully supported, whether or not the PEs are on the same SP network.
Homing of a CE to two or more PEs is fully supported, whether or not the PEs are on the same SP network.
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が2PEsに接続されるなら、両方の方向に交通を運ぶのにすべてのPE/CEリンクを使用できます。 特に、異なったイングレスPEsから特定のCEまでの交通は異なったPE/CEリンクの上のそのCEに到着するかもしれません。 これはCEとさまざまなイングレスPEsの間の背骨ネットワークルーティングによります。
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.
特定のイングレスのVRFであるなら、PEは特定の目的地に数個のルートを含んでいて、次に、これらのルートの中でそのイングレスPEからの交通は分けることができます。 これらのルートが異なったPE/CEリンクで終わると、そのイングレスPEからの交通はそれらのリンクの中で分けられるでしょう。
BGP contains a multitude of knobs that allow an SP to control the traffic sent on one PE/CE link as opposed to the other. One can also make use of the Link Bandwidth extended community [BGP-EXT-COMM] to control how traffic is distributed among multiple egress PE/CE links.
BGPはSPがもう片方と対照的に1個のPE/CEリンクに送られた交通を制御できるノブの多数を含んでいます。 また、1つは、交通が複数の出口のPE/CEリンクの中にどう広げられるかを制御するためにLink Bandwidthの使用を拡張共同体[BGP-EXT-COMM]にすることができます。
The VPN scheme is of course compatible with the use of traffic engineering techniques, Resource Reservation Protocol - Traffic Engineering (RSVP-TE) based or otherwise, in the backbone network.
VPN計画はもちろん交通エンジニアリング技法の使用と互換性があります、Resource予約プロトコル--背骨ネットワークでベースの、または、そうでない交通Engineering(RSVP-TE)。
Rosen Informational [Page 20] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[20ページ]のRFC4365適用性証明
10. Service Access
10. サービスアクセス
10.1. Internet Access
10.1. インターネットアクセス
Internet access and VPN access are possible from the same site. This is even possible over the same interface, as long as the VPN's internal addresses are distinct from the addresses of the systems that must be reached via the Internet. This requires only that Internet routes as well as VPN routes be imported into the VRF associated with that interface. This may be as simple as putting a default route to the Internet into that VRF.
インターネット・アクセスとVPNアクセスは同じサイトから可能です。 これは同じインタフェースの上で可能でさえあります、VPNの内部のアドレスがインターネットを通して達しなければならないシステムのアドレスと異なっている限り。 これは、VPNルートと同様にインターネットルートがそのインタフェースに関連しているVRFに輸入されるだけであるのを必要とします。 これはそのVRFにデフォルトルートをインターネットにつけるのと同じくらい簡単であるかもしれません。
The "route to the Internet" that is in a particular VRF need not lead directly to the Internet; it may lead to a firewall or other security device at another site of the VPN. The VPN customer can cause this to happen simply by exporting a default route from the site with the firewall. Generally, a site with a firewall will use a different virtual interface for Internet access than for VPN access, since the firewall needs to distinguish the "clean interface" from the "dirty interface".
特定のVRFにある「インターネットへのルート」は直接インターネットに通じる必要はありません。 それはVPNの別のサイトでファイアウォールか他のセキュリティ装置に通じるかもしれません。 VPN顧客は、単にファイアウォールがあるサイトからデフォルトルートを輸出することによって、これを起こらせることができます。 一般に、ファイアウォールがあるサイトはインターネット・アクセスにVPNアクセスと異なった仮想インターフェースを使用するでしょう、ファイアウォールが、「汚いインタフェース」と「清潔なインタフェース」を区別する必要があるので。
In such a configuration, the customer would export his routes to the Internet via the firewall's dirty interface, but would export the same routes to the VPN via the clean interface. Thus, all traffic from the Internet would come through the dirty interface, then through the firewall, and possibly go to another VPN site though the clean interface. This also allows any necessary Network Address Translation (NAT) functionality to be done in the firewall.
そのような構成では、顧客は、ファイアウォールの汚いインタフェースを通して彼のルートをインターネットに輸出するでしょうが、清潔なインタフェースを通して同じルートをVPNに輸出するでしょう。 したがって、インターネットからのすべての交通が、ことによるとそして、ファイアウォールを通して汚いインタフェースを通り抜けて、清潔なインタフェースですが、別のVPNサイトまで続いているでしょう。 また、これで、どんな必要なNetwork Address Translation(NAT)の機能性もファイアウォールでします。
10.2. Other Services
10.2. 他のサービス
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の中で使用中でないアドレスでそれを記述できれば。 アクセスは、firewalledするか非firewalledすることができます。 サービスにアクセスするクライアントがグローバルにユニークなIPアドレスを持たないで、ただ一つのサーバが複数のVPNsに対するサービスを提供すると、サーバに達する前にクライアントのパケットにNATを適用しなければならないでしょう。顧客サイトにおいて、または、PEルータにおけるVRF特有のNAT機能はこれができます。
Rosen Informational [Page 21] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[21ページ]のRFC4365適用性証明
11. SP Routing
11. SPルート設定
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計画から独立していて、VPNsの存在か不在で影響を受けないです。 唯一の衝撃は背骨ルーティングが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ルート自体は異なったアドレス家族としてBGPで運ばれます、「普通」のIPルートを運ぶのに使用されるアドレス家族と、異なります。 これらのルートは、PEルータからRoute ReflectorまでPEルータに渡されて、Pルータによって決して見られません。 VPNルートを運ぶRoute Reflectorsは「普通」のIPルートを運ぶRoute Reflectorsから完全に別々である場合があります。
The fact that two PE routers support a common VPN does not require those PE routers to form an IGP routing adjacency between themselves. The number of adjacencies in the backbone IGP is independent of and unrelated to the number of VPNs supported by any set of PE routers.
2つのPEルータが一般的なVPNを支持するという事実は、自分たちの間でIGPルーティング隣接番組を形成するためにそれらのPEルータを必要としません。 背骨IGPの隣接番組の数は、どんなセットのPEルータによっても支持されたVPNsの数に独立していて関係ありません。
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に参加しません。
12. Migration Impact
12. 移動衝撃
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背骨にサイトを取り付けて、ルートへの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プロトコル、[VPN-OSPF]手順を支持するPE、PE/CEプロトコルとしてのBGPとOR、およびBGP/OSPF相互作用を支持する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)に適切な測定基準を設定しなければなりません。
Rosen Informational [Page 22] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[22ページ]のRFC4365適用性証明
13. Scalability
13. スケーラビリティ
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ネットワークあたりのVPNsの数にありません、すべてのVPNsを知る必要があるSPネットワークにいいえ1、箱があるとき。 特定のVPNに関する知識はそのVPNのサイトと、そして、それらのPEsからルーティングデータを受け取るBGP Route Reflectorsに付くPEルータに限定されます。 他のシステムはVPNのために状態を全く維持しません。 もっとも、どんなRoute ReflectorもすべてのVPNsを知る必要は全くないことに注意してください。
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はあらゆるLabel Switched Path(LSP)出口ノードのために経路ドメインの中でホストルートを運ばなければなりません。 経路ドメインのあらゆるPEルータがLSP出口ノードです。 また、経路ドメインの中にあるPEルータに取り付けられたVPNsがあると、ドメインを発送しながら何らかの2番目にあるPEルータと同様に、2番目の経路ドメインに向かって導く境界ルータはLSP出口ノードになるでしょう。 したがって、PEルータの数と経路ドメインの中の境界ルータの数はドメインのIGPの中で運ぶことができるルートの数によって制限されます。 これはどんな実用的なスケーラビリティ問題も作成するように思えません。
There is no upper limit on the number of site interfaces per VPN, as state for a particular interface is maintained only at the PE router to which that interface attaches. The number of site interfaces per VPN at a given PE router is limited only by the number of interfaces that that PE router can support.
上限が全く1VPNあたりのサイトインタフェースの数にありません、特定のインタフェースへの状態がそのインタフェースが付くPEルータだけで維持されるように。 与えられた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.
1VPNあたりのルートの数はBGPで支持できるルートの数、そのVPNに付くPEsで維持できるルートの数、およびそのVPNのルートを保持するBGP Route Reflectorsで維持できないルートの数しか抑制されます。
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は同じくらい多くのVPNsを支持できますが、それはそれが扱うことができるルートの総数で抑制されます。 与えられたPEが扱わなければならないルートの数はまたそれが扱わなければならない付いて、そのような各VPN、および数の「非VPN」インターネットのルートの数が発送する(もしあれば)VPNsの特定のセットに依存します。
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,
SPは、これらの限界にしばしば達するというわけではないのを保証するのに重要な計画に従事する必要があるかもしれません。 これらの限界に達しているなら、より大きい容量についてPEを1つに取り替えるか、またはアクセスリンクがCEsからPEsまで導く方法を再編成するのが必要であるかもしれません。
Rosen Informational [Page 23] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[23ページ]のRFC4365適用性証明
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.
集中するほうがよいために、アクセスのセットは同じVPNにあるサイトからリンクされます。 異なったPEにサイトをRehomingする場合、実際の返電することはかかわらないかもしれません。 アクセス技術が切り換えられるなら、これは食糧を供給することの問題ですが、まだ重要な仕事であるかもしれません。 休止時間を持つのが「再-家へ帰」りを実行する間、必要であるなら、また、顧客に影響を与えます。 また、「実際には」Rehomingができます、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ルートを運ぶいろいろなINDEPENDENT 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に報告された変化が他のPEsに伝播されるとき。 報告された変化の率を制御する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ルータで支持できるVPNsの数における別の規制はPEルータが支持できるルーティング例の数に基づいています。 PE/CEルーティングが静的であるか、またはBGPによって行われるなら、PE装置のルーティング・プロトコル例の数はPE装置によって支持されたCEsの数に依存しません。 BGPの場合では、ただ一つのBGPプロトコル例はBGPを使用することでルーティング情報を交換するすべてのCEsを支持できます。 RIPかOSPFを通してPE/CEルータをするなら、PEは1VRFあたり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シナリオは、VPNsの1セットのためのルートを保持するためにBGP「境界ルータ」を必要とします。 2SPsがVPNsの少ない数を分担するなら、彼らの間のただ一つの境界ルータは適切な容量を提供します。 共有されたVPNsの数が増加するのに従って、追加境界ルータが、ルートの増加する数を扱うのに必要であるかもしれません。 一方、どんなただ一つの境界ルータもすべてのVPNsからすべてのルートを扱うというわけではないでしょう、したがって、より多くの境界ルータを加えることによって、VPNsの数の増加をいつも支持できます。
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シナリオは境界ルータがVPNルート(その結果、その寸法におけるスケーラビリティを改良する)を含む必要性を排除しますが、それぞれそれを必要とする費用では、ASは他のものにPEsにルートを持っています。
Rosen Informational [Page 24] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[24ページ]のRFC4365適用性証明
(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シナリオはよく比例しません。)
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は単一のサブインタフェースしか背骨に持ってはいけません、そして、1つのサイトのCEsは別のものでCEsの存在を知る必要さえありません、そして、1つのサイトの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が、どのサイトがどのVPNsに属すかをただ潜在的に言わなければならないように。 システムが拡大するのに従った計画がどのPEsが家へ帰るはずであるかを決定するのにどのように必要であっても、どのVPNs、およびどのBGP RRsが、どのVPNsが情報を発送するかを取るはずですか?
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ルータは1VPNあたりの状態を全く維持しません。 それらに関する唯一の要件は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はPにマルチキャストグループ単位ですべてのVPNsの上へまとめられたルータを述べますマルチキャスト計画が、必要である。 他のものは、全く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のリソース仕切りを通してこの問題を緩和できます、どんなVPNもPEルータに使用することが許可されているリソース(例えば、CPUとメモリ)の量を制限するために。 また、レート限界はCEからPEに送られたルーティング交通に適用されるかもしれません。
Rosen Informational [Page 25] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[25ページ]のRFC4365適用性証明
Alternately, when this problem is detected, the CE-to-PE interface may be shut down.
この問題が検出されるとき、交互に、CEからPEへのインタフェースは止められるかもしれません。
14. QoS, SLA
14. QoS、SLA
The provision of appropriate QoS capabilities may require any combination of the following:
適切なQoS能力の支給は以下の組み合わせを必要とするかもしれません:
- QoS in the access network.
- アクセスネットワークにおけるQoS。
- Admission control (policing) by the PE router on the ingress
access links.
- イングレスアクセスでのPEルータによる入場コントロール(取り締まる)はリンクされます。
- Traffic conditioning (shaping) by the PE router on the ingress
access links.
- イングレスアクセスでのPEルータによる交通調節(形成)はリンクされます。
- Traffic engineering in the backbone.
- 背骨の交通工学。
- Intserv/diffserv classification by the PE, for traffic arriving
from the CE. Once the PE classifies the user packets, this
classification needs to be preserved in the encapsulation (MPLS
or IP) used to send the packet across the backbone.
- CEから到着する交通へのPEによるIntserv/diffserv分類。 PEがいったんユーザパケットを分類すると、この分類は、背骨の向こう側にパケットを送るのに使用されるカプセル化(MPLSかIP)で保存される必要があります。
- Differentiated Services Codepoint (DSCP) mapping.
- Services Codepoint(DSCP)マッピングを微分しました。
- DSCP transparency.
- DSCP透明。
- Random Early Discard in the backbone.
- 背骨の無作為のEarly Discard。
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サポートはRFC3270[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の交通への2PEsの間の保証された帯域幅。 各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
BGP/MPLS IP VPNsは「ホースモデル」とQoSの「パイプモデル」の両方を支持できます。 「パイプモデル」では、特定のサービスの質(例えば、帯域幅の保証額)は与えられた組のCEsの間を移動するパケットのすべてかいくつかに適用されるでしょう。 「ホースモデル」、特定のサービスの質、(例えば、保証されたa
Rosen Informational [Page 26] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[26ページ]のRFC4365適用性証明
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.
帯域幅の量) CE、または、特定のCEからのすべての交通に適用されるでしょう、交通がどの他のCEから行くか、または来るかの如何にかかわらず。 BGP/MPLS IP VPNsが通常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]で指定された要件の多くが、Network Monitoring System(NMS)がSLAの文脈の中で定義されたインディケータの測定でSPと様々な顧客の間のSLAモニターと検証を支持するはずであるのを規定します。 BGP/MPLS IP VPNsがBGP/MPLS IP VPNs[L3VPN-MIB]のために設計されたManagement Information基地(MIB)のモジュールの組み合わせを使うのにおいて使用されていて、他の標準のMIBモジュールがそのようであるときに、これらのインディケータ(すなわち、カウンタ)の測定を達成できる、-、MIB、[-、MIB、] これらのMIBモジュールを支持する装置はインディケータと敷居交差点警戒を使用することでリアルタイムの性能測定に基づくSLAについて計算できます。 装置で、これらの敷居はSNMPなどの管理インタフェースを通して構成可能になる場合があります。
15. Management
15. 管理
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 Requirementsドキュメント[L3VPN-REQS]は、用語「プロバイダーの食糧を供給されたVPN」がサービスプロバイダーがVPNの管理と食糧を供給することに参加するVPNsを示すのを規定します。 これらの必要条件を満たすためにRFC BGP/MPLS IP VPNsに食糧を供給して、対処できます。 以下の小区分はBGP/MPLS IP VPNsを支持する装置がどうこれらの要件を満たすことができるかを概説するでしょう。
15.1. Management by the Provider
15.1. プロバイダーによる管理
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-特殊情報を管理します。 MIBが他の標準のMIBモジュールと組み合わせてBGP/MPLS IP VPNs[L3VPN-MIB]のために設計したされた使用がそのようであったならこれがそうすることができる、-、MIB、[-、MIB、]、他のMPLS MIBモジュール[LSRMIB]、[LDPMIB]、[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 VPNsを支持する装置が必要に応じてL3VPN要件ドキュメントでITU-T電気通信管理課Network Model「FCAPS」の機能性を支持するでしょう。 これらはFault、Configuration、Accounting、Provisioning、およびSecurityを含んでいます。
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では、SPはCE装置を管理する必要はありません。 しかしながら、SPがそうするのが、必要であるなら、SPは主要なサイトからCE装置を管理するかもしれません、主要なサイトへのルートをCEのVPNに輸出して、主要なサイトが管理されたCE装置へのルートが輸入されたVPNにあれば。
Rosen Informational [Page 27] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[27ページ]のRFC4365適用性証明
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.
主要なサイトが数個のVPNsからCE装置を管理しているなら、それらのCE装置には、互いにユニークなアドレスがなければなりません。 これが、異なったVPNsからの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モジュールや能力もあるのを必要としません。
15.2. Management by the Customer
15.2. 顧客による管理
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装置のルーティング同輩であり、確認できますなど。
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までのネットワークマネージメント交通を防ぐ)レートであるかもしれません。
16. Acknowledgements
16. 承認
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.
このドキュメントを準備するのにおいてジェレミーDe Clercq、Luyuan Fang、デーヴMcDysan、Ananth Nagarajan、ヤコフRekhter、彼らのコメントのためのMuneyoshi鈴木、批評、およびお力添えをありがとうございます。 また、管理でのセクションによる彼のご協力のためのトーマス・ナドーと、そして、セクションがQoSにある彼のご協力のためのフランソアLeFaucheurと、そして、彼のドキュメントのレビューのためのロスCallonをありがとうございます。
Rosen Informational [Page 28] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[28ページ]のRFC4365適用性証明
17. Normative References
17. 引用規格
[BGP-EXT-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Extended Communities Attribute", RFC 4360,
February 2006.
[BGP-EXT-COMM] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。
[BGP-MPLS-IP-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February
2006.
[BGP-MPLS IP VPN] ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[L3VPN-FRMWRK] Callon, R. and M. Suzuki, "A Framework for Layer
3 Provider-Provisioned Virtual Private Networks
(PPVPNs)", RFC 4110, July 2005.
[L3VPN-FRMWRK] CallonとR.とM.鈴木、「層3のプロバイダーで食糧を供給された仮想私設網(PPVPNs)のための枠組み」、RFC4110、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)に食糧を供給しました」、RFC4031、2005年4月。
[L2VPN-SEC-FRMWRK] Fang, L., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)",
RFC 4111, July 2005.
[L2VPN SEC FRMWRK] 牙、L.、「プロバイダーのためのセキュリティフレームワークは仮想私設網(PPVPNs)に食糧を供給した」RFC4111、2005年7月。
18. Informative References
18. 有益な参照
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault,
"OSPF as the PE/CE Protocol in BGP/MPLS VPNs",
Work in Progress, February 2004.
[VPN-OSPF]ローゼン、E.、P.、およびP.Pillay-Esnault、「BGP/MPLS VPNsのPE/CeプロトコルとしてのOSPF」というPsenakは進行中(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] 「BGP/MPLS IP VPNsで輪にするのを防ぐのにLSAオプションビットを使用し」て、ローゼン、E.、Psenak、P.、およびP.Pillay-Esnaultは進行中(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]ローゼン、E.、J.、Paridaens、O.、T'Joens、Y.、およびC.Sargor、「BGP/MPLS IP VPNsにおけるPE-PE IPsec Tunnelsの使用のための構造」というDe Clercqは進行中(2004年3月)で働いています。
[BGP-MPLS-MCAST-VPN] Rosen, E., Cai, Y., and IJ. Wijsnands,
"Multicast in MPLS/BGP VPNs", Work in Progress,
May 2004.
[BGP-MPLS-MCAST-VPN] ローゼン、E.、Cai、Y.、およびIJ。 「MPLS/BGP VPNsのマルチキャスト」というWijsnandsは進歩、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] R.、Rekhter、Y.、Raszuk、R.、ローゼン、E.、およびD.タッパン、「層3のVPNsのためのCeからCeへのメンバー検証」というBonicaは進行中(2003年9月)で働いています。
Rosen Informational [Page 29] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[29ページ]のRFC4365適用性証明
[FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan,
"Multiprotocol Label Switching (MPLS) Forwarding
Equivalence Class To Next Hop Label Forwarding
Entry (FEC-To-NHLFE) Management Information Base
(MIB)", RFC 3814, June 2004.
[FTNMIB] ナドー、T.、Srinivasan、C.、およびA.Viswanathan、「次に跳ぶために同値類を進めるMultiprotocolラベル切り換え(MPLS)が推進エントリー(FECから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.
J.、Paridaens、O.、Krywaniuk、A.、C.ワング、「IPsecを使用することでプロバイダーのための構造はCeベースの仮想私設網に食糧を供給した」という[IPSEC-VPN]De Clercqは進行中(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.、シェストランド、H.、およびJ.Luciani、「Multiprotocolラベル切り換え(MPLS)のための管理オブジェクトの定義、ラベル分配は(自由民主党)について議定書の中で述べます」、RFC3815、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.ナドー、「Multiprotocolはラベル切り換えルータ(LSR)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3813、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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[L3VPN-MIB] Nadeau, T. and H. Van Der Linde, "MPLS/BGP
Virtual Private Network Management Information
Base Using SMIv2", Work in Progress, August
2004.
[L3VPN-MIB] ナドー、T.、およびH.はDerリンデをバンに積みます、「MPLS/BGPの仮想の個人的なネットワークマネージメントは2004年8月にSMIv2"、進行中の仕事を使用し」て。
[IF-MIB] McCloghrie, K. and F. Kastenholz, "The
Interfaces Group MIB", RFC 2863, June 2000.
[-、MIB、]、McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、6月2000
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de
Groot, G., and E. Lear, "Address Allocation for
Private Internets", BCP 5, RFC 1918, February
1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(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.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
Rosen Informational [Page 30] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[30ページ]のRFC4365適用性証明
[VR-VPN] Knight, P., Ould-Brahim, H., and B. Gleeson,
"Network Based IP VPN Architecture using Virtual
Routers", Work in Progress, April 2004.
[VR-VPN]ナイト、P.、オールド-Brahim(H.、およびB.グリーソン)は「仮想のルータを使用して、ベースのIP VPN構造をネットワークでつなぎます」、処理中の作業、2004年4月。
Author's Address
作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Rosen Informational [Page 31] RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のためのローゼン情報[31ページ]のRFC4365適用性証明
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosen Informational [Page 32]
ローゼンInformationalです。[32ページ]
一覧
スポンサーリンク
