< draft-ietf-6man-rfc2460bis-04.txt   draft-ietf-6man-rfc2460bis-05.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: September 22, 2016 March 21, 2016 Expires: December 30, 2016 June 28, 2016
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-04 draft-ietf-6man-rfc2460bis-05
Abstract Abstract
This document specifies version 6 of the Internet Protocol (IPv6). This document specifies version 6 of the Internet Protocol (IPv6).
It obsoletes RFC2460 It 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 September 22, 2016. This Internet-Draft will expire on December 30, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Extensions to support authentication, data integrity, and Extensions to support authentication, data integrity, and
(optional) data confidentiality are specified for IPv6. (optional) data confidentiality are specified for IPv6.
This document specifies the basic IPv6 header and the initially- This document specifies the basic IPv6 header and the initially-
defined IPv6 extension headers and options. It also discusses packet defined IPv6 extension headers and options. It also discusses packet
size issues, the semantics of flow labels and traffic classes, and size issues, the semantics of flow labels and traffic classes, and
the effects of IPv6 on upper-layer protocols. The format 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
[I-D.hinden-6man-rfc4291bis]. The IPv6 version of ICMP, which all [I-D.ietf-6man-rfc4291bis]. The IPv6 version of ICMP, which all IPv6
IPv6 implementations are required to include, is specified in implementations are required to include, is specified in [RFC4443]
[RFC4443]
The data transmission order for IPv6 is the same as for IPv4 as The data transmission order for IPv6 is the same as for IPv4 as
defined in Appendix B of [RFC0791]. defined in Appendix B of [RFC0791].
Note: As this document obsoletes [RFC2460], any document referenced Note: As this document obsoletes [RFC2460], any document referenced
in this document that includes pointers to RFC2460, should be in this document that includes pointers to RFC2460, should be
interpreted as referencing this document. interpreted as referencing this document.
2. Terminology 2. Terminology
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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. When each node that forwards the packet. When
forwarding, the packet is discarded if Hop forwarding, the packet is discarded if Hop
Limit was zero when received or is decremented Limit was zero when received or is decremented
to zero. A node that is the destination of a to zero. A node that is the destination of a
packet should not discard a packet with hop packet should not discard a packet with hop
limit equal to zero, it should process the limit equal to zero, it should process the
packet normally. 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.ietf-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.ietf-6man-rfc4291bis] and section
4.4. 4.4.
4. IPv6 Extension Headers 4. IPv6 Extension Headers
In IPv6, optional internet-layer information is encoded in separate In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the upper- headers that may be placed between the IPv6 header and the upper-
layer header in a packet. There are a small number of such extension layer header in a packet. There are a small number of such extension
headers, each identified by a distinct Next Header value. As headers, each identified by a distinct Next Header value. As
illustrated in these examples, an IPv6 packet may carry zero, one, or illustrated in these examples, an IPv6 packet may carry zero, one, or
more extension headers, each identified by the Next Header field of more extension headers, each identified by the Next Header field of
skipping to change at page 7, line 26 skipping to change at page 7, line 26
| Routing | TCP | | Routing | TCP |
+---------------+----------------+------------------------ +---------------+----------------+------------------------
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP | IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data | | | | header + data
| Next Header = | Next Header = | Next Header = | | Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP | | Routing | Fragment | TCP |
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
Extension headers must never be inserted by any node other than the The insertion of Extension Headers by any node other than the source
source of the packet. IP Encapsulation must be used to meet any of the packet breaks PMTU-discovery and can result in ICMP error
requirement for inserting headers, for example, as defined in messages being sent to the source of the packet that did not insert
[RFC2473]. the header.
The current approach to allowing a header to be inserted 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 With one exception, extension headers are not processed by any node
along a packet's delivery path, until the packet reaches the node (or 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 each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header. Note: If an Destination Address field of the IPv6 header. Note: If an
intermediate forwarding node examines an extension header for any intermediate forwarding node examines an extension header for any
reason, it must do so in accordance with the provisions of [RFC7045]. reason, it must do so in accordance with the provisions of [RFC7045].
At the Destination node, normal demultiplexing on the Next Header At the Destination node, normal demultiplexing on the Next Header
field of the IPv6 header invokes the module to process the first field of the IPv6 header invokes the module to process the first
extension header, or the upper-layer header if no extension header is extension header, or the upper-layer header if no extension header is
present. The contents and semantics of each extension header present. The contents and semantics of each extension header
determine whether or not to proceed to the next header. Therefore, determine whether or not to proceed to the next header. Therefore,
extension headers must be processed strictly in the order they appear extension headers must be processed strictly in the order they appear
in the packet; a receiver must not, for example, scan through a in the packet; a receiver must not, for example, scan through a
packet looking for a particular kind of extension header and process packet looking for a particular kind of extension header and process
that header prior to processing all preceding ones. that header prior to processing all preceding ones.
The exception referred to in the preceding paragraph is the Hop-by- The exception referred to in the preceding paragraph is the Hop-by-
Hop Options header, which carries information that should be examined Hop Options header, which carries information that may be examined
and processed by every node along a packet's delivery path, including and processed by every node along a packet's delivery path, including
the source and destination nodes. The Hop-by-Hop Options header, the source and destination nodes. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its presence when present, must immediately follow the IPv6 header. Its presence
is indicated by the value zero in the Next Header field of the IPv6 is indicated by the value zero in the Next Header field of the IPv6
header. header.
It should be noted that due to performance restrictions nodes may NOTE: While [RFC2460] required that all nodes must examine and
ignore the Hop-by-Hop Option header, drop packets containing a hop- process the Hop-by-Hop Options header, it is now expected that nodes
by-hop option header, or assign packets containing a hop-by-hop along a packet's delivery path only examine and process the Hop-by-
option header to a slow processing path. Designers planning to use a Hop Options header if explicitly configured to do so.
hop-by-hop option need to be aware of this likely behaviour.
If, as a result of processing a header, a node is required to proceed If, as a result of processing a header, a node is required to proceed
to the next header but the Next Header value in the current header is 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 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 Parameter Problem message to the source of the packet, with an
ICMP Code value of 1 ("unrecognized Next Header type encountered") ICMP Code value of 1 ("unrecognized Next Header type encountered")
and the ICMP Pointer field containing the offset of the unrecognized and the ICMP Pointer field containing the offset of the unrecognized
value within the original packet. The same action should be taken if 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 a node encounters a Next Header value of zero in any header other
than an IPv6 header. than an IPv6 header.
skipping to change at page 12, line 21 skipping to change at page 12, line 26
The PadN option is used to insert two or more octets of padding The PadN option is used to insert two or more octets of padding
into the Options area of a header. For N octets of padding, the into the Options area of a header. For N octets of padding, the
Opt Data Len field contains the value N-2, and the Option Data Opt Data Len field contains the value N-2, and the Option Data
consists of N-2 zero-valued octets. consists of N-2 zero-valued octets.
Appendix A contains formatting guidelines for designing new options. Appendix A contains formatting guidelines for designing new options.
4.3. Hop-by-Hop Options Header 4.3. Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information The Hop-by-Hop Options header is used to carry optional information
that should be examined by every node along a packet's delivery path. that may be examined and processed by every node along a packet's
The Hop-by-Hop Options header is identified by a Next Header value of delivery path. The Hop-by-Hop Options header is identified by a Next
0 in the IPv6 header, and has the following format: Header value of 0 in the IPv6 header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | | | Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 32 skipping to change at page 28, line 32
Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica, Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica,
Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks,
Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh
Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka
Savola, Magnus Westerlund, and James Woodyatt. Savola, Magnus Westerlund, and James Woodyatt.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.hinden-6man-rfc4291bis] [I-D.ietf-6man-rfc4291bis]
Hinden, B. and S. Deering, "IP Version 6 Addressing Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-hinden-6man-rfc4291bis-06 (work in Architecture", draft-ietf-6man-rfc4291bis-02 (work in
progress), October 2015. progress), April 2016.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981, 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
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
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 04) Changed text discussing Fragment ID selection to refer to
RFC7739 for example algorithms. RFC7739 for example algorithms.
04) Editorial changes. 04) Editorial changes.
03) Clarified the text about decrementing the hop limit. 03) Clarified the text about decrementing the hop limit.
03) Removed IP Next Generation from the Abstract. 03) Removed IP Next Generation from the Abstract.
03) Add reference to the end of Section 4 to IPv6 Extension 03) Add reference to the end of Section 4 to IPv6 Extension
 End of changes. 12 change blocks. 
25 lines changed or deleted 37 lines changed or added

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