draft-ietf-6man-rfc2460bis-01.txt   draft-ietf-6man-rfc2460bis-02.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: May 5, 2016 November 2, 2015 Expires: June 18, 2016 December 16, 2015
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-01 draft-ietf-6man-rfc2460bis-02
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 May 5, 2016. This Internet-Draft will expire on June 18, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 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 Extention 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 . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 15, line 44 skipping to change at page 15, line 44
source addresses, or one for each active (source address, source addresses, or one for each active (source address,
destination address) combination. destination address) combination.
The initial, large, unfragmented packet is referred to as the The initial, large, unfragmented packet is referred to as the
"original packet", and it is considered to consist of three parts, as "original packet", and it is considered to consist of three parts, as
illustrated: illustrated:
original packet: original packet:
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
| Per-Fragment | Extention & Upper-Layer | Fragmentable | | Per-Fragment | Extension & Upper-Layer | Fragmentable |
| Headers | Headers | Part | | Headers | Headers | Part |
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
The Per-Fragment Headers consists of the IPv6 header plus any The Per-Fragment Headers consists of the IPv6 header plus any
extension headers that must be processed by nodes en route to the extension headers that must be processed by nodes en route to the
destination, that is, all headers up to and including the Routing destination, that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present, header if present, else the Hop-by-Hop Options header if present,
else no extension headers. else no extension headers.
The Ext Hdrs are all other extension headers that are not included The Extension Headers are all other extension headers that are not
in the Per-Fragment headers part of the packet. For this purpose, included in the Per-Fragment headers part of the packet. For this
the Encapsulating Security Payload (ESP) is not considered an purpose, the Encapsulating Security Payload (ESP) is not
extension headers. The Upper-Layer Header is the first upper- considered an extension headers. The Upper-Layer Header is the
layer header that is not an IPv6 extension header. Examples of first upper-layer header that is not an IPv6 extension header.
upper-layer headers include TCP, UDP, IPv4, IPv6, ICMPv6, and as Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
noted ESP. ICMPv6, and as noted ESP.
The Fragmentable Part consists of the rest of the packet after the The Fragmentable Part consists of the rest of the packet after the
upper-layer header or after any header (i.e., initial IPv6 header upper-layer header or after any header (i.e., initial IPv6 header
or extension header) that contains a Next Header value of No Next or extension header) that contains a Next Header value of No Next
Header. Header.
The Fragmentable Part of the original packet is divided into The Fragmentable Part of the original packet is divided into
fragments. The lengths of the fragments must be chosen such that the fragments. The lengths of the fragments must be chosen such that the
resulting fragment packets fit within the MTU of the path to the resulting fragment packets fit within the MTU of the path to the
packets' destination(s). Each complete fragment, except possibly the packets' destination(s). Each complete fragment, except possibly the
skipping to change at page 20, line 5 skipping to change at page 20, line 5
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 If any of the fragments being reassembled overlaps with any
other fragments being reassembled for the same packet, other fragments being reassembled for the same packet,
reassembly of that packet must be abandoned and all the reassembly of that packet must be abandoned and all the
fragments that have been received for that packet must be fragments that have been received for that packet must be
discarded. discarded.
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
skipping to change at page 22, line 32 skipping to change at page 22, line 37
4.7. No Next Header 4.7. No Next Header
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 Extention 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. 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.
New hop-by-hop options are not recommended because, due to New hop-by-hop options are not recommended because, due to
performance restrictions, nodes may ignore the Hop-by-Hop Option performance restrictions, nodes may ignore the Hop-by-Hop Option
header, drop packets containing a hop-by-hop header, or assign header, drop packets containing a hop-by-hop header, or assign
packets containing a hop-by-hop header to a slow processing path. packets containing a hop-by-hop header to a slow processing path.
Designers considering defining new hop-by-hop options need to be Designers considering defining new hop-by-hop options need to be
aware of this likely behaviour. There has to a very clear aware of this likely behaviour. There has to a very clear
justification why any new hop-by-hop option is needed before it is justification why any new hop-by-hop option is needed before it is
standardized. standardized.
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
02) Added text to Section 4.8 "Defining New Extension Headers and
Options" clarifying why no new hop by hop extension headers
should be define.
02) Added text to Fragment Header process on handling exact
duplicate fragments.
02) Editorial changes.
01) Added text that Extension headers must never be inserted by 01) Added text that Extension headers must never be inserted by
any node other than the source of the packet. any node other than the source of the packet.
01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop 01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop
header. header.
01) Added text that the Data Transmission Order is the same as 01) Added text that the Data Transmission Order is the same as
IPv4 as defined in RFC791. IPv4 as defined in RFC791.
01) Updated the Fragmentation header text to correct the 01) Updated the Fragmentation header text to correct the
 End of changes. 11 change blocks. 
15 lines changed or deleted 32 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/