draft-ietf-6man-rfc2460bis-12.txt   draft-ietf-6man-rfc2460bis-13.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: November 17, 2017 May 16, 2017 Expires: November 20, 2017 May 19, 2017
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-12 draft-ietf-6man-rfc2460bis-13
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 November 17, 2017. This Internet-Draft will expire on November 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12
4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14
4.6. Destination Options Header . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 24
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25
8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26
8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27
8.4. Responding to Packets Carrying Routing Headers . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Formatting Guidelines for Options . . . . . . . . . 33 Appendix A. Formatting Guidelines for Options . . . . . . . . . 33
Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36 Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36
B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39 B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39
skipping to change at page 22, line 36 skipping to change at page 22, line 36
contains 59, those octets must be ignored, and passed on unchanged if contains 59, those octets must be ignored, and passed on unchanged if
the packet is forwarded. the packet is forwarded.
4.8. Defining New Extension Headers and Options 4.8. Defining New Extension Headers and Options
Defining new IPv6 extension headers is not recommended, unless there Defining new IPv6 extension headers is not recommended, unless there
are no existing IPv6 extension headers that can be used by specifying are no existing IPv6 extension headers that can be used by specifying
a new option for that IPv6 extension header. A proposal to specify a a new option for that IPv6 extension header. A proposal to specify a
new IPv6 extension header must include a detailed technical new IPv6 extension header must include a detailed technical
explanation of why an existing IPv6 extension header can not be used explanation of why an existing IPv6 extension header can not be used
for the desired new function. for the desired new function. See [RFC6564] for additional
background information.
Note: New extension headers that require hop-by-hop behavior must not Note: New extension headers that require hop-by-hop behavior must not
be defined because, as specified in Section 4 of this document, the be defined because, as specified in Section 4 of this document, the
only Extension Header that has hop-by-hop behavior is the Hop-by-Hop only Extension Header that has hop-by-hop behavior is the Hop-by-Hop
Options header. Options header.
New hop-by-hop options are not recommended because nodes may be New hop-by-hop options are not recommended because nodes may be
configured to ignore the Hop-by-Hop Option header, drop packets configured to ignore the Hop-by-Hop Option header, drop packets
containing a hop-by-hop header, or assign packets containing a hop- containing a hop-by-hop header, or assign packets containing a hop-
by-hop header to a slow processing path. Designers considering by-hop header to a slow processing path. Designers considering
skipping to change at page 23, line 35 skipping to change at page 23, line 38
Hdr Ext Len 8-bit unsigned integer. Length of the Hdr Ext Len 8-bit unsigned integer. Length of the
Destination Options header in 8-octet units, Destination Options header in 8-octet units,
not including the first 8 octets. not including the first 8 octets.
Header Specific Data Variable-length field. Fields specific to Header Specific Data Variable-length field. Fields specific to
the extension header. the extension header.
5. Packet Size Issues 5. Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280 IPv6 requires that every link in the internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet octets or greater. This is known as the IPv6 minimum link MTU. On
packet in one piece, link-specific fragmentation and reassembly must any link that cannot convey a 1280-octet packet in one piece, link-
be provided at a layer below IPv6. specific fragmentation and reassembly must be provided at a layer
below IPv6.
Links that have a configurable MTU (for example, PPP links [RFC1661]) Links that have a configurable MTU (for example, PPP links [RFC1661])
must be configured to have an MTU of at least 1280 octets; it is must be configured to have an MTU of at least 1280 octets; it is
recommended that they be configured with an MTU of 1500 octets or recommended that they be configured with an MTU of 1500 octets or
greater, to accommodate possible encapsulations (i.e., tunneling) greater, to accommodate possible encapsulations (i.e., tunneling)
without incurring IPv6-layer fragmentation. without incurring IPv6-layer fragmentation.
From each link to which a node is directly attached, the node must be From each link to which a node is directly attached, the node must be
able to accept packets as large as that link's MTU. able to accept packets as large as that link's MTU.
skipping to change at page 32, line 38 skipping to change at page 32, line 48
<http://www.rfc-editor.org/info/rfc5095>. <http://www.rfc-editor.org/info/rfc5095>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, DOI 10.17487/RFC5722, December 2009, RFC 5722, DOI 10.17487/RFC5722, December 2009,
<http://www.rfc-editor.org/info/rfc5722>. <http://www.rfc-editor.org/info/rfc5722>.
[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>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<http://www.rfc-editor.org/info/rfc6564>.
[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>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, DOI 10.17487/RFC6946, May 2013, 6946, DOI 10.17487/RFC6946, May 2013,
<http://www.rfc-editor.org/info/rfc6946>. <http://www.rfc-editor.org/info/rfc6946>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
skipping to change at page 38, line 27 skipping to change at page 38, line 27
fragment. fragment.
o In Section 4.5 added clarification noting that some fields in the o In Section 4.5 added clarification noting that some fields in the
IPv6 header may also vary across the fragments being reassembled IPv6 header may also vary across the fragments being reassembled
and that other specifications may provide additional instructions and that other specifications may provide additional instructions
for how they should be reassembled. For example, Section 5.3 of for how they should be reassembled. For example, Section 5.3 of
[RFC3168]. [RFC3168].
o Incorporated the update from RFC6564 to add a new Section 4.8 that o Incorporated the update from RFC6564 to add a new Section 4.8 that
describes recommendations for defining new Extension headers and describes recommendations for defining new Extension headers and
options options.
o Added text to Section 5 to define "IPv6 minimum link MTU".
o Simplify the text in Section 6 about Flow Labels and remove o Simplify the text in Section 6 about Flow Labels and remove
Appendix A, and instead point to the current specifications of the Appendix A, and instead point to the current specifications of the
IPv6 Flow Label field as defined in [RFC6437] and the Traffic IPv6 Flow Label field as defined in [RFC6437] and the Traffic
Class as defined in [RFC2474] and [RFC3168]. Class as defined in [RFC2474] and [RFC3168].
o Incorporate the update in made by RFC6935 "UDP Checksums for o Incorporate the update in made by RFC6935 "UDP Checksums for
Tunneled Packets" in Section 8. Added an exception to the default Tunneled Packets" in Section 8. Added an exception to the default
behaviour for the handling of handling UDP packets with zero behaviour for the handling of handling UDP packets with zero
checksums for tunnels. checksums for tunnels.
o Add instruction to the IANA Considerations section to change o Add instruction to Section 9 "IANA Considerations" to change
references to RFC2460 to this document references to RFC2460 to this document
o Revised and expanded the Security Consideration section. o Revised and expanded Section 10 "Security Considerations".
o Add a paragraph to the acknowledgement section acknowledging the o Add a paragraph to the acknowledgement section acknowledging the
authors of the updating documents authors of the updating documents
o Update references to current versions and assign references to o Update references to current versions and assign references to
normative and informative. normative and informative.
o Changes to resolve the open Errata on RFC2460. These are: o Changes to resolve the open Errata on RFC2460. These are:
Errata ID: 2541: This errata notes that RFC2460 didn't update Errata ID: 2541: This errata notes that RFC2460 didn't update
skipping to change at page 39, line 30 skipping to change at page 39, line 30
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication Publication
This section describes change history made in each Internet Draft This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made. Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
13) Added link to reference to RFC6564 in Section 4.8.
13) Added text to Section 5 to define "IPv6 minimum link MTU".
13) Editorial changes.
12) Editorial changes (remove old duplicate paragraph). 12) Editorial changes (remove old duplicate paragraph).
11) In Section 4.5 added clarification noting that some fields in 11) In Section 4.5 added clarification noting that some fields in
the IPv6 header may also vary across the fragments being the IPv6 header may also vary across the fragments being
reassembled and that other specifications may provide reassembled and that other specifications may provide
additional instructions for how they should be reassembled. additional instructions for how they should be reassembled.
For example, Section 5.3 of [RFC3168]. For example, Section 5.3 of [RFC3168].
11) In Section 4 restructured text including separated behaviors 11) In Section 4 restructured text including separated behaviors
of extension headers and the hop-by-hop option header, of extension headers and the hop-by-hop option header,
 End of changes. 12 change blocks. 
12 lines changed or deleted 27 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/