Summary

  • RFC 8654 lets a receiver advertise capacity for BGP messages up to 65,535 octets, except OPEN and KEEPALIVE; a sender may use that envelope only after receiving the capability from that neighbour.
  • The promise stops at the session. If the next peer remains limited to 4,096 octets, only narrowly discardable attributes may be removed; if the UPDATE still cannot fit, it is not sent and a previously advertised route must be withdrawn.
  • Safe adoption treats message size as a governed budget: make internal capability uniform before external dependence, measure encoded outbound size and resource pressure, and keep rollback routes representable in the legacy envelope.

The failure begins with a true statement: both ends of one BGP session support Extended Messages. A border router receives an UPDATE larger than 4,096 octets, parses it correctly and keeps its session established. The route appears in the RIB. A feature display shows capability code 6. The change ticket is closed as successful.

Then traffic through another edge disappears.

The route reflector between the two edges also understands the extension, but one older egress peer does not advertise it. The selected route carries a path-attribute set that cannot fit the old envelope. The egress cannot simply cut the message in half, because attributes and the NLRI form one semantic advertisement. It may discard only the attributes that RFC 7606 already classifies as safe for attribute discard. If the result is still too large, RFC 8654 requires the route not to be sent; if that prefix had been advertised before, it must be withdrawn.

No protocol violation is needed. The outage is produced by a mismatch between local carriage and end-to-end expectation.

The old limit was a protocol boundary

RFC 4271 gives every BGP message a two-octet Length field, but the base specification limits valid length to 19 through 4,096 octets. That limit shaped parsers, buffers, test suites and the amount of NLRI and path-attribute material implementations expected to process as one atomic BGP message.

RFC 8654 does not abolish the old boundary globally. It creates an Extended Message Capability, code 6 with a zero-length value. A speaker advertising the capability says that it can receive and properly handle messages up to and including 65,535 octets. That is a receive promise, made to one peer during OPEN capability exchange.

The direction matters. A speaker may send an Extended Message only if it received the capability from the peer. General BGP capability rules describe use as bilateral: if either side does not advertise a given capability, that session cannot rely on it. An operator may also make support mandatory and decline a session whose peer lacks it. BIRD makes that policy distinction visible by exposing separate enable and require controls.

Possession is not advertisement. RFC 8654 explicitly forbids a capable implementation that withheld the capability—perhaps by configuration—from liberally accepting an oversized message anyway. The configured boundary has operational authority. A peer must not infer hidden tolerance.

Two extensions with similar names solve different limits

RFC 8654 excludes OPEN and KEEPALIVE from Extended Message operation. The exception is deliberate: the capability that authorizes larger messages is itself negotiated in OPEN, so a sender cannot assume it before the session has exchanged its declarations. KEEPALIVE remains the fixed 19-octet liveness message.

RFC 9072 addresses a different OPEN constraint. The base OPEN format gives Optional Parameters a one-octet total length, limiting that field to 255 octets. As capabilities accumulated, RFC 9072 reserved optional-parameter type 255 to signal a two-octet extended length encoding. It expands the capability container inside OPEN; it does not turn OPEN into a 65,535-octet RFC 8654 message and does not authorize large UPDATEs.

This distinction is an important audit canary. A platform may support RFC 9072 because it needs room to advertise many capabilities while still not enable RFC 8654 for subsequent UPDATEs. A session trace must identify both encodings separately.

A larger ceiling is not permission to fill it

The 65,535-octet value is a maximum, not a desired packing size. RFC 8654 requires applications that generate information for BGP to limit their payload with the applicable message maximum in mind. An operator may set a stricter budget to protect latency, memory, failure isolation or mixed peers.

Growth has several sources. RFC 4271 permits multiple prefixes with identical path attributes to share an UPDATE. Packing more NLRI can improve efficiency but makes one processing unit larger. ADD-PATH prepends a four-octet Path Identifier to each encoded NLRI and may increase both message volume and bytes. Large Communities are twelve-octet operator-defined values carried as an unordered set. VPN, traffic-engineering, security and topology attributes can add further material.

None of those bytes is automatically waste. A Large Community may control export or incident response. An opaque optional attribute may carry information a downstream consumer needs. A Path Identifier may distinguish candidates that would otherwise replace one another. A message-budget policy must classify semantics, not merely count attribute names.

Packing also has a hard asymmetry. If one path-attribute set is modest, a sender can usually distribute many prefixes across several UPDATEs. If the attribute block itself exceeds the legacy envelope, splitting NLRI does not solve the problem. The route representation—not the number of prefixes in that packet—is incompatible with the next peer.

TCP does not rescue that case. TCP may segment a BGP message across packets and reassemble its byte stream, but it does not split one BGP UPDATE into independent semantic UPDATEs. The BGP receiver still validates the complete message length declared in the header.

The legacy edge decides reachability

Suppose an ingress accepts a 9,000-octet UPDATE and advertises the same route toward a peer that did not offer Extended Message support. RFC 8654 provides a conservative sequence.

First, the sender may try to reduce the outgoing message by removing attributes eligible for RFC 7606's attribute-discard treatment. That class is deliberately narrow. RFC 7606 warns that an attribute with any effect on route selection or installation must not be handled through discard. Even an attribute that does not affect default selection can matter if local policy refers to it.

Second, if the advertisement still cannot fit, it is not sent. If the NLRI was already in service for that neighbour, it is withdrawn. The correct outcome may therefore be less reachability, not a lossy approximation of the route.

This makes message-size migration a policy event. An external customer can receive a route through one border and lose it through another. Two route reflectors can produce different egress sets. A backup path may exist in the Loc-RIB yet remain unadvertisable through a legacy session because its attribute set is larger. A failover test using only ordinary routes will not reveal the dependency.

RFC 8654 draws the internal consequence plainly: an AS can guarantee a consistent view only if all relevant iBGP speakers advertise the capability. If the internal control plane is mixed, the operator should reconsider advertising the capability externally. Accepting a representation that part of the AS cannot carry creates hidden topology in the information plane.

Large-message support enlarges the parser surface

A receiver advertising capability code 6 commits to accepting up to 65,535 octets. That promise touches memory allocation, input queues, parsing time, attribute validation, policy evaluation, logging and replication. Multiplying a maximum-size message by simultaneous peers and queued work gives a more useful stress scenario than testing one benign UPDATE.

RFC 8654 identifies increased exposure to resource exhaustion, whether accidental or intentional. A supporting router may also spend CPU trying to reformat a large UPDATE for a legacy neighbour or identify discardable attributes. A sender able to trigger repeated near-limit parsing and per-egress resizing can consume resources even when every message is syntactically valid.

The correct control is not a fictional claim that TCP or authentication makes the input cheap. Session protection can establish peer identity, but an authorized peer can still send costly valid data. Bound peer count, receive and transmit queue memory, message rate, maximum accepted size where implementation permits, attribute multiplicity and logging amplification. Test overload behaviour without letting telemetry or diagnostics become the larger failure.

FRRouting's current documentation lists RFC 8654 among implemented BGP RFCs. BIRD 3.3.0 documents 4,096 bytes as the base maximum, 65,535 with Extended Messages and separate enable/require controls. Those are useful implementation claims. They are not proof that a production session advertised the capability, that every parser on the path shares it or that headroom survives the deployed policy set.

Capability evidence needs a session epoch

A screenshot of configuration says what an operator intended. A negotiated-capability display says what two speakers declared when the session came up. Neither proves that one particular UPDATE crossed the boundary.

A defensible record binds evidence to a session epoch. Capture the local and received capability sets, peer identity, role, AFI/SAFI and software build. For each near-limit route, record the encoded inbound length, path-attribute length, NLRI count, relevant Path Identifiers and exact outbound encoding per material neighbour. Mark whether the route was repacked, an attribute was discarded, the advertisement was suppressed, or a prior route was withdrawn.

The receiver's response completes the control-plane chain: accepted UPDATE, Bad Message Length NOTIFICATION, session reset, policy rejection or absence. A BMP or packet capture can help, but the observation point and loss state must be declared. One collector behind the extended-capable ingress cannot testify for a legacy egress.

Finally, reachability claims require FIB and packet evidence. Successful UPDATE transmission means the peer received bytes; it does not prove that policy selected the route, recursive resolution succeeded, hardware programmed the path or packets used it. Running-code primacy keeps those layers separate.