Internet-Draft UDPO DPLPMTUD May 2024
Fairhurst & Jones Expires 8 November 2024 [Page]
Internet Engineering Task Force
Intended Status:
Standards Track
G. Fairhurst
University of Aberdeen
T. Jones
University of Aberdeen

Datagram PLPMTUD for UDP Options


This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 November 2024.

Table of Contents

1. Introduction

The User Datagram Protocol [RFC0768] offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that applications implement some form of Path MTU discovery to avoid the generation of IP fragments:

"Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD)".

The UDP API [RFC8304] offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but it does not offer any automated mechanisms for an application to discover the maximum packet size supported by a path. Upper Layer protocols, which includes applications, can implement mechanisms for Path MTU discovery above the UDP API.

Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes a method for a Packetization Layer (PL) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism that does not solely rely on ICMP PTB messages and works on paths that drop ICMP PTB messages.

UDP Options [I-D.ietf-tsvwg-udp-options] supplies functionality that can be used to implement DPLPMTUD within the transport service or in an Upper Layer protocol (including an application) that uses UDP Options. This document specifies how DPLPMTUD using UDP Options is implemented (Section 6.1 of [RFC8899]).

Implementing DPLPMTUD within the transport service above UDP Options avoids the need for each Upper Layer protocol to implement the DPLPMTUD method. It provides a standard method for applications to discover the current maximum packet size for a path and to detect when this changes.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses the terms defined for DPLPMTUD (Sections 2 and 5 of [RFC8899]).

3. DPLPMTUD for UDP Options

A UDP Options sender implementing DPLPMTUD uses the method specified in [RFC8899]. In this specification, this is realised using a pair of UDP Options: the Request (REQ) Option and the Response (RES) Option (Section 9.7 of [I-D.ietf-tsvwg-udp-options]). The method also uses the End of Options List (EOL) Option (Section 9.1 of [I-D.ietf-tsvwg-udp-options]) to introduce padding to set the size of a probe packet.

Use of DPLPMTUD MUST be explicitly enabled by the application, for instance once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol. Similarly, a DPLPMTUD receiver SHOULD NOT respond to a REQ Option until DPLPMTUD has been enabled.

Probe packets consume network capacity and incur endpoint processing (Section 4.1 of [RFC8899]). Implementations ought to send a probe packet with a REQ Option only when required by their local DPLPMTUD state machine, i.e., when confirming the base PMTU for the path, probing to increase the PLPMTU, or to confirm the current PLPMTU.

There are two designs for using DPLPMTUD over UDP Options:

When DPLPMTUD implemented within the UDP transport service, the DPLPMTUD state machine is responsible for sending probe packets to determine a PLPMTU, as described in this document. The Upper Layer protocol is responsible for deciding when a session enables DPLPMTUD.

The discovered PLPMTU can be used to either:

The figure below shows an implementation of DPLPMTUD within the UDP transport service. It illustrates key interactions between the layers. This design REQUIRES an API primitive to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port. By default, this API MUST disable DPLPMTUD processing.

|      Upper Layer Protocol      |
|         or Application         |
    ^                       | Messages (with UDP Options)
    | receive         send  | Primitives for MPS, Min_PMTU etc.
| DPLPMTUD State Machine         |
|   Maximum Packet Size (MPS)    |
|   PLPMTU, Probed-Size,Min_PMTU |
|   Token Values & Probes, etc   |
    ^                       | Messages (with UDP Options)
    |                       |   Send/Receive: Probes with Options
    | receive         send  |   Events: ICMP, Interface MTU, etc
| UDP Options Transport          |
    ^                       | Datagrams (with UDP Options)
    |                       | Fragmented Datagrams with UDP Options
    | receive         send  | Events: ICMP, Interface MTU, etc

Note: UDP allows an Upper Layer Protocol to send datagrams with or without payload data (with or without UDP Options). These are delivered across the network to the remote Upper Layer. When DPLPMTUD is implemented within the UDP transport service, DPLPMTUD can be permitted to generate probe packets with no UDP payload that include a REQ or RES UDP Option. In this case, these probe packets were not generated by the sending application and therefore the corresponding datagrams are not delivered to the remote application.

When DPLPMTUD is instead implemented by an Upper Layer protocol, the format and content of probe packets are determined by the Upper Layer protocol. This design is also permitted to use the REQ and RES Options provided by UDP Options.

If DPLPMTUD is active at more than one layer, then the values of the tokens used in REQ Options need to be coordinated with any values used for other DPLPMTUD probe packets to ensure that each probe packet can be identified by a unique token. When configurable, a design ought to avoid performing such discovery within UDP Options and also by upper protocol layers (that send and receive probe packets via UDP Options).

Section 6.1 of [RFC8899] recommends that "An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability".

3.1. Packet Formats

The UDP Options used in this document are described in [I-D.ietf-tsvwg-udp-options] and are used in the following way:

The token allows a UDP Options sender to distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger round-trip time). Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL) [RFC8085]. The UDP Options sender MUST NOT reuse a token value within the MSL. A four byte value for the token field provides sufficient space for multiple unique probe packets to be made within the MSL. Since UDP Options operates over UDP, the token values only need to be unique for the specific 5-tuple over which it is operating.

The value of the four-byte token field SHOULD be initialised to a randomised value to enhance protection from off-path attacks, as described in Section 5.1 of [RFC8085].

3.2. Sending Probe Packets with the Request Option

DPLPMTUD relies upon sending a probe packet with a specific size. Each probe packet includes the UDP Options area containing a REQ Option and any other required options concluded with an EOL Option (Section 9.1 of [I-D.ietf-tsvwg-udp-options]) followed by any padding needed to inflate to the required probe size.

A probe packet can therefore be of size up to the maximum size supported by the local interface. [RFC8899] (Section 3, item 2) requires the network interface below DPLPMTUD to provide a way to transmit a probe packet that is larger than the current PLPMTU. The size of this probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD [RFC1191][RFC8201] or the PMTU size held in the IP-layer cache), as noted in bullet 2 of Section 3 in [RFC8899]).

UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP layer.

3.3. Receiving UDP-Options Probe Packets and sending the RES Option

When DPLPMTUD is enabled, a UDP Options receiver responds by sending a UDP datagram with the RES Option when it receives a UDP Options datagram with the REQ Option.

The operation of DPLPMTUD can depend on the support at the remote UDP Options endpoint, the way in which DPLPMTUD is implemented and in some cases the application data that is exchanged over the UDP transport service. When UDP Options is not supported by the remote receiver, DPLPMTUD will be unable to confirm the path or to discover the PLPMTU. This will result in the minimum configured PLPMTU (MIN_PLPMTU). More explanation of usage is provided in Section 6.

Note: A receiver that only responds when there is a datagram queued for transmission by the Upper Layer could potentially receive multiple datagrams with a REQ Option before it can respond. When sent, the RES Option will only acknowledge the latest received token value. A sender would then conclude that any earlier REQ Options were not successfully received. However, DPLPMTUD does not normally send more than one probe packet per timeout interval, and a delay in responding will already have been treated as a failed probe attempt. Therefore, this does not significantly impact performance, although a more prompt response would have resulted in DPLPMTUD recording reception of all probe packets.

4. DPLPMTUD Sender Procedures for UDP Options

DPLPMTUD utilises three types of probe. These are described in the following sections:

4.1. Confirmation of Connectivity across a Path

The DPLPMTUD method requires a PL to confirm connectivity over the path (Section 5.1.4 of [RFC8899]), but UDP itself does not offer a mechanism for this.

UDP Options can provide this required functionality. A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity for the path, by sending a probe packet, padded to size BASE_PLPMTU. This confirmation probe MUST include the REQ UDP option to elicit a response from the remote DPLPMTUD. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size that has successfully traversed the path to the receiver. This also confirms that the remote endpoint supports the RES Option.

4.2. Sending Probe Packets to Increase the PLPMTU

From time to time, DPLPMTUD enters the SEARCHING state, described in Section 5.2 of [RFC8899], (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the current path can support a larger PLPMTU. When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) option, this value MAY be used as a hint to initialise this search to increase the PLPMTU.

Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data ("Probing using padding data" in Section 4.1 of [RFC8899]), since they will be lost whenever their size exceeds the actual PMTU. A probe packet needs to elicit a positive acknowledgment that the path has delivered a datagram of the specific probed size and, therefore, MUST include the REQ Option.

At the receiver, a received probe packet that does not carry application data does not form a part of the end-to-end transport data and is not delivered to the Upper Layer protocol (i.e., application or protocol layered above UDP).

4.3. Validating the Path with UDP Options

A PL using DPLPMTUD needs to validate that a path continues to support the PLPMTU discovered in a previous search for a suitable PLPMTU value (Section 6.1.4 of [RFC8899]). This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state to detect black-holing of data (Section 5.2 of [RFC8899], Section 4.3 of [RFC8899] defines a DPLPMTUD black-hole).

Path validation can be implemented within UDP Options by generating a probe packet of size PLPMTU, which MUST include a REQ Option to elicit a positive confirmation that the path has delivered this probe packet. A probe packet used to validate the path MAY use either "Probing using padding data" to construct a probe packet that does not carry any application data (Section 4.1 of [RFC8899]) or "Probing using application data and padding data", see Section 4.1 of [RFC8899]. When using "Probing using padding data", the UDP Options API does not indicate receipt of the zero-length probe packet, see Section 4.4.

4.4. Probe Packets that do not include Application Data

A simple implementation of the method might be designed to only use probe packets in a UDP datagram that includes no application data. The size of each probe packet is padded to the required probe size including the REQ Option. This implements "Probing using padding data" (Section 4.1 of [RFC8899]) and avoids having to retransmit application data when a probe fails. This could be achieved by setting a minimum datagram length, such that the options list ends in EOL and additional space is zero-filled as needed (Section 13 of [I-D.ietf-tsvwg-udp-options]). In this use, the probe packets do not form a part of the end-to-end transport data and a receiver does not deliver them to the Upper Layer protocol.

4.5. Probe Packets that include Application Data

An implementation always uses the format in Section 4.4 when DPLPMTUD searches to increase the PLPMTU.

An alternative format is permitted for a probe packet used to confirm connectivity or that validates the path. These probe packets are permitted to carry application data. (A UDP payload data is permitted because these probe packets perform black-hole detection and will, therefore, usually have a higher probability of successful transmission, similar to other packets sent by the Upper Layer protocol.) Section 4.1 of [RFC8899] provides a discussion of the merits and demerits of including application data. For example, this reduces the need to send additional datagrams.

This type of probe MAY utilise a control message format defined by the Upper Layer protocol, provided that the message does not need to be delivered reliably. The REQ Option MUST be included when a sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method tracks the transmission of probe packets (using the token) and reception of the corresponding RES Options to the Upper Layer protocol.

A receiver that responds to DPLPMTUD needs to process the REQ Option and include the corresponding RES Option in an Upper Layer protocol message that it returns to the requester. DPLPMTUD can be used to manage the PLPMTU in just one direction or can be used for both directions. Probe packets that use this format form a part of the end-to-end transport data.

5. Receiving Events from the Network

This specification does not rely upon reception of events from the network, but an implementation can utilise these events when provided.

5.1. Changes in the Path

A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends 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. For example, a notification that a path has changed could trigger path validation to provide black-hole protection (Section 4.3 of [RFC8899]).

An Upper Layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout) [RFC8899].

Section 3 of [RFC8899] requires any methods designed to share the PLPMTU between PLs (such as updating the IP cache PMTU for an interface/destination) to be robust to the wide variety of underlying network forwarding behaviors. For example, an implementation could avoid sharing PMTU information that could potentially relate to packets sent with the same address over a different interface.

5.2. PTB Message Handling

Support for receiving ICMP PTB messages is OPTIONAL for use with DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages.

When DPLPMTUD utilises ICMP PTB messages received in response to a probe packet it MUST use the ICMP 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. Section 4.6.1 of [RFC8899] specifies this validation procedure. An implementation unable to support this validation needs to ignore received ICMP PTB messages.

6. Examples with Different Receiver Behaviors

When enabled, a DPLPMTUD endpoint that implements UDP Options normally responds with a UDP datagram with a RES Option when requested by a sender.

The following examples describe various possible receiver behaviors:

7. Acknowledgements

Gorry Fairhurst and Tom Jones are supported by funding provided by the University of Aberdeen. The editors would like to thank Magnus Westerlund and Mohamed Boucadair for their detailed comments and also other people who contributed to completing this document.

8. IANA Considerations

This memo includes no requests to IANA.

9. Security Considerations

The security considerations for using UDP Options are described in [I-D.ietf-tsvwg-udp-options]. The method does not change the integrity protection offered by the UDP options method.

The security considerations for using DPLPMTUD are described in [RFC8899]. On path attackers could maliciously drop or modify probe packets to seek to decrease the PMTU, or to maliciously modify probe packets in an attempt to black-hole traffic.

The specification recommends that the token value in the REQ Option is initialised to a randomised value. This is to enhance protection from off-path attacks. If a subsequent probe packet uses a token value that is easily derived from the initial value, (e.g., incrementing the value) a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe packets are not transiting via the observer. This would allow probe packets to be forged, with an impact similar to other on-path attacks against probe packets. This attack could be mitigated by using an unpredictable token value for each probe packet.

The method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilises ICMP PTB messages received to a probe packet 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.

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. This allows the application to control when DPLPMTUD is used to control the additional traffic that this generates. This also ensures that DPLPMTUD probe packets are encrypted.

10. References

10.1. Normative References

Touch, J. D., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-32, , <>.
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, , <>.

10.2. Informative References

Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, , <>.
Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, , <>.
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <>.
McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, , <>.
Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)", RFC 8304, DOI 10.17487/RFC8304, , <>.

Appendix A. Revision Notes

XXX Note to RFC-Editor: please remove this entire section prior to publication. XXX

Individual draft-00.

Individual draft-01.

Individual draft-02.

Individual draft-03.

Individual draft-04

Working group draft-00

Working group draft -01

Working group draft -02

Working group draft -03

Working group draft-04.

Working group draft-05.

Working group draft-06.

Working group draft-07.

Working group draft-08.

Working group draft-09.

Working group draft-10.

Working group draft-11.

Working group draft-11.

Editorial corrections to align section numbers in referenced RFCs/I-Ds and minor editorial improvements.

Authors' Addresses

Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
AB24 3UE
United Kingdom
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
AB24 3UE
United Kingdom