Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options
Extracted elements (29)
DPLPMTUD is not specified for multicast because the method requires explicit acknowledgement of probe packets via the RES Option in UDP Options, which is primarily intended for unicast use.
Probes seeking to increase the PLPMTU should not carry application data because they will be dropped whenever their size exceeds the actual PMTU, avoiding the need to retransmit lost application data on probe failure.
Probes used only for connectivity confirmation or path validation (black-hole detection) MAY carry application data because these probe sizes are more likely to succeed, reducing the need for additional datagrams. Searches for a larger PLPMTU always use padding-only probes.
The MDS (Maximum Datagram Size) Option value advertised by the remote endpoint MAY be used as a hint to initialize the PLPMTU search, providing a useful upper bound without requiring it to be authoritative.
The rate limit on RES Options sent solely in response to REQ Options exists to mitigate a DoS amplification vector: a sender could otherwise use DPLPMTUD probe packets to elicit a stream of responses from a victim receiver.
When DPLPMTUD is active at more than one layer simultaneously, REQ Option token values must be coordinated to ensure each probe packet can be identified by a unique token. Implementations should avoid performing DPLPMTUD both within UDP Options and in an Upper Layer protocol simultaneously.
A receiver that only piggybacks the RES Option onto application datagrams (rather than sending dedicated responses) can cause probe timeouts when traffic in the return direction is sparse, potentially resulting in a smaller PLPMTU than the path actually supports.
When the remote endpoint does not support UDP Options or does not return a RES Option, DPLPMTUD cannot confirm the path or discover the PLPMTU and will fall back to using the minimum configured PLPMTU (MIN_PLPMTU).
A PL using DPLPMTUD MUST validate that a path continues to support the discovered PLPMTU. Path validation probes in the SEARCH_COMPLETE state MUST include a REQ Option to elicit positive confirmation.
A receiver that responds to DPLPMTUD MUST process the REQ Option and include the corresponding RES Option with an Upper Layer protocol message returned to the requester.
A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity by sending a probe packet padded to size BASE_PLPMTU that includes the REQ UDP Option.
A UDP Options sender that utilizes ICMP PTB messages MUST use the quoted packet to validate the UDP port information in combination with the token contained in the UDP Option before processing the packet using the DPLPMTUD method.
An implementation unable to validate ICMP PTB messages (i.e., check quoted packet and REQ token) MUST ignore received ICMP PTB messages.
Before processing an ICMP PTB message, the receiver MUST validate the protocol information in the quoted packet to confirm the message originated from the sending node. The receiver SHOULD also confirm that the REQ Option token in the quoted packet corresponds to a recently sent probe.
By default, the API MUST disable DPLPMTUD processing. An API primitive MUST be provided to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port.
Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL). The UDP Options sender MUST NOT reuse a token value within the MSL.
If a UDP Options endpoint creates and sends a datagram with a RES Option solely as a response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., 1 per measured RTT or 1 per second per port pair) to mitigate DoS amplification.
Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data, since they will be lost whenever their size exceeds the actual PMTU; a probe packet MUST include the REQ Option.
Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD; a UDP Options sender may ignore received ICMP PTB messages entirely.
The four-byte token field in the REQ Option SHOULD be initialized to a randomized value to enhance protection from off-path attacks.
The size of a probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms such as PMTUD or the IP-layer PMTU cache.
UDP datagrams used as DPLPMTUD probe packets MUST NOT be fragmented at the UDP or IP layer. In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set and without network layer endpoint fragmentation.
Use of DPLPMTUD MUST be explicitly enabled by the application. A DPLPMTUD receiver MUST NOT respond to a UDP REQ Option until DPLPMTUD has been enabled, to protect against misuse of the mechanism for other forms of probing.
DPLPMTUD for UDP Options uses three UDP Options: the Request (REQ) Option carrying a four-byte token to solicit a response, the Response (RES) Option echoing the received token to confirm delivery, and the End of Options List (EOL) Option used to pad probe packets to the required size.
If subsequent probe packets use tokens that are easily derived from the initial value (e.g., sequential increments), an on-path observer can predict future token values and forge RES Options or manipulate DPLPMTUD behavior even for probe packets not transiting the observer.
On-path attackers can maliciously drop or modify probe packets to artificially decrease the PMTU or to black-hole traffic. Using an unpredictable token value for each probe packet mitigates the ability of an on-path observer to forge probe acknowledgements.
Upper Layer protocols or applications that employ encryption ought to perform DPLPMTUD at a layer above UDP Options and not enable UDP Options support for DPLPMTUD, ensuring probe packets are encrypted and giving the application control over the additional traffic generated.
The DPLPMTUD state machine operates in three key phases: BASE_PLPMTU confirmation (connectivity probing), SEARCHING (probing to find a larger PLPMTU, entered after PMTU_RAISE_TIMER expiry), and SEARCH_COMPLETE (periodic path validation to detect black-holing). Transitions are driven by probe success, failure, or timer expiry.
The REQ Option contains a four-byte (four-octet) token that uniquely identifies each probe request within the MSL for the specific 5-tuple. The RES Option echoes the last received four-byte token from the most recently received REQ Option.