--- 1/draft-ietf-6man-rfc1981bis-05.txt 2017-04-07 11:13:11.226222711 -0700 +++ 2/draft-ietf-6man-rfc1981bis-06.txt 2017-04-07 11:13:11.266223654 -0700 @@ -1,23 +1,23 @@ Network Working Group J. McCann Internet-Draft Digital Equipment Corporation Obsoletes: 1981 (if approved) S. Deering Intended status: Standards Track Retired -Expires: October 2, 2017 J. Mogul +Expires: October 9, 2017 J. Mogul Digital Equipment Corporation R. Hinden, Ed. Check Point Software - March 31, 2017 + April 7, 2017 Path MTU Discovery for IP version 6 - draft-ietf-6man-rfc1981bis-05 + draft-ietf-6man-rfc1981bis-06 Abstract This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -26,21 +26,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 http://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 October 2, 2017. + This Internet-Draft will expire on October 9, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,21 +76,22 @@ 5.5. Issues for other transport protocols . . . . . . . . . . 12 5.6. Management interface . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction When one IPv6 node has a large amount of data to send to another node, the data is transmitted in a series of IPv6 packets. These packets can have a size less than or equal to the Path MTU (PMTU). Alternatively, they can be larger packets that are fragmented into a series of fragments each with a size less than or equal to the PMTU. It is usually preferable that these packets be of the largest size @@ -109,26 +110,26 @@ Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size. In most cases, this will result in the use of smaller packets than necessary, because most paths have a PMTU greater than the IPv6 minimum link MTU. A node sending packets much smaller than the Path MTU allows is wasting network resources and probably getting suboptimal throughput. Nodes implementing Path MTU Discovery and sending packets larger than - the IPv6 minimum link MTU are susceptible to loss if ICMPv6 [ICMPv6] - messages are blocked or not transmitted. For example, this will - result in connections that complete the TCP three-way handshake - correctly but then hang when data is transferred. This state is - referred to as a black hole connection. Path MTU Discovery relies on - such messages to determine the MTU of the path. + the IPv6 minimum link MTU are susceptible to problematic connectivity + if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For + example, this will result in connections that complete the TCP three- + way handshake correctly but then hang when data is transferred. This + state is referred to as a black hole connection. Path MTU Discovery + relies on such messages to determine the MTU of the path. An extension to Path MTU Discovery defined in this document can be found in [RFC4821]. RFC4821 defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMPv6 messages to a host is not assured. 2. Terminology node a device that implements IPv6. @@ -327,21 +328,21 @@ layering, packetization layers require a way to learn of changes in the value of MMS_S, the "maximum send transport-message size". MMS_S is a transport message size calculated by subtracting the size of the IPv6 header (including IPv6 extension headers) from the largest IP packet that can be sent, EMTU_S. MMS_S is limited by a combination of factors, including the PMTU, support for packet fragmentation and reassembly, and the packet reassembly limit (see [I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source fragmentation is available, EMTU_S is set to EMTU_R, as indicated by - the receiver at using an upper layer protocol or based on protocol + the receiver using an upper layer protocol or based on protocol requirements (1500 octets for IPv6). When a message larger than PMTU is to be transmitted, the source creates fragments, each limited by PMTU. When source fragmentation is not desired, EMTU_S is set to PMTU, and the upper layer protocol is expected to either perform its own fragmentation and reassembly or otherwise limit the size of its messages accordingly. However, packetization layers are encouraged to avoid sending messages that will require source fragmentation (for the case against fragmentation, see [FRAG]). @@ -402,25 +403,25 @@ Note: if the original packet contained a Routing header, the Routing header should be used to determine the location of the destination address within the original packet. If Segments Left is equal to zero, the destination address is in the Destination Address field in the IPv6 header. If Segments Left is greater than zero, the destination address is the last address (Address[n]) in the Routing header. The node then uses the value in the MTU field in the Packet Too Big - message as a tentative PMTU value or the minimum IPv6 next hope MTU - if that is larger, and compares the tentative PMTU to the existing - PMTU. If the tentative PMTU is less than the existing PMTU estimate, - the tentative PMTU replaces the existing PMTU as the PMTU value for - the path. + message as a tentative PMTU value or the IPv6 minimum link MTU if + that is larger, and compares the tentative PMTU to the existing PMTU. + If the tentative PMTU is less than the existing PMTU estimate, the + tentative PMTU replaces the existing PMTU as the PMTU value for the + path. The packetization layers must be notified about decreases in the PMTU. Any packetization layer instance (for example, a TCP connection) that is actively using the path must be notified if the PMTU estimate is decreased. Note: even if the Packet Too Big message contains an Original Packet Header that refers to a UDP packet, the TCP layer must be notified if any of its connections use the given path. @@ -623,21 +624,22 @@ A malicious party could also cause problems if it could stop a victim from receiving legitimate Packet Too Big messages, but in this case there are simpler denial-of-service attacks available. If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big messages, the source will not learn the actual path MTU. Packetization Layer Path MTU Discovery [RFC4821] does not rely upon network support for ICMPv6 messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holing" - of ICMPv6 message. + of ICMPv6 message. See [RFC4890] for recommendations regarding + filtering ICMPv6 messages. 7. Acknowledgements We would like to acknowledge the authors of and contributors to [RFC1191], from which the majority of this document was derived. We would also like to acknowledge the members of the IPng working group for their careful review and constructive criticisms. 8. IANA Considerations @@ -674,20 +676,25 @@ . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . + [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering + ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/ + RFC4890, May 2007, + . + [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, . [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, @@ -708,25 +715,91 @@ is discussed in [I-D.ietf-6man-rfc2460bis] old-style messages all Packet Too Big messages report the MTU of the constricting link MTU plateau tables not needed because there are no old-style messages Appendix B. Changes Since RFC 1981 - This document has the following changes from RFC1981. Numbers - identify the Internet-Draft version where the change was made: + This document is based on RFC1981 has the following changes from + RFC1981: + + o Clarified Section 1 "Introduction" that the purpose of PMTUD is to + reduce the need for IPv6 fragmentation. + + o Added text to Section 1 "Introduction" and Section 6 "Security + Considerations" about the effects on PMTUD when ICMPv6 messages + are blocked. + + o Added a short summary to the Section 1 "Introduction" of + Packetization Layer Path MTU Discovery ((PLPMTUD) and a reference + to RFC4821 that defines it. + + o Aligned text in Section 2 "Terminology" to match current + packetization layer terminology. + + o Added clarification in Section 4 "Protocol Requirements" that + nodes should validate the payload of ICMP PTB message per RFC4443. + + o Remove Note from Section 4 "Protocol Requirements" about a Packet + Too Big message reporting a next-hop MTU that is less than the + IPv6 minimum link MTU because this was removed from + [I-D.ietf-6man-rfc2460bis]. + + o Added clarification in Section 5.2 "Storing PMTU information" to + discard an ICMPv6 Packet Too Big message if it contains a MTU less + than the IPv6 minimum link MTU. + + o Removed text in Section 5.2 "Storing PMTU information" about the + RH0 routing header because it was deprecated by RFC5095. + + o Removed text about obsolete security classification from + Section 5.2 "Storing PMTU information". + + o Changed title of Section 5.4 to "Packetization Layer actions" and + changed to text in the first paragraph to to generalize this + section to cover all packetization layers, not just TCP. + + o Clarified text in Section 5.4 "Packetization Layer actions" to use + normal packetization layer retransmission methods. + + o Removed text in Section 5.4 "Packetization Layer actions" that + described 4.2 BSD because it is obsolete, and removed reference to + TP4. + + o Updated text in Section 5.5 "Issues for other transport protocols" + about NFS including adding a current reference to NFS and removing + obsolete text. + + o Editorial Changes. + +B.1. Change History Since RFC1981 + + NOTE TO RFC EDITOR: Please remove this subsection prior to RFC + Publication + + This section describes change history made in each Internet Draft + that went into producing this version. The numbers identify the + Internet-Draft version in which the change was made. Working Group Internet Drafts + 06) Revised Appendix B "Changes since RFC1981" to have a summary + of changes since RFC1981 and a separate subsection with a + change history of each Internet Draft. This subsection will + be removed when the RFC is published. + + 06) Editorial changes based on comments received after publishing + the -05 draft. + 05) Changes based on IETF last call reviews by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef, and Donald Eastlake. This includes includes: o Clarify that the purpose of PMTUD is to reduce the need for IPv6 Fragmentation. o Added text to Introduction about effects on PMTUD when ICMPv6 messages are blocked.