--- 1/draft-ietf-6man-rfc2460bis-05.txt 2016-09-13 15:16:01.049228773 -0700 +++ 2/draft-ietf-6man-rfc2460bis-06.txt 2016-09-13 15:16:01.133230890 -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: December 30, 2016 June 28, 2016 +Expires: March 17, 2017 September 13, 2016 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-05 + draft-ietf-6man-rfc2460bis-06 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 December 30, 2016. + This Internet-Draft will expire on March 17, 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 @@ -56,35 +56,35 @@ 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 . . . . . . . . . . . . . . . . . 8 - 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 9 + 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 @@ -115,21 +115,21 @@ o Improved Support for Extensions and Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. o Flow Labeling Capability A new capability is added to enable the labeling of sequences - of packets for which the sender requests to be treated in the + of packets that the sender requests to be treated in the network as a single flow. 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 @@ -340,24 +340,25 @@ natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8. A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options + Routing Authentication Encapsulating Security Payload - The first three are specified in this document; the last two are + The first four are specified in this document; the last two are specified in [RFC4302] and [RFC4303], respectively. The current list of IPv6 extension headers can be found at [IANA-EH]. 4.1. Extension Header Order When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: IPv6 header Hop-by-Hop Options header @@ -831,26 +830,20 @@ from the fragments following the Fragment headers in each of the fragment packets. The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself; its relative position in Fragmentable Part is computed from its Fragment Offset value. The Fragment header is not present in the final, reassembled packet. - 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. - It should be noted that fragments may be duplicated in the network. These exact duplicate fragments will be treated as overlapping fragments and handled as described in the previous paragraph. An implementation may choose to detect this case and not drop the other fragments of the same packet. If the fragment is a whole datagram (that is, both the Fragment Offset field and the M flag are zero), then it does not need any further reassembly and should be processed as a fully reassembled packet (i.e., updating Next Header, adjust Payload @@ -883,20 +876,25 @@ 65,535 octets, then that fragment must be discarded and an ICMP Parameter Problem, Code 0, message should be sent to the source of the fragment, pointing to the Fragment Offset field of the fragment packet. If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded and an ICMP Parameter Problem, Code 3, message should be sent to the source of the fragment, with the Pointer field set to zero. + 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. + 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 arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. @@ -972,36 +970,29 @@ contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded. 4.8. Defining New Extension Headers and Options No new extension headers that require hop-by-hop behavior should 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, due to - performance restrictions, nodes may 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. + New hop-by-hop options are not recommended because it is expected + that nodes along a packet's delivery path will only examine and + process the hop-by-hop option header if explicitly configured to do + so. - Instead of defining new Extension Headers, it is recommended that the + Defining new IPv6 extension headers is not recommended. 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 packet's destination node(s), because they - provide better handling and backward compatibility. Defining new - IPv6 extension headers is not recommended. There has to a very clear - justification why any new extension header is needed before it is - standardized. + need be examined only by a packet's destination node(s). If new Extension Headers are defined, they need to use the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Header Specific Data . @@ -1238,23 +1230,23 @@ 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. Deering, "IP Version 6 Addressing - Architecture", draft-ietf-6man-rfc4291bis-02 (work in - progress), April 2016. + Hinden, R. and D. Deering, "IP Version 6 Addressing + Architecture", draft-ietf-6man-rfc4291bis-03 (work in + progress), June 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, . @@ -1469,20 +1461,32 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Working Group Internet Drafts + 06) Added the Routing Header to the list required extension + headers that a full implementation includes. + + 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) 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 @@ -1520,21 +1524,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-03. + generation. 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