rfc9869.original   rfc9869.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force (IETF) G. Fairhurst
Internet-Draft T. Jones Request for Comments: 9869 T. Jones
Intended status: Standards Track University of Aberdeen Category: Standards Track University of Aberdeen
Expires: 24 August 2025 20 February 2025 ISSN: 2070-1721 September 2025
Datagram PLPMTUD for UDP Options Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP
draft-ietf-tsvwg-udp-options-dplpmtud-15 Options
Abstract Abstract
This document specifies how a UDP Options sender implements Datagram This document specifies how a UDP Options sender implements Datagram
Packetization Layer Path Maximum Transmission Unit Discovery Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method
(DPLPMTUD) as a robust method for Path Maximum Transmission Unit for Path MTU Discovery (PMTUD). This method uses the UDP Options
discovery. This method uses the UDP Options packetization layer. It packetization layer. It allows an application to discover the
allows an application to discover the largest size of datagram that largest size of datagram that can be sent across a network path. It
can be sent across a network path. It also provides a way to allow also provides a way to allow the application to periodically verify
the application to periodically verify the current maximum packet the current Maximum Packet Size (MPS) supported by a path and to
size supported by a path and to update this when required. update this when required.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9869.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 4 3. DPLPMTUD for UDP Options
3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . 6 3.1. Packet Formats
3.2. Sending Probe Packets with the Request Option . . . . . . 7 3.2. Sending Probe Packets with the Request Option
3.3. Receiving UDP-Options Probe Packets and sending the RES 3.3. Receiving UDP Options Probe Packets and Sending the RES
Option . . . . . . . . . . . . . . . . . . . . . . . . . 7 Option
4. DPLPMTUD Sender Procedures for UDP Options . . . . . . . . . 8 4. DPLPMTUD Sender Procedures for UDP Options
4.1. Confirmation of Connectivity across a Path . . . . . . . 8 4.1. Confirmation of Connectivity Across a Path
4.2. Sending Probe Packets to Increase the PLPMTU . . . . . . 8 4.2. Sending Probe Packets to Increase the PLPMTU
4.3. Validating the Path with UDP Options . . . . . . . . . . 9 4.3. Validating the Path with UDP Options
4.4. Probe Packets that do not include Application Data . . . 9 4.4. Probe Packets That Do Not Include Application Data
4.5. Probe Packets that include Application Data . . . . . . . 10 4.5. Probe Packets That Include Application Data
5. Receiving Events from the Network . . . . . . . . . . . . . . 10 5. Receiving Events from the Network
5.1. Changes in the Path . . . . . . . . . . . . . . . . . . . 10 5.1. Changes in the Path
5.2. Validation of PTB Messages . . . . . . . . . . . . . . . 11 5.2. Validation of PTB Messages
6. Examples with Different Receiver Behaviors . . . . . . . . . 11 6. Examples with Different Receiver Behaviors
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The User Datagram Protocol [RFC0768] offers a minimal transport The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport
service on top of IP and is frequently used as a substrate for other service on top of IP and is frequently used as a substrate for other
protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that
applications implement some form of Path MTU discovery to avoid the applications implement some form of Path MTU Discovery (PMTUD) to
generation of IP fragments: avoid the generation of IP fragments:
"Consequently, an application SHOULD either use the path MTU | Consequently, an application SHOULD either use the path MTU
information provided by the IP layer or implement Path MTU Discovery | information provided by the IP layer or implement Path MTU
(PMTUD)". | Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to
| determine whether the path to a destination will support its
| desired message size without fragmentation.
The UDP API [RFC8304] offers calls for applications to receive ICMP The UDP API [RFC8304] offers calls for applications to receive ICMP
Packet Too Big (PTB) messages and to control the maximum size of Packet Too Big (PTB) messages and to control the maximum size of
datagrams that are sent, but it does not offer any automated datagrams that are sent, but it does not offer any automated
mechanisms for an application to discover the maximum packet size mechanisms for an application to discover the MPS supported by a
supported by a path. Upper Layer protocols, which includes path. Upper Layer protocols, which include applications, can
applications, can implement mechanisms for Path MTU discovery above implement mechanisms for PMTUD above the UDP API.
the UDP API.
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes
a method for a bi-directional Packetization Layer (PL) to search for a method for a bidirectional Packetization Layer (PL) to search for
the largest Packetization Layer PMTU (PLPMTU) supported on a path. the largest Packetization Layer PMTU (PLPMTU) supported on a path.
Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for DPLPMTUD [RFC8899] specifies this support for datagram transports.
datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism
probing mechanism that does not solely rely on ICMP PTB messages and that does not solely rely on ICMP PTB messages and works on paths
works on paths that drop ICMP PTB messages. that drop ICMP PTB messages.
UDP Options [I-D.ietf-tsvwg-udp-options] supplies functionality that UDP Options [RFC9868] supplies functionality that can be used to
can be used to implement DPLPMTUD within the transport service or in implement DPLPMTUD within the transport service or in an Upper Layer
an Upper Layer protocol (including an application) that uses UDP protocol (including an application) that uses UDP Options. This
Options. This document specifies how DPLPMTUD using UDP Options is document specifies how DPLPMTUD using UDP Options is implemented
implemented (Section 6.1 of [RFC8899]), and requires support to be (Section 6.1 of [RFC8899]) and requires support to be enabled at both
enabled at both the sender and receiver. the sender and receiver.
Implementing DPLPMTUD within the transport service above UDP Options Implementing DPLPMTUD within the transport service above UDP Options
avoids the need for each Upper Layer protocol to implement the avoids the need for each Upper Layer protocol to implement the
DPLPMTUD method. It provides a standard method for applications to DPLPMTUD method. It provides a standard method for applications to
discover the current maximum packet size for a path and to detect discover the current MPS for a path and to detect when this changes.
when this changes. It can be used with Equal-Cost Multipath (ECMP) It can be used with Equal-Cost Multipath (ECMP) routing and/or
routing and/or multihoming. If multipath or multihoming is multihoming. If multipath or multihoming is supported, a state
supported, a state machine is needed for each path. machine is needed for each path.
DPLPMTUD is not specified for multicast. The method requires DPLPMTUD is not specified for multicast. The method requires
explicit acknowledgment of probe packets provided by UDP Options, explicit acknowledgement of probe packets provided by UDP Options,
which is primarily intended for unicast use (see Section 23 of which is primarily intended for unicast use (see Section 23 of
[I-D.ietf-tsvwg-udp-options]). [RFC9868]).
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terms defined for DPLPMTUD (Sections 2 and 5 This document uses the terms defined for DPLPMTUD (Sections 2 and 5
of [RFC8899]). of [RFC8899]).
3. DPLPMTUD for UDP Options 3. DPLPMTUD for UDP Options
A UDP Options sender implementing DPLPMTUD uses the method specified A UDP Options sender implementing DPLPMTUD uses the method specified
in [RFC8899]. In this specification, DPLPMTUD is realised using a in [RFC8899]. In this specification, DPLPMTUD is realized using a
pair of UDP Options: the Request (REQ) Option and the Response (RES) pair of UDP Options: the Request (REQ) Option and the Response (RES)
Option (Section 11.7 of [I-D.ietf-tsvwg-udp-options]). The method Option (Section 11.7 of [RFC9868]). The method also uses the End of
also uses the End of Options List (EOL) Option (Section 11.1 of Options List (EOL) Option (Section 11.1 of [RFC9868]) to introduce
[I-D.ietf-tsvwg-udp-options]) to introduce padding to set the size of padding to set the size of a probe packet.
a probe packet.
Use of DPLPMTUD MUST be explicitly enabled by the application, for Use of DPLPMTUD MUST be explicitly enabled by the application, for
instance once an application has established connectivity and is instance, once an application has established connectivity and is
ready to exchange data with the remote Upper Layer protocol. ready to exchange data with the remote Upper Layer protocol.
Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option
until DPLPMTUD has been enabled. This is to help protect from mis- until DPLPMTUD has been enabled. This is to help protect from misuse
use of the mechanism for other forms of probing. of the mechanism for other forms of probing.
Probe packets consume network capacity and incur endpoint processing Probe packets consume network capacity and incur endpoint processing
(Section 4.1 of [RFC8899]). Implementations ought to send a probe (Section 4.1 of [RFC8899]). Implementations ought to send a probe
packet with a UDP REQ Option only when required by their local packet with a UDP REQ Option only when required by their local
DPLPMTUD state machine, i.e., when confirming the base PMTU for the DPLPMTUD state machine, i.e., when confirming the base PMTU for the
path, probing to increase the PLPMTU, or to confirm the current path, probing to increase the PLPMTU, or confirming the current
PLPMTU. PLPMTU.
DPLPMTUD can be implemented over UDP Options in two ways: DPLPMTUD can be implemented over UDP Options in two ways:
* Implementation within the UDP transport service; * Implementation within the UDP transport service.
* Implementation in an Upper Layer protocol (or application) that * Implementation in an Upper Layer protocol (or application) that
uses UDP Options. uses UDP Options.
When DPLPMTUD is implemented within the UDP transport service, the When DPLPMTUD is implemented within the UDP transport service, the
DPLPMTUD state machine is responsible for sending probe packets to DPLPMTUD state machine is responsible for sending probe packets to
determine a PLPMTU, as described in this document (and hence the determine a PLPMTU, as described in this document. This determines
Maximum Packet Size (MPS), the largest size of application data block an MPS, the largest size of application data block that can be sent
that can be sent across a network path using a single datagram). The across a network path using a single datagram. The Upper Layer
Upper Layer protocol is responsible for deciding when a session protocol is responsible for deciding when a session enables DPLPMTUD.
enables DPLPMTUD.
The discovered PLPMTU can be used to either: The discovered PLPMTU can be used to either:
* set the maximum datagram size for the current path; * set the maximum datagram size for the current path or
* set the maximum fragment size when a sender uses the UDP * set the maximum fragment size when a sender uses the UDP
Fragmentation Option to divide a datagram into multiple UDP Fragmentation Option to divide a datagram into multiple UDP
fragments for transmission. The size of each UDP fragment is then fragments for transmission. The size of each UDP fragment is then
less than or equal to the size of the discovered largest IP packet less than or equal to the size of the discovered largest IP packet
that can be received across the current path. that can be received across the current path.
The figure below shows an implementation of DPLPMTUD within the UDP The figure below shows an implementation of DPLPMTUD within the UDP
transport service. It illustrates key interactions between the transport service. It illustrates key interactions between the
layers. This design requires an API primitive to allow the layers. This design requires an API primitive to allow the
application to control whether the DPLPMTUD state machine is enabled application to control whether the DPLPMTUD state machine is enabled
for a specific UDP port. By default, this API MUST disable DPLPMTUD for a specific UDP port. By default, this API MUST disable DPLPMTUD
processing. processing.
+--------------------------------+ +--------------------------------+
| Upper Layer Protocol | | Upper Layer Protocol |
| or Application | | or Application |
+---------------------------+----+ +---------------------------+----+
^ | Messages (with UDP Options) ^ | Messages (with UDP Options)
| receive send v Primitives for MPS, Min_PMTU etc. | receive send v Primitives for MPS, Min_PMTU, etc.
+---+----------------------------+ +---+----------------------------+
| DPLPMTUD State Machine | | DPLPMTUD State Machine |
| Maximum Packet Size (MPS) | | Maximum Packet Size (MPS) |
| PLPMTU, Probed-Size,Min_PMTU | | PLPMTU, Probed-Size, Min_PMTU|
| Token Values & Probes, etc. | | Token Values & Probes, etc. |
+---------------------------+----+ +---------------------------+----+
^ | Messages (with UDP Options) ^ | Messages (with UDP Options)
| | Send/Receive: Probes with Options | | Send/Receive: Probes with Options
| receive send v Events: ICMP, Interface MTU, etc. | receive send v Events: ICMP, Interface MTU, etc.
+---+----------------------------+ +---+----------------------------+
| UDP Options Transport | | UDP Options Transport |
+---------------------------+----+ +---------------------------+----+
^ | Datagrams (with UDP Options) ^ | Datagrams (with UDP Options)
| | Fragmented Datagrams with UDP Options | | Fragmented Datagrams with UDP Options
| receive send v Events: ICMP, Interface MTU, etc. | receive send v Events: ICMP, Interface MTU, etc.
Note: UDP allows an Upper Layer Protocol to send datagrams with or Note: UDP allows an Upper Layer protocol to send datagrams with or
without payload data (with or without UDP Options). These are without payload data (with or without UDP Options). These are
delivered across the network to the remote Upper Layer. When delivered across the network to the remote Upper Layer. When
DPLPMTUD is implemented within the UDP transport service, probe DPLPMTUD is implemented within the UDP transport service, probe
packets that include a REQ or RES UDP Option can be sent with no UDP packets that include a REQ or RES UDP Option can be sent with no UDP
payload. In this case, these probe packets were not generated by a payload. In this case, these probe packets were not generated by a
sending application and therefore the corresponding received sending application; therefore, the corresponding received datagrams
datagrams are not delivered to the remote application. are not delivered to the remote application.
When DPLPMTUD is instead implemented by an Upper Layer protocol, the When DPLPMTUD is instead implemented by an Upper Layer protocol, the
format and content of probe packets are determined by the Upper Layer format and content of probe packets are determined by the Upper Layer
protocol. This design is also permitted to use the REQ and RES protocol. This design is also permitted to use the REQ and RES
Options provided by UDP Options. Options provided by UDP Options.
If DPLPMTUD is active at more than one layer, then the values of the 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 tokens used in REQ Options need to be coordinated with any values
used for other DPLPMTUD probe packets to ensure that each probe used for other DPLPMTUD probe packets to ensure that each probe
packet can be identified by a unique token. When configurable, a packet can be identified by a unique token. When configurable, a
configuration ought to avoid performing such discovery both within configuration ought to avoid performing such discovery both within
UDP Options and also by an upper protocol layer that sends and UDP Options and also by an Upper Layer protocol that sends and
receives probe packets via UDP Options. Section 6.1 of [RFC8899] receives probe packets via UDP Options. Section 6.1 of [RFC8899]
recommends that: "An application SHOULD avoid using DPLPMTUD when the recommends that: "An application SHOULD avoid using DPLPMTUD when the
underlying transport system provides this capability." underlying transport system provides this capability."
3.1. Packet Formats 3.1. Packet Formats
The UDP Options used in this document are described in The UDP Options used in this document are described in [RFC9868] and
[I-D.ietf-tsvwg-udp-options] and are used in the following way: are used in the following ways:
* The REQ Option is set by a sending PL to solicit a response from a * The REQ Option is set by a sending PL to solicit a response from a
remote receiver. A four-byte (four octet) token identifies each remote receiver. A four-byte (four-octet) token identifies each
request. request.
* A sending PL can use the EOL option together with a minimum * A sending PL can use the EOL Option together with a minimum
datagram length to pad probe packets. datagram length to pad probe packets.
* The RES Option is sent by a UDP Options receiver in response to a * The RES Option is sent by a UDP Options receiver in response to a
previously received REQ Option. Each RES Option echoes the last previously received REQ Option. Each RES Option echoes the last
received four-byte token. received four-byte token.
* If a UDP Options endpoint creates and sends a datagram with a RES * If a UDP Options endpoint creates and sends a datagram with a RES
option solely as response to a received REQ Option, the responder Option solely as response to a received REQ Option, the responder
MUST limit the rate of these responses (e.g., limiting each pair MUST limit the rate of these responses (e.g., limiting each pair
of ports to send 1 per measured RTT or 1 per second). This rate of ports to send 1 per measured RTT or 1 per second). This rate
limit is to mitigate the DoS vector, without significantly limit is to mitigate the DoS vector without significantly
impacting the operation of DPLPMTUD. An example in impacting the operation of DPLPMTUD. An example in Section 6
Section Section 6 describes a case where this might be used. describes a case where this might be used.
* Reception of a RES Option by the REQ sender confirms that a * Reception of a RES Option by the REQ sender confirms that a
specific probe packet has been received by the remote UDP Options specific probe packet has been received by the remote UDP Options
receiver. receiver.
The token allows a UDP Options sender to distinguish between The token allows a UDP Options sender to distinguish between
acknowledgements for initial probe packets and acknowledgements acknowledgements for initial probe packets and acknowledgements
confirming receipt of subsequent probe packets (e.g., travelling confirming receipt of subsequent probe packets (e.g., travelling
along alternate paths with a larger round-trip time). Each probe along alternate paths with a larger RTT). Each probe packet MUST be
packet MUST be uniquely identifiable by the UDP Options sender within uniquely identifiable by the UDP Options sender within the Maximum
the Maximum Segment Lifetime (MSL) [RFC8085]. The UDP Options sender Segment Lifetime (MSL) [RFC8085]. The UDP Options sender MUST NOT
MUST NOT reuse a token value within the MSL. A four byte value for reuse a token value within the MSL. A four-byte value for the token
the token field provides sufficient space for multiple unique probe field provides sufficient space for multiple unique probe packets to
packets to be made within the MSL. Since UDP Options operates over be made within the MSL. Since UDP Options operates over UDP, the
UDP, the token values only need to be unique for the specific 5-tuple token values only need to be unique for the specific 5-tuple over
over which it is operating. which it is operating.
The value of the four-byte token field SHOULD be initialised to a The value of the four-byte token field SHOULD be initialized to a
randomised value to enhance protection from off-path attacks, as randomized value to enhance protection from off-path attacks, as
described in Section 5.1 of [RFC8085]. described in Section 5.1 of [RFC8085].
3.2. Sending Probe Packets with the Request Option 3.2. Sending Probe Packets with the Request Option
DPLPMTUD relies upon sending a probe packet with a specific size. DPLPMTUD relies upon sending a probe packet with a specific size.
Each probe packet includes the UDP Options area containing a REQ Each probe packet includes the UDP Options area containing a REQ
Option and any other required options concluded with an EOL Option Option and any other required options concluded with an EOL Option
(Section 11.1 of [I-D.ietf-tsvwg-udp-options]) followed by any (Section 11.1 of [RFC9868]), followed by any padding needed to
padding needed to inflate to the required probe size. inflate to the required probe size.
A probe packet can therefore be of size up to the maximum size A probe packet can therefore be up to the maximum size supported by
supported by the local interface (i.e., the Interface MTU). the local interface (i.e., the Interface MTU). Item 2 in Section 3
[RFC8899] (Section 3, item 2) requires the network interface below of [RFC8899] requires the network interface below DPLPMTUD to provide
DPLPMTUD to provide a way to transmit a probe packet that is larger a way to transmit a probe packet that is larger than the current
than the current PLPMTU. The size of this probe packet MUST NOT be PLPMTU. The size of this probe packet MUST NOT be constrained by the
constrained by the maximum PMTU set by network layer mechanisms (such maximum PMTU set by network layer mechanisms (such as discovered by
as discovered by PMTUD [RFC1191][RFC8201] or the PMTU size held in PMTUD [RFC1191][RFC8201] or the PMTU size held in the IP-layer
the IP-layer cache), as noted in bullet 2 of Section 3 in [RFC8899]). cache), as noted in item 2 in Section 3 of [RFC8899]).
UDP datagrams used as DPLPMTUD probe packets, as described in this UDP datagrams used as DPLPMTUD probe packets, as described in this
document, MUST NOT be fragmented at the UDP or IP layer. Section 3 document, MUST NOT be fragmented at the UDP or IP layer. Therefore,
of [RFC8899] therefore requires: "In IPv4, a probe packet MUST be Section 3 of [RFC8899] requires: "In IPv4, a probe packet MUST be
sent with the Don't Fragment (DF) bit set in the IP header and sent with the Don't Fragment (DF) bit set in the IP header and
without network layer endpoint fragmentation." without network layer endpoint fragmentation."
3.3. Receiving UDP-Options Probe Packets and sending the RES Option 3.3. Receiving UDP Options Probe Packets and Sending the RES Option
When DPLPMTUD is enabled, a UDP Options receiver responds by sending When DPLPMTUD is enabled, a UDP Options receiver responds by sending
a UDP datagram with the RES Option when it receives a UDP Options a UDP datagram with the RES Option when it receives a UDP Options
datagram with the REQ Option. datagram with the REQ Option.
The operation of DPLPMTUD can depend on the support at the remote UDP The operation of DPLPMTUD can depend on the support at the remote UDP
Options endpoint, the way in which DPLPMTUD is implemented and in Options endpoint, the way in which DPLPMTUD is implemented, and in
some cases the application data that is exchanged over the UDP some cases, the application data that is exchanged over the UDP
transport service. When UDP Options is not supported by the remote transport service. When UDP Options is not supported by the remote
receiver, DPLPMTUD will be unable to confirm the path or to discover receiver, DPLPMTUD will be unable to confirm the path or to discover
the PLPMTU. This will result in the minimum configured PLPMTU the PLPMTU. This will result in the minimum configured PLPMTU
(MIN_PLPMTU). More explanation of usage is provided in Section 6. (MIN_PLPMTU). More explanation of usage is provided in Section 6.
Note: A receiver that only responds when there is a datagram queued Note: A receiver that only responds when there is a datagram queued
for transmission by the Upper Layer could potentially receive for transmission by the Upper Layer could potentially receive
multiple datagrams with a REQ Option before it can respond. When multiple datagrams with a REQ Option before it can respond. When
sent, the RES Option will only acknowledge the latest received token sent, the RES Option will only acknowledge the latest received token
value. A sender would then conclude that any earlier REQ Options value. A sender would then conclude that any earlier REQ Options
were not successfully received. However, DPLPMTUD does not usually were not successfully received. However, DPLPMTUD does not usually
result in sending more than one probe packet per timeout interval, result in sending more than one probe packet per timeout interval,
and a delay in responding will already have been treated as a failed and a delay in responding will already have been treated as a failed
probe attempt. Therefore, this does not significantly impact probe attempt. Therefore, this does not significantly impact
performance, although a more prompt response would have resulted in performance, although a more prompt response would have resulted in
DPLPMTUD recording reception of all probe packets. DPLPMTUD recording reception of all probe packets.
4. DPLPMTUD Sender Procedures for UDP Options 4. DPLPMTUD Sender Procedures for UDP Options
DPLPMTUD utilises three types of probe. These are described in the DPLPMTUD utilizes three types of probe. These are described in the
following sections: following sections:
* Probes to confirm the path can support the BASE_PLPMTU * Probes to confirm the path can support the BASE_PLPMTU
(Section 5.1.4 of [RFC8899]). (Section 5.1.4 of [RFC8899]).
* Probes to detect whether the path can support a larger PLPMTU. * Probes to detect whether the path can support a larger PLPMTU.
* Probes to validate the path supports the current PLPMTU. * Probes to validate that the path supports the current PLPMTU.
4.1. Confirmation of Connectivity across a Path 4.1. Confirmation of Connectivity Across a Path
The DPLPMTUD method requires a PL to confirm connectivity over the 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 path (Section 5.1.4 of [RFC8899]), but UDP itself does not offer a
mechanism for this. mechanism for this.
UDP Options can provide this required functionality. A UDP Options UDP Options can provide this required functionality. A UDP Options
sender implementing this specification MUST elicit a positive sender implementing this specification MUST elicit a positive
confirmation of connectivity for the path, by sending a probe packet, confirmation of connectivity for the path by sending a probe packet
padded to size BASE_PLPMTU. This confirmation probe MUST include the padded to size BASE_PLPMTU. This confirmation probe MUST include the
REQ UDP Option to elicit a response from the remote DPLPMTUD. REQ UDP Option to elicit a response from the remote DPLPMTUD.
Reception of a datagram with the corresponding RES Option confirms Reception of a datagram with the corresponding RES Option confirms
the reception of a packet of the probed size that has successfully the reception of a packet of the probed size that has successfully
traversed the path to the receiver. This also confirms that the traversed the path to the receiver. This also confirms that the
remote endpoint supports the RES Option. remote endpoint supports the RES Option.
4.2. Sending Probe Packets to Increase the PLPMTU 4.2. Sending Probe Packets to Increase the PLPMTU
From time to time, DPLPMTUD enters the SEARCHING state, described in From time to time, DPLPMTUD enters the SEARCHING state, described in
Section 5.2 of [RFC8899], (e.g., after expiry of the Section 5.2 of [RFC8899], (e.g., after expiry of the
PMTU_RAISE_TIMER) to detect whether the current path can support a PMTU_RAISE_TIMER) to detect whether the current path can support a
larger PLPMTU. When the remote endpoint advertises a UDP Maximum larger PLPMTU. When the remote endpoint advertises a UDP Maximum
Datagram Size (MDS) option (see Section 11.5 of Datagram Size (MDS) option (see Section 11.5 of [RFC9868]), this
[I-D.ietf-tsvwg-udp-options]), this value MAY be used as a hint to value MAY be used as a hint to initialize this search to increase the
initialise this search to increase the PLPMTU. PLPMTU.
Probe packets seeking to increase the PLPMTU SHOULD NOT carry Probe packets seeking to increase the PLPMTU SHOULD NOT carry
application data ("Probing using padding data" in Section 4.1 of application data (see "Probing using padding data" in Section 4.1 of
[RFC8899]), since they will be lost whenever their size exceeds the [RFC8899]), since they will be lost whenever their size exceeds the
actual PMTU. [RFC8899] requires a probe packet to elicit a positive actual PMTU. [RFC8899] requires a probe packet to elicit a positive
acknowledgement that the path has delivered a datagram of the acknowledgement that the path has delivered a datagram of the
specific probed size and, therefore, when using specific probed size; therefore, a probe packet MUST include the REQ
[I-D.ietf-tsvwg-udp-options] a probe packet MUST include the REQ Option when using transport options for UDP [RFC9868].
Option.
At the receiver, a received probe packet that does not carry At the receiver, a received probe packet that does not carry
application data does not form a part of the end-to-end transport 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., data and is not delivered to the Upper Layer protocol (i.e.,
application or protocol layered above UDP). A zero-length payload application or protocol layered above UDP). A zero-length payload
notification could still be delivered to the application, see notification could still be delivered to the application (see
Section 5 of [RFC8085], although Section 18 of Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses
[I-D.ietf-tsvwg-udp-options] discusses the implications when using the implications when using UDP Options.
UDP Options.
4.3. Validating the Path with UDP Options 4.3. Validating the Path with UDP Options
A PL using DPLPMTUD MUST validate that a path continues to support A PL using DPLPMTUD MUST validate that a path continues to support
the PLPMTU discovered in a previous search for a suitable PLPMTU the PLPMTU discovered in a previous search for a suitable PLPMTU
value, as defined in Section 6.1.4 of [RFC8899]. This validation value, as defined in Section 6.1.4 of [RFC8899]. This validation
sends probe packets in the DPLPMTUD SEARCH_COMPLETE state to detect sends probe packets in the DPLPMTUD SEARCH_COMPLETE state
black-holing of data (Section 5.2 of [RFC8899], Section 4.3 of (Section 5.2 of [RFC8899]) to detect black-holing of data
[RFC8899] defines a DPLPMTUD black-hole). (Section 4.3 of [RFC8899] defines a DPLPMTUD black hole).
Path validation can be implemented within UDP Options by generating a Path validation can be implemented within UDP Options by generating a
probe packet of size PLPMTU, which MUST include a REQ Option to probe packet of size PLPMTU, which MUST include a REQ Option to
elicit a positive confirmation that the path has delivered this probe elicit a positive confirmation that the path has delivered this probe
packet. A probe packet used to validate the path MAY use either packet. A probe packet used to validate the path MAY use either
"Probing using padding data" to construct a probe packet that does "Probing using padding data" to construct a probe packet that does
not carry any application data (Section 4.1 of [RFC8899]) or "Probing not carry any application data or "Probing using application data and
using application data and padding data", see Section 4.1 of padding data"; see Section 4.1 of [RFC8899]. When using "Probing
[RFC8899]. When using "Probing using padding data", the UDP Options using padding data", the UDP Options API does not indicate receipt of
API does not indicate receipt of the zero-length probe packet, see the zero-length probe packet (see Section 6 of [RFC9868]).
Section 6 of [I-D.ietf-tsvwg-udp-options].
4.4. Probe Packets that do not include Application Data 4.4. Probe Packets That Do Not Include Application Data
A simple implementation of the method might be designed to only use A simple implementation of the method might be designed to only use
probe packets in a UDP datagram that includes no application data. probe packets in a UDP datagram that includes no application data.
The size of each probe packet is padded to the required probe size The size of each probe packet is padded to the required probe size
including the REQ Option. This implements "Probing using padding including the REQ Option. This implements "Probing using padding
data" (Section 4.1 of [RFC8899]) and avoids having to retransmit data" (Section 4.1 of [RFC8899]) and avoids having to retransmit
application data when a probe fails. This could be achieved by application data when a probe fails. This could be achieved by
setting a minimum datagram length, such that the options list ends in setting a minimum datagram length, such that the options list ends in
EOL (Section 11.1 of [I-D.ietf-tsvwg-udp-options]) with any EOL (Section 11.1 of [RFC9868]) with any additional space zero-filled
additional space is zero-filled as needed (see Section 15 of as needed (see Section 15 of [RFC9868]). In this use, the probe
[I-D.ietf-tsvwg-udp-options]). In this use, the probe packets do not packets do not form a part of the end-to-end transport data and a
form a part of the end-to-end transport data and a receiver does not receiver does not deliver them to the Upper Layer protocol.
deliver them to the Upper Layer protocol.
4.5. Probe Packets that include Application Data 4.5. Probe Packets That Include Application Data
An implementation always uses the format in Section 4.4 when DPLPMTUD An implementation always uses the format in Section 4.4 when DPLPMTUD
searches to increase the PLPMTU. searches to increase the PLPMTU.
An alternative format is permitted for a probe packet that is used to An alternative format is permitted for a probe packet that is used to
confirm the connectivity or to validate the path. These probe confirm the connectivity or to validate the path. These probe
packets MAY carry application data. (A UDP payload data is permitted packets MAY carry application data. (UDP payload data is permitted
because these probe packets perform black-hole detection and will, because these probe packets perform black-hole detection and will
therefore, usually have a higher probability of successful therefore usually have a higher probability of successful
transmission, similar to other packets sent by the Upper Layer transmission, similar to other packets sent by the Upper Layer
protocol.) Section 4.1 of [RFC8899] provides a discussion of the protocol.) Section 4.1 of [RFC8899] provides a discussion of the
merits and demerits of including application data. For example, this merits and demerits of including application data. For example, this
reduces the need to send additional datagrams. reduces the need to send additional datagrams.
This type of probe packet MAY use a control message format defined by This type of probe packet MAY use a control message format defined by
the Upper Layer protocol, provided that the message does not need to the Upper Layer protocol, provided that the message does not need to
be delivered reliably. The REQ Option MUST be included when the be delivered reliably. The REQ Option MUST be included when the
sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method
tracks the transmission of probe packets (using the REQ Option tracks the transmission of probe packets (using the REQ Option
token). token).
A receiver that responds to DPLPMTUD MUST process the REQ Option and A receiver that responds to DPLPMTUD MUST process the REQ Option and
include the corresponding RES Option with an Upper Layer protocol include the corresponding RES Option with an Upper Layer protocol
message that it returns to the requester (examples of receiver message that it returns to the requester (examples of receiver
processing are provided in Section Section 6). processing are provided in Section 6).
Probe packets that use this format form a part of the end-to-end Probe packets that use this format form a part of the end-to-end
transport data and can be used to manage the PLPMTU in just one transport data and can be used to manage the PLPMTU in just one
direction or can be used for both directions. direction or can be used for both directions.
5. Receiving Events from the Network 5. Receiving Events from the Network
This specification does not rely upon reception of events from the This specification does not rely upon reception of events from the
network, but an implementation can utilise these events when they are network, but an implementation can utilize these events when they are
provided. provided.
5.1. Changes in the Path 5.1. Changes in the Path
A change in the path or the loss of a probe packet can result in A change in the path or the loss of a probe packet can result in
DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends that DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends that
methods are robust to path changes that could have occurred since the methods are robust to path changes that could have occurred since the
path characteristics were last confirmed and to the possibility of path characteristics were last confirmed and to the possibility of
inconsistent path information being received. For example, a inconsistent path information being received. For example, a
notification that a path has changed could trigger path validation to notification that a path has changed could trigger path validation to
skipping to change at page 11, line 21 skipping to change at line 480
interface/destination) to be robust to the wide variety of underlying interface/destination) to be robust to the wide variety of underlying
network forwarding behaviors. For example, an implementation could network forwarding behaviors. For example, an implementation could
avoid sharing PMTU information that could potentially relate to avoid sharing PMTU information that could potentially relate to
packets sent with the same address over a different interface. packets sent with the same address over a different interface.
5.2. Validation of PTB Messages 5.2. Validation of PTB Messages
Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A
UDP Options sender can therefore ignore received ICMP PTB messages. UDP Options sender can therefore ignore received ICMP PTB messages.
Before processing an ICMP PTB message the DPLPMTUD method needs to Before processing an ICMP PTB message, the DPLPMTUD method needs to
perform two checks that the messgage was received in response to a perform two checks to ensure that the message was received in
sent probe packet: response to a sent probe packet:
* DPLPMTUD first utilises the quoted information in each PTB * DPLPMTUD first utilizes the quoted information in each PTB
message. The receiver MUST validate the protocol information in message. The receiver MUST validate the protocol information in
the quoted packet carried in an ICMP PTB message payload to the quoted packet carried in an ICMP PTB message payload to
validate the message originated from the sending node (see validate the message originated from the sending node (see
Section 4.6.1 of [RFC8899]). Section 4.6.1 of [RFC8899]).
* The receiver SHOULD utilize information that is not simple for an * The receiver SHOULD utilize information that is not simple for an
off-path attacker to determine (see Section 4.6.1 of [RFC8899]). off-path attacker to determine (see Section 4.6.1 of [RFC8899]).
Specifically, a UDP Options receiver SHOULD confirm that the token Specifically, a UDP Options receiver SHOULD confirm that the token
contained in the UDP REQ Option of the quoted packet has a value contained in the UDP REQ Option of the quoted packet has a value
that corresponds to a probe packet that was recently sent by the that corresponds to a probe packet that was recently sent by the
skipping to change at page 11, line 49 skipping to change at line 508
received ICMP PTB messages. received ICMP PTB messages.
6. Examples with Different Receiver Behaviors 6. Examples with Different Receiver Behaviors
When enabled, a DPLPMTUD endpoint that implements UDP Options When enabled, a DPLPMTUD endpoint that implements UDP Options
normally responds with a UDP datagram with a RES Option when normally responds with a UDP datagram with a RES Option when
requested by a sender. requested by a sender.
The following examples describe various possible receiver behaviors: The following examples describe various possible receiver behaviors:
* (No DPLPMTUD receiver support) One case is when a sender supports * No DPLPMTUD receiver support: One case is when a sender supports
this specification, but no RES Option is received from the remote this specification, but no RES Option is received from the remote
endpoint. In this example, the method is unable to discover the endpoint. In this example, the method is unable to discover the
PLPMTU. This will result in using the minimum configured PLPMTU PLPMTU. This will result in using the MIN_PLPMTU. Such a remote
(MIN_PLPMTU). Such a remote endpoint might be not configured to endpoint might be not configured to process UDP Options or might
process UDP Options, or might not return a datagram with a RES not return a datagram with a RES Option for some other reason
Option for some other reason (packet loss, insufficient space to (e.g., packet loss, insufficient space to include the option,
include the option, filtering on the path, etc). filtering on the path, etc.).
* (DPLPMTUD receiver uses application datagrams) In a second case, * DPLPMTUD receiver uses application datagrams: In a second case,
both the sender and receiver support DPLPMTUD using the both the sender and receiver support DPLPMTUD using the
specification, and the receiver only returns a RES Option with the specification, and the receiver only returns a RES Option with the
next UDP datagram that is sent to the requester. Therefore, next UDP datagram that is sent to the requester. Therefore,
reception of a REQ Option does not systematically trigger a reception of a REQ Option does not systematically trigger a
response. This allows DPLPMTUD to operate when there is a flow of response. This allows DPLPMTUD to operate when there is a flow of
datagrams in both directions, providing there is periodic feedback datagrams in both directions, provided there is periodic feedback
(e.g., one acknowledgement packet per RTT). It requires the (e.g., one acknowledgement packet per RTT). It requires the
PLPMTU at the receiver to be sufficiently large that the RES PLPMTU at the receiver to be sufficiently large enough that the
option can be included in the feedback packets that are sent in RES Option can be included in the feedback packets that are sent
the return direction. This method avoids opportunities to misuse in the return direction. This method avoids opportunities to
the method as a DoS attack. However, when there is a low rate of misuse the method as a DoS attack. However, when there is a low
transmission (or no datagrams are sent) in the return direction, rate of transmission (or no datagrams are sent) in the return
this will prevent prompt delivery of the RES Option. At the direction, this will prevent prompt delivery of the RES Option.
DPLPMTUD sender, this results in probe packets failing to be At the DPLPMTUD sender, this results in probe packets failing to
acknowledged in time, and could result in a smaller PLPMTU than is be acknowledged in time and could result in a smaller PLPMTU than
actually supported by the path or in using the minimum configured is actually supported by the path or in using the MIN_PLPMTU.
PLPMTU (MIN_PLPMTU).
* (Uni-directional transfer) Another case is where an application * Unidirectional transfer: Another case is where an application only
only transfers data in one direction (or predominantly in one transfers data in one direction (or predominantly in one
direction). In this case the wait at the receiver for a datagram direction). In this case, the wait at the receiver for a datagram
to be queued before returning a RES Option could easily result in to be queued before returning a RES Option could easily result in
a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD
could allow exchanging datagrams without a payload (as discussed could allow exchanging datagrams without a payload (as discussed
in earlier sections) to return the RES Option. in earlier sections) to return the RES Option.
* (DPLPMTUD Receiver permitted to send responses in UDP datagrams * DPLPMTUD receiver permitted to send responses in UDP datagrams
with no payload) A DPLPMTUD receiver can generate a datagram with no payload: A DPLPMTUD receiver can generate a datagram
(e.g., with zero payload data) solely to return a RES Option (e.g., with zero payload data) solely to return a RES Option
(e.g., sent when no other datagrams are queued for transmission). (e.g., sent when no other datagrams are queued for transmission).
This would allow an endpoint to probe the set of UDP ports that This would allow an endpoint to probe the set of UDP ports that
have been configured with support for this specification using a have been configured with support for this specification using a
DPLPMTUD probe packet. Although this results in some additional DPLPMTUD probe packet. Although this results in some additional
traffic overhead, it has the advantage that it can ensure timely traffic overhead, it has the advantage that it can ensure timely
progress of DPLPMTUD. Section Section 3.1 specifies: "If a UDP progress of DPLPMTUD. Section 3.1 specifies: "If a UDP Options
Options endpoint creates and sends a datagram with a RES option endpoint creates and sends a datagram with a RES Option solely as
solely as response to a received REQ Option, the responder MUST response to a received REQ Option, the responder MUST limit the
limit the rate of these responses (e.g., limiting each pair of rate of these responses (e.g., limiting each pair of ports to send
ports to send 1 per RTT or 1 per second)". This rate limit is to 1 per measured RTT or 1 per second)". This rate limit is to
mitigate the DoS vector, without significantly impacting the mitigate the DoS vector, without significantly impacting the
operation of DPLPMTUD. operation of DPLPMTUD.
7. Acknowledgements 7. IANA Considerations
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. This document has no IANA actions.
9. Security Considerations 8. Security Considerations
The security considerations for using UDP Options are described in The security considerations for using UDP Options are described in
[I-D.ietf-tsvwg-udp-options]. The method does not change the [RFC9868]. The method does not change the integrity protection
integrity protection offered by the UDP options method. offered by the UDP Options method.
The security considerations for using DPLPMTUD are described in The security considerations for using DPLPMTUD are described in
[RFC8899]. On path attackers could maliciously drop or modify probe [RFC8899]. On-path attackers could maliciously drop or modify probe
packets to seek to decrease the PMTU, or to maliciously modify probe packets to seek to decrease the PMTU or to maliciously modify probe
packets in an attempt to black-hole traffic. packets in an attempt to black-hole traffic.
The specification recommends that the token value in the REQ Option The specification recommends that the token value in the REQ Option
is initialised to a randomised value. This is to enhance protection is initialized to a randomized value. This is to enhance protection
from off-path attacks. If a subsequent probe packet uses a token from off-path attacks. If a subsequent probe packet uses a token
value that is easily derived from the initial value, (e.g., value that is easily derived from the initial value (e.g.,
incrementing the value) a misbehaving on-path observer could then incrementing the value), a misbehaving on-path observer could then
determine the token values used for subsequent probe packets from determine the token values used for subsequent probe packets from
that sender, even if these probe packets are not transiting via the that sender, even if these probe packets are not transiting via the
observer. This would allow probe packets to be forged, with an observer. This would allow probe packets to be forged, with an
impact similar to other on-path attacks against probe packets. This impact similar to other on-path attacks against probe packets. This
attack could be mitigated by using an unpredictable token value for attack could be mitigated by using an unpredictable token value for
each probe packet. each probe packet.
The method does not change the ICMP PTB message validation method The method does not change the ICMP PTB message validation method
described by DPLPMTUD: A UDP Options sender that utilises ICMP PTB described by DPLPMTUD: A UDP Options sender that utilizes ICMP PTB
messages received to a probe packet MUST use the quoted packet to messages received to a probe packet MUST use the quoted packet to
validate the UDP port information in combination with the token validate the UDP port information in combination with the token
contained in the UDP Option, before processing the packet using the contained in the UDP Option before processing the packet using the
DPLPMTUD method. DPLPMTUD method.
Upper Layer protocols or applications that employ encryption ought to Upper Layer protocols or applications that employ encryption ought to
perform DPLPMTUD at a layer above UDP Options, and not enable UDP perform DPLPMTUD at a layer above UDP Options and not enable UDP
Options support for DPLPMTUD. This allows the application to control Options support for DPLPMTUD. This allows the application to control
when DPLPMTUD is used to control the additional traffic that this when DPLPMTUD is used to control the additional traffic that this
generates. This also ensures that DPLPMTUD probe packets are generates. This also ensures that DPLPMTUD probe packets are
encrypted. encrypted.
10. References 9. References
10.1. Normative References
[I-D.ietf-tsvwg-udp-options] 9.1. Normative References
Touch, J. D. and C. M. Heard, "Transport Options for UDP",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-
options-39, 13 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
udp-options-39>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
10.2. Informative References [RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP",
RFC 9868, DOI 10.17487/RFC9868, September 2025,
<https://www.rfc-editor.org/info/rfc9868>.
9.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
skipping to change at page 15, line 10 skipping to change at line 650
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP- User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>. <https://www.rfc-editor.org/info/rfc8304>.
Appendix A. Revision Notes Acknowledgements
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, fixed.
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
Working group draft-06.
Tidy text after WG Last Call, based on review by Med.
Added text after WG Last Call, based on review by Magnus.
Added text after WG Last Call, based on comments by Joe and Mike.
Restructured to integrate the WGLC new text.
Working group draft-07.
Mention of UDP-Options in Intro, from a review by Med.
Resolve typo, from review by Magnus.
Working group draft-08.
Corrections following a review by Mike Heard.
Working group draft-09.
Corrections following a review by Erik Auerswald and others.
Working group draft-10.
Corrections following a review by Erik Auerswald.
Working group draft-11.
Revised data - waiting for UDP Options to complete.
Working group draft-11.
Editorial corrections to align section numbers in referenced RFCs/
I-Ds and minor editorial improvements.
Working group draft -12, -13.
Editorial corrections preparing for WGLC.
Working group draft -14.
Updated after INT and SEC reviews.
Working group draft -15.
Updated after IESG comments. Gorry Fairhurst and Tom Jones are supported by funding provided by
the University of Aberdeen. The authors would like to thank Magnus
Westerlund and Mohamed Boucadair for their detailed comments and also
other people who contributed to completing this document.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
 End of changes. 85 change blocks. 
388 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.48.