draft-ietf-intarea-frag-fragile-16.txt   draft-ietf-intarea-frag-fragile-17.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: March 2, 2020 Unaffiliated Expires: April 2, 2020 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
August 30, 2019 September 30, 2019
IP Fragmentation Considered Fragile IP Fragmentation Considered Fragile
draft-ietf-intarea-frag-fragile-16 draft-ietf-intarea-frag-fragile-17
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.
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 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 March 2, 2020. This Internet-Draft will expire on April 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 6 skipping to change at page 3, line 6
5.4. UDP Applications Enhancing Performance . . . . . . . . . 19 5.4. UDP Applications Enhancing Performance . . . . . . . . . 19
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. For Application and Protocol Developers . . . . . . . . . 19 6.1. For Application and Protocol Developers . . . . . . . . . 19
6.2. For System Developers . . . . . . . . . . . . . . . . . . 20 6.2. For System Developers . . . . . . . . . . . . . . . . . . 20
6.3. For Middle Box Developers . . . . . . . . . . . . . . . . 20 6.3. For Middle Box Developers . . . . . . . . . . . . . . . . 20
6.4. For ECMP, LAG and Load-Balancer Developers And Operators 20 6.4. For ECMP, LAG and Load-Balancer Developers And Operators 20
6.5. For Network Operators . . . . . . . . . . . . . . . . . . 21 6.5. For Network Operators . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors' Address . . . . . . . . . . . . . . . 26 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Operational experience [Kent] [Huston] [RFC7872] reveals that IP Operational experience [Kent] [Huston] [RFC7872] reveals that IP
fragmentation introduces fragility to Internet communication. This fragmentation introduces fragility to Internet communication. This
document describes IP fragmentation and explains the fragility it document describes IP fragmentation and explains the fragility it
skipping to change at page 18, line 47 skipping to change at page 18, line 47
5.2. Open Shortest Path First (OSPF) 5.2. Open Shortest Path First (OSPF)
OSPF implementations can emit messages large enough to cause OSPF implementations can emit messages large enough to cause
fragmentation. However, in order to optimize performance, most OSPF fragmentation. However, in order to optimize performance, most OSPF
implementations restrict their maximum message size to a value that implementations restrict their maximum message size to a value that
will not cause fragmentation. will not cause fragmentation.
5.3. Packet-in-Packet Encapsulations 5.3. Packet-in-Packet Encapsulations
This document acknowledges that in some cases, packets must be
fragmented within IP-in-IP tunnels. Therefore, this document makes
no additional recommendations regarding IP-in-IP tunnels.
In this document, packet-in-packet encapsulations include IP-in-IP In this document, packet-in-packet encapsulations include IP-in-IP
[RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP
[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).
skipping to change at page 19, line 43 skipping to change at page 19, line 49
on IP fragmentation. When a new protocol or application is deployed on IP fragmentation. When a new protocol or application is deployed
in an environment that does not fully support IP fragmentation, it in an environment that does not fully support IP fragmentation, it
SHOULD operate correctly, either in its default configuration or in a SHOULD operate correctly, either in its default configuration or in a
specified alternative configuration. specified alternative configuration.
While there may be controlled environments where IP fragmentation While there may be controlled environments where IP fragmentation
works reliably, this is a deployment issue and can not be known to works reliably, this is a deployment issue and can not be known to
someone developing a new protocol or application. It is not someone developing a new protocol or application. It is not
recommended that new protocols or applications be developed that rely recommended that new protocols or applications be developed that rely
on IP fragmentation. Protocols and applications that rely on IP on IP fragmentation. Protocols and applications that rely on IP
fragmentation will fail to work on the Internet. fragmentation will work less reliably on the Internet.
Legacy protocols that depend upon IP fragmentation SHOULD be updated Legacy protocols that depend upon IP fragmentation SHOULD be updated
to break that dependency. However, in some cases, there may be no to break that dependency. However, in some cases, there may be no
viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
in-IP encapsulation). In these cases, the protocol will continue to in-IP encapsulation). Applications and protocols cannot necessarily
rely on IP fragmentation but should only be used in environments know or control whether they use lower layers or network paths that
where IP fragmentation is known to be supported. rely on such fragmentation. In these cases, the protocol will
continue to rely on IP fragmentation but should only be used in
environments where IP fragmentation is known to be supported.
Protocols may be able to avoid IP fragmentation by using a Protocols may be able to avoid IP fragmentation by using a
sufficiently small MTU (e.g. The protocol minimum link MTU), sufficiently small MTU (e.g., The protocol minimum link MTU),
disabling IP fragmentation, and ensuring that the transport protocol disabling IP fragmentation, and ensuring that the transport protocol
in use adapts its segment size to the MTU. Other protocols may in use adapts its segment size to the MTU. Other protocols may
deploy a sufficiently reliable PMTU discovery mechanism deploy a sufficiently reliable PMTU discovery mechanism (e.g.,
(e.g.,PLMPTUD). PLMPTUD).
UDP applications SHOULD abide by the recommendations stated in UDP applications SHOULD abide by the recommendations stated in
Section 3.2 of [RFC8085]. Section 3.2 of [RFC8085].
6.2. For System Developers 6.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.
6.3. For Middle Box Developers 6.3. For Middle Box Developers
skipping to change at page 23, line 44 skipping to change at page 23, line 44
[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 [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS
http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html", http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html",
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-10 (work in
progress), July 2018. progress), September 2019.
[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-07 (work in progress), March 2019. udp-options-08 (work in progress), September 2019.
[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/
WRL-87-3.pdf>. WRL-87-3.pdf>.
[Ptacek1998] [Ptacek1998]
Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial
 End of changes. 12 change blocks. 
15 lines changed or deleted 21 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/