Diff: draft-ietf-tsvwg-datagram-plpmtud-05.txt - draft-ietf-tsvwg-datagram-plpmtud-06.txt

	draft-ietf-tsvwg-datagram-plpmtud-05.txt	draft-ietf-tsvwg-datagram-plpmtud-06.txt

	Internet Engineering Task Force G. Fairhurst	Internet Engineering Task Force G. Fairhurst
	Internet-Draft T. Jones	Internet-Draft T. Jones
	Updates: 4821 (if approved) University of Aberdeen	Updates: 4821 (if approved) University of Aberdeen
	Intended status: Standards Track M. Tuexen	Intended status: Standards Track M. Tuexen

	Expires: April 5, 2019 I. Ruengeler	Expires: May 24, 2019 I. Ruengeler
	Muenster University of Applied Sciences	Muenster University of Applied Sciences

	October 02, 2018	November 20, 2018

	Packetization Layer Path MTU Discovery for Datagram Transports	Packetization Layer Path MTU Discovery for Datagram Transports

	draft-ietf-tsvwg-datagram-plpmtud-05	draft-ietf-tsvwg-datagram-plpmtud-06

	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). The document	(PMTUD) for datagram Packetization Layers (PLs). The document
	describes an extension to RFC 1191 and RFC 8201, which specifies	describes an extension to RFC 1191 and RFC 8201, which specifies
	ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a	ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a
	PL, or a datagram application that uses a PL, to discover whether a	PL, or a datagram application that uses a PL, to discover whether a
	network path can support the current size of datagram. This can be	network path can support the current size of datagram. This can be
	used to detect and reduce the message size when a sender encounters a	used to detect and reduce the message size when a sender encounters a

	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 April 5, 2019.	This Internet-Draft will expire on May 24, 2019.

	Copyright Notice	Copyright Notice

	Copyright (c) 2018 IETF Trust and the persons identified as the	Copyright (c) 2018 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	Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of	(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4	1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4

	1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 5	1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6
	1.3. Path MTU Discovery for Datagram Services . . . . . . . . 6	1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9	3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9

	4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 11	4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12
	4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 11	4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12
	4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13	4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13

	4.3. Detection of Black Holes . . . . . . . . . . . . . . . . 13	4.3. Detection of Black Holes . . . . . . . . . . . . . . . . 14
	4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 14	4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 14

	4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 14	4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 15
	4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 15	4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 15
	5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 16	5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 16
	5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 17	5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 17
	5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 17	5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 17

	5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 17	5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 18
	5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 18	5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 19
	5.2. DPLPMTUD Phases . . . . . . . . . . . . . . . . . . . . . 19	5.2. DPLPMTUD Phases . . . . . . . . . . . . . . . . . . . . . 19

	5.2.1. Path Confirmation Phase . . . . . . . . . . . . . . . 20	5.2.1. Path Confirmation Phase . . . . . . . . . . . . . . . 21
	5.2.2. Search Phase . . . . . . . . . . . . . . . . . . . . 21	5.2.2. Search Phase . . . . . . . . . . . . . . . . . . . . 21

	5.2.2.1. Resilience to inconsistent path information . . . 21	5.2.2.1. Resilience to inconsistent path information . . . 22
	5.2.3. Search Complete Phase . . . . . . . . . . . . . . . . 21	5.2.3. Search Complete Phase . . . . . . . . . . . . . . . . 22
	5.2.4. PROBE_BASE Phase . . . . . . . . . . . . . . . . . . 22	5.2.4. PROBE_BASE Phase . . . . . . . . . . . . . . . . . . 23
	5.2.5. ERROR Phase . . . . . . . . . . . . . . . . . . . . . 22	5.2.5. ERROR Phase . . . . . . . . . . . . . . . . . . . . . 23
	5.2.5.1. Robustness to inconsistent path . . . . . . . . . 23	5.2.5.1. Robustness to inconsistent path . . . . . . . . . 23


	5.2.6. DISABLED Phase . . . . . . . . . . . . . . . . . . . 23	5.2.6. DISABLED Phase . . . . . . . . . . . . . . . . . . . 24
	5.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 23	5.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 24
	5.4. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26	5.4. Search to Increase the PLPMTU . . . . . . . . . . . . . . 27
	5.4.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26	5.4.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 27
	5.4.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27	5.4.2. Selection of Probe Sizes . . . . . . . . . . . . . . 28
	5.4.3. Resilience to inconsistent Path information . . . . . 28	5.4.3. Resilience to inconsistent Path information . . . . . 29
	6. Specification of Protocol-Specific Methods . . . . . . . . . 28	6. Specification of Protocol-Specific Methods . . . . . . . . . 29
	6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28	6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 29
	6.1.1. Application Request . . . . . . . . . . . . . . . . . 29	6.1.1. Application Request . . . . . . . . . . . . . . . . . 30
	6.1.2. Application Response . . . . . . . . . . . . . . . . 29	6.1.2. Application Response . . . . . . . . . . . . . . . . 30
	6.1.3. Sending Application Probe Packets . . . . . . . . . . 29	6.1.3. Sending Application Probe Packets . . . . . . . . . . 30
	6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29	6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 30
	6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29	6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 30
	6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30	6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 31
	6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31	6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 32
	6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 32	6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 33
	6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32	6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 33
	6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32	6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 33
	6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32	6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 33
	6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33	6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 34
	6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33	6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 34
	6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33	6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 34
	6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33	6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 34
	6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 34	6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 35
	6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 34	6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 35
	6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34	6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35
	6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34	6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 35
	6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34	6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 35
	6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34	6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 35
	6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34	6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 35
	6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 35	6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 36
	6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35	6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 36
	6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35	6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 36
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 36	9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	10.1. Normative References . . . . . . . . . . . . . . . . . . 37	10.1. Normative References . . . . . . . . . . . . . . . . . . 38
	10.2. Informative References . . . . . . . . . . . . . . . . . 39	10.2. Informative References . . . . . . . . . . . . . . . . . 39

	Appendix A. Event-driven state changes . . . . . . . . . . . . . 39	Appendix A. Event-driven state changes . . . . . . . . . . . . . 40
	Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 42	Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45

	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]). The term PTB message	(PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message

	is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry	is applied to both IPv4 ICMP Unreachable messages (type 3) that carry
	the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too	the error Fragmentation Needed (Type 3, Code 4) [RFC0792] and ICMPv6
	big messages (Type 2). When a sender receives a PTB message, it	packet too big messages (Type 2) [RFC4443]. When a sender receives a
	reduces the effective MTU to the value reported in the PTB message	PTB message, it reduces the effective MTU to the value reported as
	(in this document called the PTB_SIZE). A method from time-to-time	the Link MTU in the PTB message, and a method that from time-to-time
	increases the packet size in attempt to discover an increase in the	increases the packet size in attempt to discover an increase in the
	supported PMTU. The packets sent with a size larger than the current	supported PMTU. The packets sent with a size larger than the current
	effective PMTU are known as probe packets.	effective PMTU are 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 an attempt to send a packet larger than	current effective PMTU, or the attempt to send fails with an error
	current effective PMTU fails with an error code. Applications are	code. Applications are sometimes provided with a primitive to let
	sometimes provided with a primitive to let them read the maximum	them read the Maximum Packet Size (MPS), derived from the current
	packet size, derived from the current effective PMTU.	effective PMTU.

	Classical PMTUD is subject to protocol failures. One failure arises	Classical PMTUD is subject to protocol failures. One failure arises

	when traffic using a packet size larger than the actual PMTU is black	when traffic using a packet size larger than the actual PMTU is
	holed (all datagrams sent with this size, or larger, are silently	black-holed (all datagrams sent with this size, or larger, are
	discarded without the sender receiving ICMP PTB messages). This	silently discarded without the sender receiving ICMP PTB messages).
	could arise when the PTB messages are not delivered back to the	This could arise when the PTB messages are not delivered back to the
	sender for some reason [RFC2923]). For example, ICMP messages are	sender for some reason [RFC2923]).
	increasingly filtered by middleboxes (including firewalls) [RFC4890].
	A stateful firewall could be configured with a policy to block	Examples where PTB messages are not delivered include:
	incoming ICMP messages, which would prevent reception of PTB messages
	to endpoints behind this firewall. Other examples include cases	o The generation of ICMP messages is usually rate limited. This may
	where PTB messages are not correctly processed/generated by tunnel	result in no PTB messages being sent to the sender (see section
	endpoints.	2.4 of [RFC4443]

		o ICMP messages are increasingly filtered by middleboxes (including
		firewalls) [RFC4890]. A stateful firewall could be configured
		with a policy to block incoming ICMP messages, which would prevent
		reception of PTB messages to endpoints behind this firewall.

		o When the router issuing the ICMP message drops a tunneled packet,
		the resulting ICMP message will be directed to the tunnel ingress.
		This tunnel endpoint is responsible for forwarding the ICMP
		message and also processing the quoted packet within the payload
		field to remove the effect of the tunnel, and return a correctly
		formatted ICMP message to the sender [I-D.ietf-intarea-tunnels].
		Failure to do this results in black-holing.

		o Asymmetry in forwarding can result in there being no route back to
		the original sender, which would prevent an ICMP message being
		delivered to the sender. This can be also be an issue when
		policy-based routing is used, Equal Cost Multipath (ECMP) routing
		is used, or a middlebox acts as an application load balancer. An
		example is where the path towards the server is chosen by ECMP
		routing depending on bytes in the IP payload. In this case, when
		a packet sent by the server encounters a problem after the ECMP
		router, then any resulting ICMP message needs to also be directed
		by the ECMP router towards the same server (i.e., ICMP messages
		need to follow the same path as the flows to which they
		correspond). Failure to do this results in black-holing.

		o There are cases where the next hop destination fails to receive a
		packet because of its size. This could be due to misconfiguration
		of the layer 2 path between nodes, for instance the MTU configured
		in a layer 2 switch, or misconfiguration of the Maximum Receive
		Unit (MRU). If the packet is dropped by the link, this will not
		cause in a PTB to be sent, and result in consequent black-holing.

	Another failure could result if a node that is not on the network	Another failure could result if a node that is not on the network
	path sends a PTB message that attempts to force the sender to change	path sends a PTB message that attempts to force the sender to change
	the effective PMTU [RFC8201]. A sender can protect itself from	the effective PMTU [RFC8201]. A sender can protect itself from
	reacting to such messages by utilising the quoted packet within a PTB	reacting to such messages by utilising the quoted packet within a PTB
	message payload to validate that the received PTB message was	message payload to validate that the received PTB message was
	generated in response to a packet that had actually originated from	generated in response to a packet that had actually originated from
	the sender. However, there are situations where a sender would be	the sender. However, there are situations where a sender would be
	unable to provide this validation.	unable to provide this validation.

	Examples where validation of the PTB message is not possible include:	Examples where validation of the PTB message is not possible include:


	o When the router issuing the ICMP message is acting on a tunneled	o When a router issuing the ICMP message implements RFC792
	packet, the ICMP message will be directed to the tunnel endpoint.	[RFC0792], it is only required to include the first 64 bits of the
	This tunnel endpoint is responsible for forwarding the ICMP	IP payload of the packet within the quoted payload. This may be
	message and also processing the quoted packet within the payload	insufficient to perform the tunnel processing described in the
	field to remove the effect of the tunnel, and return a correctly	previous bullet. There could be insufficient bytes remaining for
	formatted ICMP message to the sender. Failure to do appropriate	the sender to interpret the quoted transport information. The
	processing therefore results in black-holing.	recommendation in RFC1812 [RFC1812] is that IPv4 routers return a
		quoted packet with as much of the original datagram as possible
	o When a router issuing the ICMP message implements RFC 792	without the length of the ICMP datagram exceeding 576 bytes.
	[RFC0792], it is only required to include (quote) the first 64	(IPv6 routers include as much of invoking packet as possible
	bits of the IP payload of the packet within the ICMP payload.	without the ICMPv6 packet exceeding 1280 bytes [RFC4443].)
	This could be insufficient to perform the tunnel processing
	described in the previous bullet. Even if the decapsulated
	message is processed by the tunnel endpoint, there could be
	insufficient bytes remaining for the sender to interpret the
	quoted transport information. RFC 1812 [RFC1812] requires routers
	to return the full packet if possible. This can result in black-
	holing when used the path includes tunnels.


	o When a router issuing the ICMP message quotes a packet with an	o The use of tunnels/encryption can reduce the size of the quoted
	encrypted transport, it may lack sufficient context to determine	packet returned to the original source address, increasing the
	the original transport header.	risk that there could be insufficient bytes remaining for the
		sender to interpret the quoted transport information.

	o Even when the PTB message includes sufficient bytes of the quoted	o Even when the PTB message includes sufficient bytes of the quoted
	packet, the network layer could lack sufficient context to	packet, the network layer could lack sufficient context to

	validate the ICMP message, because this depends on information	validate the message, because validation depends on information
	about the active transport flows at an endpoint node (e.g., the	about the active transport flows at an endpoint node (e.g., the
	socket/address pairs being used, and other protocol header	socket/address pairs being used, and other protocol header
	information).	information).


		o When a packet is encapsulated/tunneled over an encrypted
		transport, the tunnel/encapsulation ingress might have
		insufficient context, or computational power, to reconstruct the
		transport header that would be needed to perform validation.

	1.2. Packetization Layer Path MTU Discovery	1.2. Packetization Layer Path MTU Discovery

	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 Maximum Packet Size (MPS).	IP packets and selecting an appropriate MPS. This function is often
	This function is often performed by a transport protocol, but can	performed by a transport protocol, but can also be performed by other
	also be performed by other encapsulation methods working above the	encapsulation methods working above the transport layer.
	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 with TCP.

	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. The probe packets are sent with a progressively larger	network path. The probe packets are sent with a progressively larger

	skipping to change at page 34, line 46 ¶	skipping to change at page 35, line 46 ¶
	6.3.3.3. Handling of PTB Messages by SCTP/DTLS	6.3.3.3. Handling of PTB Messages by SCTP/DTLS

	It is not possible to perform normal ICMP validation as specified in	It is not possible to perform normal 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.4. DPLPMTUD for QUIC	6.4. 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.	UDP-based transport that provides reception feedback. The UDP
		payload includes the QUIC packet header, protected payload, and any
		authentication fields. QUIC depends on a PMTU of at least 1280
		bytes.

	Section 9.2 of [I-D.ietf-quic-transport] describes the path	Section 9.2 of [I-D.ietf-quic-transport] describes the path
	considerations when sending QUIC packets. It recommends the use of	considerations when sending QUIC packets. It recommends the use of

	PADDING frames to build the probe packet. This enables probing	PADDING frames to build the probe packet. Pure probe-only packets
	without affecting the transfer of other QUIC frames.	are constructed with PADDING frames and PING frames to create a
		padding only packet that will illict an acknowledgement. Padding
		only frames enable probing the without affecting the transfer of
		other QUIC frames.


	This provides an acknowledged PL. A sender can therefore enter the	The recommendation for QUIC endpoints implementing DPLPMTUD is
	PROBE_BASE state as soon as connectivity has been confirmed.	therefore that a MPS is maintained for each combination of local and
		remote IP addresses [I-D.ietf-quic-transport]. If a QUIC endpoint
		determines that the PMTU between any pair of local and remote IP
		addresses has fallen below an acceptable MPS, it needs to immediately
		cease sending QUIC packets on the affected path. This could result
		in termination of the connection if an alternative path cannot be
		found [I-D.ietf-quic-transport].

	6.4.1. Sending QUIC Probe Packets	6.4.1. 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

	only PADDING Frames. PADDING Frames are a single octet (0x00) and	PADDING Frames and a PING Frame. PADDING Frames are a single octet
	several of these can be used to create a probe packet of size	(0x00) and several of these can be used to create a probe packet of
	PROBED_SIZE. QUIC provides an acknowledged PL. A sender can	size PROBED_SIZE. QUIC provides an acknowledged PL, A sender can
	therefore enter the PROBE_BASE state as soon as connectivity has been	therefore enter the PROBE_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:

	o BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to	o 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.

	o MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has	o MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has

	skipping to change at page 35, line 36 ¶	skipping to change at page 36, line 47 ¶

	6.4.2. Validating the Path with QUIC	6.4.2. 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.4.3. Handling of PTB Messages by QUIC	6.4.3. 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.

	Although QUIC does not currently specify a method for validating ICMP	In addition to UDP Port validation QUIC can validate an ICMP message
	responses, it does provide some guidelines to make it harder for an	by looking for valid Connection IDs in the quoted packet.
	off-path attacker to inject ICMP messages.

	o Set the IPv4 Don't Fragment (DF) bit on a small proportion of
	packets, so that most invalid ICMP messages arrive when there are
	no DF packets outstanding, and can therefore be identified as
	spurious.

	o Store additional information from the IP or UDP headers from DF
	packets (for example, the IP ID or UDP checksum) to further
	authenticate incoming Datagram Too Big messages.

	o Any reduction in PMTU due to a report contained in an ICMP packet
	is provisional until QUIC's loss detection algorithm determines
	that the packet is actually lost.

	XXX The above list was pulled whole from quic-transport - input is
	invited from QUIC contributors. XXX

	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 37, line 31 ¶	skipping to change at page 38, line 28 ¶
	different PMTU. If not considered, this could result in data being	different PMTU. If not considered, this could result in data being
	black holed when the PLPMTU is larger than the smallest PMTU across	black holed when the PLPMTU is larger than the smallest PMTU across
	the current paths.	the current paths.

	10. References	10. References

	10.1. Normative References	10.1. Normative References

	[I-D.ietf-quic-transport]	[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed

	and Secure Transport", draft-ietf-quic-transport-14 (work	and Secure Transport", draft-ietf-quic-transport-16 (work
	in progress), August 2018.	in progress), October 2018.

	[I-D.ietf-tsvwg-udp-options]	[I-D.ietf-tsvwg-udp-options]
	Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-	Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
	udp-options-05 (work in progress), July 2018.	udp-options-05 (work in progress), July 2018.

	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,	DOI 10.17487/RFC0768, August 1980,
	<https://www.rfc-editor.org/info/rfc768>.	<https://www.rfc-editor.org/info/rfc768>.


	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	RFC 792, DOI 10.17487/RFC0792, September 1981,	DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc792>.	<https://www.rfc-editor.org/info/rfc1191>.

	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.

	[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
	RFC 1812, DOI 10.17487/RFC1812, June 1995,
	<https://www.rfc-editor.org/info/rfc1812>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <https://www.rfc-editor.org/info/rfc2460>.	December 1998, <https://www.rfc-editor.org/info/rfc2460>.


	skipping to change at page 39, line 12 ¶	skipping to change at page 39, line 45 ¶
	DOI 10.17487/RFC8201, July 2017,	DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.	<https://www.rfc-editor.org/info/rfc8201>.

	[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


	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,	[I-D.ietf-intarea-tunnels]
	DOI 10.17487/RFC1191, November 1990,	Touch, J. and M. Townsley, "IP Tunnels in the Internet
	<https://www.rfc-editor.org/info/rfc1191>.	Architecture", draft-ietf-intarea-tunnels-09 (work in
		progress), July 2018.

		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
		RFC 792, DOI 10.17487/RFC0792, September 1981,
		<https://www.rfc-editor.org/info/rfc792>.

		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
		Communication Layers", STD 3, RFC 1122,
		DOI 10.17487/RFC1122, October 1989,
		<https://www.rfc-editor.org/info/rfc1122>.

		[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
		RFC 1812, DOI 10.17487/RFC1812, June 1995,
		<https://www.rfc-editor.org/info/rfc1812>.

	[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",	[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
	RFC 2923, DOI 10.17487/RFC2923, September 2000,	RFC 2923, DOI 10.17487/RFC2923, September 2000,
	<https://www.rfc-editor.org/info/rfc2923>.	<https://www.rfc-editor.org/info/rfc2923>.

	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340,	Congestion Control Protocol (DCCP)", RFC 4340,
	DOI 10.17487/RFC4340, March 2006,	DOI 10.17487/RFC4340, March 2006,
	<https://www.rfc-editor.org/info/rfc4340>.	<https://www.rfc-editor.org/info/rfc4340>.


		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
		Control Message Protocol (ICMPv6) for the Internet
		Protocol Version 6 (IPv6) Specification", STD 89,
		RFC 4443, DOI 10.17487/RFC4443, March 2006,
		<https://www.rfc-editor.org/info/rfc4443>.

	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
	<https://www.rfc-editor.org/info/rfc4821>.	<https://www.rfc-editor.org/info/rfc4821>.

	[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering	[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
	ICMPv6 Messages in Firewalls", RFC 4890,	ICMPv6 Messages in Firewalls", RFC 4890,
	DOI 10.17487/RFC4890, May 2007,	DOI 10.17487/RFC4890, May 2007,
	<https://www.rfc-editor.org/info/rfc4890>.	<https://www.rfc-editor.org/info/rfc4890>.

	Appendix A. Event-driven state changes	Appendix A. Event-driven state changes

	skipping to change at page 44, line 26 ¶	skipping to change at page 45, line 26 ¶
	/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:

	o Updated security considerations.	o Updated security considerations.

	o Feedback after speaking with Joe Touch helped improve UDP-Options	o Feedback after speaking with Joe Touch helped improve UDP-Options
	description.	description.


		Working Group draft -06:

		o Updated description of ICMP issues in section 1.1

		o Update to description of QUIC.

	Authors' Addresses	Authors' Addresses

	Godred Fairhurst	Godred Fairhurst
	University of Aberdeen	University of Aberdeen
	School of Engineering	School of Engineering
	Fraser Noble Building	Fraser Noble Building
	Aberdeen AB24 3UE	Aberdeen AB24 3UE
	UK	UK

	Email: gorry@erg.abdn.ac.uk	Email: gorry@erg.abdn.ac.uk

End of changes. 31 change blocks.
	148 lines changed or deleted	191 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/