• The generation of ICMP messages is usually rate limited. This could result in no PTB messages being generated to the sender (see Section 2.4 of RFC 4443).
• ICMP messages can be filtered by middleboxes, including firewalls [RFC 4890]. A firewall could be configured with a policy to block incoming ICMP messages, which would prevent reception of PTB messages by a sending endpoint behind this firewall.
• When the router issuing the ICMP message drops a tunneled packet, the resulting ICMP message is directed to the tunnel ingress. This tunnel endpoint is responsible for forwarding the ICMP message, processing the quoted packet within the payload field to remove the effect of the tunnel and returning a correctly formatted ICMP message to the sender [TUNNELS]. Failure to do this prevents the PTB message from reaching the original sender.
• Asymmetry in forwarding can result in there being no return route to the original sender, which would prevent an ICMP message from being delivered to the sender. This issue can also arise when either policy-based or Equal-Cost Multipath (ECMP) routing is used or when a middlebox acts as an application load balancer. An example of which is an ECMP router choosing a path toward the server based on the bytes in the IP payload. In this case, if a packet sent by the server encounters a problem after the ECMP router, then the ECMP router needs to direct any resulting ICMP message toward the original sender.
• There are additional cases where the next-hop destination fails to receive a packet because of its size. This could be due to misconfiguration of the layer 2 path between nodes, for instance the MTU configured in a layer 2 switch, or misconfiguration of the Maximum Receive Unit (MRU). If a packet is dropped by the link, this will not cause a PTB message to be sent to the original sender.

• When a router issuing the ICMP message implements RFC 792 [RFC 0792], it is only required to include the first 64 bits of the IP payload of the packet within the quoted payload. There could be insufficient bytes remaining for the sender to interpret the quoted transport information. Note: The recommendation in RFC 1812 [RFC 1812] is that IPv4 routers return a quoted packet with as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes. IPv6 routers include as much of the invoking packet as possible without the ICMPv6 packet exceeding 1280 bytes [RFC 4443].
• The use of tunnels and/or encryption can reduce the size of the quoted packet returned to the original source address, increasing the risk that there could be insufficient bytes remaining for the sender to interpret the quoted transport information.
• Even when the PTB message includes sufficient bytes of the quoted packet, the network layer could lack sufficient context to validate the message because validation depends on information about the active transport flows at an endpoint node (e.g., the socket/address pairs being used and other protocol header information).
• When a packet is encapsulated/tunneled over an encrypted transport, the tunnel/encapsulation ingress might have insufficient context, or computational power, to reconstruct the transport header that would be needed to perform validation.
• When an ICMP message is generated by a router in a network segment that has inserted a header into a packet, the quoted packet could contain additional protocol header information that was not included in the original sent packet and that the PL sender does not process or may not know how to process. This could disrupt the ability of the sender to validate this PTB message.
• A Network Address Translation (NAT) device that translates a packet header ought to also translate ICMP messages and update the ICMP-quoted packet [RFC 5508] in that message. If this is not correctly translated, then the sender would not be able to associate the message with the PL that originated the packet, and hence this ICMP message cannot be validated.

Acknowledged PL:

A PL that includes a mechanism that can confirm successful delivery of datagrams to the remote PL endpoint (e.g., SCTP). Typically, the PL receiver returns acknowledgments corresponding to the received datagrams, which can be utilized to detect black-holing of packets (c.f., Unacknowledged PL).

Actual PMTU:

The actual PMTU is the PMTU of a network path between a sender PL and a destination PL, which the DPLPMTUD algorithm seeks to determine.

Black Hole:

A black hole is encountered when a sender is unaware that packets are not being delivered to the destination endpoint. Two types of black hole are relevant to DPLPMTUD:

• Packets encounter a packet black hole when packets are not delivered to the destination endpoint (e.g., when the sender transmits packets of a particular size with a previously known effective PMTU, and they are discarded by the network).
• An ICMP black hole is encountered when the sender is unaware that packets are not delivered to the destination endpoint because PTB messages are not received by the originating PL sender.

Classical Path MTU Discovery:

Classical PMTUD is a process described in [RFC 1191] and [RFC 8201] in which nodes rely on PTB messages to learn the largest size of unfragmented packet that can be used across a network path.

Datagram:

A datagram is a transport-layer protocol data unit, transmitted in the payload of an IP packet.

DPLPMTUD:

Datagram Packetization Layer Path MTU Discovery (DPLPMTUD),PLPMTUD performed using a datagram transport protocol.

Effective PMTU:

The effective PMTU is the current estimated value for PMTU that is used by a PMTUD. This is equivalent to the PLPMTU derived by PLPMTUD plus the size of any headers added below the PL, including the IP layer headers.

EMTU_S:

The effective MTU for sending (EMTU_S) is defined in [RFC 1122] as "the maximum IP datagram size that may be sent, for a particular combination of IP source and destination addresses...".

EMTU_R:

The effective MTU for receiving (EMTU_R) is designated in [RFC 1122] as "the largest datagram size that can be reassembled".

Link:

A link is a communication facility or medium over which nodes can communicate at the link layer, i.e., a layer below the IP layer. Examples are Ethernet LANs and Internet (or higher) layer tunnels.

Link MTU:

The link Maximum Transmission Unit (MTU) is the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted over a link. Note that this could more properly be called the IP MTU, to be consistent with how other standards organizations use the acronym. This includes the IP header but excludes link layer headers and other framing that is not part of IP or the IP payload. Other standards organizations generally define the link MTU to include the link layer headers. This specification continues the requirement in [RFC 4821] that states, "All links MUST enforce their MTU: links that might non-deterministically deliver packets that are larger than their rated MTU MUST consistently discard such packets."

MAX_PLPMTU:

The MAX_PLPMTU is the largest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2).

MIN_PLPMTU:

The MIN_PLPMTU is the smallest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2).

MPS:

The Maximum Packet Size (MPS) is the largest size of application data block that can be sent across a network path by a PL using a single datagram (see Section 4.4).

MSL:

The Maximum Segment Lifetime (MSL) is the maximum delay a packet is expected to experience across a path, taken as 2 minutes [BCP145].

Packet:

A packet is the IP header(s) and any extension headers/options plus the IP payload.

Packetization Layer (PL):

The PL is a layer of the network stack that places data into packets and performs transport protocol functions. Examples of a PL include TCP, SCTP, SCTP over UDP, SCTP over DTLS, or QUIC.

Path:

The path is the set of links and routers traversed by a packet between a source node and a destination node by a particular flow.

Path MTU (PMTU):

The Path MTU (PMTU) is the minimum of the link MTU of all the links forming a network path between a source node and a destination node, as used by PMTUD.

PTB:

In this document, the term PTB message is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry the error Fragmentation Needed (Type 3, Code 4) [RFC 0792] and ICMPv6 Packet Too Big messages (Type 2) [RFC 4443].

PTB_SIZE:

The PTB_SIZE is a value reported in a validated PTB message that indicates next-hop link MTU of a router along the path.

PL_PTB_SIZE:

The size reported in a validated PTB message, reduced by the size of all headers added by layers below the PL.

PLPMTU:

The Packetization Layer PMTU is an estimate of the largest size of PL datagram that can be sent by a path, controlled by PLPMTUD.

PLPMTUD:

Packetization Layer Path MTU Discovery (PLPMTUD), the method described in this document for datagram PLs, which is an extension to Classical PMTU Discovery.

Probe packet:

A probe packet is a datagram sent with a purposely chosen size (typically the current PLPMTU or larger) to detect if packets of this size can be successfully sent end-to-end across the network path.

Unacknowledged PL:

A PL that does not itself provide a mechanism to confirm delivery of datagrams to the remote PL endpoint (e.g., UDP), and therefore requires DPLPMTUD to provide a mechanism to detect black-holing of packets (c.f., Acknowledged PL).

1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by DPLPMTUD. 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.
2. Probe packets: The network interface below the PL is REQUIRED to provide a way to transmit a probe packet that is larger than the PLPMTU. 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 (as specified in Section 5.4 of RFC 8201).
3. Reception feedback: The destination PL endpoint is REQUIRED to provide a feedback method that indicates to the DPLPMTUD sender when a probe packet has been received by the destination PL endpoint. Section 6 provides examples of how a PL can provide this acknowledgment of received probe packets.
4. Probe loss recovery: It is RECOMMENDED to use probe packets that do not carry any user data that would require retransmission if lost. Most datagram transports permit this. If a probe packet contains user data requiring retransmission in case of loss, the PL (or layers above) is REQUIRED to arrange any retransmission and/or repair of any resulting loss. The PL is REQUIRED to be robust in the case where probe packets are lost due to other reasons (including link transmission error, congestion).
5. PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize information about the maximum size of packet that can be transmitted by the sender on the local link (e.g., the local link MTU). A PL sender MAY utilize similar information about the maximum size of network-layer packet that a receiver can accept when this is supplied (note this could be less than EMTU_R). This avoids implementations trying to send probe packets that cannot be transferred by the local link. Too high of a value could reduce the efficiency of the search algorithm. Some applications also have a maximum transport protocol data unit (PDU) size, in which case there is no benefit from probing for a size larger than this (unless a transport allows multiplexing multiple applications' PDUs into the same datagram).
6. Processing PTB messages: A DPLPMTUD sender MAY optionally utilize PTB messages received from the network layer to help identify when a network path does not support the current size of probe packet. Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information [RFC 8201]. This validation confirms that the PTB message was sent in response to a packet originated by the sender and needs to be performed before the PLPMTU discovery method reacts to the PTB message. A PTB message MUST NOT be used to increase the PLPMTU [RFC 8201] but could trigger a probe to test for a larger PLPMTU. A valid PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in the DPLPMTUD state machine. A PL_PTB_SIZE that is greater than that currently probed SHOULD be ignored. (This PTB message ought to be discarded without further processing but could be utilized as an input that enables a resilience mode).
7. Probing and congestion control: A PL MAY use a congestion controller to decide when to send a probe packet. If transmission of probe packets is limited by the congestion controller, this could result in transmission of probe packets being delayed or suspended during congestion. When the transmission of probe packets is not controlled by the congestion controller, the interval between probe packets MUST be at least one RTT. Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction [RFC 4821] because this could result in unnecessary reduction of the sending rate. An update to the PLPMTU (or MPS) MUST NOT increase the congestion window measured in bytes [RFC 4821]. Therefore, an increase in the packet size does not cause an increase in the data rate in bytes per second. A PL that maintains the congestion window in terms of a limit to the number of outstanding fixed-size packets SHOULD adapt this limit to compensate for the size of the actual packets. The transmission of probe packets can interact with the operation of a PL that performs burst mitigation or pacing, and the PL could need transmission of probe packets to be regulated by these methods.
8. Probing and flow control: Flow control at the PL concerns the end-to-end flow of data using the PL service. Flow control SHOULD NOT apply to DPLPMTU when probe packets use a design that does not carry user data to the remote application.
9. Shared PLPMTU state: The PMTU value calculated from the PLPMTU MAY also be stored with the corresponding entry associated with the destination in the IP layer cache and used by other PL instances. The specification of PLPMTUD [RFC 4821] states, "If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU". Such methods MUST be robust to the wide variety of underlying network forwarding behaviors. Section 5.2 of RFC 8201 provides guidance on the caching of PMTU information and also the relation to IPv6 flow labels.

• A PL MAY be designed to segment data blocks larger than the MPS into multiple datagrams. However, not all datagram PLs support segmentation of data blocks. It is RECOMMENDED that methods avoid forcing an application to use an arbitrary small MPS for transmission while the method is searching for the currently supported PLPMTU. A reduced MPS can adversely impact the performance of an application.
• To assist applications in choosing a suitable data block size, the PL is RECOMMENDED to provide a primitive that returns the MPS derived from the PLPMTU to the higher layer using the PL. The value of the MPS can change following a change in the path or loss of probe packets.
• Path validation: It is RECOMMENDED that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received.
• Datagram reordering: A method is REQUIRED to be robust to the possibility that a flow encounters reordering or that the traffic (including probe packets) is divided over more than one network path.
• Datagram delay and duplication: The feedback mechanism is REQUIRED to be robust to the possibility that packets could be significantly delayed or duplicated along a network path.
• When to probe: It is RECOMMENDED that methods determine whether the path has changed since it last measured the path. This can help determine when to probe the path again.

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 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]).

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

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.

PROBE_TIMER:

The PROBE_TIMER is configured to expire after a period longer than the maximum time to receive an acknowledgment to a probe packet. This value MUST NOT be smaller than 1 second and SHOULD be larger than 15 seconds. Guidance on the selection of the timer value is provided in Section [BCP145] of the UDP Usage Guidelines [BCP145].

PMTU_RAISE_TIMER:

The PMTU_RAISE_TIMER is configured to the period a sender will continue to use the current PLPMTU, after which it reenters the Search Phase. This timer has a period of 600 seconds, as recommended by PLPMTUD [RFC 4821].

DPLPMTUD MAY inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL preferring to use an up-to-date PMTU once user data is sent again can choose to continue PMTU discovery for each path. However, this will result in sending additional packets.

CONFIRMATION_TIMER:

When an acknowledged PL is used, this timer MUST NOT be used. For other PLs, the CONFIRMATION_TIMER is configured to the period a PL sender waits before confirming the current PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER and used to decrease the PLPMTU (e.g., when a black hole is encountered). Confirmation needs to be frequent enough when data is flowing that the sending PL does not black hole extensive amounts of traffic. Guidance on selection of the timer value are provided in Section [BCP145] of the UDP Usage Guidelines [BCP145].

DPLPMTUD MAY inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL preferring to use an up-to-date PMTU once user data is sent again, can choose to continue PMTU discovery for each path. However, this could result in sending additional packets.

MAX_PROBES:

The MAX_PROBES is the maximum value of the PROBE_COUNT counter (see Section 5.1.3). MAX_PROBES represents the limit for the number of consecutive probe attempts of any size. Search algorithms benefit from a MAX_PROBES value greater than 1 because this can provide robustness to isolated packet loss. The default value of MAX_PROBES is 3.

MIN_PLPMTU:

The MIN_PLPMTU is the smallest size of PLPMTU that DPLPMTUD will attempt to use. An endpoint could need to configure the MIN_PLPMTU to provide space for extension headers and other encapsulations at layers below the PL. This value can be interface and path dependent. For IPv6, this size is greater than or equal to the size at the PL that results in an 1280-byte IPv6 packet, as specified in [RFC 8200]. For IPv4, this size is greater than or equal to the size at the PL that results in an 68-byte IPv4 packet. Note: An IPv4 router is required to be able to forward a datagram of 68 bytes without further fragmentation. This is the combined size of an IPv4 header and the minimum fragment size of 8 bytes. In addition, receivers are required to be able to reassemble fragmented datagrams at least up to 576 bytes, as stated in Section 3.3.3 of RFC 1122.

MAX_PLPMTU:

The MAX_PLPMTU is the largest size of PLPMTU. This has to be less than or equal to the maximum size of the PL packet that can be sent on the outgoing interface (constrained by the local interface MTU). When known, this also ought to be less than the maximum size of PL packet that can be received by the remote endpoint (constrained by EMTU_R). It can be limited by the design or configuration of the PL being used. An application, or PL, MAY choose a smaller MAX_PLPMTU when there is no need to send packets larger than a specific size.

BASE_PLPMTU:

The BASE_PLPMTU is a configured size expected to work for most paths. The size is equal to or larger than the MIN_PLPMTU and smaller than the MAX_PLPMTU. For most PLs, a suitable BASE_PLPMTU will be larger than 1200 bytes. When using IPv4, there is no currently equivalent size specified, and a default BASE_PLPMTU of 1200 bytes is RECOMMENDED.

PROBED_SIZE:

The PROBED_SIZE is the size of the current probe packet as determined at the PL. This is a tentative value for the PLPMTU, which is awaiting confirmation by an acknowledgment.

PROBE_COUNT:

The PROBE_COUNT is a count of the number of successive unsuccessful probe packets that have been sent. Each time a probe packet is acknowledged, the value is set to zero. (Some probe loss is expected while searching, therefore loss of a single probe is not an indication of a PMTU problem.)

     MIN_PLPMTU                                MAX_PLPMTU
       <------------------------------------------->
                      |        |     |     
                      v        |     |     
                BASE_PLPMTU    |     v     
                               |  PROBED_SIZE  
                               v  
                             PLPMTU

                    +------+
           +------->| Base |-----------------+ Connectivity
           |        +------+                 | or BASE_PLPMTU
           |           |                     | confirmation failed
           |           |                     v
           |           | Connectivity    +-------+
           |           | and BASE_PLPMTU | Error |
           |           | confirmed       +-------+
           |           |                     | Consistent
           |           v                     | connectivity
Black Hole |       +--------+                | and BASE_PLPMTU
 detected  |       | Search |<---------------+ confirmed
           |       +--------+
           |          ^  |
           |          |  |
           |    Raise |  | Search
           |    timer |  | algorithm
           |  expired |  | completed
           |          |  |
           |          |  v
           |   +-----------------+
           +---| Search Complete |
               +-----------------+

Base:

The Base Phase confirms connectivity to the remote peer using packets of the BASE_PLPMTU. The confirmation of connectivity is implicit for a connection-oriented PL (where it can be performed in a PL connection handshake). A connectionless PL sends a probe packet and uses acknowledgment of this probe packet to confirm that the remote peer is reachable.

The sender also confirms that BASE_PLPMTU is supported across the network path. This may be achieved by using a PL mechanism (e.g., using a handshake packet of size BASE_PLPMTU) or by sending a probe packet of size BASE_PLPMTU and confirming that this is received.

A probe packet of size BASE_PLPMTU can be sent immediately on the initial entry to the Base Phase (following a connectivity check). A PL that does not wish to support a path with a PLPMTU less than BASE_PLPMTU can simplify the phase into a single step by performing the connectivity checks with a probe of the BASE_PLPMTU size.

Once confirmed, DPLPMTUD enters the Search Phase. If the Base Phase fails to confirm the BASE_PLPMTU, DPLPMTUD enters the Error Phase.

Search:

The Search Phase utilizes a search algorithm to send probe packets to seek to increase the PLPMTU. The algorithm concludes when it has found a suitable PLPMTU by entering the Search Complete Phase.

A PL could respond to PTB messages using the PTB to advance or terminate the search, see Section 4.6.

Search Complete:

The Search Complete Phase is entered when the PLPMTU is supported across the network path. A PL can use a CONFIRMATION_TIMER to periodically repeat a probe packet for the current PLPMTU size. If the sender is unable to confirm reachability (e.g., if the CONFIRMATION_TIMER expires) or the PL signals a lack of reachability, a black hole has been detected and DPLPMTUD enters the Base Phase.

The PMTU_RAISE_TIMER is used to periodically resume the Search Phase to discover if the PLPMTU can be raised. Black hole detection causes the sender to enter the Base Phase.

Error:

The Error Phase is entered when there is conflicting or invalid PLPMTU information for the path (e.g., a failure to support the BASE_PLPMTU) that causes DPLPMTUD to be unable to progress, and the PLPMTU is lowered.

DPLPMTUD remains in the Error Phase until a consistent view of the path can be discovered and it has also been confirmed that the path supports the BASE_PLPMTU (or DPLPMTUD is suspended).

   |         |
   | Start   | PL indicates loss
   |         |  of connectivity
   v         v
+---------------+                                   +---------------+
|    DISABLED   |                                   |     ERROR     |
+---------------+               PROBE_TIMER expiry: +---------------+
        | PL indicates     PROBE_COUNT = MAX_PROBES or    ^      |
        | connectivity  PTB: PL_PTB_SIZE < BASE_PLPMTU    |      |
        +--------------------+         +------------------+      |
                             |         |                         |
                             v         |       BASE_PLPMTU Probe |
                          +---------------+          acked       |
                          |      BASE     |--------------------->+
                          +---------------+                      |
                             ^ |    ^  ^                         |
         Black hole detected | |    |  | Black hole detected     |
        +--------------------+ |    |  +--------------------+    |
        |                      +----+                       |    |
        |                PROBE_TIMER expiry:                |    |
        |             PROBE_COUNT < MAX_PROBES              |    |
        |                                                   |    |
        |               PMTU_RAISE_TIMER expiry             |    |
        |    +-----------------------------------------+    |    |
        |    |                                         |    |    |
        |    |                                         v    |    v
+---------------+                                   +---------------+
|SEARCH_COMPLETE|                                   |   SEARCHING   |
+---------------+                                   +---------------+
   |    ^    ^                                         |    |    ^
   |    |    |                                         |    |    |
   |    |    +-----------------------------------------+    |    |
   |    |            MAX_PLPMTU Probe acked or              |    |
   |    |  PROBE_TIMER expiry: PROBE_COUNT = MAX_PROBES or  |    |
   +----+            PTB: PL_PTB_SIZE = PLPMTU              +----+
CONFIRMATION_TIMER expiry:                        PROBE_TIMER expiry:
PROBE_COUNT < MAX_PROBES or               PROBE_COUNT < MAX_PROBES or
     PLPMTU Probe acked                           Probe acked or PTB:
                                   PLPMTU < PL_PTB_SIZE < PROBED_SIZE

DISABLED:

The DISABLED state is the initial state before probing has started. It is also entered from any other state, when the PL indicates loss of connectivity. This state is left once the PL indicates connectivity to the remote PL. When transitioning to the BASE state, a probe packet of size BASE_PLPMTU can be sent immediately.

BASE:

The BASE state is used to confirm that the BASE_PLPMTU size is supported by the network path and is designed to allow an application to continue working when there are transient reductions in the actual PMTU. It also seeks to avoid long periods when a sender searching for a larger PLPMTU is unaware that packets are not being delivered due to a packet or ICMP black hole.

On entry, the PROBED_SIZE is set to the BASE_PLPMTU size, and the PROBE_COUNT is set to zero.

Each time a probe packet is sent, the PROBE_TIMER is started. The state is exited when the probe packet is acknowledged, and the PL sender enters the SEARCHING state.

The state is also left when the PROBE_COUNT reaches MAX_PROBES or a received PTB message is validated. This causes the PL sender to enter the ERROR state.

SEARCHING:

The SEARCHING state is the main probing state. This state is entered when probing for the BASE_PLPMTU completes.

Each time a probe packet is acknowledged, the PROBE_COUNT is set to zero, the PLPMTU is set to the PROBED_SIZE, and then the PROBED_SIZE is increased using the search algorithm (as described in Section 5.3).

When a probe packet is sent and not acknowledged within the period of the PROBE_TIMER, the PROBE_COUNT is incremented, and a new probe packet is transmitted.

The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT reaches MAX_PROBES, a validated PTB is received that corresponds to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or a probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU).

When a black hole is detected in the SEARCHING state, this causes the PL sender to enter the BASE state.

SEARCH_COMPLETE:

The SEARCH_COMPLETE state indicates that a search has completed. This is the normal maintenance state, where the PL is not probing to update the PLPMTU. DPLPMTUD remains in this state until either the PMTU_RAISE_TIMER expires or a black hole is detected.

When DPLPMTUD uses an unacknowledged PL and is in the SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets the PROBE_COUNT and schedules a probe packet with the size of the PLPMTU. If MAX_PROBES successive PLPMTUD-sized probes fail to be acknowledged, the method enters the BASE state. When used with an acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to generate PLPMTU probes in this state.

ERROR:

The ERROR state represents the case where either the network path is not known to support a PLPMTU of at least the BASE_PLPMTU size or when there is contradictory information about the network path that would otherwise result in excessive variation in the MPS signaled to the higher layer. The state implements a method to mitigate oscillation in the state-event engine. It signals a conservative value of the MPS to the higher layer by the PL. The state is exited when packet probes no longer detect the error. The PL sender then enters the SEARCHING state.

Implementations are permitted to enable endpoint fragmentation if the DPLPMTUD is unable to validate MIN_PLPMTU within PROBE_COUNT probes. If DPLPMTUD is unable to validate MIN_PLPMTU, the implementation will transition to the DISABLED state.

Note: MIN_PLPMTU could be identical to BASE_PLPMTU, simplifying the actions in this state.

[BCP145]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, March 2017,
<https://www.rfc-editor.org/info/bcp145>.

[RFC0768]

J. Postel, "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.

[RFC0791]

J. Postel, "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.

[RFC1191]

J.C. Mogul, and S.E. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3828]

L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004,
<https://www.rfc-editor.org/info/rfc3828>.

[RFC4820]

M. Tuexen, R. Stewart, and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
<https://www.rfc-editor.org/info/rfc4820>.

[RFC4960]

R. Stewart, "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.

[RFC6951]

M. Tuexen, and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013,
<https://www.rfc-editor.org/info/rfc6951>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8201]

J. McCann, S. Deering, J. Mogul, and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.

[RFC8261]

M. Tuexen, R. Stewart, R. Jesup, and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017,
<https://www.rfc-editor.org/info/rfc8261>.

[QUIC]

J Iyengar, and M Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Internet-Draft draft-ietf-quic-transport-29, June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-29>.

[RFC0792]

J. Postel, "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.

[RFC1122]

R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.

[RFC1812]

F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.

[RFC2923]

K. Lahey, "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.

[RFC4340]

E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.

[RFC4443]

A. Conta, S. Deering, and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.

[RFC4821]

M. Mathis, and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.

[RFC4890]

E. Davies, and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007,
<https://www.rfc-editor.org/info/rfc4890>.

[RFC5508]

P. Srisuresh, B. Ford, S. Sivakumar, and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, April 2009,
<https://www.rfc-editor.org/info/rfc5508>.

[RFC8900]

R Bonica, F Baker, G Huston, R Hinden, O Troan, and F Gont, "IP Fragmentation Considered Fragile", RFC 8900, BCP 230, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.

[TUNNELS]

Cisco, , and , "IP Tunnels in the Internet Architecture", Internet-Draft draft-ietf-intarea-tunnels-10, September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.

Godred Fairhurst

Tom Jones

Michael Tüxen

Irene Rüngeler

Timo Völker