--- 1/draft-ietf-intarea-frag-fragile-02.txt 2018-11-21 07:15:35.112576663 -0800 +++ 2/draft-ietf-intarea-frag-fragile-03.txt 2018-11-21 07:15:35.160577815 -0800 @@ -1,27 +1,27 @@ Internet Area WG R. Bonica Internet-Draft Juniper Networks Intended status: Best Current Practice F. Baker -Expires: April 21, 2019 Unaffiliated +Expires: May 25, 2019 Unaffiliated G. Huston APNIC R. Hinden Check Point Software O. Troan Cisco F. Gont SI6 Networks - October 18, 2018 + November 21, 2018 IP Fragmentation Considered Fragile - draft-ietf-intarea-frag-fragile-02 + draft-ietf-intarea-frag-fragile-03 Abstract This document describes IP fragmentation and explains how it reduces the reliability of Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. Status of This Memo @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,26 +77,26 @@ 4.7. Blackholing Due To Filtering . . . . . . . . . . . . . . 13 5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 13 5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 13 5.2. Application Layer Solutions . . . . . . . . . . . . . . . 15 6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 16 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 17 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 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.4. For Network Operators . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Operational experience [Kent] [Huston] [RFC7872] reveals that IP fragmentation reduces the reliability of Internet communication. @@ -768,83 +768,91 @@ 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). Section 3.3 of [RFC7676] further describes this corner case. See [I-D.ietf-intarea-tunnels] for further discussion. 7. Recommendations 7.1. For Application Developers - Application developers SHOULD NOT develop new applications that rely - on IP fragmentation. + Protocol developers SHOULD NOT develop new protocols that rely on IP + 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 - SHOULD be updated to break that dependency. This can be achieved by - using a sufficiently small MTU (e.g. The protocol minimum link MTU), - disabling fragmentation, and ensuring that the transport protocol in - use adapts its segment size to that MTU. This would avoid the - 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 - (e.g. [I-D.ietf-tsvwg-datagram-plpmtud] for UDP). + Legacy protocols that depend upon IP fragmentation SHOULD be updated + to break that dependency. However, in some cases, there may be no + viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- + in-IP encapsulation). In these cases, the protocol will continue to + rely on IP fragmentation. + + Some legacy protocols may be able to break their dependency upon IP + 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 Software libraries SHOULD include provision for PLPMTUD for each supported transport protocol. 7.3. For Middle Box Developers - Middle box developers SHOULD implement devices that support IP - fragmentation. These boxes SHOULD not fail or cause failures when - processing fragmented IP packets. - - 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) + Middle boxes SHOULD process IP fragments in a manner that is + compliant with RFC 791 and RFC 8200. In many cases, middle boxes + must maintain state in order to achieve this goal. - o Forward the first fragment and all subsequent fragments through - the above-mentioned next-hop + Price and performance considerations frequently motivate network + 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 As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB messages unless they are known to be forged or otherwise illegitimate. As stated in Section 4.6, filtering ICMPv6 PTB packets causes PMTUD to fail. Operators MUST ensure proper PMTUD operation in their network, including making sure the network generates PTB 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 This document makes no request of IANA. 9. Security Considerations This document mitigates some of the security considerations associated with IP fragmentation by discouraging its use. It does not introduce any new security vulnerabilities, because it does not introduce any new alternatives to IP fragmentation. Instead, it recommends well-understood alternatives. 10. Acknowledgements Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, - Lorenzo Colitti, Mike Heard, Tom Herbert, Tatuya Jinmei, Paolo - Lucente, Manoj Nayak, Eric Nygren, and Joe Touch for their comments. + Lorenzo Colitti, Mike Heard, Tom Herbert, Tatuya Jinmei, Jen Linkova, + Paolo Lucente, Manoj Nayak, Eric Nygren, and Joe Touch for their + comments. 11. References 11.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, @@ -910,22 +918,22 @@ August 2017. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-09 (work in progress), July 2018. [I-D.ietf-tsvwg-datagram-plpmtud] Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, "Packetization Layer Path MTU Discovery for Datagram - Transports", draft-ietf-tsvwg-datagram-plpmtud-05 (work in - progress), October 2018. + Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in + progress), November 2018. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-05 (work in progress), July 2018. [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524", August 1987,