draft-ietf-6man-rfc2460bis-00.txt   draft-ietf-6man-rfc2460bis-01.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: April 20, 2016 October 18, 2015 Expires: May 5, 2016 November 2, 2015
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-00 draft-ietf-6man-rfc2460bis-01
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 April 20, 2016. This Internet-Draft will expire on May 5, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 4, line 9 skipping to change at page 4, line 9
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 semantics of IPv6 addresses are specified separately in
[I-D.hinden-6man-rfc4291bis]. The IPv6 version of ICMP, which all [I-D.hinden-6man-rfc4291bis]. The IPv6 version of ICMP, which all
IPv6 implementations are required to include, is specified in IPv6 implementations are required to include, is specified in
[RFC4443] [RFC4443]
The data transmission order for IPv6 is the same as for IPv4 as
defined in Appendix B of [RFC0791].
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
addressed to itself. [See Note below]. addressed to itself. [See Note below].
skipping to change at page 7, line 26 skipping to change at page 7, line 26
| Routing | TCP | | Routing | TCP |
+---------------+----------------+------------------------ +---------------+----------------+------------------------
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP | IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data | | | | header + data
| Next Header = | Next Header = | Next Header = | | Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP | | Routing | Fragment | TCP |
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
Extension headers must never be inserted by any node other than the
source of the packet. IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in
[RFC2473].
With one exception, extension headers are not processed by any node With one exception, extension headers are not processed by any node
along a packet's delivery path, until the packet reaches the node (or along a packet's delivery path, until the packet reaches the node (or
each of the set of nodes, in the case of multicast) identified in the each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header. Note: If an Destination Address field of the IPv6 header. Note: If an
intermediate forwarding node examines an extension header for any intermediate forwarding node examines an extension header for any
reason, it must do so in accordance with the provisions of [RFC7045]. reason, it must do so in accordance with the provisions of [RFC7045].
At the Destination node, normal demultiplexing on the Next Header At the Destination node, normal demultiplexing on the Next Header
field of the IPv6 header invokes the module to process the first field of the IPv6 header invokes the module to process the first
extension header, or the upper-layer header if no extension header is extension header, or the upper-layer header if no extension header is
present. The contents and semantics of each extension header present. The contents and semantics of each extension header
skipping to change at page 12, line 12 skipping to change at page 12, line 18
The PadN option is used to insert two or more octets of padding The PadN option is used to insert two or more octets of padding
into the Options area of a header. For N octets of padding, the into the Options area of a header. For N octets of padding, the
Opt Data Len field contains the value N-2, and the Option Data Opt Data Len field contains the value N-2, and the Option Data
consists of N-2 zero-valued octets. consists of N-2 zero-valued octets.
Appendix A contains formatting guidelines for designing new options. Appendix A contains formatting guidelines for designing new options.
4.3. Hop-by-Hop Options Header 4.3. Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information The Hop-by-Hop Options header is used to carry optional information
that must be examined by every node along a packet's delivery path. that should be examined by every node along a packet's delivery path.
The Hop-by-Hop Options header is identified by a Next Header value of The Hop-by-Hop Options header is identified by a Next Header value of
0 in the IPv6 header, and has the following format: 0 in the IPv6 header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | | | Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Options . . Options .
. . . .
skipping to change at page 15, line 39 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:
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
| Unfragmentable | Extention & Upper-Layer | Fragmentable | | Per-Fragment | Extention & Upper-Layer | Fragmentable |
| Headers | Headers | Part | | Headers | Headers | Part |
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
The Unfragmentable 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 Ext Hdrs are all other extension headers that are not included
in the Unfragmentable headers part of the packet. For this in the Per-Fragment headers part of the packet. For this purpose,
purpose, the IP Authentication Header (AH) and the Encapsulating the Encapsulating Security Payload (ESP) is not considered an
Security Payload (ESP) are not considered extension headers. The extension headers. The Upper-Layer Header is the first upper-
Upper-Layer Header is the first upper-layer header that is not an layer header that is not an IPv6 extension header. Examples of
IPv6 extension header. Examples of upper-layer headers include upper-layer headers include TCP, UDP, IPv4, IPv6, ICMPv6, and as
TCP, UDP, IPv4, IPv6, ICMPv6, and as noted AH and ESP. 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. upper-layer header or after any header (i.e., initial IPv6 header
or extension header) that contains a Next Header value of No Next
Header.
The Fragmentable Part of the original packet is divided into The Fragmentable Part of the original packet is divided into
fragments, each, except possibly the last ("rightmost") one, being an fragments. The lengths of the fragments must be chosen such that the
integer multiple of 8 octets long. The fragments are transmitted in resulting fragment packets fit within the MTU of the path to the
separate "fragment packets" as illustrated: packets' destination(s). Each complete fragment, except possibly the
last ("rightmost") one, being an integer multiple of 8 octets long.
The fragments are transmitted in separate "fragment packets" as
illustrated:
original packet: original packet:
+-----------------+-----------------+--------+--------+-//-+--------+ +-----------------+-----------------+--------+--------+-//-+--------+
| Unfragmentable |Ext & Upper-Layer| first | second | | last | | Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |fragment|fragment|....|fragment| | Headers | Headers |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+ +-----------------+-----------------+--------+--------+-//-+--------+
fragment packets: fragment packets:
+------------------+---------+-------------------+----------+ +------------------+---------+-------------------+----------+
| Unfragmentable |Fragment | Ext & Upper-Layer | first | | Per-Fragment |Fragment | Ext & Upper-Layer | first |
| Headers | Header | Headers | fragment | | Headers | Header | Headers | fragment |
+------------------+---------+-------------------+----------+ +------------------+---------+-------------------+----------+
+------------------+--------+-------------------------------+ +------------------+--------+-------------------------------+
| Unfragmentable |Fragment| second | | Per-Fragment |Fragment| second |
| Headers | Header | fragment | | Headers | Header | fragment |
+------------------+--------+-------------------------------+ +------------------+--------+-------------------------------+
o o
o o
o o
+------------------+--------+----------+ +------------------+--------+----------+
| Unfragmentable |Fragment| last | | Per-Fragment |Fragment| last |
| Headers | Header | fragment | | Headers | Header | fragment |
+------------------+--------+----------+ +------------------+--------+----------+
The first fragment packet is composed of: The first fragment packet is composed of:
(1) The Unfragmentable Headers of the original packet, with the (1) The Per-Fragment Headers of the original packet, with the
Payload Length of the original IPv6 header changed to contain the Payload Length of the original IPv6 header changed to contain the
length of this fragment packet only (excluding the length of the length of this fragment packet only (excluding the length of the
IPv6 header itself), and the Next Header field of the last header IPv6 header itself), and the Next Header field of the last header
of the Unfragmentable Headers changed to 44. of the Per-Fragment Headers changed to 44.
(2) A Fragment header containing: (2) A Fragment header containing:
The Next Header value that identifies the first header after The Next Header value that identifies the first header after
the Unfragmentable Headers of the original packet. the Per-Fragment Headers of the original packet.
A Fragment Offset containing the offset of the fragment, in A Fragment Offset containing the offset of the fragment, in
8-octet units, relative to the start of the Fragmentable Part 8-octet units, relative to the start of the Fragmentable Part
of the original packet. The Fragment Offset of the first of the original packet. The Fragment Offset of the first
("leftmost") fragment is 0. ("leftmost") fragment is 0.
An M flag value of 1 as this is the first fragment. An M flag value of 1 as this is the first fragment.
The Identification value generated for the original packet. The Identification value generated for the original packet.
(3) Extension Headers, if any, and the Upper-Layer header. These (3) Extension Headers, if any, and the Upper-Layer header. These
headers must be in the first fragment. headers must be in the first fragment. Note: This restricts the
size of the headers through the Upper-Layer header to the MTU of
the path to the packets' destinations(s).
(4) The first fragment. (4) The first fragment.
The subsequent fragment packets are composed of: The subsequent fragment packets are composed of:
(1) The Unfragmentable Headers of the original packet, with the (1) The Per-Fragment Headers of the original packet, with the
Payload Length of the original IPv6 header changed to contain the Payload Length of the original IPv6 header changed to contain the
length of this fragment packet only (excluding the length of the length of this fragment packet only (excluding the length of the
IPv6 header itself), and the Next Header field of the last header IPv6 header itself), and the Next Header field of the last header
of the Unfragmentable Headers changed to 44. of the Per-Fragment Headers changed to 44.
(2) A Fragment header containing: (2) A Fragment header containing:
The Next Header value that identifies the first header after The Next Header value that identifies the first header after
the Unfragmentable Headers of the original packet. the Per-Fragment Headers of the original packet.
A Fragment Offset containing the offset of the fragment, in A Fragment Offset containing the offset of the fragment, in
8-octet units, relative to the start of the Fragmentable part 8-octet units, relative to the start of the Fragmentable part
of the original packet. of the original packet.
An M flag value of 0 if the fragment is the last ("rightmost") An M flag value of 0 if the fragment is the last ("rightmost")
one, else an M flag value of 1. one, else an M flag value of 1.
The Identification value generated for the original packet. The Identification value generated for the original packet.
(3) The fragment itself. (3) The fragment itself.
The lengths of the fragments must be chosen such that the resulting
fragment packets fit within the MTU of the path to the packets'
destination(s).
Fragments must not be created that overlap with any other fragments Fragments must not be created that overlap with any other fragments
created from the original packet. created from the original packet.
At the destination, fragment packets are reassembled into their At the destination, fragment packets are reassembled into their
original, unfragmented form, as illustrated: original, unfragmented form, as illustrated:
reassembled original packet: reassembled original packet:
+---------------+-----------------+---------+--------+-//--+--------+ +---------------+-----------------+---------+--------+-//--+--------+
| Unfragmentable|Ext & Upper-Layer| first | second | | last | | Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |frag data|fragment|.....|fragment| | Headers | Headers |frag data|fragment|.....|fragment|
+---------------+-----------------+---------+--------+-//--+--------+ +---------------+-----------------+---------+--------+-//--+--------+
The following rules govern reassembly: The following rules govern reassembly:
An original packet is reassembled only from fragment packets that An original packet is reassembled only from fragment packets that
have the same Source Address, Destination Address, and Fragment have the same Source Address, Destination Address, and Fragment
Identification. Identification.
The Unfragmentable Headers of the reassembled packet consists of The Per-Fragment Headers of the reassembled packet consists of all
all headers up to, but not including, the Fragment header of the headers up to, but not including, the Fragment header of the first
first fragment packet (that is, the packet whose Fragment Offset fragment packet (that is, the packet whose Fragment Offset is
is zero), with the following two changes: zero), with the following two changes:
The Next Header field of the last header of the Unfragmentable The Next Header field of the last header of the Per-Fragment
Headers is obtained from the Next Header field of the first Headers is obtained from the Next Header field of the first
fragment's Fragment header. fragment's Fragment header.
The Payload Length of the reassembled packet is computed from The Payload Length of the reassembled packet is computed from
the length of the Unfragmentable Headers and the length and the length of the Per-Fragment Headers and the length and
offset of the last fragment. For example, a formula for offset of the last fragment. For example, a formula for
computing the Payload Length of the reassembled original packet computing the Payload Length of the reassembled original packet
is: is:
PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last
where where
PL.orig = Payload Length field of reassembled packet. PL.orig = Payload Length field of reassembled packet.
PL.first = Payload Length field of first fragment packet. PL.first = Payload Length field of first fragment packet.
FL.first = length of fragment following Fragment header of FL.first = length of fragment following Fragment header of
first fragment packet. first fragment packet.
FO.last = Fragment Offset field of Fragment header of last FO.last = Fragment Offset field of Fragment header of last
fragment packet. fragment packet.
FL.last = length of fragment following Fragment header of FL.last = length of fragment following Fragment header of
last fragment packet. last fragment packet.
The Fragmentable Part of the reassembled packet is constructed The Fragmentable Part of the reassembled packet is constructed
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
skipping to change at page 23, line 51 skipping to change at page 24, line 28
A node must be able to accept a fragmented packet that, after A node must be able to accept a fragmented packet that, after
reassembly, is as large as 1500 octets. A node is permitted to reassembly, is as large as 1500 octets. A node is permitted to
accept fragmented packets that reassemble to more than 1500 octets. accept fragmented packets that reassemble to more than 1500 octets.
An upper-layer protocol or application that depends on IPv6 An upper-layer protocol or application that depends on IPv6
fragmentation to send packets larger than the MTU of a path should fragmentation to send packets larger than the MTU of a path should
not send packets larger than 1500 octets unless it has assurance that not send packets larger than 1500 octets unless it has assurance that
the destination is capable of reassembling packets of that larger the destination is capable of reassembling packets of that larger
size. size.
In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4), the
originating IPv6 node may receive an ICMP Packet Too Big message
reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40 for the
IPv6 header and 8 for the Fragment header), and smaller still if
additional extension headers are used.
6. Flow Labels 6. Flow Labels
The 20-bit Flow Label field in the IPv6 header is used by a source to The 20-bit Flow Label field in the IPv6 header is used by a source to
label sequences of packets to be treated in the network as a single label sequences of packets to be treated in the network as a single
flow. flow.
The current definition of the IPv6 Flow Label can be found in The current definition of the IPv6 Flow Label can be found in
[RFC6437]. [RFC6437].
7. Traffic Classes 7. Traffic Classes
skipping to change at page 28, line 26 skipping to change at page 28, line 34
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.hinden-6man-rfc4291bis] [I-D.hinden-6man-rfc4291bis]
Hinden, B. and S. Deering, "IP Version 6 Addressing Hinden, B. and S. Deering, "IP Version 6 Addressing
Architecture", draft-hinden-6man-rfc4291bis-05 (work in Architecture", draft-hinden-6man-rfc4291bis-06 (work in
progress), October 2015. progress), October 2015.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981,
<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>.
[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>.
skipping to change at page 29, line 19 skipping to change at page 29, line 30
ipv6-parameters.xhtml>. ipv6-parameters.xhtml>.
[IANA-PN] "Assigned Internet Protocol Numbers", [IANA-PN] "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/ <https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. 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 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
10.17487/RFC4302, December 2005, 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, DOI 10.17487/RFC4303, December 2005, 4303, DOI 10.17487/RFC4303, December 2005,
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
01) Added text that Extension headers must never be inserted by
any node other than the source of the packet.
01) Change "must" to "should" in Section 4.3 on the Hop-by-Hop
header.
01) Added text that the Data Transmission Order is the same as
IPv4 as defined in RFC791.
01) Updated the Fragmentation header text to correct the
inclusion of AH and note no next header case.
01) Change terminology in Fragment header section from
"Unfragmentable Headers" to "Per-Fragment Headers".
01) Removed paragraph in Section 5 that required including a
fragment header to outgoing packets if a ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. This is
based on the update in draft-ietf-6man-deprecate-atomfrag-
generation-03.
01) Changed to Fragmentation Header section to clarify MTU
restriction and 8-byte restrictions, and noting the
restriction on headers in first fragment.
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
00) Add a paragraph to the reference section acknowledging the 00) Add a paragraph to the acknowledgement section acknowledging
authors of the updating documents the authors of the updating documents
00) Remove old paragraph in Section 4 that should have been 00) Remove old paragraph in Section 4 that should have been
removed when incorporating the update from RFC7045. removed when incorporating the update from RFC7045.
00) Editorial changes. 00) Editorial changes.
Individual Internet Drafts Individual Internet Drafts
07) Update references to current versions and assign references 07) Update references to current versions and assign references
to normative and informative. to normative and informative.
 End of changes. 41 change blocks. 
70 lines changed or deleted 100 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/