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/