Summary

  • A successful probe confirms that one identified packet of the probed size reached the remote packetization layer on the path used for that observation.
  • RFC 8201 treats the path MTU as time-varying, while RFC 8899 requires renewed confirmation and separate state where multipath or multihoming is supported.
  • An operational receipt must bind the result to endpoints, flow or path identity, encapsulation overhead, probe feedback, time and representative data delivery.

One green probe, two effective paths

Imagine a datagram service that sends a padded 1,450-byte probe. The receiver acknowledges the exact probe, so the sender raises its packetization-layer PMTU. A minute later, application traffic with the same nominal size is mapped to another equal-cost member. That member adds more tunnel overhead or crosses a lower-MTU link. The packet is too large for the effective path, and the expected feedback never arrives.

The first result has not become false. It established that the identified probe was delivered at that size. What failed was the scope assigned to it. A path-MTU result belongs to a path and a time, not merely to a destination label. If load balancing, routing or encapsulation changes the packet's treatment, the old observation may no longer describe the current path.

This distinction matters because “MTU passed” is often stored as a scalar health flag. That flag discards the probe identifier, flow keys, route generation, overhead and confirmation age. It cannot show whether a later packet followed the same constraints.

What IPv6 PMTUD actually maintains

RFC 8201 defines a path MTU as the minimum link MTU along a path between a source and destination. A source can begin with the first-hop link MTU and reduce its estimate after receiving a validated ICMPv6 Packet Too Big message. Several packet-and-PTB cycles may be needed because a still smaller link can lie farther along the path.

The RFC also makes time part of the state. Routing-topology changes can alter a path's PMTU. Reductions are detected through Packet Too Big messages; increases require the source to try a larger size periodically. After a reduction, RFC 8201 recommends not attempting an increase more often than once every five minutes. Cached information is therefore an estimate with an ageing policy, not a permanent property of the destination.

A PTB message is useful evidence only after validation that it corresponds to traffic sent by the node. Even then, its reported MTU identifies a constraint encountered on that exchange. It does not explain why a route changed, which tunnel inserted overhead, or whether every parallel member has the same ceiling.

What positive probe feedback proves

RFC 8899 moves discovery into the packetization layer for datagram transports. The sender selects a probe size and needs feedback showing that the specific probe reached the remote packetization-layer endpoint. Once acknowledged, the probed size can become the current PLPMTU and the search can continue.

That is stronger than inferring success from silence. It is still deliberately narrow. One lost probe is not enough to declare a PMTU failure because congestion, corruption or reordering can also lose or delay a packet. Conversely, one acknowledged probe does not turn Search Complete into a lifetime warranty. For an unacknowledged packetization layer without other delivery evidence, RFC 8899 uses a confirmation timer to test whether the current size remains supported.

The RFC tells implementations to be robust when path information is inconsistent, packets are reordered or duplicated, or traffic is divided over more than one network path. Where multipath or multihoming is supported, it calls for a state machine for each path. That requirement is the opposite of a destination-wide green light.

The packetization limit is not the wire MTU

Operators also need to distinguish the network-layer PMTU from the maximum payload presented by a packetization layer. Headers added below that layer consume space. A new tunnel, security wrapper or extension header can reduce the usable message size even when the physical link MTU has not changed.

RFC 8899 expresses the application-facing result as a maximum packet size derived from the PLPMTU. That value can change after a path change or probe loss. Recording only “1,450 succeeded” without the layer and header context makes two different quantities look identical.

The same caution applies to failure. Repeated loss at one size can support black-hole handling, but it does not by itself attribute the loss to MTU. Congestion, policy filters, receiver state and ordinary path loss remain alternatives. The algorithm's response is a safe operating adjustment, not a complete incident verdict.

Sources