ietf-corpus

rfc-4821

Packetization Layer Path MTU Discovery

M. Mathis, J. Heffner
date2007-03 streamIETF areatsv wgpmtud statusPROPOSED STANDARD pages32 canonicalhttps://www.rfc-editor.org/rfc/rfc4821 doi10.17487/RFC4821
This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]

updated by

Extracted elements (29)

design-rationale §7.2

An initial eff_pmtu of 1400 bytes is suggested as a good compromise: safe for nearly all tunnels over common networking gear, yet close to the optimal MTU for most Internet paths today. Alternatively, using the median probe size of recent successful flows can improve the estimate.

ip, congestion

design-rationale §7.3

For TCP, a strategy that raises probe size in smaller increments may have lower overhead than binary search because failed probes are more expensive than successful ones (probe gap data must be retransmitted). For protocols where both directions cost equally, binary search halving the range each probe is simpler.

tcp, ip

design-rationale §2

In its limiting configuration where all ICMP PTB messages are ignored, PLPMTUD parallels congestion control: a transport protocol adjusts packet size using losses to deduce appropriateness, which is considered more philosophically consistent with the end-to-end principle than relying on ICMP messages containing transcribed multi-layer headers.

ip, congestion

design-rationale §8

IPv4 fragmentation should mimic IPv6 behavior (fragment at the host, set DF bit on all fragments) to minimize reliance on network fragmentation that cannot be implemented in IPv6, facilitating future migration and reducing exposure to IPv4 fragmentation reassembly errors.

ip

design-rationale §2

The isolated loss of a probe packet is treated as an MTU limit indication rather than a congestion signal, allowing retransmission of missing data without adjusting the congestion window; this exception is permissible because probe failures must be rate-limited to less than the TCP-friendly loss rate.

congestion, tcp

interoperability-note §10.3

For IP fragmentation as a Packetization Layer, an implementation SHOULD rely on path MTU sharing plus an adjunct protocol (e.g., ICMP ECHO) to probe Path MTU because the IP layer has no mechanism to determine whether packets are ultimately delivered without direct application participation.

ip

interoperability-note §5.3

IPsec may be treated as part of IP or as part of the Packetization Layer; if treated as part of IP, each security association to a remote node may need to be treated as a separate path. If treated as part of the Packetization Layer, the IPsec header size MUST be included in header size calculations.

ipsec, ip, vpn

interoperability-note §1

PLPMTUD is an extension to RFC 1191 (IPv4 PMTUD) and RFC 1981 (IPv6 PMTUD); it does not update those RFCs but implicitly relaxes their requirements by supporting correct operation without ICMP. Since PLPMTUD applies only to senders, implementation variants will not cause interoperability problems with peers.

ip, congestion

normative-requirement §4 SHOULD

All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6 functionality: all fragmentation SHOULD be done on the host, and all IPv4 packets including fragments SHOULD have the DF bit set.

ip

normative-requirement §9 MUST

All implementations MUST include a mechanism where applications using connectionless protocols can send their own probes; a third OS mode is REQUIRED where a datagram is sent even if larger than the current eff_pmtu estimate, with the DF bit set for IPv4.

ip, udp

normative-requirement §4 MUST

All implementations MUST include mechanisms for applications to selectively transmit packets larger than the current effective Path MTU but smaller than the first-hop link MTU, necessary to implement PLPMTUD in connectionless protocols and diagnostic tools.

ip, congestion

normative-requirement §4 MUST

All links MUST enforce their MTU: links that might non-deterministically deliver packets larger than their rated MTU MUST consistently discard such packets. This is the only requirement PLPMTUD places on lower layers.

ip, congestion

normative-requirement §7.2 RECOMMENDED

It is RECOMMENDED that search_low be initially set to 1024 bytes as a value likely to work over a very wide range of environments; the initial value for search_low SHOULD be configurable.

ip, congestion

normative-requirement §5.2 MUST NOT

Network or subnet numbers MUST NOT be used as representations of a path, because there is not a general mechanism to determine the network mask at the remote host.

ip

normative-requirement §4 MUST

Normal congestion control algorithms MUST remain in effect under all conditions except when only an isolated probe packet is detected as lost; in that one case, the normal congestion window or data rate reduction SHOULD be suppressed. If any other data loss is detected, standard congestion control MUST take place.

congestion, tcp

normative-requirement §4 MUST

Suppressed congestion control MUST be rate limited so it occurs less frequently than the worst-case TCP-friendly loss rate; this SHOULD be enforced by requiring a minimum headway between a suppressed congestion adjustment and the next probe equal to one RTT per packet permitted by the congestion window.

congestion, tcp

normative-requirement §7.3 MUST NOT

The probing convergence timer MUST NOT be less than 5 minutes and is recommended to be 10 minutes per RFC 1981; when it expires, search_high is reset to its initial value so the flow can take advantage of path MTU increases.

ip, congestion

normative-requirement §4 MUST

To use PLPMTUD, a Packetization Layer MUST have a loss reporting mechanism that provides the sender with timely and accurate indications of which packets were lost in the network.

congestion, tcp

normative-requirement §5.1 MUST

When conducting a probe, the Packetization Layer MUST determine the probe packet's final size including IP headers; this may require additional inter-layer communication in existing implementations.

ip, tcp

normative-requirement §4 MUST

Whenever the MTU is raised, congestion state variables MUST be rescaled so as not to increase the window size in bytes (or data rate in bytes per second).

congestion, ip

protocol-element §7.7

A full-stop timeout (none of the packets transmitted after some event are acknowledged, including retransmissions) is taken as indication of a disruptive network event. The response is to treat it as an ICMP black hole: reduce eff_pmtu to search_low, and on successive timeouts halve search_low and eff_pmtu with a lower bound of 68 bytes for IPv4 and 1280 bytes for IPv6.

ip, congestion, tcp

protocol-element §7.5

A probe packet is a packet used to test a path for a larger MTU; its size including IP headers equals the probe size. Probe outcomes are classified as: Success (acknowledged by remote), Failure (probe lost, no other losses), Timeout Failure (loss via timeout with go-back-n, trailing window indeterminate), or Inconclusive (probe lost along with other packets).

ip, congestion, tcp

protocol-element §10.2

For SCTP probing, the recommended method is to attach a PAD chunk (RFC 4820) to a minimum-length HEARTBEAT chunk to build a probe packet; this is fully compatible with all current SCTP implementations. SCTP must independently probe the PMTU on each path to the peer.

sctp, ip

protocol-element §10.1

For TCP probing, two segmentation methods are defined: non-overlapping (probe and subsequent segments contain no overlapping data; failed probe gap requires retransmitting multiple smaller segments) and overlapping (subsequent data overlaps the probe such that the probe gap equals one MSS; probe size SHOULD be limited to 3x current MSS to avoid triggering Fast Retransmit).

tcp, ip

protocol-element §7.8

MTU verification detects cases where raising eff_pmtu sharply increases loss rate (e.g., striped paths with inconsistent MTUs). A recommended strategy saves the old eff_pmtu; if loss rate exceeds ~10% over multiple RTO intervals, the new MTU is considered incorrect, the saved value is restored, and search_high is reduced as in a probe failure.

ip, congestion

protocol-element §7.1

PLPMTUD maintains three state variables per flow: search_low (smallest useful probe size minus one, network expected to deliver packets of this size), search_high (greatest useful probe size, expected too large), and eff_pmtu (effective PMTU, largest non-probe packet permitted).

ip, congestion

security-consideration §11

Because Packetization Layer protocols may share PMTU state, an untrusted or hostile packetization protocol (particularly an application) could harm other protocols on the same host by reducing shared effective MTU state; untrusted protocols SHOULD NOT be permitted to write to shared path MTU state.

security, ip

security-consideration §11

PLPMTUD can be configured to ignore all ICMP messages globally or per-application, making it unattackable via spoofed ICMP PTB messages; an attacker can only degrade performance by causing probe packets to be lost, which is less damaging than attacking congestion control by causing arbitrary packet loss.

security, ip

state-machine §7.6

On Probe Success: set search_low to probe size, raise eff_pmtu if probe size exceeds it. On Probe Failure: set search_high to probe size minus one, reduce eff_pmtu to at most search_high. On Probe Timeout Failure: reduce congestion window, use longer inter-probe interval (5x failure case). On Probe Inconclusive: do not update state variables, retry same size probe once losses recover.

ip, congestion