--- 1/draft-ietf-6man-rfc2460bis-12.txt 2017-05-19 13:13:47.771368588 -0700 +++ 2/draft-ietf-6man-rfc2460bis-13.txt 2017-05-19 13:13:47.871370996 -0700 @@ -1,19 +1,19 @@ Network Working Group S. Deering Internet-Draft Retired Obsoletes: 2460 (if approved) R. Hinden Intended status: Standards Track Check Point Software -Expires: November 17, 2017 May 16, 2017 +Expires: November 20, 2017 May 19, 2017 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-12 + draft-ietf-6man-rfc2460bis-13 Abstract This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,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 November 17, 2017. + This Internet-Draft will expire on November 20, 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 @@ -68,23 +68,23 @@ 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.6. Destination Options Header . . . . . . . . . . . . . . . 21 4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22 4.8. Defining New Extension Headers and Options . . . . . . . 22 5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23 6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24 - 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 + 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 - 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 + 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Formatting Guidelines for Options . . . . . . . . . 33 Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36 B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39 @@ -980,21 +980,22 @@ contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded. 4.8. Defining New Extension Headers and Options Defining new IPv6 extension headers is not recommended, unless there are no existing IPv6 extension headers that can be used by specifying a new option for that IPv6 extension header. A proposal to specify a new IPv6 extension header must include a detailed technical explanation of why an existing IPv6 extension header can not be used - for the desired new function. + for the desired new function. See [RFC6564] for additional + background information. Note: New extension headers that require hop-by-hop behavior must not be defined because, as specified in Section 4 of this document, the only Extension Header that has hop-by-hop behavior is the Hop-by-Hop Options header. New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. Designers considering @@ -1028,23 +1029,24 @@ Hdr Ext Len 8-bit unsigned integer. Length of the Destination Options header in 8-octet units, not including the first 8 octets. Header Specific Data Variable-length field. Fields specific to the extension header. 5. Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 - octets or greater. On any link that cannot convey a 1280-octet - packet in one piece, link-specific fragmentation and reassembly must - be provided at a layer below IPv6. + octets or greater. This is known as the IPv6 minimum link MTU. On + any link that cannot convey a 1280-octet packet in one piece, link- + specific fragmentation and reassembly must be provided at a layer + below IPv6. Links that have a configurable MTU (for example, PPP links [RFC1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation. From each link to which a node is directly attached, the node must be able to accept packets as large as that link's MTU. @@ -1451,20 +1451,25 @@ . [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, . [RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, May 2010, . + [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and + M. Bhatia, "A Uniform Format for IPv6 Extension Headers", + RFC 6564, DOI 10.17487/RFC6564, April 2012, + . + [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, . [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing @@ -1698,36 +1703,38 @@ fragment. o In Section 4.5 added clarification noting that some fields in the IPv6 header may also vary across the fragments being reassembled and that other specifications may provide additional instructions for how they should be reassembled. For example, Section 5.3 of [RFC3168]. o Incorporated the update from RFC6564 to add a new Section 4.8 that describes recommendations for defining new Extension headers and - options + options. + + o Added text to Section 5 to define "IPv6 minimum link MTU". o Simplify the text in Section 6 about Flow Labels and remove Appendix A, and instead point to the current specifications of the IPv6 Flow Label field as defined in [RFC6437] and the Traffic Class as defined in [RFC2474] and [RFC3168]. o Incorporate the update in made by RFC6935 "UDP Checksums for Tunneled Packets" in Section 8. Added an exception to the default behaviour for the handling of handling UDP packets with zero checksums for tunnels. - o Add instruction to the IANA Considerations section to change + o Add instruction to Section 9 "IANA Considerations" to change references to RFC2460 to this document - o Revised and expanded the Security Consideration section. + o Revised and expanded Section 10 "Security Considerations". o Add a paragraph to the acknowledgement section acknowledging the authors of the updating documents o Update references to current versions and assign references to normative and informative. o Changes to resolve the open Errata on RFC2460. These are: Errata ID: 2541: This errata notes that RFC2460 didn't update @@ -1748,20 +1755,26 @@ 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 + 13) Added link to reference to RFC6564 in Section 4.8. + + 13) Added text to Section 5 to define "IPv6 minimum link MTU". + + 13) Editorial changes. + 12) Editorial changes (remove old duplicate paragraph). 11) In Section 4.5 added clarification noting that some fields in the IPv6 header may also vary across the fragments being reassembled and that other specifications may provide additional instructions for how they should be reassembled. For example, Section 5.3 of [RFC3168]. 11) In Section 4 restructured text including separated behaviors of extension headers and the hop-by-hop option header,