[要約] RFC 4364は、BGP/MPLS IP仮想プライベートネットワーク（VPN）の設計と実装に関するガイドラインです。その目的は、異なるネットワーク間でセキュアな通信を確保するためのVPNソリューションを提供することです。
Network Working Group E. Rosen
Request for Comments: 4364 Cisco Systems, Inc.
Obsoletes: 2547 Y. Rekhter
Category: Standards Track Juniper Networks, Inc.
February 2006
BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP仮想プライベートネットワーク（VPNS）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.
このドキュメントでは、サービスプロバイダーがIPバックボーンを使用して、顧客にIP仮想プライベートネットワーク（VPN）を提供できる方法について説明します。この方法では、「ピアモデル」を使用します。この方法では、顧客のエッジルーター（CEルーター）がルートをサービスプロバイダーのエッジルーター（PEルーター）に送信します。顧客のルーティングアルゴリズムには「オーバーレイ」が表示されず、さまざまなサイトのCEルーターが互いに覗き込んでいません。データパケットはバックボーンにトンネル化されているため、コアルーターはVPNルートを知る必要がありません。
This document obsoletes RFC 2547.
このドキュメントは、RFC 2547を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Virtual Private Networks ...................................4
1.2. Customer Edge and Provider Edge ............................5
1.3. VPNs with Overlapping Address Spaces .......................6
1.4. VPNs with Different Routes to the Same System ..............7
1.5. SP Backbone Routers ........................................7
1.6. Security ...................................................8
2. Sites and CEs ...................................................8
3. VRFs: Multiple Forwarding Tables in PEs .........................9
3.1. VRFs and Attachment Circuits ...............................9
3.2. Associating IP Packets with VRFs ..........................10
3.3. Populating the VRFs .......................................11
4. VPN Route Distribution via BGP .................................12
4.1. The VPN-IPv4 Address Family ...............................13
4.2. Encoding of Route Distinguishers ..........................14
4.3. Controlling Route Distribution ............................15
4.3.1. The Route Target Attribute .........................15
4.3.2. Route Distribution Among PEs by BGP ................17
4.3.3. Use of Route Reflectors ............................20
4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
4.3.5. Building VPNs Using Route Targets ..................23
4.3.6. Route Distribution Among VRFs in a Single PE .......23
5. Forwarding .....................................................23
6. Maintaining Proper Isolation of VPNs ...........................26
7. How PEs Learn Routes from CEs ..................................27
8. How CEs Learn Routes from PEs ..................................30
9. Carriers' Carriers .............................................30
10. Multi-AS Backbones ............................................32
11. Accessing the Internet from a VPN .............................34
12. Management VPNs ...............................................36
13. Security Considerations .......................................37
13.1. Data Plane ...............................................37
13.2. Control Plane ............................................39
13.3. Security of P and PE Devices .............................39
14. Quality of Service ............................................39
15. Scalability ...................................................40
16. IANA Considerations ...........................................40
17. Acknowledgements ..............................................41
18. Contributors ..................................................41
19. Normative References ..........................................44
20. Informative References ........................................45
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers). Border Gateway Protocol (BGP) [BGP, BGP-MP] is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way that ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no "overlay" visible to the VPN's routing algorithm. The term "IP" in "IP VPN" is used to indicate that the PE receives IP datagrams from the CE, examines their IP headers, and routes them accordingly.
このドキュメントでは、サービスプロバイダーがIPバックボーンを使用して、顧客にIP仮想プライベートネットワーク（VPN）を提供できる方法について説明します。この方法では、「ピアモデル」を使用します。この方法では、顧客のエッジルーター（CEルーター）がルートをサービスプロバイダーのエッジルーター（PEルーター）に送信します。ボーダーゲートウェイプロトコル（BGP）[BGP、BGP-MP]は、サービスプロバイダーによって使用され、そのVPNに接続されているPEルーター間で特定のVPNのルートを交換します。これは、2つのVPNにオーバーラップアドレススペースがある場合でも、異なるVPNからのルートが明確で個別のままであることを保証する方法で行われます。PEルーターは、特定のVPNのCEルーターに分布し、そのVPNの他のCEルーターからのルート。CEルーターは互いに覗き込んでいないため、VPNのルーティングアルゴリズムに「オーバーレイ」が表示されません。「IP VPN」の「IP」という用語は、PEがCEからIPデータグラムを受信し、IPヘッダーを調べ、それに応じてルーティングすることを示すために使用されます。
Each route within a VPN is assigned a Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label or with an IP or Generic Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that it gets tunneled across the backbone to the proper PE router. Thus, the backbone core routers do not need to know the VPN routes.
VPN内の各ルートには、マルチプロトコルラベルスイッチング（MPLS）[MPLS-ARCH、MPLS-BGP、MPLS-ENCAPS]ラベルが割り当てられます。BGPがVPNルートを配布する場合、そのルートのMPLSラベルも配布します。顧客データパケットがサービスプロバイダーのバックボーンを越えて移動する前に、顧客のVPNで、パケットの宛先アドレスに最適なルートに対応するMPLSラベルとカプセル化されます。このMPLSパケットは、さらにカプセル化されています（たとえば、別のMPLSラベルまたはIPまたは一般的なルーティングカプセル化（GRE）トンネルヘッダー[MPLS-in-IP-GRE]）。したがって、バックボーンコアルーターはVPNルートを知る必要はありません。
The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises that need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider that uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value.
この方法の主な目標は、クライアントが契約関係を維持するサービスプロバイダーまたはサービスプロバイダーからIPバックボーンサービスを取得するケースをサポートすることです。クライアントは企業、エクストラネットを必要とする企業のグループ、インターネットサービスプロバイダー、アプリケーションサービスプロバイダー、この同じ方法を使用して独自のクライアントにVPNを提供する別のVPNサービスプロバイダーなどです。クライアントがバックボーンサービスを使用するのは非常にシンプルです。また、サービスプロバイダーにとって非常にスケーラブルで柔軟であり、サービスプロバイダーが価値を追加できるようにします。
Consider a set of "sites" that are attached to a common network that we call "the backbone". Now apply some policy to create a number of subsets of that set, and impose the following rule: two sites may have IP interconnectivity over that backbone only if at least one of these subsets contains them both.
「バックボーン」と呼ばれる共通のネットワークに接続されている「サイト」のセットを考えてみましょう。次に、いくつかのポリシーを適用して、そのセットの多くのサブセットを作成し、次のルールを課します。2つのサイトは、これらのサブセットの少なくとも1つに両方が含まれている場合にのみ、そのバックボーンに対してIP相互接続性を持つ場合があります。
These subsets are Virtual Private Networks (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN that contains them both. Two sites that have no VPN in common have no connectivity over that backbone.
これらのサブセットは、仮想プライベートネットワーク（VPN）です。2つのサイトには、両方を含むVPNがある場合にのみ、一般的なバックボーン上のIP接続があります。VPNが共通していない2つのサイトには、そのバックボーン上の接続性がありません。
If all the sites in a VPN are owned by the same enterprise, the VPN may be thought of as a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN may be thought of as an "extranet". A site can be in more than one VPN; e.g., in an intranet and in several extranets. In general, when we use the term "VPN" we will not be distinguishing between intranets and extranets.
VPN内のすべてのサイトが同じ企業が所有している場合、VPNは企業の「イントラネット」と考えられる場合があります。VPN内のさまざまなサイトが異なる企業が所有している場合、VPNは「エクストラネット」と考えられる場合があります。サイトは複数のVPNである可能性があります。たとえば、イントラネットおよび複数のエクストラネットで。一般に、「VPN」という用語を使用する場合、イントラネットとエクストラネットを区別しません。
We refer to the owners of the sites as the "customers". We refer to the owners/operators of the backbone as the "Service Providers" (SPs). The customers obtain "VPN service" from the SPs.
サイトの所有者を「顧客」と呼びます。バックボーンの所有者/オペレーターを「サービスプロバイダー」（SPS）と呼びます。顧客はSPSから「VPNサービス」を取得します。
A customer may be a single enterprise, a set of enterprises, an Internet Service Provider, an Application Service Provider, another SP that offers the same kind of VPN service to its own customers, etc.
顧客は、単一の企業、企業のセット、インターネットサービスプロバイダー、アプリケーションサービスプロバイダー、独自の顧客に同じ種類のVPNサービスを提供する別のSPなどです。
The policies that determine whether a particular collection of sites is a VPN are the policies of the customers. Some customers will want the implementation of these policies to be entirely the responsibility of the SP. Other customers may want to share with the SP the responsibility for implementing these policies. This document specifies mechanisms that can be used to implement these policies. The mechanisms we describe are general enough to allow these policies to be implemented either by the SP alone or by a VPN customer together with the SP. Most of the discussion is focused on the former case, however.
サイトの特定のコレクションがVPNであるかどうかを決定するポリシーは、顧客のポリシーです。一部の顧客は、これらのポリシーの実装が完全にSPの責任であることを望むでしょう。他の顧客は、これらのポリシーを実装する責任をSPと共有したい場合があります。このドキュメントは、これらのポリシーを実装するために使用できるメカニズムを指定します。私たちが説明するメカニズムは、これらのポリシーをSPのみまたはSPと一緒にVPN顧客によって実装できるようにするのに十分な一般的です。ただし、議論のほとんどは前者のケースに焦点を当てています。
The mechanisms discussed in this document allow the implementation of a wide range of policies. For example, within a given VPN, one can allow every site to have a direct route to every other site ("full mesh"). Alternatively, one can force traffic between certain pairs of sites to be routed via a third site. This can be useful, e.g., if it is desired that traffic between a pair of sites be passed through a firewall, and the firewall is located at the third site.
このドキュメントで説明されているメカニズムにより、幅広いポリシーの実装が可能になります。たとえば、特定のVPN内では、すべてのサイトが他のすべてのサイト（「フルメッシュ」）への直接ルートを持つことができます。または、特定のサイトのペア間のトラフィックを3番目のサイトを介してルーティングするように強制することができます。これは、たとえば、一対のサイト間のトラフィックをファイアウォールに渡し、ファイアウォールが3番目のサイトにあることが望ましい場合に役立ちます。
In this document, we restrict our discussion to the case in which the customer is explicitly purchasing VPN service from an SP, or from a set of SPs that have agreed to cooperate to provide the VPN service. That is, the customer is not merely purchasing internet access from an SP, and the VPN traffic does not pass through a random collection of interconnected SP networks.
このドキュメントでは、顧客がSPからVPNサービスを明示的に購入している場合、またはVPNサービスの提供に協力することに同意したSPSのセットから議論を制限します。つまり、顧客は単にSPからインターネットアクセスを購入するだけでなく、VPNトラフィックは相互接続されたSPネットワークのランダムコレクションを通過しません。
We also restrict our discussion to the case in which the backbone provides an IP service to the customer, rather than, e.g., a layer 2 service such as Frame Relay, Asynchronous Transfer Mode (ATM), ethernet, High Level Data Link Control (HDLC), or Point-to-Point Protocol (PPP). The customer may attach to the backbone via one of these (or other) layer 2 services, but the layer 2 service is terminated at the "edge" of the backbone, where the customer's IP datagrams are removed from any layer 2 encapsulation.
また、バックボーンがフレームリレー、非同期転送モード（ATM）、イーサネット、高レベルデータリンクコントロールなどのレイヤー2サービスではなく、バックボーンが顧客にIPサービスを提供するケースにも制限します。）、またはポイントツーポイントプロトコル（PPP）。顧客は、これらの（または他の）レイヤー2サービスのいずれかを介してバックボーンに接続できますが、レイヤー2サービスは、顧客のIPデータグラムがレイヤー2カプセル化から削除されるバックボーンの「エッジ」で終了します。
In the rest of this introduction, we specify some properties that VPNs should have. The remainder of this document specifies a set of mechanisms that can be deployed to provide a VPN model that has all these properties. This section also introduces some of the technical terminology used in the remainder of the document.
この紹介の残りの部分では、VPNが持つべきいくつかのプロパティを指定します。このドキュメントの残りの部分は、これらすべてのプロパティを備えたVPNモデルを提供するために展開できる一連のメカニズムを指定します。このセクションでは、文書の残りの部分で使用される技術用語の一部も紹介します。
Routers can be attached to each other, or to end systems, in a variety of different ways: PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2 Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use the term "attachment circuit" to refer generally to some such means of attaching to a router. An attachment circuit may be the sort of connection that is usually thought of as a "data link", or it may be a tunnel of some sort; what matters is that it be possible for two devices to be network layer peers over the attachment circuit.
ルーターは、PPP接続、ATM仮想回路（VC）、フレームリレーVCS、イーサネットインターフェイス、イーサネットインターフェイス上の仮想ローカルエリアネットワーク（VLAN）、GREタンネルなど、さまざまな方法で、互いに互いに接続できます。、レイヤー2トンネリングプロトコル（L2TP）トンネル、IPSECトンネルなど。「アタッチメント回路」という用語を使用して、一般にルーターに付着する手段を参照します。アタッチメント回路は、通常は「データリンク」と考えられるような接続のようなものであるか、ある種のトンネルである可能性があります。重要なのは、2つのデバイスがアタッチメント回路上のネットワークレイヤーピアになる可能性があることです。
Each VPN site must contain one or more Customer Edge (CE) devices. Each CE device is attached, via some sort of attachment circuit, to one or more Provider Edge (PE) routers.
各VPNサイトには、1つ以上の顧客エッジ（CE）デバイスが含まれている必要があります。各CEデバイスは、ある種のアタッチメント回路を介して、1つ以上のプロバイダーエッジ（PE）ルーターに接続されています。
Routers in the SP's network that do not attach to CE devices are known as "P routers".
CEデバイスに接続しないSPのネットワーク内のルーターは、「Pルーター」として知られています。
CE devices can be hosts or routers. In a typical case, a site contains one or more routers, some of which are attached to PE routers. The site routers that attach to the PE routers would then be the CE devices, or "CE routers". However, there is nothing to prevent a non-routing host from attaching directly to a PE router, in which case the host would be a CE device.
CEデバイスはホストまたはルーターにすることができます。典型的なケースでは、サイトには1つ以上のルーターが含まれており、その一部はPEルーターに取り付けられています。PEルーターに接続するサイトルーターは、CEデバイス、または「CEルーター」になります。ただし、非ルーティングホストがPEルーターに直接接続するのを防ぐものは何もありません。その場合、ホストはCEデバイスになります。
Sometimes, what is physically attached to a PE router is a layer 2 switch. In this case, we do NOT say that the layer 2 switch is a CE device. Rather, the CE devices are the hosts and routers that communicate with the PE router through the layer 2 switch; the layer 2 infrastructure is transparent. If the layer 2 infrastructure provides a multipoint service, then multiple CE devices can be attached to the PE router over the same attachment circuit.
時々、PEルーターに物理的に取り付けられているのは、レイヤー2スイッチです。この場合、レイヤー2スイッチがCEデバイスであるとは言いません。むしろ、CEデバイスは、レイヤー2スイッチを介してPEルーターと通信するホストとルーターです。レイヤー2インフラストラクチャは透明です。レイヤー2インフラストラクチャがマルチポイントサービスを提供する場合、複数のCEデバイスを同じアタッチメント回路でPEルーターに接続できます。
CE devices are logically part of a customer's VPN. PE and P routers are logically part of the SP's network.
CEデバイスは、論理的に顧客のVPNの一部です。PEおよびPルーターは、論理的にSPのネットワークの一部です。
The attachment circuit over which a packet travels when going from CE to PE is known as that packet's "ingress attachment circuit", and the PE as the packet's "ingress PE". The attachment circuit over which a packet travels when going from PE to CE is known as that packet's "egress attachment circuit", and the PE as the packet's "egress PE".
パケットがCEからPEに移動するときに移動するアタッチメント回路は、そのパケットの「イングレスアタッチメント回路」と、パケットの「Ingress PE」としてPEとして知られています。PEからCEに移動するときにパケットが移動するアタッチメント回路は、そのパケットの「出口アタッチメント回路」と、パケットの「Egress PE」としてPEとして知られています。
We will say that a PE router is attached to a particular VPN if it is attached to a CE device that is in a site of that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device that is in that site.
そのVPNのサイトにあるCEデバイスに接続されている場合、PEルーターは特定のVPNに接続されていると言います。同様に、PEルーターがそのサイトにあるCEデバイスに接続されている場合、PEルーターが特定のサイトに接続されていると言います。
When the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but it is NOT a routing peer of CE routers at other sites. Routers at different sites do not directly exchange routing information with each other; in fact, they do not even need to know of each other at all. As a consequence, the customer has no backbone or "virtual backbone" to manage, and does not have to deal with any inter-site routing issues. In other words, in the scheme described in this document, a VPN is NOT an "overlay" on top of the SP's network.
CEデバイスがルーターである場合、それは接続されているPEのルーティングピアですが、他のサイトのCEルーターのルーティングピアではありません。さまざまなサイトのルーターは、ルーティング情報を互いに直接交換しません。実際、彼らはお互いをまったく知る必要さえありません。結果として、顧客は管理するバックボーンまたは「仮想バックボーン」を持っていないため、サイト間のルーティングの問題に対処する必要はありません。言い換えれば、このドキュメントで説明されているスキームでは、VPNはSPのネットワーク上の「オーバーレイ」ではありません。
With respect to the management of the edge devices, clear administrative boundaries are maintained between the SP and its customers. Customers are not required to access the PE or P routers for management purposes, nor is the SP required to access the CE devices for management purposes.
Edgeデバイスの管理に関しては、SPとその顧客の間で明確な管理境界が維持されます。顧客は、管理目的でPEまたはPルーターにアクセスする必要はなく、SPが管理目的でCEデバイスにアクセスする必要もありません。
If two VPNs have no sites in common, then they may have overlapping address spaces. That is, a given address might be used in VPN V1 as the address of system S1, but in VPN V2 as the address of a completely different system S2. This is a common situation when the VPNs each use an RFC 1918 private address space. Of course, within each VPN, each address must be unambiguous.
2つのVPNに共通のサイトがない場合、アドレススペースが重複する可能性があります。つまり、特定のアドレスは、VPN V1でシステムS1のアドレスとして使用される場合がありますが、VPN V2ではまったく異なるシステムS2のアドレスとして使用されます。これは、VPNSがそれぞれRFC 1918プライベートアドレススペースを使用する場合の一般的な状況です。もちろん、各VPN内で、各アドレスは明確でなければなりません。
Even two VPNs that do have sites in common may have overlapping address spaces, as long as there is no need for any communication between systems with such addresses and systems in the common sites.
共通のサイトを持っている2つのVPNでさえ、一般的なサイトにそのようなアドレスとシステムを持つシステム間の通信が必要ない限り、アドレススペースが重複する可能性があります。
Although a site may be in multiple VPNs, it is not necessarily the case that the route to a given system at that site should be the same in all the VPNs. Suppose, for example, we have an intranet consisting of sites A, B, and C, and an extranet consisting of A, B, C, and the "foreign" site D. Suppose that at site A there is a server, and we want clients from B, C, or D to be able to use that server. Suppose also that at site B there is a firewall. We want all the traffic from site D to the server to pass through the firewall, so that traffic from the extranet can be access controlled. However, we don't want traffic from C to pass through the firewall on the way to the server, since this is intranet traffic.
サイトは複数のVPNにある可能性がありますが、そのサイトの特定のシステムへのルートがすべてのVPNで同じである必要があるとは限りません。たとえば、サイトa、b、cで構成されるイントラネットと、a、b、c、および「外部」サイトDで構成されるエクストラネットがあるとします。B、C、またはDのクライアントにそのサーバーを使用できるようにします。また、サイトBにファイアウォールがあると仮定します。サイトDからサーバーへのすべてのトラフィックがファイアウォールを通過するようにして、エクストラネットからのトラフィックを制御できるようにしたいと考えています。ただし、これはイントラネットトラフィックであるため、サーバーに向かう途中のファイアウォールをCからトラフィックを通過させたくありません。
It is possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A.
サーバーに2つのルートをセットアップすることが可能です。サイトbとcで使用される1つのルートは、トラフィックをサイトAに直接移動します。サイトDで使用される2番目のルートは、代わりにトラフィックをサイトBのファイアウォールに連れて行きます。サイトBから来るトラフィックになり、サイトAへのルートに従うこと
The SP's backbone consists of the PE routers, as well as other routers ("P routers") that do not attach to CE devices.
SPのバックボーンは、CEデバイスに接続しない他のルーター（「Pルーター」）だけでなく、PEルーターと他のルーターで構成されています。
If every router in an SP's backbone had to maintain routing information for all the VPNs supported by the SP, there would be severe scalability problems; the number of sites that could be supported would be limited by the amount of routing information that could be held in a single router. It is important therefore that the routing information about a particular VPN only needs to be present in the PE routers that attach to that VPN. In particular, the P routers do not need to have ANY per-VPN routing information whatsoever. (This condition may need to be relaxed somewhat when multicast routing is considered. This is not considered further in this paper, but is examined in [VPN-MCAST].)
SPのバックボーン内のすべてのルーターが、SPによってサポートされているすべてのVPNのルーティング情報を維持する必要がある場合、深刻なスケーラビリティの問題が発生します。サポートできるサイトの数は、単一のルーターに保持できるルーティング情報の量によって制限されます。したがって、特定のVPNに関するルーティング情報は、そのVPNに付着するPEルーターにのみ存在する必要があることが重要です。特に、Pルーターには、VPNごとのルーティング情報がまったく必要ではありません。（マルチキャストルーティングを考慮した場合、この状態は多少緩和する必要がある場合があります。これはこのホワイトペーパーではこれ以上考慮されていませんが、[VPN-Mcast]で検査されています。）
So just as the VPN owners do not have a backbone or "virtual backbone" to administer, the SPs themselves do not have a separate backbone or "virtual backbone" to administer for each VPN. Site-to-site routing in the backbone is optimal (within the constraints of the policies used to form the VPNs) and is not constrained in any way by an artificial "virtual topology" of tunnels.
したがって、VPNの所有者が管理するバックボーンまたは「仮想バックボーン」を持っていないように、SPS自体には、各VPNに対して管理する別のバックボーンまたは「仮想バックボーン」を持っていません。バックボーンのサイト間ルーティングは最適です（VPNを形成するために使用されるポリシーの制約内）、トンネルの人工的な「仮想トポロジ」によって決して制約されていません。
Section 10 discusses some of the special issues that arise when the backbone spans several Service Providers.
セクション10では、バックボーンがいくつかのサービスプロバイダーにまたがるときに発生する特別な問題のいくつかについて説明します。
VPNs of the sort being discussed here, even without making use of cryptographic security measures, are intended to provide a level of security equivalent to that obtainable when a layer 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of different VPNs, it is not possible for systems in one VPN to gain access to systems in another VPN. Of course, the methods described herein do not by themselves encrypt the data for privacy, nor do they provide a way to determine whether data has been tampered with en route. If this is desired, cryptographic measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].) Security is discussed in more detail in Section 13.
ここで説明する種類のVPNは、暗号化セキュリティ対策を使用しなくても、レイヤー2バックボーン（フレームリレーなど）が使用される場合に得られるセキュリティのレベルを提供することを目的としています。つまり、異なるVPNの誤解や意図的な相互接続がない場合、あるVPNのシステムが別のVPNのシステムにアクセスすることは不可能です。もちろん、本明細書に記載されている方法は、それ自体でプライバシーのためにデータを暗号化するわけではなく、データが途中で改ざんされているかどうかを判断する方法も提供しません。これが必要な場合は、さらに暗号化測定を適用する必要があります。（たとえば、[MPLS/BGP-IPSEC]を参照してください。）セキュリティについては、セクション13で詳しく説明します。
From the perspective of a particular backbone network, a set of IP systems may be regarded as a "site" if those systems have mutual IP interconnectivity that doesn't require use of the backbone. In general, a site will consist of a set of systems that are in geographic proximity. However, this is not universally true. If two geographic locations are connected via a leased line, over which Open Shortest Path First (OSPF) protocol [OSPFv2] is running, and if that line is the preferred way of communicating between the two locations, then the two locations can be regarded as a single site, even if each location has its own CE router. (This notion of "site" is topological, rather than geographical. If the leased line goes down, or otherwise ceases to be the preferred route, but the two geographic locations can continue to communicate by using the VPN backbone, then one site has become two.)
特定のバックボーンネットワークの観点から見ると、バックボーンの使用を必要としない相互のIP相互接続性がある場合、一連のIPシステムが「サイト」と見なされる場合があります。一般に、サイトは地理的に近接している一連のシステムで構成されます。ただし、これは普遍的に真実ではありません。リースされたラインを介して2つの地理的位置が接続されている場合、最初に最短パス（OSPF）プロトコル[OSOSPFV2]が実行されている場合、そのラインが2つの場所間で通信する好ましい方法である場合、2つの場所は2つの場所と見なすことができます。たとえ各場所に独自のCEルーターがある場合でも、単一のサイト。（「サイト」のこの概念は地理的ではなくトポロジーです。リースされたラインが下がったり、好ましいルートであることをやめた場合、2つの地理的位置はVPNバックボーンを使用して通信し続けることができます。二。）
A CE device is always regarded as being in a single site (though as we shall see in Section 3.2, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs.
CEデバイスは常に単一のサイトにあると見なされます（ただし、セクション3.2に表示されるように、サイトは複数の「仮想サイト」で構成される場合があります）。ただし、サイトは複数のVPNに属している場合があります。
A PE router may attach to CE devices from any number of different sites, whether those CE devices are in the same or in different VPNs. A CE device may, for robustness, attach to multiple PE routers, of the same or of different service providers. If the CE device is a router, the PE router and the CE router will appear as router adjacencies to each other.
PEルーターは、これらのCEデバイスが同じVPNであるかどうかにかかわらず、任意の数の異なるサイトからのCEデバイスに接続する場合があります。CEデバイスは、堅牢性のために、同じまたは異なるサービスプロバイダーの複数のPEルーターに取り付けることができます。CEデバイスがルーターの場合、PEルーターとCEルーターは互いにルーターの隣接として表示されます。
While we speak mostly of "sites" as being the basic unit of interconnection, nothing here prevents a finer degree of granularity in the control of interconnectivity. For example, certain systems at a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only. However, this might require that the site have two attachment circuits to the backbone, one for the intranet and one for the extranet; it might further require that firewall functionality be applied on the extranet attachment circuit.
私たちは主に「サイト」を相互接続の基本単位であると話していますが、ここでは相互接続性の制御におけるより細かい程度の粒度を妨げるものはありません。たとえば、サイトの特定のシステムは、イントラネットのメンバーと1つ以上のエクストラネットのメンバーである場合がありますが、同じサイトの他のシステムはイントラネットのメンバーのみに制限される場合があります。ただし、これには、サイトにバックボーンへの2つのアタッチメントサーキットがあり、1つはイントラネット用、もう1つはエクストラネット用に1つある場合があります。さらに、エクストラネットアタッチメント回路にファイアウォール機能を適用する必要がある場合があります。
Each PE router maintains a number of separate forwarding tables. One of the forwarding tables is the "default forwarding table". The others are "VPN Routing and Forwarding tables", or "VRFs".
各PEルーターは、多数の個別の転送テーブルを維持しています。転送テーブルの1つは、「デフォルト転送テーブル」です。その他は、「VPNルーティングテーブル」または「VRFS」です。
Every PE/CE attachment circuit is associated, by configuration, with one or more VRFs. An attachment circuit that is associated with a VRF is known as a "VRF attachment circuit".
すべてのPE/CEアタッチメント回路は、構成によって、1つ以上のVRFに関連付けられています。VRFに関連付けられているアタッチメント回路は、「VRFアタッチメント回路」として知られています。
In the simplest case and most typical case, a PE/CE attachment circuit is associated with exactly one VRF. When an IP packet is received over a particular attachment circuit, its destination IP address is looked up in the associated VRF. The result of that lookup determines how to route the packet. The VRF used by a packet's ingress PE for routing a particular packet is known as the packet's "ingress VRF". (There is also the notion of a packet's "egress VRF", located at the packet's egress PE; this is discussed in Section 5.)
最も単純なケースおよび最も典型的なケースでは、PE/CEアタッチメント回路は正確に1つのVRFに関連付けられています。特定のアタッチメント回路でIPパケットが受信されると、その宛先IPアドレスが関連するVRFで検索されます。その検索の結果は、パケットをルーティングする方法を決定します。特定のパケットをルーティングするためにパケットのイングレスPEが使用するVRFは、パケットの「イングレスVRF」として知られています。（パケットの出口PEにあるパケットの「出口VRF」の概念もあります。これについてはセクション5で説明します。）
If an IP packet arrives over an attachment circuit that is not associated with any VRF, the packet's destination address is looked up in the default forwarding table, and the packet is routed accordingly. Packets forwarded according to the default forwarding table include packets from neighboring P or PE routers, as well as packets from customer-facing attachment circuits that have not been associated with VRFs.
VRFに関連付けられていないアタッチメント回路にIPパケットが到着すると、パケットの宛先アドレスがデフォルトの転送テーブルで検索され、パケットはそれに応じてルーティングされます。デフォルトの転送テーブルに従って転送されたパケットには、隣接するPまたはPEルーターからのパケット、およびVRFに関連付けられていない顧客向けのアタッチメントサーキットからのパケットが含まれています。
Intuitively, one can think of the default forwarding table as containing "public routes", and of the VRFs as containing "private routes". One can similarly think of VRF attachment circuits as being "private", and of non-VRF attachment circuits as being "public".
直感的には、デフォルトの転送テーブルは「パブリックルート」を含むと考えることができ、VRFは「プライベートルート」を含むと考えることができます。同様に、VRFアタッチメントサーキットは「プライベート」であると考えることができ、VRF以外のアタッチメントサーキットは「公開」であると考えることができます。
If a particular VRF attachment circuit connects site S to a PE router, then connectivity from S (via that attachment circuit) can be restricted by controlling the set of routes that gets entered in the corresponding VRF. The set of routes in that VRF should be limited to the set of routes leading to sites that have at least one VPN in common with S. Then a packet sent from S over a VRF attachment circuit can only be routed by the PE to another site S' if S' is in one of the same VPNs as S. That is, communication (via PE routers) is prevented between any pair of VPN sites that have no VPN in common. Communication between VPN sites and non-VPN sites is prevented by keeping the routes to the VPN sites out of the default forwarding table.
特定のVRFアタッチメント回路がサイトsをPEルーターに接続する場合、対応するVRFに入力されるルートのセットを制御することにより、Sからの接続性（そのアタッチメント回路を介して）を制限できます。そのVRFのルートのセットは、少なくとも1つのVPNがSと共通するサイトにつながるルートのセットに制限する必要があります。S 'if s'はSと同じVPNの1つにあります。つまり、（PEルーターを介した）通信は、VPNが共通していないVPNサイトのペア間で防止されます。VPNサイトと非VPNサイト間の通信は、デフォルトの転送テーブルからVPNサイトへのルートを維持することにより防止されます。
If there are multiple attachment circuits leading from S to one or more PE routers, then there might be multiple VRFs that could be used to route traffic from S. To properly restrict S's connectivity, the same set of routes would have to exist in all the VRFs. Alternatively, one could impose different connectivity restrictions over different attachment circuit from S. In that case, some of the VRFs associated with attachment circuits from S would contain different sets of routes than some of the others.
Sから1つ以上のPEルーターにつながる複数のアタッチメント回路がある場合、SからSの接続を適切に制限するためにトラフィックをルーティングするために使用できる複数のVRFがある場合があります。VRFS。あるいは、Sからの異なるアタッチメント回路に異なる接続制限を課すことができます。その場合、Sからのアタッチメントサーキットに関連付けられたVRFの一部には、他のいくつかとは異なるルートセットが含まれます。
We allow the case in which a single attachment circuit is associated with a set of VRFs, rather than with a single VRF. This can be useful if it is desired to divide a single VPN into several "sub-VPNs", each with different connectivity restrictions, where some characteristic of the customer packets is used to select from among the sub-VPNs. For simplicity though, we will usually speak of an attachment circuit as being associated with a single VRF.
単一のアタッチメント回路が、単一のVRFではなく、VRFのセットに関連付けられるケースを許可します。これは、単一のVPNを複数の「サブVPN」に分割することが望まれる場合に役立ちます。それぞれが異なる接続制限を備えており、顧客パケットのある程度の特性がサブVPNの中から選択するために使用されます。しかし、簡単にするために、通常、単一のVRFに関連付けられているアタッチメント回路について話します。
When a PE router receives a packet from a CE device, it must determine the attachment circuit over which the packet arrived, as this determines in turn the VRF (or set of VRFs) that can be used for forwarding that packet. In general, to determine the attachment circuit over which a packet arrived, a PE router takes note of the physical interface over which the packet arrived, and possibly also takes note of some aspect of the packet's layer 2 header. For example, if a packet's ingress attachment circuit is a Frame Relay VC, the identity of the attachment circuit can be determined from the physical Frame Relay interface over which the packet arrived, together with the Data Link Connection Identifier (DLCI) field in the packet's Frame Relay header.
PEルーターがCEデバイスからパケットを受信すると、パケットの転送に使用できるVRF（またはVRFのセット）を決定するため、パケットが到着したアタッチメント回路を決定する必要があります。一般に、パケットが到着したアタッチメント回路を決定するために、PEルーターはパケットが到着した物理インターフェイスに注意し、おそらくパケットのレイヤー2ヘッダーの一部の側面にも注意してください。たとえば、パケットのイングレスアタッチメント回路がフレームリレーVCである場合、アタッチメント回路のIDは、パケットの到着した物理フレームリレーインターフェイスから、パケットのデータリンク接続識別子（DLCI）フィールドとともに決定できます。フレームリレーヘッダー。
Although the PE's conclusion that a particular packet arrived on a particular attachment circuit may be partially determined by the packet's layer 2 header, it must be impossible for a customer, by writing the header fields, to fool the SP into thinking that a packet that was received over one attachment circuit really arrived over a different one. In the example above, although the attachment circuit is determined partially by inspection of the DLCI field in the Frame Relay header, this field cannot be set freely by the customer.
特定のパケットが特定のアタッチメント回路に到着したというPEの結論は、パケットのレイヤー2ヘッダーによって部分的に決定される可能性がありますが、ヘッダーフィールドを書くことによって、顧客がSPをだまして、パケットがそうであると思わせることは不可能でなければなりません。受け取った1つのアタッチメント回路が実際に別の添付回路に到着しました。上記の例では、アタッチメント回路はフレームリレーヘッダーのDLCIフィールドの検査により部分的に決定されますが、このフィールドは顧客が自由に設定することはできません。
Rather, it must be set to a value specified by the SP, or else the packet cannot arrive at the PE router.
むしろ、SPによって指定された値に設定する必要があります。そうしないと、パケットがPEルーターに到着できません。
In some cases, a particular site may be divided by the customer into several "virtual sites". The SP may designate a particular set of VRFs to be used for routing packets from that site and may allow the customer to set some characteristic of the packet, which is then used for choosing a particular VRF from the set.
場合によっては、特定のサイトが顧客によっていくつかの「仮想サイト」に分割される場合があります。SPは、そのサイトからのルーティングパケットに使用する特定のVRFSセットを指定し、顧客がパケットの特徴を設定できるようにする場合があります。これは、セットから特定のVRFを選択するために使用されます。
For example, each virtual site might be realized as a VLAN. The SP and the customer could agree that on packets arriving from a particular CE, certain VLAN values would be used to identify certain VRFs. Of course, packets from that CE would be discarded by the PE if they carry VLAN tag values that are not in the agreed-upon set. Another way to accomplish this is to use IP source addresses. In this case, the PE uses the IP source address in a packet received from the CE, along with the interface over which the packet is received, to assign the packet to a particular VRF. Again, the customer would only be able to select from among the particular set of VRFs that that customer is allowed to use.
たとえば、各仮想サイトはVLANとして実現される場合があります。SPと顧客は、特定のCEから到着するパケットでは、特定のVRFSを特定するために特定のVLAN値を使用することに同意することができます。もちろん、そのCEからのパケットは、合意されたセットにないVLANタグ値を搭載している場合、PEによって破棄されます。これを達成する別の方法は、IPソースアドレスを使用することです。この場合、PEはCEから受信したパケット内のIPソースアドレスを使用し、パケットが受信されたインターフェイスとともに、パケットを特定のVRFに割り当てます。繰り返しますが、顧客は、その顧客が使用できる特定のVRFSのセットからのみ選択できます。
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, or out different network interfaces.
特定のホストを複数の仮想サイトに置くことが望ましい場合は、そのホストがパケットが関連付けられている仮想サイトごとに決定する必要があります。これは、例えば、異なるVLAN上の異なる仮想サイトからパケットを送信するか、異なるネットワークインターフェイスを送信することで行うことができます。
With what set of routes are the VRFs populated?
VRFが住んでいるルートのセットで？
As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes that are reachable at CE1's site. If PE2 and PE3 are attached, respectively, to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes that it has learned from CE1. PE2 and PE3 use these routes to populate the VRFs that they associate, respectively, with the sites of CE2 and CE3. Routes from sites that are not in VPN V do not appear in these VRFs, which means that packets from CE2 or CE3 cannot be sent to sites that are not in VPN V.
例として、PE1、PE2、およびPE3を3つのPEルーターとし、Ce1、Ce2、およびCe3を3つのCEルーターとします。PE1がCE1から、CE1のサイトで到達可能なルートを学習していると仮定します。PE2とPE3がそれぞれCe2およびCe3に接続し、Ce1、Ce2、およびCe3を含むVPN Vがある場合、PE1はBGPを使用してCe1から学習したルートをPE2とPE3に分布させます。PE2とPE3は、これらのルートを使用して、それぞれCE2およびCE3のサイトに関連付けているVRFを設定します。VPN Vにないサイトからのルートは、これらのVRFに表示されません。つまり、CE2またはCE3のパケットをVPN Vにないサイトに送信できません。
When we speak of a PE "learning" routes from a CE, we are not presupposing any particular learning technique. The PE may learn routes by means of a dynamic routing algorithm, but it may also "learn" routes by having those routes configured (i.e., static routing). (In this case, to say that the PE "learned" the routes from the CE is perhaps to exercise a bit of poetic license.) PEs also need to learn, from other PEs, the routes that belong to a given VPN. The procedures to be used for populating the VRFs with the proper sets of routes are specified in Section 4.
CEからのPEの「学習」ルートについて話すとき、特定の学習手法を前提としていません。PEは、動的なルーティングアルゴリズムを使用してルートを学習する場合がありますが、それらのルートを構成することでルートを「学習」する場合があります（つまり、静的ルーティング）。（この場合、PEはCEからのルートを「学んだ」と言うために、おそらく詩的なライセンスを少し行使することです。）PESは、他のPESから、特定のVPNに属するルートを学ぶ必要があります。適切なルートセットをVRFSに入力するために使用する手順は、セクション4で指定されています。
If there are multiple attachment circuits leading from a particular PE router to a particular site, they might all be mapped to the same forwarding table. But if policy dictates, they could be mapped to different forwarding tables. For instance, the policy might be that a particular attachment circuit from a site is used only for intranet traffic, while another attachment circuit from that site is used only for extranet traffic. (Perhaps, e.g., the CE attached to the extranet attachment circuit is a firewall, while the CE attached to the intranet attachment circuit is not.) In this case, the two attachment circuits would be associated with different VRFs.
特定のPEルーターから特定のサイトにつながる複数のアタッチメント回路がある場合、それらはすべて同じ転送テーブルにマッピングされる可能性があります。しかし、ポリシーが指示する場合、それらは異なる転送テーブルにマッピングすることができます。たとえば、ポリシーは、サイトからの特定のアタッチメント回路がイントラネットトラフィックにのみ使用され、そのサイトからの別のアタッチメント回路はエクストラネットトラフィックにのみ使用される可能性があります。（たとえば、Extranetアタッチメント回路に取り付けられたCEはファイアウォールですが、イントラネットアタッチメント回路に取り付けられたCEはそうではありません。）この場合、2つのアタッチメント回路は異なるVRFに関連付けられます。
Note that if two attachment circuits are associated with the same VRF, then packets that the PE receives over one of them will be able to reach exactly the same set of destinations as packets that the PE receives over the other. So two attachment circuits cannot be associated with the same VRF unless each CE is in the exact same set of VPNs as is the other.
2つのアタッチメントサーキットが同じVRFに関連付けられている場合、PEが受信するPEがそれらの1つを受け取るパケットは、PEが他のパケットとまったく同じ宛先セットに到達できるようになることに注意してください。したがって、各CEがもう一方とまったく同じVPNSセットにある場合を除き、2つのアタッチメント回路を同じVRFに関連付けることはできません。
If an attachment circuit leads to a site which is in multiple VPNs, the attachment circuit may still associated with a single VRF, in which case the VRF will contain routes from the full set of VPNs of which the site is a member.
アタッチメント回路が複数のVPNにあるサイトにつながる場合、アタッチメント回路はまだ単一のVRFに関連付けられている場合があります。この場合、VRFには、サイトがメンバーであるVPNの完全なセットからのルートが含まれます。
PE routers use BGP to distribute VPN routes to each other (more accurately, to cause VPN routes to be distributed to each other).
PEルーターはBGPを使用してVPNルートを相互に配布します（より正確には、VPNルートを互いに分布させます）。
We allow each VPN to have its own address space, which means that a given address may denote different systems in different VPNs. If two routes to the same IP address prefix are actually routes to different systems, it is important to ensure that BGP not treat them as comparable. Otherwise, BGP might choose to install only one of them, making the other system unreachable. Further, we must ensure that POLICY is used to determine which packets get sent on which routes; given that several such routes are installed by BGP, only one such must appear in any particular VRF.
各VPNが独自のアドレススペースを持つことを許可します。つまり、特定のアドレスが異なるVPNで異なるシステムを示す場合があります。同じIPアドレスプレフィックスへの2つのルートが実際に異なるシステムへのルートである場合、BGPがそれらを同等のものとして扱わないようにすることが重要です。それ以外の場合、BGPはそのうちの1つのみをインストールすることを選択して、他のシステムを到達できないようにすることができます。さらに、ポリシーを使用して、どのパケットがどのルートで送信されるかを決定する必要があります。そのようなルートがBGPによって設置されていることを考えると、特定のVRFに表示される必要があるのは1つだけです。
We meet these goals by the use of a new address family, as specified below.
以下に指定されているように、新しいアドレスファミリーを使用することにより、これらの目標を達成します。
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address. If several VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in several different VPNs, it is possible for BGP to carry several completely different routes to that address, one for each VPN.
BGPマルチプロトコル拡張[BGP-MP]により、BGPは複数の「アドレスファミリ」からルートを運ぶことができます。「VPN-IPV4アドレスファミリ」の概念を紹介します。VPN-IPV4アドレスは12バイトの数量で、8バイトのルートdistimutiuseer（RD）から始まり、4バイトのIPv4アドレスで終了します。いくつかのVPNが同じIPv4アドレスプレフィックスを使用している場合、PESはこれらを一意のVPN-IPV4アドレスプレフィックスに変換します。これにより、いくつかの異なるVPNで同じアドレスが使用されている場合、BGPがそのアドレスにいくつかの完全に異なるルートを運ぶことができます。
Since VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses.
VPN-IPV4アドレスとIPv4アドレスは異なるアドレスファミリであるため、BGPはそれらを同等のアドレスとして扱うことはありません。
An RD is simply a number, and it does not contain any inherent information; it does not identify the origin of the route or the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine where to redistribute the route (see Section 4.3).
RDは単なる数字であり、固有の情報は含まれていません。ルートの起源またはルートが分散されるVPNのセットを識別しません。RDの目的は、一般的なIPv4アドレスプレフィックスへの異なるルートを作成できるようにすることだけです。他の手段は、ルートの再配布先を決定するために使用されます（セクション4.3を参照）。
The RD can also be used to create multiple different routes to the very same system. We have already discussed a situation in which the route to a particular server should be different for intranet traffic than for extranet traffic. This can be achieved by creating two different VPN-IPv4 routes that have the same IPv4 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used (see Section 4.3.5) to decide which packets use which route.
RDは、まったく同じシステムに複数の異なるルートを作成するためにも使用できます。特定のサーバーへのルートが、エクストラネットトラフィックとはイントラネットトラフィックの場合に異なる状況についてすでに議論しています。これは、同じIPv4パーツを持つが異なるRDを持つ2つの異なるVPN-IPV4ルートを作成することで実現できます。これにより、BGPは複数の異なるルートを同じシステムにインストールでき、ポリシーを使用して（セクション4.3.5を参照）、どのパケットを使用するかを決定します。
The RDs are structured so that every Service Provider can administer its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other Service Provider. An RD consists of three fields: a 2-byte type field, an administrator field, and an assigned number field. The value of the type field determines the lengths of the other two fields, as well as the semantics of the administrator field. The administrator field identifies an assigned number authority, and the assigned number field contains a number that has been assigned, by the identified authority, for a particular purpose. For example, one could have an RD whose administrator field contains an Autonomous System number (ASN), and whose (4-byte) number field contains a number assigned by the SP to whom that ASN belongs (having been assigned to that SP by the appropriate authority).
RDSは構造化されているため、すべてのサービスプロバイダーが独自の「番号付けスペース」を管理できる（つまり、RDの割り当てを作成できます）。RDは、2バイトタイプフィールド、管理者フィールド、および割り当てられた番号フィールドの3つのフィールドで構成されています。タイプフィールドの値は、他の2つのフィールドの長さと、管理者フィールドのセマンティクスを決定します。管理者フィールドは、割り当てられた番号当局を識別し、割り当てられた番号フィールドには、特定された権限によって割り当てられた番号が特定の目的で含まれています。たとえば、管理者フィールドに自律システム番号（ASN）が含まれているRDがあり、その（4バイトの）数フィールドには、そのASNが属するSPによって割り当てられた数値が含まれています（そのSPに割り当てられています。適切な権限）。
RDs are given this structure in order to ensure that an SP that provides VPN backbone service can always create a unique RD when it needs to do so. However, the structure is not meaningful to BGP; when BGP compares two such address prefixes, it ignores the structure entirely.
RDSには、VPNバックボーンサービスを提供するSPが必要に応じて常に一意のRDを作成できるようにするために、この構造が与えられます。ただし、構造はBGPにとって意味がありません。BGPがそのような2つのアドレスプレフィックスを比較すると、構造を完全に無視します。
A PE needs to be configured such that routes that lead to a particular CE become associated with a particular RD. The configuration may cause all routes leading to the same CE to be associated with the same RD, or it may cause different routes to be associated with different RDs, even if they lead to the same CE.
特定のCEにつながるルートが特定のRDに関連付けられるように、PEを構成する必要があります。構成により、同じCEにつながるすべてのルートが同じRDに関連付けられている場合、または同じCEにつながる場合でも、異なるルートが異なるRDに関連付けられている場合があります。
As stated, a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded as follows:
述べたように、VPN-IPV4アドレスは、8バイトのルート違いで構成され、4バイトのIPv4アドレスが続きます。RDSは次のようにエンコードされます。
- Type Field: 2 bytes - Value Field: 6 bytes
- タイプフィールド：2バイト - 値フィールド：6バイト
The interpretation of the Value field depends on the value of the type field. At the present time, three values of the type field are defined: 0, 1, and 2.
値フィールドの解釈は、タイプフィールドの値に依存します。現在、タイプフィールドの3つの値が定義されています：0、1、および2。
- Type 0: The Value field consists of two subfields:
- タイプ0：値フィールドは2つのサブフィールドで構成されています。
* Administrator subfield: 2 bytes * Assigned Number subfield: 4 bytes
* 管理者サブフィールド：2バイト *割り当てされた番号サブフィールド：4バイト
The Administrator subfield must contain an Autonomous System number. If this ASN is from the public ASN space, it must have been assigned by the appropriate authority (use of ASN values from the private ASN space is strongly discouraged). The Assigned Number subfield contains a number from a numbering space that is administered by the enterprise to which the ASN has been assigned by an appropriate authority.
管理者サブフィールドには、自律システム番号が含まれている必要があります。このASNが公共のASNスペースからのものである場合、適切な当局によって割り当てられている必要があります（プライベートASNスペースからのASN値の使用は強く推奨されていません）。割り当てられた番号サブフィールドには、ASNが適切な当局によって割り当てられた企業によって管理される番号付けスペースからの番号が含まれています。
- Type 1: The Value field consists of two subfields:
- タイプ1：値フィールドは2つのサブフィールドで構成されています。
* Administrator subfield: 4 bytes * Assigned Number subfield: 2 bytes
* 管理者サブフィールド：4バイト *割り当てされた番号サブフィールド：2バイト
The Administrator subfield must contain an IP address. If this IP address is from the public IP address space, it must have been assigned by an appropriate authority (use of addresses from the private IP address space is strongly discouraged). The Assigned Number subfield contains a number from a numbering space which is administered by the enterprise to which the IP address has been assigned.
管理者サブフィールドには、IPアドレスを含める必要があります。このIPアドレスがパブリックIPアドレススペースからのものである場合、適切な権限によって割り当てられている必要があります（プライベートIPアドレススペースからのアドレスの使用は強く落胆しています）。割り当てられた番号サブフィールドには、IPアドレスが割り当てられている企業によって管理される番号付けスペースからの番号が含まれています。
- Type 2: The Value field consists of two subfields:
- タイプ2：値フィールドは2つのサブフィールドで構成されています。
* Administrator subfield: 4 bytes * Assigned Number subfield: 2 bytes
* 管理者サブフィールド：4バイト *割り当てされた番号サブフィールド：2バイト
The Administrator subfield must contain a 4-byte Autonomous System number [BGP-AS4]. If this ASN is from the public ASN space, it must have been assigned by the appropriate authority (use of ASN values from the private ASN space is strongly discouraged). The Assigned Number subfield contains a number from a numbering space which is administered by the enterprise to which the ASN has been assigned by an appropriate authority.
管理者サブフィールドには、4バイトの自律システム番号[BGP-AS4]を含める必要があります。このASNが公共のASNスペースからのものである場合、適切な当局によって割り当てられている必要があります（プライベートASNスペースからのASN値の使用は強く推奨されていません）。割り当てられた番号サブフィールドには、ASNが適切な当局によって割り当てられた企業によって管理される番号付けスペースからの番号が含まれています。
In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled.
このセクションでは、VPN-IPV4ルートの分布が制御される方法について説明します。
If a PE router is attached to a particular VPN (by being attached to a particular CE in that VPN), it learns some of that VPN's IP routes from the attached CE router. Routes learned from a CE routing peer over a particular attachment circuit may be installed in the VRF associated with that attachment circuit. Exactly which routes are installed in this manner is determined by the way in which the PE learns routes from the CE. In particular, when the PE and CE are routing protocol peers, this is determined by the decision process of the routing protocol; this is discussed in Section 7.
PEルーターが特定のVPNに接続されている場合（そのVPNの特定のCEに接続することにより）、付属のCEルーターからそのVPNのIPルートの一部を学習します。特定のアタッチメント回路を介したCEルーティングピアから学習したルートは、そのアタッチメント回路に関連付けられたVRFに取り付けられる場合があります。この方法でどのルートが設置されるかは、PEがCEからルートを学習する方法によって決定されます。特に、PEとCEがルーティングプロトコルピアである場合、これはルーティングプロトコルの決定プロセスによって決定されます。これについては、セクション7で説明します。
These routes are then converted to VPN-IP4 routes, and "exported" to BGP. If there is more than one route to a particular VPN-IP4 address prefix, BGP chooses the "best" one, using the BGP decision process. That route is then distributed by BGP to the set of other PEs that need to know about it. At these other PEs, BGP will again choose the best route for a particular VPN-IP4 address prefix. Then the chosen VPN-IP4 routes are converted back into IP routes, and "imported" into one or more VRFs. Whether they are actually installed in the VRFs depends on the decision process of the routing method used between the PE and those CEs that are associated with the VRF in question. Finally, any route installed in a VRF may be distributed to the associated CE routers.
これらのルートは、VPN-IP4ルートに変換され、BGPに「エクスポート」されます。特定のVPN-IP4アドレスプレフィックスへのルートが複数ある場合、BGPはBGP決定プロセスを使用して「最良」のルートを選択します。そのルートは、BGPによってそれについて知る必要がある他のPESのセットに分配されます。これらの他のPESでは、BGPは特定のVPN-IP4アドレスプレフィックスに最適なルートを再度選択します。次に、選択したVPN-IP4ルートがIPルートに戻され、1つ以上のVRFに「インポート」されます。それらが実際にVRFにインストールされているかどうかは、問題のVRFに関連付けられているPEとそれらのCEの間で使用されるルーティング方法の決定プロセスに依存します。最後に、VRFに設置された任意のルートは、関連するCEルーターに分布する場合があります。
Every VRF is associated with one or more Route Target (RT) attributes.
すべてのVRFは、1つ以上のルートターゲット（RT）属性に関連付けられています。
When a VPN-IPv4 route is created (from an IPv4 route that the PE has learned from a CE) by a PE router, it is associated with one or more Route Target attributes. These are carried in BGP as attributes of the route.
PEルーターによってVPN-IPV4ルート（PEがCEから学習したIPv4ルートから）が作成されると、1つ以上のルートターゲット属性に関連付けられます。これらは、ルートの属性としてBGPで運ばれます。
Any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T. When such a route is received by a PE router, it is eligible to be installed in those of the PE's VRFs that are associated with Route Target T. (Whether it actually gets installed depends upon the outcome of the BGP decision process, and upon the outcome of the decision process of the IGP (i.e., the intra-domain routing protocol) running on the PE/CE interface.)
ルートターゲットTに関連付けられているルートは、ルートターゲットTに関連付けられたVRFを持つすべてのPEルーターに配布する必要があります。そのようなルートがPEルーターによって受信される場合、関連するPEのVRFのルートにインストールされる資格があります。ルートターゲットT.（実際にインストールされるかどうかは、BGP決定プロセスの結果と、PE/CEインターフェイスで実行されているIGPの決定プロセス（つまり、ドメイン内ルーティングプロトコル）の結果によって異なります。））
A Route Target attribute can be thought of as identifying a set of sites. (Though it would be more precise to think of it as identifying a set of VRFs.) Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic that is received from the corresponding sites.
ルートターゲット属性は、一連のサイトを識別すると考えることができます。（VRFSのセットを識別すると考える方が正確ですが。）特定のルートターゲット属性をルートに関連付けることで、対応するサイトから受信するトラフィックをルーティングするために使用されるVRFにそのルートを配置できます。。
There is a set of Route Targets that a PE router attaches to a route received from site S; these may be called the "Export Targets". And there is a set of Route Targets that a PE router uses to determine whether a route received from another PE router could be placed in the VRF associated with site S; these may be called the "Import Targets". The two sets are distinct, and need not be the same. Note that a particular VPN-IPv4 route is only eligible for installation in a particular VRF if there is some Route Target that is both one of the route's Route Targets and one of the VRF's Import Targets.
PEルーターがサイトSから受信したルートに取り付けられるルートターゲットのセットがあります。これらは「エクスポート目標」と呼ばれる場合があります。また、PEルーターが別のPEルーターから受信したルートをサイトSに関連付けられたVRFに配置できるかどうかを判断するために使用するルートターゲットのセットがあります。これらは「インポートターゲット」と呼ばれる場合があります。2つのセットは明確であり、同じである必要はありません。特定のVPN-IPV4ルートは、ルートのルートターゲットのいずれかとVRFのインポートターゲットの1つであるルートターゲットがある場合にのみ、特定のVRFにインストールする資格があることに注意してください。
The function performed by the Route Target attribute is similar to that performed by the BGP Communities attribute. However, the format of the latter is inadequate for present purposes, since it allows only a 2-byte numbering space. It is desirable to structure the format, similar to what we have described for RDs (see Section 4.2), so that a type field defines the length of an administrator field, and the remainder of the attribute is a number from the specified administrator's numbering space. This can be done using BGP Extended Communities. The Route Targets discussed herein are encoded as BGP Extended Community Route Targets [BGP-EXTCOMM]. They are structured similarly to the RDs.
ルートターゲット属性によって実行される関数は、BGPコミュニティ属性によって実行される関数と類似しています。ただし、後者の形式は、2バイトの番号付けスペースのみを可能にするため、現在の目的では不十分です。RDSについて説明したものと同様に形式を構築することが望ましいので（セクション4.2を参照）、タイプフィールドは管理者フィールドの長さを定義し、属性の残りは指定された管理者の番号付けスペースからの数字です。これは、BGP拡張コミュニティを使用して実行できます。ここで説明するルートターゲットは、BGP拡張コミュニティルートターゲット[BGP-ExtComm]としてエンコードされます。それらはRDSと同様に構成されています。
When a BGP speaker has received more than one route to the same VPN-IPv4 prefix, the BGP rules for route preference are used to choose which VPN-IPv4 route is installed by BGP.
BGPスピーカーが同じVPN-IPV4プレフィックスへの複数のルートを受け取った場合、ルート設定のBGPルールを使用して、BGPによってインストールされるVPN-IPV4ルートを選択します。
Note that a route can only have one RD, but it can have multiple Route Targets. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
ルートには1つのRDしか持てませんが、複数のルートターゲットを持つことができることに注意してください。BGPでは、複数のルートとは対照的に、複数の属性を持つ単一のルートがある場合、スケーラビリティが向上します。より多くのルートを作成する（つまり、より多くのRDを使用する）ことにより、ルートターゲット属性を排除できますが、スケーリングプロパティはあまり好ましくありません。
How does a PE determine which Route Target attributes to associate with a given route? There are a number of different possible ways. The PE might be configured to associate all routes that lead to a specified site with a specified Route Target. Or the PE might be configured to associate certain routes leading to a specified site with one Route Target, and certain with another.
PEは、特定のルートに関連付けるためのターゲット属性をPEがどのように決定しますか？さまざまな方法があります。PEは、指定されたルートターゲットで指定されたサイトにつながるすべてのルートを関連付けるように構成されている場合があります。または、PEは、特定のサイトにつながる特定のルートを1つのルートターゲットに導くように構成され、特定のルートを別のルートで特定するように構成されている場合があります。
If the PE and the CE are themselves BGP peers (see Section 7), then the SP may allow the customer, within limits, to specify how its routes are to be distributed. The SP and the customer would need to agree in advance on the set of RTs that are allowed to be attached to the customer's VPN routes. The CE could then attach one or more of those RTs to each IP route that it distributes to the PE. This gives the customer the freedom to specify in real time, within agreed-upon limits, its route distribution policies. If the CE is allowed to attach RTs to its routes, the PE MUST filter out all routes that contain RTs that the customer is not allowed to use. If the CE is not allowed to attach RTs to its routes, but does so anyway, the PE MUST remove the RT before converting the customer's route to a VPN-IPv4 route.
PEとCEがそれ自体がBGPピアである場合（セクション7を参照）、SPは顧客が制限内で、そのルートの分布方法を指定することを許可する場合があります。SPと顧客は、顧客のVPNルートに接続できるRTのセットで事前に同意する必要があります。CEは、これらのRTの1つ以上を、PEに分配する各IPルートに接続できます。これにより、顧客は、合意された制限内で、そのルート配布ポリシー内でリアルタイムで指定する自由を提供します。CEがRTSをルートに取り付けることが許可されている場合、PEは顧客が使用することを許可されていないRTを含むすべてのルートを除外する必要があります。CEがRTSをそのルートに接続することを許可されていないが、とにかくそうする場合、PEは顧客のルートをVPN-IPv4ルートに変換する前にRTを削除する必要があります。
If two sites of a VPN attach to PEs that are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. (The term "IBGP" refers to the set of protocols and procedures used when there is a BGP connection between two BGP speakers in the same Autonomous System. This is distinguished from "EBGP", the set of procedures used between two BGP speakers in different Autonomous Systems.) Alternatively, each can have an IBGP connection to a route reflector [BGP-RR].
VPNの2つの部位が同じ自律システムにあるPESに接続する場合、PESはそれらの間のIBGP接続によってVPN-IPV4ルートを互いに配布できます。（「IBGP」という用語は、同じ自律システムに2つのBGPスピーカー間にBGP接続があるときに使用されるプロトコルと手順のセットを指します。これは、「EBGP」とは異なります。自律システム。）あるいは、それぞれがルートリフレクター[BGP-RR]へのIBGP接続を持つことができます。
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". This address is encoded as a VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next hop address be in the same address family as the Network Layer Reachability Information (NLRI).) It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP].) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and process the packet appropriately.
PEルーターがBGPを介してVPN-IPV4ルートを配布すると、独自のアドレスを「BGP Next Hop」として使用します。このアドレスは、RDが0のVPN-IPV4アドレスとしてエンコードされています。MPLSラベル。（基本的に、PEルーターはVPN-IPV4ルートではなく、VPN-IPV4ルートとラベル付けされたラベルを分配します。cf。[MPLS-BGP]。）PEがスタックの上部にある受信パケットを処理すると、PEはポップしますスタック、パケットを適切に処理します。
The PE may distribute the exact set of routes that appears in the VRF, or it may perform summarization and distribute aggregates of those routes, or it may do some of one and some of the other.
PEは、VRFに表示される正確なルートのセットを配布するか、要約を実行してそれらのルートの集合体を配布する場合があります。そうしないと、その他の一部を実行する場合があります。
Suppose that a PE has assigned label L to route R, and has distributed this label mapping via BGP. If R is an aggregate of a set of routes in the VRF, the PE will know that packets from the backbone that arrive with this label must have their destination addresses looked up in a VRF. When the PE looks up the label in its Label Information Base, it learns which VRF must be used. On the other hand, if R is not an aggregate, then when the PE looks up the label, it learns the egress attachment circuit, as well as the encapsulation header for the packet. In this case, no lookup in the VRF is done.
PEがラベルLをルートRに割り当て、BGPを介してこのラベルマッピングを配布したと仮定します。rがVRFの一連のルートの集合体である場合、PEは、このラベルに到着したバックボーンからのパケットがVRFで宛先アドレスを調べる必要があることを知るでしょう。PEがラベル情報ベースのラベルを検索すると、どのVRFを使用する必要があるかがわかります。一方、Rが集合体でない場合、PEがラベルを調べると、出力アタッチメント回路とパケットのカプセル化ヘッダーが学習します。この場合、VRFの検索は行われません。
We would expect that the most common case would be the case where the route is NOT an aggregate. The case where it is an aggregate can be very useful though if the VRF contains a large number of host routes (e.g., as in dial-in), or if the VRF has an associated Local Area Network (LAN) interface (where there is a different outgoing layer 2 header for each system on the LAN, but a route is not distributed for each such system).
最も一般的なケースは、ルートが集計ではない場合になると予想されます。VRFに多数のホストルート（ダイヤルインなど）が含まれている場合、またはVRFに関連するローカルエリアネットワーク（LAN）インターフェイスがある場合（たとえば）、VRFに多数のホストルートが含まれている場合は、非常に便利です。LAN上の各システムの異なる発信レイヤー2ヘッダーですが、そのようなシステムごとにルートは分散されていません）。
Whether or not each route has a distinct label is an implementation matter. There are a number of possible algorithms one could use to determine whether two routes get assigned the same label:
各ルートに異なるラベルがあるかどうかは、実装の問題です。2つのルートが同じラベルを割り当てられるかどうかを判断するために使用できる多くの可能なアルゴリズムがあります。
- One may choose to have a single label for an entire VRF, so that a single label is shared by all the routes from that VRF. Then when the egress PE receives a packet with that label, it must look up the packet's IP destination address in that VRF (the packet's "egress VRF"), in order to determine the packet's egress attachment circuit and the corresponding data link encapsulation.
- VRF全体に単一のラベルを持つことを選択できます。これにより、そのVRFのすべてのルートで単一のラベルが共有されます。次に、出力PEがそのラベルでパケットを受信した場合、パケットの出口アタッチメント回路と対応するデータリンクのカプセル化を決定するために、そのVRF（パケットの「出口VRF」）のパケットのIP宛先アドレスを調べる必要があります。
- One may choose to have a single label for each attachment circuit, so that a single label is shared by all the routes with the same "outgoing attachment circuit". This enables one to avoid doing a lookup in the egress VRF, though some sort of lookup may need to be done in order to determine the data link encapsulation, e.g., an Address Resolution Protocol (ARP) lookup.
- アタッチメント回路ごとに単一のラベルを持つことを選択できるため、同じ「発信アタッチメント回路」を持つすべてのルートで単一のラベルが共有されます。これにより、出力VRFのルックアップを避けることができますが、データリンクのカプセル化、例えばアドレス解像度プロトコル（ARP）ルックアップを決定するために、何らかのルックアップを実行する必要がある場合があります。
- One may choose to have a distinct label for each route. Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can switch the preferred path for a route from one attachment circuit to another, without there being any need to distribute new a label for that route.
- 各ルートに異なるラベルを持つことを選択できます。次に、ルートが複数のアタッチメント回路で潜在的に到達可能な場合、PE/CEルーティングは、そのルートの新しいAラベルを配布する必要がなく、あるアタッチメント回路から別のアタッチメント回路に優先パスを切り替えることができます。
There may be other possible algorithms as well. The choice of algorithm is entirely at the discretion of the egress PE, and is otherwise transparent.
他の可能なアルゴリズムもあるかもしれません。アルゴリズムの選択は、完全に出口PEの裁量であり、それ以外の場合は透明です。
In using BGP-distributed MPLS labels in this manner, we presuppose that an MPLS packet carrying such a label can be tunneled from the router that installs the corresponding BGP-distributed route to the router that is the BGP next hop of that route. This requires either that a label switched path exist between those two routers or else that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be used between them.
この方法でBGP-Distributed MPLSラベルを使用する際に、そのようなラベルを運ぶMPLSパケットは、そのルートのBGP Next Hopであるルーターに対応するBGP分布ルートをインストールするルーターからトンネル化できることを前提としています。これには、これら2つのルーターの間にラベルスイッチされたパスが存在するか、他のトンネリングテクノロジー（[MPLS-in-IP-GRE]）を使用できることが必要です。
This tunnel may follow a "best effort" route, or it may follow a traffic-engineered route. Between a given pair of routers, there may be one such tunnel, or there may be several, perhaps with different Quality of Service (QoS) characteristics. All that matters for the VPN architecture is that some such tunnel exists. To ensure interoperability among systems that implement this VPN architecture using MPLS label switched paths as the tunneling technology, all such systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP]. In particular, Downstream Unsolicited mode MUST be supported on interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM] nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces, and Downstream on Demand mode MUST be supported on LC-ATM interfaces and LC-FR interfaces.
このトンネルは、「最善の努力」ルートに従うか、交通機関のルートに従うことがあります。特定のルーターのペアの間には、そのようなトンネルが1つある場合があります。または、おそらく異なるサービス品質（QOS）特性を持ついくつかのトンネルがある場合があります。VPNアーキテクチャにとって重要なのは、そのようなトンネルが存在することです。このVPNアーキテクチャを実装するシステム間の相互運用性を確保するには、MPLSラベルスイッチされたパスをトンネルテクノロジーとして実装するために、すべてのこのようなシステムは、ラベル分布プロトコル（LDP）[MPLS-LDP]をサポートする必要があります。特に、ラベル制御ATM（LC-ATM）[MPLS-ATM]もラベル制御フレームリレー（LC-FR）[MPLS-FR]インターフェイスでも、下流のオンデマンドモードでもないインターフェイスで下流の未承諾モードをサポートする必要があります。LC-ATMインターフェイスとLC-FRインターフェイスでサポートされます。
If the tunnel follows a best-effort route, then the PE finds the route to the remote endpoint by looking up its IP address in the default forwarding table.
トンネルがベストエフォートのルートに従う場合、PEはデフォルトの転送テーブルでIPアドレスを調べることにより、リモートエンドポイントへのルートを見つけます。
A PE router, UNLESS it is a route reflector (see Section 4.3.3) or an Autonomous System Border Router (ASBR) for an inter-provider VPN (see Section 10), should not install a VPN-IPv4 route unless it has at least one VRF with an Import Target identical to one of the route's Route Target attributes. Inbound filtering should be used to cause such routes to be discarded. If a new Import Target is later added to one of the PE's VRFs (a "VPN Join" operation), it must then acquire the routes it may previously have discarded. This can be done using the refresh mechanism described in [BGP-RFSH]. The outbound route filtering mechanism of [BGP-ORF] can also be used to advantage to make the filtering more dynamic.
PEルーターは、それがルートリフレクター（セクション4.3.3を参照）でない場合（セクション4.3.3を参照）、またはプロバイダー間VPNの自律システム境界ルーター（ASBR）（セクション10を参照）は、でVPN-IPV4ルートをインストールしないでくださいルートのルートターゲット属性のいずれかと同じインポートターゲットを持つ少なくとも1つのVRF。インバウンドフィルタリングを使用して、そのようなルートを破棄する必要があります。後で新しいインポートターゲットがPEのVRFの1つ（「VPN結合」操作）に追加された場合、以前に破棄した可能性のあるルートを取得する必要があります。これは、[BGP-RFSH]で説明されている更新メカニズムを使用して実行できます。[BGP-ORF]のアウトバウンドルートフィルタリングメカニズムを使用して、フィルタリングをより動的にするために有利にすることもできます。
Similarly, if a particular Import Target is no longer present in any of a PE's VRFs (as a result of one or more "VPN Prune" operations), the PE may discard all routes that, as a result, no longer have any of the PE's VRF's Import Targets as one of their Route Target attributes.
同様に、特定のインポートターゲットがPEのVRFSのいずれにも存在しなくなった場合（1つ以上の「VPN Prune」操作の結果として）、PEは、結果として、もはや、いずれもありません。PEのVRFのインポートターゲットは、ルートターゲット属性の1つとしてターゲットをターゲットにします。
A router that is not attached to any VPN and that is not a Route Reflector (i.e., a P router) never installs any VPN-IPv4 routes at all.
VPNに接続されておらず、ルートリフレクター（つまり、Pルーター）ではないルーターは、VPN-IPV4ルートをまったくインストールしません。
Note that VPN Join and Prune operations are non-disruptive and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used.
[BGP-RFSH]の更新メカニズムが使用されている限り、VPN結合操作とプルーン操作は破壊的であり、BGP接続を倒す必要はないことに注意してください。
As a result of these distribution rules, no one PE ever needs to maintain all routes for all VPNs; this is an important scalability consideration.
これらの配布規則の結果として、すべてのVPNのすべてのルートを維持する必要はありません。これは重要なスケーラビリティの考慮事項です。
Rather than having a complete IBGP mesh among the PEs, it is advantageous to make use of BGP Route Reflectors [BGP-RR] to improve scalability. All the usual techniques for using route reflectors to improve scalability (e.g., route reflector hierarchies) are available.
PESの完全なIBGPメッシュを使用するのではなく、BGPルートリフレクター[BGP-RR]を使用してスケーラビリティを向上させることが有利です。ルートリフレクターを使用してスケーラビリティ（ルートリフレクター階層など）を改善するためのすべての通常の手法が利用可能です。
Route reflectors are the only systems that need to have routing information for VPNs to which they are not directly attached. However, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone.
ルートリフレクターは、直接接続されていないVPNのルーティング情報を持つ必要がある唯一のシステムです。ただし、バックボーンでサポートされているすべてのVPNのすべてのVPN-IPV4ルートを1つのルートリフレクターに知ってもらう必要はありません。
We outline below two different ways to partition the set of VPN-IPv4 routes among a set of route reflectors.
ルートリフレクターのセット間でVPN-IPV4ルートのセットを分割する2つの異なる方法を以下に概説します。
1. Each route reflector is preconfigured with a list of Route Targets. For redundancy, more than one route reflector may be preconfigured with the same list. A route reflector uses the preconfigured list of Route Targets to construct its inbound route filtering. The route reflector may use the techniques of [BGP-ORF] to install on each of its peers (regardless of whether the peer is another route reflector or a PE) the set of Outbound Route Filters (ORFs) that contains the list of its preconfigured Route Targets. Note that route reflectors should accept ORFs from other route reflectors, which means that route reflectors should advertise the ORF capability to other route reflectors.
1. 各ルートリフレクターには、ルートターゲットのリストが入っています。冗長性のために、同じリストで複数のルートリフレクターを事前に設定することができます。ルートリフレクターは、ルートターゲットの事前に設定されたリストを使用して、インバウンドルートフィルタリングを構築します。ルートリフレクターは、[BGP-ORF]のテクニックを使用して、各ピアに（ピアが別のルートリフレクターかPEであるかに関係なく）にインストールすることができます。ルートターゲット。ルートリフレクターは、他のルートリフレクターからのORFを受け入れる必要があることに注意してください。つまり、ルートリフレクターは他のルートリフレクターにORF機能を宣伝する必要があります。
A service provider may modify the list of preconfigured Route Targets on a route reflector. When this is done, the route reflector modifies the ORFs it installs on all of its IBGP peers. To reduce the frequency of configuration changes on route reflectors, each route reflector may be preconfigured with a block of Route Targets. This way, when a new Route Target is needed for a new VPN, there is already one or more route reflectors that are (pre)configured with this Route Target.
サービスプロバイダーは、ルートリフレクター上の事前に設定されたルートターゲットのリストを変更できます。これが完了すると、ルートリフレクターは、すべてのIBGPピアにインストールするORFを変更します。ルートリフレクターの構成変更の頻度を減らすために、各ルートリフレクターは、ルートターゲットのブロックで事前に設定される場合があります。これにより、新しいVPNに新しいルートターゲットが必要な場合、このルートターゲットで（PRE）構成された1つまたは複数のルートリフレクターが既にあります。
Unless a given PE is a client of all route reflectors, when a new VPN is added to the PE ("VPN Join"), it will need to become a client of the route reflector(s) that maintain routes for that VPN. Likewise, deleting an existing VPN from the PE ("VPN Prune") may result in a situation where the PE no longer needs to be a client of some route reflector(s). In either case, the Join or Prune operation is non-disruptive (as long as [BGP-RFSH] is used, and never requires a BGP connection to be brought down, only to be brought right back up.
特定のPEがすべてのルートリフレクターのクライアントでない限り、新しいVPNがPE（ "VPN Join"）に追加されている場合、そのVPNのルートを維持するルートリフレクターのクライアントになる必要があります。同様に、PE（ "VPN Prune"）から既存のVPNを削除すると、PEがルートリフレクターのクライアントになる必要がなくなった状況になる場合があります。どちらの場合でも、結合またはプルーンの操作は破壊的ではありません（[BGP-RFSH]が使用されている限り、BGP接続を倒す必要はありません。
(By "adding a new VPN to a PE", we really mean adding a new import Route Target to one of its VRFs, or adding a new VRF with an import Route Target not had by any of the PE's other VRFs.)
（「新しいVPNをPEに追加する」ことにより、VRFのいずれかに新しいインポートルートターゲットを追加するか、PEの他のVRFのいずれにも搭載されていないインポートルートターゲットを備えた新しいVRFを追加することを意味します。）
2. Another method is to have each PE be a client of some subset of the route reflectors. A route reflector is not preconfigured with the list of Route Targets, and does not perform inbound route filtering of routes received from its clients (PEs); rather, it accepts all the routes received from all of its clients (PEs). The route reflector keeps track of the set of the Route Targets carried by all the routes it receives. When the route reflector receives from its client a route with a Route Target that is not in this set, this Route Target is immediately added to the set. On the other hand, when the route reflector no longer has any routes with a particular Route Target that is in the set, the route reflector should delay (by a few hours) the deletion of this Route Target from the set.
2. 別の方法は、各PEをルートリフレクターのサブセットのクライアントにすることです。ルートリフレクターは、ルートターゲットのリストとともに事前に設定されておらず、クライアント（PES）から受け取ったルートのインバウンドルートフィルタリングを実行しません。むしろ、すべてのクライアント（PES）から受け取ったすべてのルートを受け入れます。ルートリフレクターは、受け取るすべてのルートによって運ばれるルートターゲットのセットを追跡します。ルートリフレクターがクライアントからこのセットにないルートターゲットを備えたルートを受信すると、このルートターゲットはすぐにセットに追加されます。一方、ルートリフレクターにセット内にある特定のルートターゲットを持つルートがなくなった場合、ルートリフレクターは（数時間）セットからのこのルートターゲットの削除を遅らせる必要があります。
The route reflector uses this set to form the inbound route filters that it applies to routes received from other route reflectors. The route reflector may also use ORFs to install the appropriate outbound route filtering on other route reflectors. Just like with the first approach, a route reflector should accept ORFs from other route reflectors. To accomplish this, a route reflector advertises ORF capability to other route reflectors.
ルートリフレクターは、このセットを使用して、他のルートリフレクターから受信したルートに適用されるインバウンドルートフィルターを形成します。ルートリフレクターは、ORFを使用して、他のルートリフレクターに適切なアウトバウンドルートフィルタリングをインストールすることもできます。最初のアプローチと同様に、ルートリフレクターは他のルートリフレクターからのORFを受け入れる必要があります。これを達成するために、ルートリフレクターは他のルートリフレクターにORF機能を宣伝します。
When the route reflector changes the set, it should immediately change its inbound route filtering. In addition, if the route reflector uses ORFs, then the ORFs have to be immediately changed to reflect the changes in the set. If the route reflector doesn't use ORFs, and a new Route Target is added to the set, the route reflector, after changing its inbound route filtering, must issue BGP Refresh to other route reflectors.
ルートリフレクターがセットを変更すると、すぐにインバウンドルートフィルタリングを変更する必要があります。さらに、ルートリフレクターがORFを使用している場合、ORFはすぐに変更する必要があり、セットの変更を反映する必要があります。ルートリフレクターがORFを使用しておらず、新しいルートターゲットがセットに追加されている場合、インバウンドルートフィルタリングを変更した後、ルートリフレクターはBGPリフレッシュを他のルートリフレクターに発行する必要があります。
The delay of "a few hours" mentioned above allows a route reflector to hold onto routes with a given RT, even after it loses the last of its clients that are interested in such routes. This protects against the need to reacquire all such routes if the clients' "disappearance" is only temporary.
上記の「数時間」の遅延により、ルートリフレクターは、そのようなルートに関心のある最後のクライアントを失った後でも、特定のRTでルートを保持することができます。これは、クライアントの「失disappear」が一時的なものにすぎない場合、そのようなルートをすべて再取得する必要性から保護されます。
With this procedure, VPN Join and Prune operations are also non-disruptive.
この手順により、VPN結合およびプルーン操作も破壊的ではありません。
Note that this technique will not work properly if some client PE has a VRF with an import Route Target that is not one of its export Route Targets.
一部のクライアントPEには、エクスポートルートターゲットの1つではないインポートルートターゲットを備えたVRFがある場合、この手法は適切に機能しないことに注意してください。
In these procedures, a PE router which attaches to a particular VPN "auto-discovers" the other PEs that attach to the same VPN. When a new PE router is added, or when an existing PE router attaches to a new VPN, no reconfiguration of other PE routers is needed.
これらの手順では、特定のVPNに付着するPEルーターが、同じVPNに付着するもう1つのPESを「自動分割」します。新しいPEルーターが追加された場合、または既存のPEルーターが新しいVPNに取り付けられた場合、他のPEルーターの再構成は必要ありません。
Just as there is no one PE router that needs to know all the VPN-IPv4 routes supported over the backbone, these distribution rules ensure that there is no one Route Reflector (RR) that needs to know all the VPN-IPv4 routes supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bounded by the capacity of any single device, and therefore can increase virtually without bound.
バックボーン上でサポートされているすべてのVPN-IPV4ルートを知る必要があるPEルーターがないように、これらの分布ルールは、サポートされているすべてのVPN-IPV4ルートを知る必要があるルートリフレクター（RR）がないことを保証します。背骨。その結果、バックボーン上でサポートできるそのようなルートの総数は、単一のデバイスの容量によって制限されていないため、拘束されずに実質的に増加する可能性があります。
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the NLRI. If the Address Family Identifier (AFI) field is set to 1, and the Subsequent Address Family Identifier (SAFI) field is set to 128, the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since the network layer protocol associated with the NLRI is still IP. Note that this VPN architecture does not require the capability to distribute unlabeled VPN-IPv4 addresses.
BGPマルチプロトコル拡張[BGP-MP]は、NLRIをエンコードするために使用されます。アドレスファミリ識別子（AFI）フィールドが1に設定され、その後のアドレスファミリ識別子（SAFI）フィールドが128に設定されている場合、NLRIはMPLS標識VPN-IPV4アドレスです。NLRIに関連付けられたネットワークレイヤープロトコルはまだIPであるため、AFI 1が使用されます。このVPNアーキテクチャでは、非ベール型VPN-IPV4アドレスを配布する機能は必要ないことに注意してください。
In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an AFI of 1 and an SAFI of 128.
2人のBGPスピーカーがラベル付きVPN-IPV4 NLRIを交換するためには、BGP機能広告を使用して、どちらもそのようなNLRIを適切に処理できるようにする必要があります。これは、[BGP-MP]で指定されているように、機能コード1（MultiProtocol BGP）を使用し、AFIが1、SAFIが128で行われます。
The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS-BGP], where the prefix consists of an 8-byte RD followed by an IPv4 prefix.
標識されたVPN-IPV4 NLRI自体は、[MPLS-BGP]で指定されているようにエンコードされており、プレフィックスは8バイトRDで構成され、その後IPv4プレフィックスが続きます。
By setting up the Import Targets and Export Targets properly, one can construct different kinds of VPNs.
インポート目標を設定し、ターゲットを適切にエクスポートすることにより、異なる種類のVPNを構築できます。
Suppose it is desired to create a fully meshed closed user group, i.e., a set of sites where each can send traffic directly to the other, but traffic cannot be sent to or received from other sites. Then each site is associated with a VRF, a single Route Target attribute is chosen, that Route Target is assigned to each VRF as both the Import Target and the Export Target, and that Route Target is not assigned to any other VRFs as either the Import Target or the Export Target.
完全にメッシュ化された閉じたユーザーグループ、つまり、それぞれが他方に直接トラフィックを送信できるが、トラフィックを他のサイトに送信または受信することができないサイトのセットを作成することが望ましいとします。次に、各サイトはVRFに関連付けられ、単一のルートターゲット属性が選択され、そのルートターゲットが各VRFにインポートターゲットとエクスポートターゲットの両方として割り当てられ、そのルートターゲットはインポートとして他のVRFに割り当てられていませんターゲットまたはエクスポートターゲット。
Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and
あるいは、何らかの理由で、「ハブと話す」種類のVPNを作成する必要があると仮定します。これは、2つのルートターゲット値を使用することで実行できます。1つは「ハブ」を意味し、1つの意味「スポーク」を意味します。ハブサイトに接続されたVRFSでは、「ハブ」はエクスポート目標であり、
"Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target.
「スポーク」はインポートターゲットです。スポークサイトに接続されているVRFSでは、「ハブ」がインポートターゲットであり、「スポーク」が輸出目標です。
Thus, the methods for controlling the distribution of routing information among various sets of sites are very flexible, which in turn provides great flexibility in constructing VPNs.
したがって、さまざまなサイトセット間のルーティング情報の分布を制御する方法は非常に柔軟であり、VPNの構築に大きな柔軟性を提供します。
It is possible to distribute routes from one VRF to another, even if both VRFs are in the same PE, even though in this case one cannot say that the route has been distributed by BGP. Nevertheless, the decision to distribute a particular route from one VRF to another within a single PE is the same decision that would be made if the VRFs were on different PEs. That is, it depends on the Route Target attribute that is assigned to the route (or would be assigned if the route were distributed by BGP), and the import target of the second VRF.
この場合、ルートがBGPによって分布しているとは言えない場合でも、両方のVRFが同じPEにある場合でも、あるVRFから別のVRFにルートを分配することができます。それにもかかわらず、特定のルートを1つのVRFから単一のPE内で別のVRFに分配する決定は、VRFが異なるPESにある場合に行われる決定と同じ決定です。つまり、ルートに割り当てられるルートターゲット属性（または、ルートがBGPによって分布している場合に割り当てられる）と、2番目のVRFのインポートターゲットに依存します。
If the intermediate routers in the backbone do not have any information about the routes to the VPNs, how are packets forwarded from one VPN site to another?
バックボーン内の中間ルーターにVPNへのルートに関する情報がない場合、パケットはあるVPNサイトから別のサイトにどのように転送されますか？
When a PE receives an IP packet from a CE device, it chooses a particular VRF in which to look up the packet's destination address. This choice is based on the packet's ingress attachment circuit.
PEがCEデバイスからIPパケットを受信すると、パケットの宛先アドレスを検索する特定のVRFを選択します。この選択は、パケットのイングレスアタッチメント回路に基づいています。
Assume that a match is found. As a result we learn the packet's "next hop".
一致が見つかったと仮定します。その結果、パケットの「次のホップ」を学びます。
If the packet's next hop is reached directly over a VRF attachment circuit from this PE (i.e., the packet's egress attachment circuit is on the same PE as its ingress attachment circuit), then the packet is sent on the egress attachment circuit, and no MPLS labels are pushed onto the packet's label stack.
パケットの次のホップに、このPEからのVRFアタッチメント回路の上に直接到達した場合（つまり、パケットの出口アタッチメント回路がイングレスアタッチメント回路と同じPEにあります）、パケットは出口アタッチメント回路に送信され、MPLSはありませんラベルは、パケットのラベルスタックに押し上げられます。
If the ingress and egress attachment circuits are on the same PE, but are associated with different VRFs, and if the route that best matches the destination address in the ingress attachment circuit's VRF is an aggregate of several routes in the egress attachment circuit's VRF, it may be necessary to look up the packet's destination address in the egress VRF as well.
Ingress and Emutressのアタッチメントサーキットは同じPEにありますが、異なるVRFに関連付けられています。また、Ingressアタッチメント回路のVRFの宛先アドレスに最適なルートが、出口アタッチメント回路のVRFのいくつかのルートの集合体である場合、出力VRFのパケットの宛先アドレスも検索するために必要になる場合があります。
If the packet's next hop is NOT reached through a VRF attachment circuit, then the packet must travel at least one hop through the backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop will have assigned an MPLS label for the route that best matches the packet's destination address. Call this label the "VPN route label". The IP packet is turned into an MPLS packet with the VPN route label as the sole label on the label stack.
パケットの次のホップがVRFアタッチメント回路を介して到達しない場合、パケットはバックボーンを介して少なくとも1回のホップを移動する必要があります。したがって、パケットには「BGP Next Hop」があり、BGP Next Hopには、パケットの宛先アドレスに最適なルートにMPLSラベルが割り当てられます。このラベルを「VPNルートラベル」と呼びます。IPパケットは、ラベルスタックの唯一のラベルとして、VPNルートラベルを備えたMPLSパケットに変換されます。
The packet must then be tunneled to the BGP Next Hop.
その後、パケットをBGPの次のホップにトンネリングする必要があります。
If the backbone supports MPLS, this is done as follows:
バックボーンがMPLSをサポートしている場合、これは次のように行われます。
- The PE routers (and any Autonomous System border routers) that redistribute VPN-IPv4 addresses need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. To ensure interoperability among different implementations, it is required to support LDP for setting up the label switched paths across the backbone. However, other methods of setting up these label switched paths are also possible. (Some of these other methods may not require the presence of the /32 address prefixes in the IGP.)
- VPN-IPV4アドレスを再配布するPEルーター（および自律システムの境界ルーター）は、バックボーンのIGPルーティングテーブルに自分自身のアドレスプレフィックスを挿入する必要があります。これにより、Backboneネットワークの各ノードでMPLSが各PEルーターに対応するラベルを割り当てることができます。さまざまな実装間の相互運用性を確保するには、バックボーンを横切るラベルスイッチされたパスをセットアップするためにLDPをサポートする必要があります。ただし、これらのラベルスイッチされたパスを設定する他の方法も可能です。（これらの他の方法のいくつかは、IGPに /32アドレスプレフィックスの存在を必要としない場合があります。）
- If there are any traffic engineering tunnels to the BGP next hop, and if one or more of those is available for use by the packet in question, one of these tunnels is chosen. This tunnel will be associated with an MPLS label, the "tunnel label". The tunnel label gets pushed on the MPLS label stack, and the packet is forwarded to the tunnel's next hop.
- BGPの次のホップにトラフィックエンジニアリングトンネルがあり、問題のパケットが使用できる場合、これらのトンネルの1つが選択されます。このトンネルは、MPLSラベル「トンネルラベル」に関連付けられます。トンネルラベルはMPLSラベルスタックに押され、パケットはトンネルの次のホップに転送されます。
- Otherwise,
- さもないと、
* The packet will have an "IGP Next Hop", which is the next hop along the IGP route to the BGP Next Hop.
* パケットには「IGP Next Hop」があります。これは、BGP Next HopへのIGPルートに沿った次のホップです。
* If the BGP Next Hop and the IGP Next Hop are the same, and if penultimate hop popping is used, the packet is then sent to the IGP Next Hop, carrying only the VPN route label.
* BGP Next HopとIGP Next Hopが同じであり、最後から2番目のホップポップを使用する場合、パケットはIGP Next Hopに送信され、VPNルートラベルのみを運びます。
* Otherwise, the IGP Next Hop will have assigned a label for the route that best matches the address of the BGP Next Hop. Call this the "tunnel label". The tunnel label gets pushed on as the packet's top label. The packet is then forwarded to the IGP Next Hop.
* それ以外の場合、IGP Next Hopは、BGP Next Hopのアドレスに最適なルートにラベルを割り当てます。これを「トンネルラベル」と呼びます。トンネルラベルは、パケットのトップラベルとして押し出されます。パケットは、IGP Next Hopに転送されます。
- MPLS will then carry the packet across the backbone to the BGP Next Hop, where the VPN label will be examined.
- MPLSは、バックボーンを介してパケットをBGP Next Hopに運び、VPNラベルを調べます。
If the backbone does not support MPLS, the MPLS packet carrying only the VPN route label may be tunneled to the BGP Next Hop using the techniques of [MPLS-in-IP-GRE]. When the packet emerges from the tunnel, it will be at the BGP Next Hop, where the VPN route label will be examined.
バックボーンがMPLSをサポートしていない場合、VPNルートラベルのみを運ぶMPLSパケットは、[MPLS-in-IP-GRE]の手法を使用してBGP Next Hopにトンネル化される場合があります。トンネルからパケットが出現すると、VPNルートラベルが検査されるBGP Next Hopになります。
At the BGP Next Hop, the treatment of the packet depends on the VPN route label (see Section 4.3.2). In many cases, the PE will be able to determine, from this label, the attachment circuit over which the packet should be transmitted (to a CE device), as well as the proper data link layer header for that interface. In other cases, the PE may only be able to determine that the packet's destination address needs to be looked up in a particular VRF before being forwarded to a CE device. There are also intermediate cases in which the VPN route label may determine the packet's egress attachment circuit, but a lookup (e.g., ARP) still needs to be done in order to determine the packet's data link header on that attachment circuit.
BGP次のホップでは、パケットの処理はVPNルートラベルに依存します（セクション4.3.2を参照）。多くの場合、PEは、このラベルから、パケットを（CEデバイスに）送信する必要があるアタッチメント回路と、そのインターフェイスの適切なデータリンクレイヤーヘッダーを決定できます。それ以外の場合、PEは、CEデバイスに転送する前に、特定のVRFでパケットの宛先アドレスを調べる必要があることのみを判断できる場合があります。また、VPNルートラベルがパケットの出口アタッチメント回路を決定できる中間ケースもありますが、そのアタッチメント回路のパケットのデータリンクヘッダーを決定するために、検索（たとえばARP）を実行する必要があります。
Information in the MPLS header itself, and/or information associated with the label, may also be used to provide QoS on the interface to the CE.
MPLSヘッダー自体の情報、および/またはラベルに関連する情報も、CEへのインターフェイス上のQoSを提供するためにも使用できます。
In any event, if the packet was an unlabeled IP packet when it arrived at its ingress PE, it will again be an unlabeled packet when it leaves its egress PE.
いずれにせよ、パケットがIngress PEに到達したときに無効なIPパケットであった場合、出口PEを離れると再び無効なパケットになります。
The fact that packets with VPN route labels are tunneled through the backbone is what makes it possible to keep all the VPN routes out of the P routers. This is crucial to ensuring the scalability of the scheme. The backbone does not even need to have routes to the CEs, only to the PEs.
VPNルートラベルを備えたパケットがバックボーンにトンネルされているという事実は、すべてのVPNルートをPルーターから排除することを可能にするものです。これは、スキームのスケーラビリティを確保するために重要です。バックボーンは、PESにのみCESへのルートを持つ必要さえありません。
With respect to the tunnels, it is worth noting that this specification:
トンネルに関しては、この仕様に注目する価値があります。
- DOES NOT require that the tunnels be point-to-point; multipoint-to-point can be used;
- トンネルがポイントツーポイントであることを必要としません。Multipoint-to-Pointを使用できます。
- DOES NOT require that there be any explicit setup of the tunnels, either via signaling or via manual configuration;
- シグナリングまたは手動構成を介して、トンネルの明示的なセットアップがあることを必要としません。
- DOES NOT require that there be any tunnel-specific signaling;
- トンネル固有のシグナル伝達があることを必要としません。
- DOES NOT require that there be any tunnel-specific state in the P or PE routers, beyond what is necessary to maintain the routing information and (if used) the MPLS label information.
- ルーティング情報を維持するために必要なものを超えて、MPLSラベル情報を（使用する場合）、PまたはPEルーターにトンネル固有の状態があることを要求しません。
Of course, this specification is compatible with the use of point-to-point tunnels that must be explicitly configured and/or signaled, and in some situations there may be reasons for using such tunnels.
もちろん、この仕様は、明示的に構成および/または信号をかけなければならないポイントツーポイントトンネルの使用と互換性があり、状況によってはそのようなトンネルを使用する理由があるかもしれません。
The considerations that are relevant to choosing a particular tunneling technology are outside the scope of this specification.
特定のトンネル技術の選択に関連する考慮事項は、この仕様の範囲外です。
To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a tunneled packet from outside the backbone, unless it is sure that both endpoints of that tunnel are outside the backbone.
あるVPNの別のVPNの適切な分離を維持するために、バックボーンのルーターがバックボーンの外側からトンネルパケットを受け入れないことが重要です。
If MPLS is being used as the tunneling technology, this means that a router in the backbone MUST NOT accept a labeled packet from any adjacent non-backbone device unless the following two conditions hold:
MPLSがトンネリングテクノロジーとして使用されている場合、これは、バックボーンのルーターが、次の2つの条件が保持されない限り、隣接する非銀行デバイスからラベル付きパケットを受け入れてはならないことを意味します。
1. the label at the top of the label stack was actually distributed by that backbone router to that non-backbone device, and
1. ラベルスタックの上部にあるラベルは、実際にそのバックボーンルーターによってその非銀行デバイスに配布され、
2. the backbone router can determine that use of that label will cause the packet to leave the backbone before any labels lower in the stack will be inspected, and before the IP header will be inspected.
2. バックボーンルーターは、そのラベルを使用すると、スタック内のラベルが低くなる前に、IPヘッダーが検査される前に、パケットがバックボーンを離れることを決定できます。
The first condition ensure that any labeled packets received from non-backbone routers have a legitimate and properly assigned label at the top of the label stack. The second condition ensures that the backbone routers will never look below that top label. Of course, the simplest way to meet these two conditions is just to have the backbone devices refuse to accept labeled packets from non-backbone devices.
最初の条件では、非骨折ルーターから受信したラベルパケットが、ラベルスタックの上部に正当で適切に割り当てられたラベルを持つことを保証します。2番目の条件により、バックボーンルーターがそのトップレーベルの下を見ることができないことを保証します。もちろん、これらの2つの条件を満たす最も簡単な方法は、バックボーンデバイスに非バックボーンデバイスからのラベル付きパケットを受け入れることを拒否することです。
If MPLS is not being used as the tunneling technology, then filtering must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can be accepted into the backbone only if the packet's IP destination address will cause it to be sent outside the backbone.
MPLSがトンネリングテクノロジーとして使用されていない場合、PacketのIP宛先アドレスがそれを引き起こす場合にのみ、MPLS-IN-IPまたはMPLS-in-GRE-in-GRE-in-GRE-in-GRE-in-GRE-in-GREパケットがバックボーンに受け入れられるようにフィルタリングを行う必要がありますバックボーンの外に送られます。
The PE routers that attach to a particular VPN need to know, for each attachment circuit leading to that VPN, which of the VPN's addresses should be reached over that attachment circuit.
特定のVPNに接続するPEルーターは、そのVPNに通じるアタッチメント回路ごとに、VPNのアドレスのどれがそのアタッチメント回路に到達する必要があるかを知る必要があります。
The PE translates these addresses into VPN-IPv4 addresses, using a configured RD. The PE then treats these VPN-IPv4 routes as input to BGP. Routes from a VPN site are NOT leaked into the backbone's IGP.
PEは、これらのアドレスを構成されたRDを使用してVPN-IPV4アドレスに変換します。PEは、これらのVPN-IPV4ルートをBGPへの入力として扱います。VPNサイトからのルートは、バックボーンのIGPに漏れていません。
Exactly which PE/CE route distribution techniques are possible depends on whether or not a particular CE is in a "transit VPN". A "transit VPN" is one that contains a router that receives routes from a "third party" (i.e., from a router that is not in the VPN, but is not a PE router) and that redistributes those routes to a PE router. A VPN that is not a transit VPN is a "stub VPN". The vast majority of VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense.
正確にどのPE/CEルート分布技術が可能であるかは、特定のCEが「トランジットVPN」にあるかどうかによって異なります。「Transit VPN」とは、「サードパーティ」からルートを受信するルーター（つまり、VPNにないがPEルーターではないルーターから）を含み、それらのルートをPEルーターに再配置するルーターを含むものです。トランジットVPNではないVPNは「スタブVPN」です。ほぼすべての企業エンタープライズネットワークを含むVPNの大部分は、この意味で「スタブ」になると予想されます。
The possible PE/CE distribution techniques are:
可能なPE/CE分布技術は次のとおりです。
1. Static routing (i.e., configuration) may be used. (This is likely to be useful only in stub VPNs.)
1. 静的ルーティング（つまり、構成）を使用できます。（これは、スタブVPNSでのみ役立つ可能性があります。）
2. PE and CE routers may be Routing Information Protocol (RIP) [RIP] peers, and the CE may use RIP to tell the PE router the set of address prefixes that are reachable at the CE router's site. When RIP is configured in the CE, care must be taken to ensure that address prefixes from other sites (i.e., address prefixes learned by the CE router from the PE router) are never advertised to the PE. More precisely: if a PE router, say, PE1, receives a VPN-IPv4 route R1, and as a result distributes an IPv4 route R2 to a CE, then R2 must not be distributed back from that CE's site to a PE router, say, PE2, (where PE1 and PE2 may be the same router or different routers), unless PE2 maps R2 to a VPN-IPv4 route that is different than (i.e., contains a different RD than) R1.
2. PEおよびCEルーターは、情報情報プロトコル（RIP）[RIP]ピアをルーティングしている場合があり、CEはRIPを使用して、CEルーターのサイトで到達可能なアドレスプレフィックスのセットをPEルーターに伝えることができます。RIPがCEで構成されている場合、他のサイトからのアドレスプレフィックス（つまり、PEルーターからCEルーターによって学習されたアドレスプレフィックス）がPEに宣伝されないことを確認するために注意する必要があります。より正確には、PEルーター、たとえばPE1がVPN-IPV4ルートR1を受信し、その結果、IPv4ルートR2をCEに分配する場合、R2をそのCEのサイトからPEルーターに分布させてはなりません。、、PE2（PE1とPE2は同じルーターまたは異なるルーターである場合があります）。PE2はR2をR2とは異なる（つまり、RDとは異なるRDが含まれている）VPN-IPV4ルートにマッピングしない限り。
3. The PE and CE routers may be OSPF peers. A PE router that is an OSPF peer of a CE router appears, to the CE router, to be an area 0 router. If a PE router is an OSPF peer of CE routers that are in distinct VPNs, the PE must of course be running multiple instances of OSPF.
3. PEルーターとCEルーターはOSPFピアである場合があります。CEルーターのOSPFピアであるPEルーターが、CEルーターに、エリア0ルーターになります。PEルーターが異なるVPNにあるCEルーターのOSPFピアである場合、もちろんPEはOSPFの複数のインスタンスを実行する必要があります。
IPv4 routes that the PE learns from the CE via OSPF are redistributed into BGP as VPN-IPv4 routes. Extended Community attributes are used to carry, along with the route, all the information needed to enable the route to be distributed to other CE routers in the VPN in the proper type of OSPF Link State Advertisement (LSA). OSPF route tagging is used to ensure that routes received from the MPLS/BGP backbone are not sent back into the backbone.
PEがOSPFを介してCEから学習するIPv4ルートは、VPN-IPV4ルートとしてBGPに再配布されます。拡張されたコミュニティ属性は、ルートとともに、適切なタイプのOSPFリンク状態広告（LSA）でVPNの他のCEルーターにルートを配布できるようにするために必要なすべての情報を運ぶために使用されます。OSPFルートタグ付けは、MPLS/BGPバックボーンから受け取ったルートがバックボーンに送り返されないようにするために使用されます。
Specification of the complete set of procedures for the use of OSPF between PE and CE can be found in [VPN-OSPF] and [OSPF-2547-DNBIT].
PEとCEの間でOSPFを使用するための完全な一連の手順セットの仕様は、[VPN-OSPF]と[OSPF-2547-DNBIT]にあります。
4. The PE and CE routers may be BGP peers, and the CE router may use BGP (in particular, EBGP to tell the PE router the set of address prefixes that are at the CE router's site. (This technique can be used in stub VPNs or transit VPNs.)
4. PEルーターとCEルーターはBGPピアである可能性があり、CEルーターはBGPを使用できます（特に、EBGPはCEルーターのサイトにあるアドレスプレフィックスのセットをPEルーターに伝えます（この手法は、スタブVPNまたはスタブVPNまたは使用できます。トランジットVPNS。）
This technique has a number of advantages over the others:
この手法には、他の手法よりも多くの利点があります。
a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs.
a) IGPの代替品とは異なり、これは、複数のCEと通信するために、PEが複数のルーティングアルゴリズムインスタンスを実行する必要はありません。
b) BGP is explicitly designed for just this function: passing routing information between systems run by different administrations.
b) BGPは、この関数のためだけに明示的に設計されています。さまざまな管理者によって実行されるシステム間でルーティング情報を渡すことです。
c) If the site contains "BGP backdoors", i.e., routers with BGP connections to routers other than PE routers, this procedure will work correctly in all circumstances. The other procedures may or may not work, depending on the precise circumstances.
c) サイトに「BGPバックドア」、つまりPEルーター以外のルーターにBGP接続を備えたルーターが含まれている場合、この手順はあらゆる状況で正しく機能します。他の手順は、正確な状況に応じて機能する場合と機能しない場合があります。
d) Use of BGP makes it easy for the CE to pass attributes of the routes to the PE. A complete specification of the set of attributes and their use is outside the scope of this document. However, some examples of the way this may be used are the following:
d) BGPを使用すると、CEがルートの属性をPEに簡単に渡すことができます。属性のセットの完全な仕様とその使用は、このドキュメントの範囲外です。ただし、これを使用する方法のいくつかの例は次のとおりです。
- The CE may suggest a particular Route Target for each route, from among the Route Targets that the PE is authorized to attach to the route. The PE would then attach only the suggested Route Target, rather than the full set. This gives the CE administrator some dynamic control of the distribution of routes from the CE.
- CEは、PEがルートに付着することが許可されているルートターゲットの中から、各ルートの特定のルートターゲットを提案する場合があります。PEは、フルセットではなく、提案されたルートターゲットのみを取り付けます。これにより、CE管理者は、CEからのルートの分布をある程度動的に制御できます。
- Additional types of Extended Community attributes may be defined, where the intention is to have those attributes passed transparently (i.e., without being changed by the PE routers) from CE to CE. This would allow CE administrators to implement additional route filtering, beyond that which is done by the PEs. This additional filtering would not require coordination with the SP.
- 追加の種類の拡張されたコミュニティ属性が定義される場合があります。ここでは、これらの属性をCEからCEまで透過的に（つまり、PEルーターによって変更されることなく）渡されることが意図されています。これにより、CE管理者は、PESによって行われるものを超えて、追加のルートフィルタリングを実装できます。この追加のフィルタリングでは、SPとの調整は必要ありません。
On the other hand, using BGP may be something new for the CE administrators.
一方、BGPを使用することは、CE管理者にとって新しいものです。
If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin attribute (see below).
サイトがトランジットVPNにない場合は、一意の自律システム番号（ASN）が必要ではないことに注意してください。サイトがトランジットにないすべてのCEは、同じasnを使用できます。これは、プライベートASNスペースから選択でき、PEによって剥ぎ取られます。ルーティングループは、原点属性のサイトを使用することにより防止されます（以下を参照）。
What if a set of sites constitutes a transit VPN? This will generally be the case only if the VPN is itself an Internet Service Provider's (ISP's) network, where the ISP is itself buying backbone services from another SP. The latter SP may be called a "carrier's carrier". In this case, the best way to provide the VPN is to have the CE routers support MPLS, and to use the technique described in Section 9.
一連のサイトがトランジットVPNを構成する場合はどうなりますか？これは通常、VPN自体がインターネットサービスプロバイダー（ISP）ネットワークである場合にのみ当てはまります。これは、ISP自体が別のspからバックボーンサービスを購入しています。後者のSPは、「キャリアのキャリア」と呼ばれる場合があります。この場合、VPNを提供する最良の方法は、CEルーターにMPLSをサポートさせ、セクション9で説明した手法を使用することです。
When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes that exist at a given site, we will simply say that the PE has "learned" the routes from that site. This includes the case where the PE has been manually configured with the routes.
特定のサイトに存在するアドレスプレフィックスをPEに通知できるさまざまな方法を区別する必要がない場合、PEがそのサイトからルートを「学習」したと言うだけです。これには、PEがルートで手動で構成されている場合が含まれます。
Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign a Route Target attribute (see Section 4.3.1) to the route, and it may assign a Site of Origin attribute to the route.
PEがサイトから学習したVPN-IPV4ルートを再配布する前に、ルートにルートターゲット属性（セクション4.3.1を参照）をルートに割り当てる必要があり、ルートに原点属性のサイトを割り当てることができます。
The Site of Origin attribute, if used, is encoded as a Route Origin Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to uniquely identify the set of routes learned from a particular site. This attribute is needed in some cases to ensure that a route learned from a particular site via a particular PE/CE connection is not distributed back to the site through a different PE/CE connection. It is particularly useful if BGP is being used as the PE/CE protocol, but different sites have not been assigned distinct ASNs.
Origin属性のサイトは、使用する場合、ルートオリジン拡張コミュニティ[BGP-Extcomm]としてエンコードされます。この属性の目的は、特定のサイトから学習したルートのセットを一意に識別することです。この属性は、特定のPE/CE接続を介して特定のサイトから学習したルートが別のPE/CE接続を介してサイトに分散されないことを確認するために必要です。BGPがPE/CEプロトコルとして使用されている場合に特に役立ちますが、異なるサイトには異なるASNが割り当てられていません。
In this section, we assume that the CE device is a router.
このセクションでは、CEデバイスがルーターであると仮定します。
If the PE places a particular route in the VRF it uses to route packets received from a particular CE, then in general, the PE may distribute that route to the CE. Of course, the PE may distribute that route to the CE only if this is permitted by the rules of the PE/CE protocol. (For example, if a particular PE/CE protocol has "split horizon", certain routes in the VRF cannot be redistributed back to the CE.) We add one more restriction on the distribution of routes from PE to CE: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site.
PEが特定のルートをVRFに配置する場合、特定のCEから受信したパケットをルーティングするために使用する場合、一般に、PEはそのルートをCEに分配する場合があります。もちろん、PEは、これがPE/CEプロトコルのルールによって許可されている場合にのみ、CEへのルートを配布する場合があります。（たとえば、特定のPE/CEプロトコルに「Horizon」が分割されている場合、VRFの特定のルートをCEに再配布することはできません。）PEからCEへのルートの分布にもう1つの制限を追加します。Origin属性の特定のサイトを識別します。そのルートは、そのサイトでCEに再配布されてはなりません。
In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site that does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.)
ただし、ほとんどの場合、PEがデフォルトルートをCEに単純に配布するだけで十分です。（場合によっては、CEがPEを指すデフォルトルートでCEを構成するだけで十分かもしれません。）これは通常、デフォルトルートを他のサイトに配布する必要がないサイトで機能します。（たとえば、企業のVPNの1つのサイトが企業のインターネットへのアクセスを持っている場合、そのサイトでは他のサイトにデフォルトを配布する必要があるかもしれませんが、そのサイト自体にデフォルトを配布することはできません。）
Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE.
CEからPEにルートを配布するために使用される手順は、PEからCEにルートを配布するためにも使用されます。
Sometimes a VPN may actually be the network of an ISP, with its own peering and routing policies. Sometimes a VPN may be the network of an SP that is offering VPN services in turn to its own customers. VPNs like these can also obtain backbone service from another SP, the "carrier's carrier", using essentially the same methods described in this document. However, it is necessary in these cases that the CE routers support MPLS. In particular:
VPNは、実際にはISPのネットワークであり、独自のピアリングおよびルーティングポリシーを備えている場合があります。VPNは、VPNサービスを自社の顧客に提供しているSPのネットワークである場合があります。このようなVPNは、このドキュメントで説明されている同じ方法を使用して、別のSPである「キャリアのキャリア」からバックボーンサービスを取得することもできます。ただし、これらの場合、CEルーターがMPLをサポートすることが必要です。特に：
- The CE routers should distribute to the PE routers ONLY those routes that are internal to the VPN. This allows the VPN to be handled as a stub VPN.
- CEルーターは、VPNの内部のルートのみをPEルーターに分配する必要があります。これにより、VPNをスタブVPNとして処理できます。
- The CE routers should support MPLS, in that they should be able to receive labels from the PE routers, and send labeled packets to the PE routers. They do not need to distribute labels of their own, though.
- CEルーターは、PEルーターからラベルを受け取り、ラベル付きパケットをPEルーターに送信できるように、MPLSをサポートする必要があります。ただし、独自のラベルを配布する必要はありません。
- The PE routers should distribute, to the CE routers, labels for the routes they distribute to the CE routers.
- PEルーターは、CEルーターに分配され、CEルーターに配布するルートのラベルを配布する必要があります。
The PE must not distribute the same label to two different CEs unless one of the following conditions holds:
次の条件のいずれかが保持されない限り、PEは2つの異なるCESに同じラベルを配布してはなりません。
* The two CEs are associated with exactly the same set of VRFs;
* 2つのCEは、VRFのまったく同じセットに関連付けられています。
* The PE maintains a different Incoming Label Map ([MPLS-ARCH]) for each CE.
* PEは、各CEに対して異なる着信ラベルマップ（[MPLS-ARCH]）を維持します。
Further, when the PE receives a labeled packet from a CE, it must verify that the top label is one that was distributed to that CE.
さらに、PEがCEからラベル付きパケットを受信する場合、トップレーベルがそのCEに配布されたものであることを確認する必要があります。
- Routers at the different sites should establish BGP connections among themselves for the purpose of exchanging external routes (i.e., routes that lead outside of the VPN).
- さまざまなサイトのルーターは、外部ルート（つまり、VPNの外側につながるルート）を交換する目的で、自分自身の間にBGP接続を確立する必要があります。
- All the external routes must be known to the CE routers.
- すべての外部ルートは、CEルーターに知られている必要があります。
Then when a CE router looks up a packet's destination address, the routing lookup will resolve to an internal address, usually the address of the packet's BGP next hop. The CE labels the packet appropriately and sends the packet to the PE. The PE, rather than looking up the packet's IP destination address in a VRF, uses the packet's top MPLS label to select the BGP next hop. As a result, if the BGP next hop is more than one hop away, the top label will be replaced by two labels, a tunnel label and a VPN route label. If the BGP next hop is one hop away, the top label may be replaced by just the VPN route label. If the ingress PE is also the egress PE, the top label will just be popped. When the packet is sent from its egress PE to a CE, the packet will have one fewer MPLS labels than it had when it was first received by its ingress PE.
次に、CEルーターがパケットの宛先アドレスを検索すると、ルーティングルックアップは内部アドレス（通常はパケットのBGP次のホップのアドレス）に解決します。CEはパケットを適切にラベル付けし、パケットをPEに送信します。PEは、VRFでパケットのIP宛先アドレスを調べるのではなく、PacketのトップMPLSラベルを使用してBGP Next Hopを選択します。その結果、BGP Next Hopが1つ以上離れている場合、トップラベルは2つのラベル、トンネルラベルとVPNルートラベルに置き換えられます。BGPの次のホップが1つのホップである場合、トップラベルはVPNルートラベルのみに置き換えることができます。イングレスPEが出口PEである場合、トップレーベルがポップされます。パケットが出口のPEからCEに送信されると、パケットは、Ingress PEによって最初に受信されたときよりも1つのMPLSラベルが少なくなります。
In the above procedure, the CE routers are the only routers in the VPN that need to support MPLS. If, on the other hand, all the routers at a particular VPN site support MPLS, then it is no longer required that the CE routers know all the external routes. All that is required is that the external routes be known to whatever routers are responsible for putting the label stack on a hitherto unlabeled packet and that there be label switched path that leads from those routers to their BGP peers at other sites. In this case, for each internal route that a CE router distributes to a PE router, it must also distribute a label.
上記の手順では、CEルーターは、MPLSをサポートする必要があるVPNの唯一のルーターです。一方、特定のVPNサイトのすべてのルーターがMPLSをサポートする場合、CEルーターがすべての外部ルートを知っていることはもはや必要ありません。必要なのは、外部ルートがラベルスタックをこれまでのラベルのないパケットに置く責任があるルーターに知られていること、およびそれらのルーターから他のサイトのBGPピアにつながるラベルスイッチ付きパスがあることです。この場合、CEルーターがPEルーターに分散する各内部ルートについて、ラベルも分散する必要があります。
What if two sites of a VPN are connected to different Autonomous Systems (e.g., because the sites are connected to different SPs)? The PE routers attached to that VPN will then not be able to maintain IBGP connections with each other, or with a common route reflector. Rather, there needs to be some way to use EBGP to distribute VPN-IPv4 addresses.
VPNの2つのサイトが異なる自律システムに接続されている場合（たとえば、サイトが異なるSPに接続されているため）。そのVPNに接続されたPEルーターは、IBGP接続を互いに維持できない場合、または共通のルートリフレクターでは維持できません。むしろ、EBGPを使用してVPN-IPV4アドレスを配布する方法が必要です。
There are a number of different ways of handling this case, which we present in order of increasing scalability.
このケースを処理する方法はさまざまな方法がありますが、これをスケーラビリティを向上させる順に提示します。
a) VRF-to-VRF connections at the AS (Autonomous System) border routers.
a) AS（自律システム）境界ルーターでのVRFからVRF接続。
In this procedure, a PE router in one AS attaches directly to a PE router in another. The two PE routers will be attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from AS to AS. Each PE will treat the other as if it were a CE router. That is, the PEs associate each such sub-interface with a VRF, and use EBGP to distribute unlabeled IPv4 addresses to each other.
この手順では、1つのPEルーターが別の手順のPEルーターに直接取り付けられます。2つのPEルーターは、ルートをASから渡す必要があるVPNごとに少なくとも1つずつ複数のサブインターフェイスで取り付けられます。各PEは、それがCEルーターであるかのように相手を扱います。つまり、PESはそのようなサブインターフェイスをそれぞれVRFに関連付け、EBGPを使用して、非標識IPv4アドレスを相互に配布します。
This is a procedure that "just works", and that does not require MPLS at the border between ASes. However, it does not scale as well as the other procedures discussed below.
これは「ただ機能する」手順であり、ASEの境界線でMPLSを必要としません。ただし、以下で説明する他の手順と同様にスケーリングしません。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.
b) ASから隣接するASからの標識VPN-IPV4ルートのEBGP再分布。
In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them, and so on.
この手順では、PEルーターはIBGPを使用して、ラベル付きVPN-IPV4ルートを自律システムボーダールーター（ASBR）、またはASBRがクライアントであるルートリフレクターに再配布します。ASBRはEBGPを使用して、ラベル付きVPN-IPV4ルートを別のASBRに再配布します。これにより、ASのPEルーターに分配されます。
When using this procedure, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet, or from any BGP peers that are not trusted. An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer.
この手順を使用する場合、VPN-IPV4ルートは、SPS間の信頼できる配置の一部として、プライベートピアリングポイントでのEBGP接続でのみ受け入れられる必要があります。VPN-IPV4ルートは、パブリックインターネット、または信頼されていないBGPピアに配布したり、受け入れたりするべきではありません。ASBRは、実際にトップレーベルをそのピアに配布していない限り、EBGPピアからラベル付きパケットを受け入れないでください。
If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes that holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.
さまざまな自律システムに接続されたサイトを持っている多くのVPNがある場合、すべてのVPNのすべてのルートを保持する2つのASEの間に単一のASBRが必要ではありません。複数のASBRがあり、それぞれがVPNSの特定のサブセットのルートのみを保持しています。
This procedure requires that there be a label switched path leading from a packet's ingress PE to its egress PE. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Also, there must be agreement among the set of SPs as to which border routers need to receive routes with which Route Targets.
この手順では、パケットの侵入PEから出口PEまでのラベルスイッチ付きパスがあることが必要です。したがって、適切な信頼関係は、パスに沿った一連のASEの間に存在する必要があります。また、SPSのセット間で、どのルートターゲットを使用して境界ルーターがルートを受信する必要があるかについて一致する必要があります。
c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS.
c) ソースASと宛先ASEの間のラベル付きVPN-IPV4ルートのマルチホップEBGPの再分布、ASから隣接するASからのラベル付きIPv4ルートのEBGP再分布。
In this procedure, VPN-IPv4 routes are neither maintained nor distributed by the ASBRs. An ASBR must maintain labeled IPv4 /32 routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled /32 routes. This results in the creation of a label switched path from the ingress PE router to the egress PE router. Now PE routers in different ASes can establish multi-hop EBGP connections to each other, and can exchange VPN-IPv4 routes over those connections.
この手順では、VPN-IPV4ルートはASBRによって維持も分布もありません。ASBRは、AS内のPEルーターへのラベル付きIPv4 /32ルーターを維持する必要があります。EBGPを使用して、これらのルートを他のASEに分配します。任意の輸送ASESのASBRは、eBGPを使用してラベル付き /32ルートに沿って渡す必要があります。これにより、イングレスPEルーターから出口PEルーターにスイッチされたパスを切り替えたラベルが作成されます。さまざまなASEのPEルーターが互いにマルチホップEBGP接続を確立することができ、それらの接続でVPN-IPV4ルートを交換できます。
If the /32 routes for the PE routers are made known to the P routers of each AS, everything works normally. If the /32 routes for the PE routers are NOT made known to the P routers (other than the ASBRs), then this procedure requires a packet's ingress PE to put a three-label stack on it. The bottom label is assigned by the egress PE, corresponding to the packet's destination address in a particular VRF. The middle label is assigned by the ASBR, corresponding to the /32 route to the egress PE. The top label is assigned by the ingress PE's IGP Next Hop, corresponding to the /32 route to the ASBR.
PEルーターの /32ルーターがそれぞれのPルーターに知られている場合、すべてが正常に機能します。PEルーターの /32ルートがPルーター（ASBR以外の）に知られていない場合、この手順では、3つのラベルスタックを置くためにパケットのイングレスPEが必要です。下のラベルは、特定のVRFのパケットの宛先アドレスに対応する出口PEによって割り当てられます。中央のラベルは、出口PEへの /32ルートに対応するASBRによって割り当てられます。トップラベルは、ASBRへの /32ルートに対応するIngress PEのIGP Next Hopによって割り当てられます。
To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) The actual PE routers would then only have IBGP connections to the route reflectors in their own AS.
スケーラビリティを向上させるために、マルチホップEBGP接続を1つのASのルートリフレクターと別のルートリフレクターの間にのみ存在することができます。（ただし、ルートリフレクターがこの接続の上にルートを配布する場合、ルートのBGP次のホップ属性を変更しません。）実際のPEルーターは、IBGP接続がルートリフレクターにのみ独自のASになります。
This procedure is very similar to the "carrier's carrier" procedures described in Section 9. Like the previous procedure, it requires that there be a label switched path leading from a packet's ingress PE to its egress PE.
この手順は、セクション9で説明されている「キャリアのキャリア」手順に非常に似ています。以前の手順と同様に、パケットのイングレスPEから出口PEにつながるラベルの切り替えパスが必要です。
Many VPN sites will need to be able to access the public Internet, as well as to access other VPN sites. The following describes some of the alternative ways of doing this.
多くのVPNサイトは、パブリックインターネットにアクセスしたり、他のVPNサイトにアクセスできる必要があります。以下は、これを行う別の方法のいくつかについて説明しています。
1. In some VPNs, one or more of the sites will obtain Internet access by means of an "Internet gateway" (perhaps a firewall) attached to a non-VRF interface to an ISP. The ISP may or may not be the same organization as the SP that is providing the VPN service. Traffic to/from the Internet gateway would then be routed according to the PE router's default forwarding table.
1. 一部のVPNでは、1つ以上のサイトがISPへの非VRFインターフェイスに接続された「インターネットゲートウェイ」（おそらくファイアウォール）を使用してインターネットアクセスを取得します。ISPは、VPNサービスを提供しているSPと同じ組織である場合と同じである場合があります。インターネットゲートウェイとの間のトラフィックは、PEルーターのデフォルト転送テーブルに従ってルーティングされます。
In this case, the sites that have Internet access may be distributing a default route to their PEs, which in turn redistribute it to other PEs and hence into other sites of the VPN. This provides Internet access for all of the VPN's sites.
この場合、インターネットにアクセスできるサイトは、デフォルトルートをPESに配布している可能性があり、それが他のPESに再配分し、したがってVPNの他のサイトに再配分します。これにより、VPNのすべてのサイトにインターネットアクセスが提供されます。
In order to properly handle traffic from the Internet, the ISP must distribute, to the Internet, routes leading to addresses that are within the VPN. This is completely independent of any of the route distribution procedures described in this document. The internal structure of the VPN will in general not be visible from the Internet; such routes would simply lead to the non-VRF interface that attaches to the VPN's Internet gateway.
インターネットからのトラフィックを適切に処理するために、ISPはインターネットに、VPN内の住所につながるルートを分配する必要があります。これは、このドキュメントで説明されているルート分布手順のいずれにも完全に依存していません。VPNの内部構造は、一般にインターネットからは見えません。このようなルートは、VPNのインターネットゲートウェイに接続する非VRFインターフェイスにつながるだけです。
In this model, there is no exchange of routes between a PE router's default forwarding table and any of its VRFs. VPN route distribution procedures and Internet route distribution procedures are completely independent.
このモデルでは、PEルーターのデフォルト転送テーブルとそのVRFの間にルートの交換はありません。VPNルート分布手順とインターネットルート配布手順は完全に独立しています。
Note that although some sites of the VPN use a VRF interface to communicate with the Internet, ultimately all packets to/from the Internet traverse a non-VRF interface before leaving/entering the VPN, so we refer to this as "non-VRF Internet access".
VPNの一部のサイトはVRFインターフェイスを使用してインターネットと通信しますが、最終的にはVPNを離れる/入力する前に、インターネットとの間ですべてのパケットが非VRFインターフェイスを通過するため、これを「非VRFインターネットと呼びます」アクセス"。
Note that the PE router to which the non-VRF interface attaches does not necessarily need to maintain all the Internet routes in its default forwarding table. The default forwarding table could have as few as one route, "default", which leads to another router (probably an adjacent one) that has the Internet routes. A variation of this scheme is to tunnel packets received over the non-VRF interface from the PE router to another router, where this other router maintains the full set of Internet routes.
非VRFインターフェイスが接続するPEルーターは、必ずしもすべてのインターネットルートをデフォルトの転送テーブルに維持する必要はないことに注意してください。デフォルトの転送テーブルには、1つのルート「デフォルト」のわずかなルートを持つことができます。これにより、インターネットルートがある別のルーター（おそらく隣接するルーター）につながります。このスキームのバリエーションは、PEルーターから別のルーターまでの非VRFインターフェイスで受信されたトンネルパケットをトンネルすることです。この他のルーターは、インターネットルートの完全なセットを維持します。
2. Some VPNs may obtain Internet access via a VRF interface ("VRF Internet access"). If a packet is received by a PE over a VRF interface, and if the packet's destination address does not match any route in the VRF, then it may be matched against the PE's default forwarding table. If a match is made there, the packet can be forwarded natively through the backbone to the Internet, instead of being forwarded by MPLS.
2. 一部のVPNは、VRFインターフェイス（「VRFインターネットアクセス」）を介してインターネットアクセスを取得する場合があります。パケットがVRFインターフェイス上のPEによって受信され、パケットの宛先アドレスがVRFのルートと一致しない場合、PEのデフォルト転送テーブルと一致する場合があります。マッチが行われた場合、MPLSによって転送される代わりに、バックボーンを介してインターネットにネイティブに転送できます。
In order for traffic to flow natively in the opposite direction (from Internet to VRF interface), some of the routes from the VRF must be exported to the Internet forwarding table. Needless to say, any such routes must correspond to globally unique addresses.
トラフィックを反対方向にネイティブに（インターネットからVRFインターフェースまで）に流れるためには、VRFからのルートの一部をインターネット転送テーブルにエクスポートする必要があります。言うまでもなく、そのようなルートはグローバルに一意のアドレスに対応する必要があります。
In this scheme, the default forwarding table might have the full set of Internet routes, or it might have as little as a single default route leading to another router that does have the full set of Internet routes in its default forwarding table.
このスキームでは、デフォルトの転送テーブルには、インターネットルートの完全なセットがあるか、デフォルトの転送テーブルにインターネットルートの完全なセットがある別のルーターにつながる単一のデフォルトルートと同じくらいほとんどない場合があります。
3. Suppose the PE has the capability to store "non-VPN routes" in a VRF. If a packet's destination address matches a "non-VPN route", then the packet is transmitted natively, rather than being transmitted via MPLS. If the VRF contains a non-VPN default route, all packets for the public Internet will match it, and be forwarded natively to the default route's next hop. At that next hop, the packets' destination addresses will be looked up in the default forwarding table, and may match more specific routes.
3. PEがVRFに「非VPNルート」を保存する機能があるとします。パケットの宛先アドレスが「非VPNルート」と一致する場合、MPLSを介して送信されるのではなく、パケットがネイティブに送信されます。VRFに非VPNデフォルトルートが含まれている場合、パブリックインターネット用のすべてのパケットがそれと一致し、デフォルトルートの次のホップにネイティブに転送されます。その次のホップでは、パケットの宛先アドレスがデフォルトの転送テーブルで検索され、より具体的なルートと一致する場合があります。
This technique would only be available if none of the CE routers is distributing a default route.
この手法は、CEルーターがデフォルトのルートを配布していない場合にのみ使用できます。
4. It is also possible to obtain Internet access via a VRF interface by having the VRF contain the Internet routes. Compared with model 2, this eliminates the second lookup, but it has the disadvantage of requiring the Internet routes to be replicated in each such VRF.
4. また、VRFにインターネットルートを含めることにより、VRFインターフェイスを介してインターネットアクセスを取得することもできます。モデル2と比較して、これにより2回目のルックアップが排除されますが、インターネットルートをそのような各VRFで複製することを要求するという不利な点があります。
If this technique is used, the SP may want to make its interface to the Internet be a VRF interface, and to use the techniques of Section 4 to distribute Internet routes, as VPN-IPv4 routes, to other VRFs.
この手法を使用する場合、SPはインターネットへのインターフェースをVRFインターフェイスにし、セクション4の手法を使用して、VPN-IPV4ルートとしてインターネットルートを他のVRFに配布することを望む場合があります。
It should be clearly understood that by default, there is no exchange of routes between a VRF and the default forwarding table. This is done ONLY upon agreement between a customer and an SP, and only if it suits the customer's policies.
デフォルトでは、VRFとデフォルトの転送テーブルとの間にルートの交換がないことを明確に理解する必要があります。これは、顧客とSPの間の合意により、および顧客のポリシーに適している場合にのみ行われます。
This specification does not require that the sub-interface connecting a PE router and a CE router be a "numbered" interface. If it is a numbered interface, this specification allows the addresses assigned to the interface to come from either the address space of the VPN or the address space of the SP.
この仕様では、PEルーターとCEルーターを接続するサブインターフェイスが「番号付き」インターフェイスであることを必要としません。番号付きインターフェイスの場合、この仕様により、インターフェイスに割り当てられたアドレスがVPNのアドレススペースまたはSPのアドレス空間から来ることができます。
If a CE router is being managed by the Service Provider, then the Service Provider will likely have a network management system that needs to be able to communicate with the CE router. In this case, the addresses assigned to the sub-interface connecting the CE and PE routers should come from the SP's address space, and should be unique within that space. The network management system should itself connect to a PE router (more precisely, be at a site that connects to a PE router) via a VRF interface. The address of the network management system will be exported to all VRFs that are associated with interfaces to CE routers that are managed by the SP. The addresses of the CE routers will be exported to the VRF associated with the network management system, but not to any other VRFs.
CEルーターがサービスプロバイダーによって管理されている場合、サービスプロバイダーには、CEルーターと通信できる必要があるネットワーク管理システムがある可能性があります。この場合、CEルーターとPEルーターを接続するサブインターフェイスに割り当てられたアドレスは、SPのアドレス空間から来る必要があり、そのスペース内で一意である必要があります。ネットワーク管理システム自体は、VRFインターフェイスを介してPEルーター（より正確には、PEルーターに接続するサイトにある）に接続する必要があります。ネットワーク管理システムのアドレスは、SPによって管理されるCEルーターへのインターフェイスに関連付けられているすべてのVRFにエクスポートされます。CEルーターのアドレスは、ネットワーク管理システムに関連付けられたVRFにエクスポートされますが、他のVRFにはエクスポートされません。
This allows communication between the CE and network management system, but does not allow any undesired communication to or among the CE routers.
これにより、CEとネットワーク管理システム間の通信が可能になりますが、CEルーターへの、またはCEルーター間の望ましくない通信は許可されません。
One way to ensure that the proper route import/exports are done is to use two Route Targets; call them T1 and T2. If a particular VRF interface attaches to a CE router that is managed by the SP, then that VRF is configured to:
適切なルートインポート/エクスポートが行われることを確認する1つの方法は、2つのルートターゲットを使用することです。それらをT1とT2と呼びます。特定のVRFインターフェイスがSPによって管理されるCEルーターに接続されている場合、そのVRFは次のように構成されています。
- import routes that have T1 attached to them, and
- T1が取り付けられたルートをインポートし、
- attach T2 to addresses assigned to each end of its VRF interfaces.
- VRFインターフェイスの各端に割り当てられたアドレスにT2を取り付けます。
If a particular VRF interface attaches to the SP's network management system, then that VRF is configured to attach T1 to the address of that system, and to import routes that have T2 attached to them.
特定のVRFインターフェイスがSPのネットワーク管理システムに接続されている場合、そのVRFはT1をそのシステムのアドレスに取り付けるように構成され、T2がそれらに取り付けられたルートをインポートするように構成されます。
By security in the "data plane", we mean protection against the following possibilities:
「データプレーン」のセキュリティにより、次の可能性に対する保護を意味します。
- Packets from within a VPN travel to a site outside the VPN, other than in a manner consistent with the policies of the VPN.
- VPN内からのパケットは、VPNのポリシーと一致する方法を除いて、VPNの外側のサイトに移動します。
- Packets from outside a VPN enter one of the VPN's sites, other than in a manner consistent with the policies of the VPN.
- VPNの外部からのパケットは、VPNのポリシーと一致する方法を除いて、VPNのサイトの1つを入力します。
Under the following conditions:
次の条件下で：
1. a backbone router does not accept labeled packets over a particular data link, unless it is known that that data link attaches only to trusted systems, or unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected, and
1. バックボーンルーターは、データリンクが信頼できるシステムにのみ添付されていることがわかっている場合、またはそのようなパケットがIPヘッダーの前にバックボーンを離れることがわかっていない場合がある場合、特定のデータリンクに対するラベル付きパケットを受け入れません。スタックが検査されます
2. labeled VPN-IPv4 routes are not accepted from untrusted or unreliable routing peers,
2. ラベル付きVPN-IPV4ルートは、信頼できないまたは信頼できないルーティングピアから受け入れられません。
3. no successful attacks have been mounted on the control plane,
3. コントロールプレーンに成功した攻撃は取り付けられていません。
the data plane security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones. If the devices under the control of the SP are properly configured, data will not enter or leave a VPN unless authorized to do so.
このアーキテクチャによって提供されるデータプレーンのセキュリティは、フレームリレーまたはATMバックボーンによってVPNSに提供されるものとほぼ同じです。SPの制御下にあるデバイスが適切に構成されている場合、データは許可されていない限り、VPNを入力または離れることはありません。
Condition 1 above can be stated more precisely. One should discard a labeled packet received from a particular neighbor unless one of the following two conditions holds:
上記の条件1は、より正確に述べることができます。次の2つの条件のいずれかが保持されない限り、特定の隣人から受信したラベルの付いたパケットを廃棄する必要があります。
- the packet's top label has a label value that the receiving system has distributed to that neighbor, or
- パケットのトップレーベルには、受信システムがその隣人に配布したラベル値があります。
- the packet's top label has a label value that the receiving system has distributed to a system beyond that neighbor (i.e., when it is known that the path from the system to which the label was distributed to the receiving system may be via that neighbor).
- パケットのトップレーベルには、受信システムがその隣接を超えたシステムに分散しているラベル値があります（つまり、ラベルが受信システムに配布されているシステムからのパスがその隣にある可能性があることがわかっている場合）。
Condition 2 above is of most interest in the case of inter-provider VPNs (see Section 10). For inter-provider VPNs constructed according to scheme b) of Section 10, condition 2 is easily checked. (The issue of security when scheme (c) of Section 10 is used is for further study.)
上記の条件2は、プロバイダー間VPNSの場合に最も興味深いものです（セクション10を参照）。セクション10のスキームb）に従って構築されたプロバイダー間VPNの場合、条件2は簡単に確認できます。（セクション10のスキーム（c）が使用される場合のセキュリティの問題は、さらなる研究のためです。）
It is worth noting that the use of MPLS makes it much simpler to provide data plane security than might be possible if one attempted to use some form of IP tunneling in place of the MPLS outer label. It is a simple matter to have one's border routers refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure a router to refuse to accept an IP packet if that packet is an IP tunneled packet whose destination address is that of a PE router; certainly, this is not impossible to do, but it has both management and performance implications.
MPLSを使用すると、MPLSの外側ラベルの代わりに何らかの形のIPトンネリングを使用しようとした場合よりも、データプレーンのセキュリティを提供するのがはるかに簡単になることは注目に値します。上記の条件の最初の条件が適用されない限り、ボーダールーターにラベル付きパケットを受け入れることを拒否することは簡単な問題です。そのパケットが宛先アドレスがPEルーターのアドレスであるIPトンネルパケットである場合、IPパケットの受け入れを拒否するようにルーターを構成することはかなり困難です。確かに、これは不可能ではありませんが、管理とパフォーマンスの両方の意味合いがあります。
MPLS-in-IP and MPLS-in-GRE tunneling are specified in [MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN packets, then the security considerations described in Section 8 of that document must be fully understood. Any implementation of BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described in that document MUST contain an implementation of IPsec that can be used as therein described. If the tunnel is not secured by IPsec, then the technique of IP address filtering at the border routers, described in Section 8.2 of that document, is the only means of ensuring that a packet that exits the tunnel at a particular egress PE was actually placed in the tunnel by the proper tunnel head node (i.e., that the packet does not have a spoofed source address). Since border routers frequently filter only source addresses, packet filtering may not be effective unless the egress PE can check the IP source address of any tunneled packet it receives, and compare it to a list of IP addresses that are valid tunnel head addresses. Any implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the egress PE to validate in this manner the IP source address of any tunneled packet that it receives.
MPLS-in-IPおよびMPLS-in-greトンネリングは、[MPLS-in-IP-GRE]で指定されています。そのようなトンネルを使用してVPNパケットを運ぶことが望ましい場合は、そのドキュメントのセクション8で説明したセキュリティに関する考慮事項を完全に理解する必要があります。そのドキュメントで説明されているように、VPNパケットをトンネル化できるBGP/MPLS IP VPNの実装は、説明されているように使用できるIPSECの実装を含める必要があります。トンネルがIPSECによって固定されていない場合、そのドキュメントのセクション8.2で説明されているボーダールーターでのIPアドレスフィルタリングの手法は、特定の出口PEでトンネルを出るパケットが実際に配置されたことを保証する唯一の手段です。適切なトンネルヘッドノードによるトンネルでは（つまり、パケットにスプーフィングされたソースアドレスがないこと）。ボーダールーターは頻繁にソースアドレスのみをフィルタリングするため、出力PEが受信したトンネルパケットのIPソースアドレスを確認し、有効なトンネルヘッドアドレスであるIPアドレスのリストと比較できない限り、パケットフィルタリングは効果的ではない場合があります。IPSECなしでMPLS-in-IPおよび/またはMPLS-in-greのトンネリングを使用できるようにする実装は、出力PEが受信したトンネルパケットのIPソースアドレスをこの方法で検証できるようにする必要があります。
In the case where a number of CE routers attach to a PE router via a LAN interface, to ensure proper security, one of the following conditions must hold:
多数のCEルーターがLANインターフェイスを介してPEルーターに付着し、適切なセキュリティを確保する場合、次の条件の1つを保持する必要があります。
1. All the CE routers on the LAN belong to the same VPN, or
1. LAN上のすべてのCEルーターは同じVPNに属します、または
2. A trusted and secured LAN switch divides the LAN into multiple VLANs, with each VLAN containing only systems of a single VPN; in this case, the switch will attach the appropriate VLAN tag to any packet before forwarding it to the PE router.
2. 信頼できるセキュリティで保護されたLANスイッチは、LANを複数のVLANに分割し、各VLANには単一のVPNのシステムのみが含まれています。この場合、スイッチはPEルーターに転送する前に、適切なVLANタグを任意のパケットに接続します。
Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired.
暗号化のプライバシーは、このアーキテクチャによっても、フレームリレーまたはATM VPNによっても提供されません。これらのアーキテクチャはすべて、必要に応じて、CE-CEベースで暗号化の使用と互換性があります。
The use of cryptography on a PE-PE basis is for further study.
PE-PEベースで暗号化の使用は、さらなる研究のためです。
The data plane security of the previous section depends on the security of the control plane. To ensure security, neither BGP nor LDP connections should be made with untrusted peers. The TCP/IP MD5 authentication option [TCP-MD5] should be used with both these protocols. The routing protocol within the SP's network should also be secured in a similar manner.
前のセクションのデータプレーンのセキュリティは、制御プレーンのセキュリティに依存します。セキュリティを確保するために、BGPもLDP接続も信頼できないピアで行うべきではありません。TCP/IP MD5認証オプション[TCP-MD5]は、これらの両方のプロトコルで使用する必要があります。SPのネットワーク内のルーティングプロトコルも同様の方法で保護する必要があります。
If the physical security of these devices is compromised, data plane security may also be compromised.
これらのデバイスの物理的なセキュリティが侵害された場合、データプレーンのセキュリティも損なわれる可能性があります。
The usual steps should be taken to ensure that IP traffic from the public Internet cannot be used to modify the configuration of these devices, or to mount Denial of Service attacks on them.
これらのデバイスの構成を変更するために、またはそれらへのサービス拒否攻撃をマウントするために、パブリックインターネットからのIPトラフィックを使用できないようにするために、通常の手順を実行する必要があります。
Although not the focus of this paper, Quality of Service is a key component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [MPLS-RSVP] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish label switched paths with particular QoS characteristics between particular pairs of sites, if that is desirable. Where an MPLS/BGP VPN spans multiple SPs, the architecture described in [PASTE] may be useful. An SP may apply either intserv (Integrated Services) or diffserv (Differentiated Services) capabilities to a particular VPN, as appropriate.
このペーパーの焦点ではありませんが、サービス品質はVPNサービスの重要な要素です。MPLS/BGP VPNSでは、Shimヘッダー[MPLS-Encaps]の「実験的」ビットを使用して、既存のL3 QoS機能をラベル付きパケットに適用できます。QoS機能。[MPLS-RSVP]で議論されているトラフィックエンジニアリング作業は、MPLS/BGP VPNSにも直接適用できます。トラフィックエンジニアリングを使用して、特定のサイトのペア間で特定のQoS特性を持つラベルスイッチ付きパスを確立することもできます。MPLS/BGP VPNが複数のSPSにまたがる場合、[ペースト]で説明されているアーキテクチャが役立つ場合があります。SPは、必要に応じて、特定のVPNにINTSERV（統合サービス）またはDIFFSERV（差別化サービス）機能を適用できます。
We have discussed scalability issues throughout this paper. In this section, we briefly summarize the main characteristics of our model with respect to scalability.
この論文全体でスケーラビリティの問題について説明しました。このセクションでは、スケーラビリティに関してモデルの主な特性を簡単に要約します。
The Service Provider backbone network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (that are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.
サービスプロバイダーのバックボーンネットワークは、（a）PEルーター、（b）BGPルートリフレクター、（c）Pルーター（PEルーターもルートリフレクターもありません）、およびマルチプロバイダーVPNSの場合（D）で構成されています。ASBRS。
P routers do not maintain any VPN routes. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. The use of two levels of labeling is what makes it possible to keep the VPN routes out of the P routers.
PルーターはVPNルートを維持しません。VPNトラフィックを適切に転送するには、PルーターはPEルーターとASBRへのルートのみを維持する必要があります。2つのレベルの標識を使用することは、VPNルートをPルーターから締め出すことを可能にするものです。
A PE router maintains VPN routes, but only for those VPNs to which it is directly attached.
PEルーターはVPNルートを維持しますが、それが直接接続されているVPNのみです。
Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs supported by the Service Provider. Thus, no single route reflector is required to maintain routes for all VPNs.
ルートリフレクターをVPN間でパーティション化することができ、各パーティションがサービスプロバイダーによってサポートされるVPNのサブセットのみのルートのみを運ぶことができます。したがって、すべてのVPNのルートを維持するために、単一のルートリフレクターは必要ありません。
For inter-provider VPNs, if the ASBRs maintain and distribute VPN-IPv4 routes, then the ASBRs can be partitioned among VPNs in a similar manner, with the result that no single ASBR is required to maintain routes for all the inter-provider VPNs. If multi-hop EBGP is used, then the ASBRs need not maintain and distribute VPN-IPv4 routes at all.
プロバイダー間VPNの場合、ASBRがVPN-IPV4ルートを維持および配布する場合、ASBRは同様の方法でVPN間で分割でき、その結果、すべてのプロバイダー間VPNのルートを維持するために単一のASBRが必要ありません。マルチホップEBGPを使用する場合、ASBRはVPN-IPV4ルートをまったく維持および配布する必要はありません。
As a result, no single component within the Service Provider network has to maintain all the routes for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
その結果、サービスプロバイダーネットワーク内の単一のコンポーネントは、すべてのVPNのすべてのルートを維持する必要はありません。したがって、VPNの数の増加をサポートするネットワークの総容量は、個々のコンポーネントの容量によって制限されません。
The Internet Assigned Numbers Authority (IANA) has created a new registry for the "Route Distinguisher Type Field" (see Section 4.2). This is a two-byte field. Types 0, 1, and 2 are defined by this document. Additional Route Distinguisher Type Field values with a high-order bit of 0 may be allocated by IANA on a "First Come, First Served" basis [IANA]. Values with a high-order bit of 1 may be allocated by IANA based on "IETF consensus" [IANA].
インターネットが割り当てられた番号局（IANA）は、「ルート違いフィールド」の新しいレジストリを作成しました（セクション4.2を参照）。これは2バイトのフィールドです。タイプ0、1、および2は、このドキュメントで定義されています。高次ビット0の追加ルートの識別器タイプのフィールド値は、「First Come、First Sever」ベース[IANA]でIANAによって割り当てられる場合があります。1の高次ビットの値は、「IETFコンセンサス」[IANA]に基づいてIANAによって割り当てられる場合があります。
This document specifies (see Section 4.3.4) the use of the BGP Address Family Identifier (AFI) value 1, along with the BGP Subsequent Address Family Identifier (SAFI) value 128, to represent the address family "VPN-IPv4 Labeled Addresses", which is defined in this document.
このドキュメントは、BGPアドレスファミリ識別子（AFI）値1の使用を指定します。、このドキュメントで定義されています。
The use of AFI value 1 for IP is as currently specified in the IANA registry "Address Family Identifier", so IANA need take no action with respect to it.
IPのAFI値1の使用は、IANAレジストリ「アドレスファミリ識別子」で現在指定されているとおりであるため、IANAはそれに関して措置を講じる必要はありません。
The SAFI value 128 was originally specified as "Private Use" in the IANA "Subsequent Address Family Identifier" registry. IANA has changed the SAFI value 128 from "private use" to "MPLS-labeled VPN address".
Safi Value 128は、もともとIANAの「プライベート使用」として指定されていました。IANAは、SAFI値128を「プライベート使用」から「MPLS標識VPNアドレス」に変更しました。
The full list of contributors can be found in Section 18.
貢献者の完全なリストは、セクション18にあります。
Significant contributions to this work have also been made by Ravi Chandra, Dan Tappan, and Bob Thomas.
この作業への多大な貢献は、ラビ・チャンドラ、ダン・タッパン、ボブ・トーマスによっても行われています。
We also wish to thank Shantam Biswas for his review and contributions.
また、Shantam Biswasのレビューと貢献についても感謝したいと思います。
Tony Bogovic Telcordia Technologies 445 South Street, Room 1A264B Morristown, NJ 07960
Tony Bogovic Telcordia Technologies 445 South Street、Room 1A264B Morristown、NJ 07960
EMail: tjb@research.telcordia.com
Stephen John Brannon Swisscom AG Postfach 1570 CH-8301 Glattzentrum (Zuerich), Switzerland
スティーブン・ジョン・ブラノン・スイスコムAG POSTFACH 1570 CH-8301 GLATTZENTRUM（ZUERICH）、スイス
EMail: stephen.brannon@swisscom.com
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE
EMail: marco.carugi@nortelnetworks.com
Christopher J. Chase AT&T 200 Laurel Ave Middletown, NJ 07748 USA
クリストファーJ.チェイスAT＆T 200ローレルアベニューミドルタウン、ニュージャージー07748 USA
EMail: chase@att.com
Ting Wo Chung Bell Nexxia 181 Bay Street Suite 350 Toronto, Ontario M5J2T3
Ting Wo Chung Bell Nexxia 181 Bay Street Suite 350 Toronto、Ontario M5J2T3
EMail: ting_wo.chung@bellnexxia.com
Eric Dean
エリック・ディーン
Jeremy De Clercq Alcatel Network Strategy Group Francis Wellesplein 1 2018 Antwerp, Belgium
Jeremy de Clercq Alcatel Network Strategy Group Francis Wellesplein 1 2018 Antwerp、ベルギー
EMail: jeremy.de_clercq@alcatel.be
Luyuan Fang AT&T IP Backbone Architecture 200 Laurel Ave. Middletown, NJ 07748
Luyuan Fang AT＆T IP Backbone Architecture 200 Laurel Ave. Middletown、NJ 07748
EMail: luyuanfang@att.com
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK
EMail: paul.hitchen@bt.com
Manoj Leelanivas Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 USA
Manoj Leelanivas Juniper Networks、Inc。385 Ravendale Drive Mountain View、CA 94043 USA
EMail: manoj@juniper.net
Dave Marshall Worldcom 901 International Parkway Richardson, Texas 75081
デイブマーシャルワールドコム901インターナショナルパークウェイリチャードソン、テキサス75081
EMail: dave.marshall@wcom.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112
EMail: lmartini@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-com, 2nd floor CH-8301 Glattzentrum, Switzerland
Monique Jeanne Morrow Cisco Systems、Inc。Glatt-Com、2階のCH-8301グラッツェントラム、スイス
EMail: mmorrow@cisco.com
Ravichander Vaidyanathan
Telcordia Technologies
445 South Street, Room 1C258B
Morristown, NJ 07960
EMail: vravi@research.telcordia.com
Adrian Smith BT BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK
Adrian Smith Bt Bt Adastral Park Martlesham Heath、Ipswich IP5 3RE UK
EMail: adrian.ca.smith@bt.com
Vijay Srinivasan 1200 Bridge Parkway Redwood City, CA 94065
Vijay Srinivasan 1200 Bridge Parkway Redwood City、CA 94065
EMail: vsriniva@cosinecom.com
Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis, Cedex, France
Alain Vedrenne Equant Heraklion、1041 Route Des Dolines、Bp347 06906 Sophia Antipolis、Cedex、France
EMail: Alain.Vedrenne@equant.com
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y。およびT. Li、「Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-EXTCOMM] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities属性」、RFC 4360、2006年2月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP] Rekhter、Y。およびE. Rosen、「BGP-4でのラベル情報の運搬」、RFC 3107、2001年5月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number Space", Work in Progress, March 2004.
[BGP-AS4] Vohra、Q。およびE. Chen、「数値スペースとしての4-OCTETのBGPサポート」、2004年3月、進行中の作業。
[BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004.
[BGP-ORF] Chen、E。およびY. Rekhter、「BGP-4の協同ルートフィルタリング機能」、2004年3月、進行中の作業。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RFSH] Chen、E。、「BGP-4のルートリフレッシュ機能」、RFC 2918、2000年9月。
[BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[BGP -RR] Bates、T.、Chandra、R。、およびE. Chen、「BGPルートリフレクション - フルメッシュIBGPの代替」、RFC 2796、2000年4月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS-ATM] Davie、B.、Lawrence、J.、McCloghrie、K.、Rosen、E.、Swallow、G.、Rekhter、Y.、およびP. Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC 3035、2001年1月。
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., and C. Sargor, "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in Progress, March 2004.
[MPLS/BGP-IPSEC] Rosen、E.、De Clercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、 "BGP/MPLSでのPE-PE IPSECトンネルの使用のためのアーキテクチャIP VPNS "、2004年3月、進行中の作業。
[MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-FR] Conta、A.、Doolan、P。、およびA. Malis、「フレームリレーネットワーク仕様のラベルスイッチングの使用」、RFC 3034、2001年1月。
[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-in-IP-GRE] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[MPLS-RSVP] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[Paste] Li、T。およびY. Rekhter、「差別化されたサービスと交通工学のプロバイダーアーキテクチャ（ペースト）」、RFC 2430、1998年10月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Work in Progress, March 2004.
[OSPF-2547-DNBIT] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「LSAオプションビットを使用してBGP/MPLS IP VPNSでのループを防ぐ」、2004年3月の作業。
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[TCP-MD5] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-Mcast] Rosen、E.、Cai、Y。、およびJ. Wijsnands、「MPLS/BGP VPNSのマルチキャスト」、2004年5月、進行中の作業。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Work in Progress, February 2004.
[VPN-OSPF] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「BGP/MPLS VPNSのPE/CEプロトコルとしてのOSPF」、2004年2月の進行中。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089
EMail: yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。