draft-ietf-6man-rfc1981bis-05.txt		draft-ietf-6man-rfc1981bis-06.txt
	Network Working Group J. McCann		Network Working Group J. McCann
	Internet-Draft Digital Equipment Corporation		Internet-Draft Digital Equipment Corporation
	Obsoletes: 1981 (if approved) S. Deering		Obsoletes: 1981 (if approved) S. Deering
	Intended status: Standards Track Retired		Intended status: Standards Track Retired
	Expires: October 2, 2017 J. Mogul		Expires: October 9, 2017 J. Mogul
	Digital Equipment Corporation		Digital Equipment Corporation
	R. Hinden, Ed.		R. Hinden, Ed.
	Check Point Software		Check Point Software
	March 31, 2017		April 7, 2017
	Path MTU Discovery for IP version 6		Path MTU Discovery for IP version 6
	draft-ietf-6man-rfc1981bis-05		draft-ietf-6man-rfc1981bis-06
	Abstract		Abstract
	This document describes Path MTU Discovery for IP version 6. It is		This document describes Path MTU Discovery for IP version 6. It is
	largely derived from RFC 1191, which describes Path MTU Discovery for		largely derived from RFC 1191, which describes Path MTU Discovery for
	IP version 4. It obsoletes RFC1981.		IP version 4. It obsoletes RFC1981.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 October 2, 2017.		This Internet-Draft will expire on October 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	5.5. Issues for other transport protocols . . . . . . . . . . 12		5.5. Issues for other transport protocols . . . . . . . . . . 12
	5.6. Management interface . . . . . . . . . . . . . . . . . . 13		5.6. Management interface . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15		Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15
	Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16		Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	When one IPv6 node has a large amount of data to send to another		When one IPv6 node has a large amount of data to send to another
	node, the data is transmitted in a series of IPv6 packets. These		node, the data is transmitted in a series of IPv6 packets. These
	packets can have a size less than or equal to the Path MTU (PMTU).		packets can have a size less than or equal to the Path MTU (PMTU).
	Alternatively, they can be larger packets that are fragmented into a		Alternatively, they can be larger packets that are fragmented into a
	series of fragments each with a size less than or equal to the PMTU.		series of fragments each with a size less than or equal to the PMTU.
	It is usually preferable that these packets be of the largest size		It is usually preferable that these packets be of the largest size
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum		Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum
	link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet		link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet
	size. In most cases, this will result in the use of smaller packets		size. In most cases, this will result in the use of smaller packets
	than necessary, because most paths have a PMTU greater than the IPv6		than necessary, because most paths have a PMTU greater than the IPv6
	minimum link MTU. A node sending packets much smaller than the Path		minimum link MTU. A node sending packets much smaller than the Path
	MTU allows is wasting network resources and probably getting		MTU allows is wasting network resources and probably getting
	suboptimal throughput.		suboptimal throughput.
	Nodes implementing Path MTU Discovery and sending packets larger than		Nodes implementing Path MTU Discovery and sending packets larger than
	the IPv6 minimum link MTU are susceptible to loss if ICMPv6 [ICMPv6]		the IPv6 minimum link MTU are susceptible to problematic connectivity
	messages are blocked or not transmitted. For example, this will		if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For
	result in connections that complete the TCP three-way handshake		example, this will result in connections that complete the TCP three-
	correctly but then hang when data is transferred. This state is		way handshake correctly but then hang when data is transferred. This
	referred to as a black hole connection. Path MTU Discovery relies on		state is referred to as a black hole connection. Path MTU Discovery
	such messages to determine the MTU of the path.		relies on such messages to determine the MTU of the path.
	An extension to Path MTU Discovery defined in this document can be		An extension to Path MTU Discovery defined in this document can be
	found in [RFC4821]. RFC4821 defines a method for Packetization Layer		found in [RFC4821]. RFC4821 defines a method for Packetization Layer
	Path MTU Discovery (PLPMTUD) designed for use over paths where		Path MTU Discovery (PLPMTUD) designed for use over paths where
	delivery of ICMPv6 messages to a host is not assured.		delivery of ICMPv6 messages to a host is not assured.
	2. Terminology		2. Terminology
	node a device that implements IPv6.		node a device that implements IPv6.
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	layering, packetization layers require a way to learn of changes in		layering, packetization layers require a way to learn of changes in
	the value of MMS_S, the "maximum send transport-message size".		the value of MMS_S, the "maximum send transport-message size".
	MMS_S is a transport message size calculated by subtracting the size		MMS_S is a transport message size calculated by subtracting the size
	of the IPv6 header (including IPv6 extension headers) from the		of the IPv6 header (including IPv6 extension headers) from the
	largest IP packet that can be sent, EMTU_S. MMS_S is limited by a		largest IP packet that can be sent, EMTU_S. MMS_S is limited by a
	combination of factors, including the PMTU, support for packet		combination of factors, including the PMTU, support for packet
	fragmentation and reassembly, and the packet reassembly limit (see		fragmentation and reassembly, and the packet reassembly limit (see
	[I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source		[I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source
	fragmentation is available, EMTU_S is set to EMTU_R, as indicated by		fragmentation is available, EMTU_S is set to EMTU_R, as indicated by
	the receiver at using an upper layer protocol or based on protocol		the receiver using an upper layer protocol or based on protocol
	requirements (1500 octets for IPv6). When a message larger than PMTU		requirements (1500 octets for IPv6). When a message larger than PMTU
	is to be transmitted, the source creates fragments, each limited by		is to be transmitted, the source creates fragments, each limited by
	PMTU. When source fragmentation is not desired, EMTU_S is set to		PMTU. When source fragmentation is not desired, EMTU_S is set to
	PMTU, and the upper layer protocol is expected to either perform its		PMTU, and the upper layer protocol is expected to either perform its
	own fragmentation and reassembly or otherwise limit the size of its		own fragmentation and reassembly or otherwise limit the size of its
	messages accordingly.		messages accordingly.
	However, packetization layers are encouraged to avoid sending		However, packetization layers are encouraged to avoid sending
	messages that will require source fragmentation (for the case against		messages that will require source fragmentation (for the case against
	fragmentation, see [FRAG]).		fragmentation, see [FRAG]).
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	Note: if the original packet contained a Routing header, the		Note: if the original packet contained a Routing header, the
	Routing header should be used to determine the location of the		Routing header should be used to determine the location of the
	destination address within the original packet. If Segments Left		destination address within the original packet. If Segments Left
	is equal to zero, the destination address is in the Destination		is equal to zero, the destination address is in the Destination
	Address field in the IPv6 header. If Segments Left is greater		Address field in the IPv6 header. If Segments Left is greater
	than zero, the destination address is the last address		than zero, the destination address is the last address
	(Address[n]) in the Routing header.		(Address[n]) in the Routing header.
	The node then uses the value in the MTU field in the Packet Too Big		The node then uses the value in the MTU field in the Packet Too Big
	message as a tentative PMTU value or the minimum IPv6 next hope MTU		message as a tentative PMTU value or the IPv6 minimum link MTU if
	if that is larger, and compares the tentative PMTU to the existing		that is larger, and compares the tentative PMTU to the existing PMTU.
	PMTU. If the tentative PMTU is less than the existing PMTU estimate,		If the tentative PMTU is less than the existing PMTU estimate, the
	the tentative PMTU replaces the existing PMTU as the PMTU value for		tentative PMTU replaces the existing PMTU as the PMTU value for the
	the path.		path.
	The packetization layers must be notified about decreases in the		The packetization layers must be notified about decreases in the
	PMTU. Any packetization layer instance (for example, a TCP		PMTU. Any packetization layer instance (for example, a TCP
	connection) that is actively using the path must be notified if the		connection) that is actively using the path must be notified if the
	PMTU estimate is decreased.		PMTU estimate is decreased.
	Note: even if the Packet Too Big message contains an Original		Note: even if the Packet Too Big message contains an Original
	Packet Header that refers to a UDP packet, the TCP layer must be		Packet Header that refers to a UDP packet, the TCP layer must be
	notified if any of its connections use the given path.		notified if any of its connections use the given path.
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	A malicious party could also cause problems if it could stop a victim		A malicious party could also cause problems if it could stop a victim
	from receiving legitimate Packet Too Big messages, but in this case		from receiving legitimate Packet Too Big messages, but in this case
	there are simpler denial-of-service attacks available.		there are simpler denial-of-service attacks available.
	If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big		If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
	messages, the source will not learn the actual path MTU.		messages, the source will not learn the actual path MTU.
	Packetization Layer Path MTU Discovery [RFC4821] does not rely upon		Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
	network support for ICMPv6 messages and is therefore considered more		network support for ICMPv6 messages and is therefore considered more
	robust than standard PMTUD. It is not susceptible to "black holing"		robust than standard PMTUD. It is not susceptible to "black holing"
	of ICMPv6 message.		of ICMPv6 message. See [RFC4890] for recommendations regarding
			filtering ICMPv6 messages.
	7. Acknowledgements		7. Acknowledgements
	We would like to acknowledge the authors of and contributors to		We would like to acknowledge the authors of and contributors to
	[RFC1191], from which the majority of this document was derived. We		[RFC1191], from which the majority of this document was derived. We
	would also like to acknowledge the members of the IPng working group		would also like to acknowledge the members of the IPng working group
	for their careful review and constructive criticisms.		for their careful review and constructive criticisms.
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 18 ¶
	<http://www.rfc-editor.org/info/rfc4861>.		<http://www.rfc-editor.org/info/rfc4861>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<http://www.rfc-editor.org/info/rfc1191>.		<http://www.rfc-editor.org/info/rfc1191>.
	[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,
	<http://www.rfc-editor.org/info/rfc4821>.		<http://www.rfc-editor.org/info/rfc4821>.
			[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
			ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/
			RFC4890, May 2007,
			<http://www.rfc-editor.org/info/rfc4890>.
	[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",		[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
	RFC 6691, DOI 10.17487/RFC6691, July 2012,		RFC 6691, DOI 10.17487/RFC6691, July 2012,
	<http://www.rfc-editor.org/info/rfc6691>.		<http://www.rfc-editor.org/info/rfc6691>.
	[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System		[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
	(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,		(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
	March 2015, <http://www.rfc-editor.org/info/rfc7530>.		March 2015, <http://www.rfc-editor.org/info/rfc7530>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 10 ¶
	is discussed in [I-D.ietf-6man-rfc2460bis]		is discussed in [I-D.ietf-6man-rfc2460bis]
	old-style messages all Packet Too Big messages report the MTU of		old-style messages all Packet Too Big messages report the MTU of
	the constricting link		the constricting link
	MTU plateau tables not needed because there are no old-style		MTU plateau tables not needed because there are no old-style
	messages		messages
	Appendix B. Changes Since RFC 1981		Appendix B. Changes Since RFC 1981
	This document has the following changes from RFC1981. Numbers		This document is based on RFC1981 has the following changes from
	identify the Internet-Draft version where the change was made:		RFC1981:
			o Clarified Section 1 "Introduction" that the purpose of PMTUD is to
			reduce the need for IPv6 fragmentation.
			o Added text to Section 1 "Introduction" and Section 6 "Security
			Considerations" about the effects on PMTUD when ICMPv6 messages
			are blocked.
			o Added a short summary to the Section 1 "Introduction" of
			Packetization Layer Path MTU Discovery ((PLPMTUD) and a reference
			to RFC4821 that defines it.
			o Aligned text in Section 2 "Terminology" to match current
			packetization layer terminology.
			o Added clarification in Section 4 "Protocol Requirements" that
			nodes should validate the payload of ICMP PTB message per RFC4443.
			o Remove Note from Section 4 "Protocol Requirements" about a Packet
			Too Big message reporting a next-hop MTU that is less than the
			IPv6 minimum link MTU because this was removed from
			[I-D.ietf-6man-rfc2460bis].
			o Added clarification in Section 5.2 "Storing PMTU information" to
			discard an ICMPv6 Packet Too Big message if it contains a MTU less
			than the IPv6 minimum link MTU.
			o Removed text in Section 5.2 "Storing PMTU information" about the
			RH0 routing header because it was deprecated by RFC5095.
			o Removed text about obsolete security classification from
			Section 5.2 "Storing PMTU information".
			o Changed title of Section 5.4 to "Packetization Layer actions" and
			changed to text in the first paragraph to to generalize this
			section to cover all packetization layers, not just TCP.
			o Clarified text in Section 5.4 "Packetization Layer actions" to use
			normal packetization layer retransmission methods.
			o Removed text in Section 5.4 "Packetization Layer actions" that
			described 4.2 BSD because it is obsolete, and removed reference to
			TP4.
			o Updated text in Section 5.5 "Issues for other transport protocols"
			about NFS including adding a current reference to NFS and removing
			obsolete text.
			o Editorial Changes.
			B.1. Change History Since RFC1981
			NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
			Publication
			This section describes change history made in each Internet Draft
			that went into producing this version. The numbers identify the
			Internet-Draft version in which the change was made.
	Working Group Internet Drafts		Working Group Internet Drafts
			06) Revised Appendix B "Changes since RFC1981" to have a summary
			of changes since RFC1981 and a separate subsection with a
			change history of each Internet Draft. This subsection will
			be removed when the RFC is published.
			06) Editorial changes based on comments received after publishing
			the -05 draft.
	05) Changes based on IETF last call reviews by Gorry Fairhurst,		05) Changes based on IETF last call reviews by Gorry Fairhurst,
	Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef,		Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef,
	and Donald Eastlake. This includes includes:		and Donald Eastlake. This includes includes:
	o Clarify that the purpose of PMTUD is to reduce the need		o Clarify that the purpose of PMTUD is to reduce the need
	for IPv6 Fragmentation.		for IPv6 Fragmentation.
	o Added text to Introduction about effects on PMTUD when		o Added text to Introduction about effects on PMTUD when
	ICMPv6 messages are blocked.		ICMPv6 messages are blocked.
End of changes. 12 change blocks.
	20 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/