Network Working Group J. Scudder
Request for Comments: 5492 Juniper Networks
Obsoletes: 3392 R. Chandra
Category: Standards Track Sonoa Systems
February 2009
Network Working Group J. Scudder
Request for Comments: 5492 Juniper Networks
Obsoletes: 3392 R. Chandra
Category: Standards Track Sonoa Systems
February 2009
Capabilities Advertisement with 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) 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). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
本文档定义了一个称为Capabilities的可选参数，该参数通过提供优雅的功能广告而无需终止BGP对等，从而有助于在边界网关协议（BGP）中引入新功能。
This document obsoletes RFC 3392.
本文件淘汰了RFC 3392。
The base BGP-4 specification [RFC4271] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate the BGP peering. This complicates the introduction of new capabilities in BGP.
基本BGP-4规范[RFC4271]要求，当BGP扬声器接收到带有一个或多个无法识别的可选参数的开放消息时，扬声器必须终止BGP对等。这使得在BGP中引入新功能变得复杂。
This specification defines an Optional Parameter and processing rules that allow BGP speakers to communicate capabilities in an OPEN message. A pair of BGP speakers that supports this specification can establish the peering even when presented with unrecognized capabilities, so long as all capabilities required to support the peering are supported.
本规范定义了一个可选参数和处理规则，允许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]中所述进行解释。
When a BGP speaker [RFC4271] that supports capabilities advertisement sends an OPEN message to its BGP peer, the message MAY include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
当支持功能广告的BGP扬声器[RFC4271]向其BGP对等方发送打开消息时，该消息可能包括一个可选参数，称为功能。该参数列出了扬声器支持的功能。
A BGP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer.
BGP演讲者通过检查演讲者从对等方收到的开放消息所携带的capabilities可选参数中存在的能力列表来确定其对等方支持的能力。
A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines (as described above) that the peer supports this capability. Simply put, a given capability can be used on a peering if that capability has been advertised by both peers. If either peer has not advertised it, the capability cannot be used.
支持特定功能的BGP扬声器可在其对等方确定（如上所述）该对等方支持该功能后，将该功能用于其对等方。简单地说，如果一个对等方都宣传了一个给定的功能，那么该功能可以在该对等方上使用。如果任何一个对等方都没有公布该功能，则无法使用该功能。
A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter.
BGP演讲者在响应带有capabilities可选参数的打开消息时，如果演讲者接收到错误子代码设置为Unsupported可选参数的通知消息，则会确定其对等方不支持功能播发。（这是基本BGP-4规范[RFC4271]的结果，而不是新的要求。）在这种情况下，演讲者应尝试与对等方重新建立BGP连接，而无需向对等方发送能力可选参数。
If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer and terminate peering (see Section "Extensions to Error Handling" for more details). For example, a BGP speaker may need to terminate peering if it established peering to exchange IPv6 routes and determines that its peer does not support Multiprotocol Extensions for BGP-4 [RFC4760]. The Error Subcode in the NOTIFICATION message is then set to Unsupported Capability. The message MUST contain the capability or capabilities that cause the speaker to send the message. The decision to send the message and terminate the peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically.
如果支持特定功能的BGP扬声器确定其对等方不支持此功能，则扬声器可能会向对等方发送通知消息并终止对等（有关更多详细信息，请参阅“错误处理扩展”一节）。例如，如果BGP演讲者建立了交换IPv6路由的对等，并确定其对等不支持BGP-4的多协议扩展[RFC4760]，则可能需要终止对等。然后将通知消息中的错误子代码设置为不支持的功能。消息必须包含导致说话人发送消息的一种或多种功能。发送消息和终止对等的决定是说话人的本地决定。如果终止，这种对等不应自动重新建立。
If a BGP speaker receives from its peer a capability that it does not itself support or recognize, it MUST ignore that capability. In particular, the Unsupported Capability NOTIFICATION message MUST NOT be generated and the BGP session MUST NOT be terminated in response to reception of a capability that is not supported by the local speaker.
如果BGP扬声器从其对等方接收到其自身不支持或无法识别的功能，则必须忽略该功能。特别是，不得生成不受支持的能力通知消息，且不得响应接收到本地扬声器不支持的能力而终止BGP会话。
4. Capabilities Optional Parameter (Parameter Type 2):
4. 功能可选参数（参数类型2）：
This is an Optional Parameter that is used by a BGP speaker to convey to its BGP peer the list of capabilities supported by the speaker. The encoding of BGP Optional Parameters is specified in Section 4.2 of [RFC4271]. The parameter type of the Capabilities Optional Parameter is 2.
这是一个可选参数，BGP演讲者使用该参数向其BGP对等方传达演讲者支持的功能列表。[RFC4271]第4.2节规定了BGP可选参数的编码。功能可选参数的参数类型为2。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
该参数包含一个或多个三元组<Capability Code，Capability Length，Capability Value>，其中每个三元组的编码如下所示：
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
~ ~
+------------------------------+
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
~ ~
+------------------------------+
The use and meaning of these fields are as follows:
这些字段的用法和含义如下：
Capability Code:
能力代码：
Capability Code is a one-octet unsigned binary integer that unambiguously identifies individual capabilities.
能力代码是一个八位无符号二进制整数，明确标识各个能力。
Capability Length:
能力长度：
Capability Length is a one-octet unsigned binary integer that contains the length of the Capability Value field in octets.
Capability Length是一个八位无符号二进制整数，它包含以八位字节为单位的Capability Value字段的长度。
Capability Value:
能力价值：
Capability Value is a variable-length field that is interpreted according to the value of the Capability Code field.
能力值是根据能力代码字段的值解释的可变长度字段。
BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value. Note, however, that processing of multiple instances of such capability does not require special handling, as additional instances do not change the meaning of the announced capability; thus, a BGP speaker MUST be prepared to accept such multiple instances.
BGP扬声器不应包含多个具有相同功能代码、功能长度和功能值的功能实例。但是，请注意，处理此类能力的多个实例不需要特殊处理，因为其他实例不会改变所宣布能力的含义；因此，BGP演讲者必须准备好接受这样的多个实例。
BGP speakers MAY include more than one instance of a capability (as identified by the Capability Code) with non-zero Capability Length field, but with different Capability Value and either the same or different Capability Length. Processing of these capability instances is specific to the Capability Code and MUST be described in the document introducing the new capability.
BGP扬声器可能包括一个以上的能力实例（由能力代码标识），该能力具有非零能力长度字段，但具有不同的能力值，以及相同或不同的能力长度。这些能力实例的处理特定于能力代码，必须在介绍新能力的文档中进行描述。
The Capabilities Optional Parameter (OPEN Optional Parameter Type 2) SHOULD only be included in the OPEN message once. If the BGP speaker wishes to include multiple capabilities in the OPEN message, it SHOULD do so as discussed above -- by listing all those capabilities as TLVs within a single Capabilities Optional Parameter. However, for backward compatibility, a BGP speaker MUST be prepared to receive an OPEN message that contains multiple Capabilities Optional Parameters, each of which contains one or more capabilities TLVs. The set of capabilities should be processed in the same way in either case, whether it is enumerated within a single Capabilities Optional Parameter of the OPEN message or split across multiple Capabilities Optional Parameters.
功能可选参数（打开可选参数类型2）只应包含在打开消息中一次。如果BGP演讲者希望在开放消息中包含多个功能，则应如上所述，将所有这些功能作为TLV列在单个功能可选参数中。但是，为了向后兼容，BGP扬声器必须准备好接收包含多个功能可选参数的开放消息，每个参数都包含一个或多个TLV功能。无论在哪种情况下，都应以相同的方式处理功能集，无论是在打开消息的单个功能可选参数中枚举，还是在多个功能可选参数之间拆分。
This document defines a new Error Subcode, Unsupported Capability. The value of this Subcode is 7. The Data field in the NOTIFICATION message MUST list the set of capabilities that causes the speaker to send the message. Each such capability is encoded in the same way as it would be encoded in the OPEN message.
此文档定义了一个新的错误子代码，即不支持的功能。此子代码的值为7。通知消息中的数据字段必须列出导致扬声器发送消息的一组功能。每一个这样的功能都以与在开放消息中编码相同的方式进行编码。
As explained in the "Overview of Operations" section, the Unsupported Capability NOTIFICATION is a way for a BGP speaker to complain that its peer does not support a required capability without which the peering cannot proceed. It MUST NOT be used when a BGP speaker receives a capability that it does not understand; such capabilities MUST be ignored.
如“操作概述”一节所述，不受支持的功能通知是BGP说话者抱怨其对等方不支持所需功能的一种方式，没有该功能，对等无法继续。当BGP扬声器接收到无法理解的功能时，不得使用该功能；必须忽略这些能力。
This document defines a Capability Optional Parameter along with a Capability Code field. IANA maintains the registry for Capability Code values. Capability Code value 0 is reserved. Capability Code values 1 through 63 are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226]. Capability Code values 64 through 127 are to be assigned by IANA using the "First Come First Served" policy defined in [RFC5226]. Capability Code values 128 through 255 are for "Private Use" as defined in [RFC5226].
本文档定义了一个功能可选参数以及一个功能代码字段。IANA维护功能代码值的注册表。保留功能代码值0。IANA将使用[RFC5226]中定义的“IETF审查”政策分配能力代码值1至63。IANA将使用[RFC5226]中定义的“先到先得”策略分配能力代码值64至127。能力代码值128至255用于[RFC5226]中定义的“专用”。
IANA created and maintains a registry for OPEN message Optional Parameters called "BGP OPEN Optional Parameter Types". Optional Parameters are identified by the Parameter Type, which is a one-octet unsigned integer. Values (0 reserved, 1-255) are to be allocated according to the "IETF Review" policy as defined in [RFC5226].
IANA创建并维护一个名为“BGP OPEN OPEN Optional Parameter Types”的开放消息可选参数注册表。可选参数由参数类型标识，参数类型为一个八位无符号整数。根据[RFC5226]中定义的“IETF审查”政策分配值（0保留，1-255）。
The registry has been populated with the two Parameter Type codes that are currently defined:
注册表已填充当前定义的两个参数类型代码：
o Parameter Type 1: Authentication (deprecated) [RFC4271] [RFC5492]
o 参数类型1：身份验证（已弃用）[RFC4271][RFC5492]
o Parameter Type 2: Capabilities [RFC5492]
o 参数类型2：功能[RFC5492]
This extension to BGP does not change the underlying security issues inherent in the existing BGP [RFC4272].
BGP的此扩展不会改变现有BGP[RFC4272]中固有的基本安全问题。
The authors would like to thank members of the IDR Working Group and the IESG and its Directorates for their review and comments.
作者要感谢IDR工作组和IESG及其董事会成员的审查和评论。
[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月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[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月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[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月。
In addition to several minor editorial changes, RFC 3392 also clarified how to handle multiple instances of the same capability.
除了一些小的编辑性修改外，RFC3392还阐明了如何处理相同功能的多个实例。
This document makes minor editorial changes and updated references, clarifies the use of the Unsupported Optional Parameter NOTIFICATION message, clarifies behavior when the Capabilities Parameter is included in the OPEN message multiple times, and clarifies requirements by changing a number of SHOULDs to MUSTs.
本文档进行了微小的编辑性更改和更新的参考，澄清了不受支持的可选参数通知消息的使用，澄清了功能参数多次包含在打开消息中时的行为，并通过将多个should更改为must来澄清要求。
Authors' Addresses
作者地址
John G. Scudder Juniper Networks
约翰·G·斯卡德尔·杜松网络公司
EMail: jgs@juniper.net
EMail: jgs@juniper.net
Ravi Chandra Sonoa Systems
拉维·钱德拉·索诺亚系统公司
EMail: rchandra@sonoasystems.com
EMail: rchandra@sonoasystems.com