Summary

  • RFC 9869 uses a four-octet REQ token, a matching RES and EOL padding to test a selected UDP datagram size. A valid match confirms receipt of that particular probe by the remote UDP Options receiver.
  • The result is specific to a 5-tuple, path and time. Multipath and multihoming require separate state, while periodic validation prevents an old success from becoming a permanent PLPMTU claim.
  • Missing or delayed feedback is ambiguous: piggyback policy, sparse return traffic, rate limits or response loss can make a capable forward path look smaller.

A receipt with a narrow subject

RFC 9869 applies Datagram Packetization Layer Path MTU Discovery to UDP Options. The sender places a four-octet token in a REQ option, pads the options area with EOL to a chosen size, and waits for the receiver to echo the token in a RES. The resulting datagram can exceed the sender's current PLPMTU estimate, but not the interface MTU; it is sent without IP fragmentation, with the IPv4 Don't Fragment bit set where applicable.

When the response matches, the RFC gives the sender a strong positive fact: this specific probe packet reached the remote UDP Options receiver. That is more reliable than treating an absent ICMP message as permission to increase size. It is also much less than a certificate. The response does not say that application data was delivered, parsed or accepted. It does not measure the return path's maximum packet size. It cannot promise that the next packet will traverse the same route.

That is why probes used to raise the PLPMTU should not carry application data. Oversized candidates are expected to fail during discovery. A zero-payload probe stays below the upper application layer. Application-data probes may confirm or validate a working size, but they are not the instrument for increasing it.

The token binds an answer to an attempt

Correlation is the mechanism's evidentiary core. Tokens must be unique for the 5-tuple within the Maximum Segment Lifetime and must not be reused inside that window. A randomized initial token and unpredictable successors make blind forgery harder. Retaining only the final PLPMTU discards the facts that justify it: token, probe size, addresses and ports, path selector, send time, response time, retry state and software version.

Enablement matters too. Both applications must explicitly enable this DPLPMTUD service, and a receiver must not emit a RES before it is enabled. If a transport service and an upper-layer protocol each run discovery, they must coordinate or use distinct tokens. Otherwise, a valid-looking answer can reach the wrong state machine.

The standard is aimed primarily at unicast and does not define multicast operation. The receiver may generate an empty-payload response, but response-only traffic must be rate-limited. These constraints are protocol state, not deployment trivia.

One route cannot sign for another

RFC 9869 requires separate discovery state for each path under multipath, ECMP or multihoming. This follows the nature of PMTU: the limiting link belongs to a path, and routing can change. Copying one successful value across alternatives converts evidence about a measured route into an assumption about unmeasured ones.

The state machine therefore periodically validates the current PLPMTU. That timer is a control against stale authority. A successful 1,400-byte probe last week may be historically true and operationally unsafe today. Conversely, a smaller value learned during a temporary failure should not become an eternal ceiling.

Silence has several causes

A receiver can wait to piggyback RES on a queued return datagram. If several probes arrive before one is sent, it may acknowledge only the latest token. Earlier probes then look unsuccessful even though they reached the receiver. With little reverse traffic, delayed feedback can keep discovery at a smaller value or at the minimum PLPMTU.

An empty-payload response improves progress but introduces amplification and workload concerns, hence rate limiting. A timeout can therefore mean forward-path loss, receiver policy, response queuing, a rate limit or reverse-path loss. It is useful state-machine input, but not a self-explaining network verdict.

ICMP Packet Too Big information is optional. If used, the implementation must validate the quoted protocol context and should validate the quoted REQ token where possible. A message that cannot be validated must be ignored. Tokens reduce forged off-path influence; they cannot stop an on-path actor from dropping or modifying traffic.

Sources