draft-ietf-intarea-frag-fragile-02.txt		draft-ietf-intarea-frag-fragile-03.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 21, 2019 Unaffiliated		Expires: May 25, 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 18, 2018		November 21, 2018
	IP Fragmentation Considered Fragile		IP Fragmentation Considered Fragile
	draft-ietf-intarea-frag-fragile-02		draft-ietf-intarea-frag-fragile-03
	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 21, 2019.		This Internet-Draft will expire on May 25, 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 43 ¶		skipping to change at page 2, line 43 ¶
	4.7. Blackholing Due To Filtering . . . . . . . . . . . . . . 13		4.7. Blackholing Due To Filtering . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . 18
	7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 18		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 . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . 19		11.1. Normative References . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . 20		11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Contributors' Address . . . . . . . . . . . . . . . 23		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.
	skipping to change at page 17, line 32 ¶		skipping to change at page 17, line 32 ¶
	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.		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		Protocol developers SHOULD NOT develop new protocols that rely on IP
	on IP fragmentation.		fragmentation. However, they MAY develop new protocols that rely on
			IP fragmentation when no viable alternative exists.
	Application-layer protocols that depend upon IPv6 fragmentation		Legacy protocols that depend upon IP fragmentation SHOULD be updated
	SHOULD be updated to break that dependency. This can be achieved by		to break that dependency. However, in some cases, there may be no
	using a sufficiently small MTU (e.g. The protocol minimum link MTU),		viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
	disabling fragmentation, and ensuring that the transport protocol in		in-IP encapsulation). In these cases, the protocol will continue to
	use adapts its segment size to that MTU. This would avoid the		rely on IP fragmentation.
	problem of PMTUD failure described in Section 4.6. Another approach
	is to use PLPMTUD in a way suitable for the transport protocol in use		Some legacy protocols may be able to break their dependency upon IP
	(e.g. [I-D.ietf-tsvwg-datagram-plpmtud] for UDP).		fragmentation by using a sufficiently small MTU (e.g. The protocol
			minimum link MTU), disabling IP fragmentation, and ensuring that the
			transport protocol in use adapts its segment size to the MTU. Other
			legacy protocols may deploy a sufficiently reliable PMTU discovery
			mechanism (e.g., PLMPTUD). However, some legacy protocols will not
			be able to break their dependency on IP fragmentation at all.
	7.2. For System Developers		7.2. For System Developers
	Software libraries SHOULD include provision for PLPMTUD for each		Software libraries SHOULD include provision for PLPMTUD for each
	supported transport protocol.		supported transport protocol.
	7.3. For Middle Box Developers		7.3. For Middle Box Developers
	Middle box developers SHOULD implement devices that support IP		Middle boxes SHOULD process IP fragments in a manner that is
	fragmentation. These boxes SHOULD not fail or cause failures when		compliant with RFC 791 and RFC 8200. In many cases, middle boxes
	processing fragmented IP packets.		must maintain state in order to achieve this goal.
	For example, in order to support IP fragmentation, a load balancer
	might execute the following procedure:
	o Receive a fragmented packet
	o Identify a next-hop using information drawn from the first
	fragment (i.e., the fragment containing offset 0)
	o Forward the first fragment and all subsequent fragments through		Price and performance considerations frequently motivate network
	the above-mentioned next-hop		operators to deploy stateless middle boxes. These stateless middle
			boxes may perform sub-optimally, process IP fragments in a manner
			that is not compliant with RFC 791 or RFC 8200, or even discard IP
			fragments completely. Such behaviors are NOT RECOMMENDED. If a
			middleboxes implements non-standard behavior with respect to IP
			fragmentation, then that behavior MUST be clearly documented.
	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
	in their network, including making sure the network generates PTB		in their network, including making sure the network generates PTB
	packets when dropping packets too large compared to outgoing		packets when dropping packets too large compared to outgoing
	interface MTU.		interface MTU. Many upper-layer protocols rely on PMTUD.
	Many upper-layer protocols rely on PMTUD.		As per RFC 8200, network operators MUST NOT deploy IPv6 links whose
			MTU is less than 1280 bytes.
			Network operators SHOULD NOT filter IP fragments if they originated
			at a domain name server or are destined for a domain name server.
	8. IANA Considerations		8. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	9. Security Considerations		9. Security Considerations
	This document mitigates some of the security considerations		This document mitigates some of the security considerations
	associated with IP fragmentation by discouraging its use. It does		associated with IP fragmentation by discouraging its use. It does
	not introduce any new security vulnerabilities, because it does not		not introduce any new security vulnerabilities, because it does not
	introduce any new alternatives to IP fragmentation. Instead, it		introduce any new alternatives to IP fragmentation. Instead, it
	recommends well-understood alternatives.		recommends well-understood alternatives.
	10. Acknowledgements		10. Acknowledgements
	Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan,		Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan,
	Lorenzo Colitti, Mike Heard, Tom Herbert, Tatuya Jinmei, Paolo		Lorenzo Colitti, Mike Heard, Tom Herbert, Tatuya Jinmei, Jen Linkova,
	Lucente, Manoj Nayak, Eric Nygren, and Joe Touch for their comments.		Paolo Lucente, Manoj Nayak, Eric Nygren, and Joe Touch for their
			comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[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>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	skipping to change at page 20, line 36 ¶		skipping to change at page 20, line 44 ¶
	August 2017.		August 2017.
	[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), July 2018.		progress), July 2018.
	[I-D.ietf-tsvwg-datagram-plpmtud]		[I-D.ietf-tsvwg-datagram-plpmtud]
	Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler,		Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler,
	"Packetization Layer Path MTU Discovery for Datagram		"Packetization Layer Path MTU Discovery for Datagram
	Transports", draft-ietf-tsvwg-datagram-plpmtud-05 (work in		Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in
	progress), October 2018.		progress), November 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.
	[Kent] Kent, C. and J. Mogul, ""Fragmentation Considered		[Kent] Kent, C. and J. Mogul, ""Fragmentation Considered
	Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in		Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in
	Computer Communications Technology, DOI		Computer Communications Technology, DOI
	10.1145/55483.55524", August 1987,		10.1145/55483.55524", August 1987,
	<http://www.hpl.hp.com/techreports/Compaq-DEC/		<http://www.hpl.hp.com/techreports/Compaq-DEC/
End of changes. 14 change blocks.
	35 lines changed or deleted		43 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/