Network Working Group F. Le Faucheur
Request for Comments: 5549 E. Rosen
Category: Standards Track Cisco Systems
May 2009
Network Working Group F. Le Faucheur
Request for Comments: 5549 E. Rosen
Category: Standards Track Cisco Systems
May 2009
Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
使用IPv6下一跳播发IPv4网络层可达性信息
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current 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. This document specifies the extensions necessary to allow advertising 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 in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
多协议BGP（MP-BGP）规定，下一跳字段中携带的地址所属的网络层协议集由地址族标识符（AFI）和后续地址族标识符（SAFI）确定。IPv4地址系列的当前AFI/SAFI定义仅规定在播发IPv4网络层可达性信息（NLRI）或VPN-IPv4 NLRI时播发属于IPv4协议的下一跳地址。本文档指定了允许使用属于IPv6协议的下一跳地址播发IPv4 NLRI或VPN-IPv4 NLRI所需的扩展。这包括AFI/SAFI定义的扩展，以允许IPv4 NLRI或VPN-IPv4 NLRI的下一个跃点的地址也属于IPv6协议，下一个跃点的编码以确定地址实际属于哪个协议，以及一种新的BGP功能，允许MP-BGP对等方动态发现它们是否可以与IPv6下一跳交换IPv4 NLRI和VPN-IPv4 NLRI。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4
4. Use of BGP Capability Advertisement .............................5
5. Operations ......................................................7
6. Usage Examples ..................................................7
6.1. IPv4 over IPv6 Core ........................................7
6.2. IPv4 VPN over IPv6 Core ....................................8
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4
4. Use of BGP Capability Advertisement .............................5
5. Operations ......................................................7
6. Usage Examples ..................................................7
6.1. IPv4 over IPv6 Core ........................................7
6.2. IPv4 VPN over IPv6 Core ....................................8
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). A number of existing AFI/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 [L2VPN-SIG]) in order to perform 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 field contains the loopback address of a PE. Similarly, the AFI/SAFI <1/132> (defined in [RFC4684]) in order to advertise Route Target (RT) membership information, allows advertising NLRI that contains such RT membership information, while the Next Hop field contains the address of the advertising router.
多协议BGP（MP-BGP）[RFC4760]规定，下一跳字段中携带的地址所属的网络层协议集由地址族标识符（AFI）和后续地址族标识符（SAFI）确定。许多现有AFI/SAFI允许下一跳地址属于与网络层可达性信息（NLRI）不同的地址族。例如，为了执行L2VPN自动发现而使用的AFI/SAFI<25/65>（根据[L2VPN-SIG]），允许广告NLRI，该NLRI包含虚拟专用LAN服务（VPLS）实例的标识符或标识给定提供商边缘（PE）处的特定连接电路池，而下一个跃点字段包含PE的环回地址。类似地，为了公布路由目标（RT）成员信息，AFI/SAFI<1/132>（在[RFC4684]中定义）允许公布包含此类RT成员信息的NLRI，而下一跳字段包含公布路由器的地址。
Furthermore, a number of these existing AFI/SAFIs allow the Next Hop to belong to either the IPv4 Network Layer Protocol or the IPv6 Network Layer Protocol, and specify the encoding of the Next Hop information in order to determine which of the protocols the address actually belongs to. For example, [RFC4684] allows the Next Hop address to be either IPv4 or IPv6 and states that the Next Hop field address shall be interpreted as an IPv4 address whenever the length of Next Hop address is 4 octets, and as an IPv6 address whenever the length of the Next Hop address is 16 octets.
此外，这些现有AFI/safi中的许多允许下一跳属于IPv4网络层协议或IPv6网络层协议，并指定下一跳信息的编码，以便确定地址实际属于哪个协议。例如，[RFC4684]允许下一跃点地址为IPv4或IPv6，并规定下一跃点地址的长度为4个八位字节时，下一跃点字段地址应解释为IPv4地址，下一跃点地址的长度为16个八位字节时，下一跃点字段地址应解释为IPv6地址。
There are situations such as those described in [RFC4925] and in [MESH-FMWK] where carriers (or large enterprise networks acting as
存在[RFC4925]和[MESH-FMWK]中所述的情况，其中运营商（或大型企业网络）充当
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 Network Layer Reachability Information (NLRI) of a given address family via a Next Hop of a different address family (i.e., IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop).
运营商的内部资源）可能需要在一个地址族类型的网络“孤岛”之间建立连接，跨越不同地址族类型的传输核心。这包括跨IPv4核心的IPv6孤岛和跨IPv6核心的IPv4孤岛。在使用多协议BGP（MP-BGP）公布相应的可达性信息的情况下，这转化为BGP演讲者需要通过不同地址族的下一跳公布给定地址族的网络层可达性信息（NLRI）（即，具有IPv4下一跳的IPv6 NLRI和具有IPv6下一跳的IPv4 NLRI）。
The current 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 [RFC3107], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop address is assumed to be of IPv6-VPN type.
IPv6地址族的当前AFI/SAFI定义假定下一个跃点地址属于IPv6地址族类型。具体而言，根据[RFC2545]和[RFC3107]，当<AFI/SAFI>为<2/1>、<2/2>或<2/4>时，假定下一跳地址为IPv6类型。根据[RFC4659]，当<AFI/SAFI>为<2/128>时，假定下一跳地址为IPv6 VPN类型。
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 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下一跃点播发时，如何在下一跃点IPv6地址字段中对IPv4地址进行编码。[RFC4798]定义了当<AFI/SAFI>为<2/1>、<2/2>或<2/4>时，如何使用IPv6寻址体系结构（[RFC4291]）中指定的IPv4映射IPv6地址格式。[RFC4659]定义了当<AFI/SAFI>为<2/128>时，如何使用IPv4映射的IPv6地址格式以及空路由标识符。因此，现有的解决方案可以通过IPv4下一跃点发布IPv6 NLRI。
Similarly, the current AFI/SAFI definitions for 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 [RFC3107], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the Next Hop address is assumed to be of IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the Next Hop address is assumed to be of 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]和[RFC3107]，当<AFI/SAFI>为<1/1>、<1/2>或<1/4>时，假定下一跳地址为IPv4类型。根据[RFC4364]，当<AFI/SAFI>为<1/128>时，假定下一跳地址为VPN-IPv4类型。显然，在下一个跃点的IPv4地址字段中没有通用的方法来编码IPv6地址。因此，目前还没有针对使用IPv6下一跳播发IPv4或VPN-IPv4 NLRI的指定解决方案。
This document specifies the extensions necessary to do so. 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 in order to determine which of the protocols the address actually belongs to, and a new 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 new BGP Capability allows
本文档指定了执行此操作所需的扩展。这包括对AFI/SAFI定义的扩展，以允许IPv4 NLRI或VPN-IPv4 NLRI的下一跳地址属于IPv4或IPv6协议，对下一跳信息进行编码，以确定该地址实际属于哪个协议，以及一种新的BGP功能，允许MP-BGP对等方动态发现它们是否可以与IPv6下一跳交换IPv4 NLRI和VPN-IPv4 NLRI。新的BGP功能允许
gradual deployment of the new functionality of advertising IPv4 reachability via an IPv6 Next Hop, without any flag day nor any risk of traffic black-holing.
逐步部署新功能，通过IPv6下一跳来宣传IPv4可达性，无需任何卖旗日，也无任何流量黑洞风险。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As mentioned earlier, MP-BGP specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, and <1/128>) only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol. This document extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of network-layer protocols to which the Next Hop address can belong, to include IPv6 in addition to IPv4.
如前所述，MP-BGP规定，下一跳字段中携带的地址所属的网络层协议集由地址族标识符（AFI）和后续地址族标识符（SAFI）确定。以下针对IPv4 NLRI或VPN-IPv4 NLRI（<1/1>、<1/2>、<1/4>和<1/128>）的当前AFI/SAFI定义仅提供了用于公布属于IPv4协议的下一跳地址的规定。本文档扩展了用于IPv4 NLRI和VPN-IPv4 NLRI广告的AFI/SAFI的定义，以扩展下一跳地址所属的网络层协议集，从而除了IPv4之外还包括IPv6。
Specifically, this document allows advertising with [RFC4760] of an MP_REACH_NLRI with:
具体而言，本文件允许使用[RFC4760]的MP_REACH_NLRI进行广告，包括：
o AFI = 1
o AFI=1
o SAFI = 1, 2, 4, or 128
o SAFI=1、2、4或128
o Length of Next Hop Address = 16 or 32
o 下一跳地址的长度=16或32
o Next Hop Address = IPv6 address of 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].
o 下一个跃点地址=下一个跃点的IPv6地址（可能后跟下一个跃点的链路本地IPv6地址）。该区域应按照[RFC2545]第3节进行施工。
o NLRI= NLRI as per current AFI/SAFI definition
o NLRI=符合当前AFI/SAFI定义的NLRI
This is in addition to the current mode of operation allowing advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2> and <1/4> with a next hop address of IPv4 type and advertisement of NLRI for <AFI/ SAFI> of <1/128> with a next hop address of VPN-IPv4 type.
这是对当前操作模式的补充，当前操作模式允许使用IPv4类型的下一跳地址为<1/1>、<1/2>和<1/4>的<AFI/SAFI>播发NLRI，以及使用VPN-IPv4类型的下一跳地址为<1/128>的<AFI/SAFI>播发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. When the Length of Next Hop Address field is equal to 16 or 32, the next hop address is of type IPv6.
接收广告的BGP扬声器必须使用下一跳地址的长度字段来确定下一跳地址所属的网络层协议。当下一跳地址字段的长度等于16或32时，下一跳地址的类型为IPv6。
Note that this method of using the Length of the 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 used in [RFC4684] and [L2VPN-SIG].
请注意，使用下一跳地址字段的长度来确定下一跳地址所属的网络层协议（在AFI/SAFI定义允许的协议集之外）的这种方法与[RFC4684]和[L2VPN-SIG]中使用的方法相同。
[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 new capability that can be advertised using [RFC5492] and that is 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]定义了一种机制，允许两个BGP扬声器发现其BGP对等方是否支持特定功能，从而确定该功能是否可用于该对等方。本文档定义了一种新的功能，该功能可以使用[RFC5492]进行广告，称为扩展的下一跳编码功能。此功能允许BGP演讲者发现，对于给定的NLRI<AFI/SAFI>，对等方是否支持下一跳的广告，其网络协议由下一跳地址字段的长度值决定，如第3节所述。
A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use the Capability Advertisement procedures defined in [RFC5492] with the Extended Next Hop Encoding Capability to establish 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:
根据本规范，希望向BGP对等方播发IPv4 NLRI或VPN-IPv4 NLRI的IPv6下一跳的BGP扬声器必须使用[RFC5492]中定义的具有扩展下一跳编码能力的能力播发过程，以确定其对等方是否支持感兴趣的NLRI AFI/SAFI对。“能力”可选参数中的字段必须设置如下：
o The Capability Code field MUST be set to 5 (which indicates the Extended Next Hop Encoding capability).
o “能力代码”字段必须设置为5（表示扩展的下一跳编码能力）。
o The Capability Length field is set to a variable value that is the length of the Capability Value field (which follows).
o “能力长度”字段设置为可变值，即能力值字段的长度（如下所示）。
o The Capability Value field has the following format:
o “能力值”字段的格式如下：
+-----------------------------------------------------+
| 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) |
+-----------------------------------------------------+
+-----------------------------------------------------+
| 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 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>表示可以用属于Nexthop-AFI的网络层协议的下一跳地址通告<NLRI-AFI/NLRI-SAFI>的NLRI。
* the AFI and SAFI values are defined in the Address Family Identifier and Subsequent Address Family Identifier registries maintained by IANA.
* AFI和SAFI值在IANA维护的地址族标识符和后续地址族标识符注册表中定义。
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下一跳的广告，因此本规范仅允许在扩展下一跳编码能力的能力值字段中使用以下值：
o NLRI AFI = 1 (IPv4)
o NLRI AFI=1（IPv4）
o NLRI SAFI = 1, 2, 4, or 128
o NLRI SAFI=1、2、4或128
o Nexthop AFI = 2 (IPv6)
o Nexthop AFI=2（IPv6）
This specification does not propose that the Extended Next Hop
Encoding capability be used with any other combinations of <NLRI AFI,
NLRI SAFI, Nexthop AFI>. In particular, this specification does not
propose that the Extended Next Hop Encoding capability be used for
NLRI AFI/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 does not propose that the Extended Next Hop Encoding
capability be used for NLRI AFI/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 IPv4 Next Hop as per
[RFC4798] and AFI/SAFI = <2/128> with IPv4 Next Hop as per
[RFC4659]).
This specification does not propose that the Extended Next Hop
Encoding capability be used with any other combinations of <NLRI AFI,
NLRI SAFI, Nexthop AFI>. In particular, this specification does not
propose that the Extended Next Hop Encoding capability be used for
NLRI AFI/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 does not propose that the Extended Next Hop Encoding
capability be used for NLRI AFI/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 IPv4 Next Hop as per
[RFC4798] and AFI/SAFI = <2/128> with IPv4 Next Hop as per
[RFC4659]).
It is expected that if new AFI/SAFIs are defined in the future, their definition will have provisions (where appropriate) for both IPv4 and IPv6 Next Hops from the onset, with determination based on Length of Next Hop Address field. Thus, new AFI/SAFIs are not expected to make use of the Extended Next Hop Encoding capability.
预计如果将来定义新的AFI/SAFI，它们的定义将从一开始就为IPv4和IPv6下一个跃点做出规定（如适用），并根据下一个跃点地址字段的长度进行确定。因此，新的AFI/SAFI预计不会使用扩展的下一跳编码能力。
A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained via BGP Capability Advertisement that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
如果BGP演讲者首先通过BGP能力公告确定BGP对等方支持相关AFI/SAFI对的扩展下一跳编码能力，则BGP演讲者必须仅向BGP对等方公告具有IPv6下一跳的IPv4或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
扩展的下一跳编码功能提供关于给定AFI/SAFI的下一跳编码的信息，假设AFI/SAFI是
allowed. It does not influence whether that AFI/SAFI is indeed allowed. Whether a AFI/SAFI can be used between the BGP peers is purely determined through the Multiprotocol Extensions capability defined in [RFC4760].
允许。这并不影响是否确实允许AFI/SAFI。BGP对等方之间是否可以使用AFI/SAFI完全取决于[RFC4760]中定义的多协议扩展功能。
The Extended Next Hop Encoding capability MAY be dynamically updated through the use of the Dynamic Capability capability and associated mechanisms defined in [DYN-CAP].
可通过使用动态能力和[DYN-CAP]中定义的相关机制来动态更新扩展的下一跳编码能力。
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扬声器将其自己的地址作为下一个跃点，则应使用正在更新的NLRI的AFI/SAFI定义中指定的编码规则，将下一个跃点地址指定为IPvx地址。此默认行为可能被策略覆盖。
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客户端能够处理它们中任何一个可能生成的任何编码。
The extensions defined in this document may be used as discussed in [MESH-FMWK] 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.
如[MESH-FMWK]所述，本文档中定义的扩展可用于IPv6主干上IPV4孤岛的互连。在此应用程序中，地址族边界路由器（AFBR；如[RFC4925]中所定义）在MP_REACH_NLRI中公布IPv4 NLRI以及IPv6下一跳。
The MP_REACH_NLRI is encoded with:
MP_REACH_NLRI编码为：
o AFI = 1
o AFI=1
o SAFI = 1
o SAFI=1
o Length of Next Hop Network Address = 16 (or 32)
o 下一跳网络地址的长度=16（或32）
o Network Address of Next Hop = IPv6 address of Next Hop
o 下一跳的网络地址=下一跳的IPv6地址
o NLRI = IPv4 routes
o NLRI=IPv4路由
During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
在BGP能力公告期间，PE路由器将在能力可选参数中包括以下字段：
o Capability Code set to "Extended Next Hop Encoding"
o 功能代码设置为“扩展下一跳编码”
o Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2>
o 容量值包含<NLRI AFI=1，NLRI SAFI=1，Nexthop AFI=2>
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路由器将在MP_REACH_NLRI中公布VPN-IPv4 NLRI以及IPv6下一跳。
The MP_REACH_NLRI is encoded with:
MP_REACH_NLRI编码为：
o AFI = 1
o AFI=1
o SAFI = 128
o SAFI=128
o Length of Next Hop Network Address = 16 (or 32)
o 下一跳网络地址的长度=16（或32）
o Network Address of Next Hop = IPv6 address of Next Hop
o 下一跳的网络地址=下一跳的IPv6地址
o NLRI = IPv4-VPN routes
o NLRI=IPv4 VPN路由
During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
在BGP能力公告期间，PE路由器将在能力可选参数中包括以下字段：
o Capability Code set to "Extended Next Hop Encoding"
o 功能代码设置为“扩展下一跳编码”
o Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop AFI=2>
o 容量值包含<NLRI AFI=1，NLRI SAFI=128，Nexthop AFI=2>
This document defines, in Section 4, a new Capability Code to indicate the Extended Next Hop Encoding capability in the [RFC5492] Capabilities Optional Parameter. The value for this new Capability Code is 5, which is in the range set aside for allocation using the "IETF Review" policy defined in [RFC5226].
本文件在第4节中定义了一个新的能力代码，以在[RFC5492]能力可选参数中指示扩展的下一跳编码能力。此新能力代码的值为5，在使用[RFC5226]中定义的“IETF审查”策略分配时预留的范围内。
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的多协议扩展之外，本文件不会提出任何其他安全问题。同样的安全机制也适用。
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 next hop address) need to keep this case in mind also.
虽然预计不是典型情况，但用作BGP下一跳地址的IPv6地址可以是IPv4映射的IPv6地址（如[RFC4291]中所定义）。网络运营商可能部署的安全机制的配置（如下一跳地址的安全检查）也需要记住这种情况。
The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in this document.
作者要感谢Yakov Rekhter、Pranav Mehta和John Scudder对本文件中定义的方法的贡献。
[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月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[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虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
[RFC5492]Scudder，J.和R.Chandra，“BGP-4的能力广告”，RFC 5492，2009年2月。
[DYN-CAP] Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, November 2006.
[DYN-CAP]Chen，E.和S.Sangli，“BGP-4的动态能力”，正在进行的工作，2006年11月。
[L2VPN-SIG] Rosen, E., "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, May 2006.
[L2VPN-SIG]Rosen，E.，“L2VPN中的资源调配、自动发现和信令”，正在进行的工作，2006年5月。
[MESH-FMWK] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", Work in Progress, February 2009.
[MESH-FMWK]Wu，J.，Cui，Y.，Metz，C.，和E.Rosen，“软线网格框架”，正在进行的工作，2009年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]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月。
[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]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月。
[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]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]Li，X.，Dawkins，S.，Ward，D.，和A.Durand，“软线问题声明”，RFC 49252007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
弗朗索瓦·勒·福彻思科系统公司绿边，法国索菲亚·安提波利斯大道400号，邮编：06410
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Eric Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Eric Rosen Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com