draft-ietf-6man-rfc2460bis-10.txt   draft-ietf-6man-rfc2460bis-11.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: October 23, 2017 April 21, 2017 Expires: October 30, 2017 April 28, 2017
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-10 draft-ietf-6man-rfc2460bis-11
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 October 23, 2017. This Internet-Draft will expire on October 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . 8 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 8
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12
4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14
4.6. Destination Options Header . . . . . . . . . . . . . . . 20 4.6. Destination Options Header . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . 24 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 25
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25
8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26
8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27
8.4. Responding to Packets Carrying Routing Headers . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Formatting Guidelines for Options . . . . . . . . . 33 Appendix A. Formatting Guidelines for Options . . . . . . . . . 33
Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36 Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36
B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39 B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
IP version 6 (IPv6) is a new version of the Internet Protocol (IP), 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
skipping to change at page 5, line 48 skipping to change at page 5, line 48
Version 4-bit Internet Protocol version number = 6. Version 4-bit Internet Protocol version number = 6.
Traffic Class 8-bit traffic class field. See section 7. Traffic Class 8-bit traffic class field. See section 7.
Flow Label 20-bit flow label. See section 6. Flow Label 20-bit flow label. See section 6.
Payload Length 16-bit unsigned integer. Length of the IPv6 Payload Length 16-bit unsigned integer. Length of the IPv6
payload, i.e., the rest of the packet payload, i.e., the rest of the packet
following this IPv6 header, in octets. (Note following this IPv6 header, in octets. (Note
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. When each node that forwards the packet. When
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 |
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
With one exception, extension headers are not examined, processed, Extension headers (except for the Hop-by-Hop Options header) are not
inserted, or deleted by any node along a packet's delivery path, processed, inserted, or deleted by any node 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 Destination Address field
of the IPv6 header.
The Hop-by-Hop Options header is not inserted or deleted, but may be
examined or processed by any node along a packet's delivery path,
until the packet reaches the node (or each of the set of nodes, in until the packet reaches the node (or each of the set of nodes, in
the case of multicast) identified in the Destination Address field of the case of multicast) identified in the Destination Address field of
the IPv6 header. Note: If an intermediate forwarding node examines the IPv6 header. The Hop-by-Hop Options header, when present, must
an extension header for any reason, it must do so in accordance with immediately follow the IPv6 header. Its presence is indicated by the
the provisions of [RFC7045]. At the Destination node, normal value zero in the Next Header field of the IPv6 header.
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-
Hop Options header, which carries information that may be examined
and processed by every node along a packet's delivery path, including
the source and destination nodes. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its presence
is indicated by the value zero in the Next Header field of the IPv6
header.
NOTE: While [RFC2460] required that all nodes must examine and NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that nodes process the Hop-by-Hop Options header, it is now expected that nodes
along a packet's delivery path only examine and process the Hop-by- along a packet's delivery path only examine and process the Hop-by-
Hop Options header if explicitly configured to do so. Hop Options header if explicitly configured to do so.
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.
If, as a result of processing a header, the destination node is If, as a result of processing a header, the destination node is
required to proceed to the next header but the Next Header value in required to proceed to the next header but the Next Header value in
the current header is unrecognized by the node, it should discard the the current header is unrecognized by the node, it should discard the
packet and send an ICMP Parameter Problem message to the source of packet and send an ICMP Parameter Problem message to the source of
the packet, with an ICMP Code value of 1 ("unrecognized Next Header the packet, with an ICMP Code value of 1 ("unrecognized Next Header
type encountered") and the ICMP Pointer field containing the offset type encountered") and the ICMP Pointer field containing the offset
of the unrecognized value within the original packet. The same of the unrecognized value within the original packet. The same
action should be taken if a node encounters a Next Header value of action should be taken if a node encounters a Next Header value of
zero in any header other than an IPv6 header. zero in any header other than an IPv6 header.
skipping to change at page 20, line 44 skipping to change at page 20, line 44
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
arrive, prior to queueing the fragments for reassembly. Only arrive, prior to queueing the fragments for reassembly. Only
those headers in the Offset zero fragment packet are retained in those headers in the Offset zero fragment packet are retained in
the reassembled packet. the reassembled packet.
The Next Header values in the Fragment headers of different The Next Header values in the Fragment headers of different
fragments of the same original packet may differ. Only the value fragments of the same original packet may differ. Only the value
from the Offset zero fragment packet is used for reassembly. from the Offset zero fragment packet is used for reassembly.
Other fields in the IPv6 header may also vary across the fragments
being reassembled. Specifications that use these fields may
provide additional instructions if the basic mechanism of using
the values from the Offset zero fragment is not sufficient. For
example, Section 5.3 of [RFC3168] describes how to combine the
Explicit Congestion Notification (ECN) bits from different
fragments to derive the ECN bits of the reassembled packet.
4.6. Destination Options Header 4.6. Destination Options Header
The Destination Options header is used to carry optional information The Destination Options header is used to carry optional information
that need be examined only by a packet's destination node(s). The that need be examined only by a packet's destination node(s). The
Destination Options header is identified by a Next Header value of 60 Destination Options header is identified by a Next Header value of 60
in the immediately preceding header, and has the following format: in the immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | | | Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
skipping to change at page 22, line 28 skipping to change at page 22, line 36
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.
Defining new IPv6 extension headers is not recommended, unless there
are no existing IPv6 extension header that can be used by specifying
a new option for that IPv6 extension header. A proposal to specify a
new IPv6 extension header must include a detailed technical
explanation of why an existing IPv6 extension header can not be used
for the desired new function.
Note: New extension headers that require hop-by-hop behavior must not
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 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 be a very clear justification why any new behaviour. There has to be a very clear justification why any new
hop-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 Instead of defining new Extension Headers, it is recommended that the
be a very clear justification why any new extension header is needed Destination Options header is used to carry optional information that
before it is standardized. Instead of defining new Extension must be examined only by a packet's destination node(s), because they
Headers, it is recommended that the Destination Options header is provide better handling and backward compatibility.
used to carry optional information that must be examined only by a
packet's destination node(s), because they provide better handling
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Header Specific Data . . Header Specific Data .
skipping to change at page 29, line 26 skipping to change at page 29, line 39
This version of the IPv6 specification resolves a number of security This version of the IPv6 specification resolves a number of security
issues that were found with the previous version [RFC2460] of the issues that were found with the previous version [RFC2460] of the
IPv6 specification. These include: IPv6 specification. These include:
o Revised the text to handle the case of fragments that are whole o Revised the text to handle the case of fragments that are whole
datagrams (i.e., both the Fragment Offset field and the M flag datagrams (i.e., both the Fragment Offset field and the M flag
are zero). If received they should be processed as a are zero). If received they should be processed as a
reassembled packet. Any other fragments that match should be reassembled packet. Any other fragments that match should be
processed independently. The Fragment creation process was processed independently. The Fragment creation process was
modified to not create whole datagram fragments (Fragment modified to not create whole datagram fragments (Fragment
Offset field and the M flag are zero). See [RFC6946] for more Offset field and the M flag are zero). See [RFC6946] and
information. [RFC8021] for more information.
o Changed the text to require that IPv6 nodes must not create o Changed the text to require that IPv6 nodes must not create
overlapping fragments. Also, when reassembling an IPv6 overlapping fragments. Also, when reassembling an IPv6
datagram, if one or more its constituent fragments is datagram, if one or more its constituent fragments is
determined to be an overlapping fragment, the entire datagram determined to be an overlapping fragment, the entire datagram
(and any constituent fragments) must be silently discarded. (and any constituent fragments) must be silently discarded.
Includes clarification that no ICMP error message should be Includes clarification that no ICMP error message should be
sent if overlapping fragments are received. See [RFC5722] for sent if overlapping fragments are received. See [RFC5722] for
more information. more information.
skipping to change at page 33, line 23 skipping to change at page 33, line 32
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>. <http://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <http://www.rfc-editor.org/info/rfc7739>. February 2016, <http://www.rfc-editor.org/info/rfc7739>.
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6
Atomic Fragments Considered Harmful", RFC 8021, DOI
10.17487/RFC8021, January 2017,
<http://www.rfc-editor.org/info/rfc8021>.
Appendix A. Formatting Guidelines for Options Appendix A. Formatting Guidelines for Options
This appendix gives some advice on how to lay out the fields when This appendix gives some advice on how to lay out the fields when
designing new options to be used in the Hop-by-Hop Options header or designing new options to be used in the Hop-by-Hop Options header or
the Destination Options header, as described in section 4.2. These the Destination Options header, as described in section 4.2. These
guidelines are based on the following assumptions: guidelines are based on the following assumptions:
o One desirable feature is that any multi-octet fields within the o One desirable feature is that any multi-octet fields within the
Option Data area of an option be aligned on their natural Option Data area of an option be aligned on their natural
boundaries, i.e., fields of width n octets should be placed at boundaries, i.e., fields of width n octets should be placed at
skipping to change at page 36, line 45 skipping to change at page 36, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ 8-octet field + + 8-octet field +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Changes Since RFC2460 Appendix B. Changes Since RFC2460
This memo has the following changes from RFC2460. This memo has the following changes from RFC2460.
o Clarification that extension headers are not examined, processed, o Removed IP Next Generation from the Abstract.
inserted, or deleted by any node along a packet's delivery path.
o Added text in Section 1 that the Data Transmission Order is the
same as IPv4 as defined in RFC791.
o Clarified the text in Section 3 about decrementing the hop limit.
o Clarification that extension headers (except for the hop-by-hop
options header) are not processed, inserted, or deleted by any
node along a packet's delivery path.
o Changed requirement for the Hop-by-Hop Options header to a may,
and added a note to indicate what is expected regarding the Hop-
by-Hop Options header.
o Added paragraph to Section 4 to clarify how Extension Headers are o Added paragraph to Section 4 to clarify how Extension Headers are
numbered and which are upper-layer headers. numbered and which are upper-layer headers.
o Revision Section 4.5 on IPv6 Fragmentation based on updates from o Add reference to the end of Section 4 to IPv6 Extension Header
IANA registry.
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 Revised Section 4.5 on IPv6 Fragmentation based on updates from
RFC5722, RFC6946 RFC7112, and RFC8021. This include: RFC5722, RFC6946 RFC7112, and RFC8021. This include:
- Revised the text to handle the case of fragments that are whole - Revised the text to handle the case of fragments that are whole
datagrams (i.e., both the Fragment Offset field and the M flag datagrams (i.e., both the Fragment Offset field and the M flag
are zero). If received they should be processed as a are zero). If received they should be processed as a
reassembled packet. Any other fragments that match should be reassembled packet. Any other fragments that match should be
processed independently. The revised Fragment creation process processed independently. The revised Fragment creation process
was modified to not create whole datagram fragments (Fragment was modified to not create whole datagram fragments (Fragment
Offset field and the M flag are zero). Offset field and the M flag are zero).
skipping to change at page 37, line 43 skipping to change at page 38, line 19
"Unfragmentable Headers" to "Per-Fragment Headers". "Unfragmentable Headers" to "Per-Fragment Headers".
- Removed the paragraph in Section 5 that required including a - Removed the 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. message reporting a Next-Hop MTU less than 1280.
- Changed the text to clarify MTU restriction and 8-byte - Changed the text to clarify MTU restriction and 8-byte
restrictions, and noting the restriction on headers in first restrictions, and noting the restriction on headers in first
fragment. fragment.
o Changed requirement for HBH header to a may, and added a note to o In Section 4.5 added clarification noting that some fields in the
indicate what is expected regarding HBH headers. IPv6 header may also vary across the fragments being reassembled
and that other specifications may provide additional instructions
o Clarified the text in Section 3 about decrementing the hop limit. for how they should be reassembled. For example, Section 5.3 of
[RFC3168].
o Removed IP Next Generation from the Abstract. o Incorporated the update from RFC6564 to add a new Section 4.8 that
describes recommendations for defining new Extension headers and
options
o Add reference to the end of Section 4 to IPv6 Extension Header o Simplify the text in Section 6 about Flow Labels and remove
IANA registry. 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].
o Added text in Section 1 that the Data Transmission Order is the o Incorporate the update in made by RFC6935 "UDP Checksums for
same as IPv4 as defined in RFC791. 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 Add instruction to the IANA Considerations section to change o Add instruction to the IANA Considerations section to change
references to RFC2460 to this document references to RFC2460 to this document
o Revised and expanded the Security Consideration section.
o Add a paragraph to the acknowledgement section acknowledging the o Add a paragraph to the acknowledgement section acknowledging the
authors of the updating documents authors of the updating documents
o Update references to current versions and assign references to o Update references to current versions and assign references to
normative and informative. normative and informative.
o Incorporated 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: o Changes to resolve the open Errata on RFC2460. These are:
Errata ID: 2541: This errata notes that RFC2460 didn't update Errata ID: 2541: This errata notes that RFC2460 didn't update
RFC2205 when the length of the Flow Label was changed from 24 RFC2205 when the length of the Flow Label was changed from 24
to 20 bits from RFC1883. This issue was resolved in RFC6437 to 20 bits from RFC1883. This issue was resolved in RFC6437
where the Flow Label is defined. This draft now references where the Flow Label is defined. This draft now references
RFC6437. No change is required. RFC6437. No change is required.
Errata ID: 4279: This errata noted that the specification Errata ID: 4279: This errata noted that the specification
doesn't handle the case of a forwarding node receiving a packet 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 with a zero Hop Limit. This is fixed in Section 3 of this
draft. draft.
Errata ID: 2843: This errata is marked rejected. No change was Errata ID: 2843: This errata is marked rejected. No change was
made. 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].
o Revised and expanded the Security Consideration section.
B.1. Change History Since RFC2460 B.1. Change History Since RFC2460
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication Publication
This section describes change history made in each Internet Draft This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made. Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
11) In Section 4.5 added clarification noting that some fields in
the IPv6 header may also vary across the fragments being
reassembled and that other specifications may provide
additional instructions for how they should be reassembled.
For example, Section 5.3 of [RFC3168].
11) In Section 4 restructured text including separated behaviors
of extension headers and the hop-by-hop option header,
removed "examine" from first paragraph about extension
headers, and removed reference to RFC7045 because "examine"
was removed (RFC7045 is referenced in Security
Considerations). Also removed "including the source and
destination nodes" from paragraph about the hop-by-hop
options header.
11) Revised Section 4.8 to make it closer to the update done by
RFC6554 that updated it and reordered the paragraphs.
11) Reordered items in Appendix B "Changes Since RFC2460" match
order of the document.
11) Editorial changes.
10) Revised and expanded Security Consideration Section based on 10) Revised and expanded Security Consideration Section based on
IESG Discuss comments. IESG Discuss comments.
10) Editorial changes. 10) Editorial changes.
09) Based on results of IETF last call, changed text in Section 4 09) Based on results of IETF last call, changed text in Section 4
to add clarification that extension headers are not examined, to add clarification that extension headers are not examined,
processed, inserted, or deleted by any node along a packet's processed, inserted, or deleted by any node along a packet's
delivery path. delivery path.
skipping to change at page 40, line 35 skipping to change at page 41, line 19
06) Moved the text in Section 4.5 regarding the handling of 06) Moved the text in Section 4.5 regarding the handling of
received overlapping fragments to the list of error received overlapping fragments to the list of error
conditions conditions
06) Rewrote the text in Section 4.8 "Defining New Extension 06) Rewrote the text in Section 4.8 "Defining New Extension
Headers and Options" to be clearer and remove redundant text. Headers and Options" to be clearer and remove redundant text.
06) Editorial changes. 06) Editorial changes.
05) Changed requirement for HBH header from a should to a may, 05) Changed requirement for the Hop-by-Hop Options header from a
and added a note to indicate what is expected. should to a may, and added a note to indicate what is
expected.
05) Corrected reference to point to draft-ietf-6man-rfc4291bis 05) Corrected reference to point to draft-ietf-6man-rfc4291bis
instead of draft-hinden-6man-rfc4291bis. instead of draft-hinden-6man-rfc4291bis.
05) Change to text regarding not inserting extension headers to 05) Change to text regarding not inserting extension headers to
cite using encapsulation as an example. 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.
 End of changes. 27 change blocks. 
76 lines changed or deleted 129 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/