Path MTU discovery
obsoletes
- rfc-1063 — IP MTU discovery options
Extracted elements (25)
A plateau table of representative MTU values is recommended over binary search or multiplicative reduction for discovering PMTU from old-style messages. The plateau approach converges as fast as binary search in the worst case and far better in practice (FDDI to Ethernet in two RTTs vs. four or five), and never underestimates the true MTU by more than a factor of 2 since plateaus lie near powers of two.
PMTU information is stored at the IP layer rather than in individual packetization protocols to avoid duplicating the implementation across TCP, UDP, and application protocols, to enable sharing of PMTU data across connections sharing a path, and because transport-layer connection state does not easily persist PMTU values long-term.
The only router change required is placing the next-hop MTU in a previously-unused ICMP field, minimizing deployment burden. Old routers leave the field zero (as required by RFC 792), which hosts can detect and handle via fallback strategies, ensuring the mechanism provides at least as good a PMTU estimate as pre-discovery practice even on unupgraded paths.
NFS over UDP frequently sends datagrams requiring fragmentation even on the first hop. NFS implementations should use PMTU Discovery but must not reduce datagram size below the minimum needed for a single RPC operation; in that case DF must not be set, allowing fragmentation.
Old-style (unmodified) routers send Datagram Too Big messages with a zero Next-Hop MTU field. A simple host fallback is to assume PMTU is the minimum of the current estimate and 576 and stop setting DF, matching pre-discovery behavior; more sophisticated strategies use the plateau table to search for an accurate estimate.
Routers derived from 4.2BSD send an incorrect Total Length in ICMP Datagram Too Big messages (original Total Length plus original Header Length in octets). Since the receiver cannot identify such routers, it must conservatively correct the value by subtracting 4 times the returned Header Length before using it in plateau-table lookup.
Transport protocols that cannot repacketize on retransmission (e.g., ISO TP4) should retransmit oversized datagrams without the DF bit to allow fragmentation, while transmitting new datagrams within the discovered PMTU with DF set.
A host MUST never reduce its estimate of the Path MTU below 68 octets.
A host MUST NOT increase its estimate of the Path MTU in response to a Datagram Too Big message, as the message might be stale, forged as a denial-of-service attack, or the result of multiple paths to the destination.
A TCP implementation MUST NOT retransmit in response to every Datagram Too Big message; a burst of oversized segments produces multiple such messages and hence multiple retransmissions, leading to exponential growth in superfluous traffic if the new PMTU estimate is still wrong.
After receiving a Datagram Too Big message, a host MUST attempt to avoid eliciting more such messages and MUST force the PMTU Discovery process to converge, either by reducing datagram size or ceasing to set DF.
An upper layer MUST NOT retransmit datagrams in response to an increase in the PMTU estimate, since such an increase never comes in response to an indication of a dropped datagram.
Attempts to detect a PMTU increase MUST NOT be done less than 5 minutes after a Datagram Too Big message has been received for the given destination, or less than 1 minute after a previous successful increase. Recommended timers are 10 minutes and 2 minutes respectively.
Hosts MUST be able to deal with Datagram Too Big messages that do not include the next-hop MTU (Next-Hop MTU field is zero), since upgrading all Internet routers is not feasible in finite time.
Hosts SHOULD no longer lower the TCP MSS option value for non-local peers; the MSS should be 40 octets less than the largest datagram the host can reassemble (MMS_R), enabling PMTU Discovery to find PMTUs larger than 576.
When a host receives a Datagram Too Big message, it MUST reduce its estimate of the PMTU for the relevant path based on the Next-Hop MTU field in the message.
When a router cannot forward a datagram because it exceeds the next-hop MTU and DF is set, the router MUST include that next-hop MTU in the low-order 16 bits of the ICMP header field; the high-order 16 bits MUST be set to zero.
A plateau table of common Internet MTU values (ranging from 68 to 65535 octets, covering Ethernet at 1500, FDDI at 4352, SLIP at 1006, X.25 at 576, and others) is used to search for an accurate PMTU when old-style Datagram Too Big messages are received; the recommended estimate is the greatest plateau value less than the returned Total Length.
Cached PMTU information is aged to handle route changes: when a PMTU value has not been decreased for approximately 10 minutes, the estimate is reset to the first-hop link MTU and all packetization layers using the path are notified, restarting the PMTU Discovery process.
Path MTU Discovery uses the IP Don't Fragment (DF) bit: a source host sets DF on all datagrams and initially assumes the PMTU equals the first-hop MTU. ICMP Destination Unreachable messages with Code 4 ('fragmentation needed and DF set'), called 'Datagram Too Big' messages, signal that the current PMTU estimate is too high, causing the host to reduce it.
PMTU values are stored per-path (identified by source address, destination address, and IP type-of-service) as fields in per-host routing table entries. Per-network and default route entries are initialized to the first-hop link MTU and MUST never be modified by PMTU Discovery; only per-host route entries are created or updated.
The TCP layer must track each connection's PMTU and not send segments exceeding both the PMTU and the peer's MSS option (defaulting to 536). A PMTU-triggered retransmission should not reduce the congestion window but should trigger slow-start; the send window must be adjusted to the greatest multiple of the new segment size fitting in the send buffer.
A malicious party can send false Datagram Too Big messages claiming a PMTU larger than reality, causing temporary blockage as the victim sends oversized datagrams that are dropped. Because hosts must never raise their PMTU estimate based on a Datagram Too Big message, they are not directly vulnerable; however, frequent repetition can cause significant datagram loss within one RTT per attack cycle.
PMTU Discovery cycles through: (1) Initial—PMTU assumed equal to first-hop MTU, DF set; (2) Reducing—on each Datagram Too Big, PMTU estimate is decreased and datagrams retransmitted at new size; (3) Stable—datagrams traverse path without fragmentation; (4) Probing—after timeout (~10 min), estimate is raised to probe for PMTU increases, possibly re-entering Reducing.
The ICMP Destination Unreachable 'fragmentation needed and DF set' message (Type=3, Code=4) is extended: the previously-unused 32-bit field is split into a 16-bit 'unused' high-order half (MUST be zero) and a 16-bit 'Next-Hop MTU' low-order field carrying the MTU of the constricting hop in octets, including IP header and data but excluding lower-level headers.