This section lists the protocol mechanisms used in this specification.
The DPLPMTUD method relies upon the PL sender being able to generate probe packets with a specific size. TCP is able to generate these probe packets by choosing to appropriately segment data being sent [RFC 4821
]. In contrast, a datagram PL that constructs a probe packet has to either request an application to send a data block that is larger than that generated by an application, or to utilize padding functions to extend a datagram beyond the size of the application data block. Protocols that permit exchange of control messages (without an application data block) can generate a probe packet by extending a control message with padding data. The total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including protocol option fields, security-related fields such as an Authenticated Encryption with Associated Data (AEAD) tag, and TLS record layer padding).
A receiver is REQUIRED
to be able to distinguish an in-band data block from any added padding. This is needed to ensure that any added padding is not passed on to an application at the receiver.
This results in three possible ways that a sender can create a probe packet:
Probing using padding data:
A probe packet that contains only control information together with any padding, which is needed to inflate to the size of the probe packet. Since these probe packets do not carry an application-supplied data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing.
Probing using application data and padding data:
A probe packet that contains a data block supplied by an application that is combined with padding to inflate the length of the datagram to the size of the probe packet.
Probing using application data:
A probe packet that contains a data block supplied by an application that matches the size of the probe packet. This method requests the application to issue a data block of the desired probe size.
A PL that uses a probe packet carrying application data and that needs protection from the loss of this probe packet could perform transport-layer retransmission/repair of the data block (e.g., by retransmitting after loss is detected or by duplicating the data block in a datagram without the padding data). This retransmitted data block might possibly need to be sent using a smaller PLPMTU, which could force the PL to use a smaller packet size to traverse the end-to-end path. (This could utilize endpoint network-layer fragmentation or a PL that can resegment the data block into multiple datagrams).
choose to use only one of these methods to simplify the implementation.
Probe messages sent by a PL MUST
contain enough information to uniquely identify the probe within the Maximum Segment Lifetime (e.g., including a unique identifier from the PL or the DPLPMTUD implementation), while being robust to reordering and replay of probe response and PTB messages.
The PL needs a method to determine (confirm) when probe packets have been successfully received end-to-end across a network path.
Transport protocols can include end-to-end methods that detect and report reception of specific datagrams that they send (e.g., DCCP, SCTP, and QUIC provide keep-alive/heartbeat features). When supported, this mechanism MAY
also be used by DPLPMTUD to acknowledge reception of a probe packet.
A PL that does not acknowledge data reception (e.g., UDP and UDP-Lite) is unable itself to detect when the packets that it sends are discarded because their size is greater than the actual PMTU. These PLs need to rely on an application protocol to detect this loss.
specifies this function for a set of IETF-specified protocols.
The description that follows uses the set of constants defined in Section 5.1.2
and variables defined in Section 5.1.3
Black hole detection is triggered by an indication that the network path could be unable to support the current PLPMTU size.
There are three indicators that can be used to detect black holes:
A validated PTB message can be received that indicates a PL_PTB_SIZE less than the current PLPMTU. A DPLPMTUD method MUST NOT rely solely on this method.
A PL can use the DPLPMTUD probing mechanism to periodically generate probe packets of the size of the current PLPMTU (e.g., using the CONFIRMATION_TIMER, Section 5.1.1). A timer tracks whether acknowledgments are received. Successive loss of probes is an indication that the current path no longer supports the PLPMTU (e.g., when the number of probe packets sent without receiving an acknowledgment, PROBE_COUNT, becomes greater than MAX_PROBES).
A PL can utilize an event that indicates the network path no longer sustains the sender's PLPMTU size. This could use a mechanism implemented within the PL to detect excessive loss of data sent with a specific packet size and then conclude that this excessive loss could be a result of an invalid PLPMTU (as in PLPMTUD for TCP [RFC 4821]).
The three methods can result in different transmission patterns for packet probes and are expected to result in different responsiveness following a change in the actual PMTU.
A PL MAY
inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL that resumes sending user data MAY
continue PLPMTU discovery for each path. This allows it to use an up-to-date PLPMTU. However, this could result in additional packets being sent.
When the method detects that the current PLPMTU is not supported, DPLPMTUD sets a lower PLPMTU and a lower MPS. The PL then confirms that the new PLPMTU can be successfully used across the path. A probe packet could need to be smaller than the size of the data block generated by the application.
The result of probing determines a usable PLPMTU, which is used to set the MPS used by the application. The MPS is smaller than the PLPMTU because it is reduced by the size of PL headers (including the overhead of security-related fields such as an AEAD tag and TLS record layer padding). The relationship between the MPS and the PLPMTUD is illustrated in Figure 1
headers .--- MPS -----.
| | |
v v v
| IP | ** | PL | protocol data |
<----- PLPMTU ----->
<---------- PMTU -------------->
A PL is unable to send a packet (other than a probe packet) with a size larger than the current PLPMTU at the network layer. To avoid this, a PL MAY
be designed to segment data blocks larger than the MPS into multiple datagrams.
DPLPMTUD seeks to avoid IP fragmentation. An attempt to send a data block larger than the MPS will therefore fail if a PL is unable to segment data. To determine the largest data block that can be sent, a PL SHOULD
provide applications with a primitive that returns the MPS, derived from the current PLPMTU.
If DPLPMTUD results in a change to the MPS, the application needs to adapt to the new MPS. A particular case can arise when packets have been sent with a size less than the MPS and the PLPMTU was subsequently reduced. If these packets are lost, the PL MAY
segment the data using the new MPS. If a PL is unable to resegment a previously sent datagram (e.g., [RFC 4960
]), then the sender either discards the datagram or could perform retransmission using network-layer fragmentation to form multiple IP packets not larger than the PLPMTU. For IPv4, the use of endpoint fragmentation by the sender is preferred over clearing the DF bit in the IPv4 header. Operational experience reveals that IP fragmentation can reduce the reliability of Internet communication [RFC 8900
], which may reduce the probability of successful retransmission.
A PL implementing this specification MUST
suspend network layer processing of outgoing packets that enforces a PMTU [RFC 1191
] for each flow utilizing DPLPMTUD and instead use DPLPMTUD to control the size of packets that are sent by a flow. This removes the need for the network layer to drop or to fragment sent packets that have a size greater than the PMTU.
This method requires the DPLPMTUD sender to validate any received PTB message before using the PTB information. The response to a PTB message depends on the PL_PTB_SIZE calculated from the PTB_SIZE in the PTB message, the state of the PLPMTUD state machine, and the IP protocol being used.
describes validation for both IPv4 ICMP Unreachable messages (Type 3) and ICMPv6 Packet Too Big messages, both of which are referred to as PTB messages in this document.
This section specifies utilization and validation of PTB messages.
A simple implementation MAY ignore received PTB messages, and in this case, the PLPMTU is not updated when a PTB message is received.
A PL that supports PTB messages MUST validate these messages before they are further processed.
A PL that receives a PTB message from a router or middlebox performs ICMP validation (see Section 4
of RFC 8201
]). Because DPLPMTUD operates at the PL, the PL needs to check that each received PTB message is received in response to a packet transmitted by the endpoint PL performing DPLPMTUD.
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. This validation includes determining that the combination of the IP addresses, the protocol, the source port, and destination port match those returned in the quoted packet -- this is also necessary for the PTB message to be passed to the corresponding PL.
The validation SHOULD
utilize information that is not simple for an off-path attacker to determine [BCP145
]. For example, it could check the value of a protocol header field known only to the two PL endpoints. A datagram application that uses well-known source and destination ports ought to also rely on other information to complete this validation.
These checks are intended to provide protection from packets that originate from a node that is not on the network path. A PTB message that does not complete the validation MUST NOT
be further utilized by the DPLPMTUD method, as discussed in the Security Considerations section (Section 8
describes this processing of PTB messages.
PTB messages that have been validated MAY
be utilized by the DPLPMTUD algorithm but MUST NOT
be used directly to set the PLPMTU.
Before using the size reported in the PTB message, it must first be converted to a PL_PTB_SIZE. The PL_PTB_SIZE is smaller than the PTB_SIZE because it is reduced by headers below the PL, including any IP options or extensions added to the PL packet.
A method that utilizes these PTB messages can improve the speed at which the algorithm detects an appropriate PLPMTU by triggering an immediate probe for the PL_PTB_SIZE (resulting in a network-layer packet of size PTB_SIZE), compared to one that relies solely on probing using a timer-based search algorithm.
A set of checks are intended to provide protection from a router that reports an unexpected PTB_SIZE. The PL also needs to check that the indicated PL_PTB_SIZE is less than the size used by probe packets and at least the minimum size accepted.
This section provides a summary of how PTB messages can be utilized, using the set of constants defined in Section 5.1.2
. This processing depends on the PL_PTB_SIZE and the current value of a set of variables:
PL_PTB_SIZE < MIN_PLPMTU
Invalid PL_PTB_SIZE, see Section 4.6.1.
PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified).
The information could be utilized as an input that triggers the enabling of a resilience mode (see Section 5.3.3).
MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU
A robust PL MAY enter an error state (see Section 5.2) for an IPv4 path when the PL_PTB_SIZE reported in the PTB message is larger than or equal to 68 bytes [RFC 0791] and when this is less than the BASE_PLPMTU.
A robust PL MAY enter an error state (see Section 5.2) for an IPv6 path when the PL_PTB_SIZE reported in the PTB message is larger than or equal to 1280 bytes [RFC 8200] and when this is less than the BASE_PLPMTU.
BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU
This could be an indication of a black hole. The PLPMTU SHOULD be set to BASE_PLPMTU (the PLPMTU is reduced to the BASE_PLPMTU to avoid unnecessary packet loss when a black hole is encountered).
The PL ought to start a search to quickly discover the new PLPMTU. The PL_PTB_SIZE reported in the PTB message can be used to initialize a search algorithm.
PLPMTU < PL_PTB_SIZE < PROBED_SIZE
The PLPMTU continues to be valid, but the size of a packet used to search (PROBED_SIZE) was larger than the actual PMTU.
The PLPMTU is not updated.
The PL can use the reported PL_PTB_SIZE from the PTB message as the next search point when it resumes the search algorithm.
PL_PTB_SIZE >= PROBED_SIZE
Inconsistent network signal.
PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified).
The information could be utilized as an input to trigger the enabling of a resilience mode.