< draft-ietf-6man-rfc2460bis-05.txt   draft-ietf-6man-rfc2460bis-06.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: December 30, 2016 June 28, 2016 Expires: March 17, 2017 September 13, 2016
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-05 draft-ietf-6man-rfc2460bis-06
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 December 30, 2016. This Internet-Draft will expire on March 17, 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 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 25 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24
8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26
8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26
8.4. Responding to Packets Carrying Routing Headers . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . 30 Appendix A. Formatting Guidelines for Options . . . . . . . . . 30
Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33 Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
skipping to change at page 3, line 38 skipping to change at page 3, line 38
o Improved Support for Extensions and Options o Improved Support for Extensions and Options
Changes in the way IP header options are encoded allows for Changes in the way IP header options are encoded allows for
more efficient forwarding, less stringent limits on the length more efficient forwarding, less stringent limits on the length
of options, and greater flexibility for introducing new options of options, and greater flexibility for introducing new options
in the future. in the future.
o Flow Labeling Capability o Flow Labeling Capability
A new capability is added to enable the labeling of sequences A new capability is added to enable the labeling of sequences
of packets for which the sender requests to be treated in the of packets that the sender requests to be treated in the
network as a single flow. network as a single flow.
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
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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:
Hop-by-Hop Options Hop-by-Hop Options
Fragment Fragment
Destination Options Destination Options
Routing
Authentication Authentication
Encapsulating Security Payload Encapsulating Security Payload
The first three are specified in this document; the last two are The first four are specified in this document; the last two are
specified in [RFC4302] and [RFC4303], respectively. The current list specified in [RFC4302] and [RFC4303], respectively. The current list
of IPv6 extension headers can be found at [IANA-EH]. of IPv6 extension headers can be found at [IANA-EH].
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
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.
If any of the fragments being reassembled overlaps with any
other fragments being reassembled for the same packet,
reassembly of that packet must be abandoned and all the
fragments that have been received for that packet must be
discarded.
It should be noted that fragments may be duplicated in the It should be noted that fragments may be duplicated in the
network. These exact duplicate fragments will be treated as network. These exact duplicate fragments will be treated as
overlapping fragments and handled as described in the previous overlapping fragments and handled as described in the previous
paragraph. An implementation may choose to detect this case paragraph. An implementation may choose to detect this case
and not drop the other fragments of the same packet. 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
skipping to change at page 20, line 51 skipping to change at page 20, line 45
65,535 octets, then that fragment must be discarded and an ICMP 65,535 octets, then that fragment must be discarded and an ICMP
Parameter Problem, Code 0, message should be sent to the source of Parameter Problem, Code 0, message should be sent to the source of
the fragment, pointing to the Fragment Offset field of the the fragment, pointing to the Fragment Offset field of the
fragment packet. fragment packet.
If the first fragment does not include all headers through an 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 an
ICMP Parameter Problem, Code 3, message should be sent to the ICMP Parameter Problem, Code 3, message should be sent to the
source of the fragment, with the Pointer field set to zero. source of the fragment, with the Pointer field set to zero.
If any of the fragments being reassembled overlaps with any other
fragments being reassembled for the same packet, reassembly of
that packet must be abandoned and all the fragments that have been
received for that packet must be discarded.
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
the reassembled packet. the reassembled packet.
skipping to change at page 22, line 44 skipping to change at page 22, line 44
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 No new extension headers that require hop-by-hop behavior should 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, due to New hop-by-hop options are not recommended because it is expected
performance restrictions, nodes may ignore the Hop-by-Hop Option that nodes along a packet's delivery path will only examine and
header, drop packets containing a hop-by-hop header, or assign process the hop-by-hop option header if explicitly configured to do
packets containing a hop-by-hop header to a slow processing path. so.
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.
Instead of defining new Extension Headers, it is recommended that the Defining new IPv6 extension headers is not recommended. Instead of
defining new Extension Headers, it is recommended that the
Destination Options header is used to carry optional information that Destination Options header is used to carry optional information that
need be examined only by a packet's destination node(s), because they need be examined only by a packet's destination node(s).
provide better handling and backward compatibility. Defining new
IPv6 extension headers is not recommended. There has to a very clear
justification why any new extension header is needed before it is
standardized.
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 28, line 33 skipping to change at page 28, line 30
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 S. Deering, "IP Version 6 Addressing Hinden, R. and D. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-6man-rfc4291bis-02 (work in Architecture", draft-ietf-6man-rfc4291bis-03 (work in
progress), April 2016. progress), June 2016.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981, 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
skipping to change at page 33, line 48 skipping to change at page 33, line 48
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. CHANGES SINCE RFC2460 Appendix B. CHANGES SINCE RFC2460
This memo has the following changes from RFC2460. Numbers identify This memo has the following changes from RFC2460. Numbers identify
the Internet-Draft version in which the change was made. the Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
06) Added the Routing Header to the list required extension
headers that a full implementation includes.
06) Moved the text in Section 4.5 regarding the handling of
received overlapping fragments to the list of error
conditions
06) Rewrote the text in Section 4.8 "Defining New Extension
Headers and Options" to be clearer and remove redundant text.
06) Editorial changes.
05) Changed requirement for HBH header from a should to a may, 05) Changed requirement for HBH header from a should to a may,
and added a note to indicate what is expected. 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
skipping to change at page 35, line 5 skipping to change at page 35, line 18
01) Updated the Fragmentation header text to correct the 01) Updated the Fragmentation header text to correct the
inclusion of AH and note no next header case. inclusion of AH and note no next header case.
01) Change terminology in Fragment header section from 01) Change terminology in Fragment header section from
"Unfragmentable Headers" to "Per-Fragment Headers". "Unfragmentable Headers" to "Per-Fragment Headers".
01) Removed paragraph in Section 5 that required including a 01) Removed paragraph in Section 5 that required including a
fragment header to outgoing packets if a ICMP Packet Too Big fragment header to outgoing packets if a ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. This is message reporting a Next-Hop MTU less than 1280. This is
based on the update in draft-ietf-6man-deprecate-atomfrag- based on the update in draft-ietf-6man-deprecate-atomfrag-
generation-03. generation.
01) Changed to Fragmentation Header section to clarify MTU 01) Changed to Fragmentation Header section to clarify MTU
restriction and 8-byte restrictions, and noting the restriction and 8-byte restrictions, and noting the
restriction on headers in first fragment. restriction on headers in first fragment.
01) Editorial changes. 01) Editorial changes.
00) Add instruction to the IANA to change references to RFC2460 00) Add instruction to the IANA to change references to RFC2460
to this document to this document
 End of changes. 17 change blocks. 
34 lines changed or deleted 39 lines changed or added

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