Diff: rfc8900v2.txt - rfc8900.txt

	rfc8900v2.txt	rfc8900.txt

	skipping to change at line 14 ¶	skipping to change at line 14 ¶
	BCP: 230 F. Baker	BCP: 230 F. Baker
	Category: Best Current Practice Unaffiliated	Category: Best Current Practice Unaffiliated
	ISSN: 2070-1721 G. Huston	ISSN: 2070-1721 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

	August 2020	September 2020

	IP Fragmentation Considered Fragile	IP Fragmentation Considered Fragile

	Abstract	Abstract

	This document describes IP fragmentation and explains how it	This document describes IP fragmentation and explains how it
	introduces fragility to Internet communication.	introduces fragility to 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.

	skipping to change at line 453 ¶	skipping to change at line 453 ¶
	* IPv4 Protocol or IPv6 Next Header.	* IPv4 Protocol or IPv6 Next Header.

	Therefore, non-fragmented packets belonging to a flow can be assigned	Therefore, non-fragmented packets belonging to a flow can be assigned
	to one link while fragmented packets belonging to the same flow can	to one link while fragmented packets belonging to the same flow can
	be divided between that link and another. This can cause suboptimal	be divided between that link and another. This can cause suboptimal
	load distribution.	load distribution.

	[RFC6438] offers a partial solution to this problem for IPv6 devices	[RFC6438] offers a partial solution to this problem for IPv6 devices
	only. According to [RFC6438]:	only. According to [RFC6438]:


	\| At intermediate routers that perform load balancing, the hash	\| At intermediate routers that perform load distribution, the hash
	\| algorithm used to determine the outgoing component-link in an ECMP	\| algorithm used to determine the outgoing component-link in an ECMP
	\| and/or LAG toward the next hop MUST minimally include the 3-tuple	\| and/or LAG toward the next hop MUST minimally include the 3-tuple
	\| {dest addr, source addr, flow label} and MAY also include the	\| {dest addr, source addr, flow label} and MAY also include the
	\| remaining components of the 5-tuple.	\| remaining components of the 5-tuple.

	If the algorithm includes only the 3-tuple {dest addr, source addr,	If the algorithm includes only the 3-tuple {dest addr, source addr,
	flow label}, it will assign all fragments belonging to a packet to	flow label}, it will assign all fragments belonging to a packet to
	the same link. (See [RFC6437] and [RFC7098]).	the same link. (See [RFC6437] and [RFC7098]).

	In order to avoid the problem described above, implementations SHOULD	In order to avoid the problem described above, implementations SHOULD

	skipping to change at line 754 ¶	skipping to change at line 754 ¶

	[RFC8085] recognizes that IP fragmentation reduces the reliability of	[RFC8085] recognizes that IP fragmentation reduces the reliability of
	Internet communication. It also recognizes that UDP lacks a	Internet communication. It also recognizes that UDP lacks a
	fragmentation mechanism of its own and relies on IP fragmentation.	fragmentation mechanism of its own and relies on IP fragmentation.
	Therefore, [RFC8085] offers the following advice regarding	Therefore, [RFC8085] offers the following advice regarding
	applications the run over the UDP:	applications the run over the UDP:

	\| An application SHOULD NOT send UDP datagrams that result in IP	\| An application SHOULD NOT send UDP datagrams that result in IP
	\| packets that exceed the Maximum Transmission Unit (MTU) along the	\| packets that exceed the Maximum Transmission Unit (MTU) along the
	\| path to the destination. Consequently, an application SHOULD	\| path to the destination. Consequently, an application SHOULD

	\| either use the Path MTU information provided by the IP layer or	\| either use the path MTU information provided by the IP layer or
	\| implement Path MTU Discovery (PMTUD) itself to determine whether	\| implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981]
	\| the path to a destination will support its desired message size	\| [RFC4821] to determine whether the path to a destination will
	\| without fragmentation.	\| support its desired message size without fragmentation.

	RFC 8085 continues:	RFC 8085 continues:

	\| Applications that do not follow the recommendation to do PMTU/	\| Applications that do not follow the recommendation to do PMTU/
	\| PLPMTUD discovery SHOULD still avoid sending UDP datagrams that	\| PLPMTUD discovery SHOULD still avoid sending UDP datagrams that

	\| would result in IP packets that exceed the Path MTU. Because the	\| would result in IP packets that exceed the path MTU. Because the
	\| actual Path MTU is unknown, such applications SHOULD fall back to	\| actual path MTU is unknown, such applications SHOULD fall back to
	\| sending messages that are shorter than the default effective MTU	\| sending messages that are shorter than the default effective MTU
	\| for sending (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the	\| for sending (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the

	\| smaller of 576 octets and the first-hop MTU. For IPv6, EMTU_S is	\| smaller of 576 bytes and the first-hop MTU [RFC1122]. For IPv6,
	\| 1280 octets [RFC8200]. The effective PMTU for a directly	\| EMTU_S is 1280 bytes [RFC2460]. The effective PMTU for a directly
	\| connected destination (with no routers on the path) is the	\| connected destination (with no routers on the path) is the
	\| configured interface MTU, which could be less than the maximum	\| configured interface MTU, which could be less than the maximum
	\| link payload size. Transmission of minimum-sized UDP datagrams is	\| link payload size. Transmission of minimum-sized UDP datagrams is
	\| inefficient over paths that support a larger PMTU, which is a	\| inefficient over paths that support a larger PMTU, which is a
	\| second reason to implement PMTU discovery.	\| second reason to implement PMTU discovery.

	RFC 8085 assumes that for IPv4 an EMTU_S of 576 is sufficiently small	RFC 8085 assumes that for IPv4 an EMTU_S of 576 is sufficiently small
	to be supported by most current Internet paths, even though the IPv4	to be supported by most current Internet paths, even though the IPv4
	minimum link MTU is 68 octets.	minimum link MTU is 68 octets.


	skipping to change at line 1055 ¶	skipping to change at line 1055 ¶
	<https://www.rfc-editor.org/info/rfc8200>.	<https://www.rfc-editor.org/info/rfc8200>.

	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	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>.

	[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.	[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
	Völker, "Packetization Layer Path MTU Discovery for	Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,

	August 2020, <https://www.rfc-editor.org/info/rfc8899>.	September 2020, <https://www.rfc-editor.org/info/rfc8899>.

	9.2. Informative References	9.2. Informative References

	[Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018,	[Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018,
	<http://www.potaroo.net/ispcol/2018-04/atr.html>.	<http://www.potaroo.net/ispcol/2018-04/atr.html>.

	[Huston] Huston, G., "IPv6, Large UDP Packets and the DNS", August	[Huston] Huston, G., "IPv6, Large UDP Packets and the DNS", August
	2017,	2017,
	<http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html>.	<http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html>.


	skipping to change at line 1093 ¶	skipping to change at line 1093 ¶

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

	[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security	[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
	Considerations for IP Fragment Filtering", RFC 1858,	Considerations for IP Fragment Filtering", RFC 1858,
	DOI 10.17487/RFC1858, October 1995,	DOI 10.17487/RFC1858, October 1995,
	<https://www.rfc-editor.org/info/rfc1858>.	<https://www.rfc-editor.org/info/rfc1858>.


		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
		for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
		1996, <https://www.rfc-editor.org/info/rfc1981>.

	[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,	[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
	DOI 10.17487/RFC2003, October 1996,	DOI 10.17487/RFC2003, October 1996,
	<https://www.rfc-editor.org/info/rfc2003>.	<https://www.rfc-editor.org/info/rfc2003>.

	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,	DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.	<https://www.rfc-editor.org/info/rfc2328>.


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

	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.	December 1998, <https://www.rfc-editor.org/info/rfc2473>.

	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	DOI 10.17487/RFC2784, March 2000,	DOI 10.17487/RFC2784, March 2000,
	<https://www.rfc-editor.org/info/rfc2784>.	<https://www.rfc-editor.org/info/rfc2784>.

	[RFC3128] Miller, I., "Protection Against a Variant of the Tiny	[RFC3128] Miller, I., "Protection Against a Variant of the Tiny

	skipping to change at line 1203 ¶	skipping to change at line 1211 ¶
	Extension Headers in the Real World", RFC 7872,	Extension Headers in the Real World", RFC 7872,
	DOI 10.17487/RFC7872, June 2016,	DOI 10.17487/RFC7872, June 2016,
	<https://www.rfc-editor.org/info/rfc7872>.	<https://www.rfc-editor.org/info/rfc7872>.

	[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-	[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
	in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,	in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
	March 2017, <https://www.rfc-editor.org/info/rfc8086>.	March 2017, <https://www.rfc-editor.org/info/rfc8086>.

	[TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet	[TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet
	Architecture", Work in Progress, Internet-Draft, draft-	Architecture", Work in Progress, Internet-Draft, draft-

	ietf-intarea-tunnels-10, 12 September 2019,	ietf-intarea-tunnels-10, September 12, 2019,
	<https://tools.ietf.org/html/draft-ietf-intarea-tunnels-	<https://tools.ietf.org/html/draft-ietf-intarea-tunnels-
	10>.	10>.

	[UDP-OPTIONS]	[UDP-OPTIONS]
	Touch, J., "Transport Options for UDP", Work in Progress,	Touch, J., "Transport Options for UDP", Work in Progress,

	Internet-Draft, draft-ietf-tsvwg-udp-options-08, 12	Internet-Draft, draft-ietf-tsvwg-udp-options-08, September
	September 2019, <https://tools.ietf.org/html/draft-ietf-	12, 2019, <https://tools.ietf.org/html/draft-ietf-tsvwg-
	tsvwg-udp-options-08>.	udp-options-08>.

	Acknowledgements	Acknowledgements

	Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan,	Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan,
	Lorenzo Colitti, Gorry Fairhurst, Joel Halpern, Mike Heard, Tom	Lorenzo Colitti, Gorry Fairhurst, Joel Halpern, Mike Heard, Tom
	Herbert, Tatuya Jinmei, Suresh Krishnan, Jen Linkova, Paolo Lucente,	Herbert, Tatuya Jinmei, Suresh Krishnan, Jen Linkova, Paolo Lucente,
	Manoj Nayak, Eric Nygren, Fred Templin, and Joe Touch for their	Manoj Nayak, Eric Nygren, Fred Templin, and Joe Touch for their
	comments.	comments.

	Authors' Addresses	Authors' Addresses

End of changes. 10 change blocks.
	15 lines changed or deleted	23 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/