Summary

  • A matching PATH_RESPONSE validates the path on which its PATH_CHALLENGE was sent; it is precise evidence about a particular address tuple.
  • Validation does not inherit the old path's capacity or RTT, and a small challenge can validate the address without validating path MTU.
  • Operations should keep path validation and application readiness as separate states joined by a broader evidence receipt.

The green light answers one question

RFC 9000 gives PATH_CHALLENGE and PATH_RESPONSE a narrow, valuable job. An endpoint sends unpredictable bytes on the path it wants to validate. Its peer echoes those bytes, using the path on which the challenge arrived. When the matching response returns, the initiator has evidence that packets traversed the tested address pair as required by the validation exchange.

That proof matters. It limits amplification against spoofed addresses and lets a connection survive an address change without treating every new tuple as trusted. But the meaning should not expand when it enters an operations dashboard. “Validated” is not shorthand for “ready for the same application load as the old path.”

The specification itself preserves this boundary. If anti-amplification limits prevented the challenge datagram from being expanded to at least 1200 bytes, the response can validate the peer address while leaving the path MTU unvalidated. A second, larger validation is required. Even the 1200-byte exchange proves a floor, not the largest datagram the path can reliably carry.

Migration starts new performance evidence

An established connection carries history: RTT samples, congestion-window state, loss observations and perhaps validated ECN behavior. Those observations belong to the path on which they were collected. RFC 9000 warns that a new path might not support the current sending rate. For a genuine address change, it therefore resets the congestion controller and RTT estimator to initial values, except for the defined port-only case.

This is a strong clue for operators. If the protocol does not treat capacity learned on the old path as proof about the new one, the monitoring system should not do so either. A successful PATH_RESPONSE and a freshly conservative congestion state can coexist. So can successful validation and a larger-datagram black hole, a different queueing regime, or ECN that still needs validation.

RFC 9002 describes the loss-recovery and congestion-control machinery that governs how sending capacity is discovered. Those mechanisms consume ACK, loss and timing evidence over time. The eight echoed challenge bytes do not contain those measurements.

Sources