Internet Protocol version Sixth (IPV6) specification

1. Introduction

IP version 6th (IPV6) is a new version of the Internet protocol after IP version 4th (IPV4) [RFC-791]. The changes from IPV4 to IPV6 are mainly concentrated in the following areas: expansion of address capacity
IPV6 increases the size of the IP address from 32 bits to 128 bits to support more address levels, larger numbers of nodes, and simpler address autoconfiguration. Scalability improvement for multicast routing adds a "scope" field to the multicast address. It also defines a new address type called "Anycast", which is used to send packages to any one of a set of nodes. Simplification of the header format
Some IPv4 header fields are deleted or become optional fields, reducing the processing overhead of the package and the bandwidth used by the IPV6 header in general. Support for extensions and options improvements
Modification of the IP Header option encoding results in more efficient transmission, fewer restrictions on the length of options, and greater adaptability when new options are introduced in the future. The ability of data flow tags
Add a new capability that allows the sender to require special handling of the special transport "stream" package can be labeled "tag", such as a non-default quality of services or "real-time" services. Ability to authenticate and maintain confidentiality

To support authentication, data integrity and (optionally) the extension of data confidentiality are described in IPv6. This article describes the IPV6 base header and the initially defined IPV6 extension header and options. The size of the package, the syntax of the Data flow label and transport class, and the impact of IPV6 on the upper layer protocol will also be discussed. The format and syntax of the IPV6 address are described separately in other articles. The IPV6 version of ICMP is required for all IPV6 applications.

2. Terms

Node-a device that applies IPv6.
Router-routing is not a node that sends its own IPV6 package. [See the instructions below]
Host-any non-router node. [See the instructions below]
Upper level-the protocol layer directly above the IPV6. Typical examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and low-level protocols, such as Ipx,appletalk or IPV6 itself, that are drilled into the network layer or in IPv6 (that is, encapsulated in IPv6).
Link-a communication device or media. The node can communicate with the link layer, which is directly below the IPV6 layer. Typical examples are Ethernet (simple or bridge), PPP connections, X.25, frame relays, or ATM networks and the "channels" of the network layer (or higher). For example, through the IPV4 or the IPV6 itself channel.
Neighbor-a node connected to the same link.
interface-a connection between a node and a link.
An identifier for an interface or a set of interfaces in an address-ipv6 layer.
Package-ipv6 header plus valid data.
Link MTU-Maximum transmission unit. That is, the maximum size of a packet that can be transmitted in a link in a eight-bit group.
Path MTU-the minimum link MTU for all links in the path between the source node and the destination node.

Note: Although uncommon, it is possible that a device has multiple interfaces for transmitting packets from some (not all) interfaces of its, not its own, and discarding those packets from other interfaces that do not have nodes of their own destination. When such a device receives a package from the previous interface or contacts its neighbor, it must follow the requirements of the router in the protocol. When it receives a package through the latter interface or contacts its neighbor, it must follow the Protocol's requirements for host hosts.

3.ipv6 Header Format

Version	4-bit Internet Protocol version number = 6.
Transport category	8-bit Transport category field.
Data Flow Label	20-bit Data flow label.
Valid data length	16-bit unsigned integer IPv6 the valid data length. That is, in a eight-bit group, the length of the remainder of the IPV6 header in this package. (Note that the first part of the extension is considered to be a portion of valid data, calculated in length)
Next Header	8-bit selector. Identifies the type of the next header immediately following the IPV6 header. Use the same numeric value as the IPV4 protocol field.
Hop count limit	A 8-bit unsigned integer. Decrements by 1 at each node that transmits this packet. Such as When the limit of the number of hops is reduced to zero, the packet is discarded.
Source Address	The address of the creator of the 128-bit package.
Destination Address	The address of the intended recipient of the 128-bit package (possibly not the final recipient if there is a routing header).

　

4.ipv6 Extension Header

In IPV6, the optional Network layer information is encoded in a separate header, placed between the IPV6 header and the upper layer protocol header in the package. There are several very few extensions to the header, each identified by a different "Next header" value. A IPV6 header can carry 0, one or more extension header, each of which is identified by the "Next Header" field in the previous header. As shown in the following example:

　

In addition to a special case, the extension header is not detected and processed by any node in the packet's routing path until the packet arrives at the node identified by the destination field (or in the case of multicast, each of the set of nodes). Here, the general processing of the "Next Header" field for the IPV6 header will be to call the processing module to handle the first extension header, or to handle the upper header if no extension header exists. The content and semantics of each extension header determine whether to process the next header. Therefore, the extension header must be handled in strict accordance with the order in which they appear in the package, so that the receiver cannot search the entire package for a particular type of header and process it before all the preceding header is processed.

The special case described above refers to the Hop-by-hop option header. It carries the information that each node in the packet's routing path must detect and process, including the source node and the destination node. The Hop-by-hop option header must be immediately after the IPV6 header if it exists. A value of zero in the next header field in the IPV6 header indicates that the header exists. If a header's processing result requires that the node process the next header, but the node does not recognize the "Next Header" field value of the header, then the node should discard the packet and send a message to the packet's source node with an ICMP "parameter Problem", with an ICMP encoded value of 1 (" Unrecognized ' next header ' type is encountered. The ICMP pointer field contains the offset of the unrecognized value in the original package. The same process should be done if the node encounters a zero value for the next header field in the header other than the IPV6 header.

To maintain 8 eight-bit group alignment for the following header, each extension header is an integer multiplier of 8 eight-bit groups. The eight-bit group fields for each extension header are aligned with their natural boundaries. That is, a field with a width of n eight-bit groups is placed at the position of the integer multiple of the N eight-bit group from the beginning of the header, where n = 1, 2, 4, or 8. A complete IPV6 implementation should include handlers for the following extension header: Hop-by-hop option Header Routing header (type 0) Fragment header first purpose address first certificate package secure valid data header (ESP header)

4.1 Order of Extension header

When more than one extension header is used in the same package, it is recommended that the header be arranged in the following order:

IPV6 Header

Hop-by-hop option Header

Destination Address option Header (Note 1)

Route Header

Fragment Header

Certification header (note 2)

Encapsulating secure Valid data header (note 2)

Destination Address option Header (Note 3)

Upper layer protocol Header

Note 1: The option to handle the first occurrence of the destination address in the subsequent addresses listed in the IPv6 Destination Address field and route header.
Note 2: Additional recommendations regarding the order in which the certification header and the header of the encapsulating security data are related are available in other documents.
Note 3: Options that are processed only by the final destination address of the package.

Each extension header should appear only once, except for the destination Address option header, which appears up to two times (once before the routing header, once before the upper-level protocol header). If the top protocol header is another IPV6 header (in the case of using channel technology or encapsulated in IPV6), it can have its own extension header later. These extension header are arranged separately in the same suggested order. If you define additional extension header, the order restrictions associated with the extension header listed above must be described. In addition to the Hop-by-hop option header must be immediately following the IPV6 header, the IPV6 node must accept and handle any order as much as possible, as well as any number of extension header occurrences within the same package. Nevertheless, it is recommended that the source nodes of the IPV6 package comply with the above recommended order unless the subsequent protocol specification modifies this order.

4.2 Options

Two of the currently defined extension header: Hop-by-hop option header and Destination Address option header, with an indefinite number of options encoded in type-length-value (TLV) format, in the following format:

Option type	A 8-bit identifier that identifies the type of option.
Option data length	A 8-bit unsigned integer. The length of the option data field in eight-bit groups.
Option data	Variable-Length field. Different data depending on the type of option.

The options in the header must be handled exactly in the order in which they appear in the header, so that the receiver cannot search the entire header for a particular type of option and process it before all previous options are processed. The option type identifier is encoded with the following rule: its top two digits specify the response that is required when the IPV6 node does not recognize this option type:

00	Skip this option to continue processing the header.
01	Throw this bag away.
10	Discard this package and send an ICMP "parameter problem" to the packet's source address, regardless of whether the packet's destination address is a multicast address, and the message is encoded 2, pointing to an unrecognized option type.
11	Discard this package, and only if the packet's destination address is not a multicast address, send an ICMP "parameter problem" to the packet's source address, encode 2 of the message, and the pointer points to an unrecognized option type.

The third digit of the option type identifier indicates whether the option data can be changed to the path of the final destination address. If there is a certification header, the entire data field of the option to change the options must be treated as a zero-eight-bit group when the package calculates or verifies the authentication value.

0-option data does not change the path
1-option data may change the path of choice

The first three bits above should be part of the option type, not independent of the option type. This means that a particular option is identified by all 8-bit option type identifiers, not just the back 5 digits in the option type. The Hop-by-hop option header and Destination Address option header use the same option type to encode space. However, the specification of a particular type of option can limit its use to only one of the two. Some options may have explicit alignment requirements to ensure that more than eight-bit group values in the option data field fall on their natural boundaries. The alignment of options requires a symbol xn+y to indicate that the option type must appear in the position of the integer multiple of the X eight-bit group at the start of the header plus the Y eight-bit group. For example: 2n represents an offset from the integer multiple of 2 eight-bit groups at the beginning of the header. 8n+2 represents an integer multiple of 8 eight-bit groups at the beginning of the header plus an offset of 2 eight-bit groups. There are two fill options for aligning subsequent options when needed, as well as integer multiples that populate the entire header with 8 eight-bit groups. All IPV6 implementations must be able to recognize these fill options.

Fill 1 option (Alignment requirements: none)

Populating the 1 option is a special case-it doesn't have a length field or a numeric field. The Fill 1 option fills a eight-bit group in the header's option area. If you need to populate more than one eight-bit group, you should use the Fill N option described below instead of multiple fill 1 options.

Fill n Option (Alignment requirements: none)

The Fill n option fills two or more eight-bit groups in the header's option area. For a population of N eight-bit groups, the option data length field should contain the value N-2, which consists of a N-2 0-valued eight-bit group.

4.3 hop-by-hop option Header

The Hop-by-hop option header is used to route optional information that must be detected by each node in the package's routing path. The Hop-by-hop option header is identified 0来 by the value of the next header field in the IPV6 header and has the following format:

Next Header	8-bit selector. Identifies the type of header immediately following the Hop-by-hop option header. Use the same numeric value as the IPV4 protocol field.
First extended length	A 8-bit unsigned integer. The length of the Hop-by-hop option header in 8 eight-bit groups, excluding the first 8 eight-bit groups.
Options	A variable-length field that has the length of the entire Hop-by-hop option header to be an integer multiple of 8 eight-bit groups. Contains one or more TLV encoding options, as described in Chapter 4.2.

The only hop-by-hop option defined in this article is the fill 1 and fill n options.

4.4 Routing Header

The route header is used to IPv6 one or more intermediate nodes in the path that the source node lists to the destination node of the package. This feature is very similar to the loose source address and routing logging options for IPv4. The value of 43 in the next Header field in the preceding header indicates that the next header is the route header. The route header has the following format:

Next Header	8-bit selector. Identifies the type of header immediately following the route header. Use the same numeric value as the IPV4 protocol field.
First extended length	A 8-bit unsigned integer. The length of the route header in 8 eight-bit groups, excluding the first 8 eight-bit groups.
Route type	An identifier for a 8-bit specific route header variable.
segmented remainder	A 8-bit unsigned integer. The number of remaining route segments. That is, the number of intermediate nodes that should still be accessible before reaching the final destination node, explicitly listed.
Specific types of data	Variable-Length field. The format is determined by the route type, which must have a length of 8 eight-bit integers for the entire route header.

If a node encounters a route header that contains an unrecognized route type value during processing of the received package, the node should be processed according to the value in the segmented remaining field, as follows: If the fragment value is zero, the node must ignore the route header and proceed with the next header in the package, whose type is determined by the "Next header" in the route header The value in the field is identified. If the piecewise remaining value is Non-zero, the node must discard the packet and send an ICMP "parameter problem" to the packet's source address, encoding 0 of the message, pointing to the unrecognized route type. If the intermediate node determines that the packet should be routed to a link with a link MTU smaller than the size of the packet after the routing header is processed, the intermediate node must discard the packet and send an ICMP "packet too large" message to the packet's source address.

The route header for type 0 has the following format:

Next Header	8-bit selector. Identifies the type of header immediately following the route header. Use the same numeric value as the IPV4 protocol field.
First extended length	A 8-bit unsigned integer. The length of the route header in 8 eight-bit groups, excluding the first 8 eight-bit groups. For a route header of type 0, the header extension length equals twice times the number of addresses in the header.
Route type	0
segmented remainder	A 8-bit unsigned integer. The number of remaining route segments. That is, the number of intermediate nodes that should still be accessible before reaching the final destination node, explicitly listed.
Keep	32-bit reserved fields. Initialized to zero on transfer, ignored when received.
Address [1..N]	128-bit address vector, numbered from 1 to N.

The multicast address is not allowed to appear in the route header of type 0, nor is it allowed in the IPV6 Destination Address field in the package that carries the route header of type 0. The route header is detected and processed until the package arrives at the node identified by the Destination Address field in the IPV6 header. At this node, the Routing header processing module is invoked, and for route type 0, the following algorithm is executed:

　

 if fragment remaining = 0 {continues to process the next header in the package, whose type is identified by the next header field in the route header} else if header expansion length is odd { Send an ICMP "parameter problem" to the source address, encode 0 packets, pointer to the first extended length field, and discard this packet} else {to compute N, which is the ground in the route header Number of addresses. 
             The method is the first extension length divided by 2 if fragment remaining than n large {send an ICMP "parameter problem" to the source address, encode 0 of the message, the pointer points to the segmented remaining field, and discard the packet}
                else {subsection remainder minus one;
                Calculate I, that is, address vector (address list) to "Access" the next address, the method is n minus subsection remaining if address [i] or IPv6 destination address is multicast address {Discard this package
                      else {Exchange IPV6 destination address and address [i] ifIPv6 hop limit is less than or equal to 1 {
                   Sends an ICMP "timeout-transmission exceeding the hop limit" message to the source address and discards the packet} else {jump limit minus one; Resubmit this package to the IPV6 module and pass it to the new Destination node}}} 

As an example of the above algorithm, consider a situation where the source node S sends a packet to the destination node D, using the routing header to pass the packet through the intermediate nodes I1,i2 and I3. In each segment of the routing path, the related field values in the IPV6 header and the route header field values should be described as follows:

When the package is passed from S to I1:
SOURCE address = S Destination Address = I1	First Extended length = 6
segmented remainder = 3
Address [1] = I2
Address [2] = I3
Address [3] = D
When the package is transferred from I1 to I2:
SOURCE address = S Destination Address = I2	First Extended length = 6
segmented remainder = 2
Address [1] = I1
Address [2] = I3
Address [3] = D
When the package is transferred from I2 to I3:
SOURCE address = S Destination Address = I3	First Extended length = 6