draft-ietf-6man-rfc2460bis-06.txt   draft-ietf-6man-rfc2460bis-07.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: March 17, 2017 September 13, 2016 Expires: April 7, 2017 October 4, 2016
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-06 draft-ietf-6man-rfc2460bis-07
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 March 17, 2017. This Internet-Draft will expire on April 7, 2017.
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 2, line 34 skipping to change at page 2, line 34
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . 13
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14
4.6. Destination Options Header . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 Appendix A. Formatting Guidelines for Options . . . . . . . . . 31
Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33 Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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,
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 6, line 32 skipping to change at page 6, line 32
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 [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 is a small number of such extension
headers, each identified by a distinct Next Header value. As headers, each one identified by a distinct Next Header value.
illustrated in these examples, an IPv6 packet may carry zero, one, or
more extension headers, each identified by the Next Header field of Extension Headers are numbered from IANA IP Protocol Numbers
the preceding header: [IANA-PN], the same values used for IPv4 and IPv6. When processing a
sequence of Next Header values in a packet, the first one that is not
an Extension Header [IANA-EH] indicates that the next item in the
packet is the corresponding upper-layer header. A special "No Next
Header" value is used if there is no upper-layer header.
As illustrated in these examples, an IPv6 packet may carry zero, one,
or more extension headers, each identified by the Next Header field
of the preceding header:
+---------------+------------------------ +---------------+------------------------
| IPv6 header | TCP header + data | IPv6 header | TCP header + data
| | | |
| Next Header = | | Next Header = |
| TCP | | TCP |
+---------------+------------------------ +---------------+------------------------
+---------------+----------------+------------------------ +---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data | IPv6 header | Routing header | TCP header + data
skipping to change at page 8, line 18 skipping to change at page 8, line 18
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
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.
If, as a result of processing a header, a node is required to proceed If, as a result of processing a header, the destination node is
to the next header but the Next Header value in the current header is required to proceed to the next header but the Next Header value in
unrecognized by the node, it should discard the packet and send an the current header is unrecognized by the node, it should discard the
ICMP Parameter Problem message to the source of the packet, with an packet and send an ICMP Parameter Problem message to the source of
ICMP Code value of 1 ("unrecognized Next Header type encountered") the packet, with an ICMP Code value of 1 ("unrecognized Next Header
and the ICMP Pointer field containing the offset of the unrecognized type encountered") and the ICMP Pointer field containing the offset
value within the original packet. The same action should be taken if of the unrecognized value within the original packet. The same
a node encounters a Next Header value of zero in any header other action should be taken if a node encounters a Next Header value of
than an IPv6 header. zero in any header other than an IPv6 header.
Each extension header is an integer multiple of 8 octets long, in Each extension header is an integer multiple of 8 octets long, in
order to retain 8-octet alignment for subsequent headers. Multi- order to retain 8-octet alignment for subsequent headers. Multi-
octet fields within each extension header are aligned on their octet fields within each extension header are aligned on their
natural boundaries, i.e., fields of width n octets are placed at an natural boundaries, i.e., fields of width n octets are placed at an
integer multiple of n octets from the start of the header, for n = 1, integer multiple of n octets from the start of the header, for n = 1,
2, 4, or 8. 2, 4, or 8.
A full implementation of IPv6 includes implementation of the A full implementation of IPv6 includes implementation of the
following extension headers: following extension headers:
skipping to change at page 19, line 40 skipping to change at page 19, line 40
from the fragments following the Fragment headers in each of from the fragments following the Fragment headers in each of
the fragment packets. The length of each fragment is computed the fragment packets. The length of each fragment is computed
by subtracting from the packet's Payload Length the length of by subtracting from the packet's Payload Length the length of
the headers between the IPv6 header and fragment itself; its the headers between the IPv6 header and fragment itself; its
relative position in Fragmentable Part is computed from its relative position in Fragmentable Part is computed from its
Fragment Offset value. Fragment Offset value.
The Fragment header is not present in the final, reassembled The Fragment header is not present in the final, reassembled
packet. packet.
It should be noted that fragments may be duplicated in the
network. These exact duplicate fragments will be treated as
overlapping fragments and handled as described in the previous
paragraph. An implementation may choose to detect this case
and not drop the other fragments of the same packet.
If the fragment is a whole datagram (that is, both the Fragment If the fragment is a whole datagram (that is, both the Fragment
Offset field and the M flag are zero), then it does not need Offset field and the M flag are zero), then it does not need
any further reassembly and should be processed as a fully any further reassembly and should be processed as a fully
reassembled packet (i.e., updating Next Header, adjust Payload reassembled packet (i.e., updating Next Header, adjust Payload
Length, removing the Fragmentation Header, etc.). Any other Length, removing the Fragmentation Header, etc.). Any other
fragments that match this packet (i.e., the same IPv6 Source fragments that match this packet (i.e., the same IPv6 Source
Address, IPv6 Destination Address, and Fragment Identification) Address, IPv6 Destination Address, and Fragment Identification)
should be processed independently. should be processed independently.
The following error conditions may arise when reassembling fragmented The following error conditions may arise when reassembling fragmented
packets: packets:
If insufficient fragments are received to complete reassembly of a o If insufficient fragments are received to complete reassembly
packet within 60 seconds of the reception of the first-arriving of a packet within 60 seconds of the reception of the first-
fragment of that packet, reassembly of that packet must be arriving fragment of that packet, reassembly of that packet
abandoned and all the fragments that have been received for that must be abandoned and all the fragments that have been received
packet must be discarded. If the first fragment (i.e., the one for that packet must be discarded. If the first fragment
with a Fragment Offset of zero) has been received, an ICMP Time (i.e., the one with a Fragment Offset of zero) has been
Exceeded -- Fragment Reassembly Time Exceeded message should be received, an ICMP Time Exceeded -- Fragment Reassembly Time
sent to the source of that fragment. Exceeded message should be sent to the source of that fragment.
If the length of a fragment, as derived from the fragment packet's o If the length of a fragment, as derived from the fragment
Payload Length field, is not a multiple of 8 octets and the M flag packet's Payload Length field, is not a multiple of 8 octets
of that fragment is 1, then that fragment must be discarded and an and the M flag of that fragment is 1, then that fragment must
ICMP Parameter Problem, Code 0, message should be sent to the be discarded and an ICMP Parameter Problem, Code 0, message
source of the fragment, pointing to the Payload Length field of should be sent to the source of the fragment, pointing to the
the fragment packet. Payload Length field of the fragment packet.
If the length and offset of a fragment are such that the Payload o If the length and offset of a fragment are such that the
Length of the packet reassembled from that fragment would exceed Payload Length of the packet reassembled from that fragment
65,535 octets, then that fragment must be discarded and an ICMP would exceed 65,535 octets, then that fragment must be
Parameter Problem, Code 0, message should be sent to the source of discarded and an ICMP Parameter Problem, Code 0, message should
the fragment, pointing to the Fragment Offset field of the be sent to the source of the fragment, pointing to the Fragment
fragment packet. Offset field of the fragment packet.
If the first fragment does not include all headers through an o If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and an Upper-Layer header, then that fragment should be discarded and
ICMP Parameter Problem, Code 3, message should be sent to the an ICMP Parameter Problem, Code 3, message should be sent to
source of the fragment, with the Pointer field set to zero. the source of the fragment, with the Pointer field set to zero.
If any of the fragments being reassembled overlaps with any other o If any of the fragments being reassembled overlaps with any
fragments being reassembled for the same packet, reassembly of other fragments being reassembled for the same packet,
that packet must be abandoned and all the fragments that have been reassembly of that packet must be abandoned and all the
received for that packet must be discarded. fragments that have been received for that packet must be
discarded and no ICMP error messages should be sent.
It should be noted that fragments may be duplicated in the
network. Instead of treating these exact duplicate fragments
as an overlapping fragments, an implementation may choose to
detect this case and drop exact duplicate fragments while
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
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
skipping to change at page 22, line 39 skipping to change at page 22, line 42
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
No new extension headers that require hop-by-hop behavior should 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 it is expected New hop-by-hop options are not recommended because nodes may be
that nodes along a packet's delivery path will only examine and configured to ignore the Hop-by-Hop Option header, drop packets
process the hop-by-hop option header if explicitly configured to do containing a hop-by-hop header, or assign packets containing a hop-
so. by-hop header to a slow processing path. Designers considering
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-
by-hop option is needed before it is standardized.
Defining new IPv6 extension headers is not recommended. Instead of Defining new IPv6 extension headers is not recommended. There has to
defining new Extension Headers, it is recommended that the 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
need be examined only by a packet's destination node(s). Headers, it is recommended that the Destination Options header is
used to carry optional information that need 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 27, line 42 skipping to change at page 28, line 13
by the responder. by the responder.
9. IANA Considerations 9. IANA Considerations
RFC2460 is referenced in a number of IANA registries. These include: RFC2460 is referenced in a number of IANA registries. These include:
o Internet Protocol Version 6 (IPv6) Parameters [IANA-6P] o Internet Protocol Version 6 (IPv6) Parameters [IANA-6P]
o Assigned Internet Protocol Numbers [IANA-PN] o Assigned Internet Protocol Numbers [IANA-PN]
o ONC RPC Network Identifiers (netids) [IANA-NI]
o Technical requirements for authoritative name servers [IANA-NS]
o Network Layer Protocol Identifiers (NLPIDs) of Interest
[IANA-NL]
o Protocol Registries [IANA-PR]
o Structure of Management Information (SMI) Numbers (MIB Module
Registrations) [IANA-MI]
The IANA should update these references to point to this document. The IANA should update these references to point to this document.
10. Security Considerations 10. Security Considerations
The security features of IPv6 are described in the Security IPv6, from the viewpoint of the basic format and transmission of
Architecture for the Internet Protocol [RFC4301]. packets, has security properties similar to IPv4. Risks of
corruption, forgery, and interception of packets, resulting in the
exposure of private information, may may be mitigated by use of the
Security Architecture for the Internet Protocol [RFC4301] or
encryption at higher layers of the protocol stack.
11. Acknowledgments 11. Acknowledgments
The authors gratefully acknowledge the many helpful suggestions of The authors gratefully acknowledge the many helpful suggestions of
the members of the IPng working group, the End-to-End Protocols the members of the IPng working group, the End-to-End Protocols
research group, and the Internet Community At Large. research group, and the Internet Community At Large.
The authors would also like to acknowledge the authors of the The authors would also like to acknowledge the authors of the
updating RFCs that were incorporated in this version of the document updating RFCs that were incorporated in this version of the document
to move the IPv6 specification to Internet Standard. They are Joe to move the IPv6 specification to Internet Standard. They are Joe
skipping to change at page 28, line 30 skipping to change at page 29, line 10
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] [I-D.ietf-6man-rfc4291bis]
Hinden, R. and D. Deering, "IP Version 6 Addressing Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-6man-rfc4291bis-03 (work in Architecture", draft-ietf-6man-rfc4291bis-04 (work in
progress), June 2016. progress), September 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 29, line 26 skipping to change at page 29, line 50
12.2. Informative References 12.2. Informative References
[IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", [IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml>. ipv6-parameters.xhtml>.
[IANA-EH] "IPv6 Extension Header Types", [IANA-EH] "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters/ipv6- <https://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#extension-header>. parameters.xhtml#extension-header>.
[IANA-MI] "Structure of Management Information (SMI) Numbers (MIB
Module Registrations)", < http://www.iana.org/assignments/
smi-numbers/smi-numbers.xhtml>.
[IANA-NI] "ONC RPC Network Identifiers (netids)",
<http://www.iana.org/assignments/rpc-netids/
rpc-netids.xhtml>.
[IANA-NL] "Network Layer Protocol Identifiers (NLPIDs) of Interest",
<http://www.iana.org/assignments/nlpids/nlpids.xhtml>.
[IANA-NS] "Technical requirements for authoritative name servers",
<https://www.iana.org/help/nameserver-requirements>.
[IANA-PN] "Assigned Internet Protocol Numbers", [IANA-PN] "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/ <https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. protocol-numbers.xhtml>.
[IANA-PR] "Protocol Registries", <https://www.iana.org/protocols>.
[IANA-RH] "IANA Routing Types Parameter Registry", [IANA-RH] "IANA Routing Types Parameter Registry",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-3>. ipv6-parameters.xhtml#ipv6-parameters-3>.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<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
skipping to change at page 33, line 48 skipping to change at page 34, 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
07) 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.
07) Added paragraph to Section 4 to clarify how Extension Headers
are numbered and which are upper-layer headers.
07) Moved the text regarding network duplicated fragments to the
received fragment error section.
07) Added clarification that no ICMP error message should be sent
if overlapping fragments are received.
07) Revised the text in Section 4.8 regarding new hop-by-hop
options and new Extension headers to be closer to the -05
version.
07) Added additional registries to the IANA Considerations
section that IANA needs to update.
07) Editorial changes.
06) Added the Routing Header to the list required extension 06) Added the Routing Header to the list required extension
headers that a full implementation includes. headers that a full implementation includes.
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.
skipping to change at page 36, line 16 skipping to change at page 37, line 32
recommendations for defining new Extension headers and recommendations for defining new Extension headers and
options options
RFC7045: The changes were to add a reference to RFC7045, RFC7045: The changes were to add a reference to RFC7045,
change the requirement for processing the hop-by-hop change the requirement for processing the hop-by-hop
option to a should, and added a note that due to option to a should, and added a note that due to
performance restrictions some nodes won't process the Hop- performance restrictions some nodes won't process the Hop-
by-Hop Option header. by-Hop Option header.
RFC7112: The changes were to revise the Fragmentation RFC7112: The changes were to revise the Fragmentation
Section to require that all headers through the first Section (Section 4.5) to require that all headers through
Upper-Layer Header are in the first fragment. This the first Upper-Layer Header are in the first fragment.
changed the text describing how packets are fragmented and This changed the text describing how packets are
reassembled and added a new error case. fragmented and reassembled and added a new error case.
06) Editorial changes. 06) Editorial changes.
05) The purpose of this draft is to incorporate the updates 05) The purpose of this draft is to incorporate the updates
dealing with fragmentation as defined in RFC5722 and RFC6946. dealing with fragmentation as defined in RFC5722 and RFC6946.
Note: The issue relating to the handling of exact duplicate Note: The issue relating to the handling of exact duplicate
fragments identified on the mailing list is left open. fragments identified on the mailing list is left open.
05) Fix text in the end of Section 4.0 to correct the number of 05) Fix text in the end of Section 4 to correct the number of
extension headers defined in this document. extension headers defined in this document.
05) Editorial changes. 05) Editorial changes.
04) The purpose of this draft is to update the document to 04) The purpose of this draft is to update the document to
incorporate the update made by RFC6935 "UDP Checksums for incorporate the update made by RFC6935 "UDP Checksums for
Tunneled Packets". Tunneled Packets".
04) Remove Routing (Type 0) header from the list of required 04) Remove Routing (Type 0) header from the list of required
extension headers. extension headers.
skipping to change at page 37, line 16 skipping to change at page 38, line 35
document to resolve the open Errata on RFC2460. document to resolve the open Errata on RFC2460.
Errata ID: 2541: This errata notes that RFC2460 didn't Errata ID: 2541: This errata notes that RFC2460 didn't
update RFC2205 when the length of the Flow Label was update RFC2205 when the length of the Flow Label was
changed from 24 to 20 bits from RFC1883. This issue was changed from 24 to 20 bits from RFC1883. This issue was
resolved in RFC6437 where the Flow Label is defined. This resolved in RFC6437 where the Flow Label is defined. This
draft now references RFC6437. No change is required. draft now references 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 doesn't handle the case of a forwarding node receiving a
packet with a zero Hop Limit. This is fixed in packet with a zero Hop Limit. This is fixed in Section 3
Section 3.0 of this draft. Note: No change was made of this draft. Note: No change was made regarding host
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].
 End of changes. 28 change blocks. 
82 lines changed or deleted 151 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/