Capabilities Advertisement with BGP-4
obsoleted by
- rfc-5492 — Capabilities Advertisement with BGP-4
obsoletes
- rfc-2842 — Capabilities Advertisement with BGP-4
Extracted elements (14)
BGP-4 originally required terminating a peering session upon receipt of an unrecognized Optional Parameter, which made introducing new capabilities disruptive. The Capabilities Optional Parameter was defined to allow graceful advertisement of new capabilities without forcing session teardown.
A speaker detects that its peer does not support capabilities advertisement when it receives a NOTIFICATION with Error Subcode Unsupported Optional Parameter in response to an OPEN carrying the Capabilities Optional Parameter. The speaker should then fall back to connecting without the parameter.
A BGP speaker that supports capabilities advertisement MAY include the Capabilities Optional Parameter in its OPEN message to advertise the list of capabilities it supports.
A NOTIFICATION message sent for an unsupported capability SHOULD contain the capability or capabilities that caused the speaker to send the message, encoded the same way as in the OPEN message.
BGP speakers MAY include more than one instance of a capability (same Capability Code) with non-zero Capability Length but different Capability Value. Processing of such multiple instances MUST be described in the document that introduces the new capability.
BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value, though processing multiple identical instances requires no special handling since they do not change the announced capability's meaning.
If a BGP speaker determines its peer does not support a capability the speaker requires, it MAY send a NOTIFICATION with Error Subcode Unsupported Capability and terminate the peering. Such peering SHOULD NOT be re-established automatically.
If a BGP speaker receives a NOTIFICATION with Error Subcode set to Unsupported Optional Parameter in response to an OPEN containing the Capabilities Optional Parameter, it SHOULD re-attempt the BGP connection without including the Capabilities Optional Parameter.
A new BGP Error Subcode, Unsupported Capability (value 7), is defined for use in NOTIFICATION messages when a speaker terminates peering because a required capability is not supported by the peer.
The Capabilities Optional Parameter (Parameter Type 2) is an Optional Parameter carried in BGP OPEN messages. It contains one or more capability triples, each encoding a Capability Code (1 octet), Capability Length (1 octet), and Capability Value (variable length).
IANA maintains the Capability Code registry. Code 0 is reserved; codes 1–63 are assigned by IANA via IETF Consensus; codes 64–127 via First Come First Served; codes 128–255 are for Private Use.
This extension to BGP does not change the underlying security issues inherent in existing BGP. The referenced protection mechanism is TCP MD5 Signature Option (RFC 2385).
During capability negotiation: (1) speaker sends OPEN with Capabilities Optional Parameter; (2) if peer replies with NOTIFICATION (Unsupported Optional Parameter), speaker retries without the parameter (falling back to basic BGP); (3) if peer supports capabilities but lacks a required one, speaker may terminate with NOTIFICATION (Unsupported Capability) and SHOULD NOT auto-reconnect.
Each capability triple in the Capabilities Optional Parameter is encoded as: Capability Code (1 octet, unambiguously identifies the capability), Capability Length (1 octet, length of the Capability Value field in octets), and Capability Value (variable, interpreted per Capability Code).