draft-ietf-tsvwg-datagram-plpmtud-09.txt   draft-ietf-tsvwg-datagram-plpmtud-10.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 May 2020 I. Ruengeler Expires: 21 May 2020 I. Ruengeler
T. Voelker T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
4 November 2019 18 November 2019
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-09 draft-ietf-tsvwg-datagram-plpmtud-10
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 May 2020. This Internet-Draft will expire on 21 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 (name-introduction) . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Classical Path MTU Discovery 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 3
(name-classical-path-mtu-discover) . . . . . . . . . . . 4 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6
1.2. Packetization Layer Path MTU Discovery 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 6
(name-packetization-layer-path-mt) . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Path MTU Discovery for Datagram Services 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9
(name-path-mtu-discovery-for-data) . . . . . . . . . . . 7 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12
2. Terminology (name-terminology) . . . . . . . . . . . . . . . 8 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12
3. Features Required to Provide Datagram PLPMTUD 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13
(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 (name-detection-of-unsupported-pl) . . . . . . 14 Detection . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Disabling the Effect of PMTUD 4.4. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 15
(name-disabling-the-effect-of-pmt) . . . . . . . . . . . 15 4.5. Response to PTB Messages . . . . . . . . . . . . . . . . 15
4.5. Response to PTB Messages 4.5.1. Validation of PTB Messages . . . . . . . . . . . . . 15
(name-response-to-ptb-messages) . . . . . . . . . . . . . 15 4.5.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 16
4.5.1. Validation of PTB Messages 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 17
(name-validation-of-ptb-messages) . . . . . . . . . . 16 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 18
4.5.2. Use of PTB Messages 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 18
(name-use-of-ptb-messages) . . . . . . . . . . . . . 17 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 19
5. Datagram Packetization Layer PMTUD 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 20
(name-datagram-packetization-laye) . . . . . . . . . . . . . . 18 5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 21
5.1. DPLPMTUD Components (name-dplpmtud-components) . . . . . 18 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Timers (name-timers) . . . . . . . . . . . . . . . . 19 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26
5.1.2. Constants (name-constants) . . . . . . . . . . . . . 20 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26
5.1.3. Variables (name-variables) . . . . . . . . . . . . . 20 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27
5.1.4. Overview of DPLPMTUD Phases 5.3.3. Resilience to Inconsistent Path Information . . . . . 27
(name-overview-of-dplpmtud-phases) . . . . . . . . . 21 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 28
5.2. State Machine (name-state-machine) . . . . . . . . . . . 23
5.3. Search to Increase the PLPMTU
(name-search-to-increase-the-plpm) . . . . . . . . . . . 26
5.3.1. Probing for a larger PLPMTU
(name-probing-for-a-larger-plpmtu) . . . . . . . . . 26
5.3.2. Selection of Probe Sizes
(name-selection-of-probe-sizes) . . . . . . . . . . . 27
5.3.3. Resilience to Inconsistent Path Information
(name-resilience-to-inconsistent-) . . . . . . . . . 28
5.4. Robustness to Inconsistent Paths
(name-robustness-to-inconsistent-) . . . . . . . . . . . 28
6. Specification of Protocol-Specific Methods
(name-specification-of-protocol-s) . . . . . . . . . . . . . . 28
6.1. Application support for DPLPMTUD with UDP or UDP-Lite
(name-application-support-for-dpl) . . . . . . . . . . . 28
6.1.1. Application Request
(name-application-request) . . . . . . . . . . . . . 29
6.1.2. Application Response
(name-application-response) . . . . . . . . . . . . . 29
6.1.3. Sending Application Probe Packets
(name-sending-application-probe-p) . . . . . . . . . 29
6.1.4. Initial Connectivity
(name-initial-connectivity) . . . . . . . . . . . . . 29
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 6. Specification of Protocol-Specific Methods . . . . . . . . . 28
8. IANA Considerations (name-iana-considerations) . . . . . . . 34 6.1. Application support for DPLPMTUD with UDP or
9. Security Considerations (name-security-considerations) . . . 34 UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 28
10. References (name-references) . . . . . . . . . . . . . . . . 35 6.1.1. Application Request . . . . . . . . . . . . . . . . . 29
10.1. Normative References (name-normative-references) . . . . 35 6.1.2. Application Response . . . . . . . . . . . . . . . . 29
10.2. Informative References 6.1.3. Sending Application Probe Packets . . . . . . . . . . 29
(name-informative-references) . . . . . . . . . . . . . 36 6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 29
A. Revision Notes (name-revision-notes) . . . . . . . . . . . . 37 6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 29
B Authors' Addresses (name-authors-addresses) . . . . . . . . . 41 6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 30
6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 30
6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 30
6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 31
6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 32
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 32
6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 33
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 33
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 33
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 33
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 37
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.
skipping to change at page 6, line 46 skipping to change at page 6, line 17
The term Packetization Layer (PL) has been introduced to describe the The term Packetization Layer (PL) has been introduced to describe the
layer that is responsible for placing data blocks into the payload of layer that is responsible for placing data blocks into the payload of
IP packets and selecting an appropriate MPS. This function is often IP packets and selecting an appropriate MPS. This function is often
performed by a transport protocol, but can also be performed by other performed by a transport protocol, but can also be performed by other
encapsulation methods working above the transport layer. encapsulation methods working above the transport layer.
In contrast to PMTUD, Packetization Layer Path MTU Discovery In contrast to PMTUD, Packetization Layer Path MTU Discovery
(PLPMTUD) [RFC4821] does not rely upon reception and validation of (PLPMTUD) [RFC4821] does not rely upon reception and validation of
PTB messages. It is therefore more robust than Classical PMTUD. PTB messages. It is therefore more robust than Classical PMTUD.
This has become the recommended approach for implementing PMTU This has become the recommended approach for implementing PMTU
discovery with TCP. discovery.
It uses a general strategy where the PL sends probe packets to search It uses a general strategy where the PL sends probe packets to search
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.
skipping to change at page 11, line 33 skipping to change at page 11, line 4
validation confirms that the PTB message was sent in response to validation confirms that the PTB message was sent in response to
a packet originating by the sender, and needs to be performed a packet originating by the sender, and needs to be performed
before the PLPMTU discovery method reacts to the PTB message. A before the PLPMTU discovery method reacts to the PTB message. A
PTB message MUST NOT be used to increase the PLPMTU [RFC8201]. PTB message MUST NOT be used to increase the PLPMTU [RFC8201].
5. Reception feedback: The destination PL endpoint is REQUIRED to 5. Reception feedback: The destination PL endpoint is REQUIRED to
provide a feedback method that indicates to the DPLPMTUD sender provide a feedback method that indicates to the DPLPMTUD sender
when a probe packet has been received by the destination PL when a probe packet has been received by the destination PL
endpoint. The mechanism needs to be robust to the possibility endpoint. The mechanism needs to be robust to the possibility
that packets could be significantly delayed along a network path. that packets could be significantly delayed along a network path.
The local PL endpoint at the sending node is REQUIRED to pass The local PL endpoint at the sending node is REQUIRED to pass
this feedback to the sender DPLPMTUD method. this feedback to the sender DPLPMTUD method.
6. Probe loss recovery: It is RECOMMENDED to use probe packets that 6. Probe loss recovery: It is RECOMMENDED to use probe packets that
do not carry any user data. Most datagram transports permit do not carry any user data that would require retransmission if
this. If a probe packet contains user data requiring lost. Most datagram transports permit this. If a probe packet
retransmission in case of loss, the PL (or layers above) are contains user data requiring retransmission in case of loss, the
REQUIRED to arrange any retransmission/repair of any resulting PL (or layers above) are REQUIRED to arrange any retransmission/
loss. DPLPMTUD is REQUIRED to be robust in the case where probe repair of any resulting loss. DPLPMTUD is REQUIRED to be robust
packets are lost due to other reasons (including link in the case where probe packets are lost due to other reasons
transmission error, congestion). (including link transmission error, congestion).
7. Probing and congestion control: The DPLPMTUD sender treats 7. Loss of a probe packet SHOULD NOT be treated as an indication of
isolated loss of a probe packet (with or without a corresponding congestion. The loss of a probe packet SHOULD NOT directly
PTB message) as a potential indication of a PMTU limit for the trigger a congestion control reaction [RFC4821] because this
path. Loss of a probe packet SHOULD NOT be treated as an could result in unecessary reduction of the sending rate. The
indication of congestion and the loss SHOULD NOT directly trigger interval between probe packets MUST be at least one RTT.
a congestion control reaction [RFC4821].
8. Shared PLPMTU state: The PLPMTU value could also be stored with 8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the
the corresponding entry in the destination cache and used by corresponding entry in the destination cache and used by other PL
other PL instances. The specification of PLPMTUD [RFC4821] instances. The specification of PLPMTUD [RFC4821] states: "If
states: "If PLPMTUD updates the MTU for a particular path, all PLPMTUD updates the MTU for a particular path, all Packetization
Packetization Layer sessions that share the path representation Layer sessions that share the path representation (as described
(as described in Section 5.2 of [RFC4821]) SHOULD be notified to in Section 5.2 of [RFC4821]) SHOULD be notified to make use of
make use of the new MTU". Such methods MUST be robust to the the new MTU". Such methods MUST be robust to the wide variety of
wide variety of underlying network forwarding behaviors, PLPMTU underlying network forwarding behaviors. Section 5.2 of
adjustments based on shared PLPMTU values should be incorporated [RFC8201] provides guidance on the caching of PMTU information
in the search algorithms. Section 5.2 of [RFC8201] provides and also the relation to IPv6 flow labels.
guidance on the caching of PMTU information and also the relation
to IPv6 flow labels.
In addition, the following principles are stated for design of a In addition, the following principles are stated for design of a
DPLPMTUD method: DPLPMTUD method:
* MPS: A method is REQUIRED to signal an appropriate MPS to the * MPS: A method is REQUIRED to signal an appropriate MPS to the
higher layer using the PL. The value of the MPS can change higher layer using the PL. The value of the MPS can change
following a change to the path. It is RECOMMENDED that methods following a change to the path. It is RECOMMENDED that methods
avoid forcing an application to use an arbitrary small MPS avoid forcing an application to use an arbitrary small MPS
(PLPMTU) for transmission while the method is searching for the (PLPMTU) for transmission while the method is searching for the
currently supported PLPMTU. Datagram PLs do not necessarily currently supported PLPMTU. Datagram PLs do not necessarily
skipping to change at page 13, line 15 skipping to change at page 12, line 29
4.1. PLPMTU Probe Packets 4.1. PLPMTU Probe Packets
The DPLPMTUD method relies upon the PL sender being able to generate The DPLPMTUD method relies upon the PL sender being able to generate
probe packets with a specific size. TCP is able to generate these probe packets with a specific size. TCP is able to generate these
probe packets by choosing to appropriately segment data being sent probe packets by choosing to appropriately segment data being sent
[RFC4821]. In contrast, a datagram PL that needs to construct a [RFC4821]. In contrast, a datagram PL that needs to construct a
probe packet has to either request an application to send a data probe packet has to either request an application to send a data
block that is larger than that generated by an application, or to block that is larger than that generated by an application, or to
utilize padding functions to extend a datagram beyond the size of the utilize padding functions to extend a datagram beyond the size of the
application data block. Protocols that permit exchange of control application data block. Protocols that permit exchange of control
messages (without an application data block) could alternatively messages (without an application data block) MAY prefer to generate a
prefer to generate a probe packet by extending a control message with probe packet by extending a control message with padding data.
padding data.
A receiver needs to be able to distinguish an in-band data block from A receiver is REQUIRED to be able to distinguish an in-band data
any added padding. This is needed to ensure that any added padding block from any added padding. This is needed to ensure that any
is not passed on to an application at the receiver. added padding is not passed on to an application at the receiver.
This results in three possible ways that a sender can create a probe This results in three possible ways that a sender can create a probe
packet listed in order of preference: packet:
Probing using padding data: A probe packet that contains only Probing using padding data: A probe packet that contains only
control information together with any padding, which is needed to control information together with any padding, which is needed to
be inflated to the size required for the probe packet. Since be inflated to the size required for the probe packet. Since
these probe packets do not carry an application-supplied data these probe packets do not carry an application-supplied data
block, they do not typically require retransmission, although they block, they do not typically require retransmission, although they
do still consume network capacity and incur endpoint processing. do still consume network capacity and incur endpoint processing.
Probing using application data and padding Probing using application data and padding
data: A probe packet that data: A probe packet that
skipping to change at page 17, line 16 skipping to change at page 16, line 30
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:
PTB_SIZE < MIN_MTU OR PTB_SIZE == 0
* Invalid PTB_SIZE.
* PTB message ought to be discarded without further processing
(e. g. PLPMTU not modified).
* The information could be utilized as an input to trigger
enabling a resilience mode.
MIN_PMTU < PTB_SIZE < BASE_PMTU MIN_PMTU < PTB_SIZE < BASE_PMTU
* A robust PL MAY enter an error state (see Section 5.2) for an * A robust PL MAY enter an error state (see Section 5.2) for an
IPv4 path when the PTB_SIZE reported in the PTB message is IPv4 path when the PTB_SIZE reported in the PTB message is
larger than or equal to 68 bytes and when this is less than the larger than or equal to 68 bytes and when this is less than the
BASE_PMTU. BASE_PMTU.
* A robust PL MAY enter an error state (see Section 5.2) for an * A robust PL MAY enter an error state (see Section 5.2) for an
IPv6 path when the PTB_SIZE reported in the PTB message is IPv6 path when the PTB_SIZE reported in the PTB message is
larger than or equal to 1280 bytes and when this is less than larger than or equal to 1280 bytes and when this is less than
the BASE_PMTU. the BASE_PMTU.
skipping to change at page 18, line 43 skipping to change at page 18, line 31
+----------------------+ +----------------------+
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 following 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 overview 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
The method utilizes up to three timers: The method utilizes up to three timers:
skipping to change at page 20, line 19 skipping to change at page 20, line 5
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). MAX_PROBES represents the counter (see Section 5.1.3). MAX_PROBES represents the
limit for the number of consecutive probe attempts of limit for the number of consecutive probe attempts of
any size. The default value of MAX_PROBES is 10. any size. The default value of MAX_PROBES is 3. This
value is greater than 1 to provide robustness to
isolated packet loss.
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
fragmented datagrams at least up to 576 bytes, as stated fragmented datagrams at least up to 576 bytes, as stated
in section 3.3.3 of [RFC1122]. in section 3.3.3 of [RFC1122].
MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to
be less than or equal to the minimum of the local MTU of be less than or equal to the minimum of the local MTU of
the outgoing interface and the destination PMTU for the outgoing interface and the destination PMTU for
receiving. An application, or PL, MAY reduce the receiving. An application, or PL, MAY choose a smaller
MAX_PMTU when there is no need to send packets larger MAX_PMTU when there is no need to send packets larger
than a specific size. than a specific size.
BASE_PMTU: The BASE_PMTU is a configured size expected to work for BASE_PMTU: The BASE_PMTU is a configured size expected to work for
most paths. The size is equal to or larger than the most paths. The size is equal to or larger than the
MIN_PMTU and smaller than the MAX_PMTU. In the case of MIN_PMTU and smaller than the MAX_PMTU. In the case of
IPv6, this value is 1280 bytes [RFC2460]. When using IPv6, this value is 1280 bytes [RFC2460]. When using
IPv4, a size of 1200 bytes is RECOMMENDED. IPv4, a size of 1200 bytes is RECOMMENDED.
5.1.3. Variables 5.1.3. Variables
This method utilizes a set of variables: This method utilizes a set of variables:
PROBED_SIZE: The PROBED_SIZE is the size of the current probe PROBED_SIZE: The PROBED_SIZE is the size of the current probe
packet. This is a tentative value for the PLPMTU, packet. This is a tentative value for the PLPMTU,
which is awaiting confirmation by an acknowledgment. which is awaiting confirmation by an acknowledgment.
PROBE_COUNT: The PROBE_COUNT is a count of the number of PROBE_COUNT: The PROBE_COUNT is a count of the number of successive
unsuccessful probe packets that have been sent with a unsuccessful probe packets that have been sent.
size of PROBED_SIZE. The value is initialized to zero
when a particular size of PROBED_SIZE is first
attempted.
The figure below illustrates the relationship between the packet size The figure below illustrates the relationship between the packet size
constants and variables at a point of time when the DPLPMTUD constants and variables at a point of time when the DPLPMTUD
algorithm performs path probing to increase the size of the PLPMTU. algorithm performs path probing to increase the size of the PLPMTU.
A probe packet has been sent of size PROBED_SIZE. Once this is A probe packet has been sent of size PROBED_SIZE. Once this is
acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the
DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual
PMTU. PMTU.
MIN_PMTU MAX_PMTU MIN_PMTU MAX_PMTU
skipping to change at page 24, line 5 skipping to change at page 23, line 22
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
by an end-to-end flow (e.g., after a routing or path fail-over by an end-to-end flow (e.g., after a routing or path fail-over
decision). decision).
5.2. State Machine 5.2. State Machine
A state machine for DPLPMTUD is depicted in Figure 4. If multipath A state machine for DPLPMTUD is depicted in Figure 4. If multipath
or multihoming is supported, a state machine is needed for each path. or multihoming is supported, a state machine is needed for each path.
Note: Some state changes are not shown to simplify the diagram. Note: Not all changes are not shown to simplify the diagram.
| | | |
| Start | PL indicates loss | Start | PL indicates loss
| | of connectivity | | of connectivity
v v v v
+---------------+ +---------------+ +---------------+ +---------------+
| DISABLED | | ERROR | | DISABLED | | ERROR |
+---------------+ PROBE_TIMER expiry: +---------------+ +---------------+ PROBE_TIMER expiry: +---------------+
| PL indicates PROBE_COUNT = MAX_PROBES or ^ | | PL indicates PROBE_COUNT = MAX_PROBES or ^ |
| connectivity PTB: PTB_SIZE < BASE_PMTU | | | connectivity PTB: PTB_SIZE < BASE_PMTU | |
skipping to change at page 25, line 35 skipping to change at page 25, line 31
the SEARCHING state. the SEARCHING state.
The state is also left when the PROBE_COUNT reaches The state is also left when the PROBE_COUNT reaches
MAX_PROBES or a received PTB message is validated. MAX_PROBES or a received PTB message is validated.
This causes the PL sender to enter the ERROR state. This causes the PL sender to enter the ERROR state.
SEARCHING: The SEARCHING state is the main probing state. SEARCHING: The SEARCHING state is the main probing state.
This state is entered when probing for the This state is entered when probing for the
BASE_PMTU was successful. BASE_PMTU was successful.
The PROBE_COUNT is set to zero when the first probe Each time a probe packet is acknowledged, the
packet is sent for each probe size. Each time a PROBE_COUNT is set to zero, the PLPMTU is set to
probe packet is acknowledged, the PLPMTU is set to the PROBED_SIZE and then the PROBED_SIZE is
the PROBED_SIZE, and then the PROBED_SIZE is
increased using the search algorithm. increased using the search algorithm.
When a probe packet is sent and not acknowledged When a probe packet is sent and not acknowledged
within the period of the PROBE_TIMER, the within the period of the PROBE_TIMER, the
PROBE_COUNT is incremented and the probe packet is PROBE_COUNT is incremented and a new probe packet
retransmitted. The state is exited when the is transmitted. The state is exited when the
PROBE_COUNT reaches MAX_PROBES, a received PTB PROBE_COUNT reaches MAX_PROBES, a received PTB
message is validated, a probe of size MAX_PMTU is message is validated, a probe of size MAX_PMTU is
acknowledged, or a black hole is detected. acknowledged, or a black hole is detected.
SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful
end to the SEARCHING state. DPLPMTUD remains in end to the SEARCHING state. DPLPMTUD remains in
this state until either the PMTU_RAISE_TIMER this state until either the PMTU_RAISE_TIMER
expires, a received PTB message is validated, or a expires, a received PTB message is validated, or a
black hole is detected. black hole is detected.
When DPLPMTUD uses an unacknowledged PL and is in When DPLPMTUD uses an unacknowledged PL and is in
the SEARCH_COMPLETE state, a CONFIRMATION_TIMER the SEARCH_COMPLETE state, a CONFIRMATION_TIMER
periodically resets the PROBE_COUNT and schedules a periodically resets the PROBE_COUNT and schedules a
probe packet with the size of the PLPMTU. If the probe packet with the size of the PLPMTU. If
probe packet fails to be acknowledged after MAX_PROBES successive PLPMTUD sized probes fail to
MAX_PROBES attempts, the method enters the BASE be acknowledged the method enters the BASE state.
state. When used with an acknowledged PL (e.g., When used with an acknowledged PL (e.g., SCTP),
SCTP), DPLPMTUD SHOULD NOT continue to generate DPLPMTUD SHOULD NOT continue to generate PLPMTU
PLPMTU probes in this state. probes in this state.
ERROR: The ERROR state represents the case where either ERROR: The ERROR state represents the case where either
the network path is not known to support a PLPMTU the network path is not known to support a PLPMTU
of at least the BASE_PMTU size or when there is of at least the BASE_PMTU size or when there is
contradictory information about the network path contradictory information about the network path
that would otherwise result in excessive variation that would otherwise result in excessive variation
in the MPS signalled to the higher layer. The in the MPS signalled to the higher layer. The
state implements a method to mitigate oscillation state implements a method to mitigate oscillation
in the state-event engine. It signals a in the state-event engine. It signals a
conservative value of the MPS to the higher layer conservative value of the MPS to the higher layer
skipping to change at page 27, line 8 skipping to change at page 27, line 5
determine whether a larger PLPMTU can be supported across a network determine whether a larger PLPMTU can be supported across a network
path. path.
The method discovers the search range by confirming the minimum The method discovers the search range by confirming the minimum
PLPMTU and then using the probe method to select a PROBED_SIZE less PLPMTU and then using the probe method to select a PROBED_SIZE less
than or equal to MAX_PMTU. MAX_PMTU is the minimum of the local MTU than or equal to MAX_PMTU. MAX_PMTU is the minimum of the local MTU
and EMTU_R (learned from the remote endpoint). The MAX_PMTU MAY be and EMTU_R (learned from the remote endpoint). The MAX_PMTU MAY be
reduced by an application that sets a maximum to the size of reduced by an application that sets a maximum to the size of
datagrams it will send. datagrams it will send.
The PROBE_COUNT is initialized to zero when a probe packet is first The PROBE_COUNT is initialized to zero when the first probe with a
sent with a particular size. A timer is used by the search algorithm size greater than or equal to PLPMTUD is sent. A timer is used by
to trigger the sending of probe packets of size PROBED_SIZE, larger the search algorithm to trigger the sending of probe packets of size
than the PLPMTU. Each probe packet successfully sent to the remote PROBED_SIZE, larger than the PLPMTU. Each probe packet successfully
peer is confirmed by acknowledgement at the PL, see Section 4.1. sent to the remote peer is confirmed by acknowledgement at the PL,
see Section 4.1.
Each time a probe packet is sent to the destination, the PROBE_TIMER Each time a probe packet is sent to the destination, the PROBE_TIMER
is started. The timer is canceled when the PL receives is started. The timer is canceled when the PL receives
acknowledgment that the probe packet has been successfully sent acknowledgment that the probe packet has been successfully sent
across the path Section 4.1. This confirms that the PROBED_SIZE is across the path Section 4.1. This confirms that the PROBED_SIZE is
supported, and the PROBED_SIZE value is then assigned to the PLPMTU. supported, and the PROBED_SIZE value is then assigned to the PLPMTU.
The search algorithm can continue to send subsequent probe packets of The search algorithm can continue to send subsequent probe packets of
an increasing size. an increasing size.
If the timer expires before a probe packet is acknowledged, the probe If the timer expires before a probe packet is acknowledged, the probe
has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER
expires, the PROBE_COUNT is incremented, the PROBE_TIMER is expires, the PROBE_COUNT is incremented, the PROBE_TIMER is
reinitialized, and a probe packet of the same size is retransmitted reinitialized, and a new probe of the same size or any other sized
(the replicated probe improve the resilience to loss). The maximum (determined by the search algorithm) can be sent. The maximum number
number of retransmissions for a particular size is configured of consecutive failed probes is configured (MAX_PROBES). If the
(MAX_PROBES). If the value of the PROBE_COUNT reaches MAX_PROBES, value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and
probing will stop, and the PL sender enters the SEARCH_COMPLETE the PL sender enters the SEARCH_COMPLETE state.
state.
5.3.2. Selection of Probe Sizes 5.3.2. Selection of Probe Sizes
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.
skipping to change at page 28, line 10 skipping to change at page 27, line 50
appropriate next size to search, an implementer 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
to frequent path changes. Frequent path changes could occur by to frequent path changes. Frequent path changes could occur by
unexpected "flapping" - where some packets from a flow pass along one unexpected "flapping" - where some packets from a flow pass along one
path, but other packets follow a different path with different path, but other packets follow a different path with different
properties. properties.
A PL sender is able to detect inconsistency from the sequence of A PL sender is able to detect inconsistency from the sequence of
PLPMTU probes that it sends or the sequence of PTB messages that it PLPMTU probes that it sends or the sequence of PTB messages that it
receives. When inconsistent path information is detected, a PL receives. When inconsistent path information is detected, a PL
sender could use an alternate search mode that clamps the offered MPS sender could use an alternate search mode that clamps the offered MPS
to a smaller value for a period of time. This avoids unnecessary to a smaller value for a period of time. This avoids unnecessary
skipping to change at page 28, line 34 skipping to change at page 28, line 25
Some paths could be unable to sustain packets of the BASE_PMTU size. Some paths could be unable to sustain packets of the BASE_PMTU size.
To be robust to these paths an implementation could implement the To be robust to these paths an implementation could implement the
Error State. This allows fallback to a smaller than desired PLPMTU, Error State. This allows fallback to a smaller than desired PLPMTU,
rather than suffer connectivity failure. This could utilize methods rather than suffer connectivity failure. This could utilize methods
such as endpoint IP fragmentation to enable the PL sender to such as endpoint IP fragmentation to enable the PL sender to
communicate using packets smaller than the BASE_PMTU. communicate using packets smaller than the BASE_PMTU.
6. Specification of Protocol-Specific Methods 6. Specification of Protocol-Specific Methods
This section specifies protocol-specific details for datagram PLPMTUD DPLPMTUD requires protocol-specific details to be specified for each
for IETF-specified transports. PL that is used.
The first subsection provides guidance on how to implement the The first subsection provides guidance on how to implement the
DPLPMTUD method as a part of an application using UDP or UDP-Lite. DPLPMTUD method as a part of an application using UDP or UDP-Lite.
The guidance also applies to other datagram services that do not The guidance also applies to other datagram services that do not
include a specific transport protocol (such as a tunnel include a specific transport protocol (such as a tunnel
encapsulation). The following subsections describe how DPLPMTUD can encapsulation). The following subsections describe how DPLPMTUD can
be implemented as a part of the transport service, allowing be implemented as a part of the transport service, allowing
applications using the service to benefit from discovery of the applications using the service to benefit from discovery of the
PLPMTU without themselves needing to implement this method. PLPMTU without themselves needing to implement this method.
skipping to change at page 34, line 28 skipping to change at page 34, line 21
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
If there are no requirements for IANA, the section will be removed If there are no requirements for IANA, the section will be removed
during conversion into an RFC by the RFC Editor. during conversion into an RFC by the RFC Editor.
9. Security Considerations 9. Security Considerations
The security considerations for the use of UDP and SCTP are provided The security considerations for the use of UDP and SCTP are provided
in the references RFCs. Security guidance for applications using UDP in the references RFCs. The interval between individual probe
is provided in the UDP Usage Guidelines [RFC8085], specifically the packets MUST be at least one RTT, and the interval between rounds of
generation of probe packets is regarded as a "Low Data-Volume probing is determined by the PMTU_RAISE_TIMER.
Application", described in section 3.1.3 of this document. This
recommends that sender limits generation of probe packets to an
average rate lower than one probe per 3 seconds.
A PL sender needs to ensure that the method used to confirm reception A PL sender needs to ensure that the method used to confirm reception
of probe packets offers protection from off-path attackers injecting of probe packets offers protection from off-path attackers injecting
packets into the path. This protection if provided in IETF-defined packets into the path. This protection if provided in IETF-defined
protocols (e.g., TCP, SCTP) using a randomly-initialized sequence protocols (e.g., TCP, SCTP) using a randomly-initialized sequence
number. A description of one way to do this when using UDP is number. A description of one way to do this when using UDP is
provided in section 5.1 of [RFC8085]). provided in section 5.1 of [RFC8085]).
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
skipping to change at page 36, line 51 skipping to change at page 36, line 42
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of "Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>. 2017, <https://www.rfc-editor.org/info/rfc8261>.
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-10 (work in
progress), 19 July 2018, progress), 12 September 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-intarea- <http://www.ietf.org/internet-drafts/draft-ietf-intarea-
tunnels-09.txt>. tunnels-10.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>.
skipping to change at page 41, line 4 skipping to change at page 40, line 43
* Removed section on DPLPMTUD with UDP Options. * Removed section on DPLPMTUD with UDP Options.
* Shortened the description of phases. * Shortened the description of phases.
Working group draft -09: Working group draft -09:
* Remove final mention of UDP Options * Remove final mention of UDP Options
* Add Initial Connectivity sections to each PL * Add Initial Connectivity sections to each PL
* Add to disable outgoing pmtu enforcement of packets * Add to disable outgoing pmtu enforcement of packets
Working group draft -10:
* Address comments from Lars Eggert
* Reinforce that PROBE_COUNT is successive attempts to probe for any
size
* Redefine MAx_PROBES to 3
* Address PTB_SIZE of 0 or less that MIN_PMTU
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
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 33 change blocks. 
164 lines changed or deleted 146 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/