draft-hinden-6man-rfc2460bis-06.txt   draft-hinden-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 23, 2016 September 20, 2015 Expires: March 31, 2016 September 28, 2015
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-hinden-6man-rfc2460bis-06 draft-hinden-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),
also sometimes referred to as IP Next Generation or IPng. It also sometimes referred to as IP Next Generation or IPng. It
obsoletes RFC2460 obsoletes RFC2460
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 23, 2016. This Internet-Draft will expire on March 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 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 . . . . . . . . . . . . . . . . . 8 4.1. Extension Header Order . . . . . . . . . . . . . . . . . 9
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . 21 4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22
4.8. Defining New Extention Headers and Options . . . . . . . 22 4.8. Defining New Extention 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 . . . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Formatting Guidelines for Options . . . . . . . . . 29 Appendix A. Formatting Guidelines for Options . . . . . . . . . 30
Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 32 Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 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 [RFC2373]. semantics of IPv6 addresses are specified separately in
The IPv6 version of ICMP, which all IPv6 implementations are required [I-D.hinden-6man-rfc4291bis]. The IPv6 version of ICMP, which all
to include, is specified in [RFC2463] IPv6 implementations are required to include, is specified in
[RFC4443]
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
node a device that implements IPv6. node a device that implements IPv6.
router a node that forwards IPv6 packets not explicitly router a node that forwards IPv6 packets not explicitly
skipping to change at page 6, line 5 skipping to change at page 6, line 8
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
[RFC1700] et seq. [IANA-PN].
Hop Limit 8-bit unsigned integer. Decremented by 1 by Hop Limit 8-bit unsigned integer. Decremented by 1 by
each node that forwards the packet. The each node that forwards the packet. The
packet is discarded if Hop Limit is packet is discarded if Hop Limit is
decremented to zero, or is received with a decremented to zero, or is received with a
zero Hop Limit. zero Hop Limit.
Source Address 128-bit address of the originator of the Source Address 128-bit address of the originator of the
packet. See [RFC2373]. packet. See [I-D.hinden-6man-rfc4291bis].
Destination Address 128-bit address of the intended recipient of Destination Address 128-bit address of the intended recipient of
the packet (possibly not the ultimate the packet (possibly not the ultimate
recipient, if a Routing header is present). recipient, if a Routing header is present).
See [RFC2373] and section 4.4. See [I-D.hinden-6man-rfc4291bis] and section
4.4.
4. IPv6 Extension Headers 4. IPv6 Extension Headers
In IPv6, optional internet-layer information is encoded in separate In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the upper- headers that may be placed between the IPv6 header and the upper-
layer header in a packet. There are a small number of such extension layer header in a packet. There are a small number of such extension
headers, each identified by a distinct Next Header value. As headers, each identified by a distinct Next Header value. As
illustrated in these examples, an IPv6 packet may carry zero, one, or illustrated in these examples, an IPv6 packet may carry zero, one, or
more extension headers, each identified by the Next Header field of more extension headers, each identified by the Next Header field of
the preceding header: the preceding header:
skipping to change at page 8, line 27 skipping to change at page 8, line 48
A full implementation of IPv6 includes implementation of the A full implementation of IPv6 includes implementation of the
following extension headers: following extension headers:
Hop-by-Hop Options Hop-by-Hop Options
Fragment Fragment
Destination Options Destination Options
Authentication Authentication
Encapsulating Security Payload Encapsulating Security Payload
The first three are specified in this document; the last two are The first three are specified in this document; the last two are
specified in [RFC2402] and [RFC2406], respectively. specified in [RFC4302] and [RFC4303], respectively.
4.1. Extension Header Order 4.1. Extension Header Order
When more than one extension header is used in the same packet, it is When more than one extension header is used in the same packet, it is
recommended that those headers appear in the following order: recommended that those headers appear in the following order:
IPv6 header IPv6 header
Hop-by-Hop Options header Hop-by-Hop Options header
Destination Options header (note 1) Destination Options header (note 1)
Routing header Routing header
skipping to change at page 9, line 7 skipping to change at page 9, line 26
Encapsulating Security Payload header (note 2) Encapsulating Security Payload header (note 2)
Destination Options header (note 3) Destination Options header (note 3)
upper-layer header upper-layer header
note 1: for options to be processed by the first destination that note 1: for options to be processed by the first destination that
appears in the IPv6 Destination Address field plus appears in the IPv6 Destination Address field plus
subsequent destinations listed in the Routing header. subsequent destinations listed in the Routing header.
note 2: additional recommendations regarding the relative order of note 2: additional recommendations regarding the relative order of
the Authentication and Encapsulating Security Payload the Authentication and Encapsulating Security Payload
headers are given in [RFC2406]. headers are given in [RFC4303].
note 3: for options to be processed only by the final destination note 3: for options to be processed only by the final destination
of the packet. of the packet.
Each extension header should occur at most once, except for the Each extension header should occur at most once, except for the
Destination Options header which should occur at most twice (once Destination Options header which should occur at most twice (once
before a Routing header and once before the upper-layer header). before a Routing header and once before the upper-layer header).
If the upper-layer header is another IPv6 header (in the case of IPv6 If the upper-layer header is another IPv6 header (in the case of IPv6
being tunneled over or encapsulated in IPv6), it may be followed by being tunneled over or encapsulated in IPv6), it may be followed by
skipping to change at page 12, line 25 skipping to change at page 12, line 45
| | | |
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the Hop-by-Hop Options immediately following the Hop-by-Hop Options
header. Uses the same values as the IPv4 header. Uses the same values as the IPv4
Protocol field [RFC1700] et seq. Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by- Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by-
Hop Options header in 8-octet units, not Hop Options header in 8-octet units, not
including the first 8 octets. including the first 8 octets.
Options Variable-length field, of length such that the Options Variable-length field, of length such that the
complete Hop-by-Hop Options header is an complete Hop-by-Hop Options header is an
integer multiple of 8 octets long. Contains integer multiple of 8 octets long. Contains
one or more TLV-encoded options, as described one or more TLV-encoded options, as described
in section 4.2. in section 4.2.
skipping to change at page 13, line 18 skipping to change at page 13, line 40
| | | |
. . . .
. type-specific data . . type-specific data .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. immediately following the Routing header.
Uses the same values as the IPv4 Protocol Uses the same values as the IPv4 Protocol
field [RFC1700] et seq. field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the Routing Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the header in 8-octet units, not including the
first 8 octets. first 8 octets.
Routing Type 8-bit identifier of a particular Routing Routing Type 8-bit identifier of a particular Routing
header variant. header variant.
Segments Left 8-bit unsigned integer. Number of route Segments Left 8-bit unsigned integer. Number of route
segments remaining, i.e., number of explicitly segments remaining, i.e., number of explicitly
skipping to change at page 14, line 29 skipping to change at page 15, line 4
IPv4, fragmentation in IPv6 is performed only by source nodes, not by IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path -- see section 5.) The routers along a packet's delivery path -- see section 5.) The
Fragment header is identified by a Next Header value of 44 in the Fragment header is identified by a Next Header value of 44 in the
immediately preceding header, and has the following format: immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M| | Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the initial header Next Header 8-bit selector. Identifies the initial header
type of the Fragmentable Part of the original type of the Fragmentable Part of the original
packet (defined below). Uses the same values packet (defined below). Uses the same values
as the IPv4 Protocol field [RFC1700] et seq. as the IPv4 Protocol field [IANA-PN].
Reserved 8-bit reserved field. Initialized to zero for Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception. transmission; ignored on reception.
Fragment Offset 13-bit unsigned integer. The offset, in Fragment Offset 13-bit unsigned integer. The offset, in
8-octet units, of the data following this 8-octet units, of the data following this
header, relative to the start of the header, relative to the start of the
Fragmentable Part of the original packet. Fragmentable Part of the original packet.
Res 2-bit reserved field. Initialized to zero for Res 2-bit reserved field. Initialized to zero for
skipping to change at page 21, line 5 skipping to change at page 21, line 31
| | | |
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the Destination Options immediately following the Destination Options
header. Uses the same values as the IPv4 header. Uses the same values as the IPv4
Protocol field [RFC1700] et seq. 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.
Options Variable-length field, of length such that the Options Variable-length field, of length such that the
complete Destination Options header is an complete Destination Options header is an
integer multiple of 8 octets long. Contains integer multiple of 8 octets long. Contains
one or more TLV-encoded options, as described one or more TLV-encoded options, as described
in section 4.2. in section 4.2.
skipping to change at page 22, line 45 skipping to change at page 23, line 24
| | | |
. . . .
. Header Specific Data . . Header Specific Data .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC1700] et seq. 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
skipping to change at page 26, line 21 skipping to change at page 26, line 41
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 [RFC2463] 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.
8.2. Maximum Packet Lifetime 8.2. Maximum Packet Lifetime
skipping to change at page 27, line 39 skipping to change at page 28, line 15
and Routing header from the received packet have been verified and Routing header from the received packet have been verified
by the responder. by the responder.
9. IANA Considerations 9. IANA Considerations
None. None.
10. Security Considerations 10. Security Considerations
The security features of IPv6 are described in the Security The security features of IPv6 are described in the Security
Architecture for the Internet Protocol [RFC2401]. Architecture for the Internet Protocol [RFC4301].
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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI [I-D.hinden-6man-rfc4291bis]
10.17487/RFC0791, September 1981, Hinden, B. and S. Deering, "IP Version 6 Addressing
<http://www.rfc-editor.org/info/rfc791>. Architecture", draft-hinden-6man-rfc4291bis-00 (work in
progress), September 2015.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<http://www.rfc-editor.org/info/rfc1700>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
<http://www.rfc-editor.org/info/rfc2373>.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, DOI 10.17487/RFC2401,
November 1998, <http://www.rfc-editor.org/info/rfc2401>.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, DOI 10.17487/RFC2402, November 1998,
<http://www.rfc-editor.org/info/rfc2402>.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November
1998, <http://www.rfc-editor.org/info/rfc2406>.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, DOI 10.17487/RFC2463,
December 1998, <http://www.rfc-editor.org/info/rfc2463>.
[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>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, DOI
10.17487/RFC4443, March 2006,
<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>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, DOI 10.17487/
RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
12.2. Informative References 12.2. Informative References
[IANA-PN] "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>.
[IANA-RH] "IANA Routing Types Parameter Registry", [IANA-RH] "IANA Routing Types Parameter Registry",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-3>. ipv6-parameters.xhtml#ipv6-parameters-3>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[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
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for [RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <http://www.rfc-editor.org/info/rfc5871>. May 2010, <http://www.rfc-editor.org/info/rfc5871>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>. <http://www.rfc-editor.org/info/rfc6936>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, DOI 10.17487/
RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
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 32, line 46 skipping to change at page 33, line 46
| | | |
+ 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. Numbers identify
the Internet-Draft version in which the change was made. the Internet-Draft version in which the change was made.
07) The purpose of this draft is to update references to current
versions and assign references to normative and informative.
07) Editorial changes.
06) The purpose of this draft is to incorporate the updates 06) The purpose of this draft is to incorporate the updates
dealing with Extension headers as defined in RFC6564, dealing with Extension headers as defined in RFC6564,
RFC7045, and RFC7112. The changes include: RFC7045, and RFC7112. The changes include:
RFC6564: Added new Section 4.8 that describe RFC6564: Added new Section 4.8 that describe
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 to require that all headers through the first
Upper-Layer Header are in the first fragment. This Upper-Layer Header are in the first fragment. This
changed how packets were fragmented and reassembled and changed the text describing how packets are fragmented and
added a new error case. 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.0 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.
04) Editorial changes. 04) Editorial changes.
--------------------------------------------------------
03) The purpose of this draft is to update the document for the 03) The purpose of this draft is to update the document for the
deprecation of the RH0 Routing Header as specified in RFC5095 deprecation of the RH0 Routing Header as specified in RFC5095
and the allocations guidelines for routing headers as and the allocations guidelines for routing headers as
specified in RFC5871. Both of these RFCs updated RFC2460. specified in RFC5871. Both of these RFCs updated RFC2460.
--------------------------------------------------------
02) The purpose of this version of the draft is to update the 02) The purpose of this version of the draft is to update the
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.0 of this draft. Note: No change was made Section 3.0 of this draft. Note: No change was made
regarding host behaviour. regarding host 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
Stephen E. Deering Stephen E. Deering
Retired Retired
Vancouver, British Columbia Vancouver, British Columbia
Canada Canada
Robert M. Hinden Robert M. Hinden
Check Point Software Check Point Software
959 Skyway Road 959 Skyway Road
 End of changes. 41 change blocks. 
87 lines changed or deleted 82 lines changed or added

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