Summary

  • RFC 9764 pads BFD transport payloads to a configured size, fills the added bytes with zero and requires IPv4 packets to set Don't Fragment. An Up session can therefore provide recurring evidence that this particular BFD traffic is crossing at the selected size.
  • The result is directional and forwarding-treatment specific. Both endpoints must be configured for a bidirectional claim, and LAG or ECMP can leave member links unexercised while the aggregate BFD session remains Up.
  • pdu-size is a shared operational control, not harmless telemetry. Raising it can take an established session Down, affect several dependent clients and trigger policy before the operator knows whether the cause is a true size limit, unsupported parsing, selective filtering or member variation.

The maintenance window appeared finished. A multihop BFD session was Up, its interval was steady, and the dashboard was green. Yet the customer application still failed whenever it sent a larger datagram. The small control packets had crossed the network; the useful traffic had not.

That is the gap RFC 9764 tries to narrow. BFD is widely used to learn whether two systems can exchange control packets quickly enough to keep a session alive. Its ordinary packets are small. Small-packet reachability is valuable, but it does not answer a size-sensitive application's question: can the path carry a packet at least this large without fragmentation?

The RFC's answer is deliberately modest. Increase the BFD transport payload to a configured value. Keep sending it through the ordinary Asynchronous-mode state machine. If the enlarged control packets stop arriving, the session follows normal BFD failure behavior. The resulting state now carries a packet-size condition.

The hard part is not adding zeros. It is keeping the evidence from growing larger than the test.

A lower bound, not a map of the path

The new variable is bfd.PaddedPduSize. The sender increases the BFD transport-protocol payload to that number of bytes. The extra payload must be zero, and the receiver should not inspect its contents. With IPv4, the Don't Fragment bit must be set. A path that cannot carry the padded packet as sent cannot quietly satisfy the test by fragmenting it into smaller pieces.

This is an elegant use of the existing protocol. RFC 5880 already defines the BFD state machine and its detection behavior. RFC 9764 does not create a second availability protocol. It changes the size of the encapsulation that carries a valid BFD PDU, then lets non-reception produce the familiar state transition.

But an Up state proves only a floor. If the selected value is 1,512 bytes, successful reception supports the claim that these BFD packets can traverse at 1,512 bytes under the forwarding conditions they experienced. It does not discover the maximum. The path might carry 2,000, 4,000 or 9,000 bytes; the session has not asked. If the Path MTU later increases, the session stays Up and does not announce the extra capacity.

This differs from the broader history of Path MTU Discovery. RFC 1191 defines a path MTU as a property of a particular path and makes a sender reduce its estimate after bounded feedback. RFC 8899 gives datagram transports a packetization-layer probing framework. RFC 9764 is not a general maximum-finding algorithm. It asks whether one configured minimum remains usable.

That precision is operationally helpful. An application that needs only 1,400 bytes should not inherit a 9,000-byte test merely because a local interface supports jumbo frames. The chosen size should follow the dependent application's requirement. Interface MTU is a local capacity. Padded BFD state is an observation over the exercised path. Application success is a third claim.

One session can hide two directions

The word “bidirectional” in BFD's name is not permission to skip directional evidence. RFC 9764 is explicit: when an application needs the selected Path MTU in both directions, PaddedPduSize must be configured at both ends. Without that arrangement, the mechanism can correctly establish that large control packets arrive in one direction while leaving the reverse direction untested at that size.

That distinction survives even when the endpoints share one session view. A packet sent from A to B may cross a different queue, tunnel, policy or physical route from a packet sent from B to A. One side can accept 1,512 bytes while the other direction drops them. Some links are intentionally asymmetric, so the honest configuration may use different values at the two ends rather than pretend symmetry.

RFC 5881 describes single-hop BFD. On a directly connected link, interface MTU configuration often supplies much of the assurance, and BFD Echo can exercise forwarding. RFC 5883 carries BFD over multiple hops, where that direct-link guarantee disappears. RFC 9764 is especially important there, but multiple hops also make the path claim easier to overstate.

An audit record therefore needs two observations, not one label: the configured and received size from A to B, and the configured and received size from B to A. “The session is Up” is a useful summary only after the directional facts remain recoverable underneath it.

The largest client quietly sets the risk

BFD sessions are often shared by several client protocols. One client may need packets of 1,400 bytes; another may depend on 1,512. RFC 9764 says an implementation should select the largest requested PaddedPduSize for sessions between the same endpoints. Choosing the smaller request could leave the session Up while the larger client's requirement is not actually met.

This turns a single configuration value into a small piece of shared infrastructure governance. The largest client supplies the effective threshold. Every client then observes the state produced at that threshold. A new client can therefore change the meaning and availability of a session that older clients already depend on.

Imagine a routing client comfortable with 1,400 bytes sharing a BFD session with a storage overlay that requests 1,600. Raising the padded size may reveal a true narrow link. It may also encounter a peer implementation that accepts ordinary BFD but refuses the larger encapsulation. In either case the session can go Down, and the routing client can react even though its own size requirement was still satisfied.

The governance question is not whether the larger request is legitimate. It is who owns the shared consequence. A safe change record names the requesting client, the old and new sizes, the dependent clients, both endpoint capabilities, the rollback value and the policy actions tied to Down.

Unsupported reception looks like network loss

RFC 9764 changes no BFD header rule. A conforming BFD PDU remains inside a larger transport payload. Nevertheless, an existing implementation may not accept an arbitrarily padded packet, or it may incorrectly reject the control packet during validation. From the state machine's perspective, both cases look like non-reception.

That creates an important ambiguity. Session Down after enabling padding can mean the path cannot carry the selected size. It can also mean the far endpoint cannot process that representation. Selective filtering may discard it. A policy device may treat large control traffic differently. An on-path attacker can selectively drop BFD packets and cause the same result.

The wire outcome is real: the padded packets did not sustain the session. The root cause is not yet known. An automation that immediately publishes “Path MTU below 1,512” has crossed from observation into diagnosis without evidence.

Zero padding addresses a different risk. It prevents local uninitialised memory from leaking into the added payload. The receiver is advised not to validate those zero bytes, because the useful condition is the encapsulation length, not a new content exchange. This design keeps the mechanism small, but it does not remove the need to test endpoint support before a fleet-wide rollout.

ECMP is where the green light becomes dangerous

A forwarding system can present one logical path while distributing packets across several physical members. LAG and ECMP improve capacity and resilience by hiding that choice from higher layers. They also limit what one BFD flow can prove.

The BFD control packets may hash onto one healthy member. Customer flows may hash onto another member whose MTU is smaller or whose forwarding is broken. The BFD session stays Up because the packets it sends continue to arrive. Some application traffic still fails.

RFC 7130 defines a BFD approach for LAG member links, but RFC 9764 notes that no general-purpose multihop BFD mechanism is specified to exercise every ECMP link. Some implementations use internal knowledge to improve member coverage. That behavior is implementation-specific and cannot be assumed from the standard alone.

This is not a defect in the evidence. It is a boundary. The result says what happened to the control flow the network actually forwarded. It does not say what would happen to every possible entropy value, tunnel choice or member. Inconsistent member MTUs can make the effective Path MTU flow dependent.

The RFC 9978 commission, RFC 9978, owns a related but different warning: counts of missed BFD control packets can expose instability without proving data-plane loss or customer impact. Here the question is packet size. The shared discipline is to keep BFD evidence attached to the control packets and forwarding scope that generated it.

Configuration is part of the proof

RFC 9764 includes the ietf-bfd-large YANG module. It augments the BFD models in RFC 9314 with a padding feature and a pdu-size leaf for single-hop, multihop, LAG and MPLS session structures. The model follows the Network Management Datastore Architecture in RFC 8342.

The leaf is writable. That means the evidence chain begins before the packet is sent. Who changed the value? Which datastore and intended configuration held it? Did both endpoints commit the same epoch? Which clients contributed requests? Did operational state reflect the configured value? Was the session already Up?

RFC 9764 warns that changing pdu-size on an Up session may take it Down and may affect several clients. Access to this leaf therefore belongs inside ordinary change control and authenticated management, not in an unreviewed monitoring experiment. The configuration is capable of causing the failure it is meant to reveal.

RFC 7880 provides Seamless BFD context, and RFC 9764 says the technique can apply there as well. That compatibility does not broaden the claim. Each mode still needs its own endpoint, direction, encapsulation, selected size and forwarding-scope record.

A successful probe is not a future packet

Another nearby standard makes the temporal limit visible. RFC 9869 applies Datagram Packetization Layer Path MTU Discovery to UDP Options with request and response tokens. Its separate BTW commission explains why one confirmed probe cannot certify an arbitrary future datagram. RFC 9764 improves continuity by making the sized probe part of recurring BFD traffic, but it cannot abolish change between samples or force an application packet onto the same member.

Recurrence narrows uncertainty; it does not create omniscience. Route changes, ECMP hashing, queue policy, encapsulation overhead and endpoint behavior can differ. The right claim includes the most recent successful reception time and configuration epoch. “Currently Up at the selected BFD size” is reviewable. “The service path supports this MTU” is too broad unless service evidence closes the gap.

Sources and evidence boundary

The primary specification is RFC 9764. Its BFD foundation is RFC 5880, with RFC 5881 for single-hop operation, RFC 5883 for multihop operation, RFC 7130 for LAG and RFC 7880 for S-BFD. Management context comes from RFC 9314 and RFC 8342. Packet-size context comes from RFC 1191, RFC 8899 and RFC 9869; adjacent BFD stability scope comes from RFC 9978.

The governance lens comes from Heng Lu's Minimum Initial Specification, Running-Code Primacy and reality-layer analysis. Applied here, the principle is practical: let the common mechanism make one packet-size fact locally verifiable, and leave the operator who bears the consequence in control of the next decision.