draft-ietf-tsvwg-udp-options-dplpmtud-01.txt   draft-ietf-tsvwg-udp-options-dplpmtud-02.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Intended status: Standards Track University of Aberdeen Intended status: Standards Track University of Aberdeen
Expires: 22 May 2022 18 November 2021 Expires: 29 May 2022 25 November 2021
Datagram PLPMTUD for UDP Options Datagram PLPMTUD for UDP Options
draft-ietf-tsvwg-udp-options-dplpmtud-01 draft-ietf-tsvwg-udp-options-dplpmtud-02
Abstract Abstract
This document specifies how a UDP Options sender implements Datagram This document specifies how a UDP Options sender implements Datagram
Packetization Layer Path Maximum Transmission Unit Discovery Packetization Layer Path Maximum Transmission Unit Discovery
(DPLPMTUD) as a robust method for Path Maximum Transmission Unit (DPLPMTUD) as a robust method for Path Maximum Transmission Unit
discovery. This method uses the UDP Options packetization layer. It discovery. This method uses the UDP Options packetization layer. It
allows a datagram application to discover the largest size of allows a datagram application to discover the largest size of
datagram that can be sent across a network path. datagram that can be sent across a specific network path.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 May 2022. This Internet-Draft will expire on 29 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3
4. Sending UDP-Options Probe Packets . . . . . . . . . . . . . . 4 4. Sending UDP-Options Probe Packets . . . . . . . . . . . . . . 4
4.1. Packet Probes using the Echo Request Option Request 4.1. Packet Probes using the Echo Request and Response
Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 Options . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. DPLPMTUD Procedures for UDP Options . . . . . . . . . . . 5 4.2. DPLPMTUD Procedures for UDP Options . . . . . . . . . . . 5
4.2.1. Confirmation of Connectivity across a Path . . . . . 5 4.2.1. Confirmation of Connectivity across a Path . . . . . 5
4.2.2. Sending Probe Packets to Increase the PLPMTU . . . . 5 4.2.2. Sending Probe Packets to Increase the PLPMTU . . . . 6
4.2.3. Validating the Path with UDP Options . . . . . . . . 6 4.2.3. Validating the Path with UDP Options . . . . . . . . 6
4.2.4. Sending Packet Probes that include Application 4.2.4. Sending Packet Probes that include Application
Data . . . . . . . . . . . . . . . . . . . . . . . . 6 Data . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.5. Changes in the Path . . . . . . . . . . . . . . . . . 7
4.3. PTB Message Handling for this Method . . . . . . . . . . 7 4.3. PTB Message Handling for this Method . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The User Datagram Protocol [RFC0768] offers a minimal transport The User Datagram Protocol [RFC0768] offers a minimal transport
service on top of IP and is frequently used as a substrate for other service on top of IP and is frequently used as a substrate for other
protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that
applications implement some form of Path MTU discovery to avoid the applications implement some form of Path MTU discovery to avoid the
generation of IP fragments: generation of IP fragments:
"Consequently, an application SHOULD either use the path MTU "Consequently, an application SHOULD either use the path MTU
information provided by the IP layer or implement Path MTU Discovery information provided by the IP layer or implement Path MTU Discovery
(PMTUD)". (PMTUD)".
The UDP API [RFC8304] offers calls for applications to receive ICMP The UDP API [RFC8304] offers calls for applications to receive ICMP
Packet Too Big (PTB) messages and to control the maximum size of Packet Too Big (PTB) messages and to control the maximum size of
datagrams that are sent, but does not offer any automated mechanisms datagrams that are sent, but does not offer any automated mechanisms
for an application to discover the maximum packet size supported by a for an application to discover the maximum packet size supported by a
path. Applications and upper layer protocols implement mechanisms path. Upper layer protocols (which can include applications)
for Path MTU discovery above the UDP API. implement mechanisms for Path MTU discovery above the UDP API.
Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes
a Packetization Layer (PL) (such as UDP Options) to search for the a method for a Packetization Layer (PL) (such as UDP Options) to
largest Packetization Layer PMTU (PLPMTU) supported on a path. search for the largest Packetization Layer PMTU (PLPMTU) supported on
Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for a path. Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support
datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a for datagram transports. PLPMTUD and DPLPMTUD gain robustness by
probing mechanism that does not solely rely on ICMP PTB messages and using a probing mechanism that does not solely rely on ICMP PTB
works on paths that drop ICMP PTB messages. messages and works on paths that drop ICMP PTB messages.
In summary, UDP Options [I-D.ietf-tsvwg-udp-options] supplies This document specifies how UDP Options [I-D.ietf-tsvwg-udp-options]
functionality that can be used to implement DPLPMTUD within the UDP can be used as a PL to implement DPLPMTUD (see Section 6.1 of
transport service. This document specifies how an implementation can [RFC8899]). In summary, UDP Options [I-D.ietf-tsvwg-udp-options]
use this additional functionality to support DPLPMTUD. Implementing supplies functionality that can be used to implement DPLPMTUD within
DPLPMTUD using UDP Options avoids the need for each upper layer the UDP transport service. Implementing DPLPMTUD using UDP Options
protocol or application to implement the DPLPMTUD method. This avoids the need for each upper layer protocol or application to
provides a standard method for applications to discover the current implement the DPLPMTUD method. This provides a standard method for
maximum packet size for a path and to detect when this changes. applications to discover the current maximum packet size for a path
and to detect when this changes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. here.
3. DPLPMTUD for UDP Options 3. DPLPMTUD for UDP Options
There are two ways an upper PL can perform DPLPMTUD: There are two ways an upper PL can perform DPLPMTUD:
* The UDP Options sender implementing DPLPMTUD uses the method * The UDP Options sender implementing DPLPMTUD uses the method
specified in [RFC8899] and the upper PL or application does not specified in [RFC8899] and the upper PL (or application) does not
perform PMTU discovery. In this case, UDP Options processing is perform PMTU discovery. In this case, UDP Options processing is
responsible for sending probes to determine a PLPMTU, as described responsible for sending probes to determine a PLPMTU, as described
in this document. This discovered PLPMTU can be used by UDP in this document. "An application SHOULD avoid using DPLPMTUD
Options to either: when the underlying transport system provides this capability"
(Section 6.1 of [RFC8899]). This discovered PLPMTU can be used by
UDP Options to either:
- set the maximum datagram size for the current path (based on - set the maximum datagram size for the current path (based on
the discovered largest IP packet that can be received across the discovered largest IP packet that can be received across
the path). the current path).
- set the maximum fragment size when a sender uses the UDP - set the maximum fragment size when a sender uses the UDP
Fragmentation Option to divide a datagram into multiple UDP Fragmentation Option to divide a datagram into multiple UDP
fragments for transmission. Each UDP fragment is then less fragments for transmission. Each UDP fragment is then less
than the discovered largest IP packet that can be received than the discovered largest IP packet that can be received
across the path. across the current path.
* An upper PL or application performs DPLPMTUD (e.g., QUIC * An upper PL (or application performs DPLPMTUD (e.g., QUIC
[RFC9000]). This upper PL then uses probes to determine a safe [RFC9000]). This upper PL then uses probes to determine a safe
PLPMTU for the datagrams that it sends. The contents of any probe PLPMTU for the datagrams that it sends. The format and content of
is determined by the upper PL. Such a design needs to avoid any probe is determined by the upper PL. Such a design should
performing discovery at multiple levels, so, when when avoid performing discovery at multiple levels, so, when when
configurable, this upper PL SHOULD disable DPLPMTUD by UDP Options configurable, this upper PL SHOULD disable DPLPMTUD by UDP
[RFC8899]). Options.
This section describe packet formats and procedures for DPLPMTUD This section describes packet formats and procedures for DPLPMTUD
using UDP Options. using UDP Options.
4. Sending UDP-Options Probe Packets 4. Sending UDP-Options Probe Packets
DPLPMTUD relies upon the ability of a UDP Options sender to generate DPLPMTUD relies upon the ability of a UDP Options sender to generate
a probe with a specific size, up to the maximum for the size a probe with a specific size, up to the maximum for the size
supported by the local interface. The size of a DPLPMTUD probe supported by a local interface. This MUST NOT be constrained by the
packet MUST NOT be constrained by the maximum PMTU set by network maximum PMTU set by network layer mechanisms (such as PMTUD
layer mechanisms (such as PMTUD [RFC1063][RFC8201] or the IP Cache). [RFC1191][RFC8201] or the PMTU size held in the IP- layer cache), as
noted in bullet 2 of Section 2 in [RFC8899]).
Probe packets consume network capacity and incur endpoint processing Probe packets consume network capacity and incur endpoint processing
(see Section 4.1 of [RFC8899]). Implementations ought to send a (see Section 4.1 of [RFC8899]). Implementations ought to send a
probe with a Request Probe Option only when required by their local probe with an REQ Option only when required by their local DPLPMTUD
DPLPMTUD state machine, i.e., when confirming the base PMTU for the state machine, i.e., when confirming the base PMTU for the path,
path, probing to increase the PLPMTU or to confirm the current probing to increase the PLPMTU or to confirm the current PLPMTU.
PLPMTU.
4.1. Packet Probes using the Echo Request Option Request Option 4.1. Packet Probes using the Echo Request and Response Options
A UDP Options node that supports DPLPMTUD MUST support sending and
receiving of the REQ Option and the RES Option. When not supported,
DPLPMTUD will be unable to confirm the Path or to discover the PMTU.
This section describes a format of probe consisting of an empty UDP This section describes a format of probe consisting of an empty UDP
datagram, UDP Options area and Padding. The UDP Options area datagram, UDP Options area and Padding.
contains the Echo Request Option (RES), any other required options
concluded with an EOL Option followed by any padding needed to
inflate to the required probe size. The reception of this option
generates an Echo Response Option that confirms reception of a
specific received probe.
The UDP Options used in this method are described in section 6 of A Probe Packet includes the UDP Options area containing a RES Option
and any other required options concluded with an EOL Option followed
by any padding needed to inflate to the required probe size.
The UDP Options used in this document are described in Section 6 of
[I-D.ietf-tsvwg-udp-options]: [I-D.ietf-tsvwg-udp-options]:
* The Echo Request Option (RES) is set by a sending PL to solicit a * The REQ Option is set by a sending PL to solicit a response from a
response from a remote UDP Options receiver. A four-byte token remote UDP Options receiver. A four-byte token identifies each
identifies each request. request.
* The Echo Response Option (REQ) is generated by the UDP Options * The RES Option is generated by the UDP Options receiver in
receiver in response to reception of a previously received Echo response to reception of a previously received REQ Option. Each
Request Option. Each Echo Response Option echoes a previously RES Option echoes a previously received four-byte token.
received four-byte token.
* Reception of a RES Option confirms reception of a specific
received probe by the remote UDP Options receiver.
The token value allows a sender to distinguish between The token value allows a sender to distinguish between
acknowledgements for initial probes and acknowledgements confirming acknowledgements for initial probes and acknowledgements confirming
receipt of subsequent probes (e.g., travelling along alternate paths receipt of subsequent probes (e.g., travelling along alternate paths
with a larger round trip time). This needs each probe to be uniquely with a larger round trip time). This needs each probe to be uniquely
identifiable by the UDP Options sender within the Maximum Segment identifiable by the UDP Options sender within the Maximum Segment
Lifetime (MSL). The UDP Options sender therefore MUST NOT recycle Lifetime (MSL). The UDP Options sender therefore MUST NOT recycle
token values until they have expired or have been acknowledged. A token values until they have expired or have been acknowledged. 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 probes to be made within the MSL. multiple unique probes to be made within the MSL. Since UDP Options
operates over UDP, the token values only need to be unique for the
specific 5-tuple over which DPLPMTUD is operating.
The initial value of the four byte token field SHOULD be assigned to The initial value of the four byte token field SHOULD be assigned to
a randomised value to enhance protection from off-path attacks, as a randomised value to enhance protection from off-path attacks, as
described in section 5.1 of [RFC8085]). described in Section 5.1 of [RFC8085]).
4.2. DPLPMTUD Procedures for UDP Options 4.2. DPLPMTUD Procedures for UDP Options
DPLPMTUD utilizes three types of probes. These are described in the DPLPMTUD utilises three types of probes. These are described in the
following sections: following sections:
* A probe to confirm the path can support the base PLPMTU. * A probe to confirm the path can support the BASE_PLPMTU see
Section 5.1.4 of [RFC8899]).
* A probe to detect whether the path can support a larger PLPMTU. * A probe to detect whether the path can support a larger PLPMTU.
* A probe to validate the path supports the current PLPMTU. * A probe to validate the path supports the current PLPMTU.
4.2.1. Confirmation of Connectivity across a Path 4.2.1. Confirmation of Connectivity across a Path
The DPLPMTUD method requires a PL to confirm connectivity over the The DPLPMTUD method requires a PL to confirm connectivity over the
path using the base PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP path using the BASE_PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP
does not offer a mechanism for this. does not offer a mechanism for this.
UDP Options can provide this required functionality. A UDP Options UDP Options can provide this required functionality. A UDP Options
sender implementing this specification MUST elicit a positive sender implementing this specification MUST elicit a positive
confirmation of connectivity for the path, by sending a probe, padded confirmation of connectivity for the path, by sending a probe, padded
to size BASE_PLPMTU. This confirmation probe MUST include a UDP to size BASE_PLPMTU. This confirmation probe MUST include a UDP
Option that elicits a response from the remote endpoint (e.g., by Option that elicits a response from the remote endpoint (e.g., by
including the ECHO Request/Response Option) to confirm that a packet including the RES and REQ Options) to confirm that a packet of the
of the size traversed the path. size traversed the path. This also confirms that the remote receiver
supports use of the RES and REQ Options.
4.2.2. Sending Probe Packets to Increase the PLPMTU 4.2.2. Sending Probe Packets to Increase the PLPMTU
From time to time, DPLPMTUD searches to detect whether the current From time to time, DPLPMTUD enters the SEARCHING state [RFC8899]
path can support a larger PLPMTU. When the remote endpoint (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the
current path can support a larger PLPMTU. When the remote endpoint
advertises a UDP Maximum Segment Size (MSS) option, this value can be advertises a UDP Maximum Segment Size (MSS) option, this value can be
used as a hint to initialise this search to increase the PLPMTU. used as a hint to initialise this search to increase the PLPMTU.
Probe packets seeking to increase the PLPMTU SHOULD NOT carry Probe packets seeking to increase the PLPMTU SHOULD NOT carry
application data (see "Probing using padding data" in Section 4.1 of application data (see "Probing using padding data" in Section 4.1 of
[RFC8899]), since they will be lost whenever their size exceeds the [RFC8899]), since they will be lost whenever their size exceeds the
actual PMTU. actual PMTU.
A probe seeking to increase the PLPMTU MUST elicit a positive A probe seeking to increase the PLPMTU needs to elicit a positive
confirmation that the path has delivered a Datagram of the specific acknowledgment that the path has delivered a datagram of the specific
probed size and therefore SHOULD include the Echo Request Option probed size and, therefore, MUST include the REQ Option.
Request Option.
Received probes that do not carry application data do not form a part Received probes that do not carry application data do not form a part
of the end-to-end transport data and are not delivered to the upper of the end-to-end transport data and are not delivered to the upper
layer protocol. layer protocol.
4.2.3. Validating the Path with UDP Options 4.2.3. Validating the Path with UDP Options
A PL using DPLPMTUD needs to validate that a path continues to A PL using DPLPMTUD needs to validate that a path continues to
support the PLPMTU discovered in a previous search for a suitable support the PLPMTU discovered in a previous search for a suitable
PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends
probes in the DPLPMTUD SEARCH_COMPLETE state i.e., to detect black- probes in the DPLPMTUD SEARCH_COMPLETE state to detect black-holing
holing of data (see Section 4.2 of [RFC8899]). of data (see Section 4.2 of [RFC8899]).
This function can be implemented within UDP Options, by generating a This function can be implemented within UDP Options, by generating a
probe of size PLPMTU which MUST include a UDP Option to elicit a probe of size PLPMTU, which MUST include a RES Option to elicit a
positive confirmation that the path has delivered the probe. This positive confirmation whether the path has delivered the probe. This
confirmation probe MAY use "Probing using padding data" or "Probing confirmation probe MAY use "Probing using padding data" or "Probing
using application data and padding data" (see Section 4.1 of using application data and padding data" (see Section 4.1 of
[RFC8899]) or can construct a probe packet that does not carry any [RFC8899]) or can construct a probe packet that does not carry any
application data, as described in a previous section. application data, as described in a previous section.
4.2.4. Sending Packet Probes that include Application Data 4.2.4. Sending Packet Probes that include Application Data
The method can be designed to only use probes that are formed of a The method can be designed to only use probes that are formed of a
UDP Options datagram containing control information, padded to the UDP datagram that includes application data (which could be
required size. This implements "Probing using padding data", and applications control information), padded to the required size and
avoids having to retransmit application data when a probe fails. include a RES Option. This implements "Probing using padding data",
and avoids having to retransmit application data when a probe fails.
This type of probe must be used when searching to increase the This type of probe must be used when searching to increase the
PLPMTU. These probes do not form a part of the end-to-end transport PLPMTU. In this use, the RES and REQ Options do not form a part of
data and a receiver does not deliver these to the upper layer the end-to-end transport data and a receiver does not deliver them to
protocol. A simple implementation of the method might be designed to the upper layer protocol. A simple implementation of the method
only use this format for all probes. might be designed to only use this format for all probes.
Probe used to confirm the connectivity or to validate support for the The probe used to confirm the connectivity or to validate support for
current PLPMTU are also permitted to carry application data, since the current PLPMTU are also permitted to carry application data,
this type of probe is expected to be successful. Section 4.1 of since this type of probe is expected to be successful. Section 4.1
[RFC8899] provides a discussion of the merits and demerits of of [RFC8899] provides a discussion of the merits and demerits of
including application data. For example, this reduces the need to including application data. For example, this reduces the need to
send an additional datagram when confirming that the current path send an additional datagram when confirming that the current path
supports datagrams of size PLPMTU and could be designed to utilise a supports datagrams of size PLPMTU and could be designed to utilise a
control message format defined by the PL that does not need to be control message format defined by the PL that does not need to be
delivered reliably. delivered reliably. In this use, the RES and REQ Options need to be
included by the sending upper layer and the values of tokens need to
be coordinated with values used for other DPLPMTUD probe packets.
These probes do form a part of the end-to-end transport data and a
receiver does deliver the RES and REQ Options to the upper layer
protocol.
4.2.5. Changes in the Path
A change in the path or the loss of probe packets can result in a
change of the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are
robust to path changes that could have occurred since the path
characteristics were last confirmed and to the possibility of
inconsistent path information being received. For example, a
notification that a path could have changed could trigger path
validation to provide black hole protection Section 4.3 of
[RFC8899]).
Section 3 of [RFC8899] requires any methods designed to share the
PLPMTU between PLs (such as updating the IP cache PMTU for an
interface/destination) to be robust to the wide variety of underlying
network forwarding behaviors. For example, an implementation could
avoid sharing PMTU information that could potentially relate to
packets sent with the same address over a different interface.
4.3. PTB Message Handling for this Method 4.3. PTB Message Handling for this Method
Support for receiving ICMP PTB messages is OPTIONAL for use with Support for receiving ICMP PTB messages is OPTIONAL for use with
DPLPMTUD. A UDP Options sender can therefore ignore received ICMP DPLPMTUD. A UDP Options sender can therefore ignore received ICMP
PTB messages. PTB messages.
A UDP Options sender that utilises ICMP PTB messages received in A UDP Options sender that utilises ICMP PTB messages received in
response to a probe packet MUST use the quoted packet to validate the response to a probe packet MUST use the quoted packet to validate the
UDP port information in combination with the token and/or timestamp UDP port information in combination with the token value contained in
value contained in the UDP Option, before processing the packet using the UDP Option, before processing the packet using the DPLPMTUD
the DPLPMTUD method (see Section 4.4.1 of [RFC8899]). An method. Section 4.6.1 of [RFC8899] specifies this validation
implementation unable to support this validation needs to ignore procedure. An implementation unable to support this validation needs
received ICMP PTB messages. to ignore received ICMP PTB messages.
5. Acknowledgements 5. Acknowledgements
Gorry Fairhurst and Tom Jones are supported by funding provided by Gorry Fairhurst and Tom Jones are supported by funding provided by
the University of Aberdeen. the University of Aberdeen.
6. IANA Considerations 6. IANA Considerations
This memo includes no requests to IANA. This memo includes no requests to IANA.
7. Security Considerations 7. Security Considerations
The security considerations for using UDP Options are described in The security considerations for using UDP Options are described in
[I-D.ietf-tsvwg-udp-options]. The proposed new method does not [I-D.ietf-tsvwg-udp-options]. The proposed new method does not
change the integrity protection offered by the UDP options method. change the integrity protection offered by the UDP options method.
The specification recommends that the token in the REQ/RES message is The specification recommends that the token in the REQ Option is
initialised to a randomised value to enhance protection from off-path initialised to a randomised value to enhance protection from off-path
attacks. attacks.
The security considerations for using DPLPMTUD are described in The security considerations for using DPLPMTUD are described in
[RFC8899]. The proposed new method does not change the ICMP PTB [RFC8899]. The proposed new method does not change the ICMP PTB
message validation method described DPLPMTUD: A UDP Options sender message validation method described DPLPMTUD: A UDP Options sender
that utilises ICMP PTB messages received to a probe packet MUST use that utilies ICMP PTB messages received to a probe packet MUST use
the quoted packet to validate the UDP port information in combination the quoted packet to validate the UDP port information in combination
with the token and/or timestamp value contained in the UDP Option, with the token and/or timestamp value contained in the UDP Option,
before processing the packet using the DPLPMTUD method. before processing the packet using the DPLPMTUD method.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-tsvwg-udp-options] [I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in Touch, J. D., "Transport Options for UDP", Work in
skipping to change at page 8, line 29 skipping to change at page 9, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
8.2. Informative References 8.2. Informative References
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, DOI 10.17487/RFC1191, November 1990,
July 1988, <https://www.rfc-editor.org/info/rfc1063>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP- User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>. <https://www.rfc-editor.org/info/rfc8304>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Appendix A. Revision Notes Appendix A. Revision Notes
XXX Note to RFC-Editor: please remove this entire section prior to XXX Note to RFC-Editor: please remove this entire section prior to
publication. XXX publication. XXX
Individual draft-00. Individual draft-00.
* This version contains a description for consideration and comment * This version contains a description for consideration and comment
by the TSVWG. by the TSVWG.
skipping to change at page 10, line 25 skipping to change at page 11, line 10
* Say that the recommended approach is to not use user data for * Say that the recommended approach is to not use user data for
probes. probes.
* Attempts to clarify and improve wording throughout. * Attempts to clarify and improve wording throughout.
* Remove text saying you can respond to multiple probes in a single * Remove text saying you can respond to multiple probes in a single
packet. packet.
* Simplified text by removing options that don't yield benefit. * Simplified text by removing options that don't yield benefit.
Working group draft -02
* Update to reflect comments from MED.
* More consistent description of DPLPMTUD with UDP Options.
* Clarify token is intended per 5-tuple, not interface.
* BASE_PLPMTU related to RFC8899.
* Probes with user data can carry application control data.
* Added that application data uses RES and REQ tokens from the app.
* QUIC was intended as an informational reference to an example of
RFC8899.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
 End of changes. 48 change blocks. 
112 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/