From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5492.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc5492.txt (limited to 'doc/rfc/rfc5492.txt') diff --git a/doc/rfc/rfc5492.txt b/doc/rfc/rfc5492.txt new file mode 100644 index 0000000..d5df5a9 --- /dev/null +++ b/doc/rfc/rfc5492.txt @@ -0,0 +1,395 @@ + + + + + + +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 + +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. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + 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. + +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. + + This document obsoletes RFC 3392. + + + +Scudder & Chandra Standards Track [Page 1] + +RFC 5492 Capabilities Advertisement February 2009 + + +1. Introduction + + 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. + + 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. + +2. Requirements Language + + 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]. + +3. Overview of Operations + + 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. + + 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. + + 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. + + 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. + + + + +Scudder & Chandra Standards Track [Page 2] + +RFC 5492 Capabilities Advertisement February 2009 + + + 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. + + 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. + +4. Capabilities Optional Parameter (Parameter Type 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. + + The parameter contains one or more triples , where each triple is encoded as + shown below: + + +------------------------------+ + | 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. + + + + +Scudder & Chandra Standards Track [Page 3] + +RFC 5492 Capabilities Advertisement February 2009 + + + Capability Length: + + Capability Length is a one-octet unsigned binary integer that + contains the length of the Capability Value field in octets. + + 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 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. + + 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. + +5. Extensions to Error Handling + + 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. + + + + + + +Scudder & Chandra Standards Track [Page 4] + +RFC 5492 Capabilities Advertisement February 2009 + + + 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. + +6. IANA Considerations + + 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 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]. + + The registry has been populated with the two Parameter Type codes + that are currently defined: + + o Parameter Type 1: Authentication (deprecated) [RFC4271] [RFC5492] + + o Parameter Type 2: Capabilities [RFC5492] + +7. Security Considerations + + This extension to BGP does not change the underlying security issues + inherent in the existing BGP [RFC4272]. + +8. Acknowledgments + + The authors would like to thank members of the IDR Working Group and + the IESG and its Directorates for their review and comments. + + + + + + + + + + + +Scudder & Chandra Standards Track [Page 5] + +RFC 5492 Capabilities Advertisement February 2009 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +9.2. Informative References + + [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", + RFC 4272, January 2006. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Scudder & Chandra Standards Track [Page 6] + +RFC 5492 Capabilities Advertisement February 2009 + + +Appendix A. Comparison between RFC 2842 and RFC 3392 + + In addition to several minor editorial changes, RFC 3392 also + clarified how to handle multiple instances of the same capability. + +Appendix B. Comparison between RFC 3392 and This Document + + 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. + +Authors' Addresses + + John G. Scudder + Juniper Networks + + EMail: jgs@juniper.net + + + Ravi Chandra + Sonoa Systems + + EMail: rchandra@sonoasystems.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Scudder & Chandra Standards Track [Page 7] + -- cgit v1.2.3