--- 1/draft-ietf-6man-rfc1981bis-02.txt 2016-10-04 17:16:16.542190995 -0700 +++ 2/draft-ietf-6man-rfc1981bis-03.txt 2016-10-04 17:16:16.582192018 -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 29, 2016 J. Mogul +Expires: April 7, 2017 J. Mogul Digital Equipment Corporation R. Hinden, Ed. Check Point Software - April 27, 2016 + October 4, 2016 Path MTU Discovery for IP version 6 - draft-ietf-6man-rfc1981bis-02 + draft-ietf-6man-rfc1981bis-03 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 29, 2016. + This Internet-Draft will expire on April 7, 2017. Copyright Notice Copyright (c) 2016 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 @@ -64,21 +64,21 @@ Table of Contents 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 . . . . . . . . . . . . . 10 + 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 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 @@ -350,25 +350,21 @@ If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation could use the flow id as the local representation of a path. Packets 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. In particular, a packet - containing a type 0 Routing header in which all bits in the Strict/ - Loose Bit Map are equal to 1 contains a complete path specification. - An implementation could use source route information in the local - representation of a path. + 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 @@ -628,22 +624,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-04 (work - in progress), March 2016. + (IPv6) Specification", draft-ietf-6man-rfc2460bis-07 (work + in progress), October 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. @@ -695,21 +691,24 @@ 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 - 02) Clarified in Section 3. that ICMP Packet Too Big should be + 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. 00) Added text to discard an ICMP Packet Too Big message containing an MTU less than the IPv6 minimum link MTU. 00) Revision of text regarding RFC4821.