draft-ietf-tsvwg-udp-options-dplpmtud-00.txt   draft-ietf-tsvwg-udp-options-dplpmtud-01.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: 16 April 2022 13 October 2021 Expires: 22 May 2022 18 November 2021
Datagram PLPMTUD for UDP Options Datagram PLPMTUD for UDP Options
draft-ietf-tsvwg-udp-options-dplpmtud-00 draft-ietf-tsvwg-udp-options-dplpmtud-01
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 is a robust method for Path MTU Discovery (PMTUD) discovery. This method uses the UDP Options packetization layer. It
that uses the UDP Options Packetization Layer (PL). It allows a allows a datagram application to discover the largest size of
datagram application that uses this PL, to discover the largest size datagram that can be sent across a network path.
of datagram that can be sent across a 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 16 April 2022. This Internet-Draft will expire on 22 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified 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
3.1. Confirmation of Connectivity across a Path . . . . . . . 3 4. Sending UDP-Options Probe Packets . . . . . . . . . . . . . . 4
3.2. Sending UDP-Options Probe Packets . . . . . . . . . . . . 4 4.1. Packet Probes using the Echo Request Option Request
3.2.1. Sending Packet Probes using the Echo Request Option Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
Request Option . . . . . . . . . . . . . . . . . . . 5 4.2. DPLPMTUD Procedures for UDP Options . . . . . . . . . . . 5
3.2.2. Sending Packet Probes that include Application 4.2.1. Confirmation of Connectivity across a Path . . . . . 5
4.2.2. Sending Probe Packets to Increase the PLPMTU . . . . 5
4.2.3. Validating the Path with UDP Options . . . . . . . . 6
4.2.4. Sending Packet Probes that include Application
Data . . . . . . . . . . . . . . . . . . . . . . . . 6 Data . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Validating the Path with UDP Options . . . . . . . . . . 6 4.3. PTB Message Handling for this Method . . . . . . . . . . 7
3.3.1. Sending Packet Probes using Timestamps . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
3.4. PTB Message Handling for this Method . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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] offer 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 maxmium 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. Applications and upper layer protocols implement mechanisms
for path MTU discovery above the UDP API. for Path MTU discovery above the UDP API.
Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for
a Packetization Layer (PL) (such as UDP with options) to search for a Packetization Layer (PL) (such as UDP Options) to search for the
the largest Packetization Layer PMTU (PLPMTU) supported on a path. largest Packetization Layer PMTU (PLPMTU) supported on a path.
Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for
datagram transports. PLPMTUD and DPLPMTUD use a probing mechanism datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a
that does not solely rely on ICMP PTB messages and works in the probing mechanism that does not solely rely on ICMP PTB messages and
presence of lost probes. works on paths that drop ICMP PTB messages.
UDP Options [I-D.ietf-tsvwg-udp-options] supplies functionality that In summary, UDP Options [I-D.ietf-tsvwg-udp-options] supplies
can be used to implement DPLPMTUD within the UDP transport service. functionality that can be used to implement DPLPMTUD within the UDP
This document specifies this additional functionality. Implementing transport service. This document specifies how an implementation can
use this additional functionality to support DPLPMTUD. Implementing
DPLPMTUD using UDP Options avoids the need for each upper layer DPLPMTUD using UDP Options avoids the need for each upper layer
protocol or application to implement the DPLPMTUD method. This protocol or application to implement the DPLPMTUD method. This
provides a standard method for applications to discover the current provides a standard method for applications to discover the current
maximum packet size for a path and to detect when this changes. 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.
The structure of the present document follows the structure used to
describe DPLPMTUD for other transports [RFC8899].
3. DPLPMTUD for UDP Options 3. DPLPMTUD for UDP Options
The DPLPMTUD PL endpoint implements the method specified in There are two ways an upper PL can perform DPLPMTUD:
[RFC8899].
3.1. Confirmation of Connectivity across a Path
The DPLPMTUD method requires a PL to be able to confirm connectivity
on the path (see Section 5.1.4 of [RFC8899]), but UDP does not offer
a mechanism for this.
UDP Options can provide this required functionality. A UDP Options
sender implementing this specification SHOULD elicit a positive
confirmation of connectivity of the path, using a suitable confirmed
UDP Option (i.e., Timestamps, ECHO Request/Response) to .
3.2. Sending UDP-Options Probe Packets
DPLPMTUD relies upon the ability of a sender PL to generate probe * The UDP Options sender implementing DPLPMTUD uses the method
packets with a specific size, and to confirm when these are delivered specified in [RFC8899] and the upper PL or application does not
across the path. Therefore, a UDP options sender needs to be able to perform PMTU discovery. In this case, UDP Options processing is
send probes up to the maximum for the size the local interface responsible for sending probes to determine a PLPMTU, as described
supports, which MUST NOT be further constrained by the maximum PMTU in this document. This discovered PLPMTU can be used by UDP
set by network layer mechanisms (such as PMTUD [RFC1063][RFC8201]). Options to either:
DPLPMTUD needs to be able to generate probe packets that are not - set the maximum datagram size for the current path (based on
delivered to the upper layer protocol as a part of the end-to-end the discovered largest IP packet that can be received across
transport data (i.e. ensure any added padding data is not delivered the path).
to the upper layer protocol at the receiver). UDP Options provide
the necessary additional support required to do this within the
transport layer.
There are various designs described in DPLPMTUD to send a Packet - set the maximum fragment size when a sender uses the UDP
Probe to test the size of packet supported by a path (see Section 4.1 Fragmentation Option to divide a datagram into multiple UDP
of [RFC8899]). This prevents "Probing using padding data" or fragments for transmission. Each UDP fragment is then less
"Probing using application data and padding data" (see Section 4.1 of than the discovered largest IP packet that can be received
[RFC8899]). across the path.
A PL needs to determine whether the current path supports datagrams * An upper PL or application performs DPLPMTUD (e.g., QUIC
used as Probe Packets. DPLPMTUD SHOULD add a UDP Option (e.g., [RFC9000]). This upper PL then uses probes to determine a safe
Timestamps, ECHO Request/Response) to a Packet Probe to elicit a PLPMTU for the datagrams that it sends. The contents of any probe
positive confirmation that the path has delivered the Probe Packet of is determined by the upper PL. Such a design needs to avoid
the corresponding size. From time to time, such probes can also be performing discovery at multiple levels, so, when when
used to determine whether the current path can support a larger size configurable, this upper PL SHOULD disable DPLPMTUD by UDP Options
of datagram that the current PLPMTU. [RFC8899]).
A PL also needs to determine that the current path supports the size This section describe packet formats and procedures for DPLPMTUD
of datagram that the application is currently sending when in the using UDP Options.
DPLPMTUD SEARCH_COMPLETE state i.e., to detect black-holing of data
(see Section 4.2 of [RFC8899]). UDP Options can provide this by
eliciting a positive confirmation that the path has delivered a
Datagram of the corresponding size.
3.2.1. Sending Packet Probes using the Echo Request Option Request 4. Sending UDP-Options Probe Packets
Option
The RECOMMENDED method sends a Probe Packet with the Echo Request DPLPMTUD relies upon the ability of a UDP Options sender to generate
Option (RES) together with any padding needed to inflate the required a probe with a specific size, up to the maximum for the size
size. The reception of this option generates an Echo Response Option supported by the local interface. The size of a DPLPMTUD probe
that confirms reception of each received Probe Packet. packet MUST NOT be constrained by the maximum PMTU set by network
layer mechanisms (such as PMTUD [RFC1063][RFC8201] or the IP Cache).
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 Packet with a Request Probe Option only when required by their probe with a Request Probe Option only when required by their local
local DPLPMTUD state machine, i.e., when probing to grow the PLPMTU DPLPMTUD state machine, i.e., when confirming the base PMTU for the
or to confirm the current PLPMTU. path, probing to increase the PLPMTU or to confirm the current
PLPMTU.
Implementations MAY track multiple requests and respond acknowledging 4.1. Packet Probes using the Echo Request Option Request Option
them with a single packet.
This section describes a format of probe consisting of an empty UDP
datagram, UDP Options area and Padding. The UDP Options area
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 The UDP Options used in this method 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 Echo Request Option (RES) is set by a sending PL to solicit a
response from a remote endpoint. A four-byte token identifies response from a remote UDP Options receiver. A four-byte token
each request. identifies each request.
* The Echo Response Option (REQ) is generated by the UDP Options * The Echo Response Option (REQ) is generated by the UDP Options
receiver in response to reception of a previously received Echo receiver in response to reception of a previously received Echo
Request Option. Each Echo Response Option echoes a previously Request Option. Each Echo Response Option echoes a previously
received four-byte token. received four-byte token.
The token value allows implementations to distinguish between The token value allows a sender to distinguish between
acknowledgements for initial Probe Packets and acknowledgements acknowledgements for initial probes and acknowledgements confirming
confirming receipt of subsequent Probe Packets (e.g., travelling receipt of subsequent probes (e.g., travelling along alternate paths
along alternate paths with a larger round trip time). This needs with a larger round trip time). This needs each probe to be uniquely
each Probe Packet needs to be uniquely identifiable by the UDP identifiable by the UDP Options sender within the Maximum Segment
Options sender within the Maximum Segment Lifetime (MSL). The UDP Lifetime (MSL). The UDP Options sender therefore MUST NOT recycle
Options sender therefore MUST NOT recycle token values until they token values until they have expired or have been acknowledged. A
have expired or have been acknowledged. A four byte value for the four byte value for the token field provides sufficient space for
token field provides sufficient space for multiple unique probes to multiple unique probes to be made within the MSL.
be made within the MSL.
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]).
The procedure to handle the loss of a datagram is the responsibility 4.2. DPLPMTUD Procedures for UDP Options
of the sender of the request. Implementations MAY track multiple
requests and respond to them with a single packet carrying the Echo
Response Option (REQ).
3.2.2. Sending Packet Probes that include Application Data DPLPMTUD utilizes three types of probes. These are described in the
following sections:
The RECOMMENDED approach to generating a Probe Packet is to send a * A probe to confirm the path can support the base PLPMTU.
probe formed of a UDP Options datagram contains only control
information, padded to the size required for the probe. This allows
"Probing using padding data", and avoids having to retransmit
application data when a probe fails.
If an application/transport needs protection from the loss of data in * A probe to detect whether the path can support a larger PLPMTU.
the Probe Packet payload, the application/ transport could perform
transport-layer retransmission/repair of the data block (e.g., by
retransmission after loss is detected or by duplicating the data
block in a datagram without the padding) [RFC8085].
3.3. Validating the Path with UDP Options * A probe to validate the path supports the current PLPMTU.
A PL also needs to validate that the path continues to support the 4.2.1. Confirmation of Connectivity across a Path
PLPMTU discovered in a previous search for a suitable PLPMTU value
(see Section 6.1.4 of [RFC8899]). This confirmation MAY be provided
by an upper layer protocol confirming correct reception of data by
the remote PL, but there is no generic mechanism to access this upper
layer information.
This function can be implemented within UDP Options, by generating a The DPLPMTUD method requires a PL to confirm connectivity over the
Probe Packet of size PLPMTU to confirm the path. This Probe Packet path using the base PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP
MUST elicit a response from the remote PL and could use either the does not offer a mechanism for this.
ECHO Response Option or the TimeStamp option (see Section 5.9
[I-D.ietf-tsvwg-udp-options]).
A sender MAY choose to include application data in Probe Packets (see UDP Options can provide this required functionality. A UDP Options
Section 4.1 of [RFC8899] for discussion of the merits and demerits of sender implementing this specification MUST elicit a positive
this approach). For example, this might reduce the need to send an confirmation of connectivity for the path, by sending a probe, padded
additional datagram when confirming that the current path supports to size BASE_PLPMTU. This confirmation probe MUST include a UDP
datagrams of size PLPMTU. Option that elicits a response from the remote endpoint (e.g., by
including the ECHO Request/Response Option) to confirm that a packet
of the size traversed the path.
3.3.1. Sending Packet Probes using Timestamps 4.2.2. Sending Probe Packets to Increase the PLPMTU
Reception of a valid Timestamp Option echoed by the remote endpoint From time to time, DPLPMTUD searches to detect whether the current
can be used to infer connectivity. It can also confirm that packets path can support a larger PLPMTU. When the remote endpoint
of the current size are being received by the remote PL. This can advertises a UDP Maximum Segment Size (MSS) option, this value can be
provide useful feedback, even over paths with asymmetric capacity used as a hint to initialise this search to increase the PLPMTU.
and/or that carry UDP Option flows that have asymmetric datagram
rates, because an echo of the most recent timestamp still indicates
reception of at least one packet of the transmitted size. This is
sufficient to confirm there is no black hole (see Section 2.1 of
[RFC2923]).
When sending a probe to increase the PLPMTU, such a Timestamp might Probe packets seeking to increase the PLPMTU SHOULD NOT carry
be unable to unambiguously identify that a specific Probe Packet has application data (see "Probing using padding data" in Section 4.1 of
been received [KP87]. Timestamp mechanisms therefore cannot be used [RFC8899]), since they will be lost whenever their size exceeds the
to confirm the reception of individual probe messages and cannot be actual PMTU.
used to stimulate a response from the remote peer.
Note: Probe Packets used to search for a larger PLPMTU MUST include A probe seeking to increase the PLPMTU MUST elicit a positive
the Echo Request Option. confirmation that the path has delivered a Datagram of the specific
probed size and therefore SHOULD include the Echo Request Option
Request Option.
3.4. PTB Message Handling for this Method 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
layer protocol.
A UDP Options sender can ignore received ICMP PTB messages, and this 4.2.3. Validating the Path with UDP Options
support is OPTIONAL for use with DPLPMTUD.
A UDP Options sender that utilises ICMP PTB messages received to a A PL using DPLPMTUD needs to validate that a path continues to
Probe Packet MUST use the quoted packet to validate the UDP port support the PLPMTU discovered in a previous search for a suitable
information in combination with the token and/or timestamp value PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends
contained in the UDP Option, before processing the packet using the probes in the DPLPMTUD SEARCH_COMPLETE state i.e., to detect black-
DPLPMTUD method (see Section 4.4.1 of [RFC8899]). An implementation holing of data (see Section 4.2 of [RFC8899]).
unable to support this validation needs to ignore received ICMP PTB
messages.
4. Acknowledgements This function can be implemented within UDP Options, by generating a
probe of size PLPMTU which MUST include a UDP Option to elicit a
positive confirmation that the path has delivered the probe. This
confirmation probe MAY use "Probing using padding data" or "Probing
using application data and padding data" (see Section 4.1 of
[RFC8899]) or can construct a probe packet that does not carry any
application data, as described in a previous section.
4.2.4. Sending Packet Probes that include Application Data
The method can be designed to only use probes that are formed of a
UDP Options datagram containing control information, padded to the
required size. 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
PLPMTU. These probes do not form a part of the end-to-end transport
data and a receiver does not deliver these to the upper layer
protocol. A simple implementation of the method might be designed to
only use this format for all probes.
Probe used to confirm the connectivity or to validate support for the
current PLPMTU are also permitted to carry application data, since
this type of probe is expected to be successful. Section 4.1 of
[RFC8899] provides a discussion of the merits and demerits of
including application data. For example, this reduces the need to
send an additional datagram when confirming that the current path
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
delivered reliably.
4.3. PTB Message Handling for this Method
Support for receiving ICMP PTB messages is OPTIONAL for use with
DPLPMTUD. A UDP Options sender can therefore ignore received ICMP
PTB messages.
A UDP Options sender that utilises ICMP PTB messages received in
response to a probe packet MUST use the quoted packet to validate the
UDP port information in combination with the token and/or timestamp
value contained in the UDP Option, before processing the packet using
the DPLPMTUD method (see Section 4.4.1 of [RFC8899]). An
implementation unable to support this validation needs to ignore
received ICMP PTB messages.
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.
5. IANA Considerations 6. IANA Considerations
This memo includes no requests to IANA. This memo includes no requests to IANA.
6. 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/RES message 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 utilises 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.
7. References 8. References
7.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
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13,
19 June 2021, <https://www.ietf.org/archive/id/draft-ietf- 19 June 2021, <https://www.ietf.org/archive/id/draft-ietf-
tsvwg-udp-options-13.txt>. tsvwg-udp-options-13.txt>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
skipping to change at page 8, line 33 skipping to change at page 8, line 29
[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>.
7.2. Informative References [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>.
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 8.2. Informative References
Estimates in Reliable Transport Protocols", 1987.
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, MTU discovery options", RFC 1063, DOI 10.17487/RFC1063,
July 1988, <https://www.rfc-editor.org/info/rfc1063>. July 1988, <https://www.rfc-editor.org/info/rfc1063>.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.
[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,
skipping to change at page 10, line 4 skipping to change at page 9, line 48
* Tidied language to clarify the method. * Tidied language to clarify the method.
Individual draft-04 Individual draft-04
* Reworded text on probing with data a little * Reworded text on probing with data a little
* Removed paragraph on suspending ICMP PTB suspension. * Removed paragraph on suspending ICMP PTB suspension.
Working group draft-00 Working group draft-00
* First Working Group Version
* -00 First Working Group Version
* RFC8899 call search_done SEARCH_COMPLETE, fix * RFC8899 call search_done SEARCH_COMPLETE, fix
Working group draft -01
* Update to reflect new fragmentation design in UDP Options.
* Add a description of uses of DPLPMTUD with UDP Options.
* Add a description on how to form probe packets with padding.
* Say that MSS options can be used to initialise the search
algorithm.
* Say that the recommended approach is to not use user data for
probes.
* Attempts to clarify and improve wording throughout.
* Remove text saying you can respond to multiple probes in a single
packet.
* Simplified text by removing options that don't yield benefit.
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. 52 change blocks. 
178 lines changed or deleted 205 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/