Packetization Layer Path MTU Discovery for Datagram Transports
updates
- rfc-4821 — Packetization Layer Path MTU Discovery
- rfc-4960 — Stream Control Transmission Protocol
- rfc-6951 — UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
- rfc-8085 — UDP Usage Guidelines
- rfc-8261 — Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
Extracted elements (30)
BASE_PLPMTU is set to a size expected to work for most paths (RECOMMENDED > 1200 bytes) rather than the minimum IP-layer size, so that DPLPMTUD can allow applications to continue working during transient PMTU reductions without falling back to the minimum fragment size. This prevents long periods of unnecessarily low MPS.
DPLPMTUD does not rely on reception and validation of PTB messages, making it more robust than Classical PMTUD. PTB messages can be filtered by firewalls, rate-limited, lost due to tunnel misconfiguration, or blocked by routing asymmetry — any of which creates a packet black hole the classical method cannot detect.
SCTP probing uses a minimal HEARTBEAT chunk bundled with a PAD chunk rather than DATA chunks with padding. This enables probing without affecting user message transfer and without being limited by congestion control or flow control, because these probe packets do not carry application data.
For SCTP/UDP (RFC 6951), the UDP header (8 bytes) must be included in probe size calculations when filling the PAD chunk, and PTB message validation must account for the UDP header consuming part of the quoted packet header space.
QUIC is a UDP-based acknowledged PL that supports DPLPMTUD natively via padding and packet coalescence for probe construction. From DPLPMTUD's perspective, QUIC functions as an acknowledged PL; the QUIC specification describes the method for using DPLPMTUD with QUIC packets.
RFC 4960 does not specify a way to validate SCTP/DTLS ICMP message payloads, and neither does this document. This can prevent processing of PTB messages at the PL when SCTP is encapsulated in DTLS.
A DPLPMTUD method MUST NOT rely solely on validated PTB messages to detect black holes; it must also use probe-based confirmation or PL-layer loss detection.
A PL implementing this specification MUST suspend network layer processing of outgoing packets that enforces a PMTU for each flow utilizing DPLPMTUD, and instead use DPLPMTUD to control the size of packets sent by a flow.
A PL MUST NOT send a datagram (other than a probe packet) with a size at the PL that is larger than the current PLPMTU.
A PTB message MUST NOT be used to increase the PLPMTU; it may only trigger a probe to test whether a larger PLPMTU is supported.
An update to the PLPMTU (or MPS) MUST NOT increase the congestion window measured in bytes; an increase in packet size does not cause an increase in the data rate in bytes per second.
Any received PTB message MUST be validated before it is used to update PLPMTU discovery information. A PTB message that does not complete validation MUST NOT be further utilized by the DPLPMTUD method.
DPLPMTUD SHOULD only be performed at one layer between a pair of endpoints; an upper PL or application should avoid using DPLPMTUD when already enabled in a lower layer. A PL MUST adjust the MPS indicated by DPLPMTUD to account for any additional overhead introduced by the PL.
In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation. In IPv6, a probe packet is always sent without source fragmentation.
Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction, as this could result in unnecessary reduction of the sending rate.
Processing of PTB message payloads SHOULD be rate-limited to avoid a denial-of-service attack when arbitrary headers are included; the DPLPMTUD method is robust to such loss.
The PL MUST check the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node, including IP addresses, protocol, source port, and destination port.
The PROBE_TIMER MUST NOT be smaller than 1 second and SHOULD be larger than 15 seconds.
When an acknowledged PL (e.g., SCTP) is used and DPLPMTUD is in the SEARCH_COMPLETE state, DPLPMTUD SHOULD NOT continue to generate PLPMTU probes, and a sender MUST NOT implement the CONFIRMATION_TIMER.
When the transmission of probe packets is not controlled by the congestion controller, the interval between probe packets MUST be at least one RTT.
DPLPMTUD defines four constants: MAX_PROBES (default 3, maximum consecutive probe attempts), MIN_PLPMTU (smallest attempted PLPMTU, at least yielding 1280-byte IPv6 or 68-byte IPv4 packets), MAX_PLPMTU (constrained by local interface MTU and EMTU_R), and BASE_PLPMTU (expected working size for most paths, RECOMMENDED > 1200 bytes).
DPLPMTUD tracks two key variables: PROBED_SIZE (the size of the current probe packet as determined at the PL, a tentative PLPMTU value awaiting acknowledgment) and PROBE_COUNT (count of successive unsuccessful probe packets; reset to zero on each acknowledgment).
The Maximum Packet Size (MPS) is the largest application data block that can be sent using a single datagram. It is smaller than the PLPMTU because it is reduced by PL header sizes (including AEAD tags and TLS record layer padding). The PL SHOULD provide a primitive returning the current MPS to the higher layer.
Three probe packet types are defined: (1) padding-only probes carrying only control information and padding; (2) application data plus padding probes; and (3) application data-only probes sized to match the probe target. Probe messages MUST contain enough information to uniquely identify the probe within the MSL.
Three timers are defined: PROBE_TIMER (expires after max ACK wait time, >= 1s, SHOULD be > 15s); PMTU_RAISE_TIMER (600 seconds, after which DPLPMTUD re-enters Search Phase); and CONFIRMATION_TIMER (used only with unacknowledged PLs in SEARCH_COMPLETE state to periodically confirm the PLPMTU).
An on-path attacker able to create PTB messages with valid quoted IP packets could drive down the PLPMTU. Two mitigations are specified: (1) a PL sender never reduces PLPMTU below BASE_PLPMTU solely in response to a PTB message (it enters BASE state first); (2) PTB processing can be suspended in a robustness mode when subsequent probes confirm a larger size is path-supported.
If a PL can use cryptographic confidentiality or data-integrity mechanisms, the design ought to avoid adding padding to DPLPMTUD probe packets that is not also protected by those cryptographic mechanisms. Probe packet padding content does not influence the search algorithm.
PTB messages MUST be validated to protect against off-path attackers. A node supporting DPLPMTUD must validate the PTB payload to ensure it corresponds to a datagram actually sent by the PL. Validation SHOULD utilize information not easily determined by an off-path attacker, such as a protocol header field known only to the two PL endpoints.
DPLPMTUD defines five states: DISABLED (initial, or on loss of connectivity), BASE (confirms BASE_PLPMTU is path-supported; enters SEARCHING on success or ERROR on failure), SEARCHING (main probing state; increases PLPMTU via search algorithm; exits to SEARCH_COMPLETE or BASE on black hole), SEARCH_COMPLETE (normal maintenance; PMTU_RAISE_TIMER triggers re-entry to SEARCHING), and ERROR (conflicting path info; exits to SEARCHING once consistent BASE_PLPMTU confirmed).
SCTP probe packets consist of an SCTP common header followed by a HEARTBEAT chunk and a PAD chunk (RFC 4820). The PAD chunk length is set to (probe_size - sizeof(SCTP_common_header) - sizeof(HEARTBEAT_chunk)). The HEARTBEAT chunk SHOULD include the probe size to help associate HEARTBEAT ACKs with probe sizes.