[要約] RFC 6368は、BGP/MPLS IP仮想プライベートネットワーク（VPN）におけるプロバイダ/カスタマーエッジプロトコルとしての内部BGPの要件を定義しています。このRFCの目的は、内部BGPを使用してBGP/MPLS IP VPNを実装するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) P. Marques
Request for Comments: 6368
Category: Standards Track R. Raszuk
ISSN: 2070-1721 NTT MCL
K. Patel
Cisco Systems
K. Kumaki
T. Yamagata
KDDI Corporation
September 2011
Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLSのプロバイダー/顧客エッジプロトコルとしての内部BGP IP仮想プライベートネットワーク（VPNS）
Abstract
概要
This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned.
このドキュメントでは、BGP/MPLS IP VPNSのBGPプロバイダー/顧客エッジルーター反復のプロトコル拡張と手順を定義します。これらの拡張と手順には、ルーティング情報に関する限り、BGP/MPLS IP VPNの使用を顧客ネットワークに透過的にすることを目的としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6368.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6368で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. IP VPN as a Route Server ........................................3
4. Path Attributes .................................................5
5. BGP Customer Route Attributes ...................................6
6. Next-Hop Handling ...............................................7
7. Exchanging Routes between Different VPN Customer Networks .......8
8. Deployment Considerations ......................................10
9. Security Considerations ........................................12
10. IANA Considerations ...........................................12
11. Acknowledgments ...............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
In current deployments, when BGP is used as the Provider/Customer Edge routing protocol, these peering sessions are typically configured as an external peering between the VPN provider autonomous system (AS) and the customer network autonomous system. At each External BGP boundary, BGP path attributes [RFC4271] are modified as per standard BGP rules. This includes prepending the AS_PATH attribute with the autonomous-system number of the originating Customer Edge (CE) router and the autonomous-system number(s) of the Provider Edge (PE) router(s).
現在の展開では、BGPがプロバイダー/カスタマーエッジルーティングプロトコルとして使用される場合、これらのピアリングセッションは通常、VPNプロバイダーの自律システム（AS）と顧客ネットワークの自律システム間の外部ピーリングとして構成されます。各外部BGP境界では、BGPパス属性[RFC4271]が標準BGPルールに従って変更されます。これには、AS_PATH属性を、発信元の顧客エッジ（CE）ルーターの自律システム番号とプロバイダーエッジ（PE）ルーターの自律システム番号で準備することが含まれます。
In order for such routes not to be rejected by AS_PATH loop detection, a PE router advertising a route received from a remote PE often remaps the customer network autonomous-system number to its own. Otherwise, the customer network can use different autonomous-system numbers at different sites or configure their CE routers to accept routes containing their own AS number.
そのようなルートがAS_PATHループ検出によって拒否されないようにするために、PEルーターがリモートPEから受け取ったルートを宣伝するPEルーターは、顧客ネットワークの自律システム番号を独自に再マップすることがよくあります。それ以外の場合、顧客ネットワークは、異なるサイトで異なる自律システム番号を使用したり、CEルーターを設定して、独自のAS番号を含むルートを受け入れたりできます。
While this technique works well in situations where there are no BGP routing exchanges between the client network and other networks, it does have drawbacks for customer networks that use BGP internally for purposes other than interaction between CE and PE routers.
この手法は、クライアントネットワークと他のネットワークの間にBGPルーティング交換がない状況ではうまく機能しますが、CEルーターとPEルーター間の対話以外の目的でBGPを内部的に使用する顧客ネットワークの欠点があります。
In order to make the usage of BGP/MPLS VPN services as transparent as possible to any external interaction, it is desirable to define a mechanism by which PE-CE routers can exchange BGP routes by means other than External BGP.
BGP/MPLS VPNサービスの使用を外部相互作用に対して可能な限り透明にするためには、PE-CEルーターがBGP以外の手段でBGPルートを交換できるメカニズムを定義することが望ましいです。
One can consider a BGP/MPLS VPN as a provider-managed backbone service interconnecting several customer-managed sites. While this model is not universal, it does constitute a good starting point.
BGP/MPLS VPNは、いくつかの顧客管理サイトを相互接続するプロバイダー管理バックボーンサービスと見なすことができます。このモデルは普遍的ではありませんが、良い出発点を構成します。
Independently of the presence of VPN service, networks often use a hierarchical design utilizing either BGP route reflection [RFC4456] or confederations [RFC5065]. This document assumes that the IP VPN service interacts with the customer network following a similar model.
VPNサービスの存在とは無関係に、ネットワークはしばしばBGPルート反射[RFC4456]またはコンフェデレーション[RFC5065]のいずれかを使用して階層設計を使用します。このドキュメントは、IP VPNサービスが同様のモデルに従って顧客ネットワークと対話することを前提としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In a typical backbone/area hierarchical design, routers that attach an area (or site) to the core use BGP route reflection (or confederations) to distribute routes between the top-level core Internal BGP (iBGP) mesh and the local area iBGP cluster.
典型的なバックボーン/エリアの階層設計では、エリア（またはサイト）をコア使用BGPルートリフレクション（またはコンフェデレーション）に接続するルーターを使用して、トップレベルのコア内部BGP（IBGP）メッシュとローカルエリアIBGPクラスター間のルートを配布します。。
To provide equivalent functionality in a network using a provider-provisioned backbone, one can consider the VPN as the equivalent of an Internal BGP Route Server that multiplexes information from _N_ VPN attachment points.
プロバイダーがプロビジョニングされたバックボーンを使用してネットワークで同等の機能を提供するために、_N_ VPNアタッチメントポイントから情報を多重化する内部BGPルートサーバーに相当するVPNを考慮することができます。
A route learned by any of the PEs in the IP VPN is available to all other PEs that import the Route Target used to identify the customer network. This is conceptually equivalent to a centralized route server.
IP VPNのPESのいずれかによって学習されたルートは、顧客ネットワークを識別するために使用されるルートターゲットをインポートする他のすべてのPESが利用できます。これは、集中型ルートサーバーと概念的に同等です。
In a PE router, PE-received routes are not advertised back to other PEs. It is this split-horizon technique that prevents routing loops in an IP VPN environment. This is also consistent with the behavior of a top-level mesh of route reflectors (RRs).
PEルーターでは、PE受信ルートは他のPESに宣伝されていません。IP VPN環境でのルーティングループを防ぐのは、このスプリットホリゾンテクニックです。これは、ルートリフレクター（RRS）のトップレベルメッシュの動作とも一致しています。
In order to complete the Route Server model, it is necessary to be able to transparently carry the Internal BGP path attributes of customer network routes through the BGP/MPLS VPN core. This is achieved by using a new BGP path attribute, described below, that allows the customer network attributes to be saved and restored at the BGP/MPLS VPN boundaries.
ルートサーバーモデルを完了するには、BGP/MPLS VPNコアを介して顧客ネットワークルートの内部BGPパス属性を透過的に運ぶことができる必要があります。これは、以下で説明する新しいBGPパス属性を使用して達成されます。これにより、顧客ネットワーク属性をBGP/MPLS VPN境界で保存および復元できます。
When a route is advertised from PE to CE, if it is advertised as an iBGP route, the CE will not advertise it further unless it is itself configured as a route reflector (or has an External BGP session). This is a consequence of the default BGP behavior of not advertising iBGP routes back to iBGP peers. This behavior is not modified.
ルートがPEからCEに宣伝されている場合、IBGPルートとして宣伝されている場合、CEはルートリフレクターとして構成されていない限り（または外部BGPセッションがある場合）、それをさらに宣伝しません。これは、IBGPルートをIBGPピアに戻さないというデフォルトのBGP動作の結果です。この動作は変更されていません。
On a BGP/MPLS VPN PE, a CE-received route MUST be advertised to other VPN PEs that import the Route Targets that are associated with the route. This is independent of whether the CE route has been received as an external or internal route. However, a CE-received route is not re-advertised back to other CEs unless route reflection is explicitly configured. This is the equivalent of disabling client-to-client reflection in BGP route reflection implementations.
BGP/MPLS VPN PEでは、経路に関連付けられているルートターゲットをインポートするCEで推測されるルートを他のVPN PEに宣伝する必要があります。これは、CEルートが外部ルートまたは内部ルートとして受信されたかどうかに依存しません。ただし、Route Reflectionが明示的に構成されていない限り、CEで推測されるルートは他のCESに再承認されません。これは、BGPルートリフレクションの実装におけるクライアントからクライアントへの反射を無効にすることに相当します。
When reflection is configured on the PE router, with local CE routers as clients, there is no need to internally mesh multiple CEs that may exist in the site.
ローカルCEルーターをクライアントとしてPEルーターで構成する場合、サイトに存在する可能性のある複数のCEを内部的にメッシュする必要はありません。
This Route Server model can also be used to support a confederation-style abstraction to CE devices. At this point, we choose not to describe in detail the procedures for that mode of operation. Confederations are considered to be less common than route reflection in enterprise environments.
このルートサーバーモデルは、CEデバイスへの連合スタイルの抽象化をサポートするためにも使用できます。この時点で、その動作モードの手順を詳細に説明しないことを選択します。コンフェデレーションは、エンタープライズ環境でのルート反射よりも一般的ではないと考えられています。
--> push path attributes --> vrf-export --> BGP/MPLS IP VPN
VRF route PE-PE route
advertisement
<-- pop path attributes <-- vrf-import <--
The diagram above shows the BGP path attribute stack processing in relation to existing BGP/MPLS IP VPN [RFC4364] route processing procedures. BGP path attributes received from a customer network are pushed into the stack, before adding the Export Route Targets to the BGP path attributes. Conversely, the stack is popped following the Import Target processing step that identifies the VPN Routing and Forwarding (VRF) table in which a PE-received route is accepted.
上の図は、既存のBGP/MPLS IP VPN [RFC4364]ルート処理手順に関連するBGPパス属性スタック処理を示しています。顧客ネットワークから受信したBGPパス属性は、BGPパス属性にエクスポートルートターゲットを追加する前に、スタックに押し込まれます。逆に、PEが受信したルートが受け入れられるVPNルーティングと転送（VRF）テーブルを識別するインポートターゲット処理ステップに従ってスタックがポップされます。
When the advertising PE performs a "push" operation at the "vrf-export" processing stage, it SHOULD initialize the attributes of the BGP IP VPN route advertisement as it would for a locally originated route from the respective VRF context.
広告PEが「VRF-Export」処理段階で「プッシュ」操作を実行すると、BGP IP VPNルート広告の属性を初期化する必要があります。
When a PE-received route is imported into a VRF, its IGP metric, as far as BGP path selection is concerned, SHOULD be the metric to the remote PE address, expressed in terms of the service provider metric domain.
PEが受信したルートがVRFにインポートされる場合、BGPパスの選択に関する限り、IGPメトリックは、サービスプロバイダーメトリックドメインで表されるリモートPEアドレスのメトリックである必要があります。
For the purposes of VRF route selection performed at the PE, between routes received from local CEs and remote PEs, customer network IGP metrics SHOULD always be considered higher (and thus least preferred) than local site metrics.
PEで実行されるVRFルート選択の目的、ローカルCESから受け取ったルートとリモートPESの間で、顧客ネットワークIGPメトリックは、ローカルサイトメトリックよりも常に高い（したがって最小限の優先）と見なされるべきです。
When backdoor links are present, this would tend to direct the traffic between two sites through the backdoor link for BGP routes originated by a remote site. However, BGP already has policy mechanisms, such as the LOCAL_PREF attribute, to address this type of situation.
バックドアリンクが存在する場合、これにより、リモートサイトが発信するBGPルートのバックドアリンクを介して2つのサイト間のトラフィックを向ける傾向があります。ただし、BGPには、このタイプの状況に対処するために、local_pref属性などのポリシーメカニズムが既にあります。
When a given CE is connected to more than one PE, it will not advertise the route that it receives from a PE to another PE unless configured as a route reflector, due to the standard BGP route advertisement rules.
特定のCEが複数のPEに接続されている場合、標準のBGPルート広告ルールのために、ルートリフレクターとして構成されていない限り、PEから別のPEへのルートを宣伝しません。
When a CE reflects a PE-received route to another PE, the fact that the original attributes of a route are preserved across the VPN prevents the formation of routing loops due to mutual redistribution between the two networks.
CEが別のPEへのPE推定ルートを反映している場合、VPN全体にルートの元の属性が保存されているという事実は、2つのネットワーク間の相互の再分配によりルーティングループの形成を防ぎます。
In order to transparently carry the BGP path attributes of customer routes, this document defines a new BGP path attribute:
顧客ルートのBGPパス属性を透過的に運ぶために、このドキュメントは新しいBGPパス属性を定義します。
ATTR_SET (type code 128)
attr_set（タイプコード128）
ATTR_SET is an optional transitive attribute that carries a set of BGP path attributes. An attribute set (ATTR_SET) can include any BGP attribute that can occur in a BGP UPDATE message, except for the MP_REACH and MP_UNREACH attributes.
ATTR_SETは、一連のBGPパス属性を搭載するオプションの推移的属性です。属性セット（ATTR_SET）には、MP_REACHおよびMP_UNREACH属性を除き、BGP更新メッセージで発生する可能性のあるBGP属性を含めることができます。
The ATTR_SET attribute is encoded as follows:
attr_set属性は次のようにエンコードされます。
+------------------------------+
| Attr Flags (O|T) Code = 128 |
+------------------------------+
| Attr. Length (1 or 2 octets) |
+------------------------------+
| Origin AS (4 octets) |
+------------------------------+
| Path Attributes (variable) |
+------------------------------+
The Attribute Flags are encoded according to RFC 4271 [RFC4271]. The Extended Length bit determines whether the Attribute Length is one or two octets.
属性フラグは、RFC 4271 [RFC4271]に従ってエンコードされます。拡張された長さビットは、属性の長さが1つまたは2つのオクテットであるかどうかを決定します。
The attribute value consists of a 4-octet "Origin AS" value followed by a variable-length field that conforms to the BGP UPDATE message path attribute encoding rules. The length of this attribute is 4 plus the total length of the encoded attributes.
属性値は、「値として4オクターテットの「Origin」で構成され、その後にBGP更新メッセージパス属性エンコードルールに準拠する可変長さフィールドが続きます。この属性の長さは、エンコードされた属性の合計長さ4に加えています。
The ATTR_SET attribute is used by a PE router to store the original set of BGP attributes it receives from a CE. When a PE router advertises a PE-received route to a CE, it will use the path attributes carried in the ATTR_SET attribute.
attr_set属性は、PEルーターによって使用されて、CEから受信するBGP属性の元のセットを保存します。PEルーターがCEへのPE受信ルートを宣伝すると、attr_set属性に掲載されたパス属性が使用されます。
In other words, the BGP path attributes are "pushed" into this attribute, which operates as a stack, when the route is received by the VPN and "popped" when the route is advertised in the PE-to-CE direction.
言い換えれば、BGPパス属性は、ルートがVPNによって受信され、ルートがPE-To-CE方向に宣伝されると「ポップ」したときにスタックとして動作するこの属性に「プッシュ」されます。
Using this mechanism isolates the customer network from the attributes used in the customer network and vice versa. Attributes such as the route reflection cluster list attribute are segregated such that customer network cluster identifiers won't be considered by the customer network route reflectors and vice versa.
このメカニズムを使用すると、顧客ネットワークが顧客ネットワークで使用されている属性から分離され、その逆も同様です。ルートリフレクションクラスターリスト属性などの属性は分離され、顧客ネットワーククラスター識別子が顧客ネットワークルートリフレクターによって考慮されないようにし、その逆も同様です。
The Origin autonomous-system number is designed to prevent a route originating in a given autonomous-system iBGP from being leaked into a different autonomous system without proper AS_PATH manipulation. It SHOULD contain the autonomous-system number of the customer network that originates the given set of attributes. The value is encoded as a 32-bit unsigned integer in network byte order, regardless of whether or not the originating PE supports 4-octet AS numbers [RFC4893].
Origin Autonomous-System Numberは、特定の自律システムIBGPに由来するルートが、適切なAS_PATH操作なしに異なる自律システムに漏れなくなるのを防ぐように設計されています。指定された属性セットを発信する顧客ネットワークの自律システム番号を含める必要があります。この値は、発信されるPEが数字として4-OCTETをサポートするかどうかに関係なく、ネットワークバイトの順序で32ビットの非署名整数としてエンコードされます[RFC4893]。
The AS_PATH and AGGREGATOR attributes contained within an ATTR_SET attribute MUST be encoded using 4-octet AS numbers [RFC4893], regardless of the capabilities advertised by the BGP speaker to which the ATTR_SET attribute is transmitted. BGP speakers that support the extensions defined in this document MUST also support RFC 4893 [RFC4893]. The reason for this requirement is to remove ambiguity between 2-octet and 4-octet AS_PATH attribute encoding.
ATTR_SET属性内に含まれるAS_PATHおよびアグリゲーター属性は、ATTR_SET属性が送信されるBGPスピーカーによって宣伝されている機能に関係なく、4-OCTETとして[RFC4893]として4-OCTETとしてエンコードする必要があります。このドキュメントで定義されている拡張機能をサポートするBGPスピーカーは、RFC 4893 [RFC4893]もサポートする必要があります。この要件の理由は、2-OCTETと4-OCTET AS_PATH属性エンコードの間のあいまいさを削除するためです。
The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. When present, it SHOULD be ignored by the receiving PE. Future applications of the ATTR_SET attribute MAY define meaningful semantics for an included NEXT_HOP attribute.
next_hop属性をattr_setに含めないでください。存在する場合、受信PEによって無視される必要があります。attr_set属性の将来のアプリケーションは、含まれているnext_hop属性の意味のあるセマンティクスを定義する場合があります。
The ATTR_SET attribute SHALL be considered malformed if any of the following apply:
attr_set属性は、次のいずれかが適用される場合、奇形と見なされます。
o Its length is less than 4 octets.
o その長さは4オクテット未満です。
o The original path attributes carried in the variable-length attribute data include the MP_REACH or MP_UNREACH attribute.
o 変数長属性データに搭載されている元のパス属性には、MP_REACHまたはMP_UNREACH属性が含まれます。
o The included attributes are malformed themselves.
o 含まれている属性は、それ自体を奇形しています。
An UPDATE message with a malformed ATTR_SET attribute SHALL be handled as follows. If its Partial flag is set and its Neighbor-Complete flag is clear, the UPDATE is treated as a route withdraw as discussed in [OPT-TRANS-BGP]. Otherwise (i.e., Partial flag is clear or Neighbor-Complete is set), the procedures of the BGP-4 base specification [RFC4271] MUST be followed with respect to an Optional Attribute Error.
不正なattr_set属性を持つ更新メッセージは、次のように処理されなければなりません。部分フラグが設定され、近隣の完全なフラグが明確である場合、[Opt-Trans-BGP]で説明されているように、更新はルート引き出しとして扱われます。それ以外の場合（つまり、部分フラグがクリアまたは隣接コンプリートが設定されています）、BGP-4ベース仕様[RFC4271]の手順に従って、オプションの属性エラーに関して従う必要があります。
When BGP/MPLS VPNs are not in use, the NEXT_HOP attribute in iBGP routes carries the address of the border router advertising the route into the domain. The IGP distance to the NEXT_HOP of the route is an important component of BGP route selection.
BGP/MPLS VPNが使用されていない場合、IBGPルートのNext_Hop属性は、ボーダールーターのアドレスがドメインにルートを宣伝するアドレスを運びます。ルートのnext_hopまでのIGP距離は、BGPルート選択の重要なコンポーネントです。
When a BGP/MPLS VPN service is used to provide interconnection between different sites, since the customer network runs a different IGP domain, metrics between the provider and customer networks are not comparable.
BGP/MPLS VPNサービスを使用して異なるサイト間の相互接続を提供する場合、顧客ネットワークは異なるIGPドメインを実行するため、プロバイダーと顧客ネットワーク間のメトリックは匹敵しません。
However, the most important component of a metric is the inter-area metric, which is known to the customer network. The intra-area metric is typically negligible.
ただし、メトリックの最も重要なコンポーネントは、顧客ネットワークに知られているエリア間メトリックです。エリア内メトリックは通常無視できます。
The use of route reflection, for instance, requires metrics to be configured so that inter-cluster/area metrics are always greater than intra-cluster metrics.
たとえば、ルートリフレクションの使用では、クラスター間/エリアメトリックが常にクラスター内メトリックよりも大きくなるように、メトリックを構成する必要があります。
The approach taken by this document is to rewrite the NEXT_HOP attribute at the VRF import/export boundary. PE routers take into account the PE-PE IGP distance calculated by the customer network IGP, when selecting between routes advertised from different PEs.
このドキュメントで採用されたアプローチは、VRFインポート/エクスポート境界でNext_Hop属性を書き換えることです。PEルーターは、異なるPEから宣伝されているルート間で選択するときに、カスタマーネットワークIGPによって計算されたPE-PE IGP距離を考慮します。
An advantage of the proposed method is that the customer network can run independent IGPs at each site.
提案された方法の利点は、顧客ネットワークが各サイトで独立したIGPを実行できることです。
In the traditional model, where External BGP sessions are used between the BGP/MPLS VPN PE and CE, the PE router identifies itself as belonging to the customer network autonomous system.
BGP/MPLS VPN PEとCEの間で外部BGPセッションが使用されている従来のモデルでは、PEルーターは、それ自体がカスタマーネットワークの自律システムに属すると識別します。
In order to use Internal BGP sessions, the PE router has to identify itself as belonging to the customer AS. More specifically, the VRF that is used to interconnect to that customer site is assigned to the customer AS rather than the VPN provider AS.
内部BGPセッションを使用するために、PEルーターは顧客に属していると自分自身を識別する必要があります。より具体的には、その顧客サイトと相互接続するために使用されるVRFは、VPNプロバイダーとしてではなく、顧客に割り当てられます。
The Origin AS element in the ATTR_SET path attribute conveys the AS number of the originating VRF. This AS number is used in a receiving PE in order to identify route exchanges between VRFs in different ASes.
ATTR_SETパス属性の要素としての原点は、発信するVRFの数を伝えます。これは、異なるASEのVRF間のルート交換を識別するために、受信PEで使用されます。
In scenarios such as what is commonly referred to as an "extranet" VPN, routes MAY be advertised to both internal and external VPN attachments belonging to different autonomous systems.
一般に「エクストラネット」VPNと呼ばれるものなどのシナリオでは、ルートは、異なる自律システムに属する内部および外部VPNアタッチメントの両方に宣伝されます。
+-----+ +-----+
| PE1 |-----------------| PE2 |
+-----+ +-----+
/ \ |
+-----+ +-----+ +-----+
| CE1 | | CE2 | | CE3 |
+-----+ +-----+ +-----+
AS 1 AS 2 AS 1
Consider the example given above, where (PE1, CE1) and (PE2, CE3) sessions are iBGP. In BGP/MPLS VPNs, a route received from CE1 above may be distributed to the VRFs corresponding to the attachment points for CEs 2 and 3.
上記の例を考えてみましょう。ここで、（PE1、CE1）および（PE2、CE3）セッションはIBGPです。BGP/MPLS VPNSでは、上記のCE1から受信したルートは、CES 2および3のアタッチメントポイントに対応するVRFに分布できます。
The desired result in such a scenario is to present the internal peer (CE3) with a BGP advertisement that contains the same BGP path attributes received from CE1, and to present the external peer (CE2) with a BGP advertisement that would correspond to a situation where AS 1 and AS 2 have an External BGP session between them.
このようなシナリオでの望ましい結果は、CE1から受信した同じBGPパス属性を含むBGP広告を内部ピア（CE3）に提示し、外部ピア（CE2）に状況に対応するBGP広告を提示することです。ここで、1と2はそれらの間に外部BGPセッションを持っています。
In order to achieve this goal, the following set of rules applies:
この目標を達成するために、次の一連のルールが適用されます。
When importing a VPN route that contains the ATTR_SET attribute into a destination VRF, a PE router MUST check that the "Origin AS" number contained in the ATTR_SET attribute matches the autonomous system associated with the VRF.
attr_set属性を宛先VRFに含むVPNルートをインポートする場合、PEルーターは、attr_set属性に含まれる「オリジン」数がVRFに関連付けられた自律システムと一致することを確認する必要があります。
In case the autonomous-system numbers do match, the route is imported into the VRF with the attributes contained in the ATTR_SET attribute. Otherwise, in the case of an autonomous-system number mismatch, the set of attributes to be associated with the route SHALL be constructed as follows:
自律系の数値が一致した場合、attributesがattr_set属性に含まれる属性を使用して、ルートがVRFにインポートされます。それ以外の場合、自律システム数の不一致の場合、ルートに関連付けられる属性のセットは、次のように構築されなければなりません。
1. The path attributes are set to the attributes contained in the ATTR_SET attribute.
1. パス属性は、attribed_set属性に含まれる属性に設定されます。
2. iBGP-specific attributes are discarded (LOCAL_PREF, ORIGINATOR, CLUSTER_LIST, etc).
2. IBGP固有の属性は破棄されます（local_pref、originator、cluster_listなど）。
3. The "Origin AS" number contained in the ATTR_SET attribute is prepended to the AS_PATH following the rules that would apply to an External BGP peering between the source and destination ASes.
3. attr_set属性に含まれる「起源として」数は、ソースと宛先ASEの間で外部BGPのピアリングに適用されるルールに従ってAS_Pathに加えられます。
4. If the autonomous system associated with the VRF is the same as the VPN provider autonomous system and the AS_PATH attribute of the VPN route is not empty, it SHALL be prepended to the AS_PATH attribute of the VRF route.
4. VRFに関連付けられている自律システムがVPNプロバイダーの自律システムと同じであり、VPNルートのAS_PATH属性が空でない場合、VRFルートのAS_PATH属性に加えてください。
When advertising the VRF route to an External BGP peer, a PE router SHALL apply steps 1 to 4 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute. For example, if the route originated in a VRF that supports Internal BGP peering and the ATTR_SET attribute and is advertised to a CE that is configured in the traditional External BGP mode, then the originator AS, the VPN AS_PATH segment, and the customer network AS are prepended to the AS_PATH.
VRFルートを外部BGPピアに宣伝する場合、PEルーターは上記で定義された手順1〜4を適用し、その後、独自の自律システム番号をAS_PATH属性にプレイズする必要があります。たとえば、ルートが内部BGPピアリングとattr_set属性をサポートし、従来の外部BGPモードで構成されているCEに宣伝されている場合、VPN AS_PATHセグメント、および顧客ネットワークとしてオリジネーターとして宣伝されている場合AS_PATHに加えられます。
When importing a route without the ATTR_SET attribute to a VRF that is configured in a different autonomous system, a PE router MUST prepend the VPN provider AS number to the AS_PATH.
別の自律システムで構成されているVRFにattr_set属性を持たないルートをインポートする場合、PEルーターはVPNプロバイダーをAS_PATHに番号として準備する必要があります。
In all cases where a route containing the ATTR_SET attribute is imported, attributes present on the VPN route other than the NEXT_HOP attribute are ignored, both from the point of view of route selection in the VRF Adj-RIB-In and route advertisement to a CE router. In other words, the information contained in the ATTR_SET attribute overrides the VPN route attributes on "vrf-import".
ATTR_SET属性を含むルートがインポートされるすべての場合において、VRF Adj-rib-inのルート選択の観点から、CEへのルート広告の両方の点から、Next_Hop属性以外のVPNルートに存在する属性は無視されます。ルーター。言い換えれば、attr_set属性に含まれる情報は、「VRF-Import」のVPNルート属性をオーバーライドします。
It is RECOMMENDED that different VRFs of the same VPN (i.e., in different PE routers) that are configured with iBGP PE-CE peering sessions use different Route Distinguisher (RD) values. Otherwise (in the case where the same RD is used), the BGP IP VPN infrastructure may select a single BGP customer path for a given IP Network Layer Reachability Information (NLRI) without access to the detailed path information that is contained in the ATTR_SET attribute.
IBGP PE-CEピアリングセッションで構成されている同じVPN（つまり、異なるPEルーター）の異なるVRFSは、異なるルートdistiutiuseer（RD）値を使用することをお勧めします。それ以外の場合は（同じRDが使用される場合）、BGP IP VPNインフラストラクチャは、attr_set属性に含まれる詳細なパス情報にアクセスすることなく、特定のIPネットワークレイヤーリーチ可能性情報（NLRI）の単一のBGPカスタマーパスを選択できます。。
As mentioned previously, the model for this service is a "Route Server" where the IP VPN provides the customer network with all the BGP paths known by the CEs. This effectively implies the use of unique RDs per VRF.
前述のように、このサービスのモデルは、IP VPNがCESで既知のすべてのBGPパスを顧客ネットワークに提供する「ルートサーバー」です。これは、VRFあたりの一意のRDの使用を効果的に意味します。
The stated goal of this extension is to isolate the customer network from the BGP path attribute operations performed by the IP VPN and conversely isolate the service provider network from any attributes injected by the customer. For instance, BGP communities can be used to influence the behavior of the IP VPN infrastructure. Using this extension, the service provider network can transparently carry these attributes without interfering with its operations.
この拡張機能の指定された目標は、IP VPNによって実行されたBGPパス属性操作から顧客ネットワークを分離し、逆に顧客が注入した属性からサービスプロバイダーネットワークを分離することです。たとえば、BGPコミュニティを使用して、IP VPNインフラストラクチャの動作に影響を与えることができます。この拡張機能を使用して、サービスプロバイダーネットワークは、その操作を妨げることなく、これらの属性を透過的に運ぶことができます。
Another example of unwanted interaction between customer and IP VPN BGP attributes is a scenario where the same service provider autonomous-system number is used to provide Internet service as well as the IP VPN service. In this case, it is not uncommon to have a VPN customer route contain the AS number of the service provider. The IP VPN should work transparently in this case as in all others.
顧客とIP VPN BGP属性の間の不要な相互作用のもう1つの例は、同じサービスプロバイダーの自律システム番号を使用して、IP VPNサービスを提供するために使用されるシナリオです。この場合、VPNカスタマールートにサービスプロバイダーの数を含めることは珍しくありません。この場合、他のすべての場合と同様に、IP VPNは透過的に動作するはずです。
This protocol extension is designed to behave such that each PE VRF operates as a router in the configured AS. Previously, VRFs operated in the provider network AS only. The VPN backbone provides interconnection between VRFs of the same AS, as well as interconnection between different ASes (subject to the appropriate policies). When interconnecting VRFs in the same AS, the VPN backbone operates as a top-level route reflection mesh. When interconnecting VRFs in different ASes, the provider network provides an implicit peering relationship between the ASes that originate and import a specific route.
このプロトコル拡張は、各PE VRFが設定されたASのルーターとして動作するように動作するように設計されています。以前は、VRFはプロバイダーネットワークでのみ動作していました。VPNバックボーンは、同じものと同じVRF間の相互接続と、異なるASE間の相互接続を提供します（適切なポリシーの対象）。VRFを相互接続する場合、VPNバックボーンはトップレベルのルートリフレクションメッシュとして動作します。さまざまなASEでVRFを相互接続する場合、プロバイダーネットワークは、特定のルートを発生およびインポートするASEの間に暗黙のピアリング関係を提供します。
This extension is also applicable to scenarios where the VPN backbone spans multiple ASes. When the VPN backbone Inter-AS operation follows option b) or c) as defined in Section 10 of [RFC4364], the provider networks are able to influence the route attributes and route selection of the VPN routes while providing a transparent service to the customer AS. Either Internal BGP connectivity or extranets can be provided to the customer AS.
この拡張機能は、VPNバックボーンが複数のASEに及ぶシナリオにも適用されます。VPNバックボーン間AS操作がオプションb）またはc）に従うと、[RFC4364]のセクション10で定義されているように、プロバイダーネットワークは、顧客に透明なサービスを提供しながら、VPNルートのルート属性とルート選択に影響を与えることができます。なので。内部BGP接続またはエクストラネットのいずれかを顧客に提供できます。
When VPN provider networks interconnect via option a), there is no possibility of providing a fully transparent service. By definition, option a) implies that each autonomous-system border router (ASBR) has a VRF associated with the customer VPN that is configured to operate in the respective provider AS. These ASBR VRFs then communicate via External BGP with their peer provider ASes.
VPNプロバイダーネットワークがオプションa）を介して相互接続する場合、完全に透明なサービスを提供する可能性はありません。定義上、オプションa）は、各自律システムの境界ルーター（ASBR）が、それぞれのプロバイダーで動作するように構成されている顧客VPNに関連付けられたVRFを持っていることを意味します。これらのASBR VRFは、ピアプロバイダーASEと外部BGPを介して通信します。
In this case, it is still possible to have all the customer VRFs with one provider network be configured in the same customer AS. This customer AS will then peer with the provider AS implicitly at the ASBR, which will in turn peer explicitly with a second provider AS. This is not, however, a scenario in which transparency to the customer AS is possible.
この場合、1つのプロバイダーネットワークを備えたすべての顧客VRFを同じ顧客と同じ顧客で構成することはまだ可能です。この顧客は、ASBRで暗黙的にプロバイダーと一緒にピアになります。ただし、これは、可能な限り顧客への透明性のシナリオではありません。
It is worthwhile to consider the security implications of this proposal from two independent perspectives: the IP VPN provider and the IP VPN customer.
IP VPNプロバイダーとIP VPN顧客という2つの独立した観点から、この提案のセキュリティへの影響を考慮することは価値があります。
From an IP VPN provider perspective, this mechanism will assure separation between the BGP path attributes advertised by the CE router and the BGP attributes used within the provider network, thus potentially improving security.
IP VPNプロバイダーの観点から、このメカニズムは、CEルーターによって宣伝されているBGPパス属性とプロバイダーネットワーク内で使用されるBGP属性の分離を保証し、セキュリティを改善する可能性があります。
Although this behavior is largely implementation dependent, it is currently possible for a CE device to inject BGP attributes (extended communities, for example) that have semantics on the IP VPN provider network, unless explicitly disabled by configuration in the PE.
この動作は実装に大きく依存していますが、現在、CEデバイスがPEの構成によって明示的に無効にされない限り、IP VPNプロバイダーネットワーク上にセマンティクスを持つBGP属性（拡張コミュニティなど）を注入することが可能です。
With the rules specified for the ATTR_SET path attribute, any attribute that has been received from a CE is pushed into the stack before the route is advertised to other PEs.
attr_setパス属性に指定されたルールを使用すると、CEから受信された属性は、ルートが他のPESに宣伝される前にスタックに押し込まれます。
As with any other field based on values received from an external system, an implementation must consider the issues of input validation and resource management.
外部システムから受け取った値に基づく他のフィールドと同様に、実装は入力検証とリソース管理の問題を考慮する必要があります。
From the perspective of the VPN customer network, it is our opinion that there is no change to the security profile of PE-CE interaction. While having an iBGP session allows the PE to specify additional attributes not allowed on an External BGP session (e.g., LOCAL_PREF), this does not significantly change the fact that the VPN customer must trust its service provider to provide it with correct routing information.
VPNカスタマーネットワークの観点から見ると、PE-CE相互作用のセキュリティプロファイルに変更はないというのは私たちの意見です。IBGPセッションを使用すると、PEは外部BGPセッション（local_prefなど）で許可されていない追加の属性を指定できますが、これはVPN顧客が正しいルーティング情報を提供するためにサービスプロバイダーを信頼しなければならないという事実を大きく変えることはありません。
This document defines a new BGP path attribute that is part of a registry space managed by IANA. IANA has updated its BGP Path Attributes registry with the value specified above (128) for the ATTR_SET path attribute.
このドキュメントでは、IANAが管理するレジストリスペースの一部である新しいBGPパス属性を定義します。IANAは、ATTR_SETパス属性の上記（128）を指定した値でBGPパス属性レジストリを更新しました。
The authors would like to thank Stephane Litkowski and Bruno Decraene for their comments.
著者は、Stephane LitkowskiとBruno Decraeneのコメントに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[RFC4456] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、2006年4月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893] Vohra、Q。およびE. Chen、「Number Spaceとしての4オクテットのBGPサポート」、RFC 4893、2007年5月。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007.
[RFC5065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システムコンフェデレーション」、RFC 5065、2007年8月。
[OPT-TRANS-BGP] Scudder, J. and E. Chen, "Error Handling for Optional Transitive BGP Attributes", Work in Progress, September 2010.
[Opt-Trans-BGP] Scudder、J。およびE. Chen、「オプションの推移的BGP属性のエラー処理」、2010年9月、進行中の作業。
Authors' Addresses
著者のアドレス
Pedro Marques
ペドロ・マルケス
EMail: pedro.r.marques@gmail.com
Robert Raszuk NTT MCL 101 S. Ellsworth Avenue Suite 350 San Mateo, CA 94401 US
Robert Raszuk NTT MCL 101 S. Ellsworth Avenue Suite 350 San Mateo、CA 94401 US
EMail: robert@raszuk.net
Keyur Patel Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
Keyur Patel Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134 US
EMail: keyupate@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi Chiyoda-Ku、東京102-8460日本
EMail: ke-kumaki@kddi.com
Tomohiro Yamagata KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
Yamagata Kddi Corporation Garden Air Tower Iidabashi Chiyoda-Ku、東京102-8460日本
EMail: to-yamagata@kddi.com