--- 1/draft-ietf-6man-rfc2460bis-08.txt 2017-03-30 07:13:23.487401938 -0700 +++ 2/draft-ietf-6man-rfc2460bis-09.txt 2017-03-30 07:13:23.583404206 -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: May 19, 2017 November 15, 2016 +Expires: October 1, 2017 March 30, 2017 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-08 + draft-ietf-6man-rfc2460bis-09 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,25 +21,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 May 19, 2017. + This Internet-Draft will expire on October 1, 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 @@ -56,49 +56,50 @@ not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Header Format . . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 6 - 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 9 - 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 8 + 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 - 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 + 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 - 4.6. Destination Options Header . . . . . . . . . . . . . . . 21 + 4.6. Destination Options Header . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . 25 - 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 + 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24 + 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 - 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27 + 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 8.4. Responding to Packets Carrying Routing Headers . . . . . 27 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29 - Appendix A. Formatting Guidelines for Options . . . . . . . . . 31 - Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 + Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 33 + B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction - IP version 6 (IPv6) is a new version of the Internet Protocol, + 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 IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by @@ -127,24 +128,24 @@ o Authentication and Privacy Capabilities Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6. This document specifies the basic IPv6 header and the initially- defined IPv6 extension headers and options. It also discusses packet size issues, the semantics of flow labels and traffic classes, and the effects of IPv6 on upper-layer protocols. The format and - semantics of IPv6 addresses are specified separately in + semantics of IPv6 addresses are specified separately in [RFC4291]. - [I-D.ietf-6man-rfc4291bis]. The IPv6 version of ICMP, which all IPv6 - implementations are required to include, is specified in [RFC4443] + The IPv6 version of ICMP, which all IPv6 implementations are required + to include, is specified in [RFC4443] The data transmission order for IPv6 is the same as for IPv4 as defined in Appendix B of [RFC0791]. Note: As this document obsoletes [RFC2460], any document referenced in this document that includes pointers to RFC2460, should be interpreted as referencing this document. 2. Terminology @@ -177,29 +178,29 @@ interfaces. packet an IPv6 header plus payload. link MTU the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. path MTU the minimum link MTU of all the links in a path between a source node and a destination node. - Note: it is possible, though unusual, for a device with multiple - interfaces to be configured to forward non-self-destined packets - arriving from some set (fewer than all) of its interfaces, and to - discard non-self-destined packets arriving from its other interfaces. - Such a device must obey the protocol requirements for routers when - receiving packets from, and interacting with neighbors over, the - former (forwarding) interfaces. It must obey the protocol - requirements for hosts when receiving packets from, and interacting - with neighbors over, the latter (non-forwarding) interfaces. + Note: it is possible for a device with multiple interfaces to be + configured to forward non-self-destined packets arriving from some + set (fewer than all) of its interfaces, and to discard non-self- + destined packets arriving from its other interfaces. Such a device + must obey the protocol requirements for routers when receiving + packets from, and interacting with neighbors over, the former + (forwarding) interfaces. It must obey the protocol requirements for + hosts when receiving packets from, and interacting with neighbors + over, the latter (non-forwarding) interfaces. 3. IPv6 Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + @@ -239,27 +240,26 @@ Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. When forwarding, the packet is discarded if Hop Limit was zero when received or is decremented to zero. A node that is the destination of a packet should not discard a packet with hop limit equal to zero, it should process the packet normally. Source Address 128-bit address of the originator of the - packet. See [I-D.ietf-6man-rfc4291bis]. + packet. See [RFC4291]. Destination Address 128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). - See [I-D.ietf-6man-rfc4291bis] and section - 4.4. + See [RFC4291] and section 4.4. 4. IPv6 Extension Headers In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper- layer header in a packet. There is a small number of such extension headers, each one identified by a distinct Next Header value. Extension Headers are numbered from IANA IP Protocol Numbers [IANA-PN], the same values used for IPv4 and IPv6. When processing a @@ -286,47 +286,36 @@ | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 header | Routing header | Fragment header | fragment of TCP | | | | header + data | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+----------------- - The insertion of Extension Headers by any node other than the source - of the packet causes serious problems. Two examples include breaking - the integrity checks provided by the Authentication Header Integrity - [RFC4302], and breaking Path MTU Discovery which can result in ICMP - error messages being sent to the source of the packet that did not - insert the header, rather than the node that inserted the header. - - One approach to avoid these problems is to encapsulate the packet - using another IPv6 header and including the additional extension - header after the first IPv6 header, for example, as defined in - [RFC2473] - - With one exception, extension headers are not 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. + With one exception, extension headers are not examined, 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. 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. NOTE: While [RFC2460] required that all nodes must examine and @@ -658,21 +648,21 @@ For every packet that is to be fragmented, the source node generates an Identification value. The Identification must be different than that of any other fragmented packet sent recently* with the same Source Address and Destination Address. If a Routing header is present, the Destination Address of concern is that of the final destination. * "recently" means within the maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same - packet. However, it is not required that a source node know + packet. However, it is not required that a source node knows the maximum packet lifetime. Rather, it is assumed that the requirement can be met by implementing an algorithm that results in a low identification reuse frequency. Examples of algorithms that can meet this requirement are described in [RFC7739]. The initial, large, unfragmented packet is referred to as the "original packet", and it is considered to consist of three parts, as illustrated: @@ -888,21 +880,21 @@ the source of the fragment, with the Pointer field set to zero. o If any of the fragments being reassembled overlaps with any other fragments being reassembled for the same packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded and no ICMP error messages should be sent. It should be noted that fragments may be duplicated in the network. Instead of treating these exact duplicate fragments - as an overlapping fragments, an implementation may choose to + as overlapping fragments, an implementation may choose to detect this case and drop exact duplicate fragments while keeping the other fragments belonging to the same packet. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets @@ -977,37 +969,37 @@ The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field 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 + 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 a very clear justification why any new hop- - by-hop option is needed before it is standardized. + 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 - a very clear justification why any new extension header is needed + 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 need be examined only by a + 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | @@ -1019,21 +1011,21 @@ Next Header 8-bit selector. Identifies the type of header immediately following the extension header. Uses the same values as the IPv4 Protocol field [IANA-PN]. 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 + 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. Links that have a configurable MTU (for example, PPP links [RFC1661]) @@ -1138,33 +1130,33 @@ plus TCP data). Some upper-layer protocols carry their own length information (e.g., the Length field in the UDP header); for such protocols, that is the length used in the pseudo- header. Other protocols (such as TCP) do not carry their own length information, in which case the length used in the pseudo-header is the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the upper-layer header. o Unlike IPv4, the default behavior when UDP packets are - originated by an IPv6 node, is that the UDP checksum is not + originated by an IPv6 node is that the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. o As an exception to the default behaviour, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode must follow the - requirements specified in "Applicability Statement for the use + requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. The IPv6 version of ICMP [RFC4443] includes the above pseudo-header in its checksum computation; this is a change from the IPv4 version of ICMP, which does not include a pseudo-header in its checksum. The reason for the change is to protect ICMP from misdelivery or corruption of those fields of the IPv6 header on which it depends, which, unlike IPv4, are not covered by an internet-layer checksum. The Next Header field in the pseudo-header for ICMP contains the value 58, which identifies the IPv6 version of ICMP. @@ -1262,40 +1253,39 @@ Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Savola, Magnus Westerlund, and James Woodyatt. 12. References 12.1. Normative References - [I-D.ietf-6man-rfc4291bis] - Hinden, R. and S. <>, "IP Version 6 Addressing - Architecture", draft-ietf-6man-rfc4291bis-06 (work in - progress), November 2016. - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . + [RFC4443] 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, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ RFC6437, November 2011, . @@ -1339,24 +1329,20 @@ . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . - [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in - IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, - December 1998, . - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, @@ -1503,35 +1489,168 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Appendix B. CHANGES SINCE RFC2460 +Appendix B. Changes Since RFC2460 - This memo has the following changes from RFC2460. Numbers identify - the Internet-Draft version in which the change was made. + 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 Expanded Security Considerations section to include both IPsec and + encryption at higher levels in the protocol stack as ways to + mitigate IP level security issues. + + 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 + RFC5722, RFC6946 RFC7112, and RFC8021. This includes: + + - 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). + + - 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, including those not yet + received) MUST be silently discarded. Includes clarification + that no ICMP error message should be sent if overlapping + fragments are received. + + - Revised the text to require that all headers through the first + Upper-Layer Header are in the first fragment. This changed the + text describing how packets are fragmented and reassembled, and + added a new error case. + + - Added text to Fragment Header process on handling exact + duplicate fragments. + + - Updated the Fragmentation header text to correct the inclusion + of AH and note no next header case. + + - Change terminology in Fragment header section from + "Unfragmentable Headers" to "Per-Fragment Headers". + + - Removed 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 Removed IP Next Generation from the Abstract. + + o Add reference to the end of Section 4 to IPv6 Extension Header + IANA registry. + + o Added text in Section 1 that the Data Transmission Order is the + same as IPv4 as defined in RFC791. + + o Add instruction to the IANA Considerations section to change + references to RFC2460 to this document + + 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 Incorporate 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]. + +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 + 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. + + 09) Changed reference from draft-ietf-6man-rfc4291bis to RFC4291 + because the bis draft won't be advanced as the same time. + + 09) Revised "Changes since RFC2460" Section to have a summary of + changes since RFC2460 and a separate subsection with a change + history of each Internet Draft. This subsection will be + removed when the RFC is published. + + 09) Editorial changes. + 08) Revised header insertion text in Section 4 based on the results of w.g. survey that concluded to describe the problems with header insertion. 08) Editorial changes. 07) Expanded Security Considerations section to include both - IPSEC and encryption at higher levels in the protocol stack + IPsec and encryption at higher levels in the protocol stack as ways to mitigate IP level security issues. 07) Added paragraph to Section 4 to clarify how Extension Headers are numbered and which are upper-layer headers. 07) Moved the text regarding network duplicated fragments to the received fragment error section. 07) Added clarification that no ICMP error message should be sent if overlapping fragments are received. @@ -1600,22 +1719,21 @@ 01) Updated the Fragmentation header text to correct the inclusion of AH and note no next header case. 01) Change terminology in Fragment header section from "Unfragmentable Headers" to "Per-Fragment Headers". 01) Removed 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. This is - based on the update in draft-ietf-6man-deprecate-atomfrag- - generation. + based on the update in RFC8021. 01) Changed to Fragmentation Header section to clarify MTU restriction and 8-byte restrictions, and noting the restriction on headers in first fragment. 01) Editorial changes. 00) Add instruction to the IANA to change references to RFC2460 to this document