draft-ietf-6man-rfc2460bis-08.txt   draft-ietf-6man-rfc2460bis-09.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: May 19, 2017 November 15, 2016 Expires: October 1, 2017 March 30, 2017
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-08 draft-ietf-6man-rfc2460bis-09
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 May 19, 2017. This Internet-Draft will expire on October 1, 2017.
Copyright Notice 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. 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 2, line 23 skipping to change at page 2, line 23
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Header Format . . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Header Format . . . . . . . . . . . . . . . . . . . . . 5
4. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 6 4. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 6
4.1. Extension Header Order . . . . . . . . . . . . . . . . . 9 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 8
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12
4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14
4.6. Destination Options Header . . . . . . . . . . . . . . . 21 4.6. Destination Options Header . . . . . . . . . . . . . . . 20
4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22 4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22
4.8. Defining New Extension Headers and Options . . . . . . . 22 4.8. Defining New Extension Headers and Options . . . . . . . 22
5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23 5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23
6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24 7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24
8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 25 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24
8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 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 8.4. Responding to Packets Carrying Routing Headers . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Formatting Guidelines for Options . . . . . . . . . 31 Appendix A. Formatting Guidelines for Options . . . . . . . . . 30
Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 34 Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 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 designed as the successor to IP version 4 (IPv4) [RFC0791]. The
changes from IPv4 to IPv6 fall primarily into the following changes from IPv4 to IPv6 fall primarily into the following
categories: categories:
o Expanded Addressing Capabilities o Expanded Addressing Capabilities
IPv6 increases the IP address size from 32 bits to 128 bits, to IPv6 increases the IP address size from 32 bits to 128 bits, to
support more levels of addressing hierarchy, a much greater support more levels of addressing hierarchy, a much greater
number of addressable nodes, and simpler auto-configuration of number of addressable nodes, and simpler auto-configuration of
addresses. The scalability of multicast routing is improved by addresses. The scalability of multicast routing is improved by
skipping to change at page 3, line 50 skipping to change at page 3, line 50
o Authentication and Privacy Capabilities o Authentication and Privacy Capabilities
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 [RFC4291].
[I-D.ietf-6man-rfc4291bis]. The IPv6 version of ICMP, which all IPv6 The IPv6 version of ICMP, which all IPv6 implementations are required
implementations are required to include, is specified in [RFC4443] to include, is specified in [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 5, line 5 skipping to change at page 5, line 5
interfaces. interfaces.
packet an IPv6 header plus payload. packet an IPv6 header plus payload.
link MTU the maximum transmission unit, i.e., maximum packet size link MTU the maximum transmission unit, i.e., maximum packet size
in octets, that can be conveyed over a link. in octets, that can be conveyed over a link.
path MTU the minimum link MTU of all the links in a path between path MTU the minimum link MTU of all the links in a path between
a source node and a destination node. a source node and a destination node.
Note: it is possible, though unusual, for a device with multiple Note: it is possible for a device with multiple interfaces to be
interfaces to be configured to forward non-self-destined packets configured to forward non-self-destined packets arriving from some
arriving from some set (fewer than all) of its interfaces, and to set (fewer than all) of its interfaces, and to discard non-self-
discard non-self-destined packets arriving from its other interfaces. destined packets arriving from its other interfaces. Such a device
Such a device must obey the protocol requirements for routers when must obey the protocol requirements for routers when receiving
receiving packets from, and interacting with neighbors over, the packets from, and interacting with neighbors over, the former
former (forwarding) interfaces. It must obey the protocol (forwarding) interfaces. It must obey the protocol requirements for
requirements for hosts when receiving packets from, and interacting hosts when receiving packets from, and interacting with neighbors
with neighbors over, the latter (non-forwarding) interfaces. over, the latter (non-forwarding) interfaces.
3. IPv6 Header Format 3. IPv6 Header Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit | | Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
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.ietf-6man-rfc4291bis]. packet. See [RFC4291].
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.ietf-6man-rfc4291bis] and section See [RFC4291] 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 is a small number of such extension layer header in a packet. There is a small number of such extension
headers, each one identified by a distinct Next Header value. headers, each one identified by a distinct Next Header value.
Extension Headers are numbered from IANA IP Protocol Numbers Extension Headers are numbered from IANA IP Protocol Numbers
[IANA-PN], the same values used for IPv4 and IPv6. When processing a [IANA-PN], the same values used for IPv4 and IPv6. When processing a
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 |
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
The insertion of Extension Headers by any node other than the source With one exception, extension headers are not examined, processed,
of the packet causes serious problems. Two examples include breaking inserted, or deleted by any node along a packet's delivery path,
the integrity checks provided by the Authentication Header Integrity until the packet reaches the node (or each of the set of nodes, in
[RFC4302], and breaking Path MTU Discovery which can result in ICMP the case of multicast) identified in the Destination Address field of
error messages being sent to the source of the packet that did not the IPv6 header. Note: If an intermediate forwarding node examines
insert the header, rather than the node that inserted the header. an extension header for any reason, it must do so in accordance with
the provisions of [RFC7045]. At the Destination node, normal
One approach to avoid these problems is to encapsulate the packet demultiplexing on the Next Header field of the IPv6 header invokes
using another IPv6 header and including the additional extension the module to process the first extension header, or the upper-layer
header after the first IPv6 header, for example, as defined in header if no extension header is present. The contents and semantics
[RFC2473] of each extension header determine whether or not to proceed to the
next header. Therefore, extension headers must be processed strictly
With one exception, extension headers are not processed by any node in the order they appear in the packet; a receiver must not, for
along a packet's delivery path, until the packet reaches the node (or example, scan through a packet looking for a particular kind of
each of the set of nodes, in the case of multicast) identified in the extension header and process that header prior to processing all
Destination Address field of the IPv6 header. Note: If an preceding ones.
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- The exception referred to in the preceding paragraph is the Hop-by-
Hop Options header, which carries information that may 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.
NOTE: While [RFC2460] required that all nodes must examine and NOTE: While [RFC2460] required that all nodes must examine and
skipping to change at page 15, line 39 skipping to change at page 15, line 22
For every packet that is to be fragmented, the source node generates For every packet that is to be fragmented, the source node generates
an Identification value. The Identification must be different than an Identification value. The Identification must be different than
that of any other fragmented packet sent recently* with the same that of any other fragmented packet sent recently* with the same
Source Address and Destination Address. If a Routing header is Source Address and Destination Address. If a Routing header is
present, the Destination Address of concern is that of the final present, the Destination Address of concern is that of the final
destination. destination.
* "recently" means within the maximum likely lifetime of a * "recently" means within the maximum likely lifetime of a
packet, including transit time from source to destination and packet, including transit time from source to destination and
time spent awaiting reassembly with other fragments of the same 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 the maximum packet lifetime. Rather, it is assumed that the
requirement can be met by implementing an algorithm that requirement can be met by implementing an algorithm that
results in a low identification reuse frequency. Examples of results in a low identification reuse frequency. Examples of
algorithms that can meet this requirement are described in algorithms that can meet this requirement are described in
[RFC7739]. [RFC7739].
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:
skipping to change at page 20, line 46 skipping to change at page 20, line 25
the source of the fragment, with the Pointer field set to zero. the source of the fragment, with the Pointer field set to zero.
o If any of the fragments being reassembled overlaps with any o If any of the fragments being reassembled overlaps with any
other fragments being reassembled for the same packet, other fragments being reassembled for the same packet,
reassembly of that packet must be abandoned and all the reassembly of that packet must be abandoned and all the
fragments that have been received for that packet must be fragments that have been received for that packet must be
discarded and no ICMP error messages should be sent. discarded and no ICMP error messages should be sent.
It should be noted that fragments may be duplicated in the It should be noted that fragments may be duplicated in the
network. Instead of treating these exact duplicate fragments 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 detect this case and drop exact duplicate fragments while
keeping the other fragments belonging to the same packet. keeping the other fragments belonging to the same packet.
The following conditions are not expected to occur, but are not The following conditions are not expected to occur, but are not
considered errors if they do: considered errors if they do:
The number and content of the headers preceding the Fragment The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may header of different fragments of the same original packet may
differ. Whatever headers are present, preceding the Fragment differ. Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets header in each fragment packet, are processed when the packets
skipping to change at page 22, line 43 skipping to change at page 22, line 24
The value 59 in the Next Header field of an IPv6 header or any The value 59 in the Next Header field of an IPv6 header or any
extension header indicates that there is nothing following that extension header indicates that there is nothing following that
header. If the Payload Length field of the IPv6 header indicates the 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 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 contains 59, those octets must be ignored, and passed on unchanged if
the packet is forwarded. the packet is forwarded.
4.8. Defining New Extension Headers and Options 4.8. Defining New Extension Headers and Options
New extension headers that require hop-by-hop behavior must not be 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 Extension Header that has hop-by-hop behavior is the Hop-by-Hop
Options header. Options header.
New hop-by-hop options are not recommended because nodes may be New hop-by-hop options are not recommended because nodes may be
configured to ignore the Hop-by-Hop Option header, drop packets configured to ignore the Hop-by-Hop Option header, drop packets
containing a hop-by-hop header, or assign packets containing a hop- containing a hop-by-hop header, or assign packets containing a hop-
by-hop header to a slow processing path. Designers considering by-hop header to a slow processing path. Designers considering
defining new hop-by-hop options need to be aware of this likely 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- behaviour. There has to be a very clear justification why any new
by-hop option is needed before it is standardized. hop-by-hop option is needed before it is standardized.
Defining new IPv6 extension headers is not recommended. There has to 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 before it is standardized. Instead of defining new Extension
Headers, it is recommended that the Destination Options header is 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 packet's destination node(s), because they provide better handling
and backward compatibility. and backward compatibility.
If new Extension Headers are defined, they need to use the following If new Extension Headers are defined, they need to use the following
format: format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | | | Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
skipping to change at page 23, line 38 skipping to change at page 23, line 24
Next Header 8-bit selector. Identifies the type of Next Header 8-bit selector. Identifies the type of
header immediately following the extension header immediately following the extension
header. Uses the same values as the IPv4 header. Uses the same values as the IPv4
Protocol field [IANA-PN]. Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the Hdr Ext Len 8-bit unsigned integer. Length of the
Destination Options header in 8-octet units, Destination Options header in 8-octet units,
not including the first 8 octets. 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. the extension header.
5. Packet Size Issues 5. Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280 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 octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6. be provided at a layer below IPv6.
Links that have a configurable MTU (for example, PPP links [RFC1661]) Links that have a configurable MTU (for example, PPP links [RFC1661])
skipping to change at page 26, line 19 skipping to change at page 26, line 6
plus TCP data). Some upper-layer protocols carry their own plus TCP data). Some upper-layer protocols carry their own
length information (e.g., the Length field in the UDP header); length information (e.g., the Length field in the UDP header);
for such protocols, that is the length used in the pseudo- for such protocols, that is the length used in the pseudo-
header. Other protocols (such as TCP) do not carry their own header. Other protocols (such as TCP) do not carry their own
length information, in which case the length used in the length information, in which case the length used in the
pseudo-header is the Payload Length from the IPv6 header, minus pseudo-header is the Payload Length from the IPv6 header, minus
the length of any extension headers present between the IPv6 the length of any extension headers present between the IPv6
header and the upper-layer header. header and the upper-layer header.
o Unlike IPv4, the default behavior when UDP packets are 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 optional. That is, whenever originating a UDP packet, an IPv6
node must compute a UDP checksum over the packet and the node must compute a UDP checksum over the packet and the
pseudo-header, and, if that computation yields a result of pseudo-header, and, if that computation yields a result of
zero, it must be changed to hex FFFF for placement in the UDP zero, it must be changed to hex FFFF for placement in the UDP
header. IPv6 receivers must discard UDP packets containing a header. IPv6 receivers must discard UDP packets containing a
zero checksum, and should log the error. zero checksum, and should log the error.
o As an exception to the default behaviour, protocols that use o As an exception to the default behaviour, protocols that use
UDP as a tunnel encapsulation may enable zero-checksum mode for UDP as a tunnel encapsulation may enable zero-checksum mode for
a specific port (or set of ports) for sending and/or receiving. a specific port (or set of ports) for sending and/or receiving.
Any node implementing zero-checksum mode must follow the 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]. of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
The IPv6 version of ICMP [RFC4443] includes the above pseudo-header The IPv6 version of ICMP [RFC4443] includes the above pseudo-header
in its checksum computation; this is a change from the IPv4 version 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 of ICMP, which does not include a pseudo-header in its checksum. The
reason for the change is to protect ICMP from misdelivery or reason for the change is to protect ICMP from misdelivery or
corruption of those fields of the IPv6 header on which it depends, corruption of those fields of the IPv6 header on which it depends,
which, unlike IPv4, are not covered by an internet-layer checksum. which, unlike IPv4, are not covered by an internet-layer checksum.
The Next Header field in the pseudo-header for ICMP contains the The Next Header field in the pseudo-header for ICMP contains the
value 58, which identifies the IPv6 version of ICMP. value 58, which identifies the IPv6 version of ICMP.
skipping to change at page 29, line 9 skipping to change at page 28, line 37
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.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 [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>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC of Explicit Congestion Notification (ECN) to IP", RFC
3168, DOI 10.17487/RFC3168, September 2001, 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, DOI Protocol Version 6 (IPv6) Specification", RFC 4443, DOI
10.17487/RFC4443, March 2006, 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"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>.
skipping to change at page 30, line 37 skipping to change at page 30, line 17
<http://www.rfc-editor.org/info/rfc1661>. <http://www.rfc-editor.org/info/rfc1661>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
10.17487/RFC4302, December 2005, 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, DOI 10.17487/RFC4303, December 2005, 4303, DOI 10.17487/RFC4303, December 2005,
skipping to change at page 34, line 41 skipping to change at page 33, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | Option Type=X |Opt Data Len=12| | 0 | 0 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field | | 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ 8-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 This memo has the following changes from RFC2460.
the Internet-Draft version in which the change was made.
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 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 08) Revised header insertion text in Section 4 based on the
results of w.g. survey that concluded to describe the results of w.g. survey that concluded to describe the
problems with header insertion. problems with header insertion.
08) Editorial changes. 08) Editorial changes.
07) Expanded Security Considerations section to include both 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. as ways to mitigate IP level security issues.
07) Added paragraph to Section 4 to clarify how Extension Headers 07) Added paragraph to Section 4 to clarify how Extension Headers
are numbered and which are upper-layer headers. are numbered and which are upper-layer headers.
07) Moved the text regarding network duplicated fragments to the 07) Moved the text regarding network duplicated fragments to the
received fragment error section. received fragment error section.
07) Added clarification that no ICMP error message should be sent 07) Added clarification that no ICMP error message should be sent
if overlapping fragments are received. if overlapping fragments are received.
skipping to change at page 36, line 43 skipping to change at page 38, line 41
01) Updated the Fragmentation header text to correct the 01) Updated the Fragmentation header text to correct the
inclusion of AH and note no next header case. inclusion of AH and note no next header case.
01) Change terminology in Fragment header section from 01) Change terminology in Fragment header section from
"Unfragmentable Headers" to "Per-Fragment Headers". "Unfragmentable Headers" to "Per-Fragment Headers".
01) Removed paragraph in Section 5 that required including a 01) Removed paragraph in Section 5 that required including a
fragment header to outgoing packets if a ICMP Packet Too Big fragment header to outgoing packets if a ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. This is message reporting a Next-Hop MTU less than 1280. This is
based on the update in draft-ietf-6man-deprecate-atomfrag- based on the update in RFC8021.
generation.
01) Changed to Fragmentation Header section to clarify MTU 01) Changed to Fragmentation Header section to clarify MTU
restriction and 8-byte restrictions, and noting the restriction and 8-byte restrictions, and noting the
restriction on headers in first fragment. restriction on headers in first fragment.
01) Editorial changes. 01) Editorial changes.
00) Add instruction to the IANA to change references to RFC2460 00) Add instruction to the IANA to change references to RFC2460
to this document to this document
skipping to change at page 39, line 12 skipping to change at page 41, line 9
of this draft. Note: No change was made regarding host of this draft. Note: No change was made regarding host
behaviour. behaviour.
Errata ID: 2843: This errata is marked rejected. No Errata ID: 2843: This errata is marked rejected. No
change is required. change is required.
02) Editorial changes to the Flow Label and Traffic Class text. 02) Editorial changes to the Flow Label and Traffic Class text.
01) The purpose of this version of the draft is to update the 01) The purpose of this version of the draft is to update the
document to point to the current specifications of the IPv6 document to point to the current specifications of the IPv6
Flow Label field as defined in [RFC6437] and the Traffic Flow Label field as defined in [RFC6437] and the Traffic
Class as defined in [RFC2474] and [RFC3168]. Class as defined in [RFC2474] and [RFC3168].
00) The purpose of this version is to establish a baseline from 00) The purpose of this version is to establish a baseline from
RFC2460. The only intended changes are formatting (XML is RFC2460. The only intended changes are formatting (XML is
slightly different from .nroff), differences between an RFC slightly different from .nroff), differences between an RFC
and Internet Draft, fixing a few ID Nits, and updates to the and Internet Draft, fixing a few ID Nits, and updates to the
authors information. There should not be any content changes authors information. There should not be any content changes
to the specification. to the specification.
Authors' Addresses Authors' Addresses
 End of changes. 37 change blocks. 
86 lines changed or deleted 202 lines changed or added

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