draft-ietf-intarea-frag-fragile-01.txt		draft-ietf-intarea-frag-fragile-02.txt
	Internet Area WG R. Bonica		Internet Area WG R. Bonica
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Best Current Practice F. Baker		Intended status: Best Current Practice F. Baker
	Expires: April 13, 2019 Unaffiliated		Expires: April 21, 2019 Unaffiliated
	G. Huston		G. Huston
	APNIC		APNIC
	R. Hinden		R. Hinden
	Check Point Software		Check Point Software
	O. Troan		O. Troan
	Cisco		Cisco
	F. Gont		F. Gont
	SI6 Networks		SI6 Networks
	October 10, 2018		October 18, 2018
	IP Fragmentation Considered Fragile		IP Fragmentation Considered Fragile
	draft-ietf-intarea-frag-fragile-01		draft-ietf-intarea-frag-fragile-02
	Abstract		Abstract
	This document describes IP fragmentation and explains how it reduces		This document describes IP fragmentation and explains how it reduces
	the reliability of Internet communication.		the reliability of Internet communication.
	This document also proposes alternatives to IP fragmentation and		This document also proposes alternatives to IP fragmentation and
	provides recommendations for developers and network operators.		provides recommendations for developers and network operators.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 13, 2019.		This Internet-Draft will expire on April 21, 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
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 13		5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 13
	5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 13		5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 13
	5.2. Application Layer Solutions . . . . . . . . . . . . . . . 15		5.2. Application Layer Solutions . . . . . . . . . . . . . . . 15
	6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 16		6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 16
	6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 17		6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 17
	7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17		7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
	7.1. For Application Developers . . . . . . . . . . . . . . . 17		7.1. For Application Developers . . . . . . . . . . . . . . . 17
	7.2. For System Developers . . . . . . . . . . . . . . . . . . 17		7.2. For System Developers . . . . . . . . . . . . . . . . . . 17
	7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 17		7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 18
	7.4. For Network Operators . . . . . . . . . . . . . . . . . . 18		7.4. For Network Operators . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 18		9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . 20		11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Contributors' Address . . . . . . . . . . . . . . . 22		Appendix A. Contributors' Address . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Operational experience [Kent] [Huston] [RFC7872] reveals that IP		Operational experience [Kent] [Huston] [RFC7872] reveals that IP
	fragmentation reduces the reliability of Internet communication.		fragmentation reduces the reliability of Internet communication.
	This document describes IP fragmentation and explains how it reduces		This document describes IP fragmentation and explains how it reduces
	the reliability of Internet communication. This document also		the reliability of Internet communication. This document also
	proposes alternatives to IP fragmentation and provides		proposes alternatives to IP fragmentation and provides
	recommendations for developers and network operators.		recommendations for developers and network operators.
	While this document identifies issues associated with IP		While this document identifies issues associated with IP
	fragmentation, it does not recommend deprecation. Some applications		fragmentation, it does not recommend deprecation. Some applications
	(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation.		(see Section 6) require IP fragmentation. Furthermore, fragmentation
			is expected to work in limited domains where security and
			interoperability issues can be addressed.
	Rather than deprecating IP Fragmentation, this document recommends		Rather than deprecating IP Fragmentation, this document recommends
	that upper-layer protocols address the problem of fragmentation at		that upper-layer protocols address the problem of fragmentation at
	their layer, reducing their reliance on IP fragmentation to the		their layer, reducing their reliance on IP fragmentation to the
	greatest degree possible.		greatest degree possible.
	2. IP Fragmentation		2. IP Fragmentation
	2.1. Links, Paths, MTU and PMTU		2.1. Links, Paths, MTU and PMTU
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 26 ¶
	[RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459]		[RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459]
	describes fragmentation issues associated with all of the above-		describes fragmentation issues associated with all of the above-
	mentioned encapsulations.		mentioned encapsulations.
	The fragmentation strategy described for GRE in [RFC7588] has been		The fragmentation strategy described for GRE in [RFC7588] has been
	deployed for all of the above-mentioned encapsulations. This		deployed for all of the above-mentioned encapsulations. This
	strategy does not rely on IP fragmentation except in one corner case.		strategy does not rely on IP fragmentation except in one corner case.
	(see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473).		(see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473).
	Section 3.3 of [RFC7676] further describes this corner case.		Section 3.3 of [RFC7676] further describes this corner case.
			See [I-D.ietf-intarea-tunnels] for further discussion.
	7. Recommendations		7. Recommendations
	7.1. For Application Developers		7.1. For Application Developers
	Application developers SHOULD NOT develop new applications that rely		Application developers SHOULD NOT develop new applications that rely
	on IP fragmentation.		on IP fragmentation.
	Application-layer protocols that depend upon IPv6 fragmentation		Application-layer protocols that depend upon IPv6 fragmentation
	SHOULD be updated to break that dependency. This can be achieved by		SHOULD be updated to break that dependency. This can be achieved by
	using a sufficiently small MTU (e.g. The protocol minimum link MTU),		using a sufficiently small MTU (e.g. The protocol minimum link MTU),
	skipping to change at page 18, line 11 ¶		skipping to change at page 18, line 17 ¶
	Middle box developers SHOULD implement devices that support IP		Middle box developers SHOULD implement devices that support IP
	fragmentation. These boxes SHOULD not fail or cause failures when		fragmentation. These boxes SHOULD not fail or cause failures when
	processing fragmented IP packets.		processing fragmented IP packets.
	For example, in order to support IP fragmentation, a load balancer		For example, in order to support IP fragmentation, a load balancer
	might execute the following procedure:		might execute the following procedure:
	o Receive a fragmented packet		o Receive a fragmented packet
	o Identify a next-hop using information drawn from the first		o Identify a next-hop using information drawn from the first
	fragment		fragment (i.e., the fragment containing offset 0)
	o Forward the first fragment and all subsequent fragments through		o Forward the first fragment and all subsequent fragments through
	the above-mentioned next-hop		the above-mentioned next-hop
	7.4. For Network Operators		7.4. For Network Operators
	As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB		As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB
	messages unless they are known to be forged or otherwise		messages unless they are known to be forged or otherwise
	illegitimate. As stated in Section 4.6, filtering ICMPv6 PTB packets		illegitimate. As stated in Section 4.6, filtering ICMPv6 PTB packets
	causes PMTUD to fail. Operators MUST ensure proper PMTUD operation		causes PMTUD to fail. Operators MUST ensure proper PMTUD operation
End of changes. 10 change blocks.
	10 lines changed or deleted		14 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/