(Obsoletes RFC 1883, Updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112, Errata)
1: semantics 语义
2: 1 octet = 8bits = 1byte
3: padding 填充
4: terminology 专门名词， 术语
5: encounter: 遇见
6: algoritms 算法
7: omit 省略， 遗漏
一：Introduction
1. Changes form IPv6 to IPv6.
1) Expanded Addressing Capabilities
32 bits to 128 bits to support
a) more levels of addressing hiearchy
b) a much greater number of address nodes
c) simpler auto-configration of address nodes.
d) add a "scope" field to multicast addresses.
e) define a new type of addresses called "anycast address" to send a packet to anyone of a group of nodes.
2) Header Format Simplication
Drop or make optional some IPv4 header field.
a) Reduce the common-case processing cost of packet handling.
b) limit the bandwidth cost of the IPv6 header.
3) Improved Support for Extensions and Options
Changes in the way IP header options
a) more efficient forwarding.
b) less stringent limits on the length of options. (选项长度放松)
c) greater flexibility for introducing new options in the future.
4) Flow Labeling Capability
a) add a capability to enable the labeling of packets, for which the sender requests special handling,
such as non-default quality or "real-time" service.
5) Authentication and Privacy Capabilities
a) Extensions to support authentication data integraty (数据完整)，
optional data confidentiality(数据机密性)。
二、 Terminology
1: node - a device that implements IPv6.
2: router - a node that forwards IPv6 packets not explicitly addressed to itself.
3: host - any node that is not a router.
4: upper layer - a protocol layer immediatly above IPv6, ICMP, TCP, UDP, OSPF, IPX, AppleTalk or IPv6 intself.
5. link - a communication facility at the same link.
below IPv6.
Ethernets(bridged), PPP links, X.25, Frame, Relay.
6. neighbors - nodes attached to the same link.
7. interface - a node's attachment to a link.
8. packet - an IPv6 header plus payload.
9. link MTU - the maximum transmission unit.
maximum packet size in octets.
10. path MTU - the minimum link MTU of all the links in a path between a source node and a destination node.
三、 IPv6 Header Format (40 octets)
8 parts
a) Version, Traffic class, Flow Label(4, 8, 20)
b) Payload, Next Header, Hop Limit(16, 8, 8)
c) Source Address(128).
d) Destination Address(128).
1: Version - 4 bits
2: Traffic Class -8 bits
3: Flow Label -20 bits
4: Payload -16 bits The rest of the packet following this IPv6 Header, in octets(including IPv6 Extension Headers.)
5: Next Header -8 bits
6: Hop limit -8 bits The packet is discarded if Hop limit is decremented to zero.
7. Source Address - 128 bits.
8. Destination Address -128 bits.
四、 IPv6 Extension Header
Optional IPv6 internet-layer is encoded in separate headers that may be placed between the IPv6 header and the upper layer header in a packet.
note by self: ICMP is the upper-layer, so extension header does not include ICMP.
?
With one excepition(Hop by Hop), extension headers are not examined or processed by any node along a packets delivery path,
until the packet reaches the node(or each set of nodes in the case of municast).
Extension Headers must be processed strictly in the order they appear in the packet.
Hop by hop option carries information that must be examined and processed by every node along a packets delivery path,
including the source and destination nodes.
If the next header field value is unrecognized, it should discard the packet and send an ICMP Parameter Problem message to the source, with
an ICMP code value of 1 ("unrecognized Next Header type encountered"). and the ICMP Point field containing the offset of the unrecognized
value within the original packet. The same action should be taken if a node encounters a Next Header field value of zero in any header other
IPv6.
Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers.
Multi-octet fields within each extension header are aligned on their nature boundaries, fields of width n octets are placed at an integer
of multiple of n octets form the start of the header, for n = 1, 2, 4, 8.
A full implementation of IPv6 includes implementation of the following extension headers.
1) Hop by Hop (IPv6 Next Header value of 0)
2) Routing (Type 0, IPv6 Next Header value of 43)
3) Fragment (IPv6 Next Header value of 44)
4) Destination options(Ipv6 Next Header value of 60)
5) Authentication
6) Encapsulating Security Payload
4.1 Extension Header Order
When more than one extension header is used in the same packet, it is recommended in the following order.
1) IPv6 Header
2) Hop by hop.
3) Destination Options (note 1)
4) Routing
5) Fragment
6) Authentication (note 2)
7) Encapsulating Security Payload (note 2)
8) Destination Options (note 3)
9) upper-layer header
note 1: for options to be processed by the first Destination Options plus subsequent destinations listed in the Routing Header.
note 2: Addtional recommendations regarding the relative order of the Authentication and Encapsulating security Payload
headers are given in RFC-2406.
note 3: for options to be processed only by the final destination of the packet.
Each extension header should occur at most once , except for Destination Options occuring at most twice.
If the uppler-layer header is another IPv6 header (in the case of IPv6 being tunneld over or encapsulated in IPv6), it may be followed
its own extsion headers, which are separtely subject to the same ordering recommendations.
If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified.
IPv6 nodes must accept and attemp to process extension headers in any order and occuring any number of times in the same packet,
except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly
advised that souces of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that
recommendation.
note by self: 虽然协议规定了extension header 出现的次数和次序， 但是对nodes来说， 必须能处理一个packet中出现任何次序和次数的extension header.
或者出现了其他RFC修改上述order。
4.2 Options
Two of currently-defined extension headers -- Hop-by-Hop and the Destination options -- carry a variable number of type-length-value(TLF)
encoded "options", of the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - -
Option Type: 8-bit identifier of the type of option.
Opt Data Len: 8-bit unsighed integer. Lenth of the Option Data field of ths option, in octets.
Option Data: Variable-length field. Option-Type-specific data.
The sequence of options within a header must be processed strictly in the order the appear in the header;
A receiver must not, for example, scan through the header looking for a particular kind of option and process
that option prior to processing all preceding ones.
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken
if processing IPv6 node does not recognize the Option Type.
00 - skip over this action and continue processing the header.
01 - discard the packet.
02 - discard the packet and regardless of whether or not the packets Destination Address was a multicast address, send
an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination Address was not a mullticast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
The third-highest-order bit of the Option type specifies whether or not the Option Data of that option can change en-route to
the packet's final destination. When an Authentication header is present in the packet, for any option whose data may
change en-route, its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet's
authenticating value.
0 - Option Data does not change en-route.
1 - Option Data may change en-route.
The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type.
The same Option Type numbering space is used for both the Hop-by-Hop Options header and the Destination Operations header.
However, the specification of a paticular option may restrict its use to only one of those two headers.
Individual options may have specific alignment requirements, to ensure the multi-octet values within Option Data fields fall on
natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type
must appear at an integer multiple of x octets from the start of the header, plus y octets.
2n : means any 2-octet offset from the start of the header,
8n+2 ： means any 8-octet offset from the start of the header, plus 2 octets.
There are two padding options which are used when nesscessary to align subsequent options and to pad out the containing header to
a multiple of 8 octets in length. These padding options must be recognized by all IPv6 implementaions:
Pad1 option (alignment requirement: none)
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Note ! the format of Pad1 option is a special case -- it does not have length and value fields(Option Data len, Option Data).
Pad1 option is used to insert one octet of padding into the Option area of a header.
More than one octet of padding required, PadN Option described next:
PadN option (alignment requirement: none)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - -
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 Opt Data Len field containing the Value N - 2, Option Data
consists of N-2 zero-valued octets.
Appendix B contains formatting guidelines for designing new options.
4.3 Hop-by-Hop Options Header
Following Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header -- 8 bit, Uses the same value as the IPv4 Protocol Field(RFC 1700).
Hdr Ext Len -- 8 bit usigned integer. Length of the Hop-by-Hop Options header in
8-octet unit, not including the first 8 octets.
Options --- Variable-length field, of length such that complete Hop-by-Hop Options
header is an integer multiple of 8 octets long. Contains one or more
TLV(type-length-value) encoded options, as described in section 4.2.
The only Hop-by-Hop options defined in this document are Pad1 and PadN options.
4.4 Routing Header
It is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the
way to a packet's destination, vary similar to IPv4's Loose Source and Record Route Option.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 Sections
1) Next Header -- 8-bit selector. Uses the same values as IPv4 Protocol Field(RFC1700).
2) Hdr Ext Len -- 8 bit, Length of the Routing header in 8-octet units, not including the first 8 octets.
3) Routing Type -- 8 bit identifier of a particular Routing Header variant.
4) Segments Left --8 bit. Number of route segments remaining-- number of explicitly listed
intermediate nodes still to be visited before reaching the final destination.
5) type-specific data -- Variable-length field, of format determined by the Routing Type, and of length
such that the complete Routing Header is an integer multiple of 8 octets long.
If a node receives a packet with an unrecognized Routing Type value, the required behavior depends on the value of
Segments Left field as follows:
1) Segments Left is zero, the node must ignore the Routing header and proceed to process the next header.
2) Segments Left is non-zero, the node must dicard the packet and send an ICMP Parmeter Problem, Code 0,
message to the packet's Source Address, pointing to the unrecognized Routing Type.
If, after processing a Routing Header, an intermediate node determines that the packet is to be forwarded onto
a link whose link MTU is less than the packet, the node must discard the packet and send ICMP Too Big message
to the packet's Source Address.
Type 0 Rourting Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type = 0 | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hdr Ext Len: For Type 0 Router Header, Hdr Ext Len is equal to two times the number of addresses in the header.
Reserved: 32-bit field, initialized to zero.
Multicast Address must not appear in a Routing header of Type 0, or in the IPv6 Destination field carring Routing
Header of Type 0.
Routing Header of Type 0 performs the following algorithms：
if (Segments Left = 0)
{
proceed to process the next header in the packet.
}
else if ( Hdr Ext Len is odd)
{
send an ICMP Prameter Promblem, Code 0, message to the source, poiting to the Hdr Ex Len field, and dicard the packet.
}
else
{
compute n = Hdr Ext Len/2
if ( Segments Left > n)
{
send an ICMP Parameter Problem, Code 0, message to the Source, pointing to the Segments Left field, dicard the packet.
}
else
{
decrement Segments Left by 1;
compute i, the next address to be visited in the address vector, i = n - (Segments Left)
if ( Address[i] or the IPv6 Destination is muticast)
{
discard the packet;
}
else
{
swap the IPv6 Destination Address and Address[i];
if ( Hop limit <= 1)
{
send an ICMP Time Exceed -- Hop Limit Exceed to the source and dicard the message.
}
else
{
decrement the Hop Limit by 1;
resubmit the packet to the IPv6 module for transmission to the new destination.
}
}
}
}
4.5 Fragment Header
The Fragment Header is used by an IPv6 source to send a packet larger than would fit in the path MTU.
(Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packets'
delivery path)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1) Reserved: initialized to zero, ignored on reception.
2）Fragment Offset: 13 bit unsigned integer, the offset, in 8-octet units, of the data following this header,
relative to the start of the Fragmentable Part of the original packet.
3) Res: 2-bit Reserved field, initialized to zero.
4) M Flag: 0 = last fragment, 1= more fragments;
5) Identification: 32bits.
In order to send a packet that is too large to fit the path MTU, a source node may divide the packet into
fragments and send each fragment as a separate packet, to be reassembled at the receiver.
For every packet that is to be fragmented, the source node generates an Identification.
Identification must be different than that of any other fragmented packet sent recently with
the same Source and Destination Address. If a Routing Header present, the Destination
of concern is that of the final destination.
Note: recently means the maximum likely lifetime of a packet. including transmit time from source
to destination and time spent awaiting reassembly with other fragments.
However, it is not required that a source node know the maximum packet life time.
Rather, it is assumed that the requirement can be met by maintaining the
Identification value as a simple, 32-bit, "wrap-around" counter,
incremented each time a packet must be fragmented.
It is an implementation choice whether to maintain a single counter for the node
or multiple counters. e.g, one for each of the node's possible source addresses, or
one for each active(source address, destination address) combination.
The initial, large, unfragmented packet is referred to as the "original packet".
It is considered to consist of two parts, as follow:
+------------------+----------------------//-----------------------+
| Unfragmentable | Fragmentable |
| Part | Part |
+----------------------+----------------------//-------------------------------+
1) Unfragmentalble Part: consists of the IPv6 header plus any extension headers that must
be processed by nodes en route to destination, that is, all headers up to and including
the Routing header if present, else Hop-by-Hop Options Header if present,
else no extension headers.
2) Fragmentable Part: consists of the rest of the packet.
+------------------+--------------+--------------+--//--+----------+
| Unfragmentable | first | second | | last |
| Part | fragment | fragment | .... | fragment |
+------------------+--------------+--------------+--//--+----------+
+------------------+----------+--------------+
| Unfragmentable | Fragment | first |
| Part | Header | fragment |
+------------------+----------+--------------+
+------------------+----------+--------------+
| Unfragmentable | Fragment| second |
| Part | Header | fragment |
+------------------+----------+--------------+
o
o
o
+------------------+--------+----------+
| Unfragmentable |Fragment| last |
| Part | Header | fragment |
+------------------+--------+----------+
Each fragment packet is composed of
(1) The Unfragmentable Part of the orginal packet, with the Payload Length changed and
Next Header field changed to 44.
(2) Fragment Header containing
a) Next Header that identifies the first header of the Fragmentable Part of the Original Packet.
b) A Fragment Offset containing the offset of the fragment, in 8-octet units.
(The fragment offset of the first is "0").
The Fragment length chosen to fit path MTU.
At the destination, the following rules goven reassembly:
(1) An orginal packet is resassembled only from packets having the same
Source Address, Destination Address, Fragment Identification.
(2) Unfragmentable Part:
a) The Next Header of the last header of the Unfragmentable.
4.6 Destination Options Header
The Destination Options Header is used to carry optional information that need to be
examined only by a packet's destination node(s), following format(same with Hop-by-Hop):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hdr Ext Len -- 8 bit usigned integer. Length of the Hop-by-Hop Options header in
8-octet unit, not including the first 8 octets.
The only destination options defined in this document are Pad1 and PadN options
specified in Section 4.2.
Note: there are two possible ways to encode optional destination information in an
IPv6 packet:
1) an option in the Destinaion Options Header.
2) as a separate extension header(examples Fragment Header, Authentication Header).
Which approach can be used depends on what action is desired of a destinaion
node that does not understand the optional information:
4.7 No Next Header
The value 59 in the the Next Header field of an IPv6 header or any extension header indicates
that there is nothing following that 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
contains 59, those octets must be ignored, and passed on unchanged if
the packet is forwarded.
4.8 Packet Size Issues
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
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
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.
It is strongly recommended that IPv6 nodes implement Path MTU
Discovery [RFC-1981], in order to discover and take advantage of path
MTUs greater than 1280 octets.
However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply
restrict itself to sending packets no larger than 1280 octets,
and omit implementation of Path MTU Discovery.
A node must be able to accept a fragmented packet that, after
reassembly, is as large as 1500 octets.