Capabilities Advertisement with BGP-4
obsoleted by
- rfc-3392 — Capabilities Advertisement with BGP-4
Extracted elements (12)
A particular capability identified by its Capability Code may occur more than once within the Capabilities Optional Parameter, providing flexibility for capabilities that require multiple instances.
The existing BGP-4 requirement to terminate peering upon receiving an unrecognized Optional Parameter complicates introduction of new capabilities. The Capabilities Optional Parameter allows graceful capability advertisement without requiring peering termination.
A BGP speaker detects that its peer doesn't support capabilities advertisement when it receives a NOTIFICATION with Error Subcode 'Unsupported Optional Parameter' in response to an OPEN carrying the Capabilities Optional Parameter, and should fall back to a connection without the Capabilities parameter.
A BGP speaker that supports capabilities advertisement may use a particular capability with its peer only after determining that the peer supports this capability by examining the Capabilities Optional Parameter in the received OPEN message.
If a BGP speaker determines its peer doesn't support a required capability, the speaker may send a NOTIFICATION with Error Subcode 'Unsupported Capability' and terminate peering; such peering should not be re-established automatically.
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.
The NOTIFICATION message for Unsupported Capability should contain the capability or capabilities that caused the speaker to send the message.
A new NOTIFICATION Error Subcode 'Unsupported Capability' is defined with value 7. The Data field lists the set of capabilities that caused the speaker to send the message, encoded the same way as in the received OPEN message.
The Capabilities Optional Parameter (Parameter Type 2) is used by a BGP speaker to convey to its BGP peer the list of capabilities supported by the speaker. It contains one or more triples of <Capability Code, Capability Length, Capability Value>.
IANA is to create and maintain a registry for Capability Code values. Code 0 is reserved; codes 1-63 assigned by IETF Consensus; codes 64-127 by First Come First Served; codes 128-255 for Private Use.
This extension to BGP does not change the underlying security issues inherent in the existing BGP; security considerations are as described in RFC 2385 (TCP MD5 Signature Option).
Each capability triple is encoded as: Capability Code (1 octet), Capability Length (1 octet, length of Capability Value in octets), and Capability Value (variable length, interpreted per Capability Code).