Network Working Group T. Bates
Request for Comments: 4760 Cisco Systems
Obsoletes: 2858 R. Chandra
Category: Standards Track Sonoa Systems
D. Katz
Y. Rekhter
Juniper Networks
January 2007
Network Working Group T. Bates
Request for Comments: 4760 Cisco Systems
Obsoletes: 2858 R. Chandra
Category: Standards Track Sonoa Systems
D. Katz
Y. Rekhter
Juniper Networks
January 2007
Multiprotocol Extensions for BGP-4
BGP-4的多协议扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
本文档定义了BGP-4的扩展，使其能够承载多个网络层协议（如IPv6、IPX、L3VPN等）的路由信息。扩展是向后兼容的-支持扩展的路由器可以与不支持扩展的路由器进行互操作。
The only three pieces of information carried by BGP-4 [BGP-4] that are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI (expressed as IPv4 address prefixes). This document assumes that any BGP speaker (including the one that supports multiprotocol capabilities defined in this document) has to have an IPv4 address (which will be used, among other things, in the AGGREGATOR attribute). Therefore, to enable BGP-4 to support routing for multiple Network Layer protocols, the only two things that have to be added to BGP-4 are (a) the ability to associate a particular Network Layer protocol with the next hop information, and (b) the ability to associate a particular Network Layer protocol with NLRI. To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI, this document uses a combination of Address Family, as defined in [IANA-AF], and Subsequent Address Family (as described in this document).
BGP-4[BGP-4]承载的三条特定于IPv4的信息是（a）下一跳属性（表示为IPv4地址），（b）聚合器（包含IPv4地址）和（c）NLRI（表示为IPv4地址前缀）。本文档假设任何BGP演讲者（包括本文档中定义的支持多协议功能的演讲者）必须具有IPv4地址（除其他外，将在聚合器属性中使用该地址）。因此，为了使BGP-4能够支持多个网络层协议的路由，只需向BGP-4添加两件事：（a）将特定网络层协议与下一跳信息关联的能力，以及（b）将特定网络层协议与NLRI关联的能力。为了识别与NLRI的下一跳信息和语义相关联的各个网络层协议，本文档使用[IANA-AF]中定义的地址族和后续地址族（如本文档所述）的组合。
One could further observe that the next hop information (the information provided by the NEXT_HOP attribute) is meaningful (and necessary) only in conjunction with the advertisements of reachable destinations - in conjunction with the advertisements of unreachable destinations (withdrawing routes from service), the next hop information is meaningless. This suggests that the advertisement of reachable destinations should be grouped with the advertisement of the next hop to be used for these destinations, and that the advertisement of reachable destinations should be segregated from the advertisement of unreachable destinations.
可以进一步观察到，下一跳信息（由下一跳属性提供的信息）仅与可到达目的地的广告结合（与不可到达目的地的广告结合）（从服务中撤回路由）是有意义的（和必要的），下一跳信息是没有意义的。这表明可到达目的地的广告应与用于这些目的地的下一跳广告分组，并且可到达目的地的广告应与不可到达目的地的广告分离。
To provide backward compatibility, as well as to simplify introduction of the multiprotocol capabilities into BGP-4, this document uses two new attributes, Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the set of reachable destinations together with the next hop information to be used for forwarding to these destinations. The second one (MP_UNREACH_NLRI) is used to carry the set of unreachable destinations. Both of these attributes are optional and non-transitive. This way, a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the information carried in these attributes and will not pass it to other BGP speakers.
为了提供向后兼容性，以及简化将多协议功能引入BGP-4的过程，本文档使用了两个新属性：多协议可访问NLRI（MP_REACH_NLRI）和多协议不可访问NLRI（MP_UNREACH_NLRI）。第一个（MP_REACH_NLRI）用于携带可到达目的地集以及用于转发到这些目的地的下一跳信息。第二个（MP_UNREACH_NLRI）用于承载一组无法到达的目的地。这两个属性都是可选的和不可传递的。这样，不支持多协议功能的BGP演讲者只会忽略这些属性中包含的信息，而不会将其传递给其他BGP演讲者。
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]中所述进行解释。
3. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
3. 多协议可达NLRI-MP_可达NLRI（类型代码14）：
This is an optional non-transitive attribute that can be used for the following purposes:
这是一个可选的非传递属性，可用于以下目的：
(a) to advertise a feasible route to a peer
(a) 向同行宣传可行的路线
(b) to permit a router to advertise the Network Layer address of the router that should be used as the next hop to the destinations listed in the Network Layer Reachability Information field of the MP_NLRI attribute.
(b) 允许路由器公布路由器的网络层地址，该地址应作为MP_NLRI属性的网络层可达性信息字段中列出的目的地的下一个跃点。
The attribute is encoded as shown below:
该属性的编码如下所示：
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
The use and meaning of these fields are as follows:
这些字段的用法和含义如下：
Address Family Identifier (AFI):
地址族标识符（AFI）：
This field in combination with the Subsequent Address Family Identifier field identifies the set of Network Layer protocols to which the address carried in the Next Hop field must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop MUST provide a way to determine its Network Layer protocol.
该字段与后续地址族标识符字段相结合，标识下一跳字段中携带的地址必须属于的网络层协议集、下一跳地址的编码方式以及随后的网络层可达性信息的语义。如果允许下一跳来自多个网络层协议，则下一跳的编码必须提供确定其网络层协议的方法。
Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF].
目前为地址族标识符字段定义的值在IANA的地址族编号注册表[IANA-AF]中指定。
Subsequent Address Family Identifier (SAFI):
后续地址系列标识符（SAFI）：
This field in combination with the Address Family Identifier field identifies the set of Network Layer protocols to which the address carried in the Next Hop must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop MUST provide a way to determine its Network Layer protocol.
该字段与地址族标识符字段相结合，标识下一跳中携带的地址必须属于的一组网络层协议、下一跳地址的编码方式以及随后的网络层可达性信息的语义。如果允许下一跳来自多个网络层协议，则下一跳的编码必须提供确定其网络层协议的方法。
Length of Next Hop Network Address:
下一跳网络地址的长度：
A 1-octet field whose value expresses the length of the "Network Address of Next Hop" field, measured in octets.
一个1个八位字节的字段，其值表示“下一跳的网络地址”字段的长度，以八位字节为单位。
Network Address of Next Hop:
下一跳的网络地址：
A variable-length field that contains the Network Address of the next router on the path to the destination system. The Network Layer protocol associated with the Network Address of the Next Hop is identified by a combination of <AFI, SAFI> carried in the attribute.
一个可变长度字段，包含目标系统路径上下一个路由器的网络地址。与下一跳的网络地址相关联的网络层协议由属性中携带的<AFI，SAFI>的组合标识。
Reserved:
保留：
A 1 octet field that MUST be set to 0, and SHOULD be ignored upon receipt.
必须设置为0的1个八位字节字段，在收到时应忽略该字段。
Network Layer Reachability Information (NLRI):
网络层可达性信息（NLRI）：
A variable length field that lists NLRI for the feasible routes that are being advertised in this attribute. The semantics of NLRI is identified by a combination of <AFI, SAFI> carried in the attribute.
一个可变长度字段，列出此属性中正在播发的可行路由的NLRI。NLRI的语义由属性中携带的<AFI，SAFI>的组合标识。
When the Subsequent Address Family Identifier field is set to one of the values defined in this document, each NLRI is encoded as specified in the "NLRI encoding" section of this document.
当后续地址族标识符字段设置为本文档中定义的一个值时，每个NLRI将按照本文档“NLRI编码”部分中的规定进行编码。
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message.
MP_REACH_NLRI path属性中包含的下一跳信息定义了路由器的网络层地址，该地址应用作更新消息中MP_NLRI属性中列出的目的地的下一跳。
The rules for the next hop information are the same as the rules for the information carried in the NEXT_HOP BGP attribute (see Section 5.1.3 of [BGP-4]).
下一跳信息的规则与下一跳BGP属性中携带的信息的规则相同（见[BGP-4]第5.1.3节）。
An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute.
携带MP_REACH_NLRI的更新消息还必须携带ORIGIN和AS_PATH属性（在EBGP和IBGP交换中）。此外，在IBGP交换中，这样的消息还必须带有LOCAL_PREF属性。
An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute.
不携带NLRI的更新消息（MP_REACH_NLRI属性中编码的消息除外）不应携带NEXT_HOP属性。如果此类消息包含下一跳属性，则接收消息的BGP扬声器应忽略此属性。
An UPDATE message SHOULD NOT include the same address prefix (of the same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined.
更新消息不应在以下多个字段中包含相同的地址前缀（相同的<AFI，SAFI>）：撤回路由字段、网络可达性信息字段、MP_REACH_NLRI字段和MP_UNREACH_NLRI字段。此表单中的更新消息处理未定义。
4. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
4. 多协议不可访问NLRI-MP_UNREACH_NLRI（类型代码15）：
This is an optional non-transitive attribute that can be used for the purpose of withdrawing multiple unfeasible routes from service.
这是一个可选的非传递属性，可用于从服务中提取多个不可行的路由。
The attribute is encoded as shown below:
该属性的编码如下所示：
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Withdrawn Routes (variable) |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Withdrawn Routes (variable) |
+---------------------------------------------------------+
The use and the meaning of these fields are as follows:
这些字段的用途和含义如下：
Address Family Identifier (AFI):
地址族标识符（AFI）：
This field in combination with the Subsequent Address Family Identifier field identifies the set of Network Layer protocols to which the address carried in the Next Hop field must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop MUST provide a way to determine its Network Layer protocol.
该字段与后续地址族标识符字段相结合，标识下一跳字段中携带的地址必须属于的网络层协议集、下一跳地址的编码方式以及随后的网络层可达性信息的语义。如果允许下一跳来自多个网络层协议，则下一跳的编码必须提供确定其网络层协议的方法。
Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF].
目前为地址族标识符字段定义的值在IANA的地址族编号注册表[IANA-AF]中指定。
Subsequent Address Family Identifier (SAFI):
后续地址系列标识符（SAFI）：
This field in combination with the Address Family Identifier field identifies the set of Network Layer protocols to which the address carried in the Next Hop must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop MUST provide a way to determine its Network Layer protocol.
该字段与地址族标识符字段相结合，标识下一跳中携带的地址必须属于的一组网络层协议、下一跳地址的编码方式以及随后的网络层可达性信息的语义。如果允许下一跳来自多个网络层协议，则下一跳的编码必须提供确定其网络层协议的方法。
Withdrawn Routes Network Layer Reachability Information:
撤回的路由网络层可达性信息：
A variable-length field that lists NLRI for the routes that are being withdrawn from service. The semantics of NLRI is identified by a combination of <AFI, SAFI> carried in the attribute.
一个可变长度字段，列出正在退出服务的路由的NLRI。NLRI的语义由属性中携带的<AFI，SAFI>的组合标识。
When the Subsequent Address Family Identifier field is set to one of the values defined in this document, each NLRI is encoded as specified in the "NLRI encoding" section of this document.
当后续地址族标识符字段设置为本文档中定义的一个值时，每个NLRI将按照本文档“NLRI编码”部分中的规定进行编码。
An UPDATE message that contains the MP_UNREACH_NLRI is not required to carry any other path attributes.
包含MP_UNREACH_NLRI的更新消息不需要携带任何其他路径属性。
The Network Layer Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
网络层可达性信息被编码为<length，prefix>形式的一个或多个2元组，其字段描述如下：
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
这些字段的用途和含义如下：
a) Length:
a) 长度：
The Length field indicates the length, in bits, of the address prefix. A length of zero indicates a prefix that matches all (as specified by the address family) addresses (with prefix, itself, of zero octets).
长度字段以位表示地址前缀的长度。长度为零表示与所有（由地址系列指定的）地址（前缀本身为零个八位字节）匹配的前缀。
b) Prefix:
b) 前缀：
The Prefix field contains an address prefix followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.
前缀字段包含一个地址前缀，后跟足够的尾随位，以使字段的结尾落在八位字节边界上。请注意，尾随位的值是无关的。
This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes:
本文档为MP_REACH_NLRI和MP_UNREACH_NLRI属性中的后续地址族标识符字段定义了以下值：
1 - Network Layer Reachability Information used for unicast forwarding
1-用于单播转发的网络层可达性信息
2 - Network Layer Reachability Information used for multicast forwarding
2-用于多播转发的网络层可达性信息
An implementation MAY support all, some, or none of the Subsequent Address Family Identifier values defined in this document.
实现可能支持本文档中定义的所有、部分或任何后续地址族标识符值。
If a BGP speaker receives from a neighbor an UPDATE message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if the speaker determines that the attribute is incorrect, the speaker MUST delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute. For the duration of the BGP session over which the UPDATE message was received, the speaker then SHOULD ignore all the subsequent routes with that AFI/SAFI received over that session.
如果BGP扬声器从邻居接收到包含MP_REACH_NLRI或MP_UNREACH_NLRI属性的更新消息，并且如果扬声器确定该属性不正确，演讲者必须删除从其AFI/SAFI与错误MP_REACH_NLRI或MP_UNREACH_NLRI属性中携带的相同的邻居接收的所有BGP路由。在收到更新消息的BGP会话期间，演讲者应忽略该会话期间收到的AFI/SAFI的所有后续路由。
In addition, the speaker MAY terminate the BGP session over which the UPDATE message was received. The session SHOULD be terminated with the Notification message code/subcode indicating "UPDATE Message Error"/"Optional Attribute Error".
此外，说话者可以终止接收更新消息的BGP会话。应使用指示“更新消息错误”/“可选属性错误”的通知消息代码/子代码终止会话。
A BGP speaker that uses Multiprotocol Extensions SHOULD use the Capability Advertisement procedures [BGP-CAP] to determine whether the speaker could use Multiprotocol Extensions with a particular peer.
使用多协议扩展的BGP演讲者应使用能力公告程序[BGP-CAP]来确定演讲者是否可以对特定对等方使用多协议扩展。
The fields in the Capabilities Optional Parameter are set as follows. The Capability Code field is set to 1 (which indicates Multiprotocol Extensions capabilities). The Capability Length field is set to 4. The Capability Value field is defined as:
Capabilities可选参数中的字段设置如下。Capability Code字段设置为1（表示多协议扩展功能）。“能力长度”字段设置为4。能力值字段定义为：
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
The use and meaning of this field is as follow:
该字段的用途和含义如下：
AFI - Address Family Identifier (16 bit), encoded the same way as in the Multiprotocol Extensions
AFI—地址族标识符（16位），编码方式与多协议扩展中的编码方式相同
Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver.
Res.-保留（8位）字段。发送方应将设置为0，接收方应忽略。
Note that not setting the field value to 0 may create issues for a receiver not ignoring the field. In addition, this definition is problematic if it is ever attempted to redefine the field.
请注意，如果不将字段值设置为0，可能会为不忽略该字段的接收者造成问题。此外，如果试图重新定义字段，则此定义存在问题。
SAFI - Subsequent Address Family Identifier (8 bit), encoded the same way as in the Multiprotocol Extensions.
SAFI—后续地址族标识符（8位），编码方式与多协议扩展中的编码方式相同。
A speaker that supports multiple <AFI, SAFI> tuples includes them as multiple Capabilities in the Capabilities Optional Parameter.
支持多个<AFI，SAFI>元组的说话人在Capabilities可选参数中将它们作为多个功能包含。
To have a bi-directional exchange of routing information for a particular <AFI, SAFI> between a pair of BGP speakers, each such speaker MUST advertise to the other (via the Capability Advertisement mechanism) the capability to support that particular <AFI, SAFI> route.
为了在一对BGP扬声器之间为特定的<AFI，SAFI>双向交换路由信息，每个这样的扬声器必须（通过能力公告机制）向另一个播发支持该特定<AFI，SAFI>路由的能力。
As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI attributes contain the Subsequence Address Family Identifier (SAFI) field. The SAFI name space is defined in this document. The IANA registered and maintains values for the SAFI namespace as follows:
如本文档所述，MP_REACH_NLRI和MP_UNREACH_NLRI属性包含子序列地址族标识符（SAFI）字段。SAFI名称空间在本文档中定义。IANA注册并维护SAFI命名空间的值，如下所示：
- SAFI values 1 and 2 are assigned in this document.
- 本文件中指定了SAFI值1和2。
- SAFI value 3 is reserved. It was assigned by RFC 2858 for a use that was never fully implemented, so it is deprecated by this document.
- 保留SAFI值3。它是由RFC 2858分配的，用于从未完全实现的用途，因此本文档不推荐使用它。
- SAFI values 5 through 63 are to be assigned by IANA using either the Standards Action process, defined in [RFC2434], or the Early IANA Allocation process, defined in [RFC4020].
- IANA将使用[RFC2434]中定义的标准行动流程或[RFC4020]中定义的早期IANA分配流程分配SAFI值5至63。
- SAFI values 67 through 127 are to be assigned by IANA, using the "First Come First Served" policy, defined in RFC 2434.
- IANA将使用RFC 2434中定义的“先到先得”策略分配SAFI值67至127。
- SAFI values 0 and 255 are reserved.
- SAFI值0和255保留。
- SAFI values 128 through 240 are part of the previous "private use" range. At the time of approval of this document, the unused values were provided to IANA by the Routing Area Director. These unused values, namely, 130, 131, 135 through 139, and 141 through 240, are considered reserved in order to avoid conflicts.
- SAFI值128到240是以前“专用”范围的一部分。在批准本文件时，未使用的值由路由区域主管提供给IANA。这些未使用的值，即130、131、135到139和141到240，被认为是保留的，以避免冲突。
- SAFI values 241 through 254 are for "private use", and values in this range are not to be assigned by IANA.
- SAFI值241至254仅供“私人使用”，IANA不分配此范围内的值。
This document makes the use of the next hop information consistent with the information carried in the NEXT_HOP BGP path attribute.
本文档使用的下一跳信息与下一跳BGP路径属性中携带的信息一致。
This document removes the definition of SAFI 3 and deprecates SAFI 3.
本文档删除了SAFI 3的定义，不推荐SAFI 3。
This document changes partitioning of the SAFI space. Specifically, in RFC 2858 SAFI values 128 through 240 were part of the "private use" range. This document specifies that of this range, allocations that are currently in use are to be recognized by IANA, and that unused values, namely 130, 131, 135 through 139, and 141 through 240, should be considered reserved.
本文档更改了SAFI空间的分区。具体而言，在RFC 2858中，SAFI值128到240属于“专用”范围。本文件规定，在该范围内，IANA将识别当前正在使用的分配，未使用的值，即130、131、135至139和141至240，应视为保留。
This document renames the Number of SNPAs field to Reserved and removes the rest of the SNPA-related information from the MP_REACH_NLRI attribute.
本文档将SNPA编号字段重命名为Reserved，并从MP_REACH_NLRI属性中删除其余SNPA相关信息。
This document restricts the MP_REACH_NLRI attribute to carry only a single instance of <AFI, SAFI, Next Hop Information, ...>.
此文档限制MP_REACH_NLRI属性仅携带<AFI、SAFI、下一跳信息，…>的单个实例。
This document restricts the MP_UNREACH_NLRI attribute to carry only a single instance of <AFI, SAFI, ...>.
本文档限制MP_UNREACH_NLRI属性仅携带<AFI，SAFI，…>的单个实例。
This document clarifies handling of an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute.
本文档阐明了对不携带NLRI的更新消息的处理，MP_REACH_NLRI属性中编码的消息除外。
This document clarifies error handling in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI attributes.
本文档阐明了存在MP_REACH_NLRI或MP_UNREACH_NLRI属性时的错误处理。
This document specifies the use of BGP Capabilities Advertisements in conjunction with multi-protocol extensions.
本文档规定了BGP功能广告与多协议扩展的结合使用。
Finally, this document includes the "IANA Consideration" section.
最后，本文件包括“IANA考虑”部分。
This extension to BGP does not change the underlying security issues inherent in the existing BGP.
BGP的此扩展不会改变现有BGP中固有的基本安全问题。
The authors would like to thank members of the IDR Working Group for their review and comments.
作者要感谢IDR工作组成员的审查和评论。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[BGP-CAP]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-4]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[IANA-AF] "Address Family Numbers", Reachable from
http://www.iana.org/numbers.html
[IANA-AF] "Address Family Numbers", Reachable from
http://www.iana.org/numbers.html
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020]Kompella，K.和A.Zinin，“早期IANA标准轨道代码点分配”，BCP 100，RFC 4020，2005年2月。
Authors' Addresses
作者地址
Tony Bates Cisco Systems, Inc. EMail: tbates@cisco.com
Tony Bates Cisco Systems，Inc.电子邮件：tbates@cisco.com
Ravi Chandra Sonoa Systems EMail: rchandra@sonoasystems.com
Ravi Chandra Sonoa系统电子邮件：rchandra@sonoasystems.com
Dave Katz Juniper Networks, Inc. EMail: dkatz@juniper.net
Dave Katz Juniper Networks，Inc.电子邮件：dkatz@juniper.net
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks，Inc.电子邮件：yakov@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。