Network Working Group T. Bates
Request for Comments: 2858 Y. Rekhter
Obsoletes: 2283 Cisco Systems
Category: Standards Track R. Chandra
Redback Networks Inc
D. Katz
Juniper Networks
June 2000
Network Working Group T. Bates
Request for Comments: 2858 Y. Rekhter
Obsoletes: 2283 Cisco Systems
Category: Standards Track R. Chandra
Redback Networks Inc
D. Katz
Juniper Networks
June 2000
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 Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, 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[BGP-4]只能承载IPv4[IPv4]的路由信息。本文档定义了BGP-4的扩展，使其能够承载多个网络层协议（如IPv6、IPX等）的路由信息。扩展是向后兼容的-支持扩展的路由器可以与不支持扩展的路由器进行互操作。
This document obsoletes RFC 2283.
本文件废除了RFC 2283。
The only three pieces of information carried by 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
BGP-4承载的唯一三条特定于IPv4的信息是（a）下一跳属性（表示为IPv4地址），（b）聚合器（包含IPv4地址）和（c）NLRI（表示为IPv4地址前缀）。本文档假设任何BGP演讲者（包括本文档中定义的支持多协议功能的演讲者）必须具有IPv4地址（除其他外，将在聚合器属性中使用该地址）。因此，要使BGP-4支持多个网络层协议的路由，只需向BGP-4添加两件事：（a）将特定网络层协议与下一跳信息关联的能力，以及（b）将
associated a particular Network Layer protocol with NLRI. To identify individual Network Layer protocols this document uses Address Family, as defined in [RFC1700].
将特定网络层协议与NLRI关联。为了识别各个网络层协议，本文档使用[RFC1700]中定义的地址族。
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演讲者。
2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
2. 多协议可达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属性的网络层可达性信息字段中列出的目的地的下一个跃点。
(c) to allow a given router to report some or all of the Subnetwork Points of Attachment (SNPAs) that exist within the local system
(c) 允许给定路由器报告本地系统中存在的部分或全部子网连接点（SNPA）
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) |
+---------------------------------------------------------+
| Number of SNPAs (1 octet) |
+---------------------------------------------------------+
| Length of first SNPA(1 octet) |
+---------------------------------------------------------+
| First SNPA (variable) |
+---------------------------------------------------------+
| Length of second SNPA (1 octet) |
+---------------------------------------------------------+
| Second SNPA (variable) |
+---------------------------------------------------------+
| ... |
+---------------------------------------------------------+
| Length of Last SNPA (1 octet) |
+---------------------------------------------------------+
| Last SNPA (variable) |
+---------------------------------------------------------+
| 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) |
+---------------------------------------------------------+
| Number of SNPAs (1 octet) |
+---------------------------------------------------------+
| Length of first SNPA(1 octet) |
+---------------------------------------------------------+
| First SNPA (variable) |
+---------------------------------------------------------+
| Length of second SNPA (1 octet) |
+---------------------------------------------------------+
| Second SNPA (variable) |
+---------------------------------------------------------+
| ... |
+---------------------------------------------------------+
| Length of Last SNPA (1 octet) |
+---------------------------------------------------------+
| Last SNPA (variable) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
The use and meaning of these fields are as follows:
这些字段的用法和含义如下：
Address Family Identifier:
地址族标识符：
This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section).
此字段携带与以下网络地址关联的网络层协议的标识。RFC 1700中指定了此字段的当前定义值（请参阅“地址族编号”部分）。
Subsequent Address Family Identifier:
后续地址族标识符：
This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute.
此字段提供有关属性中包含的网络层可达性信息类型的附加信息。
Length of Next Hop Network Address:
下一跳网络地址的长度：
A 1 octet field whose value expresses the length of the "Network Address of Next Hop" field as 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
一个可变长度字段，包含目标系统路径上下一个路由器的网络地址
Number of SNPAs:
SNPA的数量：
A 1 octet field which contains the number of distinct SNPAs to be listed in the following fields. The value 0 may be used to indicate that no SNPAs are listed in this attribute.
一个1个八位字节的字段，其中包含要在以下字段中列出的不同SNPA的数量。值0可用于指示此属性中未列出SNPA。
Length of Nth SNPA:
第n个SNPA的长度：
A 1 octet field whose value expresses the length of the "Nth SNPA of Next Hop" field as measured in semi-octets
一个1个八位字节的字段，其值表示以半八位字节测量的“下一跳的第n个SNPA”字段的长度
Nth SNPA of Next Hop:
下一跳的第n个SNPA：
A variable length field that contains an SNPA of the router whose Network Address is contained in the "Network Address of Next Hop" field. The field length is an integral number of octets in length, namely the rounded-up integer value of one half the SNPA length expressed in semi-octets; if the SNPA contains an odd number of semi-octets, a value in this field will be padded with a trailing all-zero semi-octet.
一个可变长度字段，包含路由器的SNPA，其网络地址包含在“下一跳的网络地址”字段中。字段长度是长度为八位字节的整数，即以半八位字节表示的SNPA长度的一半的向上舍入整数值；如果SNPA包含奇数个半八位字节，则此字段中的值将用尾随的全零半八位字节填充。
Network Layer Reachability Information:
网络层可达性信息：
A variable length field that lists NLRI for the feasible routes that are being advertised in this attribute. 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将按照本文档“NLRI编码”部分中的规定进行编码。
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the border router that should be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message. When advertising a MP_REACH_NLRI attribute to an external peer, a router may use one of its own interface addresses in the next hop component of the attribute, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. This is known as a "first party" next hop. A BGP speaker can advertise to an external
MP_REACH_NLRI path属性中包含的下一跳信息定义了边界路由器的网络层地址，该地址应用作更新消息中MP_NLRI属性中列出的目的地的下一跳。当向外部对等方公布MP_REACH_NLRI属性时，路由器可以在该属性的下一跳组件中使用其自己的接口地址之一，前提是正在公布路由的外部对等方与下一跳地址共享公共子网。这被称为“第一方”下一跳。BGP扬声器可以向外部广播
peer an interface of any internal peer router in the next hop component, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. This is known as a "third party" next hop information. A BGP speaker can advertise any external peer router in the next hop component, provided that the Network Layer address of this border router was learned from an external peer, and the external peer to which the route is being advertised shares a common subnet with the next hop address. This is a second form of "third party" next hop information.
对等路由器下一跳组件中任何内部对等路由器的接口，前提是该路由所通告到的外部对等路由器与下一跳地址共享一个公共子网。这被称为“第三方”下一跳信息。BGP扬声器可以在下一跳组件中播发任何外部对等路由器，前提是该边界路由器的网络层地址是从外部对等方获悉的，并且正在播发路由的外部对等方与下一跳地址共享一个公共子网。这是第二种形式的“第三方”下一跳信息。
Normally the next hop information is chosen such that the shortest available path will be taken. A BGP speaker must be able to support disabling advertisement of third party next hop information to handle imperfectly bridged media or for reasons of policy.
通常选择下一跳信息，以便选择最短的可用路径。BGP演讲者必须能够支持禁用第三方下一跳信息的广告，以处理不完善的桥接媒体或出于政策原因。
A BGP speaker must never advertise an address of a peer to that peer as a next hop, for a route that the speaker is originating. A BGP speaker must never install a route with itself as the next hop.
对于说话人发起的路由，BGP说话人不得将对等方的地址作为下一跳播发给该对等方。BGP扬声器决不能将自身作为下一跳安装路由。
When a BGP speaker advertises the route to an internal peer, the advertising speaker should not modify the next hop information associated with the route. When a BGP speaker receives the route via an internal link, it may forward packets to the next hop address if the address contained in the attribute is on a common subnet with the local and remote BGP speakers.
当BGP演讲者向内部对等方播发路由时，播发演讲者不应修改与路由相关联的下一跳信息。当BGP扬声器通过内部链路接收到路由时，如果属性中包含的地址位于本地和远程BGP扬声器的公共子网中，则BGP扬声器可能会将数据包转发到下一跳地址。
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. If such a message is received from an external peer, the local system shall check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer than sent the message. If that is not the case, the local system shall send the NOTIFICATION message with Error Code UPDATE Message Error, and the Error Subcode set to Malformed AS_PATH.
携带MP_REACH_NLRI的更新消息还必须携带ORIGIN和AS_PATH属性（在EBGP和IBGP交换中）。此外，在IBGP交换中，这样的消息还必须带有LOCAL_PREF属性。如果从外部对等方接收到此类消息，本地系统应检查AS_路径属性中最左侧的AS是否等于发送消息的对等方的自治系统编号。如果情况并非如此，本地系统应发送带有错误代码UPDATE message Error的通知消息，并将错误子代码设置为格式错误的AS_PATH。
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扬声器应忽略此属性。
3. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
3. 多协议不可访问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:
地址族标识符：
This field carries the identity of the Network Layer protocol associated with the NLRI that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section).
此字段携带与后面的NLRI关联的网络层协议的标识。RFC 1700中指定了此字段的当前定义值（请参阅“地址族编号”部分）。
Subsequent Address Family Identifier:
后续地址族标识符：
This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute.
此字段提供有关属性中包含的网络层可达性信息类型的附加信息。
Withdrawn Routes:
撤销路线：
A variable length field that lists NLRI for the routes that are being withdrawn from service. 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将按照本文档“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-用于多播转发的网络层可达性信息
3 - Network Layer Reachability Information used for both unicast and multicast forwarding
3-用于单播和多播转发的网络层可达性信息
If a BGP speaker receives from a neighbor an Update message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and 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。能力值字段定义为：
The use and meaning of this field is as follow:
该字段的用途和含义如下：
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
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，接收方应忽略。
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> routes.
为了在一对BGP扬声器之间对特定的<AFI，SAFI>进行双向路由信息交换，每个这样的扬声器必须向另一个播发（通过能力播发机制）支持该特定<AFI，SAFI>路由的能力。
As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI attributes contain the Subsequence Address Family Identifier (SAFI) field. The SAFI name space is defined in Section 9. The IANA will maintain and register values for the SAFI namespace as follows. SAFI value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this document. SAFI values 4 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. SAFI values 64 through 127 are to be assigned by IANA, using the "First Come First
如本文档所述，MPL_REACH_NLRI和MP_UNRACH_NLRI属性包含子序列地址族标识符（SAFI）字段。SAFI名称空间在第9节中定义。IANA将维护和注册SAFI命名空间的值，如下所示。SAFI值0是保留的。SAFI值1、2和3在本文档中指定。IANA将使用RFC 2434中定义的“IETF共识”政策分配SAFI值4至63。SAFI值64至127由IANA使用“先到先得”分配
Served" policy defined in RFC 2434. SAFI values 128 through 255 are for "private use", and values in this range are not to be assigned by IANA.
RFC 2434中定义的“已服务”策略。SAFI值128到255用于“私人使用”，此范围内的值不由IANA分配。
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 [Heffernan].
BGP的这一扩展并没有改变现有BGP[Heffernan]固有的潜在安全问题。
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 2842, May 2000.
[BGP-CAP]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 2842，2000年5月。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[Heffernan]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1700] Postel, J. and J. K. Reynolds, "Assigned Numbers", STD
2, RFC 1700, October 1994. (see also
http://www.iana.org/iana/assignments.html)
[RFC1700] Postel, J. and J. K. Reynolds, "Assigned Numbers", STD
2, RFC 1700, October 1994. (see also
http://www.iana.org/iana/assignments.html)
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Tony Bates Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: tbates@cisco.com
EMail: tbates@cisco.com
Ravi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134
拉维·钱德拉Redback Networks Inc.位于加利福尼亚州圣何塞霍尔格路350号，邮编95134
EMail: rchandra@redback.com
EMail: rchandra@redback.com
Dave Katz Juniper Networks, Inc. 3260 Jay St. Santa Clara, CA 95054
Dave Katz Juniper Networks，Inc.加利福尼亚州圣克拉拉杰街3260号，邮编95054
EMail: dkatz@jnx.com
EMail: dkatz@jnx.com
Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
雅科夫·雷克特思科系统公司，地址：加利福尼亚州圣何塞市西塔斯曼大道170号，邮编：95134
EMail: yakov@cisco.com
EMail: yakov@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。