Skip to main content

4. DPLPMTUD Mechanisms

This section lists the protocol mechanisms used in this specification.

4.1. PLPMTU Probe Packets​

The DPLPMTUD method relies on the PL sender being able to generate probe packets with a specific size. TCP is able to generate these probe packets by choosing a appropriate segment of data being sent [RFC4821]. In contrast, a datagram PL that constructs a probe packet has to either request the application to send a data block that is larger than that generated by the application or 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 the headers and padding added to the payload data being sent (e.g., including protocol option fields, security-related fields such as an AEAD tag, and TLS record layer padding).

REQUIRED: The receiver needs to be able to distinguish between in-band data blocks and any added padding. This is needed to ensure that any added padding is not passed to the receiving application.

Three Methods for Creating Probe Packets​

1. Probing using padding data​

A probe packet that contains only control information together with any padding needed to inflate the length of the datagram to the size of the probe packet. Since these probe packets do not carry an application-provided data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing.

2. 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.

3. Probing using application data​

A probe packet that contains a data block supplied by an application that matches the size of a probe packet. This method requests the application to issue a data block of the desired probe size.

Probe Packet Protection​

PLs that use probe packets carrying application data that need to be resilient to the loss of this probe packet can perform transport layer retransmission/repair of the data block (e.g., by retransmission after loss is detected or by duplicating the data block in a datagram without the padding data). This retransmitted data block might 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 could segment the data block into multiple datagrams by a PL).

DPLPMTUD MAY choose to use only one of these methods to simplify the implementation.

Probe Packet Identification​

Probe messages sent by the 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 from the DPLPMTUD implementation) and be robust to reordering and replay of probe responses and PTB messages.

4.2. Confirmation of Probed Packet Size​

The PL needs a method to determine (confirm) when a probe packet has been successfully received end-to-end across a network path.

Transport protocols can include end-to-end methods that detect and report the reception of specific datagrams they send (e.g., DCCP, SCTP, and QUIC provide keep-alive/heartbeat functions). When supported, this mechanism MAY also be used by DPLPMTUD to acknowledge reception of a probe packet.

PLs that do not acknowledge data reception (e.g., UDP and UDP-Lite) are unable by themselves to detect when a packet they send has been discarded because its size is greater than the actual PMTU. These PLs need to rely on an application protocol to detect this loss.

Section 6 specifies this function for a set of IETF-specified protocols.

4.3. Black Hole Detection and Reducing the PLPMTU​

The description below 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.

Three Black Hole Detection Indicators​

1. PTB Message Indication​

A validated PTB message can be received that indicates a PL_PTB_SIZE less than the current PLPMTU. The DPLPMTUD method MUST NOT rely solely on this method.

2. Periodic Probing​

The PL can use the DPLPMTUD probing mechanism to periodically generate probe packets of the current PLPMTU size (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 sustains the PLPMTU (e.g., when the number of probe packets sent without receiving an acknowledgment, PROBE_COUNT, becomes greater than MAX_PROBES).

3. PL Event Indication​

The PL can utilize an event that indicates the network path is no longer sustaining the sender's PLPMTU size. This can be detected using mechanisms implemented within the PL to detect excessive loss of data sent with a specific packet size, and then deduce that this excessive loss could be a result of an invalid PLPMTU (as for PLPMTUD for TCP [RFC4821]).

Probing Pattern Differences​

These three methods can result in different transmission patterns for packets used as probes and are expected to result in different responsiveness after an actual PMTU change.

Probe Suppression​

MAY: The PL suppress sending probe packets when an application has not sent data since the last probe packet.

A PL that resumes sending user data MAY continue to use PLPMTU discovery for each path. This allows it to use the latest PLPMTU. However, this could result in additional packets being sent.

PLPMTU Reduction​

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 for the path. Probe packets might need to be smaller than the size of data blocks generated by the application.

4.4. The Maximum Packet Size (MPS)​

The result of probing determines the available 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 for security-related fields such as AEAD tags and TLS record layer padding).

Relationship Between MPS and PLPMTU​

|<----- PLPMTU ----->|
|<-- MPS -->|  PL Headers  |  IP Headers  |
| App Data  | Transport | Security | Network |

The PL cannot send a packet (other than a probe packet) with a size at the network layer that is larger than the current PLPMTU. 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. If the PL is unable to segment data, an attempt to send a data block larger than the MPS will fail. To determine the largest data block that can be sent, a PL SHOULD provide a primitive to the application that returns the MPS derived from the current PLPMTU.

MPS Change Handling​

If DPLPMTUD results in a change to the MPS, applications need to adapt to the new MPS. A particular case can arise when packets are sent with a size less than the MPS and the PLPMTU is subsequently reduced. If these packets are lost, the PL MAY segment the data using the new MPS.

If the PL is unable to resegment a previously sent datagram (e.g., [RFC4960]), the sender either discards the datagram or can perform retransmission using network layer fragmentation to form multiple IP packets not larger than the PLPMTU. For IPv4, the sender uses endpoint fragmentation in preference to clearing the DF bit in the IPv4 header. Operational experience shows that IP fragmentation can reduce the reliability of Internet communication [RFC8900], which could reduce the probability of successful retransmission.

4.5. Disabling the Effect of PMTUD​

A PL implementing this specification MUST suspend enforcement of the PMTU [RFC1191] [RFC8201] for network layer processing of outgoing packets for each flow that uses DPLPMTUD and instead use DPLPMTUD to control the size of packets that the flow sends. This eliminates the need for the network layer to drop or fragment sent packets with a size greater than the PMTU.

4.6. Response to PTB Messages​

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 in use.

Section 4.6.1 describes validation of 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.

4.6.1. Validation of PTB Messages​

This section specifies utilization and validation of PTB messages.

Implementation Options​

  • Simple Implementation: MAY ignore received PTB messages, in which case the PLPMTU is not updated when a PTB message is received.

  • PL Supporting PTB: MUST validate these messages before further processing.

Validation Process​

A PL that receives a PTB message from a router or middlebox performs ICMP validation (see Section 4 of [RFC8201] and Section 5.2 of [BCP145]). Because DPLPMTUD operates at the PL, the PL needs to check each received PTB message to determine whether it was received in response to a packet originated 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 that the message originated from the sending node. This validation includes determining that the combination of IP addresses, protocol, source port, and destination port match the combination returned in the quoted packet -- this is also necessary for the PTB message to be passed to the corresponding PL.

Validation SHOULD utilize information that is not readily available to an off-path attacker [BCP145]. For example, it can check the value of protocol header fields known only to the two PL endpoints. Datagram applications using well-known source and destination ports ought also to rely upon 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. PTB messages that have not completed validation MUST NOT be further utilized by the DPLPMTUD method, as discussed in the Security Considerations section (Section 8).

Section 4.6.2 describes the processing of PTB messages.

4.6.2. Use of PTB Messages​

A validated PTB message 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.

Methods that utilize these PTB messages can improve the speed with which the algorithm detects an appropriate PLPMTU by triggering an immediate probe for a PL_PTB_SIZE (resulting in a network-layer packet size of PTB_SIZE), compared to methods that rely solely on a timer-based search algorithm.

A set of checks are intended to provide protection from a router reporting an unexpected PTB_SIZE. The PL also needs to check that the indicated PL_PTB_SIZE is less than the size used by a probe packet and at least the minimum accepted size.

PTB Message Processing Summary​

This section provides a summary of how PTB messages are utilized, using the set of constants defined in Section 5.1.2. This processing depends on the PL_PTB_SIZE and the current values of a set of variables:

PL_PTB_SIZE < MIN_PLPMTU​

  • Invalid PL_PTB_SIZE, see Section 4.6.1
  • The PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified)
  • This information could be utilized as an input to trigger enabling a resilience mode (see Section 5.3.3)

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU​

  • A robust PL MAY enter the 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 [RFC0791] and less than BASE_PLPMTU
  • A robust PL MAY enter the 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 [RFC8200] and less than 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 (PLPMTU is reduced to 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 the search algorithm

PLPMTU < PL_PTB_SIZE < PROBED_SIZE​

  • The PLPMTU continues to be valid, but the size used for a search (PROBED_SIZE) is larger than the actual PMTU
  • The PLPMTU is not updated
  • When it resumes the search algorithm, the PL can use the PL_PTB_SIZE reported in the PTB message as the next search point

PL_PTB_SIZE >= PROBED_SIZE​

  • Inconsistent network signal
  • The PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified)
  • This information could be utilized as an input that triggers enabling a resilience mode

These mechanisms together ensure that DPLPMTUD can reliably discover and maintain an appropriate Path MTU.

Last updated on