Extended Message Support for BGP
updates
- rfc-4271 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (20)
OPEN and KEEPALIVE messages are excluded from the extended message size increase to reduce the complexity of providing backward compatibility, since these messages are fundamental to session establishment.
A BGP UPDATE carrying an extended message may propagate to BGP speakers that do not support Extended Messages; announcements where the attribute set plus NLRI exceeds 4,096 octets may cause lack of reachability on those paths.
In an AS with multiple iBGP speakers and external neighbors, a consistent internal view requires all iBGP speakers to advertise the BGP Extended Message Capability; if not, the operator should consider whether to advertise the capability to external peers.
The BGP Extended Message Capability applies to all messages except OPEN and KEEPALIVE messages; these exceptions reduce the complexity of providing backward compatibility.
A BGP speaker capable of receiving BGP Extended Messages SHOULD advertise the BGP Extended Message Capability to its peers using BGP Capabilities Advertisement.
A BGP speaker MAY send BGP Extended Messages to a peer only if the BGP Extended Message Capability was received from that peer.
A BGP speaker that has the ability to use BGP Extended Messages but has not advertised the capability MUST NOT accept a BGP Extended Message; a speaker MUST NOT implement a more liberal policy accepting them.
An implementation that advertises the BGP Extended Message Capability MUST be capable of receiving a message with a length up to and including 65,535 octets.
Applications generating information encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account.
If a message cannot be reduced to fit within 4,096 octets for a non-capable neighbor, it must not be sent, and if the NLRI was previously advertised to that peer, it must be withdrawn from service (RFC 4271, Sections 9.2 and 9.1.3).
If a NOTIFICATION is to be sent to a BGP speaker that has not advertised the BGP Extended Message Capability, the size of the NOTIFICATION message MUST NOT exceed 4,096 octets.
It is RECOMMENDED that BGP protocol developers and implementers are conservative in their application and use of BGP Extended Messages. Future protocol specifications MUST describe how to handle peers that can only accommodate 4,096-octet messages.
Peers that wish to use the BGP Extended Message Capability MUST support error handling for BGP UPDATE messages per RFC 7606.
When propagating an UPDATE larger than 4,096 octets to a neighbor that has not advertised the BGP Extended Message Capability, the speaker SHOULD try to reduce the outgoing message size by removing attributes eligible under the 'attribute discard' approach of RFC 7606.
A BGP Extended Message is any BGP message over 4,096 octets in length, with a maximum size of 65,535 octets. The smallest valid BGP message remains a KEEPALIVE at 19 octets.
The BGP Extended Message Capability is a new BGP capability defined with Capability Code 6 and Capability Length 0, advertised via BGP Capabilities Advertisement (RFC 5492).
IANA allocated Capability Code 6 in the 'Capability Codes' registry with the description 'BGP Extended Message', referencing RFC 8654.
A remote speaker able to craft a large BGP Extended Message on a path with non-capable peers may cause capable peers to discard attributes (potentially triggering an attack) or perform a downgrade, and imposes resource load from message reformatting.
Increased memory requirements for buffering larger messages create increased exposure to resource exhaustion, whether intentional (DoS) or unintentional.
The BGP message Length field, previously constrained to a maximum of 4,096, is raised to 65,535 for all messages except OPEN and KEEPALIVE when both peers have negotiated the BGP Extended Message Capability (Capability Code 6, Length 0).