When computing the maximum payload size available for upper-layer
data, an upper-layer protocol must take into account the larger size
of the IPv6 header relative to the IPv4 header. For example, in
IPv4, TCP's MSS option is computed as the maximum packet size (a
default value or a value learned through Path MTU Discovery) minus 40
octets (20 octets for the minimum-length IPv4 header and 20 octets
for the minimum-length TCP header). When using TCP over IPv6, the
MSS must be computed as the maximum packet size minus 60 octets,
because the minimum-length IPv6 header (i.e., an IPv6 header with no
extension headers) is 20 octets longer than a minimum-length IPv4
header.
8.4 Responding to Packets Carrying Routing Headers
When an upper-layer protocol sends one or more packets in response to
a received packet that included a Routing header, the response
packet(s) must not include a Routing header that was automatically
derived by "reversing" the received Routing header UNLESS the
integrity and authenticity of the received Source Address and Routing
header have been verified (e.g., via the use of an Authentication
header in the received packet). In other words, only the following
kinds of packets are permitted in response to a received packet
bearing a Routing header:
o Response packets that do not carry Routing headers.
o Response packets that carry Routing headers that were NOT
derived by reversing the Routing header of the received packet
(for example, a Routing header supplied by local
configuration).
o Response packets that carry Routing headers that were derived
by reversing the Routing header of the received packet IF AND
ONLY IF the integrity and authenticity of the Source Address
and Routing header from the received packet have been verified
by the responder.
Appendix A. Semantics and Usage of the Flow Label Field
A flow is a sequence of packets sent from a particular source to a
particular (unicast or multicast) destination for which the source
desires special handling by the intervening routers. The nature of
that special handling might be conveyed to the routers by a control
protocol, such as a resource reservation protocol, or by information
within the flow's packets themselves, e.g., in a hop-by-hop option.
The details of such control protocols or options are beyond the scope
of this document.
There may be multiple active flows from a source to a destination, as
well as traffic that is not associated with any flow. A flow is
uniquely identified by the combination of a source address and a
non-zero flow label. Packets that do not belong to a flow carry a
flow label of zero.
A flow label is assigned to a flow by the flow's source node. New
flow labels must be chosen (pseudo-)randomly and uniformly from the
range 1 to FFFFF hex. The purpose of the random allocation is to
make any set of bits within the Flow Label field suitable for use as
a hash key by routers, for looking up the state associated with the
flow.
All packets belonging to the same flow must be sent with the same
source address, destination address, and flow label. If any of those
packets includes a Hop-by-Hop Options header, then they all must be
originated with the same Hop-by-Hop Options header contents
(excluding the Next Header field of the Hop-by-Hop Options header).
If any of those packets includes a Routing header, then they all must
be originated with the same contents in all extension headers up to
and including the Routing header (excluding the Next Header field in
the Routing header). The routers or destinations are permitted, but
not required, to verify that these conditions are satisfied. If a
violation is detected, it should be reported to the source by an ICMP
Parameter Problem message, Code 0, pointing to the high-order octet
of the Flow Label field (i.e., offset 1 within the IPv6 packet).
The maximum lifetime of any flow-handling state established along a
flow's path must be specified as part of the description of the
state-establishment mechanism, e.g., the resource reservation
protocol or the flow-setup hop-by-hop option. A source must not re-
use a flow label for a new flow within the maximum lifetime of any
flow-handling state that might have been established for the prior
use of that flow label.
When a node stops and restarts (e.g., as a result of a "crash"), it
must be careful not to use a flow label that it might have used for
an earlier flow whose lifetime may not have expired yet. This may be
accomplished by recording flow label usage on stable storage so that
it can be remembered across crashes, or by refraining from using any
flow labels until the maximum lifetime of any possible previously
established flows has expired. If the minimum time for rebooting the
node is known, that time can be deducted from the necessary waiting
period before starting to allocate flow labels.
There is no requirement that all, or even most, packets belong to
flows, i.e., carry non-zero flow labels. This observation is placed
here to remind protocol designers and implementors not to assume
otherwise. For example, it would be unwise to design a router whose
performance would be adequate only if most packets belonged to flows,
or to design a header compression scheme that only worked on packets
that belonged to flows.
Appendix B. Formatting Guidelines for Options
This appendix gives some advice on how to lay out the fields when
designing new options to be used in the Hop-by-Hop Options header or
the Destination Options header, as described in section 4.2. These
guidelines are based on the following assumptions:
o One desirable feature is that any multi-octet fields within the
Option Data area of an option be aligned on their natural
boundaries, i.e., fields of width n octets should be placed at
an integer multiple of n octets from the start of the Hop-by-
Hop or Destination Options header, for n = 1, 2, 4, or 8.
o Another desirable feature is that the Hop-by-Hop or Destination
Options header take up as little space as possible, subject to
the requirement that the header be an integer multiple of 8
octets long.
o It may be assumed that, when either of the option-bearing
headers are present, they carry a very small number of options,
usually only one.
These assumptions suggest the following approach to laying out the
fields of an option: order the fields from smallest to largest, with
no interior padding, then derive the alignment requirement for the
entire option based on the alignment requirement of the largest field
(up to a maximum alignment of 8 octets). This approach is
illustrated in the following examples:
Example 1
If an option X required two data fields, one of length 8 octets and
one of length 4 octets, it would be laid out as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8-octet field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Its alignment requirement is 8n+2, to ensure that the 8-octet field
starts at a multiple-of-8 offset from the start of the enclosing
header. A complete Hop-by-Hop or Destination Options header
containing this one option would look as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8-octet field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 2
If an option Y required three data fields, one of length 4 octets,
one of length 2 octets, and one of length 1 octet, it would be laid
out as follows:
+-+-+-+-+-+-+-+-+
| Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-octet field | 2-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Its alignment requirement is 4n+3, to ensure that the 4-octet field
starts at a multiple-of-4 offset from the start of the enclosing
header. A complete Hop-by-Hop or Destination Options header
containing this one option would look as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-octet field | 2-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 3
A Hop-by-Hop or Destination Options header containing both options X
and Y from Examples 1 and 2 would have one of the two following
formats, depending on which option appeared first:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8-octet field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-octet field | 2-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-octet field | 2-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=4 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8-octet field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Considerations
The security features of IPv6 are described in the Security
Architecture for the Internet Protocol [RFC-2401].
Acknowledgments
The authors gratefully acknowledge the many helpful suggestions of
the members of the IPng working group, the End-to-End Protocols
research group, and the Internet Community At Large.
Authors' Addresses
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527 8213
Fax: +1 408 527 8254
EMail: deering@cisco.com
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: +1 408 990-2004
Fax: +1 408 743-5677
EMail: hinden@iprg.nokia.com
References
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC2402, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC2406, November 1998.
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet
Protocol Version 6 (IPv6)", RFC2463, December 1998.
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU
Discovery for IP version 6", RFC1981, August 1996.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC791,
September 1981.
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC1661, July 1994.
CHANGES SINCE RFC-1883
This memo has the following changes from RFC-1883. Numbers identify
the Internet-Draft version in which the change was made.
02) Removed all references to jumbograms and the Jumbo Payload
option (moved to a separate document).
02) Moved most of Flow Label description from section 6 to (new)
Appendix A.
02) In Flow Label description, now in Appendix A, corrected maximum
Flow Label value from FFFFFF to FFFFF (i.e., one less "F") due
to reduction of size of Flow Label field from 24 bits to 20
bits.
02) Renumbered (relettered?) the previous Appendix A to be Appendix
B.
02) Changed the wording of the Security Considerations section to
avoid dependency loop between this spec and the IPsec specs.
02) Updated R. Hinden's email address and company affiliation.
--------------------------------------------------------
01) In section 3, changed field name "Class" to "Traffic Class" and
increased its size from 4 to 8 bits. Decreased size of Flow
Label field from 24 to 20 bits to compensate for increase in
Traffic Class field.
01) In section 4.1, restored the order of the Authentication Header
and the ESP header, which were mistakenly swapped in the 00
version of this memo.
01) In section 4.4, deleted the Strict/Loose Bit Map field and the
strict routing functionality from the Type 0 Routing header, and
removed the restriction on number of addresses that may be
carried in the Type 0 Routing header (was limited to 23
addresses, because of the size of the strict/loose bit map).
01) In section 5, changed the minimum IPv6 MTU from 576 to 1280
octets, and added a recommendation that links with configurable
MTU (e.g., PPP links) be configured to have an MTU of at least
1500 octets.
01) In section 5, deleted the requirement that a node must not send
fragmented packets that reassemble to more than 1500 octets
without knowledge of the destination reassembly buffer size, and
replaced it with a recommendation that upper-layer protocols or
applications should not do that.
01) Replaced reference to the IPv4 Path MTU Discovery spec (RFC-
1191) with reference to the IPv6 Path MTU Discovery spec (RFC-
1981), and deleted the Notes at the end of section 5 regarding
Path MTU Discovery, since those details are now covered by RFC-
1981.
01) In section 6, deleted specification of "opportunistic" flow
set-up, and removed all references to the 6-second maximum
lifetime for opportunistically established flow state.
01) In section 7, deleted the provisional description of the
internal structure and semantics of the Traffic Class field, and
specified that such descriptions be provided in separate
documents.
--------------------------------------------------------
00) In section 4, corrected the Code value to indicate "unrecognized
Next Header type encountered" in an ICMP Parameter Problem
message (changed from 2 to 1).
00) In the description of the Payload Length field in section 3, and
of the Jumbo Payload Length field in section 4.3, made it
clearer that extension headers are included in the payload
length count.
00) In section 4.1, swapped the order of the Authentication header
and the ESP header. (NOTE: this was a mistake, and the change
was undone in version 01.)
00) In section 4.2, made it clearer that options are identified by
the full 8-bit Option Type, not by the low-order 5 bits of an
Option Type. Also specified that the same Option Type numbering
space is used for both Hop-by-Hop Options and Destination
Options headers.
00) In section 4.4, added a sentence requiring that nodes processing
a Routing header must send an ICMP Packet Too Big message in
response to a packet that is too big to fit in the next hop link
(rather than, say, performing fragmentation).
00) Changed the name of the IPv6 Priority field to "Class", and
replaced the previous description of Priority in section 7 with
a description of the Class field. Also, excluded this field
from the set of fields that must remain the same for all packets
in the same flow, as specified in section 6.
00) In the pseudo-header in section 8.1, changed the name of the
"Payload Length" field to "Upper-Layer Packet Length". Also
clarified that, in the case of protocols that carry their own
length info (like non-jumbogram UDP), it is the upper-layer-
derived length, not the IP-layer-derived length, that is used in
the pseudo-header.
00) Added section 8.4, specifying that upper-layer protocols, when
responding to a received packet that carried a Routing header,
must not include the reverse of the Routing header in the
response packet(s) unless the received Routing header was
authenticated.
00) Fixed some typos and grammatical errors.
00) Authors' contact info updated.
--------------------------------------------------------
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.