draft-ietf-tsvwg-datagram-plpmtud-08.txt   draft-ietf-tsvwg-datagram-plpmtud-09.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Updates4821 (if approved) University of Aberdeen Updates4821 (if approved) University of Aberdeen
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: 7 December 2019 I. Ruengeler Expires: 7 May 2020 I. Ruengeler
T. Voelker T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
5 June 2019 4 November 2019
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-08 draft-ietf-tsvwg-datagram-plpmtud-09
Abstract Abstract
This document describes a robust method for Path MTU Discovery This document describes a robust method for Path MTU Discovery
(PMTUD) for datagram Packetization Layers (PLs). It describes an (PMTUD) for datagram Packetization Layers (PLs). It describes an
extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path
MTU Discovery for IPv4 and IPv6. The method allows a PL, or a MTU Discovery for IPv4 and IPv6. The method allows a PL, or a
datagram application that uses a PL, to discover whether a network datagram application that uses a PL, to discover whether a network
path can support the current size of datagram. This can be used to path can support the current size of datagram. This can be used to
detect and reduce the message size when a sender encounters a network detect and reduce the message size when a sender encounters a network
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 7 December 2019. This Internet-Draft will expire on 7 May 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction (name-introduction) . . . . . . . . . . . . . . 4
1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 1.1. Classical Path MTU Discovery
1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 (name-classical-path-mtu-discover) . . . . . . . . . . . 4
1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7 1.2. Packetization Layer Path MTU Discovery
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 (name-packetization-layer-path-mt) . . . . . . . . . . . 6
3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 10 1.3. Path MTU Discovery for Datagram Services
4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12 (name-path-mtu-discovery-for-data) . . . . . . . . . . . 7
4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12 2. Terminology (name-terminology) . . . . . . . . . . . . . . . 8
4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 14 3. Features Required to Provide Datagram PLPMTUD
(name-features-required-to-provid) . . . . . . . . . . . . . . 10
4. DPLPMTUD Mechanisms (name-dplpmtud-mechanisms) . . . . . . . 12
4.1. PLPMTU Probe Packets (name-plpmtu-probe-packets) . . . . 13
4.2. Confirmation of Probed Packet Size
(name-confirmation-of-probed-pack) . . . . . . . . . . . 14
4.3. Detection of Unsupported PLPMTU Size, aka Black Hole 4.3. Detection of Unsupported PLPMTU Size, aka Black Hole
Detection . . . . . . . . . . . . . . . . . . . . . . . . 14 Detection (name-detection-of-unsupported-pl) . . . . . . 14
4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 15 4.4. Disabling the Effect of PMTUD
4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 15 (name-disabling-the-effect-of-pmt) . . . . . . . . . . . 15
4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 16 4.5. Response to PTB Messages
5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 17 (name-response-to-ptb-messages) . . . . . . . . . . . . . 15
5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 18 4.5.1. Validation of PTB Messages
5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 18 (name-validation-of-ptb-messages) . . . . . . . . . . 16
5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 19 4.5.2. Use of PTB Messages
5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 20 (name-use-of-ptb-messages) . . . . . . . . . . . . . 17
5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 21 5. Datagram Packetization Layer PMTUD
5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 23 (name-datagram-packetization-laye) . . . . . . . . . . . . . . 18
5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26 5.1. DPLPMTUD Components (name-dplpmtud-components) . . . . . 18
5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26 5.1.1. Timers (name-timers) . . . . . . . . . . . . . . . . 19
5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27 5.1.2. Constants (name-constants) . . . . . . . . . . . . . 20
5.3.3. Resilience to Inconsistent Path Information . . . . . 27 5.1.3. Variables (name-variables) . . . . . . . . . . . . . 20
5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 28 5.1.4. Overview of DPLPMTUD Phases
6. Specification of Protocol-Specific Methods . . . . . . . . . 28 (name-overview-of-dplpmtud-phases) . . . . . . . . . 21
6.1. Application support for DPLPMTUD with UDP or 5.2. State Machine (name-state-machine) . . . . . . . . . . . 23
UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Search to Increase the PLPMTU
6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 (name-search-to-increase-the-plpm) . . . . . . . . . . . 26
6.1.2. Application Response . . . . . . . . . . . . . . . . 29 5.3.1. Probing for a larger PLPMTU
6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 (name-probing-for-a-larger-plpmtu) . . . . . . . . . 26
6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29 5.3.2. Selection of Probe Sizes
6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29 (name-selection-of-probe-sizes) . . . . . . . . . . . 27
6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 30 5.3.3. Resilience to Inconsistent Path Information
6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 30 (name-resilience-to-inconsistent-) . . . . . . . . . 28
6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 31 5.4. Robustness to Inconsistent Paths
6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 31 (name-robustness-to-inconsistent-) . . . . . . . . . . . 28
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 32 6. Specification of Protocol-Specific Methods
6.3.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 32 (name-specification-of-protocol-s) . . . . . . . . . . . . . . 28
6.3.2. Validating the Path with QUIC . . . . . . . . . . . . 33 6.1. Application support for DPLPMTUD with UDP or UDP-Lite
6.3.3. Handling of PTB Messages by QUIC . . . . . . . . . . 33 (name-application-support-for-dpl) . . . . . . . . . . . 28
6.4. DPLPMTUD for UDP-Options . . . . . . . . . . . . . . . . 33 6.1.1. Application Request
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 (name-application-request) . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6.1.2. Application Response
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 (name-application-response) . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1.3. Sending Application Probe Packets
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 (name-sending-application-probe-p) . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 36 6.1.4. Initial Connectivity
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 37 (name-initial-connectivity) . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.5. Validating the Path
(name-validating-the-path) . . . . . . . . . . . . . 30
6.1.6. Handling of PTB Messages
(name-handling-of-ptb-messages) . . . . . . . . . . . 30
6.2. DPLPMTUD for SCTP (name-dplpmtud-for-sctp) . . . . . . . 30
6.2.1. SCTP/IPv4 and SCTP/IPv6
(name-sctp-ipv4-and-sctp-ipv6) . . . . . . . . . . . 30
6.2.2. DPLPMTUD for SCTP/UDP
(name-dplpmtud-for-sctp-udp) . . . . . . . . . . . . 31
6.2.3. DPLPMTUD for SCTP/DTLS
(name-dplpmtud-for-sctp-dtls) . . . . . . . . . . . . 32
6.3. DPLPMTUD for QUIC (name-dplpmtud-for-quic) . . . . . . . 32
6.3.1. Initial Connectivity
(name-initial-connectivity-5) . . . . . . . . . . . . 33
6.3.2. Sending QUIC Probe Packets
(name-sending-quic-probe-packets) . . . . . . . . . . 33
6.3.3. Validating the Path with QUIC
(name-validating-the-path-with-qu) . . . . . . . . . 33
6.3.4. Handling of PTB Messages by QUIC
(name-handling-of-ptb-messages-by-q) . . . . . . . . 34
7. Acknowledgements (name-acknowledgements) . . . . . . . . . . 34
8. IANA Considerations (name-iana-considerations) . . . . . . . 34
9. Security Considerations (name-security-considerations) . . . 34
10. References (name-references) . . . . . . . . . . . . . . . . 35
10.1. Normative References (name-normative-references) . . . . 35
10.2. Informative References
(name-informative-references) . . . . . . . . . . . . . 36
A. Revision Notes (name-revision-notes) . . . . . . . . . . . . 37
B Authors' Addresses (name-authors-addresses) . . . . . . . . . 41
1. Introduction 1. Introduction
The IETF has specified datagram transport using UDP, SCTP, and DCCP, The IETF has specified datagram transport using UDP, SCTP, and DCCP,
as well as protocols layered on top of these transports (e.g., SCTP/ as well as protocols layered on top of these transports (e.g., SCTP/
UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP
network layer. This document describes a robust method for Path MTU network layer. This document describes a robust method for Path MTU
Discovery (PMTUD) that may be used with these transport protocols (or Discovery (PMTUD) that may be used with these transport protocols (or
the applications that use their transport service) to discover an the applications that use their transport service) to discover an
appropriate size of packet to use across an Internet path. appropriate size of packet to use across an Internet path.
1.1. Classical Path MTU Discovery 1.1. Classical Path MTU Discovery
Classical Path Maximum Transmission Unit Discovery (PMTUD) can be Classical Path Maximum Transmission Unit Discovery (PMTUD) can be
used with any transport that is able to process ICMP Packet Too Big used with any transport that is able to process ICMP Packet Too Big
(PTB) messages (e.g., [RFC1191] and [RFC8201]). In this document, (PTB) messages (e.g., [RFC1191] and [RFC8201]). In this document,
the term PTB message is applied to both IPv4 ICMP Unreachable the term PTB message is applied to both IPv4 ICMP Unreachable
messages (type 3) that carry the error Fragmentation Needed (Type 3, messages (type 3) that carry the error Fragmentation Needed (Type 3,
Code 4) [RFC0792] and ICMPv6 packet too big messages (Type 2) Code 4) [RFC0792] and ICMPv6 Packet Too Big messages (Type 2)
[RFC4443]. When a sender receives a PTB message, it reduces the [RFC4443]. When a sender receives a PTB message, it reduces the
effective MTU to the value reported as the Link MTU in the PTB effective MTU to the value reported as the Link MTU in the PTB
message, and a method that from time-to-time increases the packet message, and a method that from time-to-time increases the packet
size in attempt to discover an increase in the supported PMTU. The size in attempt to discover an increase in the supported PMTU. The
packets sent with a size larger than the current effective PMTU are packets sent with a size larger than the current effective PMTU are
known as probe packets. known as probe packets.
Packets not intended as probe packets are either fragmented to the Packets not intended as probe packets are either fragmented to the
current effective PMTU, or the attempt to send fails with an error current effective PMTU, or the attempt to send fails with an error
code. Applications are sometimes provided with a primitive to let code. Applications are sometimes provided with a primitive to let
skipping to change at page 6, line 39 skipping to change at page 7, line 10
for the largest size of unfragmented datagram that can be sent over a for the largest size of unfragmented datagram that can be sent over a
network path. Probe packets are sent with a progressively larger network path. Probe packets are sent with a progressively larger
packet size. If a probe packet is successfully delivered (as packet size. If a probe packet is successfully delivered (as
determined by the PL), then the PLPMTU is raised to the size of the determined by the PL), then the PLPMTU is raised to the size of the
successful probe. If no response is received to a probe packet, the successful probe. If no response is received to a probe packet, the
method reduces the probe size. The result of probing with the PLPMTU method reduces the probe size. The result of probing with the PLPMTU
is used to set the application MPS. is used to set the application MPS.
PLPMTUD introduces flexibility in the implementation of PMTU PLPMTUD introduces flexibility in the implementation of PMTU
discovery. At one extreme, it can be configured to only perform ICMP discovery. At one extreme, it can be configured to only perform ICMP
black Hole Detection and recovery to increase the robustness of Black Hole Detection and recovery to increase the robustness of
Classical PMTUD, or at the other extreme, all PTB processing can be Classical PMTUD, or at the other extreme, all PTB processing can be
disabled and PLPMTUD can completely replace Classical PMTUD. disabled and PLPMTUD can completely replace Classical PMTUD (see
Section 4.5).
PLPMTUD can also include additional consistency checks without PLPMTUD can also include additional consistency checks without
increasing the risk that data is lost when probing to discover the increasing the risk that data is lost when probing to discover the
path MTU. For example, information available at the PL, or higher path MTU. For example, information available at the PL, or higher
layers, enables received PTB messages to be validated before being layers, enables received PTB messages to be validated before being
utilized. utilized.
1.3. Path MTU Discovery for Datagram Services 1.3. Path MTU Discovery for Datagram Services
Section 5 of this document presents a set of algorithms for datagram Section 5 of this document presents a set of algorithms for datagram
skipping to change at page 14, line 20 skipping to change at page 14, line 35
Transport protocols can include end-to-end methods that detect and Transport protocols can include end-to-end methods that detect and
report reception of specific datagrams that they send (e.g., DCCP and report reception of specific datagrams that they send (e.g., DCCP and
SCTP provide keep-alive/heartbeat features). When supported, this SCTP provide keep-alive/heartbeat features). When supported, this
mechanism SHOULD also be used by DPLPMTUD to acknowledge reception of mechanism SHOULD also be used by DPLPMTUD to acknowledge reception of
a probe packet. a probe packet.
A PL that does not acknowledge data reception (e.g., UDP and UDP- A PL that does not acknowledge data reception (e.g., UDP and UDP-
Lite) is unable itself to detect when the packets that it sends are Lite) is unable itself to detect when the packets that it sends are
discarded because their size is greater than the actual PMTU. These discarded because their size is greater than the actual PMTU. These
PLs need to either rely on an application protocol to detect this PLs need to either rely on an application protocol to detect this
loss, or make use of an additional transport method such as UDP- loss.
Options [I-D.ietf-tsvwg-udp-options].
Section 6 specifies this function for a set of IETF-specified Section 6 specifies this function for a set of IETF-specified
protocols. protocols.
4.3. Detection of Unsupported PLPMTU Size, aka Black Hole Detection 4.3. Detection of Unsupported PLPMTU Size, aka Black Hole Detection
A PL sender needs to reduce the PLPMTU when it discovers the actual A PL sender needs to reduce the PLPMTU when it discovers the actual
PMTU supported by a network path is less than the PLPMTU. This can PMTU supported by a network path is less than the PLPMTU. This can
be triggered when a validated PTB message is received, or by another be triggered when a validated PTB message is received, or by another
event that indicates the network path no longer sustains the current event that indicates the network path no longer sustains the current
skipping to change at page 15, line 19 skipping to change at page 15, line 33
additional packets being sent. additional packets being sent.
When the method detects the current PLPMTU is not supported, DPLPMTUD When the method detects the current PLPMTU is not supported, DPLPMTUD
sets a lower MPS. The PL then confirms that the updated PLPMTU can sets a lower MPS. The PL then confirms that the updated PLPMTU can
be successfully used across the path. The PL could need to send a be successfully used across the path. The PL could need to send a
probe packet with a size less than the size of the data block probe packet with a size less than the size of the data block
generated by an application. In this case, the PL could provide a generated by an application. In this case, the PL could provide a
way to fragment a datagram at the PL, or use a control packet as the way to fragment a datagram at the PL, or use a control packet as the
packet probe. packet probe.
4.4. Response to PTB Messages 4.4. Disabling the Effect of PMTUD
A PL implementing this specification MUST suspend network layer
processing of outgoing packets that enforces a PMTU
[RFC1191][RFC8201] for each flow utilising DPLPMTUD, and instead use
DPLPMTUD to control the size of packets that are sent by a flow.
This removes the need for the network layer to drop or fragment sent
packets that have a size greater than the PMTU.
4.5. Response to PTB Messages
This method requires the DPLPMTUD sender to validate any received PTB This method requires the DPLPMTUD sender to validate any received PTB
message before using the PTB information. The response to a PTB message before using the PTB information. The response to a PTB
message depends on the PTB_SIZE indicated in the PTB message, the message depends on the PTB_SIZE indicated in the PTB message, the
state of the PLPMTUD state machine, and the IP protocol being used. state of the PLPMTUD state machine, and the IP protocol being used.
Section 4.4.1 first describes validation for both IPv4 ICMP Section 4.5.1 first describes validation for both IPv4 ICMP
Unreachable messages (type 3) and ICMPv6 packet too big messages, Unreachable messages (type 3) and ICMPv6 Packet Too Big messages,
both of which are referred to as PTB messages in this document. both of which are referred to as PTB messages in this document.
4.4.1. Validation of PTB Messages 4.5.1. Validation of PTB Messages
This section specifies utilization of PTB messages. This section specifies utilization of PTB messages.
* A simple implementation MAY ignore received PTB messages and in * A simple implementation MAY ignore received PTB messages and in
this case the PLPMTU is not updated when a PTB message is this case the PLPMTU is not updated when a PTB message is
received. received.
* An implementation that supports PTB messages MUST validate * An implementation that supports PTB messages MUST validate
messages before they are further processed. messages before they are further processed.
skipping to change at page 16, line 23 skipping to change at page 16, line 46
These checks are intended to provide protection from packets that These checks are intended to provide protection from packets that
originate from a node that is not on the network path. A PTB message originate from a node that is not on the network path. A PTB message
that does not complete the validation MUST NOT be further utilized by that does not complete the validation MUST NOT be further utilized by
the DPLPMTUD method. the DPLPMTUD method.
PTB messages that have been validated MAY be utilized by the DPLPMTUD PTB messages that have been validated MAY be utilized by the DPLPMTUD
algorithm, but MUST NOT be used directly to set the PLPMTU. A method algorithm, but MUST NOT be used directly to set the PLPMTU. A method
that utilizes these PTB messages can improve the speed at the which that utilizes these PTB messages can improve the speed at the which
the algorithm detects an appropriate PLPMTU, compared to one that the algorithm detects an appropriate PLPMTU, compared to one that
relies solely on probing. Section 4.4.2 describes this processing. relies solely on probing. Section 4.5.2 describes this processing.
4.4.2. Use of PTB Messages 4.5.2. Use of PTB Messages
A set of checks are intended to provide protection from a router that A set of checks are intended to provide protection from a router that
reports an unexpected PTB_SIZE. The PL also needs to check that the reports an unexpected PTB_SIZE. The PL also needs to check that the
indicated PTB_SIZE is less than the size used by probe packets and indicated PTB_SIZE is less than the size used by probe packets and
larger than minimum size accepted. larger than minimum size accepted.
This section provides a summary of how PTB messages can be utilized. This section provides a summary of how PTB messages can be utilized.
This processing depends on the PTB_SIZE and the current value of a This processing depends on the PTB_SIZE and the current value of a
set of variables: set of variables:
skipping to change at page 17, line 27 skipping to change at page 18, line 8
PLPMTU < PTB_SIZE < PROBED_SIZE PLPMTU < PTB_SIZE < PROBED_SIZE
* The PLPMTU continues to be valid, but the last PROBED_SIZE * The PLPMTU continues to be valid, but the last PROBED_SIZE
searched was larger than the actual PMTU. searched was larger than the actual PMTU.
* The PLPMTU is not updated. * The PLPMTU is not updated.
* The PL can use the reported PTB_SIZE from the PTB message as * The PL can use the reported PTB_SIZE from the PTB message as
the next search point when it resumes the search algorithm. the next search point when it resumes the search algorithm.
xxx Author Note: Do we want to specify how to handle PTB Message with
PTB_SIZE = 0? xxx
5. Datagram Packetization Layer PMTUD 5. Datagram Packetization Layer PMTUD
This section specifies Datagram PLPMTUD (DPLPMTUD). The method can This section specifies Datagram PLPMTUD (DPLPMTUD). The method can
be introduced at various points (as indicated with * in the figure be introduced at various points (as indicated with * in the figure
below) in the IP protocol stack to discover the PLPMTU so that an below) in the IP protocol stack to discover the PLPMTU so that an
application can utilize an appropriate MPS for the current network application can utilize an appropriate MPS for the current network
path. DPLPMTUD SHOULD NOT be used by an application if it is already path. DPLPMTUD SHOULD NOT be used by an application if it is already
used in a lower layer. used in a lower layer.
+----------------------+ +----------------------+
skipping to change at page 18, line 30 skipping to change at page 18, line 42
| Network Interface | | Network Interface |
+----------------------+ +----------------------+
Figure 1: Examples where DPLPMTUD can be implemented Figure 1: Examples where DPLPMTUD can be implemented
The central idea of DPLPMTUD is probing by a sender. Probe packets The central idea of DPLPMTUD is probing by a sender. Probe packets
are sent to find the maximum size of a user message that can be are sent to find the maximum size of a user message that can be
completely transferred across the network path from the sender to the completely transferred across the network path from the sender to the
destination. destination.
The folloowing sections identify the components needed for The following sections identify the components needed for
implementation, provides an overvoew of the phases of operation, and implementation, provides an overvoew of the phases of operation, and
specifies the state machine and search algorithm. specifies the state machine and search algorithm.
5.1. DPLPMTUD Components 5.1. DPLPMTUD Components
This section describes the timers, constants, and variables of This section describes the timers, constants, and variables of
DPLPMTUD. DPLPMTUD.
5.1.1. Timers 5.1.1. Timers
skipping to change at page 19, line 10 skipping to change at page 19, line 25
of the UDP Usage Guidelines [RFC8085]. of the UDP Usage Guidelines [RFC8085].
If the PL has a path Round Trip Time (RTT) If the PL has a path Round Trip Time (RTT)
estimate and timely acknowledgements the estimate and timely acknowledgements the
PROBE_TIMER can be derived from the PL RTT PROBE_TIMER can be derived from the PL RTT
estimate. estimate.
PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period
a sender will continue to use the current a sender will continue to use the current
PLPMTU, after which it re-enters the Search PLPMTU, after which it re-enters the Search
phase. This timer has a period of 600 secs, as phase. This timer has a period of 600 seconds,
recommended by PLPMTUD [RFC4821]. as recommended by PLPMTUD [RFC4821].
DPLPMTUD MAY inhibit sending probe packets when DPLPMTUD MAY inhibit sending probe packets when
no application data has been sent since the no application data has been sent since the
previous probe packet. A PL preferring to use previous probe packet. A PL preferring to use
an up-to-data PMTU once user data is sent again, an up-to-data PMTU once user data is sent again,
can choose to continue PMTU discovery for each can choose to continue PMTU discovery for each
path. However, this may result in sending path. However, this may result in sending
additional packets. additional packets.
CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST
skipping to change at page 20, line 4 skipping to change at page 20, line 17
additional packets. additional packets.
An implementation could implement the various timers using a single An implementation could implement the various timers using a single
timer. timer.
5.1.2. Constants 5.1.2. Constants
The following constants are defined: The following constants are defined:
MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT
counter (see Section 5.1.3). The default value of counter (see Section 5.1.3). MAX_PROBES represents the
MAX_PROBES is 10. limit for the number of consecutive probe attempts of
any size. The default value of MAX_PROBES is 10.
MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size. MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size.
For IPv6, this value is 1280 bytes, as specified in For IPv6, this value is 1280 bytes, as specified in
[RFC2460]. For IPv4, the minimum value is 68 bytes. [RFC2460]. For IPv4, the minimum value is 68 bytes.
Note: An IPv4 router is required to be able to forward a Note: An IPv4 router is required to be able to forward a
datagram of 68 bytes without further fragmentation. datagram of 68 bytes without further fragmentation.
This is the combined size of an IPv4 header and the This is the combined size of an IPv4 header and the
minimum fragment size of 8 bytes. In addition, minimum fragment size of 8 bytes. In addition,
receivers are required to be able to reassemble receivers are required to be able to reassemble
skipping to change at page 22, line 5 skipping to change at page 22, line 31
| timer | | algorithm | timer | | algorithm
| expired | | completed | expired | | completed
| | | | | |
| | v | | v
| +-----------------+ | +-----------------+
+---| Search Complete | +---| Search Complete |
+-----------------+ +-----------------+
Figure 3: DPLPMTUD Phases Figure 3: DPLPMTUD Phases
BASE_PMTU Confirmation Phase Base: The Base Phase confirms connectivity to the remote
* The BASE_PMTU Confirmation Phase confirms connectivity to the peer. This phase is implicit for a connection-
remote peer. This phase is implicit for a connection-oriented oriented PL (where it can be performed in a PL
PL (where it can be performed in a PL connection handshake). A connection handshake). A connectionless PL needs
connectionless PL needs to send an acknowledged probe packet to to send an acknowledged probe packet to confirm
confirm that the remote peer is reachable. that the remote peer is reachable. The sender also
confirms that BASE_PMTU is supported across the
* The sender also confirms that BASE_PMTU is supported across the network path.
network path.
* A PL that does not wish to support a path with a PLPMTU less
than BASE_PMTU can simplify the phase into a single step by
performing the connectivity checks with a probe of the
BASE_PMTU size.
* Once confirmed, DPLPMTUD enters the Search Phase. If this
phase fails to confirm, DPLPMTUD enters the Error Phase.
Search Phase
* The Search Phase utilizes a search algorithm to send probe
packets to seek to increase the PLPMTU.
* The algorithm concludes when it has found a suitable PLPMTU, by
entering the Search Complete Phase.
* A PL could respond to PTB messages using the PTB to advance or
terminate the search, see Section 4.4.
* Black Hole Detection can also terminate the search by entering A PL that does not wish to support a path with a
the BASE_PMTU Confirmation phase. PLPMTU less than BASE_PMTU can simplify the phase
into a single step by performing the connectivity
checks with a probe of the BASE_PMTU size.
Search Complete Phase Once confirmed, DPLPMTUD enters the Search Phase.
* The Search Complete Phase is entered when the PLPMTU is If this phase fails to confirm, DPLPMTUD enters the
supported across the network path. Error Phase.
* A PL can use a CONFIRMATION_TIMER to periodically repeat a Search: The Search Phase utilizes a search algorithm to
probe packet for the current PLPMTU size. If the sender is send probe packets to seek to increase the PLPMTU.
unable to confirm reachability (e.g., if the CONFIRMATION_TIMER The algorithm concludes when it has found a
expires) or the PL signals a lack of reachability, DPLPMTUD suitable PLPMTU, by entering the Search Complete
enters the BASE_PMTU Confirmation phase. Phase.
* The PMTU_RAISE_TIMER is used to periodically resume the search A PL could respond to PTB messages using the PTB to
phase to discover if the PLPMTU can be raised. advance or terminate the search, see Section 4.5.
* Black Hole Detection or receipt of a validated PTB message Search Complete: The Search Complete Phase is entered when the
Section 4.4.1) can cause the sender to enter the BASE_PMTU PLPMTU is supported across the network path. A PL
Confirmation Phase. can use a CONFIRMATION_TIMER to periodically repeat
a probe packet for the current PLPMTU size. If the
sender is unable to confirm reachability (e.g., if
the CONFIRMATION_TIMER expires) or the PL signals a
lack of reachability, DPLPMTUD enters the Base
phase.
Error Phase The PMTU_RAISE_TIMER is used to periodically resume
* The Error Phase is entered when there is conflicting or invalid the search phase to discover if the PLPMTU can be
PLPMTU information for the path (e.g. a failure to support the raised. Black Hole Detection or receipt of a
BASE_PMTU) that cause DPLPMTUD to be unable to progress and the validated PTB message (see Section 4.5.1) can cause
PLPMTU is lowered the sender to enter the Base Phase.
* DPLPMTUD remains in the Error Phase until a consistent view of Error: The Error Phase is entered when there is
the path can be discovered and it has also been confirmed that conflicting or invalid PLPMTU information for the
the path supports the BASE_PMTU (or DPLPMTUD is suspended). path (e.g. a failure to support the BASE_PMTU) that
cause DPLPMTUD to be unable to progress and the
PLPMTU is lowered.
* Note: MIN_PMTU may be identical to BASE_PMTU, simplifying the DPLPMTUD remains in the Error Phase until a
actions in this phase. consistent view of the path can be discovered and
it has also been confirmed that the path supports
the BASE_PMTU (or DPLPMTUD is suspended).
An implementation that only reduces the PLPMTU to a suitable size An implementation that only reduces the PLPMTU to a suitable size
would be sufficient to ensure reliable operation, but can be very would be sufficient to ensure reliable operation, but can be very
inefficient when the actual PMTU changes or when the method (for inefficient when the actual PMTU changes or when the method (for
whatever reason) makes a suboptimal choice for the PLPMTU. whatever reason) makes a suboptimal choice for the PLPMTU.
A full implementation of DPLPMTUD provides an algorithm enabling the A full implementation of DPLPMTUD provides an algorithm enabling the
DPLPMTUD sender to increase the PLPMTU following a change in the DPLPMTUD sender to increase the PLPMTU following a change in the
characteristics of the path, such as when a link is reconfigured with characteristics of the path, such as when a link is reconfigured with
a larger MTU, or when there is a change in the set of links traversed a larger MTU, or when there is a change in the set of links traversed
skipping to change at page 26, line 32 skipping to change at page 26, line 35
by the PL. The state is exited when packet probes by the PL. The state is exited when packet probes
no longer detect the error or when the PL indicates no longer detect the error or when the PL indicates
that connectivity has been lost. that connectivity has been lost.
Implementations are permitted to enable endpoint Implementations are permitted to enable endpoint
fragmentation if the DPLPMTUD is unable to validate fragmentation if the DPLPMTUD is unable to validate
MIN_PMTU within PROBE_COUNT probes. If DPLPMTUD is MIN_PMTU within PROBE_COUNT probes. If DPLPMTUD is
unable to validate MIN_PMTU the implementation unable to validate MIN_PMTU the implementation
should transition to the DISABLED state. should transition to the DISABLED state.
Note: MIN_PMTU may be identical to BASE_PMTU,
simplifying the actions in this state.
5.3. Search to Increase the PLPMTU 5.3. Search to Increase the PLPMTU
This section describes the algorithms used by DPLPMTUD to search for This section describes the algorithms used by DPLPMTUD to search for
a larger PLPMTU. a larger PLPMTU.
5.3.1. Probing for a larger PLPMTU 5.3.1. Probing for a larger PLPMTU
Implementations use a search algorithm across the search range to Implementations use a search algorithm across the search range to
determine whether a larger PLPMTU can be supported across a network determine whether a larger PLPMTU can be supported across a network
path. path.
skipping to change at page 27, line 37 skipping to change at page 27, line 43
The search algorithm needs to determine a minimum useful gain in The search algorithm needs to determine a minimum useful gain in
PLPMTU. It would not be constructive for a PL sender to attempt to PLPMTU. It would not be constructive for a PL sender to attempt to
probe for all sizes. This would incur unnecessary load on the path probe for all sizes. This would incur unnecessary load on the path
and has the undesirable effect of slowing the time to reach a more and has the undesirable effect of slowing the time to reach a more
optimal MPS. Implementations SHOULD select the set of probe packet optimal MPS. Implementations SHOULD select the set of probe packet
sizes to maximize the gain in PLPMTU from each search step. sizes to maximize the gain in PLPMTU from each search step.
Implementations could optimize the search procedure by selecting step Implementations could optimize the search procedure by selecting step
sizes from a table of common PMTU sizes. When selecting the sizes from a table of common PMTU sizes. When selecting the
appropriate next size to search, an implementor ought to also appropriate next size to search, an implementer ought to also
consider that there can be common sizes of MPS that applications seek consider that there can be common sizes of MPS that applications seek
to use, and their could be common sizes of MTU used within the to use, and their could be common sizes of MTU used within the
network. network.
5.3.3. Resilience to Inconsistent Path Information 5.3.3. Resilience to Inconsistent Path Information
A decision to increase the PLPMTU needs to be resilient to the A decision to increase the PLPMTU needs to be resilient to the
possibility that information learned about the network path is possibility that information learned about the network path is
inconsistent. A path is inconsistent, when, for example, probe inconsistent. A path is inconsistent, when, for example, probe
packets are lost due to other reasons (i. e. not packet size) or due packets are lost due to other reasons (i. e. not packet size) or due
skipping to change at page 29, line 34 skipping to change at page 29, line 46
to reach the destination. to reach the destination.
6.1.3. Sending Application Probe Packets 6.1.3. Sending Application Probe Packets
A probe packet that may carry an application data block, but the A probe packet that may carry an application data block, but the
successful transmission of this data is at risk when used for successful transmission of this data is at risk when used for
probing. Some applications may prefer to use a probe packet that probing. Some applications may prefer to use a probe packet that
does not carry an application data block to avoid disruption to data does not carry an application data block to avoid disruption to data
transfer. transfer.
6.1.4. Validating the Path 6.1.4. Initial Connectivity
An application that does not have other higher-layer information
confirming connectivity with the remote peer SHOULD implement a
connectivity mechanism using acknowledged probe packets before
entering the BASE state.
6.1.5. Validating the Path
An application that does not have other higher-layer information An application that does not have other higher-layer information
confirming correct delivery of datagrams SHOULD implement the confirming correct delivery of datagrams SHOULD implement the
CONFIRMATION_TIMER to periodically send probe packets while in the CONFIRMATION_TIMER to periodically send probe packets while in the
SEARCH_COMPLETE state. SEARCH_COMPLETE state.
6.1.5. Handling of PTB Messages 6.1.6. Handling of PTB Messages
An application that is able and wishes to receive PTB messages MUST An application that is able and wishes to receive PTB messages MUST
perform ICMP validation as specified in Section 5.2 of [RFC8085]. perform ICMP validation as specified in Section 5.2 of [RFC8085].
This requires that the application to check each received PTB This requires that the application to check each received PTB
messages to validate it is received in response to transmitted messages to validate it is received in response to transmitted
traffic and that the reported PTB_SIZE is less than the current traffic and that the reported PTB_SIZE is less than the current
probed size (see Section 4.4.2). A validated PTB message MAY be used probed size (see Section 4.5.2). A validated PTB message MAY be used
as input to the DPLPMTUD algorithm, but MUST NOT be used directly to as input to the DPLPMTUD algorithm, but MUST NOT be used directly to
set the PLPMTU. set the PLPMTU.
6.2. DPLPMTUD for SCTP 6.2. DPLPMTUD for SCTP
Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
method for SCTP. It recommends the use of the PAD chunk, defined in method for SCTP. It recommends the use of the PAD chunk, defined in
[RFC4820] to be attached to a minimum length HEARTBEAT chunk to build [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
a probe packet. This enables probing without affecting the transfer a probe packet. This enables probing without affecting the transfer
of user messages and without interfering with congestion control. of user messages and without interfering with congestion control.
This is preferred to using DATA chunks (with padding as required) as This is preferred to using DATA chunks (with padding as required) as
path probes. path probes.
XXX Author Note: Future versions of this document might define a
parameter contained in the INIT and INIT ACK chunk to indicate the
remote peer MTU to the local peer. However, multihoming makes this a
bit complex, so it might not be worth doing. XXX
6.2.1. SCTP/IPv4 and SCTP/IPv6 6.2.1. SCTP/IPv4 and SCTP/IPv6
6.2.1.1. Initial Connectivity
The base protocol is specified in [RFC4960]. This provides an The base protocol is specified in [RFC4960]. This provides an
acknowledged PL. A sender can therefore enter the BASE state as soon acknowledged PL. A sender can therefore enter the BASE state as soon
as connectivity has been confirmed. as connectivity has been confirmed.
6.2.1.1. Sending SCTP Probe Packets 6.2.1.2. Sending SCTP Probe Packets
Probe packets consist of an SCTP common header followed by a Probe packets consist of an SCTP common header followed by a
HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control
the length of the probe packet. The HEARTBEAT chunk is used to the length of the probe packet. The HEARTBEAT chunk is used to
trigger the sending of a HEARTBEAT ACK chunk. The reception of the trigger the sending of a HEARTBEAT ACK chunk. The reception of the
HEARTBEAT ACK chunk acknowledges reception of a successful probe. HEARTBEAT ACK chunk acknowledges reception of a successful probe.
The HEARTBEAT chunk carries a Heartbeat Information parameter which The HEARTBEAT chunk carries a Heartbeat Information parameter which
should include, besides the information suggested in [RFC4960], the should include, besides the information suggested in [RFC4960], the
probe size, which is the size of the complete datagram. The size of probe size, which is the size of the complete datagram. The size of
skipping to change at page 30, line 49 skipping to change at page 31, line 15
request and the PAD chunk header. The payload of the PAD chunk request and the PAD chunk header. The payload of the PAD chunk
contains arbitrary data. contains arbitrary data.
To avoid fragmentation of retransmitted data, probing starts right To avoid fragmentation of retransmitted data, probing starts right
after the PL handshake, before data is sent. Assuming this behavior after the PL handshake, before data is sent. Assuming this behavior
(i.e., the PMTU is smaller than or equal to the interface MTU), this (i.e., the PMTU is smaller than or equal to the interface MTU), this
process will take a few round trip time periods depending on the process will take a few round trip time periods depending on the
number of PMTU sizes probed. The Heartbeat timer can be used to number of PMTU sizes probed. The Heartbeat timer can be used to
implement the PROBE_TIMER. implement the PROBE_TIMER.
6.2.1.2. Validating the Path with SCTP 6.2.1.3. Validating the Path with SCTP
Since SCTP provides an acknowledged PL, a sender MUST NOT implement Since SCTP provides an acknowledged PL, a sender MUST NOT implement
the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.2.1.3. PTB Message Handling by SCTP 6.2.1.4. PTB Message Handling by SCTP
Normal ICMP validation MUST be performed as specified in Appendix C Normal ICMP validation MUST be performed as specified in Appendix C
of [RFC4960]. This requires that the first 8 bytes of the SCTP of [RFC4960]. This requires that the first 8 bytes of the SCTP
common header are quoted in the payload of the PTB message, which can common header are quoted in the payload of the PTB message, which can
be the case for ICMPv4 and is normally the case for ICMPv6. be the case for ICMPv4 and is normally the case for ICMPv6.
When a PTB message has been validated, the PTB_SIZE reported in the When a PTB message has been validated, the PTB_SIZE reported in the
PTB message SHOULD be used with the DPLPMTUD algorithm, providing PTB message SHOULD be used with the DPLPMTUD algorithm, providing
that the reported PTB_SIZE is less than the current probe size (see that the reported PTB_SIZE is less than the current probe size (see
Section 4.4). Section 4.5).
6.2.2. DPLPMTUD for SCTP/UDP 6.2.2. DPLPMTUD for SCTP/UDP
The UDP encapsulation of SCTP is specified in [RFC6951]. The UDP encapsulation of SCTP is specified in [RFC6951].
6.2.2.1. Sending SCTP/UDP Probe Packets 6.2.2.1. Initial Connectivity
Packet probing can be performed as specified in Section 6.2.1.1. The A sender can enter the BASE state as soon as SCTP connectivity has
been confirmed.
6.2.2.2. Sending SCTP/UDP Probe Packets
Packet probing can be performed as specified in Section 6.2.1.2. The
maximum payload is reduced by 8 bytes, which has to be considered maximum payload is reduced by 8 bytes, which has to be considered
when filling the PAD chunk. when filling the PAD chunk.
6.2.2.2. Validating the Path with SCTP/UDP 6.2.2.3. Validating the Path with SCTP/UDP
Since SCTP provides an acknowledged PL, a sender MUST NOT implement Since SCTP provides an acknowledged PL, a sender MUST NOT implement
the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.2.2.3. Handling of PTB Messages by SCTP/UDP 6.2.2.4. Handling of PTB Messages by SCTP/UDP
ICMP validation MUST be performed for PTB messages as specified in ICMP validation MUST be performed for PTB messages as specified in
Appendix C of [RFC4960]. This requires that the first 8 bytes of the Appendix C of [RFC4960]. This requires that the first 8 bytes of the
SCTP common header are contained in the PTB message, which can be the SCTP common header are contained in the PTB message, which can be the
case for ICMPv4 (but note the UDP header also consumes a part of the case for ICMPv4 (but note the UDP header also consumes a part of the
quoted packet header) and is normally the case for ICMPv6. When the quoted packet header) and is normally the case for ICMPv6. When the
validation is completed, the PTB_SIZE indicated in the PTB message validation is completed, the PTB_SIZE indicated in the PTB message
SHOULD be used with the DPLPMTUD providing that the reported PTB_SIZE SHOULD be used with the DPLPMTUD providing that the reported PTB_SIZE
is less than the current probe size. is less than the current probe size.
6.2.3. DPLPMTUD for SCTP/DTLS 6.2.3. DPLPMTUD for SCTP/DTLS
The Datagram Transport Layer Security (DTLS) encapsulation of SCTP is The Datagram Transport Layer Security (DTLS) encapsulation of SCTP is
specified in [RFC8261]. It is used for data channels in WebRTC specified in [RFC8261]. It is used for data channels in WebRTC
implementations. implementations.
6.2.3.1. Sending SCTP/DTLS Probe Packets 6.2.3.1. Initial Connectivity
Packet probing can be done as specified in Section 6.2.1.1. A sender can enter the BASE state as soon as SCTP connectivity has
been confirmed.
6.2.3.2. Validating the Path with SCTP/DTLS 6.2.3.2. Sending SCTP/DTLS Probe Packets
Packet probing can be done as specified in Section 6.2.1.2.
6.2.3.3. Validating the Path with SCTP/DTLS
Since SCTP provides an acknowledged PL, a sender MUST NOT implement Since SCTP provides an acknowledged PL, a sender MUST NOT implement
the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.2.3.3. Handling of PTB Messages by SCTP/DTLS 6.2.3.4. Handling of PTB Messages by SCTP/DTLS
It is not possible to perform ICMP validation as specified in It is not possible to perform ICMP validation as specified in
[RFC4960], since even if the ICMP message payload contains sufficient [RFC4960], since even if the ICMP message payload contains sufficient
information, the reflected SCTP common header would be encrypted. information, the reflected SCTP common header would be encrypted.
Therefore it is not possible to process PTB messages at the PL. Therefore it is not possible to process PTB messages at the PL.
6.3. DPLPMTUD for QUIC 6.3. DPLPMTUD for QUIC
Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a
UDP-based transport that provides reception feedback. The UDP UDP-based transport that provides reception feedback. The UDP
skipping to change at page 32, line 42 skipping to change at page 33, line 19
The recommendation for QUIC endpoints implementing DPLPMTUD is that a The recommendation for QUIC endpoints implementing DPLPMTUD is that a
MPS is maintained for each combination of local and remote IP MPS is maintained for each combination of local and remote IP
addresses [I-D.ietf-quic-transport]. If a QUIC endpoint determines addresses [I-D.ietf-quic-transport]. If a QUIC endpoint determines
that the PMTU between any pair of local and remote IP addresses has that the PMTU between any pair of local and remote IP addresses has
fallen below an acceptable MPS, it needs to immediately cease sending fallen below an acceptable MPS, it needs to immediately cease sending
QUIC packets on the affected path. This could result in termination QUIC packets on the affected path. This could result in termination
of the connection if an alternative path cannot be found of the connection if an alternative path cannot be found
[I-D.ietf-quic-transport]. [I-D.ietf-quic-transport].
6.3.1. Sending QUIC Probe Packets 6.3.1. Initial Connectivity
The base protocol is specified in [I-D.ietf-quic-transport]. This
provides an acknowledged PL. A sender can therefore enter the BASE
state as soon as connectivity has been confirmed.
6.3.2. Sending QUIC Probe Packets
A probe packet consists of a QUIC Header and a payload containing A probe packet consists of a QUIC Header and a payload containing
PADDING Frames and a PING Frame. PADDING Frames are a single octet PADDING Frames and a PING Frame. PADDING Frames are a single octet
(0x00) and several of these can be used to create a probe packet of (0x00) and several of these can be used to create a probe packet of
size PROBED_SIZE. QUIC provides an acknowledged PL, a sender can size PROBED_SIZE. QUIC provides an acknowledged PL, a sender can
therefore enter the BASE state as soon as connectivity has been therefore enter the BASE state as soon as connectivity has been
confirmed. confirmed.
The current specification of QUIC sets the following: The current specification of QUIC sets the following:
* BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to * BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to
1200 bytes to confirm the path can support packets of a useful 1200 bytes to confirm the path can support packets of a useful
size. size.
* MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has * MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has
fallen below 1200 bytes MUST immediately stop sending on the fallen below 1200 bytes MUST immediately stop sending on the
affected path. affected path.
6.3.2. Validating the Path with QUIC 6.3.3. Validating the Path with QUIC
QUIC provides an acknowledged PL. A sender therefore MUST NOT QUIC provides an acknowledged PL. A sender therefore MUST NOT
implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.3.3. Handling of PTB Messages by QUIC 6.3.4. Handling of PTB Messages by QUIC
QUIC operates over the UDP transport, and the guidelines on ICMP QUIC operates over the UDP transport, and the guidelines on ICMP
validation as specified in Section 5.2 of [RFC8085] therefore apply. validation as specified in Section 5.2 of [RFC8085] therefore apply.
In addition to UDP Port validation QUIC can validate an ICMP message In addition to UDP Port validation QUIC can validate an ICMP message
by looking for valid Connection IDs in the quoted packet. by looking for valid Connection IDs in the quoted packet.
6.4. DPLPMTUD for UDP-Options
UDP Options [I-D.ietf-tsvwg-udp-options] provides a way to extend UDP
to provide new transport mechanisms.
Support for using DPLPMTUD with UDP-Options is defined in the UDP-
Options specification [I-D.ietf-tsvwg-udp-options].
7. Acknowledgements 7. Acknowledgements
This work was partially funded by the European Union's Horizon 2020 This work was partially funded by the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). The views expressed are solely those of the author(s). (NEAT). The views expressed are solely those of the author(s).
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 34, line 23 skipping to change at page 34, line 51
There are cases where ICMP Packet Too Big (PTB) messages are not There are cases where ICMP Packet Too Big (PTB) messages are not
delivered due to policy, configuration or equipment design (see delivered due to policy, configuration or equipment design (see
Section 1.1), this method therefore does not rely upon PTB messages Section 1.1), this method therefore does not rely upon PTB messages
being received, but is able to utilize these when they are received being received, but is able to utilize these when they are received
by the sender. PTB messages could potentially be used to cause a by the sender. PTB messages could potentially be used to cause a
node to inappropriately reduce the PLPMTU. A node supporting node to inappropriately reduce the PLPMTU. A node supporting
DPLPMTUD MUST therefore appropriately validate the payload of PTB DPLPMTUD MUST therefore appropriately validate the payload of PTB
messages to ensure these are received in response to transmitted messages to ensure these are received in response to transmitted
traffic (i.e., a reported error condition that corresponds to a traffic (i.e., a reported error condition that corresponds to a
datagram actually sent by the path layer, see Section 4.4.1). datagram actually sent by the path layer, see Section 4.5.1).
An on-path attacker, able to create a PTB message could forge PTB An on-path attacker, able to create a PTB message could forge PTB
messages that include a valid quoted IP packet. Such an attack could messages that include a valid quoted IP packet. Such an attack could
be used to drive down the PLPMTU. There are two ways this method can be used to drive down the PLPMTU. There are two ways this method can
be mitigated against such attacks: First, by ensuring that a PL be mitigated against such attacks: First, by ensuring that a PL
sender never reduces the PLPMTU below the base size, solely in sender never reduces the PLPMTU below the base size, solely in
response to receiving a PTB message. This is achieved by first response to receiving a PTB message. This is achieved by first
entering the BASE state when such a message is received. Second, the entering the BASE state when such a message is received. Second, the
design does not require processing of PTB messages, a PL sender could design does not require processing of PTB messages, a PL sender could
therefore suspend processing of PTB messages (e.g., in a robustness therefore suspend processing of PTB messages (e.g., in a robustness
skipping to change at page 36, line 28 skipping to change at page 37, line 7
10.2. Informative References 10.2. Informative References
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-09 (work in Architecture", draft-ietf-intarea-tunnels-09 (work in
progress), 19 July 2018, progress), 19 July 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-intarea- <http://www.ietf.org/internet-drafts/draft-ietf-intarea-
tunnels-09.txt>. tunnels-09.txt>.
[I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-07 (work in progress), 8 March 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-
options-07.txt>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
skipping to change at page 38, line 26 skipping to change at page 38, line 49
* There is still work to complete, please comment on this draft. * There is still work to complete, please comment on this draft.
Working Group draft -01: Working Group draft -01:
* This draft includes improved introduction. * This draft includes improved introduction.
* The draft is updated to require ICMP validation prior to accepting * The draft is updated to require ICMP validation prior to accepting
PTB messages - this to be confirmed by WG PTB messages - this to be confirmed by WG
* Section added to discuss Selection of Probe Size - methods to be * Section added to discuss Selection of Probe Size - methods to be
evlauated and recommendations to be considered evaluated and recommendations to be considered
* Section added to align with work proposed in the QUIC WG. * Section added to align with work proposed in the QUIC WG.
Working Group draft -02: Working Group draft -02:
* The draft was updated based on feedback from the WG, and a * The draft was updated based on feedback from the WG, and a
detailed review by Magnus Westerlund. detailed review by Magnus Westerlund.
* The document updates RFC 4821. * The document updates RFC 4821.
skipping to change at page 39, line 26 skipping to change at page 39, line 49
* Corrected transition from confirmation directly to the search * Corrected transition from confirmation directly to the search
phase (Base has been checked). phase (Base has been checked).
* Redrawn state diagrams. * Redrawn state diagrams.
* Renamed BASE_MTU to BASE_PMTU (because it is a base for the PMTU). * Renamed BASE_MTU to BASE_PMTU (because it is a base for the PMTU).
* Clarified Error state. * Clarified Error state.
* Clarified supsending DPLPMTUD. * Clarified suspending DPLPMTUD.
* Verified normative text in requirements section. * Verified normative text in requirements section.
* Removed duplicate text. * Removed duplicate text.
* Changed all text to refer to /packet probe/probe packet/ * Changed all text to refer to /packet probe/probe packet/
/validation/verification/ added term /Probe Confirmation/ and /validation/verification/ added term /Probe Confirmation/ and
clarified BlackHole detection. clarified BlackHole detection.
Working Group draft -05: Working Group draft -05:
skipping to change at page 40, line 22 skipping to change at page 40, line 46
Working group draft -08: Working group draft -08:
* Moved to rfcxml v3+ * Moved to rfcxml v3+
* Rendered diagrams to svg in html version. * Rendered diagrams to svg in html version.
* Removed Appendix A. Event-driven state changes. * Removed Appendix A. Event-driven state changes.
* Removed section on DPLPMTUD with UDP Options. * Removed section on DPLPMTUD with UDP Options.
* Shortened the dsecription of phases. * Shortened the description of phases.
Working group draft -09:
* Remove final mention of UDP Options
* Add Initial Connectivity sections to each PL
* Add to disable outgoing pmtu enforcement of packets
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering, Fraser Noble Building School of Engineering, Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
 End of changes. 56 change blocks. 
167 lines changed or deleted 216 lines changed or added

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