Internet Protocol version 6 (IPv6) specification (1)

Internet Protocol version 6 (IPv6) Specification
Description
This article describes in detail a standard protocol for Internet groups, and requests for further improvement.
For details, refer to the current version of "official Internet protocol standard" (Standard 1) to obtain the standard of this Protocol.
Statement. The distribution of this article is unrestricted.
Copyright Notice
Copyright (C) Internet Association (1998). All rights reserved.
Summary
This article details Internet Protocol version 6th (IPv6), which is sometimes called the next-generation IP address or
IPng.
Directory
1. introduction ....................................... ................... 2
2. term ....................................... ................... 3
3. IPv6 Header Format ..................................... ............ 4
4. IPv6 extension header ..................................... ............ 6
4.1 sequence of extension headers ................................... ........ 7
4.2 options ...................................... ............... 9
4.3 Hop-by-Hop option header ................................ ..... 11
4.4 Route Header ..................................... ........... 12
4.5 fragment header ..................................... ........... 18
4.6 Destination Address option header ................................... ..... 23
4.7 "no next Header ".................................. ........ 24
5. package size .................................... ............. 24
6. data Flow tag ...................................... ............ 25
7. transmission type ...................................... ............... 25
8. upper-layer protocols ..................................... ............ 27
8.1 upper-layer protocol checksum .................................... ...... 27
Maximum lifetime of the 8.2 package ................................... ....... 28
8.3 maximum payload size of upper layer protocols ................28
8.4 response to the packet carrying the Routing Header ................................ 29
RFC 2460 IPv6 Specification December 1998
Appendix. the semantics and usage of the Data Flow Label fields .............................. 30
Appendix B. guidelines for Option Field Format .............................. 32
Security considerations ..................................... .............. 35
Thank you ....................................... ..................... 35
Address of the author ..................................... ................. 35
References ...................................... .................. 35
Changes since RFC-1883 ................................... ....... 36
Complete copyright notice .................................... .............. 39
1. Introduction
IP 6th (IPv6) is an Internet Protocol after IP 4th (IPv4) [RFC-791]
A new version, from IPv4 to IPv6, focuses on the following aspects:
O address capacity expansion
IPv6 increases the IP address size from 32-bit to 128-bit, which supports more address levels and more
A large number of nodes and simpler automatic configuration of addresses. the scalability of multicast routes is improved
Adds a "range" field to the multicast address, and defines a new address called "anycast ".
Type, used to send packets to any of the nodes in a group.
O Header Format simplification
Some IPv4 header fields are deleted or become optional fields, which reduces packet processing.
Overhead and the bandwidth occupied by the IPv6 Header.
O support expansion and option Improvement
The modification of the IP header option encoding method leads to more efficient transmission, with fewer options in length.
Restrictions and more adaptability when new options are introduced in the future.
O Data Flow Label capability
Add a new capability so that those senders require special processing to belong to the special transmission "stream"
The package can be labeled, such as non-default quality services or real-time services.
RFC 2460 IPv6 Specification December 1998
O authentication and confidentiality
To support authentication, data integrity and (optional) Data Confidentiality extensions are described in IPv6.
This article describes the basic IPv6 Header and the IPv6 extension header and options initially defined.
Dimensions, data flow labels and transmission class syntax, and IPv6 impact on upper-layer protocols.
The address format and syntax are described separately in [ADDRARCH]. The IPv6 version of ICMP is all IPv6 applications.
It must be included in [ICMPv6.
2. Terms
Node-A device that applies IPv6.
Vro-the node that sends the IPv6 package to itself. [refer to the following description]
Host-any non-router node. [See the following description]
Upper Layer-the protocol layer directly on the IPv6 upper layer. Typical examples are transmission protocols such as TCP and UDP,
Control protocols such as ICMP, routing protocols such as OSPF, and the network layer or IPv6
A low-layer protocol (such as IPX,
AppleTalk, or IPv6 itself.
Link-a communication device or media through which nodes can communicate with the link layer, that is, directly
Communication at the layer below IPv6. a typical example is Ethernet (simple
Or Bridge); PPP connection; X.25 frame relay, or ATM Network; and network
Tunnel of a layer (or higher layer). For example, tunnel through IPv4 or IPv6
Path.
Neighbor-nodes connected to the same link.
Interface-connection between nodes and links.
Address-the identifier of an interface or a group of interfaces in the IPv6 layer.
Package-IPv6 Header with payload.
The maximum transmission unit of the link MTU, which is an eight-bit packet that can be transmitted in the link.
Maximum size.
RFC 2460 IPv6 Specification December 1998
Path MTU-the minimum link MTU of all links in the path from the source node to the target node.
Note: although this is not common, it is possible that a device has multiple interfaces for transmitting
Packets sent from some (not all) interfaces that do not take themselves as the target node, and discard those from other interfaces
When a device receives packets or
When its neighbor contacts, it must follow the router requirements in the Protocol. When it receives
The package or its neighbor must comply with the requirements of the Protocol for the host.
3. IPv6 Header Format
+- +-+
| Version | transmission type | data stream tag |
+- +-+
| Payload length | next header | hop count limit |
+- +-+
|
++
|
+ Source Address +
|
++
|
+- +-+
|
++
|
+ Target address +
|
++
|
+- +-+
Version 4: Bit Internet Protocol version = 6.
Transmission category 8-bit Transmission category fields. See chapter 7th.
20-Bit Data Flow Label for Data Flow labels. See chapter 6th.
16-bit unsigned integer in payload length. IPv6 payload length is 8
The length of the rest of the IPv6 Header in this package.
Degree. (note that the first part of the extension [Chapter 4th] will be considered as a payload.
Part in length .)
RFC 2460 IPv6 Specification December 1998
Next header 8-bit selector. identifies the next header next to the IPv6 Header
Type. Use the IPv4 protocol field [RFC-1700 and subsequent protocols]
The same value.
The number of hops must be an 8-bit unsigned integer. The number of hops decreases at each node that transmits the package. 1. For example:
If the number of hops is reduced to zero, the package is discarded.
Source Address: the address of the producer of the 128 bits. See [ADDRARCH]
Destination Address: the address of the expected receiver of the 128 bits (if there is a Route Header,
May not be the final receiver). See [ADDRARCH] and Chapter 4.4.
4. IPv6 expansion Header
In IPv6, the optional network layer information is encoded in an independent header and placed on the IPv6 Header and
There are only a few extension headers between layer protocol headers, each of which consists of different
The value of "bu" to identify. an IPv6 Header can carry zero, one or more extension headers, each
The extension header is identified by the "next Header" field in the previous header, as shown in the following example:
+ --------------- + ------------------------
| IPv6 Header | TCP Header + Data
|
| Next header = |
| TCP |
+ --------------- + ------------------------
| IPv6 Header | Route Header | TCP Header + Data
|
| Next header = |
| Route Header | TCP |
+ --------------- + ---------------- + ------------------------
+ --------------- + ---------------- + -----------------
| IPv6 Header | Route Header | shard header | TCP Header + Data
|
| Next header = |
| Route Header | shard header | TCP |
+ --------------- + ---------------- + -----------------
Except for one exception, the extension header does not detect and process any node in the package's transfer path until this package
The node identified by the target address field (or each of the nodes in a group in the case of multicast ).
Here, the general processing of the "next Header" field in the IPv6 Header is to call the processing module to process
One extension header, or, if there is no extension header, process the upper-layer header.
The content and semantics determine whether to process the next header. Therefore, the extension header must be in the package strictly according to their
In this way, the receiver cannot search the entire package to find a specific type of header, and
And process it before processing all the previous headers.
The special case described above refers to the Hop-by-Hop option header, which carries each section in the Transfer Path of the package.
Information that must be checked and processed by the node, including the source node and destination node. Hop-by-Hop option header if
If yes, it must be followed by the IPv6 Header. The value of the "next Header" field in the IPv6 Header is zero.
Indicates that this header exists.
If the processing result of a header requires the node to process the next header, but the node cannot identify this header"
Next Header "field value, the node should discard this package and send
ICMP "parameter is faulty" message, ICMP encoding value is 1 ("the next header is unrecognizable'
Type "). The ICMP pointer field contains the unidentifiable offset in the original package. If the node encounters
When the value of the "next Header" field in other headers other than the IPv6 Header is zero
Processing.
Why 3? Alignment of eight bits. Each extension header is an integer multiple of eight bits.
Multiple eight-bit fields in each expansion header are aligned with their natural boundaries. That is, the width is n.
The fields in the eight-digit group are placed at an integer multiple of n eight-digit groups at the starting position of the header, where n = 1, 2,
4, or 8.
A complete IPv6 implementation should include the following extended first handler:
Hop-by-Hop option Header
Route Header (Type 0)
Shard Header
Destination Address Header
Certification first
Encapsulation security payload header (ESP header)
The first four will be described in this article, and the last two are described in [RFC-2402] and [RFC-2406] respectively.
4.1 sequence of expansion Headers
When more than one extension header is used in the same package, we recommend that you sort the headers in the following order:
IPv6 Header
Hop-by-Hop option Header
Destination Address option header (Note 1)
Route Header
Shard Header
Certification first (note 2)
Encapsulate the safe payload header (note 2)
Destination Address option header (note 3)
Upper-layer protocol header
NOTE 1: The first IP address listed by the IPv6 Destination Address field and Route Header appears
.
NOTE 2: additional recommendation parameters for the sequence of authentication headers and encapsulation of Security Payload Headers
See [RFC-2406].
NOTE 3: only the final destination address of the package is used.
In addition to the destination address option header, it can appear at most twice (one before the Route Header and one before the upper-layer protocol header)
In addition, each extension header should only appear once.
If the upper-layer protocol header is another IPv6 Header (when tunneling technology is used or encapsulated in IPv6
), Which can be followed by their own extension headers. These extension headers are arranged independently in the same recommended order.
If other extension headers are defined, the order restrictions related to the extension headers listed above must be described.
Except that the Hop-by-Hop option header must be followed by the IPv6 Header, IPv6 nodes must accept
And try to deal with any order, as well as any number of expansion headers appear in the same package.
Therefore, it is strongly recommended that the source node of the IPv6 package follow the recommended sequence, unless the subsequent protocol specification modifies this
Sequence.