RFC 8950 - Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8950.html
タイトル : RFC 8950 - IPv6の到達範囲内到達可能性情報（NLRI）の広告IPv6ネクストホップ
翻訳編集 : 自動生成

[要約] RFC 8950は、IPv6ネクストホップを使用してIPv4ネットワーク層到達可能性情報（NLRI）を広告する方法について説明しています。この文書の目的は、IPv4とIPv6の間の相互運用性を向上させることにあります。主に、異なるIPバージョン間でのルーティング情報の交換を効率化する場面で利用されます。

Internet Engineering Task Force (IETF)                      S. Litkowski
Request for Comments: 8950                                    S. Agrawal
Obsoletes: 5549                                         K. Ananthamurthy
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                                 K. Patel
                                                                  Arrcus
                                                           November 2020

Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

IPv6の到達範囲内到達可能性情報（NLRI）の広告IPv6ネクストホップ

Abstract

概要

Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.

Multiprotocol BGP（MP-BGP）は、使用可能なネクストホップアドレスファミリのセットがアドレスファミリID（AFI）および次のアドレスファミリID（SAFI）によって決定されることを指定します。IPv4アドレスファミリのAFI / SAFI定義は、IPv4ネットワーク層到達可能性情報（NLRI）またはVPN-IPv4 NLRIをアドバタイズするときにIPv4プロトコルに属するネクストホップアドレスを広告するための規定のみを持ちます。

This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549.

このドキュメントは、IPv4 NLRIまたはVPN-IPv4 NLRIの広告をIPv6プロトコルに属するネクストホップアドレスを使用できるようにするのに必要な拡張機能を指定します。これは、IPv4 NLRIまたはVPN-IPv4 NLRIのネクストホップのアドレスもIPv6プロトコルに属し、次のホップのエンコーディングを実行して、アドレスが実際にどのプロトコルに属するかを決定するための次のホップのエンコーディングを含む。IPv6ネクストホップでIPv4 NLRIとVPN-IPv4 NLRIを交換できるかどうかをMP-BGPピアを動的に発見できるようにするBGP機能とBGP機能。この文書はRFC 5549を廃止します。

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 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8950.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8950で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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ドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Changes Compared to RFC 5549
   3.  Extension of AFI/SAFI Definitions for the IPv4 Address Family
   4.  Use of BGP Capability Advertisement
   5.  Operations
   6.  Usage Examples
     6.1.  IPv4 over IPv6 Core
     6.2.  IPv4 VPN Unicast over IPv6 Core
     6.3.  IPv4 VPN Multicast over IPv6 Core
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of network-layer protocols to which the address carried in the Next Hop Address field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). A number of existing AFIs/SAFIs allow the next-hop address to belong to a different address family than the Network Layer Reachability Information (NLRI). For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform Layer 2 Virtual Private Network (L2VPN) auto-discovery allows advertising NLRI that contains the identifier of a Virtual Private LAN Service (VPLS) instance or that identifies a particular pool of attachment circuits at a given Provider Edge (PE), while the Next Hop Address field contains the loopback address of a PE. Similarly, the AFI/SAFI <1/132> (defined in [RFC4684]) to advertise Route Target (RT) membership information allows advertising NLRI that contains such RT membership information, while the Next Hop Address field contains the address of the advertising router.

Multiprotocol BGP（MP-BGP）[RFC4760]は、ネクストホップアドレスフィールドに搭載されているアドレスが属する可能性があるネットワーク層プロトコルのセットが、アドレスファミリID（AFI）と後続のアドレスファミリID（SAFI）によって決まります。）。いくつかの既存のAFI / SAFIは、ネットワーク層到達可能性情報（NLRI）とは、ネクストホップアドレスが異なるアドレスファミリに属していることを可能にします。たとえば、Layer 2 Virtual Private Network（L2VPN）を実行するためのAFI / SAFI <25/65>使用する（RFC6074]）、Virtual Private LANサービス（VPLS）インスタンスの識別子を含むNLRIを広告することができます。または、特定のホップアドレスフィールドにはPEのループバックアドレスが含まれている間、または特定のホップアドレスフィールドにはPEのループバックアドレスが含まれている間、または特定のホップアドレスフィールドには特定のプールを識別します。同様に、経路ターゲット（RT）メンバーシップ情報をアドバタイズするためのAFI / SAFI <1/132>（RFC4684]で定義されています）メンバーシップ情報は、そのようなRTメンバーシップ情報を含む広告NLRI、次のホップアドレスフィールドには広告ルータのアドレスが含まれています。。

Furthermore, a number of these existing AFIs/SAFIs allow the next hop to belong to either the IPv4 protocol or the IPv6 protocol and specify the encoding of the next-hop information to determine which of the protocols the address actually belongs to. For example, [RFC4684] allows the next-hop address to be either an IPv4 or IPv6 address and states that the Next Hop Address field shall be interpreted as an IPv4 address whenever the length of the next-hop address is 4 octets and as an IPv6 address whenever the length of the next-hop address is 16 octets.

さらに、これらの既存のAFIS / SAFIのいくつかは、次のホップをIPv4プロトコルまたはIPv6プロトコルに属し、次のホップ情報のエンコーディングを指定して、アドレスが実際に属するプロトコルのどちらのプロトコルを決定することができます。たとえば、[RFC4684]は、ネクストホップアドレスをIPv4またはIPv6アドレスであり、次のホップアドレスフィールドがネクストホップアドレスの長さが4オクテットである場合はいつでもIPv4アドレスとして解釈されることを示します。イスターホップアドレスの長さが16オクテットの場合はいつでもIPv6アドレス。

There are situations such as those described in [RFC4925] and [RFC5565] where carriers (or large enterprise networks acting as a carrier for their internal resources) may be required to establish connectivity between 'islands' of networks of one address family type across a transit core of a differing address family type. This includes both the case of IPv6 islands across an IPv4 core and the case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP (MP-BGP) is used to advertise the corresponding reachability information, this translates into the requirement for a BGP speaker to advertise the NLRI of a given address family via a next hop of a different address family (i.e., IPv6 NLRI with an IPv4 next hop and IPv4 NLRI with an IPv6 next hop).

[RFC4925]と[RFC5565]のような状況は、1つのアドレスファミリの1つのアドレスファミリータイプのネットワークの「島」との間の接続性を確立するために必要な場合があります。異なるアドレスファミリタイプのトランジットコア。これには、IPv4コア全体のIPv6島の場合とIPv6コア全体のIPv4島の場合が含まれます。Multiprotocol BGP（MP-BGP）が対応する到達可能性情報をアドバタイズするために使用される場合、これは、異なるアドレスファミリの次のホップ（すなわち、IPv6 NLRI）を介して特定のアドレスファミリのNLRIを宣伝するためのBGPスピーカーの要件に変換される。IPv4ネクストホップを備えたIPv4ネクストホップとIPv4 NLRI。

The AFI/SAFI definitions for the IPv6 address family assume that the next-hop address belongs to the IPv6 address family type. Specifically, as per [RFC2545] and [RFC8277], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the next-hop address is assumed to be of an IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the next-hop address is assumed to be of a VPN-IPv6 type.

IPv6アドレスファミリのAFI / SAFI定義は、ネクストホップアドレスがIPv6アドレスファミリタイプに属しているとします。具体的には、[RFC2545]と[RFC8277]、[RFC8277]、<AFI / SAFI>が<2/1>、<2/2>、または<2/4>の場合、ネクストホップアドレスは次のように想定されます。IPv6タイプ。[RFC4659]（RFC4659]、<AFI / SAFI>が<2/128>の場合、ネクストホップアドレスはVPN-IPv6タイプであると想定されます。

However, [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the next-hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 next hop. [RFC4798] defines how the IPv4-mapped IPv6 address format specified in the IPv6 addressing architecture ([RFC4291]) can be used for that purpose when the <AFI/ SAFI> is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4-mapped IPv6 address format as well as a null Route Distinguisher (RD) can be used for that purpose when the <AFI/SAFI> is <2/128>. Thus, there are existing solutions for the advertisement of IPv6 NLRI with an IPv4 next hop.

ただし、[RFC4798]と[RFC4659]は、IPv6 NLRIをIPv4ネクストホップでアドバタイズする必要がある場合は、IPv4アドレスのインストールアドレスの内部にIPv4アドレスをエンコードする方法を指定します。[RFC4798] IPv6アドレス指定アーキテクチャ（[RFC4291]）で指定されたIPv4マップIPv6アドレスフォーマットをその目的に使用できる方法を定義します。<AFC / SAFI>が<2/1>、<2/2>、または<2/4>。[RFC4659] <AFC / SAFI>が<2/128>のときに、IPv4マップIPv6アドレスフォーマットとNULLルート識別器（RD）を使用できる方法を定義します。したがって、IPv4ネクストホップでIPv6 NLRIの広告のための既存の解決策があります。

Similarly, the AFI/SAFI definitions for the advertisement of IPv4 NLRI or VPN-IPv4 NLRI assume that the next-hop address belongs to the IPv4 address family type. Specifically, as per [RFC4760] and [RFC8277], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the next-hop address is assumed to be of an IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the next-hop address is assumed to be of a VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the <AFI/SAFI> is <1/129>, the next-hop address is assumed to be of a VPN-IPv4 type. There is clearly no generally applicable method for encoding an IPv6 address inside the IPv4 address field of the next hop. Hence, there is currently no specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 next hop.

同様に、IPv4 NLRIまたはVPN-IPv4 NLRIの広告のAFI / SAFI定義は、ネクストホップアドレスがIPv4アドレスファミリタイプに属していると想定しています。具体的には、[RFC4760]と[RFC8277]、[RFC8277]、<AFI / SAFI>が<1/1>、<1/2>、または<1/4>の場合、ネクストホップアドレスは次のと仮定されます。IPv4タイプ。[RFC4364]、<AFC4364]、<AFI / SAFI>が<1/128>の場合、ネクストホップアドレスはVPN-IPv4タイプのものと見なされます。[RFC6513]と[RFC6514]と同様に、<AFI / SAFI>が<1/129>のとき、ネクストホップアドレスはVPN-IPv4タイプであると仮定されます。次のホップのIPv4アドレスフィールド内にIPv6アドレスをエンコードするための一般的に適用可能な方法は明らかに適用されません。したがって、IPv4またはVPN-IPv4 NLRIをIPv6ネクストホップで広告するための指定されたソリューションは現在ありません。

This document specifies the extensions necessary to allow advertisement of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 protocol, the encoding of the next-hop information to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. The BGP Capability allows gradual deployment of the functionality of advertising IPv4 reachability via an IPv6 next hop without any flag day nor any risk of traffic black-holing.

このドキュメントでは、IPv4プロトコルに属するネクストホップアドレスを持つIPv4 NLRIまたはVPN-IPv4 NLRIの広告を許可するために必要な拡張機能を指定します。これは、IPv4 NLRIまたはVPN-IPv4 NLRIの次のホップのアドレスをIPv4またはIPv6プロトコルに属するための次のホップのアドレスを、次のホップ情報のエンコーディングを許可するための次のホップのアドレスを含む。プロトコルアドレスは実際に属し、BGP能力、およびMP-BGPピアがIPv4 NLRIとVPN-IPv4 NLRIをIPv6ネクストホップで交換できるかどうかを動的に検出できるようにするBGP機能です。BGP機能により、Flag Dayのいかなるフラグの日も、トラフィックのブラックホリングの危険性も、IPv6の次のホップを介してIPv4到達可能性を広告する機能を段階的に展開できます。

This document obsoletes [RFC5549].

この文書は廃止されています[RFC5549]。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. Changes Compared to RFC 5549

2. RFC 5549と比較した変更

This document introduces two significant changes compared to [RFC5549]:

この文書では、[RFC5549]と比較して2つの大きな変更が紹介されています。

* In [RFC5549], when AFI/SAFI <1/128> is used, the next-hop address is encoded as an IPv6 address with a length of 16 or 32 bytes. To accommodate all existing implementations and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document modifies how the next-hop address is encoded. The next-hop address is now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes (see Sections 3 and 6.2). This change addresses Erratum ID 5253 ([Err5253]). As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability.

* [RFC5549]では、AFI / SAFI <1/128>を使用すると、ネクストホップアドレスは16または32バイトのIPv6アドレスとしてエンコードされます。既存のすべての実装に対応し、VPNV4OIPv4とVPNV6OIPv6との一貫性をもたらすために、この文書は次のホップアドレスがどのようにエンコードされるかを変更します。ネクストホップアドレスは、長さ24または48バイトのVPN-IPv6アドレスとしてエンコードされます（セクション3と6.2を参照）。この変更は、Erratum ID 5253（[ERR5253]）に対応しています。既知のすべての展開された実装が今日相互運用可能であり、新しい提案されたエンコーディングを使用するにつれて、変更は既存の相互運用性を損なわない。

* This document allows AFI/SAFI <1/129> (IPv4 multicast) to use an IPv6 underlay using similar encoding and procedures to AFI/SAFI <1/128> (see Sections 3 and 6.3).

* このドキュメントでは、AFI / SAFI <1/129（IPv4マルチキャスト）が、AFI / SAFI <1/128>の同様のエンコードと手順を使用してIPv6アンダーラインを使用することを可能にします（セクション3と6.3を参照）。

3. Extension of AFI/SAFI Definitions for the IPv4 Address Family

3. IPv4アドレスファミリのAFI / SAFI定義の拡張

As mentioned earlier, MP-BGP specifies that the set of usable next-hop address families is determined by the AFI and the SAFI. The following AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, <1/128>, and <1/129>) only have provisions for advertising a next-hop address that belongs to the IPv4 protocol. This document extends the set of usable next-hop address families to include IPv6 in addition to IPv4 when advertising an IPv4 or VPN-IPv4 NLRI.

前述のように、MP-BGPは、使用可能なネクストホップアドレスファミリのセットがAFIとSAFIによって決定されることを指定します。IPv4 NLRIまたはVPN-IPv4 NLRI（<1/1>、<1/2>、<1/4>、<1/128>、<1/129>、<1/128>、および<1/129>のための以下のAFI / SAFI定義IPv4プロトコルに属するネクストホップアドレスを広告するため。この文書は、IPv4またはVPN-IPv4 NLRIを広告するときにIPv4に加えてIPv6を含めるために、使用可能なネクストホップアドレスファミリのセットを拡張します。

Specifically, this document allows advertising the MP_REACH_NLRI attribute [RFC4760] with this content:

具体的には、この文書では、このコンテンツを使用してMP_REACH_NLRI属性[RFC4760]を広告することができます。

* AFI = 1

* SAFI = 1, 2, or 4

* SAFI = 1,2、または4

* Length of Next Hop Address = 16 or 32

* ネクストホップアドレス= 16または32の長さ

* Next Hop Address = IPv6 address of a next hop (potentially followed by the link-local IPv6 address of the next hop). This field is to be constructed as per Section 3 of [RFC2545].

* ネクストホップアドレス=ネクストホップのIPv6アドレス（潜在的に次のホップのリンクローカルIPv6アドレス）。このフィールドは[RFC2545]のセクション3に従って構築されます。

* NLRI = NLRI as per the AFI/SAFI definition

* AFI / SAFI定義に従ってNLRI = NLRI

It also allows advertising the MP_REACH_NLRI attribute [RFC4760] with this content:

このコンテンツを使用してMP_REACH_NLRI属性[RFC4760]の広告も可能です。

* AFI = 1

* SAFI = 128 or 129

* SAFI = 128または129

* Length of Next Hop Address = 24 or 48

* ネクストホップアドレス= 24または48の長さ

* Next Hop Address = VPN-IPv6 address of a next hop with an 8-octet RD set to zero (potentially followed by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set to zero).

* 次のホップアドレス= VPN-IPv6 8オクテットRDをゼロに設定したネクストホップのアドレス（次に、8オクテットRDがゼロに設定されているネクストホップのリンクローカルVPN-IPv6アドレス）。

* NLRI = NLRI as per the AFI/SAFI definition

* AFI / SAFI定義に従ってNLRI = NLRI

This is in addition to the existing mode of operation allowing advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2>, and <1/4> with a next-hop address of an IPv4 type and advertisement of NLRI for an <AFI/SAFI> of <1/128> and <1/129> with a next-hop address of a VPN-IPv4 type.

これは、<1/1>、<1/2>のNLRIの広告をIPv4タイプのネクストホップアドレスで許可する既存の動作モードに追加されています。VPN-IPv4タイプのネクストホップアドレスを持つ<1/128>と<1/129>のNLRIの広告。

The BGP speaker receiving the advertisement MUST use the Length of Next Hop Address field to determine which network-layer protocol the next-hop address belongs to.

広告を受信したBGPスピーカーは、次のホップアドレスフィールドの長さを使用して、次のホップアドレスがどのネットワーク層プロトコルに属するかを判断する必要があります。

* When the AFI/SAFI is <1/1>, <1/2>, or <1/4> and when the Length of Next Hop Address field is equal to 16 or 32, the next-hop address is of type IPv6.

* AFI / SAFIが<1/1>、<1/2>、または<1/4>の場合、およびネクストホップアドレスフィールドの長さが16または32に等しい場合、ネクストホップアドレスはIPv6型です。

* When the AFI/SAFI is <1/128> or <1/129> and when the Length of Next Hop Address field is equal to 24 or 48, the next-hop address is of type VPN-IPv6.

* AFI / SAFIが<1/128>または<1/129>の場合、およびネクストホップアドレスフィールドの長さが24または48に等しい場合、ネクストホップアドレスはVPN-IPv6型です。

Note that this method of using the Length of Next Hop Address field to determine which network-layer protocol the next-hop address belongs to (out of the set of protocols allowed by the AFI/SAFI definition) is the same as that used in [RFC4684] and [RFC6074].

なお、次のホップアドレスフィールドの長さを使用して次のホップアドレスがどのネットワーク層プロトコルに属するか（AFI / SAFI定義によって許可されているプロトコルのセット）を判断する方法である。RFC4684と[RFC6074]。

4. Use of BGP Capability Advertisement

4. BGP機能広告の使用

[RFC5492] defines a mechanism to allow two BGP speakers to discover if a particular capability is supported by their BGP peer and, thus, whether it can be used with that peer. This document defines a capability that can be advertised using [RFC5492], referred to as the "Extended Next Hop Encoding capability". This capability allows BGP speakers to discover whether, for a given NLRI <AFI/SAFI>, a peer supports advertisement with a next hop whose network protocol is determined by the value of the Length of Next Hop Address field, as specified in Section 3.

[RFC5492] 2つのBGPスピーカーが自分のBGPピアによってサポートされているかどうか、したがって、そのピアと共に使用できるかどうかを検出できるようにするメカニズムを定義します。この文書は、[RFC5492]を使用して「拡張ネクストホップエンコーディング機能」と呼ばれる機能を定義しています。この機能により、BGPスピーカーは、特定のNLRI <AFI / SAFI>の場合、PeerがNext Hop Addressフィールドの長さの値によってネットワークプロトコルが決定されているネクストホップを使用してアドバタイズをサポートしているかどうかをBGPスピーカーが検出できます。

A BGP speaker that wishes to advertise an IPv6 next hop for IPv4 NLRI or for VPN-IPv4 NLRI to a BGP peer as per this specification MUST use the Capability Advertisement procedures defined in [RFC5492] with the Extended Next Hop Encoding capability to determine whether its peer supports this for the NLRI AFI/SAFI pair(s) of interest. The fields in the Capabilities Optional Parameter MUST be set as follows:

IPv4 NLRIのネクストホップまたはVPN-IPv4 NLRIのIPv6の次のホップをアドバタイズしたいBGPスピーカーは、この仕様に従って[RFC5492]で定義されている機能広告プロシージャーを使用してETSIDS NEXT HOPエンコーディング機能を使用して使用しなければなりません。ピアは、関心のあるNLRI AFI / SAFIペアの場合にこれをサポートしています。機能任務のフィールドオプションパラメータは次のように設定する必要があります。

* The Capability Code field MUST be set to 5 (which indicates the Extended Next Hop Encoding capability).

* 能力コードフィールドは5に設定する必要があります（これは拡張ネクストホップエンコーディング機能を示します）。

* The Capability Length field is set to a variable value that is the length of the Capability Value field (which follows).

* 能力長フィールドは、能力値フィールドの長さである変数値に設定されます（続く）。

* The Capability Value field has the following format:

* Capability Valueフィールドには次の形式があります。

               +-----------------------------------------------------+
               | NLRI AFI - 1 (2 octets)                             |
               +-----------------------------------------------------+
               | NLRI SAFI - 1 (2 octets)                            |
               +-----------------------------------------------------+
               | Nexthop AFI - 1 (2 octets)                          |
               +-----------------------------------------------------+
               | .....                                               |
               +-----------------------------------------------------+
               | NLRI AFI - N (2 octets)                             |
               +-----------------------------------------------------+
               | NLRI SAFI - N (2 octets)                            |
               +-----------------------------------------------------+
               | Nexthop AFI - N (2 octets)                          |
               +-----------------------------------------------------+

where:

ただし：

- each triple <NLRI AFI, NLRI SAFI, Nexthop AFI> indicates that the NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a next-hop address belonging to the network-layer protocol of Nexthop AFI.

- 各トリプル<NLRI AFI、NLRI SAFI、NEXTHOP AFI>は、<NLRI AFI / NLRI SAFI>のNLRIがNexThop AFIのネットワーク層プロトコルに属するネクストホップアドレスでアドバンスすることができることを示している。

- the AFI and SAFI values are defined in the "Address Family Numbers" and "Subsequent Address Family Identifier (SAFI) Parameters" registries (see [IANA-AFI] and [IANA-SAFI], respectively).

- AFI値とSAFIの値は、「アドレスファミリ番号」と「後続のアドレスファミリ識別子（SAFI）パラメータ」レジストリ（それぞれ[IANA-AFI]および[IANA-SAFI]を参照）に定義されています。

Since this document only concerns itself with the advertisement of IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop, this specification only allows the following values in the Capability Value field of the Extended Next Hop Encoding capability:

この文書はIPv4 NLRIおよびVPN-IPv4 NLRIの広告だけでIPv6ネクストホップを使用するだけで、この仕様では、拡張ネクストホップエンコーディング機能の機能値フィールドに次の値を使用できます。

* NLRI AFI = 1 (IPv4)

* NLRI AFI = 1（IPv4）

* NLRI SAFI = 1, 2, 4, 128, or 129

* NLRI SAFI = 1,2,4,128、または129

* Nexthop AFI = 2 (IPv6)

* Nexthop AFI = 2（IPv6）

   This document does not specify the use of the Extended Next Hop
   Encoding capability with any other combinations of <NLRI AFI, NLRI
   SAFI, Nexthop AFI>.  For example, the Next Hop Encoding capability
   specified in this document is not intended to be used for NLRI AFIs/
   SAFIs whose definition already allows use of both IPv4 and IPv6 next
   hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]).  Similarly,
   it is not intended that the Extended Next Hop Encoding capability be
   used for NLRI AFIs/SAFIs for which there is already a solution for
   advertising a next hop of a different address family (e.g., AFI/SAFI
   = <2/1>, <2/2>, or <2/4> with an IPv4 next hop as per [RFC4798] and
   AFI/SAFI = <2/128> with an IPv4 next hop as per [RFC4659]).

It is expected that if new AFIs/SAFIs are defined in the future, their definitions will have provisions (where appropriate) for both IPv4 and IPv6 next hops from the beginning, with the determination based on the Length of Next Hop Address field. Thus, new AFIs/SAFIs are not expected to make use of the Extended Next Hop Encoding capability.

将来的に新しいAFIS / Safisが定義されている場合、それらの定義は最初からIPv4とIPv6の両方のための規定（適切な場合）を持ち、次のホップアドレスフィールドの長さに基づいて決定します。したがって、新しいAFIS / SAFISは、拡張ネクストホップエンコーディング機能を利用するとは期待されていません。

A BGP speaker MUST only advertise the IPv4 or VPN-IPv4 NLRI with an IPv6 next hop to a BGP peer if the BGP speaker has first ascertained via the BGP Capability Advertisement that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.

BGPスピーカーは、BGPピアが関連するAFIの拡張ネクストホップエンコーディング機能をサポートしているBGPスピーカーが最初にBGPキャッション広告をサポートしている場合、BGPスピーカーがBGPピアへのIPv6またはVPN-IPv4 NLRIのみをアドバタイズしなければなりません。セーフペア。

The Extended Next Hop Encoding capability provides information about next-hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is allowed. It does not influence whether that AFI/SAFI is indeed allowed. Whether an AFI/SAFI can be used between the BGP peers is purely determined through the Multiprotocol Extensions capability defined in [RFC4760].

拡張ネクストホップエンコーディング機能は、AFI / SAFIが許可されていると仮定して、特定のAFI / SAFIのネクストホップエンコーディングに関する情報を提供します。AFI / SAFIが確かに許可されているかどうかは影響しません。BGPピア間でAFI / SAFIを使用できるかどうかは、[RFC4760]で定義されているマルチプロトコル拡張機能を介して純粋に決定されます。

5. Operations

5. オペレーション

By default, if a particular BGP session is running over IPvx (where IPvx is IPv4 or IPv6) and if the BGP speaker sending an update is putting its own address in as the next hop, then the next-hop address SHOULD be specified as an IPvx address, using the encoding rules specified in the AFI/SAFI definition of the NLRI being updated. This default behavior may be overridden by policy.

デフォルトでは、特定のBGPセッションがIPvx（IPvxがIPv4またはIPv6の場合）を介して実行されている場合、およびアップデートを送信するBGPスピーカーが次のホップとして自身のアドレスを置くことになっている場合は、次のホップアドレスを次のように指定する必要があります。IPvxアドレスは、更新されているNLRIのAFI / SAFI定義で指定されたエンコード規則を使用しています。このデフォルトの動作はポリシーによって上書きされる可能性があります。

When a next-hop address needs to be passed along unchanged (e.g., as a Route Reflector (RR) would do), its encoding MUST NOT be changed. If a particular RR client cannot handle that encoding (as determined by the BGP Capability Advertisement), then the NLRI in question cannot be distributed to that client. For sound routing in certain scenarios, this will require that all the RR clients be able to handle whatever encodings any of them may generate.

次のホップアドレスを変更されずに渡される必要がある場合（例えば、ルートリフレクタ（RR）は行う）、その符号化は変更されてはならない。特定のRRクライアントがそのエンコーディングを処理できない場合（BGP機能広告によって決定されるように）、問題のNLRIはそのクライアントに配布することはできません。サウンドルーティングのために、特定のシナリオでは、これにより、すべてのRRクライアントがそれらのいずれかのエンコーディングが生成される可能性があるものであれば処理できるようにする必要があります。

6. Usage Examples

6. 使用例

6.1. IPv4 over IPv6 Core

6.1. IPv6 over IPv6コア

The extensions defined in this document may be used as discussed in [RFC5565] for the interconnection of IPv4 islands over an IPv6 backbone. In this application, Address Family Border Routers (AFBRs; as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 next hop.

この文書で定義された拡張は、IPv6バックボーン上のIPv4島の相互接続のための[RFC5565]で説明されているように使用されてもよい。このアプリケーションでは、ファミリボーダールータ（AFBR; [RFC4925]で定義されているように）IPv6ネクストホップとともに、IPv4 NLRIを宣伝します。

The MP_REACH_NLRI is encoded with:

MP_REACH_NLRIは次のようにエンコードされています。

* AFI = 1

* SAFI = 1

* Length of Next Hop Address field = 16 (or 32)

* ネクストホップアドレスフィールドの長さ= 16（または32）

* Next Hop Address = IPv6 address of the next hop

* ネクストホップアドレス=ネクストホップのIPv6アドレス

* NLRI = IPv4 routes

* NLRI = IPv4ルート

During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:

BGP機能の広告の間、PEルータには機能の任意のフィールドが含まれます。

* Capability Code set to "Extended Next Hop Encoding"

* 能力コードは「拡張ネクストホップエンコーディング」に設定されています

* Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2>

* <NLRI AFI = 1、NLRI SAFI = 1、NEXTHOP AFI = 2>を含む能力値

6.2. IPv4 VPN Unicast over IPv6 Core

6.2. IPv6コアのIPv4 VPNユニキャスト

The extensions defined in this document may be used for support of IPv4 VPNs over an IPv6 backbone. In this application, PE routers would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 next hop.

この文書で定義されている拡張子は、IPv6バックボーンを介したIPv4 VPNのサポートに使用できます。このアプリケーションでは、PEルーターはIPv6ネクストホップとともにMP_REACH_NLRIにVPN-IPv4 NLRIをアドバタイズします。

The MP_REACH_NLRI is encoded with:

MP_REACH_NLRIは次のようにエンコードされています。

* AFI = 1

* SAFI = 128

* Length of Next Hop Address field = 24 (or 48)

* ネクストホップアドレスフィールドの長さ= 24（または48）

* Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero

* RDがゼロに設定されているネクストホップアドレス= VPN-IPv6アドレス

* NLRI = IPv4-VPN routes

* NLRI = IPv4-VPNルート

During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:

BGP機能の広告の間、PEルータには機能の任意のフィールドが含まれます。

* Capability Code set to "Extended Next Hop Encoding"

* 能力コードは「拡張ネクストホップエンコーディング」に設定されています

* Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop AFI=2>

* <NLRI AFI = 1、NLRI SAFI = 128、NEXTHOP AFI = 2>を含む能力値

6.3. IPv4 VPN Multicast over IPv6 Core

6.3. IPv6コアのIPv4 VPNマルチキャスト

The extensions defined in this document may be used for support of IPv4 multicast VPNs over an IPv6 backbone. In this application, PE routers would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 next hop.

この文書で定義されている拡張子は、IPv6バックボーン上のIPv4マルチキャストVPNのサポートに使用できます。このアプリケーションでは、PEルーターはIPv6ネクストホップとともにMP_REACH_NLRIにVPN-IPv4 NLRIをアドバタイズします。

The MP_REACH_NLRI is encoded with:

MP_REACH_NLRIは次のようにエンコードされています。

* AFI = 1

* SAFI = 129

* Length of Next Hop Address field = 24 (or 48)

* ネクストホップアドレスフィールドの長さ= 24（または48）

* Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero

* RDがゼロに設定されているネクストホップアドレス= VPN-IPv6アドレス

* NLRI = IPv4-VPN routes

* NLRI = IPv4-VPNルート

During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:

BGP機能の広告の間、PEルータには機能の任意のフィールドが含まれます。

* Capability Code set to "Extended Next Hop Encoding"

* 能力コードは「拡張ネクストホップエンコーディング」に設定されています

* Capability Value containing <NLRI AFI=1, NLRI SAFI=129, Nexthop AFI=2>

* <NLRI AFI = 1、NLRI SAFI = 129、NEXTHOP AFI = 2>を含む能力値

7. IANA Considerations

7. IANAの考慮事項

This document does not define any new code points from those included in [RFC5549].

この文書は[RFC5549]に含まれているものから新しいコードポイントを定義しません。

[RFC5549] added "Extended Next Hop Encoding" to the "Capability Codes" registry ([IANA-CAP-CODE]), which was created by [RFC5492]. IANA has updated the registration of that entry to refer to this document. The value allocated for this Capability Code is 5.

[RFC5549] [RFC5492]によって作成された「機能コード」レジストリ（[IANA-CAPコード]）に「拡張ネクストホップエンコード」を追加しました。IANAはこの文書を参照するためにそのエントリの登録を更新しました。この機能コードに割り当てられた値は5です。

8. Security Considerations

8. セキュリティに関する考慮事項

This document does not raise any additional security issues beyond those of BGP-4 and the Multiprotocol Extensions for BGP-4. The same security mechanisms are applicable.

この文書は、BGP-4のものを超えて追加のセキュリティ上の問題を発生させず、BGP-4のMultiprotocol Extensionsです。同じセキュリティメカニズムが適用可能です。

However, as [RFC4272] discusses, BGP is vulnerable to traffic diversion attacks. The ability to advertise an IPv6 next hop adds a new means by which an attacker could cause traffic to be diverted from its normal path. Such an attack differs from preexisting vulnerabilities in that traffic could be forwarded to a distant target across an intervening network infrastructure (e.g., an IPv6 core), allowing an attack to potentially succeed more easily since less infrastructure would have to be subverted. Potential consequences include "hijacking" of traffic or denial of service.

ただし、[RFC4272]について説明すると、BGPはトラフィック転換攻撃に対して脆弱です。IPv6ネクストホップをアドバタイズする能力は、攻撃者がその通常のパスからトラフィックを転送させることができる新しい手段を追加します。そのような攻撃は、そのトラフィックが介在するネットワークインフラストラクチャ（例えば、IPv6コア）を介して遠いターゲットに転送される可能性があるという既存の脆弱性とは異なり、インフラストラクチャが少なくなる必要があるので攻撃をより容易に成功させることができる。潜在的な結果には、トラフィックまたはサービス拒否の「ハイジャック」が含まれます。

Although not expected to be the typical case, the IPv6 address used as the BGP next-hop address could be an IPv4-mapped IPv6 address (as defined in [RFC4291]). Configuration of the security mechanisms potentially deployed by the network operator (such as security checks on a next-hop address) also need to keep this case in mind.

典型的な場合ではないが、BGPネクストホップアドレスとして使用されるIPv6アドレスは、（[RFC4291]で定義されているように）IPv4マップIPv6アドレスであり得る。ネットワークオペレータによって潜在的に展開されるセキュリティメカニズムの構成（次のホップアドレスのセキュリティチェックなど）もこの場合を念頭に置いておく必要があります。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, <https://www.rfc-editor.org/info/rfc2545>.

[RFC2545] Marques、P.およびF.Dupont、「IPv6ドメイン間ルーティング用のBGP-4マルチプロトコル拡張の使用」、RFC 2545、DOI 10.17487 / RFC2545、1999年3月、<https：//www.rfc-編集者。ORG / INFO / RFC2545>。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC4760]ベイツ、T.、Chandra、R.、Katz、D.、およびY.Rekhter、「BGP-4」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。

[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC5492] Scudder、J.およびR.Chandra、「BGP-4による機能広告」、RFC 5492、DOI 10.17487 / RFC5492、2009年2月、<https：//www.rfc-editor.org/info/rfc5492>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.

[RFC8277] Rosen、E.、「MPLSラベルをアドレスプレフィックスにバインドするためのBGPの使用」、RFC 8277、DOI 10.17487 / RFC8277、2017年10月、<https://www.rfc-editor.org/info/rfc8277>。

9.2. Informative References

9.2. 参考引用

[Err5253] RFC Errata, Erratum ID 5253, RFC 5549, <https://www.rfc-editor.org/errata/eid5253>.

[ERR5253] RFCエラータ、Erratum ID 5253、RFC 5549、<https://www.rfc-editor.org/errata/eid5253>。

[IANA-AFI] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers/>.

[IANA-AFI] IANA、「住所の家族番号」、<https://www.iana.org/assignments/address-family-numbers/>。

[IANA-CAP-CODE] IANA, "Capability Codes", <https://www.iana.org/assignments/capability-codes/>.

[IANA-CAPコード] IANA、「機能コード」、<https://www.iana.org/assignments/capability-codes/>

[IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <https://www.iana.org/assignments/safi-namespace/>.

[IANA-SAFI] IANA、「後続のアドレスファミリID（SAFI）パラメータ」、<https：//www.iana.org/assignments/safi-namespace/>。

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

[RFC4272] Murphy、S.、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https：//www.rfc-editor.org/info/rfc4272>。

[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, DOI 10.17487/RFC4659, September 2006, <https://www.rfc-editor.org/info/rfc4659>.

[RFC4659] DE CLERCQ、J.、OOM、D.、COLUGI、M.、およびF.LE FAUCHEUR、IPV6 VPNの「BGP-MPLS IP仮想プライベートネットワーク（VPN）拡張子」、RFC 4659、DOI 10.17487 / RFC4659、2006年9月、<https：//www.rfc-editor.org/info/rfc4659>。

[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, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.

[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ.Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングのための制約付きルート配布（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS） "、RFC 4684、DOI 10.17487 / RFC4684、2006年11月、<https://www.rfc-editor.org/info/rfc4684>。

[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, DOI 10.17487/RFC4798, February 2007, <https://www.rfc-editor.org/info/rfc4798>.

[RFC4798] DE CLERCQ、J.、OOM、D.、Prevost、S.、およびF.Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv4 MPLS（6PE）」、RFC 4798、DOI 10.17487 / RFC47982007年2月、<https：//www.rfc-editor.org/info/rfc4798>。

[RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, DOI 10.17487/RFC4925, July 2007, <https://www.rfc-editor.org/info/rfc4925>.

[RFC4925] Li、X.、ED。、Dawkins、S、ED。、Ward、D.、Ed。、およびA. Durand、Ed。、「Softwire Downerest Statement」、RFC 4925、DOI 10.17487 / RFC4925、7月2007年、<https://www.rfc-editor.org/info/rfc4925>。

[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, DOI 10.17487/RFC5549, May 2009, <https://www.rfc-editor.org/info/rfc5549>.

[RFC5549] Le Faucheur、F.およびE.ローゼン、「IPv4ネットワーク層到達可能性情報をIPv6ネクストホップと広告推奨」、RFC 5549、DOI 10.17487 / RFC5549、2009年5月、<https：//www.rfc-editor.org/ info / rfc5549>。

[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, <https://www.rfc-editor.org/info/rfc5565>.

[RFC5565] WU、J.、CUI、Y、METZ、CU、およびE.ローゼン、「ソフトワイヤーメッシュフレームワーク」、RFC 5565、DOI 10.17487 / RFC5565、2009年6月、<https：///www.rfc-編集者.org / info / rfc5565>。

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.

[RFC6074]ローゼン、E.、Davie、B.、Radoaca、V.、およびW.Luo、「レイヤ2仮想プライベートネットワークにおけるプロビジョニング、自動発見、およびシグナリング（L2VPNS）」、RFC 6074、DOI 10.17487 / RFC6074、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC6513]ロージェン、E。、ED。R.Aggarwal、ed。、「MPLS / BGP IP VPNSのマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、2012年2月、<https：//www.rfc-editor.org/info/rfc6513>。

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.

[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T.、およびY.Rekhter、「BGPエンコーディングおよびMPLS / BGP IP VPNSのマルチキャストの手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、<https://www.rfc-editor.org/info/rfc6514>。

Acknowledgments

謝辞

The authors would like to thank Francois Le Faucheur and Eric Rosen for their work on [RFC5549].

著者らは、Francois Le FaucheurとEric RosenをRFC5549にしています。

The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in [RFC5549].

著者らは、[RFC5549]で定義されたアプローチへの貢献について、Yakov Rekhter、Pranav Mehta、およびJohn Scudderに感謝します。

Authors' Addresses

著者の住所

Stephane Litkowski Cisco

Stephane Litkowski Cisco.

   Email: slitkows@cisco.com

Swadesh Agrawal Cisco

Swadesh Agrawal Cisco.

   Email: swaagraw@cisco.com

Krishna Muddenahally Ananthamurthy Cisco

クリシュナは泥だらけのAnanthamurthyyCys.

   Email: kriswamy@cisco.com

Keyur Patel Arrcus

   Email: keyur@arrcus.com