--- 1/draft-ietf-6man-rfc2460bis-10.txt 2017-04-28 16:13:30.200840932 -0700 +++ 2/draft-ietf-6man-rfc2460bis-11.txt 2017-04-28 16:13:30.288843052 -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: October 23, 2017 April 21, 2017 +Expires: October 30, 2017 April 28, 2017 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-10 + draft-ietf-6man-rfc2460bis-11 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 October 23, 2017. + This Internet-Draft will expire on October 30, 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 @@ -61,41 +61,41 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Header Format . . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 6 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 8 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 - 4.6. Destination Options Header . . . . . . . . . . . . . . . 20 + 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. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 25 + 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 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction IP version 6 (IPv6) is a new version of the Internet Protocol (IP), designed as the successor to IP version 4 (IPv4) [RFC0791]. The changes from IPv4 to IPv6 fall primarily into the following categories: o Expanded Addressing Capabilities @@ -221,21 +221,21 @@ Version 4-bit Internet Protocol version number = 6. Traffic Class 8-bit traffic class field. See section 7. Flow Label 20-bit flow label. See section 6. Payload Length 16-bit unsigned integer. Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. (Note - that any extension headers [section 4] present + that any extension headers [Section 4] present are considered part of the payload, i.e., included in the length count.) Next Header 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field [IANA-PN]. Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. When @@ -286,50 +286,49 @@ | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 header | Routing header | Fragment header | fragment of TCP | | | | header + data | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+----------------- - With one exception, extension headers are not examined, processed, - inserted, or deleted by any node along a packet's delivery path, + Extension headers (except for the Hop-by-Hop Options header) are not + processed, inserted, or deleted by any node along a packet's delivery + path, until the packet reaches the node (or each of the set of nodes, + in the case of multicast) identified in the Destination Address field + of the IPv6 header. + + The Hop-by-Hop Options header is not inserted or deleted, but may be + examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of - the IPv6 header. Note: If an intermediate forwarding node examines - an extension header for any reason, it must do so in accordance with - the provisions of [RFC7045]. At the Destination node, normal - demultiplexing on the Next Header field of the IPv6 header invokes - the module to process the first extension header, or the upper-layer - header if no extension header is present. The contents and semantics - of each extension header determine whether or not to proceed to the - next header. Therefore, extension headers must be processed strictly - in the order they appear in the packet; a receiver must not, for - example, scan through a packet looking for a particular kind of - extension header and process that header prior to processing all - preceding ones. - - The exception referred to in the preceding paragraph is the Hop-by- - Hop Options header, which carries information that may be examined - and processed by every node along a packet's delivery path, including - the source and destination nodes. The Hop-by-Hop Options header, - when present, must immediately follow the IPv6 header. Its presence - is indicated by the value zero in the Next Header field of the IPv6 - header. + the IPv6 header. The Hop-by-Hop Options header, when present, must + immediately follow the IPv6 header. Its presence is indicated by the + value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. + At the Destination node, normal demultiplexing on the Next Header + field of the IPv6 header invokes the module to process the first + extension header, or the upper-layer header if no extension header is + present. The contents and semantics of each extension header + determine whether or not to proceed to the next header. Therefore, + extension headers must be processed strictly in the order they appear + in the packet; a receiver must not, for example, scan through a + packet looking for a particular kind of extension header and process + that header prior to processing all preceding ones. + If, as a result of processing a header, the destination node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. @@ -899,20 +898,28 @@ differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. The Next Header values in the Fragment headers of different fragments of the same original packet may differ. Only the value from the Offset zero fragment packet is used for reassembly. + Other fields in the IPv6 header may also vary across the fragments + being reassembled. Specifications that use these fields may + provide additional instructions if the basic mechanism of using + the values from the Offset zero fragment is not sufficient. For + example, Section 5.3 of [RFC3168] describes how to combine the + Explicit Congestion Notification (ECN) bits from different + fragments to derive the ECN bits of the reassembled packet. + 4.6. Destination Options Header The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + @@ -973,35 +980,44 @@ contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded. 4.8. Defining New Extension Headers and Options 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. + Defining new IPv6 extension headers is not recommended, unless there + are no existing IPv6 extension header 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. + + 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 defining new hop-by-hop options need to be aware of this likely behaviour. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. - Defining new IPv6 extension headers is not recommended. There has to - be a very clear justification why any new extension header is needed - before it is standardized. Instead of defining new Extension - Headers, it is recommended that the Destination Options header is - used to carry optional information that must be examined only by a - packet's destination node(s), because they provide better handling - and backward compatibility. + Instead of defining new Extension Headers, it is recommended that the + Destination Options header is used to carry optional information that + must be examined only by a packet's destination node(s), because they + provide better handling and backward compatibility. If new Extension Headers are defined, they need to use the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Header Specific Data . @@ -1288,22 +1304,22 @@ This version of the IPv6 specification resolves a number of security issues that were found with the previous version [RFC2460] of the IPv6 specification. These include: o Revised the text to handle the case of fragments that are whole datagrams (i.e., both the Fragment Offset field and the M flag are zero). If received they should be processed as a reassembled packet. Any other fragments that match should be processed independently. The Fragment creation process was modified to not create whole datagram fragments (Fragment - Offset field and the M flag are zero). See [RFC6946] for more - information. + Offset field and the M flag are zero). See [RFC6946] and + [RFC8021] for more information. o Changed the text to require that IPv6 nodes must not create overlapping fragments. Also, when reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments) must be silently discarded. Includes clarification that no ICMP error message should be sent if overlapping fragments are received. See [RFC5722] for more information. @@ -1471,20 +1487,25 @@ [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . + [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 + Atomic Fragments Considered Harmful", RFC 8021, DOI + 10.17487/RFC8021, January 2017, + . + Appendix A. Formatting Guidelines for Options This appendix gives some advice on how to lay out the fields when designing new options to be used in the Hop-by-Hop Options header or the Destination Options header, as described in section 4.2. These guidelines are based on the following assumptions: o One desirable feature is that any multi-octet fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n octets should be placed at @@ -1605,27 +1625,48 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix B. Changes Since RFC2460 This memo has the following changes from RFC2460. - o Clarification that extension headers are not examined, processed, - inserted, or deleted by any node along a packet's delivery path. + o Removed IP Next Generation from the Abstract. + + o Added text in Section 1 that the Data Transmission Order is the + same as IPv4 as defined in RFC791. + + o Clarified the text in Section 3 about decrementing the hop limit. + + o Clarification that extension headers (except for the hop-by-hop + options header) are not processed, inserted, or deleted by any + node along a packet's delivery path. + + o Changed requirement for the Hop-by-Hop Options header to a may, + and added a note to indicate what is expected regarding the Hop- + by-Hop Options header. o Added paragraph to Section 4 to clarify how Extension Headers are numbered and which are upper-layer headers. - o Revision Section 4.5 on IPv6 Fragmentation based on updates from + o Add reference to the end of Section 4 to IPv6 Extension Header + IANA registry. + + o Incorporate the updates from RFC5095 and RFC5871 to remove the + description of the RH0 Routing Header, that the allocations + guidelines for routing headers are specified in RFC5871, and + removed RH0 Routing Header from the list of required extension + headers. + + o Revised Section 4.5 on IPv6 Fragmentation based on updates from RFC5722, RFC6946 RFC7112, and RFC8021. This include: - Revised the text to handle the case of fragments that are whole datagrams (i.e., both the Fragment Offset field and the M flag are zero). If received they should be processed as a reassembled packet. Any other fragments that match should be processed independently. The revised Fragment creation process was modified to not create whole datagram fragments (Fragment Offset field and the M flag are zero). @@ -1652,91 +1693,101 @@ "Unfragmentable Headers" to "Per-Fragment Headers". - Removed the paragraph in Section 5 that required including a fragment header to outgoing packets if a ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. - Changed the text to clarify MTU restriction and 8-byte restrictions, and noting the restriction on headers in first fragment. - o Changed requirement for HBH header to a may, and added a note to - indicate what is expected regarding HBH headers. - - o Clarified the text in Section 3 about decrementing the hop limit. + 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 Removed IP Next Generation from the Abstract. + o Incorporated the update from RFC6564 to add a new Section 4.8 that + describes recommendations for defining new Extension headers and + options - o Add reference to the end of Section 4 to IPv6 Extension Header - IANA registry. + 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 Added text in Section 1 that the Data Transmission Order is the - same as IPv4 as defined in RFC791. + 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 references to RFC2460 to this document + o Revised and expanded the Security Consideration section. + 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 Incorporated the update from RFC6564 to add a new Section 4.8 that - describes recommendations for defining new Extension headers and - options - - 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 Incorporate the updates from RFC5095 and RFC5871 to remove the - description of the RH0 Routing Header, that the allocations - guidelines for routing headers are specified in RFC5871, and - removed RH0 Routing Header from the list of required extension - headers. - o Changes to resolve the open Errata on RFC2460. These are: Errata ID: 2541: This errata notes that RFC2460 didn't update RFC2205 when the length of the Flow Label was changed from 24 to 20 bits from RFC1883. This issue was resolved in RFC6437 where the Flow Label is defined. This draft now references RFC6437. No change is required. Errata ID: 4279: This errata noted that the specification doesn't handle the case of a forwarding node receiving a packet with a zero Hop Limit. This is fixed in Section 3 of this draft. Errata ID: 2843: This errata is marked rejected. No change was made. - 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 Revised and expanded the Security Consideration section. - B.1. Change History Since RFC2460 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 + 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, + removed "examine" from first paragraph about extension + headers, and removed reference to RFC7045 because "examine" + was removed (RFC7045 is referenced in Security + Considerations). Also removed "including the source and + destination nodes" from paragraph about the hop-by-hop + options header. + + 11) Revised Section 4.8 to make it closer to the update done by + RFC6554 that updated it and reordered the paragraphs. + + 11) Reordered items in Appendix B "Changes Since RFC2460" match + order of the document. + + 11) Editorial changes. + 10) Revised and expanded Security Consideration Section based on IESG Discuss comments. 10) Editorial changes. 09) Based on results of IETF last call, changed text in Section 4 to add clarification that extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path. @@ -1783,22 +1834,23 @@ 06) Moved the text in Section 4.5 regarding the handling of received overlapping fragments to the list of error conditions 06) Rewrote the text in Section 4.8 "Defining New Extension Headers and Options" to be clearer and remove redundant text. 06) Editorial changes. - 05) Changed requirement for HBH header from a should to a may, - and added a note to indicate what is expected. + 05) Changed requirement for the Hop-by-Hop Options header from a + should to a may, and added a note to indicate what is + expected. 05) Corrected reference to point to draft-ietf-6man-rfc4291bis instead of draft-hinden-6man-rfc4291bis. 05) Change to text regarding not inserting extension headers to cite using encapsulation as an example. 04) Changed text discussing Fragment ID selection to refer to RFC7739 for example algorithms.