Summary

  • RFC 8654 raises the BGP message limit from 4,096 to 65,535 octets for messages other than OPEN and KEEPALIVE, but only a peer that advertised capability code 6 may be sent an extended message.
  • The capability is a receiving commitment on one session, not network-wide permission: mixed support can force attribute discard, withholding, or withdrawal, while larger buffers increase resource-exhaustion exposure.

The larger envelope begins with a bilateral promise

RFC 4271 established a simple baseline. A BGP message is processed only after it is received in full, and its maximum size is 4,096 octets. RFC 8654 updates that ceiling because newer address families and features can require a larger payload. For messages other than OPEN and KEEPALIVE, the new upper bound is 65,535 octets.

The number alone is not the control. Capability negotiation is. A speaker able to receive extended messages SHOULD advertise the BGP Extended Message Capability defined by RFC 8654 and carried through RFC 5492. IANA registers it as capability code 6. A sender MAY send an extended message only when that capability was received from the peer on that session.

Advertising is therefore a commitment, not a decoration. An implementation that advertises the capability MUST be capable of receiving a message up to and including 65,535 octets. Conversely, a speaker that can use extended messages but did not advertise the capability—perhaps because configuration disabled it—MUST NOT accept one. Implementation capacity does not override the configured session boundary.

RFC 8654 adds a separate outbound boundary: a NOTIFICATION sent to a peer that did not advertise the capability MUST NOT exceed 4,096 octets.

One capable edge does not make the next edge capable

The difficult case appears after acceptance. An UPDATE larger than 4,096 octets may arrive from a capable peer, describe an ongoing announcement, and then need to propagate to a neighbor that did not advertise extended-message support. The first session authorized receipt. It said nothing about the second session.

RFC 8654 tells the intermediary that it SHOULD try to reduce the outgoing message by removing attributes eligible for RFC 7606's attribute-discard treatment. That remedy is deliberately narrow: eligible discarded attributes must not affect route selection or installation. If the UPDATE is still too large, it must not be sent to the non-capable neighbor. If the NLRI had already been advertised there, it must be withdrawn from service.

This is why the feature is not merely a higher integer. A representation that fits on one edge can change reachability at the next. The beneficiary may be an application that needs a larger attribute set or more NLRI in one message. The cost can fall on the downstream peer and on users of a route that can no longer cross the 4,096-octet boundary.

Internal consistency becomes an executive rollout question

Mixed support inside one autonomous system is especially consequential. RFC 8654 says a consistent view can be guaranteed only if every iBGP speaker advertises the capability. If that condition is absent, the operator should consider whether to advertise extended-message support to external peers at all.

That advice establishes a useful sequence. Inventory session capability first. Test the largest receive path and parser, measure buffer headroom, identify every internal and external boundary, and observe routes dropped or attributes discarded during incremental deployment. Only then decide which external peers should see capability code 6.

The security boundary is equally restrained. RFC 8654 does not change BGP's underlying security problems. Larger buffers can increase exposure to intentional or accidental resource exhaustion. Reformatting and attribute discard also consume work. Receiving a capability proves neither route legitimacy nor the safety of the payload; it proves only that the peer announced the specified receiving capacity.

Evidence and limits

RFC 8654 defines the extended-message size, exceptions, capability rules, mixed-peer behavior, consistency warning and resource considerations. RFC 4271 supplies the 4,096-octet baseline and BGP propagation rules. RFC 5492 defines capability advertisement. RFC 7606 supplies the eligible attribute-discard boundary. The IANA registry confirms the current code assignment.

The sources do not identify which networks enable the capability, quantify a universal memory cost, guarantee that discard will make every UPDATE fit, or prescribe one safe rollout order for every topology. The assessment of power, authorization, beneficiaries, cost and counterfactual is analysis derived from the standards.

Sources