draft-ietf-6man-rfc2460bis-11.txt   draft-ietf-6man-rfc2460bis-12.txt 
Network Working Group S. Deering Network Working Group S. Deering
Internet-Draft Retired Internet-Draft Retired
Obsoletes: 2460 (if approved) R. Hinden Obsoletes: 2460 (if approved) R. Hinden
Intended status: Standards Track Check Point Software Intended status: Standards Track Check Point Software
Expires: October 30, 2017 April 28, 2017 Expires: November 17, 2017 May 16, 2017
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-11 draft-ietf-6man-rfc2460bis-12
Abstract Abstract
This document specifies version 6 of the Internet Protocol (IPv6). This document specifies version 6 of the Internet Protocol (IPv6).
It obsoletes RFC2460 It obsoletes RFC2460
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2017. This Internet-Draft will expire on November 17, 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 34 skipping to change at page 2, line 34
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12
4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 12
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14
4.6. Destination Options Header . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 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 31 skipping to change at page 22, line 31
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
New extension headers that require hop-by-hop behavior must not be
defined because, as specified in Section 4 of this document, the only
Extension Header that has hop-by-hop behavior is the Hop-by-Hop
Options header.
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 header 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.
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.
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
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,
removed "examine" from first paragraph about extension removed "examine" from first paragraph about extension
headers, and removed reference to RFC7045 because "examine" headers, and removed reference to RFC7045 because "examine"
was removed (RFC7045 is referenced in Security was removed (RFC7045 is referenced in Security
Considerations). Also removed "including the source and Considerations). Also removed "including the source and
destination nodes" from paragraph about the hop-by-hop destination nodes" from paragraph about the hop-by-hop
options header. options header.
11) Revised Section 4.8 to make it closer to the update done by 11) Revised Section 4.8 to make it closer to the update done by
RFC6554 that updated it and reordered the paragraphs. RFC6554 that updated it and reordered the paragraphs.
11) Reordered items in Appendix B "Changes Since RFC2460" match 11) Reordered items in Appendix B "Changes Since RFC2460" to
order of the document. match the order of the document.
11) Editorial changes. 11) Editorial changes.
10) Revised and expanded Security Consideration Section based on 10) Revised and expanded Security Consideration Section based on
IESG Discuss comments. IESG Discuss comments.
10) Editorial changes. 10) Editorial changes.
09) Based on results of IETF last call, changed text in Section 4 09) Based on results of IETF last call, changed text in Section 4
to add clarification that extension headers are not examined, to add clarification that extension headers are not examined,
 End of changes. 9 change blocks. 
14 lines changed or deleted 11 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/