<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
 which is available here: http://xml.resource.org. --> version='1.0' encoding='UTF-8'?>

<!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/reference.RFC.0768.xml">
<!ENTITY RFC1191 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"> nbsp    "&#160;">
  <!ENTITY RFC8085 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml">
<!ENTITY RFC8304 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8304.xml">
<!ENTITY RFC8899 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.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"> wj     "&#8288;">
]>
<!-- ?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-tsvwg-udp-options-dplpmtud-15"
    ipr="trust200902">
    <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
     or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

    <!-- ***** FRONT MATTER ***** --> number="9869" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
        <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
        <title abbrev="UDPO abbrev="UDP Options with DPLPMTUD">Datagram PLPMTUD Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options</title>

        <!-- add 'role="editor"' below for the editors if appropriate -->

        <!-- Another author who claims to be an editor -->
    <seriesInfo name="RFC" value="9869"/>
        <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School of Engineering</street>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>
                    <region></region>
          <code>AB24 3UE</code>
                    <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>gorry@erg.abdn.ac.uk</email>
      </address>
    </author>
    <author fullname="Tom Jones" initials="T" surname="Jones">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School of Engineering</street>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>
                    <region></region>
          <code>AB24 3UE</code>
                    <country>UK</country>
                    <country>UK</country>
          <country>United Kingdom</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> month="September" year="2025"/>

    <area>WIT</area>
    <workgroup>tsvwg</workgroup>

    <keyword>UDP</keyword>
    <keyword>UDP-Options</keyword>
    <keyword>PMTUD</keyword>
    <keyword>PLPMTUD</keyword>
    <keyword>DPLPMTUD</keyword>
    <keyword>Datagram</keyword>

    <abstract>
      <t>This document specifies how a UDP Options sender implements Datagram
      Packetization Layer Path Maximum Transmission Unit MTU Discovery (DPLPMTUD)
      as a robust method for Path Maximum Transmission Unit discovery. 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 Maximum Packet Size (MPS) supported by a
      path and to update this when required.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The User Datagram Protocol (UDP) <xref target="RFC0768"></xref> target="RFC0768" format="default"/> offers a
            minimal transport service on top of IP and is frequently used as a
            substrate for other protocols. Section 3.2 <xref target="RFC8085" sectionFormat="bare" section="3.2"/> of UDP Guidelines <xref
            target="RFC8085"></xref> target="RFC8085" format="default"/> recommends that applications implement some
            form of Path MTU discovery Discovery (PMTUD) to avoid the generation of IP fragments:</t>

            <t>"Consequently,
      <blockquote>Consequently, an application SHOULD <bcp14>SHOULD</bcp14> either use the path MTU
            information provided by the IP layer or implement Path MTU Discovery
            (PMTUD)".</t>
            (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the
   path to a destination will support its desired message size without
   fragmentation.</blockquote>
      <t>The UDP API <xref target="RFC8304"></xref> target="RFC8304" format="default"/> offers calls for
            applications to receive ICMP Packet Too Big (PTB) messages and to
            control the maximum size of datagrams that are sent, but it does not offer
            any automated mechanisms for an application to discover the maximum
            packet size MPS
            supported by a path. Upper Layer protocols, which
            includes
            include applications, can
            implement mechanisms for Path MTU discovery PMTUD above the UDP API.</t>
      <t>Packetization Layer Path MTU Discovery (PLPMTUD) <xref target="RFC4821"></xref> target="RFC4821" format="default"/>
            describes a method for a bi-directional bidirectional Packetization Layer (PL)
            to search for the largest Packetization Layer PMTU (PLPMTU) supported on
            a path. Datagram PLPMTUD (DPLPMTUD) DPLPMTUD <xref target="RFC8899"></xref> target="RFC8899" format="default"/>
            specifies this support for datagram transports. PLPMTUD and DPLPMTUD
            gain robustness by using a probing mechanism that does not solely rely on
            ICMP PTB messages and works on paths that drop ICMP PTB messages.</t>
      <t>UDP Options <xref target="I-D.ietf-tsvwg-udp-options"></xref> target="RFC9868" format="default"/> supplies
            functionality that can be used to implement DPLPMTUD within the
            transport service or in an Upper Layer protocol (including an application)
            that uses UDP Options.
            This document specifies how DPLPMTUD using UDP Options
            is implemented (Section 6.1 of <xref target="RFC8899"></xref>), (<xref target="RFC8899" sectionFormat="of" section="6.1"/>)
            and requires support to be enabled at both the sender and receiver.
      </t>
      <t>Implementing DPLPMTUD within the
            transport service above UDP Options avoids the need for
            each Upper Layer protocol to implement the DPLPMTUD
            method. It provides a standard method for applications to discover the
            current maximum packet size MPS for a path and to detect when this
            changes. It can be used with Equal-Cost Multipath (ECMP) routing
           and/or multihoming. If multipath or multihoming is supported,
           a state machine is needed for each path.</t>
      <t>DPLPMTUD is not specified for multicast. The method requires
           explicit acknowledgment acknowledgement of probe packets provided by UDP Options,
           which is primarily intended for unicast use (see Section  23 of
           <xref target="I-D.ietf-tsvwg-udp-options"></xref>).</t>

        </section><!-- End of Intro --> target="RFC9868" sectionFormat="of" section="23"/>).</t>
    </section>
    <section title="Terminology">
            <t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
            "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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
            "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
            BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
            <t>
            This here.
        </t>

      <t>This document uses the terms defined for DPLPMTUD (Sections 2 <xref
      target="RFC8899" sectionFormat="bare" section="2"/> and 5 <xref
      target="RFC8899" sectionFormat="bare" section="5"/> of <xref target="RFC8899"></xref>).
      target="RFC8899" format="default"/>).
      </t>
    </section> <!-- End of terms -->
        <section title="DPLPMTUD numbered="true" toc="default">
      <name>DPLPMTUD for UDP Options"> Options</name>
      <t>A UDP Options sender implementing DPLPMTUD uses the method specified
            in <xref target="RFC8899"></xref>. target="RFC8899" format="default"/>. In this specification, DPLPMTUD is
            realised
            realized using a pair of
            UDP Options:
            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
            (Section 11.1 of  <xref target="I-D.ietf-tsvwg-udp-options"></xref>)
            (<xref target="RFC9868" sectionFormat="of" section="11.1"/>) to
            introduce padding to set the size of a probe packet.</t>
      <t>Use of DPLPMTUD MUST <bcp14>MUST</bcp14> be explicitly enabled by the application, for instance instance,
            once an application has established connectivity and is ready
            to exchange data with the remote Upper Layer protocol.
            Similarly, a DPLPMTUD receiver MUST NOT <bcp14>MUST NOT</bcp14> respond to a UDP REQ
            Option until DPLPMTUD has been enabled. This is to help
            protect from mis-use misuse of the mechanism for other forms of probing.</t>
      <t>Probe packets consume network capacity and incur endpoint
            processing (Section 4.1 of <xref target="RFC8899"></xref>). (<xref target="RFC8899" sectionFormat="of" section="4.1"/>).
            Implementations ought to send a probe packet with a UDP REQ
            Option only when required by their local DPLPMTUD state machine,
            i.e., when confirming the base PMTU for the path,
            probing to increase the PLPMTU, or to confirm confirming the current
            PLPMTU.</t>
      <t>DPLPMTUD can be implemented
            over UDP Options in two ways:</t>
             <list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Implementation within the UDP transport service;</t> service.</t>
        </li>
        <li>
          <t>Implementation in an Upper Layer protocol (or application) that uses UDP Options.</t>
            </list>
        </li>
      </ul>
      <t>When DPLPMTUD is implemented within the UDP
            transport service, the DPLPMTUD state machine
            is responsible for sending probe packets to determine a PLPMTU, as described
            in this document (and hence the Maximum Packet Size (MPS), document. This determines an MPS,
            the largest size of application data block that can be sent across a network path
            using a single datagram). datagram. The Upper Layer protocol is responsible for deciding
            when a session enables DPLPMTUD.</t>
      <t>The discovered PLPMTU can be used to either:</t>

            <list style="symbols">
      <ul spacing="normal">
        <li>
          <t> set the maximum datagram size for the current path;</t> path or</t>
        </li>
        <li>
          <t> set the maximum fragment size when a sender uses the
                    UDP Fragmentation Option to divide a datagram into
                    multiple UDP fragments for transmission. The size of each UDP fragment
                    is then less than or equal to the size of the discovered largest IP packet that can
                    be received across the current path.
          </t>
            </list>
        </li>
      </ul>
      <t>The figure below shows an implementation of DPLPMTUD within the UDP
            transport service.
            It illustrates key interactions between the layers.
            This design requires an API primitive to allow the application to
            control whether the DPLPMTUD state machine is enabled for a specific
      UDP port. By default, this API MUST <bcp14>MUST</bcp14> disable DPLPMTUD processing.</t>

            <figure>

	<artset>
	  <artwork align="left">
                    <![CDATA[ type="svg">
	  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="352" width="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" transform="rotate(90,232,336)"/>
<polygon class="arrowhead" points="240,248 228,242.4 228,253.6" fill="black" transform="rotate(90,232,248)"/>
<polygon class="arrowhead" points="240,104 228,98.4 228,109.6" fill="black" transform="rotate(90,232,104)"/>
<polygon class="arrowhead" points="48,296 36,290.4 36,301.6" fill="black" transform="rotate(270,40,296)"/>
<polygon class="arrowhead" points="48,200 36,194.4 36,205.6" fill="black" transform="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      |
|         or Application         |
+---------------------------+----+
    ^                       | Messages (with UDP Options)
    | receive         send  v Primitives for MPS, Min_PMTU Min_PMTU, etc.
+---+----------------------------+
| DPLPMTUD State Machine         |
|   Maximum Packet Size (MPS)    |
|   PLPMTU, Probed-Size,Min_PMTU | Probed-Size, Min_PMTU|
|   Token Values & Probes, etc.  |
+---------------------------+----+
    ^                       | Messages (with UDP Options)
    |                       |   Send/Receive: Probes with Options
    | receive         send  v   Events: ICMP, Interface MTU, etc.
+---+----------------------------+
| UDP Options Transport          |
+---------------------------+----+
    ^                       | Datagrams (with UDP Options)
    |                       |   Fragmented Datagrams with UDP Options
    | receive         send  v   Events: ICMP, Interface MTU, etc.
    ]]></artwork>
</figure>
    </artset>
      <t>Note: UDP allows an Upper Layer Protocol protocol
            to send datagrams with or without payload data (with or without
            UDP Options). These
            are delivered across the network to the remote Upper Layer.
            When DPLPMTUD is implemented within the UDP
            transport service, probe 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 sending
            application and therefore
            application; therefore, the corresponding received datagrams are
            not delivered to the remote application.</t>
      <t>When DPLPMTUD is instead implemented by an Upper Layer protocol,
            the format and content
            of probe packets are determined by the Upper Layer protocol.
            This design is also permitted to use the REQ and RES Options
            provided by UDP Options.</t>
      <t>If DPLPMTUD is active at more than one layer,
            then the values of the tokens used in REQ Options need to be coordinated
            with any values used for other DPLPMTUD probe packets to ensure
            that each probe packet can be identified by a unique token.
            When configurable, a configuration ought to avoid
            performing such discovery both within UDP Options
            and also by an upper Upper Layer protocol layer
            that sends and receives probe packets via UDP Options.
            Section 6.1 of
            <xref target="RFC8899"></xref> target="RFC8899" sectionFormat="of" section="6.1"/> recommends that:
            "An application SHOULD <bcp14>SHOULD</bcp14> avoid using DPLPMTUD when the underlying
            transport system provides this capability."</t>
      <section anchor="formats" title="Packet Formats"> numbered="true" toc="default">
        <name>Packet Formats</name>
        <t>The UDP Options used in this document are described in
                <xref target="I-D.ietf-tsvwg-udp-options"></xref> target="RFC9868" format="default"/> and are used
                in the following way:</t>

                <list style="symbols"> ways:</t>
        <ul spacing="normal">
          <li>
            <t>The REQ Option is set by a sending PL to solicit a response from a
                    remote receiver. A four-byte (four octet) (four-octet) token identifies each request.</t>
          </li>
          <li>
            <t>A sending PL can use the EOL option Option together with a minimum
                    datagram length to pad probe packets.</t>
          </li>
          <li>
            <t>The RES Option is sent by a UDP Options receiver in response to a
                    previously received REQ Option. Each RES Option echoes the last received
                    four-byte token.</t>
          </li>
          <li>
            <t> If a UDP Options  endpoint creates and sends a datagram
                    with a RES option Option solely as response to a received REQ Option,
                    the responder MUST <bcp14>MUST</bcp14> 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 limit is to mitigate the DoS vector, vector
                    without significantly impacting the operation of DPLPMTUD.
                    An example in Section <xref target="examples"></xref> target="examples" format="default"/>
                    describes a case where this might be used.</t>
          </li>
          <li>
            <t>
                    Reception of a RES Option by the REQ sender confirms that a specific
                    probe packet has been received by the remote UDP Options receiver.</t>
            </list>
          </li>
        </ul>
        <t>The token allows a UDP Options sender to distinguish
            between acknowledgements for initial probe packets and
            acknowledgements confirming receipt of subsequent probe packets
            (e.g., travelling along alternate paths with a larger round-trip
            time). RTT).
            Each probe packet MUST <bcp14>MUST</bcp14> be uniquely
            identifiable by the UDP Options sender within the Maximum Segment
            Lifetime (MSL) <xref target="RFC8085"></xref>. target="RFC8085" format="default"/>.
            The UDP Options sender MUST NOT <bcp14>MUST NOT</bcp14> reuse
            a token value within the MSL. A
            four byte
            four-byte value for the token field provides sufficient space for
            multiple unique probe packets to be made within the MSL. Since UDP Options
            operates over UDP, the token values only need to be unique for
            the specific 5-tuple over which it is operating.
        </t>
        <t>The value of the four-byte token field SHOULD <bcp14>SHOULD</bcp14> be initialised initialized
            to a randomised randomized value to enhance protection from off-path attacks,
            as described in Section 5.1 of <xref target="RFC8085"></xref>.</t> target="RFC8085" sectionFormat="of" section="5.1"/>.</t>
      </section> <!-- End of DPLPMTUD for UDP Options:Formats -->

        <section title="Sending numbered="true" toc="default">
        <name>Sending Probe Packets with the Request Option"> Option</name>
        <t>DPLPMTUD relies upon sending a probe packet
            with a specific size.
            Each probe packet includes the UDP Options area containing
            a REQ Option
            and any other required options concluded with an EOL Option
            (Section 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>
        <t>A probe packet can therefore be of size up to the maximum size
            supported by the local interface (i.e., the Interface MTU).
            Item 2 in <xref target="RFC8899"></xref> (Section 3, item 2) section="3" target="RFC8899" format="default"/> requires the network interface
            below DPLPMTUD to provide a way to transmit a probe packet
            that is larger than the current PLPMTU.
            The size of this probe packet MUST NOT <bcp14>MUST NOT</bcp14> be constrained by the maximum PMTU
            set by network layer mechanisms (such as discovered by PMTUD
            <xref target="RFC1191"></xref><xref target="RFC8201"></xref> target="RFC1191" format="default"/><xref target="RFC8201" format="default"/> or the PMTU size
            held in the IP-layer cache),
            as noted in bullet item 2 of Section 3 in <xref target="RFC8899"></xref>).</t> target="RFC8899" sectionFormat="of" section="3"/>).</t>
        <t>UDP datagrams used as DPLPMTUD probe packets, as described in this
            document, MUST NOT <bcp14>MUST NOT</bcp14> be fragmented at the UDP or IP layer.
            Section 3 of
            Therefore, <xref target="RFC8899"></xref>
            therefore target="RFC8899" sectionFormat="of" section="3"/>
            requires: "In IPv4, a probe packet MUST <bcp14>MUST</bcp14> be sent with the
            Don't Fragment (DF) bit set in the IP header and without network layer
            endpoint fragmentation."</t>
      </section>    <!-- End of DPLPMTUD for UDP Options:sending -->

        <section title="Receiving UDP-Options numbered="true" toc="default">
        <name>Receiving UDP Options Probe Packets and sending Sending the RES Option"> Option</name>
        <t>When DPLPMTUD is enabled, a UDP Options receiver responds
            by sending a UDP datagram with the RES Option when
            it receives a UDP Options datagram with
            the REQ Option.</t>
        <t>The operation of DPLPMTUD can depend on the support at
            the remote UDP Options endpoint, the way in which DPLPMTUD
            is implemented implemented, and in some cases cases, the application data that is
            exchanged over the UDP transport service.
            When UDP Options is not supported by the remote receiver,
            DPLPMTUD will be unable to confirm the path or to discover the PLPMTU.
            This will result in the minimum configured PLPMTU (MIN_PLPMTU).
            More explanation of usage is provided in <xref target="examples"></xref>. target="examples" format="default"/>.
        </t>
        <t>Note: A receiver that only responds when there is a datagram
            queued for transmission by the Upper Layer could potentially
            receive multiple datagrams with a REQ Option before it can
            respond. When sent, the RES Option will only acknowledge the
            latest received token value. A sender would then conclude
            that any earlier REQ Options were not successfully received.
            However, DPLPMTUD does not usually result in sending more than one
            probe packet per timeout interval, and a delay in responding
            will already have been treated as a failed probe attempt.
            Therefore, this does not significantly impact performance,
            although a more prompt response would have resulted in
            DPLPMTUD recording reception of all probe packets.</t>
      </section> <!-- End of DPLPMTUD for UDP Options:Receiving -->
    </section> <!-- End of DPLPMTUD for UDP Options -->

    <section anchor="UDPOPT-PLPMTUD" title="DPLPMTUD numbered="true" toc="default">
      <name>DPLPMTUD Sender Procedures for UDP Options"> Options</name>
      <t> DPLPMTUD utilises utilizes three types of probe. These are described in the following sections:</t>
            <list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Probes to confirm the path can support the BASE_PLPMTU (Section 5.1.4 of <xref
                    target="RFC8899"></xref>).</t> (<xref target="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>
            </list>
        </li>
      </ul>
      <section title="Confirmation numbered="true" toc="default">
        <name>Confirmation of Connectivity across Across a Path"> Path</name>
        <t>The DPLPMTUD method requires a PL to confirm connectivity over the
        path (Section 5.1.4 of <xref
                        target="RFC8899"></xref>), (<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 MUST <bcp14>MUST</bcp14> elicit a positive
                    confirmation of connectivity for the path, path by sending a probe packet, packet
                    padded to size BASE_PLPMTU. This confirmation probe MUST <bcp14>MUST</bcp14>
                    include the REQ UDP Option to elicit a response from the remote DPLPMTUD.
                    Reception of a datagram with the corresponding RES Option confirms
                    the reception of a packet of the probed size that has successfully
                    traversed the path to the receiver.
                    This also confirms that the
                    remote endpoint supports the RES Option.</t>
      </section> <!-- End of Procedures for UDP Options:End of confirm -->

            <section title="Sending numbered="true" toc="default">
        <name>Sending Probe Packets to Increase the PLPMTU"> PLPMTU</name>
        <t>From time to time, DPLPMTUD enters the SEARCHING state, described
        in
                Section 5.2 of <xref target="RFC8899"></xref>, target="RFC8899" sectionFormat="of" section="5.2"/>, (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-udp-options"></xref>),
        target="RFC9868" sectionFormat="of"
        section="11.5"/>), this value MAY <bcp14>MAY</bcp14> be used as a hint to
                initialise
        initialize this search to increase the PLPMTU.</t>
        <t> Probe packets seeking to increase the PLPMTU SHOULD NOT <bcp14>SHOULD
        NOT</bcp14> carry application data
                ("Probing (see "Probing using padding data" in Section 4.1 of
        <xref target="RFC8899"></xref>), target="RFC8899" sectionFormat="of" section="4.1"/>), since they
        will be lost whenever their size exceeds the actual PMTU.  <xref target="RFC8899"></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 and, size; therefore,
                when using <xref target="I-D.ietf-tsvwg-udp-options"></xref> a probe packet
                MUST
        <bcp14>MUST</bcp14> include the REQ Option.</t> 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 Section 5 of application (see <xref target="RFC8085"></xref>, target="RFC8085"
        sectionFormat="of" section="5"/>), although
                Section 18 of
        <xref target="I-D.ietf-tsvwg-udp-options"></xref> target="RFC9868" sectionFormat="of" section="18"/>
                discusses the implications when using UDP Options.</t>
      </section> <!-- End of Procedures for UDP Options: Increase -->

            <section title="Validating numbered="true" toc="default">
              <name>Validating the Path with UDP Options"> Options</name>
        <t>A PL using DPLPMTUD MUST <bcp14>MUST</bcp14> validate that a path
        continues to support the PLPMTU discovered in a previous search for a
        suitable PLPMTU value, as defined in Section 6.1.4 of <xref target="RFC8899"></xref>. target="RFC8899"
        sectionFormat="of" section="6.1.4"/>.  This validation sends probe
        packets in the DPLPMTUD SEARCH_COMPLETE state (<xref target="RFC8899" sectionFormat="of" section="5.2"/>) to detect black-holing
        of data
                    (Section 5.2 of <xref target="RFC8899"></xref>, Section 4.3 of <xref target="RFC8899"></xref>
        (<xref target="RFC8899" sectionFormat="of" section="4.3"/> defines a
        DPLPMTUD black-hole).</t> black hole).</t>
        <t>Path validation can be implemented within UDP Options by generating
        a probe packet of size PLPMTU, which MUST <bcp14>MUST</bcp14> include a REQ
        Option to elicit a positive confirmation that the path has delivered
        this probe packet.  A probe packet used to validate the path MAY
        <bcp14>MAY</bcp14> use either "Probing using padding data" to
        construct a probe packet that does not carry any application data (Section 4.1 of <xref target="RFC8899"></xref>) or
        "Probing using application data and padding data", data"; see Section 4.1 of <xref target="RFC8899"></xref>.
        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 Section 6 of packet (see <xref target="I-D.ietf-tsvwg-udp-options"></xref>.
        target="RFC9868" sectionFormat="of" section="6"/>).
        </t>
      </section> <!-- End of Procedures for UDP Options: Validate -->

            <section anchor="no-app-data" title="Probe numbered="true" toc="default">
        <name>Probe Packets that do not include That Do Not Include Application Data"> Data</name>
        <t> A simple implementation of the method might be designed to only
        use probe packets in a UDP datagram that includes no application
        data. The size of each probe packet is padded to the required probe
        size including the REQ Option. This implements "Probing using padding
        data" (Section 4.1 of <xref target="RFC8899"></xref>) (<xref target="RFC8899" sectionFormat="of" section="4.1"/>) and
        avoids having to retransmit application data when a probe fails.  This
        could be achieved by setting a minimum datagram length, such that the
        options list ends in EOL (Section 11.1 of <xref target="I-D.ietf-tsvwg-udp-options"></xref>) (<xref target="RFC9868"
        sectionFormat="of" section="11.1"/>) with any additional space is
        zero-filled as needed (see Section 15 of <xref target="I-D.ietf-tsvwg-udp-options"></xref>). target="RFC9868"
        sectionFormat="of" section="15"/>).  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 Data -=-->

            <section title="Probe numbered="true" toc="default">
        <name>Probe Packets that include That Include Application Data"> Data</name>
        <t>
                An implementation always uses the format in <xref target="no-app-data"></xref> target="no-app-data" format="default"/>
                when DPLPMTUD searches to increase the PLPMTU.</t>
        <t>
                An alternative format is permitted for a probe packet that is used to confirm
                the connectivity or to validate the path.
                These probe packets MAY <bcp14>MAY</bcp14> carry application data.
                (A UDP
                (UDP payload data is permitted because these probe packets perform
                black-hole detection
                and will, therefore, will therefore usually have a higher probability of successful
                transmission, similar to other packets sent by the Upper Layer protocol.)
                Section 4.1 of
                <xref target="RFC8899"></xref> target="RFC8899" sectionFormat="of" section="4.1"/> provides a discussion of
                the merits and demerits of including application data. For example, this
                reduces the need to send additional datagrams.
        </t>
        <t>This type of probe packet MAY <bcp14>MAY</bcp14> use
                a control message format defined by the Upper Layer protocol,
                provided that the message does not need to
                be delivered reliably. The REQ Option MUST <bcp14>MUST</bcp14> be
                included when the sending Upper Layer protocol performs DPLPMTUD.
                The DPLPMTUD method tracks the transmission
                of probe packets (using the REQ Option token).</t>
        <t>A receiver that responds to DPLPMTUD MUST <bcp14>MUST</bcp14> process the REQ Option and
                include the corresponding RES Option with an Upper Layer protocol message
                that it returns to the requester (examples of receiver processing are
                provided in Section <xref target="examples"></xref>).</t> target="examples" format="default"/>).</t>
        <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
                one direction or can be used for both directions.</t>
      </section> <!-- End of Procedures for UDP Options: With App Data -->
    </section> <!-- End of Procedures for UDP Options -->

    <section title="Receiving numbered="true" toc="default">
      <name>Receiving Events from the Network"> Network</name>
      <t>This specification does not rely upon reception of events from the network,
        but an implementation can utilise utilize these events when they are provided.</t>
      <section title="Changes numbered="true" toc="default">
        <name>Changes in the Path"> Path</name>
        <t>A change in the path or the loss of a probe packet can result in
        DPLPMTUD updating the PLPMTU. DPLPMTUD <xref target="RFC8899"></xref> target="RFC8899"
        format="default"/> recommends that methods are robust to path changes
        that could have occurred since the path characteristics were last
        confirmed and to the possibility of inconsistent path information
        being received. For example, a notification that a path has changed
        could trigger path validation to provide black-hole protection
            (Section 4.3 of <xref target="RFC8899"></xref>).</t> (<xref
        target="RFC8899" sectionFormat="of" section="4.3"/>).</t>
        <t>An Upper Layer protocol could trigger DPLPMTUD to validate the path
        when it observes a high packet loss rate (or a repeated protocol
        timeout) <xref target="RFC8899"></xref>.</t>

            <t>Section 3 of <xref target="RFC8899"></xref> target="RFC8899" format="default"/>.</t>
        <t><xref target="RFC8899" sectionFormat="of" section="3"/> requires
        any methods designed to share the PLPMTU between PLs (such as updating
        the IP cache PMTU for an interface/destination) to be robust to the
        wide variety of underlying network forwarding behaviors. For example,
        an implementation could avoid sharing PMTU information that could
        potentially relate to packets sent with the same address over a
        different interface.</t>
      </section> <!-- End of Path Changes -->

       <section title="Validation numbered="true" toc="default">
        <name>Validation of PTB Messages"> Messages</name>
        <t> Support for receiving ICMP PTB messages is
            OPTIONAL
            <bcp14>OPTIONAL</bcp14> for DPLPMTUD. A UDP Options sender
            can therefore ignore received ICMP PTB messages.</t>
        <t>Before processing an ICMP PTB message message, the
            DPLPMTUD method needs to perform two checks to ensure
            that the messgage message was received
            in response to a sent probe packet:</t>
            <list style="symbols">
        <ul spacing="normal">
          <li>
            <t>DPLPMTUD first utilises utilizes the quoted information in each PTB
            message.  The receiver MUST <bcp14>MUST</bcp14> validate the protocol
            information in the quoted packet carried in an ICMP PTB message
            payload to validate the message originated from the sending node
            (see Section 4.6.1 of <xref target="RFC8899"></xref>).</t> target="RFC8899" sectionFormat="of"
            section="4.6.1"/>).</t>
          </li>
          <li>
            <t>The receiver SHOULD <bcp14>SHOULD</bcp14> utilize information that is
            not simple for an off-path attacker to determine (see Section 4.6.1 of
            <xref target="RFC8899"></xref>). target="RFC8899" sectionFormat="of" section="4.6.1"/>).
            Specifically, a UDP Options receiver SHOULD <bcp14>SHOULD</bcp14> confirm
            that the token 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 current endpoint.</t>
            </list>
          </li>
        </ul>
        <t>An
            implementation unable to support this validation MUST <bcp14>MUST</bcp14> ignore
            received ICMP PTB messages.</t>
      </section> <!-- End of PTB -->

    </section> <!-- End of Network Events -->

    <section anchor="examples" title="Examples numbered="true" toc="default">
      <name>Examples with Different Receiver Behaviors"> Behaviors</name>
      <t> When enabled, a DPLPMTUD endpoint that implements UDP Options
        normally responds with a
        UDP datagram with a RES Option when requested by a sender.</t>
      <t>The following examples describe various possible receiver behaviors:</t>
        <list style="symbols">
            <t>(No
      <ul spacing="normal">
        <li>
          <t>No DPLPMTUD receiver support) support:
            One case is when a sender supports this specification,
            but no RES Option is received from the remote endpoint.
            In this example, the method
            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 Options, Options or
            might not return a datagram with a RES Option for some other reason
            (packet
            (e.g., packet loss, insufficient space
            to include the option, filtering on the path, etc).</t>

            <t>(DPLPMTUD etc.).</t>
        </li>
        <li>
          <t>DPLPMTUD receiver uses application datagrams) datagrams:
            In a second case, both the sender and receiver
            support DPLPMTUD using the specification,
            and the receiver only returns a RES Option with the next UDP datagram
            that is sent to the requester.
            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,
            providing
            provided there is periodic feedback (e.g., one acknowledgement packet per RTT).
            It requires the PLPMTU at the receiver
            to be sufficiently large enough that the RES option Option can be included in the feedback packets
            that are sent in the return direction.
            This method avoids opportunities to misuse the method as a DoS attack.
            However, when there is a low
            rate of transmission (or no datagrams are sent) in the return direction,
            this will prevent prompt delivery of the RES Option.
            At the DPLPMTUD sender, this results in probe packets failing to be
            acknowledged in time, time
            and could result in a smaller PLPMTU than is actually supported by
            the path or in using the minimum configured PLPMTU (MIN_PLPMTU).</t>

            <t>(Uni-directional transfer) MIN_PLPMTU.</t>
        </li>
        <li>
          <t>Unidirectional transfer: Another case is where an application only transfers data
            in one direction (or predominantly in one direction).
            In this case case, the wait at the receiver for a datagram to be queued before
            returning a RES Option could easily result in a probe timeout
            at the DPLPMTUD sender.
            In this case, DPLPMTUD could allow exchanging datagrams without
            a payload (as discussed in earlier sections) to return the RES Option.</t>

            <t>(DPLPMTUD Receiver
        </li>
        <li>
          <t>DPLPMTUD receiver permitted to send responses in UDP datagrams with no payload) payload:
            A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data)
            solely to return a RES Option
            (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
            been configured with support for this specification
            using a DPLPMTUD probe packet.
            Although this results in some additional traffic overhead,
            it has the advantage that it
            can ensure timely progress of DPLPMTUD.
            Section
            <xref target="formats"></xref> target="formats" format="default"/> specifies: "If a UDP Options endpoint creates and
            sends a datagram with a RES option Option solely as response to a received REQ Option,
            the responder MUST <bcp14>MUST</bcp14> 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 limit is to mitigate the DoS vector, without significantly impacting
            the operation of DPLPMTUD.</t>
        </list>
        </li>
      </ul>
    </section> <!-- End of examples -->

        <section anchor="Acknowledgements" title="Acknowledgements">
            <t>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.</t>
        </section> <!-- End of acknowledgements -->

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes document has no requests to IANA.</t>
        </section> <!-- End of IANA --> actions.</t>
    </section>

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations for using UDP Options are described in
            <xref target="I-D.ietf-tsvwg-udp-options"></xref>. target="RFC9868" format="default"/>. The
            method does not change the integrity protection offered by the UDP
            options
            Options method.</t>
      <t>The security considerations for using DPLPMTUD are described in <xref
                target="RFC8899"></xref>. On path target="RFC8899" format="default"/>. On-path attackers could maliciously drop
            or modify probe packets to seek to decrease the PMTU, PMTU or
            to maliciously modify probe packets in an attempt to black-hole traffic.</t>
      <t>The specification recommends that the token value in the REQ Option is
            initialised
            initialized to a randomised randomized value. This is to enhance protection from off-path
            attacks.
            If a subsequent probe packet uses a token value that is easily derived
            from the initial value, value
            (e.g., incrementing the value) value), a misbehaving on-path observer could then
            determine the token values used for subsequent probe packets from
            that sender, even if these probe packets are not transiting via the observer.
            This would allow probe packets to be forged, with an impact similar to other on-path
            attacks against probe packets.
            This attack could be mitigated by using an unpredictable
            token value for each probe packet.</t>
      <t>The method does not change the
            ICMP PTB message validation method described by DPLPMTUD: A UDP Options
            sender that utilises utilizes ICMP PTB messages received to a probe packet MUST <bcp14>MUST</bcp14>
            use the quoted packet to validate the UDP port information in
            combination with the token contained in the UDP
            Option,
            Option before processing the packet using the DPLPMTUD method.</t>
      <t>Upper Layer protocols or applications that employ encryption
            ought to perform DPLPMTUD
            at a layer above UDP Options, Options and not enable UDP Options support for DPLPMTUD.
            This allows the application to control when DPLPMTUD is used to control the additional
            traffic that this generates.
            This also ensures that DPLPMTUD probe packets are encrypted.</t>
    </section> <!-- End of Sec Considerations -->
    </middle>
    <back>

      <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>

<!-- References split into informative and normative RFC 9868
draft-ietf-tsvwg-udp-options-45
-->

        <references title="Normative References">
            <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

            &RFC768;

            &RFC2119;

            &RFC8174;

            &RFC8899;

            &I-D.ietf-tsvwg-udp-options;
<reference anchor="RFC9868" target="https://www.rfc-editor.org/info/rfc9868">
  <front>
      <title>Transport Options for UDP</title>
      <author initials="J." surname="Touch" fullname="Dr. Joseph D. Touch">
         <organization>Independent Consultant</organization>
      </author>
      <author initials="C." surname="Heard" fullname="C. M. Heard" role="editor">
         <organization>Unaffiliated</organization>
      </author>
    <date month="September" year="2025"/>
  </front>
  <seriesInfo name="RFC" value="9868"/>
  <seriesInfo name="DOI" value="10.17487/RFC9868"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8304.xml"/>
      </references>

        <references title="Informative References">
            &RFC1191;

            &RFC4821;

            &RFC8085;

            &RFC8201;

            &RFC8304;
    </references>

    <section title="Revision Notes">
            <t>XXX Note to RFC-Editor: please remove this entire section prior to
                publication. XXX</t>

            <t>Individual draft-00.</t>

            <t><list style="symbols">
                <t>This version contains a description for consideration anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t><contact fullname="Gorry Fairhurst"/> and comment <contact fullname="Tom
      Jones"/> are supported by funding provided 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 University of
      Aberdeen. The authors would like to Echo thank <contact fullname="Magnus
      Westerlund"/> and <contact fullname="Mohamed Boucadair"/> for their
      detailed comments and also other people who contributed to align
                    names with draft-ietf-tsvwg-udp-options</t>

                <t>Remove Appendix B, Informative Description completing
      this document.</t>
    </section>

  </back>

<!-- [rfced] Please review whether any 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 notes in UDP Options.</t>
                <t>Add a description of uses of DPLPMTUD with UDP Options.</t>
                <t>Add a description on how to form probe packets with padding.</t>
                <t>Say that MSS options can this document
should be used to initialise the search algorithm.</t>
                <t>Say that in the recommended approach <aside> element. It is to not use user data defined as "a container for probes.</t>
                <t>Attempts to clarify and improve wording throughout.</t>
                <t>Remove text saying you can respond to multiple probes in a single packet.</t>
                <t>Simplified text by removing options
content that don't yield benefit.</t>

            </list></t>
            <t>Working group draft -02</t>
            <t><list style="symbols">
                <t>Update to reflect comments from MED.</t>
                <t>More consistent description of DPLPMTUD with UDP Options.</t>
                <t>Clarify the nonce value (token) is intended per 5-tuple, not interface.</t>
                <t>BASE_PLPMTU related semantically less important or tangential to RFC8899.</t>
                <t>Probes with user data can carry application control data.</t>
                <t>Added the
content that application data surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] We note that this document uses RES and REQ nonce (token) values from the app.</t>
                <t>QUIC was intended as an informational reference to an example of RFC8899.</t>
            </list></t>
            <t>Working group draft -03</t>
            <t><list style="symbols">
                <t>Update to reflect more comments from MED.</t>
                <t>Again more consistent description of DPLPMTUD with UDP Options.</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 "UDP Options", while RFC-to-be 9868 <draft-ietf-tsvwg-udp-options> uses "UDP options" (lowercase).  Please review by Magnus.</t>
                <t>Added text after WG Last Call, based on comments by Joe and Mike.</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 let us know if these should be made consistent.  Perhaps lowercase for UDP Options "UDP options" in general, but "Option" when referring 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>
    </back> a specific option (e.g., Response (RES) Option).

See <https://www.rfc-editor.org/authors/rfc9868.html>.
-->

</rfc>