rfc9869xml2.original.xml   rfc9869.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC768 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.0768.xml">
<!ENTITY RFC1191 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1191.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4821.xml">
<!ENTITY RFC8085 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8085.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8201.xml">
<!ENTITY RFC8304 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8304.xml">
<!ENTITY RFC8899 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8899.xml">
<!ENTITY I-D.ietf-tsvwg-udp-options SYSTEM "http://xml2rfc.tools.ietf.org/public
/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-udp-options-39.xml">
]>
<!-- ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tsvwg-udp-options-dplpmtud-15"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust20090
2,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only neces
sary if the
full title is longer than 39 characters -->
<title abbrev="UDPO DPLPMTUD">Datagram PLPMTUD for UDP Options</title>
<!-- add 'role="editor"' below for the editors if appropriate --> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- Another author who claims to be an editor --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-tsvwg-udp-options-dplpmtud-15" number="9869" consensus="true" ipr="trust20090 2" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="UDP Options with DPLPMTUD">Datagram Packetization Layer P
ath MTU Discovery (DPLPMTUD) for UDP Options</title>
<seriesInfo name="RFC" value="9869"/>
<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst"> <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address>
<address> <postal>
<postal> <street>School of Engineering</street>
<street>School of Engineering</street> <street>Fraser Noble Building</street>
<street>Fraser Noble Building</street> <city>Aberdeen</city>
<city>Aberdeen</city> <code>AB24 3UE</code>
<region></region> <country>United Kingdom</country>
<code>AB24 3UE</code> </postal>
<country>UK</country> <email>gorry@erg.abdn.ac.uk</email>
</postal> </address>
</author>
<email>gorry@erg.abdn.ac.uk</email> <author fullname="Tom Jones" initials="T" surname="Jones">
</address> <organization>University of Aberdeen</organization>
</author> <address>
<postal>
<author fullname="Tom Jones" initials="T" surname="Jones"> <street>School of Engineering</street>
<organization>University of Aberdeen</organization> <street>Fraser Noble Building</street>
<city>Aberdeen</city>
<address> <code>AB24 3UE</code>
<postal> <country>United Kingdom</country>
<street>School of Engineering</street> </postal>
<street>Fraser Noble Building</street> <email>tom@erg.abdn.ac.uk</email>
<city>Aberdeen</city> </address>
<region></region> </author>
<code>AB24 3UE</code> <date month="October" year="2025"/>
<country>UK</country>
<country>UK</country>
</postal>
<email>tom@erg.abdn.ac.uk</email>
</address>
</author>
<date day="20" month="February" year="2025" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions. If this element is not
present, the default is "Network Working Group", which is used by the
RFC Editor as a nod to the history of the IETF. -->
<keyword>UDP UDP-Options PMTUD PLPMTUD DPLPMTUD Datagram</keyword> <area>WIT</area>
<workgroup>tsvwg</workgroup>
<abstract> <keyword>UDP</keyword>
<t>This document specifies how a UDP Options sender implements Datag <keyword>UDP-Options</keyword>
ram <keyword>PMTUD</keyword>
Packetization Layer Path Maximum Transmission Unit Discovery (DP <keyword>PLPMTUD</keyword>
LPMTUD) <keyword>DPLPMTUD</keyword>
as a robust method for Path Maximum Transmission Unit discovery. <keyword>Datagram</keyword>
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
.</t>
</abstract>
</front>
<middle> <abstract>
<section title="Introduction"> <t>This document specifies how a UDP Options sender implements Datagram
<t>The User Datagram Protocol <xref target="RFC0768"></xref> offers Packetization Layer Path MTU Discovery (DPLPMTUD)
a as a robust method for Path MTU Discovery (PMTUD). 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 (MPS) supported by
a
path and to update this when required.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>The User Datagram Protocol (UDP) <xref target="RFC0768" format="default
"/> offers a
minimal transport service on top of IP and is frequently used as a minimal transport service on top of IP and is frequently used as a
substrate for other protocols. Section 3.2 of UDP Guidelines <xref substrate for other protocols. Section <xref target="RFC8085" sectio
target="RFC8085"></xref> recommends that applications implement some nFormat="bare" section="3.2"/> of UDP Guidelines <xref target="RFC8085" format="
form of Path MTU discovery to avoid the generation of IP fragments:< default"/> recommends that applications implement some
/t> form of Path MTU Discovery (PMTUD) to avoid the generation of IP fra
gments:</t>
<t>"Consequently, an application SHOULD either use the path MTU <blockquote>Consequently, an application <bcp14>SHOULD</bcp14> 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 Discovery
(PMTUD)".</t> (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether th
e
<t>The UDP API <xref target="RFC8304"></xref> offers calls for path to a destination will support its desired message size without
fragmentation.</blockquote>
<t>The UDP API <xref target="RFC8304" format="default"/> offers calls for
applications to receive ICMP Packet Too Big (PTB) messages and to 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 control the maximum size of datagrams that are sent, but it does not offer
any automated mechanisms for an application to discover the maximum any automated mechanisms for an application to discover the MPS
packet size supported by a path. Upper Layer protocols, which supported by a path. Upper Layer protocols, which
includes applications, can include applications, can
implement mechanisms for Path MTU discovery above the UDP API.</t> implement mechanisms for PMTUD above the UDP API.</t>
<t>Packetization Layer Path MTU Discovery (PLPMTUD) <xref target="RFC4821"
<t>Packetization Layer Path MTU Discovery (PLPMTUD) <xref target="RF format="default"/>
C4821"></xref> describes a method for a bidirectional Packetization Layer (PL)
describes a method for a bi-directional Packetization Layer (PL)
to search for the largest Packetization Layer PMTU (PLPMTU) supporte d on to search for the largest Packetization Layer PMTU (PLPMTU) supporte d on
a path. Datagram PLPMTUD (DPLPMTUD) <xref target="RFC8899"></xref> a path. DPLPMTUD <xref target="RFC8899" format="default"/>
specifies this support for datagram transports. PLPMTUD and DPLPMTUD specifies this support for datagram transports. PLPMTUD and DPLPMTUD
gain robustness by using a probing mechanism that does not solely re ly on gain robustness by using a probing mechanism that does not solely re ly on
ICMP PTB messages and works on paths that drop ICMP PTB messages.</t > ICMP PTB messages and works on paths that drop ICMP PTB messages.</t >
<t>UDP Options <xref target="RFC9868" format="default"/> supplies
<t>UDP Options <xref target="I-D.ietf-tsvwg-udp-options"></xref> sup
plies
functionality that can be used to implement DPLPMTUD within the functionality that can be used to implement DPLPMTUD within the
transport service or in an Upper Layer protocol (including an applic ation) transport service or in an Upper Layer protocol (including an applic ation)
that uses UDP Options. that uses UDP Options.
This document specifies how DPLPMTUD using UDP Options This document specifies how DPLPMTUD using UDP Options
is implemented (Section 6.1 of <xref target="RFC8899"></xref>), is implemented (<xref target="RFC8899" sectionFormat="of" section="6 .1"/>)
and requires support to be enabled at both the sender and receiver. and requires support to be enabled at both the sender and receiver.
</t> </t>
<t>Implementing DPLPMTUD within the
<t>Implementing DPLPMTUD within the
transport service above UDP Options avoids the need for transport service above UDP Options avoids the need for
each Upper Layer protocol to implement the DPLPMTUD each Upper Layer protocol to implement the DPLPMTUD
method. It provides a standard method for applications to discover t he method. It provides a standard method for applications to discover t he
current maximum packet size for a path and to detect when this current MPS for a path and to detect when this
changes. It can be used with Equal-Cost Multipath (ECMP) routing changes. It can be used with Equal-Cost Multipath (ECMP) routing
and/or multihoming. If multipath or multihoming is supported, and/or multihoming. If multipath or multihoming is supported,
a state machine is needed for each path.</t> a state machine is needed for each path.</t>
<t>DPLPMTUD is not specified for multicast. The method requires
explicit acknowledgement of probe packets provided by UDP Options,
which is primarily intended for unicast use (see
<xref target="RFC9868" sectionFormat="of" section="23"/>).</t>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>DPLPMTUD is not specified for multicast. The method requires <t>This document uses the terms defined for DPLPMTUD (Sections <xref
explicit acknowledgment of probe packets provided by UDP Options, target="RFC8899" sectionFormat="bare" section="2"/> and <xref
which is primarily intended for unicast use (see Section 23 of target="RFC8899" sectionFormat="bare" section="5"/> of <xref
<xref target="I-D.ietf-tsvwg-udp-options"></xref>).</t> target="RFC8899" format="default"/>).
</t>
</section><!-- End of Intro --> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>DPLPMTUD for UDP Options</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT <t>A UDP Options sender implementing DPLPMTUD uses the method specified
", in <xref target="RFC8899" format="default"/>. In this specification,
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and DPLPMTUD is
"OPTIONAL" in this document are to be interpreted as described in realized using a pair of
BCP 14
<xref target="RFC2119"></xref>
<xref target="RFC8174"></xref>
when, and only when, they appear in all
capitals, as shown here.</t>
<t>
This document uses the terms defined for DPLPMTUD
(Sections 2 and 5 of <xref target="RFC8899"></xref>).
</t>
</section> <!-- End of terms -->
<section title="DPLPMTUD for UDP Options">
<t>A UDP Options sender implementing DPLPMTUD uses the method specif
ied
in <xref target="RFC8899"></xref>. In this specification, DPLPMTUD i
s
realised using a pair of
UDP Options: UDP Options:
the Request (REQ) Option and the Response (RES) Option the Request (REQ) Option and the Response (RES) Option
(Section 11.7 of <xref target="I-D.ietf-tsvwg-udp-options"></xref>). (<xref target="RFC9868" sectionFormat="of" section="11.7"/>).
The method also uses the End of Options List (EOL) Option The method also uses the End of Options List (EOL) Option
(Section 11.1 of <xref target="I-D.ietf-tsvwg-udp-options"></xref>) to (<xref target="RFC9868" sectionFormat="of" section="11.1"/>) to
introduce padding to set the size of a probe packet.</t> introduce padding to set the size of a probe packet.</t>
<t>Use of DPLPMTUD <bcp14>MUST</bcp14> be explicitly enabled by the applic
<t>Use of DPLPMTUD MUST be explicitly enabled by the application, fo ation, for instance,
r instance
once an application has established connectivity and is ready once an application has established connectivity and is ready
to exchange data with the remote Upper Layer protocol. to exchange data with the remote Upper Layer protocol.
Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Similarly, a DPLPMTUD receiver <bcp14>MUST NOT</bcp14> respond to a UDP REQ
Option until DPLPMTUD has been enabled. This is to help Option until DPLPMTUD has been enabled. This is to help
protect from mis-use of the mechanism for other forms of probing.</t protect from misuse of the mechanism for other forms of probing.</t>
> <t>Probe packets consume network capacity and incur endpoint
processing (<xref target="RFC8899" sectionFormat="of" section="4.1"/
<t>Probe packets consume network capacity and incur endpoint >).
processing (Section 4.1 of <xref target="RFC8899"></xref>).
Implementations ought to send a probe packet with a UDP REQ Implementations ought to send a probe packet with a UDP REQ
Option only when required by their local DPLPMTUD state machine, Option only when required by their local DPLPMTUD state machine,
i.e., when confirming the base PMTU for the path, i.e., when confirming the base PMTU for the path,
probing to increase the PLPMTU, or to confirm the current probing to increase the PLPMTU, or confirming the current
PLPMTU.</t> PLPMTU.</t>
<t>DPLPMTUD can be implemented
<t>DPLPMTUD can be implemented
over UDP Options in two ways:</t> over UDP Options in two ways:</t>
<list style="symbols"> <ul spacing="normal">
<t>Implementation within the UDP transport service;</t> <li>
<t>Implementation in an Upper Layer protocol (or application) t <t>Implementation within the UDP transport service.</t>
hat uses UDP Options.</t> </li>
</list> <li>
<t>Implementation in an Upper Layer protocol (or application) that use
<t>When DPLPMTUD is implemented within the UDP s UDP Options.</t>
</li>
</ul>
<t>When DPLPMTUD is implemented within the UDP
transport service, the DPLPMTUD state machine transport service, the DPLPMTUD state machine
is responsible for sending probe packets to determine a PLPMTU, as d escribed is responsible for sending probe packets to determine a PLPMTU, as d escribed
in this document (and hence the Maximum Packet Size (MPS), in this document. This determines an MPS,
the largest size of application data block that can be sent across a network path the largest size of application data block that can be sent across a network path
using a single datagram). The Upper Layer protocol is responsible fo r deciding using a single datagram. The Upper Layer protocol is responsible for deciding
when a session enables DPLPMTUD.</t> when a session enables DPLPMTUD.</t>
<t>The discovered PLPMTU can be used to either:</t>
<t>The discovered PLPMTU can be used to either:</t> <ul spacing="normal">
<li>
<list style="symbols"> <t> set the maximum datagram size for the current path or</t>
</li>
<t> set the maximum datagram size for the current path;</t> <li>
<t> set the maximum fragment size when a sender uses the <t> set the maximum fragment size when a sender uses the
UDP Fragmentation Option to divide a datagram into UDP Fragmentation Option to divide a datagram into
multiple UDP fragments for transmission. The size of each UD P fragment multiple UDP fragments for transmission. The size of each UD P fragment
is then less than or equal to the size of the discovered lar gest IP packet that can is then less than or equal to the size of the discovered lar gest IP packet that can
be received across the current path. be received across the current path.
</t> </t>
</list> </li>
</ul>
<t>The figure below shows an implementation of DPLPMTUD within the U <t>The figure below shows an implementation of DPLPMTUD within the UDP
DP
transport service. transport service.
It illustrates key interactions between the layers. It illustrates key interactions between the layers.
This design requires an API primitive to allow the application to This design requires an API primitive to allow the application to
control whether the DPLPMTUD state machine is enabled for a specific control whether the DPLPMTUD state machine is enabled for a specific
UDP port. By default, this API MUST disable DPLPMTUD processing.</t> UDP port. By default, this API <bcp14>MUST</bcp14> disable DPLPMTUD proces sing.</t>
<figure> <artset>
<artwork align="left"> <artwork type="svg">
<![CDATA[ <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="352" widt
h="560" viewBox="0 0 560 352" class="diagram" text-anchor="middle" font-family="
monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,16 L 8,64" fill="none" stroke="black"/>
<path d="M 8,112 L 8,192" fill="none" stroke="black"/>
<path d="M 8,256 L 8,288" fill="none" stroke="black"/>
<path d="M 40,72 L 40,112" fill="none" stroke="black"/>
<path d="M 40,200 L 40,256" fill="none" stroke="black"/>
<path d="M 40,296 L 40,336" fill="none" stroke="black"/>
<path d="M 232,64 L 232,104" fill="none" stroke="black"/>
<path d="M 232,192 L 232,248" fill="none" stroke="black"/>
<path d="M 232,288 L 232,336" fill="none" stroke="black"/>
<path d="M 272,16 L 272,64" fill="none" stroke="black"/>
<path d="M 272,112 L 272,192" fill="none" stroke="black"/>
<path d="M 272,256 L 272,288" fill="none" stroke="black"/>
<path d="M 8,16 L 272,16" fill="none" stroke="black"/>
<path d="M 8,64 L 272,64" fill="none" stroke="black"/>
<path d="M 8,112 L 272,112" fill="none" stroke="black"/>
<path d="M 8,192 L 272,192" fill="none" stroke="black"/>
<path d="M 8,256 L 272,256" fill="none" stroke="black"/>
<path d="M 8,288 L 272,288" fill="none" stroke="black"/>
<polygon class="arrowhead" points="240,336 228,330.4 228,341.6" fill="black" tra
nsform="rotate(90,232,336)"/>
<polygon class="arrowhead" points="240,248 228,242.4 228,253.6" fill="black" tra
nsform="rotate(90,232,248)"/>
<polygon class="arrowhead" points="240,104 228,98.4 228,109.6" fill="black" tran
sform="rotate(90,232,104)"/>
<polygon class="arrowhead" points="48,296 36,290.4 36,301.6" fill="black" transf
orm="rotate(270,40,296)"/>
<polygon class="arrowhead" points="48,200 36,194.4 36,205.6" fill="black" transf
orm="rotate(270,40,200)"/>
<polygon class="arrowhead" points="48,72 36,66.4 36,77.6" fill="black" transform
="rotate(270,40,72)"/>
<g class="text">
<text x="140" y="36">Upper Layer Protocol</text>
<text x="140" y="52">or Application</text>
<text x="352" y="84">Messages (with UDP Options)</text>
<text x="80" y="100">receive</text>
<text x="196" y="100">send</text>
<text x="376" y="100">Primitives for MPS, Min_PMTU, etc.</text>
<text x="108" y="132">DPLPMTUD State Machine</text>
<text x="136" y="148">Maximum Packet Size (MPS)</text>
<text x="148" y="164">PLPMTU, Probed-Size, Min_PMTU</text>
<text x="144" y="180">Token Values &amp; Probes, etc.</text>
<text x="352" y="212">Messages (with UDP Options)</text>
<text x="392" y="228">Send/Receive: Probes with Options</text>
<text x="80" y="244">receive</text>
<text x="196" y="244">send</text>
<text x="392" y="244">Events: ICMP, Interface MTU, etc.</text>
<text x="104" y="276">UDP Options Transport</text>
<text x="356" y="308">Datagrams (with UDP Options)</text>
<text x="408" y="324">Fragmented Datagrams with UDP Options</text>
<text x="80" y="340">receive</text>
<text x="196" y="340">send</text>
<text x="392" y="340">Events: ICMP, Interface MTU, etc.</text>
</g>
</svg>
</artwork>
<artwork align="left" name="" type="ascii-art" alt=""><![CDATA[
+--------------------------------+ +--------------------------------+
| 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.
]]></artwork>
]]></artwork> </artset>
</figure> <aside>
<t>Note: UDP allows an Upper Layer Protocol <t>Note: UDP allows an Upper Layer protocol
to send datagrams with or without payload data (with or without to send datagrams with or without payload data (with or without
UDP Options). These UDP Options). These
are delivered across the network to the remote Upper Layer. are delivered across the network to the remote Upper Layer.
When DPLPMTUD is implemented within the UDP When DPLPMTUD is implemented within the UDP
transport service, probe packets that include a REQ or RES UDP Optio n transport service, probe packets that include a REQ or RES UDP Optio n
can be sent with no UDP payload. can be sent with no UDP payload.
In this case, these probe packets were not generated by a sending In this case, these probe packets were not generated by a sending
application and therefore the corresponding received datagrams are application; therefore, the corresponding received datagrams are
not delivered to the remote application.</t> not delivered to the remote application.</t>
</aside>
<t>When DPLPMTUD is instead implemented by an Upper Layer protocol, <t>When DPLPMTUD is instead implemented by an Upper Layer protocol,
the format and content the format and content
of probe packets are determined by the Upper Layer protocol. of probe packets are determined by the Upper Layer protocol.
This design is also permitted to use the REQ and RES Options This design is also permitted to use the REQ and RES Options
provided by UDP Options.</t> provided by UDP Options.</t>
<t>If DPLPMTUD is active at more than one layer,
<t>If DPLPMTUD is active at more than one layer,
then the values of the tokens used in REQ Options need to be coordin ated then the values of the tokens used in REQ Options need to be coordin ated
with any values used for other DPLPMTUD probe packets to ensure with any values used for other DPLPMTUD probe packets to ensure
that each probe packet can be identified by a unique token. that each probe packet can be identified by a unique token.
When configurable, a configuration ought to avoid When configurable, a configuration ought to avoid
performing such discovery both within UDP Options performing such discovery both within UDP Options
and also by an upper protocol layer and also by an Upper Layer protocol
that sends and receives probe packets via UDP Options. that sends and receives probe packets via UDP Options.
Section 6.1 of <xref target="RFC8899"></xref> recommends that: <xref target="RFC8899" sectionFormat="of" section="6.1"/> recommends
"An application SHOULD avoid using DPLPMTUD when the underlying that:
"An application <bcp14>SHOULD</bcp14> avoid using DPLPMTUD when the
underlying
transport system provides this capability."</t> transport system provides this capability."</t>
<section anchor="formats" numbered="true" toc="default">
<section anchor="formats" title="Packet Formats"> <name>Packet Formats</name>
<t>The UDP Options used in this document are described in
<t>The UDP Options used in this document are described in <xref target="RFC9868" format="default"/> and are used
<xref target="I-D.ietf-tsvwg-udp-options"></xref> and are used in the following ways:</t>
in the following way:</t> <ul spacing="normal">
<li>
<list style="symbols"> <t>The REQ Option is set by a sending PL to solicit a response from
<t>The REQ Option is set by a sending PL to solicit a respon a
se from a remote receiver. A four-byte (four-octet) token identifies e
remote receiver. A four-byte (four octet) token identifies e ach request.</t>
ach request.</t> </li>
<li>
<t>A sending PL can use the EOL option together with a minim <t>A sending PL can use the EOL Option together with a minimum
um
datagram length to pad probe packets.</t> datagram length to pad probe packets.</t>
</li>
<t>The RES Option is sent by a UDP Options receiver in respo <li>
nse to a <t>The RES Option is sent by a UDP Options receiver in response to a
previously received REQ Option. Each RES Option echoes the l ast received previously received REQ Option. Each RES Option echoes the l ast received
four-byte token.</t> four-byte token.</t>
</li>
<t> If a UDP Options endpoint creates and sends a datagram <li>
with a RES option solely as response to a received REQ Optio <t> If a UDP Options endpoint creates and sends a datagram
n, with a RES Option solely as response to a received REQ Optio
the responder MUST limit the rate of these responses n,
the responder <bcp14>MUST</bcp14> limit the rate of these re
sponses
(e.g., limiting each pair of ports to send 1 per measured RT T or (e.g., limiting each pair of ports to send 1 per measured RT T or
1 per second). This rate limit is to mitigate the DoS vector , 1 per second). This rate limit is to mitigate the DoS vector
without significantly impacting the operation of DPLPMTUD. without significantly impacting the operation of DPLPMTUD.
An example in Section <xref target="examples"></xref> An example in <xref target="examples" format="default"/>
describes a case where this might be used.</t> describes a case where this might be used.</t>
<t> </li>
<li>
<t>
Reception of a RES Option by the REQ sender confirms that a specific Reception of a RES Option by the REQ sender confirms that a specific
probe packet has been received by the remote UDP Options rec eiver.</t> probe packet has been received by the remote UDP Options rec eiver.</t>
</list> </li>
</ul>
<t>The token allows a UDP Options sender to distinguish <t>The token allows a UDP Options sender to distinguish
between acknowledgements for initial probe packets and between acknowledgements for initial probe packets and
acknowledgements confirming receipt of subsequent probe packets acknowledgements confirming receipt of subsequent probe packets
(e.g., travelling along alternate paths with a larger round-trip (e.g., travelling along alternate paths with a larger RTT).
time). Each probe packet MUST be uniquely Each probe packet <bcp14>MUST</bcp14> be uniquely
identifiable by the UDP Options sender within the Maximum Segment identifiable by the UDP Options sender within the Maximum Segment
Lifetime (MSL) <xref target="RFC8085"></xref>. Lifetime (MSL) <xref target="RFC8085" format="default"/>.
The UDP Options sender MUST NOT reuse The UDP Options sender <bcp14>MUST NOT</bcp14> reuse
a token value within the MSL. A a token value within the MSL. A
four byte value for the token field provides sufficient space for four-byte value for the token field provides sufficient space for
multiple unique probe packets to be made within the MSL. Since UDP O ptions multiple unique probe packets to be made within the MSL. Since UDP O ptions
operates over UDP, the token values only need to be unique for operates over UDP, the token values only need to be unique for
the specific 5-tuple over which it is operating. the specific 5-tuple over which it is operating.
</t> </t>
<t>The value of the four-byte token field <bcp14>SHOULD</bcp14> be initi
<t>The value of the four-byte token field SHOULD be initialised alized
to a randomised value to enhance protection from off-path attacks, to a randomized value to enhance protection from off-path attacks,
as described in Section 5.1 of <xref target="RFC8085"></xref>.</t> as described in <xref target="RFC8085" sectionFormat="of" section="5
.1"/>.</t>
</section> <!-- End of DPLPMTUD for UDP Options:Formats --> </section>
<section title="Sending Probe Packets with the Request Option">
<t>DPLPMTUD relies upon sending a probe packet <section numbered="true" toc="default">
<name>Sending Probe Packets with the Request Option</name>
<t>DPLPMTUD relies upon sending a probe packet
with a specific size. with a specific size.
Each probe packet includes the UDP Options area containing Each probe packet includes the UDP Options area containing
a REQ Option a REQ Option
and any other required options concluded with an EOL Option and any other required options concluded with an EOL Option
(Section 11.1 of <xref target="I-D.ietf-tsvwg-udp-options"></xref>) (<xref target="RFC9868" sectionFormat="of" section="11.1"/>),
followed by any padding needed to inflate to the required probe size .</t> followed by any padding needed to inflate to the required probe size .</t>
<t>A probe packet can therefore be up to the maximum size
<t>A probe packet can therefore be of size up to the maximum size
supported by the local interface (i.e., the Interface MTU). supported by the local interface (i.e., the Interface MTU).
<xref target="RFC8899"></xref> (Section 3, item 2) requires the netw ork interface Item 2 in <xref section="3" target="RFC8899" format="default"/> requ ires the network interface
below DPLPMTUD to provide a way to transmit a probe packet below DPLPMTUD to provide a way to transmit a probe packet
that is larger than the current PLPMTU. that is larger than the current PLPMTU.
The size of this probe packet MUST NOT be constrained by the maximum PMTU The size of this probe packet <bcp14>MUST NOT</bcp14> be constrained by the maximum PMTU
set by network layer mechanisms (such as discovered by PMTUD set by network layer mechanisms (such as discovered by PMTUD
<xref target="RFC1191"></xref><xref target="RFC8201"></xref> or the PMTU size <xref target="RFC1191" format="default"/><xref target="RFC8201" form at="default"/> or the PMTU size
held in the IP-layer cache), held in the IP-layer cache),
as noted in bullet 2 of Section 3 in <xref target="RFC8899"></xref>) as noted in item 2 in <xref target="RFC8899" sectionFormat="of" sect
.</t> ion="3"/>).</t>
<t>UDP datagrams used as DPLPMTUD probe packets, as described in this
<t>UDP datagrams used as DPLPMTUD probe packets, as described in thi document, <bcp14>MUST NOT</bcp14> be fragmented at the UDP or IP lay
s er.
document, MUST NOT be fragmented at the UDP or IP layer. Therefore, <xref target="RFC8899" sectionFormat="of" section="3"/>
Section 3 of <xref target="RFC8899"></xref> requires: "In IPv4, a probe packet <bcp14>MUST</bcp14> be sent with
therefore requires: "In IPv4, a probe packet MUST be sent with the the
Don't Fragment (DF) bit set in the IP header and without network lay er Don't Fragment (DF) bit set in the IP header and without network lay er
endpoint fragmentation."</t> endpoint fragmentation."</t>
</section>
</section> <!-- End of DPLPMTUD for UDP Options:sending --> <section numbered="true" toc="default">
<name>Receiving UDP Options Probe Packets and Sending the RES Option</na
<section title="Receiving UDP-Options Probe Packets and sending the RES me>
Option"> <t>When DPLPMTUD is enabled, a UDP Options receiver responds
<t>When DPLPMTUD is enabled, a UDP Options receiver responds
by sending a UDP datagram with the RES Option when by sending a UDP datagram with the RES Option when
it receives a UDP Options datagram with it receives a UDP Options datagram with
the REQ Option.</t> the REQ Option.</t>
<t>The operation of DPLPMTUD can depend on the support at
<t>The operation of DPLPMTUD can depend on the support at
the remote UDP Options endpoint, the way in which DPLPMTUD the remote UDP Options endpoint, the way in which DPLPMTUD
is implemented and in some cases the application data that is is implemented, and in some cases, the application data that is
exchanged over the UDP transport service. exchanged over the UDP transport service.
When UDP Options is not supported by the remote receiver, When UDP Options is not supported by the remote receiver,
DPLPMTUD will be unable to confirm the path or to discover the PLPMT U. DPLPMTUD will be unable to confirm the path or to discover the PLPMT U.
This will result in the minimum configured PLPMTU (MIN_PLPMTU). This will result in the minimum configured PLPMTU (MIN_PLPMTU).
More explanation of usage is provided in <xref target="examples"></x More explanation of usage is provided in <xref target="examples" for
ref>. mat="default"/>.
</t> </t>
<aside>
<t>Note: A receiver that only responds when there is a datagram <t>Note: A receiver that only responds when there is a datagram
queued for transmission by the Upper Layer could potentially queued for transmission by the Upper Layer could potentially
receive multiple datagrams with a REQ Option before it can receive multiple datagrams with a REQ Option before it can
respond. When sent, the RES Option will only acknowledge the respond. When sent, the RES Option will only acknowledge the
latest received token value. A sender would then conclude latest received token value. A sender would then conclude
that any earlier REQ Options were not successfully received. that any earlier REQ Options were not successfully received.
However, DPLPMTUD does not usually result in sending more than one However, DPLPMTUD does not usually result in sending more than one
probe packet per timeout interval, and a delay in responding probe packet per timeout interval, and a delay in responding
will already have been treated as a failed probe attempt. will already have been treated as a failed probe attempt.
Therefore, this does not significantly impact performance, Therefore, this does not significantly impact performance,
although a more prompt response would have resulted in although a more prompt response would have resulted in
DPLPMTUD recording reception of all probe packets.</t> DPLPMTUD recording reception of all probe packets.</t>
</aside>
</section> <!-- End of DPLPMTUD for UDP Options:Receiving --> </section>
</section> <!-- End of DPLPMTUD for UDP Options --> </section>
<section anchor="UDPOPT-PLPMTUD" title="DPLPMTUD Sender Procedures for UDP O
ptions">
<t> DPLPMTUD utilises three types of probe. These are described in t
he following sections:</t>
<list style="symbols">
<t>Probes to confirm the path can support the BASE_PLPMTU (Secti
on 5.1.4 of <xref
target="RFC8899"></xref>).</t>
<t>Probes to detect whether the path can support a larger PLPMTU
.</t>
<t>Probes to validate the path supports the current PLPMTU.</t>
</list>
<section title="Confirmation of Connectivity across a Path">
<t>The DPLPMTUD method requires a PL to confirm
connectivity over the path (Section 5.1.4 of <xref
target="RFC8899"></xref>), but UDP itself does not offer
a mechanism for
this.</t>
<t>UDP Options can provide this required functionality. A UDP Op <section anchor="UDPOPT-PLPMTUD" numbered="true" toc="default">
tions <name>DPLPMTUD Sender Procedures for UDP Options</name>
sender implementing this specification MUST elicit a positiv <t> DPLPMTUD utilizes three types of probe. These are described in the fol
e lowing sections:</t>
confirmation of connectivity for the path, by sending a prob <ul spacing="normal">
e packet, <li>
padded to size BASE_PLPMTU. This confirmation probe MUST <t>Probes to confirm the path can support the BASE_PLPMTU (<xref targe
t="RFC8899" sectionFormat="of" section="5.1.4"/>).</t>
</li>
<li>
<t>Probes to detect whether the path can support a larger PLPMTU.</t>
</li>
<li>
<t>Probes to validate that the path supports the current PLPMTU.</t>
</li>
</ul>
<section numbered="true" toc="default">
<name>Confirmation of Connectivity Across a Path</name>
<t>The DPLPMTUD method requires a PL to confirm connectivity over the
path (<xref target="RFC8899" sectionFormat="of" section="5.1.4"/>),
but UDP itself does not offer a mechanism for this.</t>
<t>UDP Options can provide this required functionality. A UDP Options
sender implementing this specification <bcp14>MUST</bcp14> e
licit a positive
confirmation of connectivity for the path by sending a probe
packet
padded to size BASE_PLPMTU. This confirmation probe <bcp14>M
UST</bcp14>
include the REQ UDP Option to elicit a response from the rem ote DPLPMTUD. include the REQ UDP Option to elicit a response from the rem ote DPLPMTUD.
Reception of a datagram with the corresponding RES Option co nfirms Reception of a datagram with the corresponding RES Option co nfirms
the reception of a packet of the probed size that has succes sfully the reception of a packet of the probed size that has succes sfully
traversed the path to the receiver. traversed the path to the receiver.
This also confirms that the This also confirms that the
remote endpoint supports the RES Option.</t> remote endpoint supports the RES Option.</t>
</section> <!-- End of Procedures for UDP Options:End of confirm --> </section>
<section title="Sending Probe Packets to Increase the PLPMTU">
<t>From time to time, DPLPMTUD enters the SEARCHING state, descr
ibed in
Section 5.2 of <xref target="RFC8899"></xref>,
(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 (see Section 11.5 of <xref target="I-D.ietf-tsvwg-u
dp-options"></xref>),
this value MAY be used as a hint to
initialise this search to increase the PLPMTU.</t>
<t> Probe packets seeking to increase the PLPMTU SHOULD NOT carr
y application data
("Probing using padding data" in Section 4.1 of <xref target="RF
C8899"></xref>),
since they will be lost whenever their size exceeds the actual P
MTU.
<xref target="RFC8899"></xref> requires a probe packet
to elicit a positive acknowledgement that the path has
delivered a datagram of the specific probed size and, therefore,
when using <xref target="I-D.ietf-tsvwg-udp-options"></xref> a p
robe packet
MUST include the REQ Option.</t>
<t>At the receiver, a received probe packet that does not carry <section numbered="true" toc="default">
application data <name>Sending Probe Packets to Increase the PLPMTU</name>
does not form a part of the end-to-end <t>From time to time, DPLPMTUD enters the SEARCHING state, described
transport data and is not delivered to the Upper Layer protocol in <xref target="RFC8899" sectionFormat="of" section="5.2"/>, (e.g.,
(i.e., application or protocol layered above UDP). A zero-length after expiry of the PMTU_RAISE_TIMER) to detect whether the current
payload path can support a larger PLPMTU. When the remote endpoint advertises
notification could still be delivered to the application, a UDP Maximum Datagram Size (MDS) Option (see <xref
see Section 5 of <xref target="RFC8085"></xref>, although target="RFC9868" sectionFormat="of"
Section 18 of <xref target="I-D.ietf-tsvwg-udp-options"></xref> section="11.5"/>), this value <bcp14>MAY</bcp14> be used as a hint to
initialize this search to increase the PLPMTU.</t>
<t> Probe packets seeking to increase the PLPMTU <bcp14>SHOULD
NOT</bcp14> carry application data (see "Probing using padding data" in
<xref target="RFC8899" sectionFormat="of" section="4.1"/>), since they
will be lost whenever their size exceeds the actual PMTU. <xref
target="RFC8899" format="default"/> requires a probe packet to elicit
a positive acknowledgement that the path has delivered a datagram of
the specific probed size; therefore, a probe packet
<bcp14>MUST</bcp14> include the REQ Option when using transport
options for UDP <xref target="RFC9868" format="default"/>.</t>
<t>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 zero-length payload notification could
still be delivered to the application (see <xref target="RFC8085"
sectionFormat="of" section="5"/>), although
<xref target="RFC9868" sectionFormat="of" section="18"/>
discusses the implications when using UDP Options.</t> discusses the implications when using UDP Options.</t>
</section> <!-- End of Procedures for UDP Options: Increase --> </section>
<section title="Validating the Path with UDP Options">
<t>A PL using DPLPMTUD MUST validate that a path continues to su
pport the
PLPMTU discovered in a previous search for a suitable PLPMTU
value,
as defined in Section 6.1.4 of <xref target="RFC8899"></xref
>.
This validation sends probe packets in the
DPLPMTUD SEARCH_COMPLETE state to detect black-holing of dat
a
(Section 5.2 of <xref target="RFC8899"></xref>, Section 4.3
of <xref target="RFC8899"></xref>
defines a DPLPMTUD black-hole).</t>
<t>Path validation can be implemented within UDP Options by gene <section numbered="true" toc="default">
rating <name>Validating the Path with UDP Options</name>
a probe packet of size PLPMTU, which MUST include a REQ Opti <t>A PL using DPLPMTUD <bcp14>MUST</bcp14> validate that a path
on to elicit a continues to support the PLPMTU discovered in a previous search for a
positive confirmation that the path has delivered this probe suitable PLPMTU value, as defined in <xref target="RFC8899"
packet. sectionFormat="of" section="6.1.4"/>. This validation sends probe
A probe packet used to validate the path MAY use either "Pro packets in the DPLPMTUD SEARCH_COMPLETE state (<xref target="RFC8899" se
bing using padding data" ctionFormat="of" section="5.2"/>) to detect black-holing
to construct a probe packet that does not carry any of data
application data (Section 4.1 of <xref target="RFC8899"></xr (<xref target="RFC8899" sectionFormat="of" section="4.3"/> defines a
ef>) or "Probing using DPLPMTUD black hole).</t>
application data and padding data", see Section 4.1 of <xref <t>Path validation can be implemented within UDP Options by generating
target="RFC8899"></xref>. a probe packet of size PLPMTU, which <bcp14>MUST</bcp14> include a REQ
When using "Probing using padding data", the UDP Options API Option to elicit a positive confirmation that the path has delivered
does not indicate receipt of the this probe packet. A probe packet used to validate the path
zero-length probe packet, see Section 6 of <xref target="I-D <bcp14>MAY</bcp14> use either "Probing using padding data" to
.ietf-tsvwg-udp-options"></xref>. construct a probe packet that does not carry any application data or
</t> "Probing using application data and padding data"; see <xref
</section> <!-- End of Procedures for UDP Options: Validate --> target="RFC8899" sectionFormat="of" section="4.1"/>. When using
"Probing using padding data", the UDP Options API does not indicate
receipt of the zero-length probe packet (see <xref
target="RFC9868" sectionFormat="of" section="6"/>).
</t>
</section>
<section anchor="no-app-data" title="Probe Packets that do not inclu <section anchor="no-app-data" numbered="true" toc="default">
de Application Data"> <name>Probe Packets That Do Not Include Application Data</name>
<t> <t> A simple implementation of the method might be designed to only
A simple implementation of the method might be designed use probe packets in a UDP datagram that includes no application
to only use probe packets in a UDP datagram that includes no data. The size of each probe packet is padded to the required probe
application data. The size of each probe packet is padded to the size including the REQ Option. This implements "Probing using padding
required data" (<xref target="RFC8899" sectionFormat="of" section="4.1"/>) and
probe size including the REQ Option. This implements avoids having to retransmit application data when a probe fails. This
"Probing using padding data" (Section 4.1 of <xref target="RFC88 could be achieved by setting a minimum datagram length, such that the
99"></xref>) options list ends in EOL (<xref target="RFC9868"
and avoids having to retransmit sectionFormat="of" section="11.1"/>) with any additional space
application data when a probe fails. zero-filled as needed (see <xref target="RFC9868"
This could be achieved by setting sectionFormat="of" section="15"/>). In this use, the probe packets do
a minimum datagram length, such that the options list not form a part of the end-to-end transport data and a receiver does
ends in EOL (Section 11.1 of <xref target="I-D.ietf-tsvwg-udp-op not deliver them to the Upper Layer protocol.
tions"></xref>) </t>
with any additional space is zero-filled as needed </section>
(see Section 15 of <xref target="I-D.ietf-tsvwg-udp-options"></x
ref>).
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.
</t>
</section> <!-- End of Procedures for UDP Options: Probe Without Dat
a -=-->
<section title="Probe Packets that include Application Data"> <section numbered="true" toc="default">
<t> <name>Probe Packets That Include Application Data</name>
An implementation always uses the format in <xref target="no-app <t>
-data"></xref> An implementation always uses the format in <xref target="no-app
-data" format="default"/>
when DPLPMTUD searches to increase the PLPMTU.</t> when DPLPMTUD searches to increase the PLPMTU.</t>
<t>
<t>
An alternative format is permitted for a probe packet that is us ed to confirm An alternative format is permitted for a probe packet that is us ed to confirm
the connectivity or to validate the path. the connectivity or to validate the path.
These probe packets MAY carry application data. These probe packets <bcp14>MAY</bcp14> carry application data.
(A UDP payload data is permitted because these probe packets per (UDP payload data is permitted because these probe packets perfo
form rm
black-hole detection black-hole detection
and will, therefore, usually have a higher probability of succes sful and will therefore usually have a higher probability of successf ul
transmission, similar to other packets sent by the Upper Layer p rotocol.) transmission, similar to other packets sent by the Upper Layer p rotocol.)
Section 4.1 of <xref target="RFC8899"></xref> provides a discuss ion of <xref target="RFC8899" sectionFormat="of" section="4.1"/> provid es a discussion of
the merits and demerits of including application data. For examp le, this the merits and demerits of including application data. For examp le, this
reduces the need to send additional datagrams. reduces the need to send additional datagrams.
</t> </t>
<t>This type of probe packet MAY use <t>This type of probe packet <bcp14>MAY</bcp14> use
a control message format defined by the Upper Layer protocol, a control message format defined by the Upper Layer protocol,
provided that the message does not need to provided that the message does not need to
be delivered reliably. The REQ Option MUST be be delivered reliably. The REQ Option <bcp14>MUST</bcp14> be
included when the sending Upper Layer protocol performs DPLPMTUD . included when the sending Upper Layer protocol performs DPLPMTUD .
The DPLPMTUD method tracks the transmission The DPLPMTUD method tracks the transmission
of probe packets (using the REQ Option token).</t> of probe packets (using the REQ Option token).</t>
<t>A receiver that responds to DPLPMTUD <bcp14>MUST</bcp14> process the
<t>A receiver that responds to DPLPMTUD MUST process the REQ Opt REQ Option and
ion and
include the corresponding RES Option with an Upper Layer protoco l message include the corresponding RES Option with an Upper Layer protoco l message
that it returns to the requester (examples of receiver processin g are that it returns to the requester (examples of receiver processin g are
provided in Section <xref target="examples"></xref>).</t> provided in <xref target="examples" format="default"/>).</t>
<t>Probe packets that use this format form a part of the end-to-end
<t>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 transport data and can be used to manage the PLPMTU in just
one direction or can be used for both directions.</t> one direction or can be used for both directions.</t>
</section>
</section>
</section> <!-- End of Procedures for UDP Options: With App Data --> <section numbered="true" toc="default">
</section> <!-- End of Procedures for UDP Options --> <name>Receiving Events from the Network</name>
<t>This specification does not rely upon reception of events from the netw
<section title="Receiving Events from the Network"> ork,
but an implementation can utilize these events when they are provided.</
<t>This specification does not rely upon reception of events from the ne t>
twork, <section numbered="true" toc="default">
but an implementation can utilise these events when they are provided.</ <name>Changes in the Path</name>
t> <t>A change in the path or the loss of a probe packet can result in
DPLPMTUD updating the PLPMTU. DPLPMTUD <xref target="RFC8899"
<section title="Changes in the Path"> format="default"/> recommends that methods are robust to path changes
<t>A change in the path or the loss of a probe packet can result in that could have occurred since the path characteristics were last
DPLPMTUD updating confirmed and to the possibility of inconsistent path information
the PLPMTU. DPLPMTUD being received. For example, a notification that a path has changed
<xref target="RFC8899"></xref> recommends that methods are robust to could trigger path validation to provide black-hole protection (<xref
path changes target="RFC8899" sectionFormat="of" section="4.3"/>).</t>
that could have occurred since the path characteristics were last <t>An Upper Layer protocol could trigger DPLPMTUD to validate the path
confirmed and to the possibility of inconsistent path information be when it observes a high packet loss rate (or a repeated protocol
ing timeout) <xref target="RFC8899" format="default"/>.</t>
received. For example, a notification that a path has changed could <t><xref target="RFC8899" sectionFormat="of" section="3"/> requires
trigger path validation to provide black-hole protection any methods designed to share the PLPMTU between PLs (such as updating
(Section 4.3 of <xref target="RFC8899"></xref>).</t> the IP cache PMTU for an interface/destination) to be robust to the
wide variety of underlying network forwarding behaviors. For example,
<t>An Upper Layer protocol could trigger DPLPMTUD to validate the pa an implementation could avoid sharing PMTU information that could
th potentially relate to packets sent with the same address over a
when it observes a different interface.</t>
high packet loss rate (or a repeated protocol timeout) <xref target= </section>
"RFC8899"></xref>.</t>
<t>Section 3 of <xref target="RFC8899"></xref> 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 underlyin
g
network forwarding behaviors. For example, an implementation could a
void
sharing PMTU information that could potentially relate to packets se
nt
with the same address over a different interface.</t>
</section> <!-- End of Path Changes -->
<section title="Validation of PTB Messages"> <section numbered="true" toc="default">
<t> Support for receiving ICMP PTB messages is <name>Validation of PTB Messages</name>
OPTIONAL for DPLPMTUD. A UDP Options sender <t> Support for receiving ICMP PTB messages is
<bcp14>OPTIONAL</bcp14> for DPLPMTUD. A UDP Options sender
can therefore ignore received ICMP PTB messages.</t> can therefore ignore received ICMP PTB messages.</t>
<t>Before processing an ICMP PTB message, the
<t>Before processing an ICMP PTB message the DPLPMTUD method needs to perform two checks to ensure
DPLPMTUD method needs to perform two checks that the message was received
that the messgage was received
in response to a sent probe packet:</t> in response to a sent probe packet:</t>
<list style="symbols"> <ul spacing="normal">
<t>DPLPMTUD first utilises the quoted information in each PTB mess <li>
age. <t>DPLPMTUD first utilizes the quoted information in each PTB
The receiver MUST validate the protocol information in the quoted message. The receiver <bcp14>MUST</bcp14> validate the protocol
packet information in the quoted packet carried in an ICMP PTB message
carried in an ICMP PTB message payload to validate the message payload to validate the message originated from the sending node
originated from the sending node (see Section 4.6.1 of (see <xref target="RFC8899" sectionFormat="of"
<xref target="RFC8899"></xref>).</t> section="4.6.1"/>).</t>
<t>The receiver SHOULD utilize information that is not simple for </li>
an <li>
off-path attacker to determine (see Section 4.6.1 of <t>The receiver <bcp14>SHOULD</bcp14> utilize information that is
<xref target="RFC8899"></xref>). not simple for an off-path attacker to determine (see
Specifically, a UDP Options receiver SHOULD confirm that <xref target="RFC8899" sectionFormat="of" section="4.6.1"/>).
the token contained in the UDP REQ Option of the quoted packet Specifically, a UDP Options receiver <bcp14>SHOULD</bcp14> confirm
has a value that corresponds to a probe packet that was recently that the token contained in the UDP REQ Option of the quoted
sent by the current endpoint.</t> packet has a value that corresponds to a probe packet that was
</list> recently sent by the current endpoint.</t>
<t>An </li>
implementation unable to support this validation MUST ignore </ul>
<t>An
implementation unable to support this validation <bcp14>MUST</bcp14>
ignore
received ICMP PTB messages.</t> received ICMP PTB messages.</t>
</section> <!-- End of PTB --> </section>
</section> <!-- End of Network Events -->
<section anchor="examples" title="Examples with Different Receiver Behaviors "> </section>
<t> When enabled, a DPLPMTUD endpoint that implements UDP Options <section anchor="examples" numbered="true" toc="default">
<name>Examples with Different Receiver Behaviors</name>
<t> When enabled, a DPLPMTUD endpoint that implements UDP Options
normally responds with a normally responds with a
UDP datagram with a RES Option when requested by a sender.</t> UDP datagram with a RES Option when requested by a sender.</t>
<t>The following examples describe various possible receiver behaviors:</t
<t>The following examples describe various possible receiver behaviors:< >
/t> <ul spacing="normal">
<list style="symbols"> <li>
<t>(No DPLPMTUD receiver support) <t>No DPLPMTUD receiver support:
One case is when a sender supports this specification, One case is when a sender supports this specification,
but no RES Option is received from the remote endpoint. but no RES Option is received from the remote endpoint.
In this example, the method In this example, the method
is unable to discover the PLPMTU. This will result in using the is unable to discover the PLPMTU. This will result in using the
minimum configured PLPMTU (MIN_PLPMTU). MIN_PLPMTU.
Such a remote endpoint might be not configured to process UDP Option Such a remote endpoint might be not configured to process UDP Option
s, or s or
might not return a datagram with a RES Option for some other reason might not return a datagram with a RES Option for some other reason
(packet loss, insufficient space (e.g., packet loss, insufficient space
to include the option, filtering on the path, etc).</t> to include the option, filtering on the path, etc.).</t>
</li>
<t>(DPLPMTUD receiver uses application datagrams) <li>
<t>DPLPMTUD receiver uses application datagrams:
In a second case, both the sender and receiver In a second case, both the sender and receiver
support DPLPMTUD using the specification, support DPLPMTUD using the specification,
and the receiver only returns a RES Option with the next UDP datagra m and the receiver only returns a RES Option with the next UDP datagra m
that is sent to the requester. that is sent to the requester.
Therefore, reception of a REQ Option does not systematically trigger a response. Therefore, reception of a REQ Option does not systematically trigger a response.
This allows DPLPMTUD to operate when there is a flow of datagrams in both directions, This allows DPLPMTUD to operate when there is a flow of datagrams in both directions,
providing there is periodic feedback (e.g., one acknowledgement pack et per RTT). provided there is periodic feedback (e.g., one acknowledgement packe t per RTT).
It requires the PLPMTU at the receiver It requires the PLPMTU at the receiver
to be sufficiently large that the RES option can be included in the feedback packets to be sufficiently large enough that the RES Option can be included in the feedback packets
that are sent in the return direction. that are sent in the return direction.
This method avoids opportunities to misuse the method as a DoS attac k. This method avoids opportunities to misuse the method as a DoS attac k.
However, when there is a low However, when there is a low
rate of transmission (or no datagrams are sent) in the return direct ion, rate of transmission (or no datagrams are sent) in the return direct ion,
this will prevent prompt delivery of the RES Option. this will prevent prompt delivery of the RES Option.
At the DPLPMTUD sender, this results in probe packets failing to be At the DPLPMTUD sender, this results in probe packets failing to be
acknowledged in time, acknowledged in time
and could result in a smaller PLPMTU than is actually supported by and could result in a smaller PLPMTU than is actually supported by
the path or in using the minimum configured PLPMTU (MIN_PLPMTU).</t> the path or in using the MIN_PLPMTU.</t>
</li>
<t>(Uni-directional transfer) Another case is where an application o <li>
nly transfers data <t>Unidirectional transfer: Another case is where an application only
transfers data
in one direction (or predominantly in one direction). in one direction (or predominantly in one direction).
In this case the wait at the receiver for a datagram to be queued be fore In this case, the wait at the receiver for a datagram to be queued b efore
returning a RES Option could easily result in a probe timeout returning a RES Option could easily result in a probe timeout
at the DPLPMTUD sender. at the DPLPMTUD sender.
In this case, DPLPMTUD could allow exchanging datagrams without In this case, DPLPMTUD could allow exchanging datagrams without
a payload (as discussed in earlier sections) to return the RES Optio n.</t> a payload (as discussed in earlier sections) to return the RES Optio n.</t>
</li>
<t>(DPLPMTUD Receiver permitted to send responses in UDP datagrams w <li>
ith no payload) <t>DPLPMTUD receiver permitted to send responses in UDP datagrams with
no payload:
A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data) A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data)
solely to return a RES Option 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 have This would allow an endpoint to probe the set of UDP ports that have
been configured with support for this specification been configured with support for this specification
using a DPLPMTUD probe packet. using a DPLPMTUD probe packet.
Although this results in some additional traffic overhead, Although this results in some additional traffic overhead,
it has the advantage that it it has the advantage that it
can ensure timely progress of DPLPMTUD. can ensure timely progress of DPLPMTUD.
Section <xref target="formats"></xref> specifies: "If a UDP Options <xref target="formats" format="default"/> specifies: "If a UDP Optio
endpoint creates and ns endpoint creates and
sends a datagram with a RES option solely as response to a received sends a datagram with a RES Option solely as response to a received
REQ Option, REQ Option,
the responder MUST limit the rate of these responses the responder <bcp14>MUST</bcp14> limit the rate of these responses
(e.g., limiting each pair of ports to send 1 per RTT or 1 per second (e.g., limiting each pair of ports to send 1 per measured RTT or 1 p
)". er second)".
This rate limit is to mitigate the DoS vector, without significantly impacting This rate limit is to mitigate the DoS vector, without significantly impacting
the operation of DPLPMTUD.</t> the operation of DPLPMTUD.</t>
</list> </li>
</section> <!-- End of examples --> </ul>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Gorry Fairhurst and Tom Jones are supported by funding provided b
y
the University of Aberdeen. The editors would like to thank Magnus W
esterlund
and Mohamed Boucadair for their detailed comments and also other peo
ple
who contributed to completing this document.</t>
</section> <!-- End of acknowledgements -->
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t>This memo includes no requests to IANA.</t> <name>IANA Considerations</name>
</section> <!-- End of IANA --> <t>This document has no IANA actions.</t>
</section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<t>The security considerations for using UDP Options are described i <name>Security Considerations</name>
n <t>The security considerations for using UDP Options are described in
<xref target="I-D.ietf-tsvwg-udp-options"></xref>. The <xref target="RFC9868" format="default"/>. The
method does not change the integrity protection offered by the UDP method does not change the integrity protection offered by the UDP
options method.</t> Options method.</t>
<t>The security considerations for using DPLPMTUD are described in <xref t
<t>The security considerations for using DPLPMTUD are described in < arget="RFC8899" format="default"/>. On-path attackers could maliciously drop
xref or modify probe packets to seek to decrease the PMTU or
target="RFC8899"></xref>. On path attackers could maliciously dr
op
or modify probe packets to seek to decrease the PMTU, or
to maliciously modify probe packets in an attempt to black-hole traf fic.</t> to maliciously modify probe packets in an attempt to black-hole traf fic.</t>
<t>The specification recommends that the token value in the REQ Option is
<t>The specification recommends that the token value in the REQ Opti initialized to a randomized value. This is to enhance protection fro
on is m off-path
initialised to a randomised value. This is to enhance protection fro
m off-path
attacks. attacks.
If a subsequent probe packet uses a token value that is easily deriv ed If a subsequent probe packet uses a token value that is easily deriv ed
from the initial value, from the initial value
(e.g., incrementing the value) a misbehaving on-path observer could (e.g., incrementing the value), a misbehaving on-path observer could
then 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 observer. 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 This would allow probe packets to be forged, with an impact similar to other on-path
attacks against probe packets. attacks against probe packets.
This attack could be mitigated by using an unpredictable This attack could be mitigated by using an unpredictable
token value for each probe packet.</t> token value for each probe packet.</t>
<t>The method does not change the
<t>The method does not change the
ICMP PTB message validation method described by DPLPMTUD: A UDP Opti ons ICMP PTB message validation method described by DPLPMTUD: A UDP Opti ons
sender that utilises ICMP PTB messages received to a probe packet MU ST sender that utilizes ICMP PTB messages received to a probe packet <b cp14>MUST</bcp14>
use the quoted packet to validate the UDP port information in use the quoted packet to validate the UDP port information in
combination with the token contained in the UDP combination with the token contained in the UDP
Option, before processing the packet using the DPLPMTUD method.</t> Option before processing the packet using the DPLPMTUD method.</t>
<t>Upper Layer protocols or applications that employ encryption
<t>Upper Layer protocols or applications that employ encryption
ought to perform DPLPMTUD ought to perform DPLPMTUD
at a layer above UDP Options, and not enable UDP Options support for 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 cont rol the additional This allows the application to control when DPLPMTUD is used to cont rol the additional
traffic that this generates. traffic that this generates.
This also ensures that DPLPMTUD probe packets are encrypted.</t> This also ensures that DPLPMTUD probe packets are encrypted.</t>
</section> <!-- End of Sec Considerations --> </section>
</middle> </middle>
<back> <back>
<!-- References split into informative and normative -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.2119.xml"?-->
&RFC768;
&RFC2119;
&RFC8174;
&RFC8899;
&I-D.ietf-tsvwg-udp-options;
</references>
<references title="Informative References">
&RFC1191;
&RFC4821; <references>
<name>References</name>
&RFC8085; <references>
<name>Normative References</name>
&RFC8201; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
768.xml"/>
&RFC8304; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<section title="Revision Notes"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>XXX Note to RFC-Editor: please remove this entire section prior t 899.xml"/>
o
publication. XXX</t>
<t>Individual draft-00.</t>
<t><list style="symbols">
<t>This version contains a description for consideration and com
ment
by the TSVWG.</t>
</list></t>
<t>Individual draft-01.</t>
<list style="symbols">
<t>Address Nits</t>
<t>Change Probe Request and Probe Reponse options to Echo to ali
gn
names with draft-ietf-tsvwg-udp-options</t>
<t>Remove Appendix B, Informative Description of new UDP Options
</t>
<t>Add additional sections around Probe Packet generation</t>
</list>
<t>Individual draft-02.</t>
<t><list style="symbols">
<t>Address Nits</t>
</list>Individual draft-03.</t>
<t><list style="symbols">
<t>Referenced DPLPMTUD RFC.</t>
<t>Tidied language to clarify the method.</t>
</list>Individual draft-04</t>
<t><list style="symbols">
<t>Reworded text on probing with data a little</t>
<t>Removed paragraph on suspending ICMP PTB suspension.</t>
</list>Working group draft-00</t>
<t><list style="symbols">
<t>-00 First Working Group Version</t>
<t>RFC8899 call search_done SEARCH_COMPLETE, fixed.</t>
</list></t>
<t>Working group draft -01</t>
<t><list style="symbols">
<t>Update to reflect new fragmentation design in UDP Options.</t <reference anchor="RFC9868" target="https://www.rfc-editor.org/info/rfc9868">
> <front>
<t>Add a description of uses of DPLPMTUD with UDP Options.</t> <title>Transport Options for UDP</title>
<t>Add a description on how to form probe packets with padding.< <author initials="J." surname="Touch" fullname="Dr. Joseph D. Touch">
/t> <organization>Independent Consultant</organization>
<t>Say that MSS options can be used to initialise the search alg </author>
orithm.</t> <author initials="C." surname="Heard" fullname="C. M. Heard" role="editor"
<t>Say that the recommended approach is to not use user data for >
probes.</t> <organization>Unaffiliated</organization>
<t>Attempts to clarify and improve wording throughout.</t> </author>
<t>Remove text saying you can respond to multiple probes in a si <date month="October" year="2025"/>
ngle packet.</t> </front>
<t>Simplified text by removing options that don't yield benefit. <seriesInfo name="RFC" value="9868"/>
</t> <seriesInfo name="DOI" value="10.17487/RFC9868"/>
</reference>
</list></t> </references>
<t>Working group draft -02</t> <references>
<t><list style="symbols"> <name>Informative References</name>
<t>Update to reflect comments from MED.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<t>More consistent description of DPLPMTUD with UDP Options.</t> 191.xml"/>
<t>Clarify the nonce value (token) is intended per 5-tuple, not <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
interface.</t> 821.xml"/>
<t>BASE_PLPMTU related to RFC8899.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<t>Probes with user data can carry application control data.</t> 85.xml"/>
<t>Added that application data uses RES and REQ nonce (token) va <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
lues from the app.</t> 201.xml"/>
<t>QUIC was intended as an informational reference to an example <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
of RFC8899.</t> 304.xml"/>
</list></t> </references>
<t>Working group draft -03</t> </references>
<t><list style="symbols">
<t>Update to reflect more comments from MED.</t>
<t>Again more consistent description of DPLPMTUD with UDP Option
s.</t>
<t>Clarify token/nonce to use token. </t>
<t>Clarify any use of application data for black-hole detection.
</t>
<t>Minor changes to reflect update to UDP Options base spec.</t>
</list></t>
<t>Working group draft-04.</t>
<t><list>
<t>Update for WG Last Call</t>
</list></t>
<t>Working group draft-05.</t>
<t><list>
<t>Update following WG Last Call</t>
</list></t>
<t>Working group draft-06.</t>
<t><list>
<t>Tidy text after WG Last Call, based on review by Med.</t>
<t>Added text after WG Last Call, based on review by Magnus.</t>
<t>Added text after WG Last Call, based on comments by Joe and M
ike.</t>
<t>Restructured to integrate the WGLC new text.</t>
</list></t>
<t>Working group draft-07.</t>
<t><list>
<t>Mention of UDP-Options in Intro, from a review by Med.</t>
<t>Resolve typo, from review by Magnus.</t>
</list></t>
<t>Working group draft-08.</t>
<t><list>
<t>Corrections following a review by Mike Heard.</t>
</list></t>
<t>Working group draft-09.</t>
<t><list>
<t>Corrections following a review by Erik Auerswald and others.<
/t>
</list></t>
<t>Working group draft-10.</t>
<t><list>
<t>Corrections following a review by Erik Auerswald.</t>
</list></t>
<t>Working group draft-11.</t>
<t><list>
<t>Revised data - waiting for UDP Options to complete.</t>
</list></t>
<t>Working group draft-11.</t>
<t>Editorial corrections to align section numbers in referenced RFCs
/I-Ds and minor editorial improvements.</t>
<t>Working group draft -12, -13.</t>
<t><list>
<t>Editorial corrections preparing for WGLC.</t>
</list></t>
<t>Working group draft -14.</t>
<t><list>
<t>Updated after INT and SEC reviews.</t>
</list></t>
<t>Working group draft -15.</t>
<t><list>
<t>Updated after IESG comments.</t>
</list></t>
</section> <section anchor="Acknowledgements" numbered="false" toc="default">
</back> <name>Acknowledgements</name>
<t><contact fullname="Gorry Fairhurst"/> and <contact fullname="Tom
Jones"/> are supported by funding provided by the University of
Aberdeen. The authors would like to thank <contact fullname="Magnus
Westerlund"/> and <contact fullname="Mohamed Boucadair"/> for their
detailed comments and also other people who contributed to completing
this document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 113 change blocks. 
788 lines changed or deleted 595 lines changed or added

This html diff was produced by rfcdiff 1.48.