Capabilities Advertisement with BGP-4
obsoletes
- rfc-3392 — Capabilities Advertisement with BGP-4
updated by
- rfc-8810 — Revision to Capability Codes Registration Procedures
Extracted elements (18)
Base BGP-4 requires that a speaker receiving an OPEN message with unrecognized Optional Parameters must terminate the BGP peering, which complicates introduction of new capabilities. This specification defines an Optional Parameter and processing rules so peers can establish sessions even when unrecognized capabilities are present.
Multiple instances of a capability with different Capability Values under the same Capability Code are explicitly allowed to support capabilities that require advertising multiple parameter sets (e.g., multiple address families). The semantics of aggregating such instances are defined per-capability by the document introducing that capability.
A BGP speaker that supports a specific capability (e.g., Multiprotocol Extensions for BGP-4) MAY send an Unsupported Capability NOTIFICATION and terminate peering if the peer does not support that capability, but the decision is strictly local to the speaker.
When the peer signals it does not support capabilities advertisement by returning an Unsupported Optional Parameter NOTIFICATION, the local speaker should fall back to establishing a session without sending the Capabilities Optional Parameter, preserving backward compatibility with non-capable peers.
A BGP speaker that receives a Capabilities Optional Parameter capability it does not support or recognize MUST ignore that capability. The Unsupported Capability NOTIFICATION MUST NOT be generated and the BGP session MUST NOT be terminated solely due to reception of an unrecognized capability.
A given capability can be used on a peering only if it has been advertised by both peers. If either peer has not advertised a capability, that capability cannot be used on the session.
BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value in an OPEN message, but MUST be prepared to accept such duplicates since they do not change the meaning of the announced capability.
If a BGP speaker receives a NOTIFICATION with Error Subcode Unsupported Optional Parameter in response to an OPEN carrying the Capabilities Optional Parameter, the speaker SHOULD attempt to re-establish the BGP connection without sending the Capabilities Optional Parameter.
If a BGP speaker terminates peering by sending an Unsupported Capability NOTIFICATION because the peer lacks a required capability, such peering SHOULD NOT be re-established automatically.
The Capabilities Optional Parameter SHOULD only be included once in the OPEN message, with all capabilities listed as TLVs within that single parameter. However, a BGP speaker MUST be prepared to receive an OPEN containing multiple Capabilities Optional Parameters and process them identically to a single parameter.
When a BGP speaker sends an Unsupported Capability NOTIFICATION, the message MUST contain the capability or capabilities that caused the speaker to send the message, each encoded as it would appear in an OPEN message.
When multiple instances of a capability with the same Capability Code but different Capability Values are included, processing MUST be described in the document introducing that capability.
Error Subcode 7, Unsupported Capability, is used in a NOTIFICATION message when a BGP speaker determines that its peer lacks a required capability without which the peering cannot proceed. The Data field lists all offending capabilities.
The Capabilities Optional Parameter is OPEN Optional Parameter Type 2. It lists all capabilities supported by a BGP speaker as a sequence of TLV triples within the OPEN message sent during session establishment.
IANA maintains the BGP Capability Codes registry: value 0 is reserved; values 1–63 assigned by IETF Review; values 64–127 assigned by First Come First Served; values 128–255 for Private Use.
IANA maintains the 'BGP OPEN Optional Parameter Types' registry. Parameter Type values 0 (reserved) through 255 are assigned by IETF Review. Currently defined: Type 1 (Authentication, deprecated) and Type 2 (Capabilities).
This extension to BGP does not change the underlying security issues inherent in the existing BGP protocol as analyzed in RFC 4272; no new security vulnerabilities are introduced.
The Capabilities Optional Parameter (Parameter Type 2) contains one or more triples: Capability Code (1 octet unsigned integer), Capability Length (1 octet, length of Capability Value in octets), and Capability Value (variable-length, interpreted per Capability Code).