draft-ietf-6man-rfc2460bis-02.txt   draft-ietf-6man-rfc2460bis-03.txt 
Network Working Group S. Deering Network Working Group S. Deering
Internet-Draft Retired Internet-Draft Retired
Obsoletes: 2460 (if approved) R. Hinden Obsoletes: 2460 (if approved) R. Hinden
Intended status: Standards Track Check Point Software 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 Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-02 draft-ietf-6man-rfc2460bis-03
Abstract Abstract
This document specifies version 6 of the Internet Protocol (IPv6), This document specifies version 6 of the Internet Protocol (IPv6).
also sometimes referred to as IP Next Generation or IPng. It It obsoletes RFC2460
obsoletes RFC2460
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 11 skipping to change at page 6, line 11
that any extension headers [section 4] present that any extension headers [section 4] present
are considered part of the payload, i.e., are considered part of the payload, i.e.,
included in the length count.) included in the length count.)
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the IPv6 header. Uses immediately following the IPv6 header. Uses
the same values as the IPv4 Protocol field the same values as the IPv4 Protocol field
[IANA-PN]. [IANA-PN].
Hop Limit 8-bit unsigned integer. Decremented by 1 by Hop Limit 8-bit unsigned integer. Decremented by 1 by
each node that forwards the packet. The each node that forwards the packet. When
packet is discarded if Hop Limit is forwarding, the packet is discarded if Hop
decremented to zero, or is received with a Limit was zero when received or is decremented
zero Hop Limit. 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 Source Address 128-bit address of the originator of the
packet. See [I-D.hinden-6man-rfc4291bis]. packet. See [I-D.hinden-6man-rfc4291bis].
Destination Address 128-bit address of the intended recipient of Destination Address 128-bit address of the intended recipient of
the packet (possibly not the ultimate the packet (possibly not the ultimate
recipient, if a Routing header is present). recipient, if a Routing header is present).
See [I-D.hinden-6man-rfc4291bis] and section See [I-D.hinden-6man-rfc4291bis] and section
4.4. 4.4.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
A full implementation of IPv6 includes implementation of the A full implementation of IPv6 includes implementation of the
following extension headers: following extension headers:
Hop-by-Hop Options Hop-by-Hop Options
Fragment Fragment
Destination Options Destination Options
Authentication Authentication
Encapsulating Security Payload Encapsulating Security Payload
The first three are specified in this document; the last two are 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 4.1. Extension Header Order
When more than one extension header is used in the same packet, it is When more than one extension header is used in the same packet, it is
recommended that those headers appear in the following order: recommended that those headers appear in the following order:
IPv6 header IPv6 header
Hop-by-Hop Options header Hop-by-Hop Options header
Destination Options header (note 1) Destination Options header (note 1)
Routing header Routing header
skipping to change at page 9, line 42 skipping to change at page 9, line 43
IPv6 nodes must accept and attempt to process extension headers in IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet, any order and occurring any number of times in the same packet,
except for the Hop-by-Hop Options header which is restricted to except for the Hop-by-Hop Options header which is restricted to
appear immediately after an IPv6 header only. Nonetheless, it is appear immediately after an IPv6 header only. Nonetheless, it is
strongly advised that sources of IPv6 packets adhere to the above strongly advised that sources of IPv6 packets adhere to the above
recommended order until and unless subsequent specifications revise recommended order until and unless subsequent specifications revise
that recommendation. that recommendation.
4.2. Options 4.2. Options
Two of the currently-defined extension headers -- the Hop-by-Hop Two of the currently-defined extension headers defined in this
Options header and the Destination Options header -- carry a variable document -- the Hop-by-Hop Options header and the Destination Options
number of type-length-value (TLV) encoded "options", of the following header -- carry a variable number of type-length-value (TLV) encoded
format: "options", of the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data | Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-bit identifier of the type of option. Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the Option Opt Data Len 8-bit unsigned integer. Length of the Option
Data field of this option, in octets. Data field of this option, in octets.
Option Data Variable-length field. Option-Type-specific Option Data Variable-length field. Option-Type-specific
data. data.
The sequence of options within a header must be processed strictly in The sequence of options within a header must be processed strictly in
the order they appear in the header; a receiver must not, for the order they appear in the header; a receiver must not, for
skipping to change at page 15, line 47 skipping to change at page 16, line 4
The initial, large, unfragmented packet is referred to as the The initial, large, unfragmented packet is referred to as the
"original packet", and it is considered to consist of three parts, as "original packet", and it is considered to consist of three parts, as
illustrated: illustrated:
original packet: original packet:
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
| Per-Fragment | Extension & Upper-Layer | Fragmentable | | Per-Fragment | Extension & Upper-Layer | Fragmentable |
| Headers | Headers | Part | | Headers | Headers | Part |
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
The Per-Fragment Headers consists of the IPv6 header plus any The Per-Fragment Headers consists of the IPv6 header plus any
extension headers that must be processed by nodes en route to the extension headers that must be processed by nodes en route to the
destination, that is, all headers up to and including the Routing destination, that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present, header if present, else the Hop-by-Hop Options header if present,
else no extension headers. else no extension headers.
The Extension Headers are all other extension headers that are not The Extension Headers are all other extension headers that are not
included in the Per-Fragment headers part of the packet. For this included in the Per-Fragment headers part of the packet. For this
purpose, the Encapsulating Security Payload (ESP) is not 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. first upper-layer header that is not an IPv6 extension header.
Examples of upper-layer headers include TCP, UDP, IPv4, IPv6, Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
ICMPv6, and as noted ESP. ICMPv6, and as noted ESP.
The Fragmentable Part consists of the rest of the packet after the The Fragmentable Part consists of the rest of the packet after the
upper-layer header or after any header (i.e., initial IPv6 header upper-layer header or after any header (i.e., initial IPv6 header
or extension header) that contains a Next Header value of No Next or extension header) that contains a Next Header value of No Next
Header. Header.
The Fragmentable Part of the original packet is divided into The Fragmentable Part of the original packet is divided into
skipping to change at page 29, line 22 skipping to change at page 29, line 22
"IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/
RFC6437, November 2011, RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>. <http://www.rfc-editor.org/info/rfc6437>.
12.2. Informative References 12.2. Informative References
[IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", [IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml>. ipv6-parameters.xhtml>.
[IANA-EH] "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#extension-header>.
[IANA-PN] "Assigned Internet Protocol Numbers", [IANA-PN] "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/ <https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. protocol-numbers.xhtml>.
[IANA-RH] "IANA Routing Types Parameter Registry", [IANA-RH] "IANA Routing Types Parameter Registry",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-3>. ipv6-parameters.xhtml#ipv6-parameters-3>.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
skipping to change at page 33, line 48 skipping to change at page 33, line 48
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. CHANGES SINCE RFC2460 Appendix B. CHANGES SINCE RFC2460
This memo has the following changes from RFC2460. Numbers identify This memo has the following changes from RFC2460. Numbers identify
the Internet-Draft version in which the change was made. the Internet-Draft version in which the change was made.
Working Group Internet Drafts 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 02) Added text to Section 4.8 "Defining New Extension Headers and
Options" clarifying why no new hop by hop extension headers 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 02) Added text to Fragment Header process on handling exact
duplicate fragments. duplicate fragments.
02) Editorial changes. 02) Editorial changes.
01) Added text that Extension headers must never be inserted by 01) Added text that Extension headers must never be inserted by
any node other than the source of the packet. any node other than the source of the packet.
01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop 01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop
 End of changes. 14 change blocks. 
19 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/