Internet Engineering Task Force (IETF) R. Aggarwal
Request for Comments: 6515 Juniper Networks, Inc.
Updates: 6514 E. Rosen
Category: Standard Track Cisco Systems, Inc.
ISSN: 2070-1721 February 2012
IPv4 and IPv6 Infrastructure Addresses in
BGP Updates for Multicast VPN
Abstract
抽象
To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514.
マルチキャストVPN（MVPN）サービスを提供するには、プロバイダーエッジルータは、マルチキャスト-VPN（「MCAST-VPN」）BGPルートを運ぶBGPアップデートメッセージを発信します。彼らはまた、MVPN固有の属性を運ぶユニキャストVPNルートを発信します。これらのルートは、顧客のアドレス空間からアドレスだけでなく、プロバイダのアドレス空間からアドレスをエンコードします。これら2つのアドレス空間は独立しており、二つの空間のアドレスファミリー（IPv4またはIPv6）は、同じであってもなくてもよいです。これらのルートは、常に顧客のアドレスがIPv4アドレスであるかどうか、彼らがIPv6アドレスであるかどうかを指定し、「アドレスファミリ」フィールドを含みます。しかし、明示的にプロバイダのアドレスのアドレスファミリを指定する一切のフィールドがありません。相互運用性を確保するために、この文書は、プロバイダのIPv4アドレスは常に4オクテットアドレスとしてこれらの更新メッセージに符号化されていること、およびIPv4とIPv6との間の区別は、アドレス・フィールドの長さによってのみシグナリングされることを指定します。具体的な例を詳細に説明します。この文書は、RFC 6514に更新します。
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/rfc6515.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6515で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. IPv4 and IPv6 Addresses in MCAST-VPN Routes ................2
1.2. Specification of Requirements ..............................4
1.3. Acronyms Used in This Document .............................4
2. PE Addresses in MCAST-VPN Routes ................................4
3. VRF Route Import Extended Community .............................5
4. PMSI Tunnel Attributes in I-PMSI A-D Routes .....................6
4.1. Relationship to AFI Value ..................................6
4.2. Relationship to Next Hop Address Family ....................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
9. Informative References ..........................................7
[MVPN-BGP] defines a new set of BGP route types that are used by service providers (SPs) to provide Multicast Virtual Private Network service to their customers. These routes have a newly defined BGP NLRI, the "MCAST-VPN" NLRI. The MCAST-VPN NLRI is carried in the NLRI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP]. The SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to identify the NLRI as being an MCAST-VPN NLRI.
[MVPN-BGP]は、顧客にマルチキャストバーチャルプライベートネットワークサービスを提供するために、サービスプロバイダ（SPS）で使用されているBGPルートタイプの新しいセットを定義します。これらのルートは、新たに定義されたBGP NLRI、 "MCAST-VPN" NLRIを持っています。 MCAST-VPN NLRIは[BGP-MP]で定義されたMP_REACH_NLRI / MP_UNREACH_NLRI属性のNLRIフィールドで搬送されます。 MP_REACH_NLRI / MP_UNREACH_NLRI属性のSAFIフィールドはMCAST-VPN NLRIあるとしてNLRIを識別するために使用されます。
When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2. AFI 1 indicates that any customer multicast addresses occurring in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2 indicates that such addresses are IPv6 addresses.
MP_REACH_NLRI / MP_UNREACH_NLRI属性のSAFIフィールドが「MCAST-VPN」の値を有する場合、AFIフィールドは、二つの定義された値を有する：1および2 AFI 1はMP_REACH_NLRI / MP_UNREACH_NLRI属性に生じる任意の顧客マルチキャストアドレスは、IPv4アドレスであることを示しています。 AFI 2は、そのようなアドレスがIPv6アドレスであることを示しています。
However, some of the MCAST-VPN routes also contain addresses of Provider Edge (PE) routers in the SP network. An SP with an IPv4 network may provide MVPN service for customers using IPv6, and an SP with an IPv6 network may provide MVPN service for customers that use IPv4. Therefore, the address family of the PE addresses MUST NOT be inferred from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute.
しかしながら、MCAST-VPN経路のいくつかはまた、プロバイダエッジ（PE）SPネットワーク内のルータのアドレスを含みます。 IPv4ネットワークとのSPは、IPv6を使用して顧客のためのMVPNサービスを提供することができ、およびIPv6ネットワークとのSPは、IPv4を使用する顧客のためのMVPNサービスを提供することができます。したがって、PEアドレスのアドレスファミリーは、関連MP_REACH_NLRI / MP_UNREACH_NLRI属性のAFIフィールドから推測してはなりません。
The purpose of this document is to make clear that whenever a PE address occurs in an MCAST-VPN route (whether in the NLRI or in an attribute), the IP address family of that address is determined by the length of the address (a length of 4 octets for IPv4 addresses, a length of 16 octets for IPv6 addresses), NOT by the AFI field of the route.
この文書の目的は、透明PEアドレスがMCAST-VPN経路（NLRIまたは属性にかかわらず）で発生するたびに、そのアドレスのIPアドレスファミリーがアドレス（長さの長さによって決定されることを確認することですIPv4アドレスの4つのオクテットのIPv6アドレスの16オクテットの長さ）の、NOT経路のAFIフィールドによって。
In particular, if a SP with an IPv4 core network is providing MVPN/IPv6 service to a customer, the PE addresses in the MCAST-VPN routes will be 4-octet IPv4 routes, even though the AFI of those routes will have the value 2.
具体的には、IPv4のコアネットワークとSPが顧客にMVPN / IPv6サービスを提供している場合、MCAST-VPN経路におけるPEアドレスは、それらのルートのAFIは値2を有しているにもかかわらず、4オクテットのIPv4ルートであろう。
Some previous specifications (e.g., [RFC4659] and [RFC4798]) have taken a different approach, requiring that in any routes containing IPv6 or VPN-IPv6 customer addresses, the IPv4 PE addresses be represented as IPv6-mapped IPv4 addresses [RFC4291]. This document does not use that approach. Rather, this specification uses the approach adopted in [RFC4684] and [RFC5549]. The MCAST-VPN routes contain enough information to enable the IP address family of the PE addresses to be inferred from the address lengths.
いくつかの以前の仕様（例えば、[RFC4659]及び[RFC4798]）は、IPv6またはVPN-IPv6の顧客アドレスを含む任意の経路で、IPv4のPEアドレスはIPv6にマッピングされたIPv4アドレス[RFC4291]として表されることを必要と異なるアプローチをとっています。この文書では、そのアプローチを使用していません。むしろ、本明細書では[RFC4684]及び[RFC5549]に採用されたアプローチを使用します。 MCAST-VPN経路はアドレスの長さから推測されるPEアドレスのIPアドレスファミリを有効にするために十分な情報を含みます。
[MVPN-BGP] also defines an attribute, the "VRF Route Import Extended Community", that is attached to unicast VPN-IPv4 or VPN-IPv6 routes. This extended community contains a PE address, and this document specifies how to encode an IPv6 address in this attribute, independent of whether the attribute is attached to a VPN-IPv4 route or a VPN-IPv6 route.
[MVPN-BGP]はまた、そのユニキャストVPN-IPv4またはVPN-IPv6ルートに取り付けられて、属性、「VRFルートインポート拡張コミュニティ」を定義します。この拡張コミュニティは、PEのアドレスが含まれており、この文書は、属性がVPN-IPv4ルートまたはVPN-IPv6ルートに取り付けられているかどうかとは無関係に、この属性にIPv6アドレスをエンコードする方法を指定します。
This document also clarifies an issue with respect to the significance of the Address Family field of an Intra-AS I-PMSI A-D route that carries a PMSI Tunnel Attribute.
この資料はまたPMSIトンネル属性を運ぶイントラAS I-PMSI A-Dのルートのアドレスファミリフィールドの重要性に関して問題を明確にしています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses a number of acronyms, mostly taken directly from the BGP and VPN specifications.
この文書では、主にBGPおよびVPNの仕様から直接取得頭字語の数を、使用しています。
- A-D Route: Auto-Discovery Route [MVPN]
- A-Dルート：自動検出ルート[MVPN]
- AFI: Address Family Identifier [BGP-MP]
- AFI：アドレスファミリ識別子[BGP-MP]
- AS: Autonomous System [BGP]
- AS：自律システム[BGP]
- I-PMSI: Inclusive PMSI [RFC4364]
- I-PMSI：込みPMSI [RFC4364]
- MVPN: Multicast Virtual Private Network [MVPN]
- MVPN：マルチキャストバーチャルプライベートネットワーク[MVPN]
- MCAST-VPN routes: BGP routes of "MCAST-VPN" Subsequent Address Family, as defined in [MVPN-BGP]. The NLRI of such routes may be referred to as MCAST-VPN NLRI.
- MCAST-VPNルート： "MCAST-VPN" 次のアドレスファミリのBGPルート、[MVPN-BGP]で定義されます。そのような経路のNLRIはMCAST-VPN NLRIと呼ぶことができます。
- MP_REACH_NLRI: Multiprotocol Reachable NLRI [BGP-MP]
- MP_REACH_NLRI：マルチ到達可能NLRI [BGP-MP]
- MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI [BGP-MP]
- MP_UNREACH_NLRI：マルチプロトコル到達不能NLRI [BGP-MP]
- PMSI: Provider Multicast Service Interface [MVPN]
- PMSI：プロバイダマルチキャストサービスインタフェース[MVPN]
- NLRI: Network Layer Reachability Information [BGP]
- NLRI：ネットワーク層到達可能性情報[BGP]
- PE: Provider Edge [RFC4364]
- PE：プロバイダエッジ[RFC4364]
- S-PMSI: Selective PMSI [RFC4364]
- S-PMSI：選択PMSI [RFC4364]
- SAFI: Subsequent Address Field Identifier [BGP-MP]
- SAFI：次のアドレスフィールド識別子[BGP-MP]
- SP: Service Provider
- SP：サービスプロバイダ
PE addresses occur in MCAST-VPN routes in the following places:
PEアドレスは、次の場所にMCAST-VPNの経路で発生します。
1. "Network Address of Next Hop" field in the MP_REACH_NLRI attribute, as defined in Section 3 of [BGP-MP]. This field is preceded by a "length of next hop address" field. Hence, it is always clear whether the address is an IPv4 address (length is 4) or an IPv6 address (length is 16). If the length of the next hop address is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP].
[BGP-MP]のセクション3で定義されたMP_REACH_NLRI属性のフィールド、1「ネクストホップのネットワークアドレス」。このフィールドは、フィールド「ネクストホップアドレスの長さ」が先行しています。したがって、アドレスは、IPv4アドレスまたはIPv6アドレス（長さが4である）（長さは16である）であるか否かを常に明らかです。次ホップアドレスの長さは4でも16でもない場合、MP_REACH_NLRI属性が「正しくない」と見なされなければならない、そして[BGP-MP]のセクション7で指定されるように処理されなければなりません。
2. "Intra-AS I-PMSI A-D route", defined in Section 4.1 of [MVPN-BGP]. All MCAST-VPN routes begin with a 1-octet route type field, followed by a 1-octet "NLRI length" field. In the Intra-AS I-PMSI A-D route, the length is followed by an 8-octet Route Distinguisher (RD), which is then followed by the "Originating Router's IP Address" field. The length of this field (4 octets for IPv4 or 16 octets for IPv6) can thus be inferred from the NLRI length field (which will be either 12 or 24, respectively). If the inferred length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP].
2. [MVPN-BGP]のセクション4.1で定義される "イントラAS I-PMSI A-Dルート"。全てMCAST-VPNルートは1オクテット「NLRI長」フィールドに続いて、1オクテットルートタイプフィールドから始まります。イントラAS I-PMSI A-Dの経路では、長さは、次に、「発信元ルータのIPアドレス」フィールドが続く8オクテットルート識別子（RD）が続きます。このフィールド（IPv4またはIPv6の16オクテット4つのオクテット）の長さは、このように（それぞれ、12又は24のいずれかになります）NLRI長フィールドから推論することができます。 「発信側ルータのIPアドレス」フィールドの推論された長さは4でも16でもない場合は、MP_REACH_NLRI属性が「正しくない」と見なされなければならない、と[BGP-MP]のセクション7で指定されるように扱われなければなりません。
3. "S-PMSI A-D Route", defined in Section 4.3 of [MVPN-BGP]. In this route, the "NLRI length" field is followed by an 8-octet RD, a variable-length "multicast source" field, a variable-length "multicast group" field, and an "Originating Router's IP Address" field. The two variable-length fields have their own length fields. From these two length fields and the NLRI length field, one can compute the length of the "Originating Router's IP Address" field, which again is either 4 for IPv4 or 16 for IPv6. If the computed length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP].
3 MVPN-BGP]のセクション4.3で定義された "S-PMSI A-Dルート" を、。この経路では、「NLRI長さ」フィールドは8オクテットRD、可変長「マルチキャストソース」フィールド、可変長「マルチキャストグループ」フィールド、および「発信元ルータのIPアドレス」フィールドが続きます。 2可変長フィールドは、独自の長さフィールドを持っています。これらの二つの長さフィールドとNLRI長フィールドから、1は再びIPv4の4またはIPv6のための16のいずれかである「発信側ルータのIPアドレス」フィールドの長さを計算することができます。 「発信側ルータのIPアドレス」フィールドの計算された長さは4でも16でもない場合は、MP_REACH_NLRI属性が「正しくない」と見なされなければならない、と[BGP-MP]のセクション7で指定されるように扱われなければなりません。
4. "Leaf A-D Route", defined in Section 4.4 of [MVPN-BGP]. In this route, the "NLRI length" field is following by a variable-length "route key", which is followed by the "Originating Router's IP Address" field. The Route Key has its own length field. From the NLRI length and the route key length, one can compute the length of the "Originating Router's IP Address" field. If the computed length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP].
4 MVPN-BGP]のセクション4.4で定義された "リーフA-Dルート" を、。このルートでは、「NLRIの長さ」フィールドは、「発信側ルータのIPアドレス」フィールドに続いて、可変長「ルートキー」によって以下の通りです。ルートキーは、自身の長さフィールドを持っています。 NLRI長とルートキーの長さから、一つは「発信側ルータのIPアドレス」フィールドの長さを計算することができます。 「発信側ルータのIPアドレス」フィールドの計算された長さは4でも16でもない場合は、MP_REACH_NLRI属性が「正しくない」と見なされなければならない、と[BGP-MP]のセクション7で指定されるように扱われなければなりません。
The "VRF Route Import Extended Community", specified in [MVPN-BGP], is an attribute carried by unicast VPN-IPv4 or VPN-IPv6 routes. It is an "IPv4 Address Specific Extended Community" of type "VRF Route
[MVPN-BGP]で指定された「VRFルートインポート拡張コミュニティ」は、ユニキャストVPN-IPv4またはVPN-IPv6ルートによって運ばれる属性です。これは、VRFルート」タイプの「IPv4のアドレス特定拡張コミュニティ」です
Import"; hence, it can only carry an IPv4 address. To carry an IPv6 address, an "IPv6 Address Specific Extended Community" [RFC5701], of type "VRF Route Import", must be used. A code point for this type of extended community has been allocated by IANA.
インポート ";したがって、それだけでIPv4アドレスを運ぶことができるIPv6アドレス、搬送する。『』タイプの[RFC5701]の『IPv6アドレスの特定拡張コミュニティVRFルートインポート』を、使用しなければならないこのタイプのコードポイント。拡張コミュニティは、IANAによって割り当てられています。
When a PMSI Tunnel Attribute occurs in an I-PMSI A-D route originated by a particular PE or Autonomous System Border Router (ASBR), it identifies a tunnel that the PE/ASBR uses by default for carrying the multicast traffic of a particular customer MVPN. The proper encoding and interpretation of the PMSI Tunnel attribute is affected by both the AFI and "Network Address of Next Hop" fields.
PMSIトンネル属性が特定のPEまたは自律システム境界ルータ（ASBR）によって発信I-PMSI A-Dの経路で発生した場合、それはPE / ASBRは、特定の顧客MVPNのマルチキャストトラフィックを運ぶためにデフォルトで使用するトンネルを識別する。 PMSIトンネル属性の適切なエンコードおよび解釈は、AFIと「ネクストホップのネットワークアドレス」フィールドの両方に影響されます。
When the PMSI Tunnel Attribute occurs in a BGP Update message with a MP_REACH_NLRI attribute whose AFI is 1, the meaning is that the identified tunnel is used by default to carry IPv4 MVPN traffic for a particular customer MVPN. When the PMSI Tunnel Attribute occurs in a BGP Update message with a MP_REACH_NLRI attribute whose AFI is 2, the meaning is that the identified tunnel is used by default to carry IPv6 MVPN traffic for a particular customer MVPN. To assign both IPv4 and IPv6 MVPN traffic to an I-PMSI tunnel, two I-PMSI A-D routes MUST be used -- one whose MP_REACH_NLRI has an AFI of 1 and one whose MP_REACH_NLRI has an AFI of 2. To use the same tunnel for both IPv4 and IPv6 traffic, the same value of the PMSI Tunnel attribute can be used in each route.
PMSIのトンネル属性がAFI 1であるMP_REACH_NLRI属性を持つBGP Updateメッセージで発生した場合には、意味が特定されたトンネルは、特定の顧客MVPNのIPv4 MVPNトラフィックを運ぶためにデフォルトで使用されていることです。 PMSIのトンネル属性がAFI 2であるMP_REACH_NLRI属性を持つBGP Updateメッセージで発生した場合には、意味が特定されたトンネルは、特定の顧客MVPNのためのIPv6 MVPNトラフィックを運ぶためにデフォルトで使用されていることです。 I-PMSIトンネルにIPv4とIPv6のMVPNの両方のトラフィックを割り当てるために、2つのI-PMSIのADルートが使用されなければならない - そのMP_REACH_NLRI有する1のAFI一方とそのMP_REACH_NLRIに同じトンネルを使用する2のAFIを有するものをIPv4とIPv6の両方のトラフィックは、PMSIトンネル属性の同じ値が各経路で使用することができます。
If the "Network Address of Next Hop" field in the MP_REACH_NLRI attribute contains an IPv4 address, then any IP addresses appearing in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be IPv4 addresses.
MP_REACH_NLRI属性のフィールド「ネクストホップのネットワークアドレスは、」IPv4アドレスが含まれている場合、PMSIトンネル属性の「トンネル識別子」フィールドに出現する任意のIPアドレスは、IPv4アドレスである必要があります。
If the "Network Address of Next Hop" field in the MP_REACH_NLRI attribute contains an IPv6 address, then any IP addresses appearing in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be IPv6 addresses.
MP_REACH_NLRI属性のフィールド「ネクストホップのネットワークアドレスは、」IPv6アドレスが含まれている場合、PMSIトンネル属性の「トンネル識別子」フィールドに出現する任意のIPアドレスは、IPv6アドレスでなければなりません。
If these conditions are not met, the PMSI Tunnel Attribute MUST be handled as a "malformed" PMSI Tunnel Attribute, as specified in Section 5 of [MVPN-BGP].
これらの条件が満たされない場合[MVPN-BGP]のセクション5で指定されるように、PMSIトンネル属性は、「不正な」PMSIトンネル属性として取り扱わなければなりません。
IANA has assigned the code point 0x000b for "VRF Route Import" in the "IPv6 Address Specific Extended Community" registry in the "transitive communities" portion of the namespace. The references are to this document and to [MVPN-BGP].
IANAは、名前空間の「推移コミュニティ」の部分に「IPv6アドレスの特定拡張コミュニティ」レジストリで「VRFルートのインポート」のコードポイント0x000bが割り当てられています。参照は、この文書にし、[MVPN-BGP]にあります。
This document does not raise any security considerations beyond those raised by [MVPN-BGP].
この文書では、[MVPN-BGP]が提起したものを超えてすべてのセキュリティ上の考慮事項は発生しません。
The authors wish to thank Dongling Duan, Keyur Patel, Yakov Rekhter, and Karthik Subramanian.
著者はDonglingドゥアン、Keyurパテル、ヤコフ・レックター、およびカルティクサブラマニアンに感謝したいです。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[BGP-MP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[BGP-MP]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[MVPN]ローゼン、E.、エド。、およびR.アガルワル、エド。、RFC 6513、2012年2月 "MPLS / BGP VPNのIPにおけるマルチキャスト"。
[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[MVPN-BGP]アガルワル、R.、ローゼン、E.、モリン、T.、およびY. Rekhter、 "BGPエンコーディング及びMPLS / IP VPNのBGPにおけるマルチキャストのための手順"、RFC 6514、2012年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ルFaucheur、 "BGP-MPLS IP仮想プライベートネットワーク（VPN）は、IPv6 VPNのための拡張"、RFC 4659、2006年9月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、RFC 4798、2007年2月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684]マルケス、P.、Bonica、R.、牙、L.、マティーニ、L.、Raszuk、R.、パテル、K.、およびJ.ギシャール、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングのための制約経路配信（BGP / MPLS）インターネット・プロトコル（IP）、仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月。
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
[RFC5549]ルFaucheur、F.とE.ローゼン、 "IPv6のネクストホップと広告のIPv4ネットワーク層到達可能性情報"、RFC 5549、2009年5月。
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009.
[RFC5701] Rekhter、Y.、RFC 5701、2009年11月の "IPv6は、特定のBGP拡張コミュニティ属性をアドレス"。
Authors' Addresses
著者のアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 EMail: raggarwa_1@yahoo.com
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 Eメール：raggarwa_1@yahoo.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 Eメール：erosen@cisco.com