--- 1/draft-ietf-6man-rfc2460bis-02.txt 2016-01-22 09:15:24.780522889 -0800 +++ 2/draft-ietf-6man-rfc2460bis-03.txt 2016-01-22 09:15:24.856524786 -0800 @@ -1,46 +1,45 @@ Network Working Group S. Deering Internet-Draft Retired Obsoletes: 2460 (if approved) R. Hinden Intended status: Standards Track Check Point Software -Expires: June 18, 2016 December 16, 2015 +Expires: July 25, 2016 January 22, 2016 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-02 + draft-ietf-6man-rfc2460bis-03 Abstract - This document specifies version 6 of the Internet Protocol (IPv6), - also sometimes referred to as IP Next Generation or IPng. It - obsoletes RFC2460 + 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. 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 June 18, 2016. + This Internet-Draft will expire on July 25, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 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 @@ -232,24 +231,27 @@ 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. The - packet is discarded if Hop Limit is - decremented to zero, or is received with a - zero Hop Limit. + 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.hinden-6man-rfc4291bis]. 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.hinden-6man-rfc4291bis] and section 4.4. @@ -339,21 +341,22 @@ A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Authentication Encapsulating Security Payload The first three are specified in this document; the last two are - specified in [RFC4302] and [RFC4303], respectively. + 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 Destination Options header (note 1) Routing header @@ -389,28 +392,29 @@ IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. 4.2. Options - Two of the currently-defined extension headers -- the Hop-by-Hop - Options header and the Destination Options header -- carry a variable - number of type-length-value (TLV) encoded "options", of the following - format: + Two of the currently-defined extension headers defined in this + document -- the Hop-by-Hop Options header and the Destination Options + header -- carry a variable number of type-length-value (TLV) encoded + "options", of the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - + Option Type 8-bit identifier of the type of option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Option Data Variable-length field. Option-Type-specific data. The sequence of options within a header must be processed strictly in the order they appear in the header; a receiver must not, for @@ -661,31 +666,30 @@ The initial, large, unfragmented packet is referred to as the "original packet", and it is considered to consist of three parts, as illustrated: original packet: +------------------+-------------------------+---//----------------+ | Per-Fragment | Extension & Upper-Layer | Fragmentable | | Headers | Headers | Part | +------------------+-------------------------+---//----------------+ - The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. The Extension Headers are all other extension headers that are not included in the Per-Fragment headers part of the packet. For this purpose, the Encapsulating Security Payload (ESP) is not - considered an extension headers. The Upper-Layer Header is the + considered an extension header. The Upper-Layer Header is the first upper-layer header that is not an IPv6 extension header. Examples of upper-layer headers include TCP, UDP, IPv4, IPv6, ICMPv6, and as noted ESP. The Fragmentable Part consists of the rest of the packet after the upper-layer header or after any header (i.e., initial IPv6 header or extension header) that contains a Next Header value of No Next Header. The Fragmentable Part of the original packet is divided into @@ -1269,20 +1273,24 @@ "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ RFC6437, November 2011, . 12.2. Informative References [IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", . + [IANA-EH] "IPv6 Extension Header Types", + . + [IANA-PN] "Assigned Internet Protocol Numbers", . [IANA-RH] "IANA Routing Types Parameter Registry", . [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, @@ -1456,23 +1463,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 + 03) Clarified the text about decrementing the hop limit. + + 03) Removed IP Next Generation from the Abstract. + + 03) Add reference to the end of Section 4 to IPv6 Extension + Header IANA registry. + + 03) Editorial changes. + 02) Added text to Section 4.8 "Defining New Extension Headers and Options" clarifying why no new hop by hop extension headers - should be define. + should be defined. 02) Added text to Fragment Header process on handling exact duplicate fragments. 02) Editorial changes. 01) Added text that Extension headers must never be inserted by any node other than the source of the packet. 01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop