]> University of Aberdeen

School of Engineering Fraser Noble Building Aberdeen AB24 3UE UK gorry@erg.abdn.ac.uk

University of Aberdeen

School of Engineering Fraser Noble Building Aberdeen AB24 3UE UK tom@erg.abdn.ac.uk

Transport Internet Engineering Task Force UDP UDP-Options PMTUD PLPMTUD DPLPMTUD 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 specific network path. It also provides a way to allow the the application to periodically verify the current maximum packet size supported by a path and to update this when required.

The User Datagram Protocol offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section 3.5 of UDP Guidelines 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 offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but 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) implement mechanisms for Path MTU discovery above the UDP API. Packetization Layer Path MTU Discovery (PLPMTUD) describes a method for a Packetization Layer (PL) (such as UDP Options) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. Datagram PLPMTUD (DPLPMTUD) 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 supplies functionality that can be used to implement DPLPMTUD within the UDP transport service. This document specifies how DPLPMTUD is implemented (see Section 6.1 of ). Implementing DPLPMTUD using UDP Options avoids the need for each upper layer protocol (or application) 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.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined for DPLPMTUD (see Sections 2 and 5 of

The packet formats and procedures for DPLPMTUD using UDP Options are described in this section. There are two ways an upper layer protocol (i.e. an application or protocol layered above UDP) can perform DPLPMTUD: A UDP Options sender implementing DPLPMTUD uses the method specified in and the upper layer protocol does not perform PMTU discovery. In this case, UDP Options processing is responsible for sending probe packets to determine a PLPMTU, as described in this document. The discovered PLPMTU can be used by UDP Options to either: set the maximum datagram size for the current path. set the maximum fragment size when a sender uses the UDP Fragmentation Option to divide a datagram into multiple UDP fragments for transmission. Each UDP fragment is then less than the discovered largest IP packet that can be received across the current path. An upper layer protocol using UDP can implement DPLPMTUD. It then uses probe packetsn using REQ and RES Options to determine a safe PLPMTU for the datagrams that it sends. The format and content of these probe packets is determined by the upper layer protocol. Note: 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 idnetified by a unique token. When configurable, a design ought to avoid such performing discovery at thde UDP options and upper protocol layers. Section 6.1 of recommends that "An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability".

DPLPMTUD relies upon a UDP Options sender sending a probe packet with a specific size, up to the maximum for the size supported by a local interface. This MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD or the PMTU size held in the IP-layer cache), as noted in bullet 2 of Section 3 in ). Probe packets consume network capacity and incur endpoint processing (see Section 4.1 of ). 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.

A UDP Options sender sender the REQ Option and receives the RES Option. If this 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). (Section 3, item 2) requires the network interface below the PL to provide a way to transmit a probe packet that is larger than the PLPMTU without network layer endpoint fragmentation. This document adds to this: UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP layer. The remainder of the section describes a format of a probe packet consisting of an empty UDP datagram, the UDP Options area and any needed Padding. Each probe packet includes the UDP Options area containing a RES Option and any other required options concluded with an EOL Option followed by any padding needed to inflate to the required probe size. The UDP Options used in this document are described in Section 5.11 of : The REQ Option is set by a sending PL to solicit a response from a remote receiver. A four-byte token identifies each request. The RES Option is sent by a UDP Options receiver in response to a previously received REQ Option. Each RES Option echoes a received four-byte token. Reception of a RES Option by the sender confirms that a specific probe packet has been received by the remote UDP Options receiver. The token allows a 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). The UDP Options sender MUST NOT resuse 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 DPLPMTUD 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 ). Like other UDP options, each of the two option kinds MUST NOT appear more than once in each UDP datagram.

DPLPMTUD utilises three types of probe. These are described in the following sections: A probe to confirm the path can support the BASE_PLPMTU (see Section 5.1.4 of ). A probe to detect whether the path can support a larger PLPMTU. A probe to validate the path supports the current PLPMTU.

The DPLPMTUD method requires a PL to confirm connectivity over the path (see Section 5.1.4 of ), 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 RES UDP option to elicit a response from the remote endpoint. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size has traversed the path to the receiver. It also confirms that the remote receiver supports the RES Option.

From time to time, DPLPMTUD enters the SEARCHING state (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 Segment Size (MSS) 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 (see "Probing using padding data" in Section 4.1 of ), 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).

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 (see Section 6.1.4 of ). This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state to detect black-holing of data (see Section 4.2 of , which also defines a 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" or "Probing using application data and padding data" (see Section 4.1 of ) or can construct a probe packet that does not carry any application data, as described in a previous section.

A simple implementation of the method might be designed to only use probe packets in a UDP datagram that include no application data. Each probe packet is padded to the required probe size including the REQ Option. This implements "Probing using padding data" (Section 4.1 of ), and avoids having to retransmit application data when a probe fails. 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.

An implementation always uses the format in the previous section when DPLPMTUD searches to increase the PLPMTU. An alternative format is permitted for a probe packet that confirms connectivity or that validates the path. These probe packets are permitted to carry application data. (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 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 RES Option) and reception of the corresponding RES Options to the upper layer protocol. A receiver that responds to DPLPMTUD needs to processes 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 PL PMTU 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.

A receiver that implements UDP Options ought to respond with a UDP datagram with a RES Option when requested by a sender. The following exampoles describe different receiver behaviors: When a sender supports this specificatoon, but the remote receiver that does not return a RES Option, the method is unable to discover the PLPMTU and will result in using minimum configured PLPMTU (MIN_PLPMTU). Such a remote receiver might not process UDP options, or might not return a Datagram with a RES Option for some other reason (due to persisent packet loss, insufficent space to include the option, etc.) When the sender and receiver support DPLPMTUD using the specication, and the receiver design only return a RES Option with next has a UDP datagram to send to the requester. In this design, the reception of a REQ Option does not trigger a response. The design allows DPLPMTUD to operate when there is a flow of datagrams in both directions, even when one direction only provides periodic feedback (e.g., one acknowledgment packet per RTT). Use requires the PLPMTU at the receiver to be sufficiently large that it allows adding the RES option to the feedback packets that are sent. the path. This simple method helps avoid opportunities to use the method as a DoS attack. When the sender and receiver support DPLPMTUD using the specication, a receiver could be designed to only return a RES Option when it next has a UDP datagram to send to the requester, but there is a low rate of transmission (or no datagrams are sent) in the return direction. The lack of transmission opprunities prevents prompt delivery of the RES Option, and can result in probe packets failing to be acknowledged in time. This will result in a smaller PLPMTU than actually suppported by the path, or using the minimum configured PLPMTU (MIN_PLPMTU). The design of a receiver could permit it to generate a datagram (e.g. with zero payload data) solely to return a RES Option (e.g., when no other Datagrams are queued for transmission). This design allows a UDP Options endpoint to probe the set of open UDP ports using DPLPMTUD probe packets. It results in a some additional traffic overhead, but has the advantage thatb it can ensure timely progress of DPLPMTUD. If a UDP Options endpoint creates and sends a Datagram with a RES option solely as respond to received RES Option, the respionder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per RTT or 1 per second). This rate limit mitigates the DoS vector, without significantly impacting the operation of DPLPMTUD.

A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD 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 ). An upper layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout). Section 3 of 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.

Support for receiving ICMP PTB messages is OPTIONAL for use with DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages. A UDP Options sender that utilises ICMP PTB messages received in response to a probe packet 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 specifies this validation procedure. An implementation unable to support this validation needs to ignore received ICMP PTB messages.

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.

This memo includes no requests to IANA.

The security considerations for using UDP Options are described in . The proposed new method does not change the integrity protection offered by the UDP options method. The security considerations for using DPLPMTUD are described in . 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 designed 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) then a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe pakcets 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 proposed new method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilities 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.

&RFC768; &RFC2119; &RFC8174; &RFC8899; &I-D.ietf-tsvwg-udp-options; &RFC1191; &RFC4821; &RFC8085; &RFC8201; &RFC8304;

XXX Note to RFC-Editor: please remove this entire section prior to publication. XXX Individual draft-00. This version contains a description for consideration and comment by the TSVWG. Individual draft-01. Address Nits Change Probe Request and Probe Reponse options to Echo to align names with draft-ietf-tsvwg-udp-options Remove Appendix B, Informative Description of new UDP Options Add additional sections around Probe Packet generation Individual draft-02. Address Nits Individual draft-03. Referenced DPLPMTUD RFC. Tidied language to clarify the method. Individual draft-04 Reworded text on probing with data a little Removed paragraph on suspending ICMP PTB suspension. Working group draft-00 -00 First Working Group Version RFC8899 call search_done SEARCH_COMPLETE, fix Working group draft -01 Update to reflect new fragmentation design in UDP Options. Add a description of uses of DPLPMTUD with UDP Options. Add a description on how to form probe packets with padding. Say that MSS options can be used to initialise the search algorithm. Say that the recommended approach is to not use user data for probes. Attempts to clarify and improve wording throughout. Remove text saying you can respond to multiple probes in a single packet. Simplified text by removing options that don't yield benefit. Working group draft -02 Update to reflect comments from MED. More consistent description of DPLPMTUD with UDP Options. Clarify the nonce value (token) is intended per 5-tuple, not interface. BASE_PLPMTU related to RFC8899. Probes with user data can carry application control data. Added that application data uses RES and REQ nonce (token) values from the app. QUIC was intended as an informational reference to an example of RFC8899. Working group draft -03 Update to reflect more comments from MED. Again more consistent description of DPLPMTUD with UDP Options. Clarify token/nonce to use "token". Clarify any use of application data for black-hole detection. Minor changes to reflect update to UDP Options base spec. Working group draft-04. Update for WG Last Call Working group draft-05. Update following WG Last Call