--- 1/draft-ietf-6man-rfc1981bis-03.txt 2017-01-31 11:13:08.820475114 -0800 +++ 2/draft-ietf-6man-rfc1981bis-04.txt 2017-01-31 11:13:08.856475958 -0800 @@ -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: April 7, 2017 J. Mogul +Expires: August 4, 2017 J. Mogul Digital Equipment Corporation R. Hinden, Ed. Check Point Software - October 4, 2016 + January 31, 2017 Path MTU Discovery for IP version 6 - draft-ietf-6man-rfc1981bis-03 + draft-ietf-6man-rfc1981bis-04 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,25 +26,25 @@ 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 April 7, 2017. + This Internet-Draft will expire on August 4, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -67,24 +67,24 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 7 5.3. Purging stale PMTU information . . . . . . . . . . . . . 9 5.4. TCP layer actions . . . . . . . . . . . . . . . . . . . . 10 5.5. Issues for other transport protocols . . . . . . . . . . 12 - 5.6. Management interface . . . . . . . . . . . . . . . . . . 13 + 5.6. Management interface . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction When one IPv6 node has a large amount of data to send to another @@ -106,26 +106,21 @@ 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. An extension to Path MTU Discovery defined in this document can be found in [RFC4821]. It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of - ICMP messages to a host is not assured. In this algorithm, the - proper MTU is determined by starting with small packets and probing - with successively larger packets. The bulk of the algorithm is - implemented above IP, in the transport layer (e.g., TCP) or other - "Packetization Protocol" that is responsible for determining packet - boundaries. + ICMP messages to a host is not assured. 2. Terminology node a device that implements IPv6. router a node that forwards IPv6 packets not explicitly addressed to itself. host any node that is not a router. @@ -173,25 +168,25 @@ flow id a combination of a source address and a non-zero flow label. 3. Protocol Overview This memo describes a technique to dynamically discover the PMTU of a path. The basic idea is that a source node initially assumes that the PMTU of a path is the (known) MTU of the first hop in the path. If any of the packets sent on that path are too large to be forwarded - by some node (regardless of whether it decrements the Hop Limit) - along the path, that node will discard them and return ICMPv6 Packet - Too Big messages [ICMPv6]. Upon receipt of such a message, the - source node reduces its assumed PMTU for the path based on the MTU of - the constricting hop as reported in the Packet Too Big message. + by some node along the path, that node will discard them and return + ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such a + message, the source node reduces its assumed PMTU for the path based + on the MTU of the constricting hop as reported in the Packet Too Big + message. The Path MTU Discovery process ends when the node's estimate of the PMTU is less than or equal to the actual PMTU. Note that several iterations of the packet-sent/Packet-Too-Big-message-received cycle may occur before the Path MTU Discovery process ends, as there may be links with smaller MTUs further along the path. Alternatively, the node may elect to end the discovery process by ceasing to send packets larger than the IPv6 minimum link MTU. @@ -214,21 +209,21 @@ multicast destination. Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can to appear to be directly connected but is in fact more than one hop away. 4. Protocol Requirements - As discussed in section 1, IPv6 nodes are not required to implement + As discussed in Section 1, IPv6 nodes are not required to implement Path MTU Discovery. The requirements in this section apply only to those implementations that include Path MTU Discovery. When a node receives a Packet Too Big message, it MUST reduce its estimate of the PMTU for the relevant path, based on the value of the MTU field in the message. The precise behavior of a node in this circumstance is not specified, since different applications may have different requirements, and since different implementation architectures may favor different strategies. @@ -290,21 +285,21 @@ Implementing Path MTU Discovery in the packetization layers simplifies some of the inter-layer issues, but has several drawbacks: the implementation may have to be redone for each packetization protocol, it becomes hard to share PMTU information between different packetization layers, and the connection-oriented state maintained by some packetization layers may not easily extend to save PMTU information for long periods. It is therefore suggested that the IP layer store PMTU information and that the ICMP layer process received Packet Too Big messages. - The packetization layers may respond to changes in the PMTU, by + The packetization layers may respond to changes in the PMTU by changing the size of the messages they send. To support this layering, packetization layers require a way to learn of changes in the value of MMS_S, the "maximum send transport-message size". The MMS_S is derived from the Path MTU by subtracting the size of the IPv6 header plus space reserved by the IP layer for additional headers (if any). It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. This may result in a packet size that exceeds the Path MTU. @@ -320,22 +315,22 @@ Ideally, a PMTU value should be associated with a specific path traversed by packets exchanged between the source and destination nodes. However, in most cases a node will not have enough information to completely and accurately identify such a path. Rather, a node must associate a PMTU value with some local representation of a path. It is left to the implementation to select the local representation of a path. In the case of a multicast destination address, copies of a packet may traverse many different paths to reach many different nodes. The - local representation of the "path" to a multicast destination must in - fact represent a potentially large set of paths. + local representation of the "path" to a multicast destination must + represent a potentially large set of paths. Minimally, an implementation could maintain a single PMTU value to be used for all packets originated from the node. This PMTU value would be the minimum PMTU learned across the set of all paths in use by the node. This approach is likely to result in the use of smaller packets than is necessary for many paths. An implementation could use the destination address as the local representation of a path. The PMTU value associated with a destination would be the minimum PMTU learned across the set of all @@ -352,47 +347,44 @@ sent to a particular destination but belonging to different flows may use different paths, with the choice of path depending on the flow id. This approach will result in the use of optimally sized packets on a per-flow basis, providing finer granularity than PMTU values maintained on a per-destination basis. For source routed packets (i.e. packets containing an IPv6 Routing header [I-D.ietf-6man-rfc2460bis]), the source route may further qualify the local representation of a path. - Note: Some paths may be further distinguished by different - security classifications. The details of such classifications are - beyond the scope of this memo. - Initially, the PMTU value for a path is assumed to be the (known) MTU of the first-hop link. When a Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message. For example, if the destination address is used as the local representation of a path, the destination address from the original packet would be used to determine which path the message applies to. 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, 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 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. 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. @@ -471,24 +463,25 @@ The TCP layer must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU. A simple implementation could ask the IP layer for this value each time it created a new segment, but this could be inefficient. Moreover, TCP implementations that follow the "slow- start" congestion-avoidance algorithm [CONG] typically calculate and cache several other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be updated. - A TCP implementation must also store the MSS value received from its - peer, and must not send any segment larger than this MSS, regardless - of the PMTU. In 4.xBSD-derived implementations, this may require - adding an additional field to the TCP state record. + A TCP implementation must also store the Maximum Segment Size (MSS) + value received from its peer, and must not send any segment larger + than this MSS, regardless of the PMTU. In 4.xBSD-derived + implementations, this may require adding an additional field to the + TCP state record. The value sent in the TCP MSS option is independent of the PMTU. This MSS option value is used by the other end of the connection, which may be using an unrelated PMTU value. See [I-D.ietf-6man-rfc2460bis] sections "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for information on selecting a value for the TCP MSS option. When a Packet Too Big message is received, it implies that a packet was dropped by the node that sent the ICMP message. It is sufficient @@ -624,22 +617,22 @@ 8. IANA Considerations This document does not have any IANA actions 9. References 9.1. Normative References [I-D.ietf-6man-rfc2460bis] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", draft-ietf-6man-rfc2460bis-07 (work - in progress), October 2016. + (IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work + in progress), November 2016. [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, . 9.2. Informative References [CONG] Jacobson, V., "Congestion Avoidance and Control", Proc. @@ -691,20 +684,28 @@ 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 that the change was made.: Working Group Internet Drafts + 04) Changes based on AD Evaluation including removing details + about RFC4821 algorithm in Section 1, remove text about + decrementing hop limit from Section 3, and removed text about + obsolete security classifications from Section 5.2. + + 04) Editorial changes and clarification in Section 5.2 based on + IP Directorate review by Donald Eastlake + 03) Remove text in Section 5.3 regarding RH0 since it was deprecated by RFC5095 02) Clarified in Section 3 that ICMP Packet Too Big should be sent even if the node doesn't decrement the hop limit 01) Revised the text about PLPMTUD to use the word "path". 01) Editorial changes.