Internet Agreement Sixth Edition (IPv6) Specification
1. Introduction IP IP (IPv6) is a new version of the Internet protocol after the IP 4 (IPv4) [RFC-791]. The change from IPv4 to IPv6 is mainly concentrated in the following aspects:
The extended IPv6 of the address capacity increases the size of the IP address from 32 bits to 128 bits, which can support more address hierarchical, larger numbers of nodes, and the simpler address automatic configuration. The scalability improvement of multicast routes adds a "range" field to the multicast address. A new address type called "Anycast" is also defined, which is used to send the package to any one of a set of nodes. Simplified some IPv4 headers in the first format are deleted or become an optional field, which reduces the processing overhead of the general case and the bandwidth occupied by IPv6. Improved IP header option coding modifications to support extensions and options, result in more efficient transmission, less restrictions in terms of options, and more adaptability to introduce new options in the future. The ability of the data stream tag adds a new ability to make those senders that are specially processed to "stream" packages can be attached to "labels", such as non-default quality services or "Real Time" services. Certification and confidentiality
Extensions for supporting authentication, data integrity, and (optional) data confidential are described in IPv6. This document describes the basic header of IPv6 and the initial defined IPv6 extended header and options. The size of the package is also discussed, the grammar of the data stream label, and transfer category, and the impact of IPv6 on the upper protocol. The format and syntax of IPv6 addresses are separately illustrated in other articles. IPv6 version of ICMP is included in all IPv6 applications. 2. the term
Node - A device for applying IPv6. Router - Transfer is not a node that is sent to your IPv6 package. [See the description of the following] Host - any non-router node. [See the following description] The upper layer - the protocol layer directly on the IPv6. Typical examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and network layers or low-level protocols that are opened in IPv6 (also packaged in IPv6), such as IPX, AppleTalk or IPv6 itself. Link - a communication device or media. It is possible to communicate with the link layer through its node, that is, communicating directly below IPv6. Typical examples are "simple or bridges), PPP connections, X.25, frame relays, or ATM networks and" channels "of network layers (or higher). For example, through IPv4 or IPv6 itself. Neighbor - connect the node on the same link. Interface - Node Connection to the link. An interface or a set of interfaces in the address-IPv6 layer. Package-IPV6 first plus valid data. Link MTU - Maximum Transmission Unit. That is, the maximum size of the package that can be transmitted in the link in the eight-bit group. Path MTU - The source node to the smallest link MTU of all links in the path between the destination nodes.
Note: Although it is not common, this is possible: it is a device with multiple interfaces, used to transfer some (not all) interfaces from it, do not use the package of itself, and abandon those from Other interfaces, no packages that do not use itself. When such devices receive packages through the previous interface or contact their neighbors, it must follow the requirements of the router in the protocol. When it receives the package or contacts its neighbors through the latter interface, it must follow the requirements of the host in the protocol.
3. IPv6 first format
version
4-bit Internet protocol version number = 6.
Transmission category
8-bit transfer category field.
Data flow label
20 data flow labels.
Valid data length
16-bit unsigned integer, IPv6 valid data length. That is, in the eight-bit group, in the length of the remainder behind the IPv6 in this package. (Note that the first extension will be considered part of the valid data, calculated in length)
Next head
8-bit selector. Identify the type of next header next to IPv6 headers. Use the same value as the IPv4 protocol field.
Humping limit
8-bit no symbol integers. Decrement 1 at each node that is transmitted this package. Such as
If the number of hops is limited to zero, you will discard this package.
source address
The address of the 128-bit package producer.
Destination address
The address of the 128-bit package is the address of the recipient (if there is a routing head, it may not be the final recipient).
4. IPv6 extension The first in IPv6, optional network layer information is encoded in an independent header, placed between IPv6 in the package and the upper layer protocol header. There are several few uncommon extensions, each of which is identified by different "next head". An IPv6 header can carry zero, one or more extension first, each extension first, identified by the "next head" field in the previous head. As shown in the following example: In addition to a special case, the extended header is not detected and processed in any node in the transfer path of the package until this package reaches the node identified by the destination address field (or in the case of multicast, each of the set of nodes) One). Here, the regular processing of the "next head" field of the IPv6 head will be to call the processing module to process the first extension header, or if there is no extension header, the upper layer is processed. Each extension header content and semantic decide whether to handle the next head. Therefore, the extended first must be processed in strict accordance with them appear in the package; so that the recipient cannot search the entire bag to find a particular type of head, and process it before processing all the first front. The special case described above refers to the top of the HOP-BY-HOP option. It carries information of each node in the transfer path of the package that must be detected and processed, including the source node and destination node. If the HOP-BY-HOP option is in the forever, it must be followed behind the IPv6 head. The value of the "next head" field in the IPv6 first means this header. If a header processing requires the node to process the next header, but the node cannot identify the "next head" field value of this header, then the node should abandon this package, and send a source node to the package to send an ICMP "parameter problem" Packet, ICMP encoded value is 1 ("" "encountered unrecognizable 'next header' type"). The ICMP pointer field contains the offset that cannot be identified in the original package. If the node encounters the value of the "next head" field outside the other head other than the IPv6, the same processing should be made. In order to maintain 8 eight groups behind the first part, each extended first part is an integer multiple of eight eight groups. Multi-eight-bit fields of each extended head are aligned in their natural borders. That is, the width is the field of n eight-bit groups in the position of the integer times of n eight-bit groups at the beginning of the header, where n = 1, 2, 4, or 8. A complete IPv6 implementation should contain the following extended handlers:
Hop-by-hop option header routing head (Type 0) Split First Destination Address First Certification First Package Safety and Effective Data First (ESP Head) 4.1 Extended First
When using more than one expansion first in the same package, it is recommended to arrange these headings in order in order:
IPv6 first HOP-BY-HOP option first destination address option header (Note 1) Routing first slice first authentication head (Note 2) Package safety and effective data header (Note 2) Delivery address option header (Note 3) The first protocol head
Note 1: Options of the first destination address processing in the subsequent address listed by the IPv6 destination address field and the routing address. Note 2: Additional recommendations for the relevant order of the initial and package safety and effective data headers see other literature. Note 3: Options for processing only by the final destination address of the package. In addition to the first two times in the first part of the destination address option (before the routing of the routing), each extension should only appear once. If the upper layer protocol is the first IPv6 (in the case of using channel technology or package in IPv6), it can have its own expansion first. These extensions are arranged independently in the same suggestion. If other extension headers are defined, the order limitations associated with the extended headings listed above must be described. In addition to hop-by-hop options, the IPv6 nodes must be accepted after the IPv6 header, and to handle any order, and the extension first in the same package. Nevertheless, it is recommended that the source node of the IPv6 package comply with the above suggestion order unless the subsequent protocol specification is modified. 4.2 Options The currently defined extension first: Hop-by-hop option header and destination address option header, the options for encoding uncertain numbers, the type--length-value (TLV) format, the format is as follows: Option type
8-bit identifier, identify the type of option.
Option data length
8-bit no symbol integers. The length of the option data field in the eight-bit group.
Option data
Variable length field. Different data depending on the type of item.
The options in the head must be processed in strict accordance with them in the first order; this, the receiver cannot search the entire first part to find a particular type of option, and process it before processing all the previous options. The option type identifier is encoded as follows: its maximum two specify the reaction required when IPv6 nodes cannot identify this option:
00 Skip this option and continue to process the head. 01 Abandon this package 10 Abandon this package, and no matter whether the package's destination address is not a multicast address, the source address of the package is sent to the packet, and there is a problem with the encoding 2, the pointer points to the type of option that cannot be identified. 11 Abandon this package, and only when the packet is not a multicast address, the source address of the package will send an ICMP "parameter problem", encoding 2, pointer points to the type of option that cannot be identified.
The third bit of the option type identifier indicates whether the option data can be changed to the selection of the final destination address. If there is an authentication header, when the package calculation or check the authentication value, the entire data field that can be changed to the selection must be treated as a total eight-bit group. 0 - Options Data does not change the route 1 - Option Data may change the first three digits of the selection as part of the option type, and cannot be independent of the option type. That is to say, a particular option is identified by all 8-bit option type identifier, not just the back 5 digits in the option type. Hop-by-hop option The header and destination address option will use the same option type encoded space. Despite this, specifications for a particular type of option can limit it only one of them. Some options may have a clear alignment request to ensure that the multi-eight-bit group values in the Option Data field can fall on its natural boundary. The alignment of the option requires the symbol xn y, indicating that the option type must appear on the integer multiple of the X eight-bit group from the first start position. For example: 2N means an offset of an integer multiple of 2 eight-bit groups from the beginning. 8N 2 indicates that an integer multiple of 8 eight-bit groups from the beginning of the first end plus two eight-bit offset. There are two fill options to align the subsequent options when needed, and the entire first filled into 8 eight-bit groups. All IPv6 implementations must be able to identify these fill options. Fill 1 Option (Alignment Requirements: None) Fill 1 Option is a special case - it does not have a length field and a numeric field. Fill 1 options are used to populate an eight-bit group in the first option area. If you need to fill more than one eight-bit group, you should use the padding n option you want to introduce instead of multiple padding 1 options. Fill n option (alignment requirements: None) The padding n option is used to populate two or more eight-bit groups in the first option area. For N-eight-bit groups, the option data length field should contain value N-2, and the option data consists of n-2 zero value eight-bit groups. 4.3 Hop-by-Hop Option Header HOP-BY-HOP Option The header is used to transmit optional information that must be detected by each node in the transfer path of the package. The Hop-By-Hop option is identified by the "next head" field value in the IPv6 header, and has the following format: the next head
8-bit selector. Identify the type of the head in the back of the Hop-By-Hop option. Use the same value as the IPv4 protocol field.
First expansion length
8-bit no symbol integers. The length of the beginning of the hop-by-hop option in 8 eight-bit groups does not include the starting 8 eight-bit groups.
Option
Variable length field, its length must make the length of the entire HOP-BY-HOP option in the length of 8 eight-bit groups. Contains one or more TLV encoding options, as described in Chapter 4.2.
Only the HOP-BY-HOP options defined herein are filled 1 and padding n options. 4.4 Routing the first routing header The IPv6 source node lists one or more intermediate nodes of "Access" in the path to the destination node of the package. This feature is very similar to the loose source address of IPv4 and routing options. The value in the "next head" field in the first part is 43 indicates that the next first first is the routing head. The routing head has the following format:
Next head
8-bit selector. Identify the type of the head behind the routing head. Use the same value as the IPv4 protocol field.
First expansion length
8-bit no symbol integers. The length of the beginning of the routing of 8 eight-bit groups does not include the starting eight eight-bit groups.
Routing type
The 8-bit certain specific route identifier of the first variable.
Segmentation remaining
8-bit no symbol integers. The number of remaining routing segments. That is, the number of intermediate nodes should be discounted before they can be accessed before reaching the final destination node.
Specific type of data
Variable length field. The format is determined by the route type, and its length must make the length of the entire routing of 8 eight-bit groups.
If the node encounters the routing of the routing type value containing the unrecognized routing, the node should be processed according to the value in the segment remaining field, as described below: If the residual value of the segment is zero, the node The routing header must be ignored, the next header in the process of processes the package, which is identified by the value in the "next head" field in the routing header. If the residual value of the segment is not zero, the node must discard this package, and send an ICMP "parameter problem", code encoding 0, and pointer points to the type of routing that cannot be identified. If the intermediate node is processed after processing the routing header, it should be sent to a link MTU less than the size of this package, then the intermediate node must discard this package, and send a ICMP "package for the source address for the package." "Packets. The routing of type 0 has the following format: the next head
8-bit selector. Identify the type of the head behind the routing head. Use the same value as the IPv4 protocol field.
First expansion length
8-bit no symbol integers. The length of the beginning of the routing of 8 eight-bit groups does not include the starting eight eight-bit groups. For the routing of type 0, the first extension is equal to twice the number of addresses in the head.
Routing type
0
Segmentation remaining
8-bit no symbol integers. The number of remaining routing segments. That is, the number of intermediate nodes should be discounted before they can be accessed before reaching the final destination node.
Reserve
32-bit reserved fields. The transmission is initialized to zero; negligible when receiving.
Address [1..n]
128-bit address vector, from 1 to n.
The multicast address is not allowed to appear in the routing of type 0, nor is it allowed in the IPv6 destination address field in the packet carrying type 0 routing. The nodes identified until the package reaches the destination address field identified by the IPv6 is detected and processed. In this node call the routing first processing module, and for routing type 0, the following algorithm is performed: IF segment remaining = 0 {
Continue to process the next head in the package, its type identifies by the "next head" field in the routing header
}
Else if the first extension length is odd {
Send the source address to the ICMP "Parameter Existence Problem", encoded 0 packets, pointer points to the first extension length field, and discard this package
}
Else {
Calculate N, which is the number of addresses in the routing header. The method is the first extension length divided by 2
IF segment remaining than n {
Send the source address to the ICMP "parameter problem", encoding 0 packets, pointer points to the residual field, and discard this package
}
Else {
Segmentation remaining;
Calculate I, which is the next address to "access" in the address vector (address list), the method is the remaining segment remaining
IF address [i] or IPv6 destination address is multicast address {
Abandon this package
}
Else {
Exchange IPv6 destination address and address [i]
The IFIPv6 hop limit is less than or equal to 1 {
Send a message to the source address to "timeout-transmission exceeding the hop limit", and discard this package
}
Else {
The number of hops is limited;
Re-submit this package to the IPv6 module, pass it to the new destination node
}
}
}
}
As an example of the above algorithm, considering such a case: The source node S transmits a packet to the destination node D, and the packet is passed through intermediate node I1, I2, and I3. In each paragraph of the transfer path, the relevant field values in the IPv6 header and the routing header value should be as follows:
When the package is transmitted from S to I1: source address = s destination address = i1
First expansion length = 6
Segmentation remain = 3
Address [1] = i2
Address [2] = i3
Address [3] = D
When the package is passed from I1 to I2: source address = s destination address = i2 first expansion length = 6
Segmentation remain = 2
Address [1] = i1
Address [2] = i3
Address [3] = D
When the package is passed from I2 to I3: source address = s destination address = i3
First expansion length = 6
Segmentation remain = 1
Address [1] = i1
Address [2] = i2
Address [3] = D
When the package is passed from I3 to D: source address = s destination address = D
First expansion length = 6
Segmentation remaining = 0
Address [1] = i1
Address [2] = i2
Address [3] = i3
4.5 Splitting The first IPv6 source node uses a slice header to send a package greater than the path MTU that go to the destination node. (Note: Different from IPv4, in IPv6, only the source node of the package can make slice, the router in the transfer path cannot perform fragmentation? See Chapter 5) In the first part of the "next head" field The value is 44 indicates the next first first part of the slice. The first part of the fragment has the following format:
Next head
8-bit selector. Identify the type of the initial header of the gravizable portion in the original package (later definition). Use the same value as the IPv4 protocol field.
Reserve
8 reserved fields. The transmission is initialized to zero; negligible when receiving.
Split offset
13-bit unsigned integers. In 88-bit groups, the headed data is at the offset at the start position of the gravizable portion in the original package.
RES (reservation)
2 reserved fields. The transmission is initialized to zero; negligible when receiving.
M flag
1 = There is also a fragmentation; 0 = last fragmentation.
Logo
32-bit. See the description below.
To send a packet greater than the path MTU of the destination node, the source node can be divided into several shards, each segmentation separately, and restructuring at the recipient. Source nodes should specify a identifier value for each package that points. This identification value must be different from the identification value of other fragmentation packages between the same pair of source nodes and destination nodes. If there is a routing header, the destination node refers to the final destination node. "Recently" is a maximum survival of the package. This includes the time of transmission time from the source node to the destination node, and the time taken to wait for the other fragment reorganization of the same package. Despite this, the source node does not necessarily know the maximum survival of the package. It simply uses the identification field value as a simple 32-bit loop counter, and each time the wrapper is slidably added to an increment. Specific implementation can choose to maintain a counter or multiple counters, but also to maintain a counter for each node, or to maintain a counter for each activity (source address, destination address). Initially, the big data package of unsailed slices is called "original package". The original package can be regarded as consisting of two parts, as shown below: Original Package: The inseparable portion includes the IPv6 header, and those that must be processed by the routing. That is, the following three situations: All routing heads previous (if existing), or if there is a Hop-Hop option, or if there is no extension. The remaining parts in the package are the fragmented portion, that is, the extension header that is only processed by the final destination node of the package, as well as the upper layer protocol header and data. The fragmented portion in the original package is divided into several shards, removes the last ("right") a fragment, each of which is an integer multiple of 8 eight-bit groups. These fractions are transmitted from each other "fragmentation package", as shown in the following example: Original Packet: Split Pack: The fractional packet is composed of the following sections: (1) The unsangible portion in the original package. Among them, the original IPv6 header value should only contain the length of the slice package (not including the length of the IPv6 head). The "next head" field value in the inseparable portion is changed to 44. (2) Split the head. These include: its "next head" value identifies the first header of the segmented portion in the original package. The fractional offset field includes an offset at the start position of the slice portion in the original packet in eight eight-bit groups. The first ("left") fragmentation of the fragmentation is 0. Its M flag is 0 indicates that this is the final ("rightmost") a shard, otherwise the M flag is 1. Its identification value is generated according to the original package. (3) The length of the fragmentation of the slices should make the size of the fragmentation package suitable for the path MTU to the destination node. At the destination node, the fragmentation package is recombined into the form of the original unparalleled film, as shown in the following example: The original package of the recombination: Recombination should follow the principle: the original package can only be divided by the same source address, destination address, and fragmentation Slice recombination. The non-fragmented portion in the recombinant package is composed of all the first slices (which is the package of the fragmentation offset is 0), and as the following Two modifications: From the "next head" field in the slice header of the first fragmentation, the "next head" field value is obtained in the last header of the unparalleled part. The length and offset of the length and the offset of the final fragmentation are calculated from the length and offset of the length and the offset of the final fragmentation. The formula for calculating the valid data length of the restructure package is: Pl.orig = pl.First - fl.first - 8 (8 * fo.last) fl.last pl.ORIG = Restructive package valid data length field. Pl.first = The valid data length field of the first fragment package. Fl.first = The first slice length in the first slice packet. FO.last = Fragmentation offset field of the final piece in the last slice package. Fl.last = Fragmentation length behind the final fragmentation package. The sequential part of the recombinant package is composed of a fragmentation of the heads in each fragmentation package.
The length of each fragment can be subtracted from the valid data length of the slice package to be calculated by the length of all the first part of the IPv6 in this package. The relative positions of each slice in the slightly fragmented portion are calculated from the fragmentation offset. The final reorganized package does not contain a fragmentation. The following error scenarios may occur: If the first (arrived by the first (arrived) slice is received 60 seconds after 60 seconds, it is necessary to terminate this reorganization, abandon all received Pack. If the first fragmentation is received (which is the fragmentation of the fragmentation offset is zero), an ICMP "timeout-fragment reorganization timeout" message should be sent to the source node of the fragmentation.
If the slide length obtained by the valid data length field of the fragmentation is not an integer multiple of 8 eight-bit groups, and the M flag bit of the fragmentation is 1, then this fragmentation must be discarded, and the source of the fragmentation The node sends an ICMP "parameter existence problem", encoding 0 packet, pointer points to the valid data length field of the slice package.
If the length and offset of the fragment make the valid data length of the recombinant package exceed 65,535 eight groups, then this fragmentation must be discarded, and there is a problem with the source node of the fragmentation, "encoding 0 packets, pointer points to the fragmentation offset field of the fragmentation package. Do not want the following scenarios, but do not treat them as errors:
Among the different fractions of the same original package, the heads of the first part of the fragmentation may differ in quantity and content.
When each slice is reached, no matter what the first part of the slide header, it should be processed before entering the slice reorganization queue. Only the first package of the fragmentation offset is zero only retains the reorganized package.
Among the different fractions of the same original package, the "next head" value in the fragmentation is different. The value in the package that only the fragmentation offset is zero can be used to reorganize. 4.6 Destination Address Options The header of the destination address option is used to carry optional information that is only detected by the destination node of the package. The value in the "next head" field in the first header indicates that the next head is the first part of the destination address option. The first part of the destination address option has the following format:
Next head
8-bit selector. Identify the type of the head that keeps followed in the first part of the destination address option. Use the same value as the IPv4 protocol field.
First expansion length
8-bit no symbol integers. The length of the first 88-bit groups is not included in the first part of the destination address option of 8 eight-bit groups.
Option
Variable length field, its length must make the length of the entire destination address option 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 destination address options defined herein are filled 1 and fill n options, as described in Chapter 4.2. It should be noted that there are two ways to encode the optional information of the destination address: or as an option in the first part of the destination address option, or as an independent extension header. The first part of the fragmentation and the first part of the latter is a typical example of the latter. Using which method depends on the destination node, it is desirable to take the measures that you want to take: o If you want the node to abandon this package, and when the package's destination address is not a multicast address, a source address is sent an ICMP. "Type Unrecognizable" packets can encode this information into an option in the independent extension header or destination address option, the highest of the option type is 11. The final selection can be determined according to other factors, such as which one can use less eight-bit groups, which can generate better alignment or higher processing efficiency. o If you want to take other measures, then this information must be encoded as an option in the first part of the destination address option. The highest two digits of its option type are 00, 01 or 10, and the measures you need are specified. 4.7 "No Next" IPv6 "The" next head "is 59 indicates that there is no other first behind this head. If the valid data field in the IPv6 first indicates the last head ("The next head" field is 59, there are other eight groups, then these eight groups will be ignored and remain not in the transmission process. change. 5. The size of the package IPv6 requires each link on the Internet with a 1280 or more eight-bit group of MTUs. Unable to deliver 1280 eight-bit groups within a piece must provide fragmentation and reorganization mechanisms in the IPv6 under the protocol of the link. A link (such as the PPP link [RFC-1661]) that can be configured (such as PPP link [RFC-1661]) must be configured with an MTU of at least 1280 eight-bit groups; it is recommended to have an MTU having 1500 or more eight-bit groups, which can be accommodated The package (that is, "channel") and is not slid in IPv6 protocol layers. The node directly connected to the link must be able to receive the link of the link MTU size. It is recommended that the IPv6 node uses "Path MTU Discovery" technology [RFC-1981] to find a larger path MTU than 1280 eight-bit groups, and exert its advantages. However, a minimal IPv6 implementation (such as in the ROM) can simply limit the package that only transmits less than 1280 eight-bit groups, ignoring the "Path MTU discovery" technology. To send a package greater than the path MTU, the node can use the IPv6 fragment header, slide the package in the source node, and reorganize the package in the destination node. However, if the application can adjust the size of the package to fit the standard path MTU, it is best not to use fragmentation. The node must be able to receive a slice package of 1,500 eight-bit group after receiving the recombination. At the same time, the node is allowed to receive a slice package greater than 1500 eight-bit groups after reorganization. The upper layer protocol or application based on the packet larger than the path MTU is transmitted to the IPv6 fragment, and the package is not transmitted more than 1500 eight-bit groups unless it is aware of the destination node. As a response to the IPv6 packet (which is converted from IPv6 into IPv4), IPv6 initial nodes may receive the ICMP "Baby" message, and the next hop MTU is less than 1280. In this case, the IPv6 node does not have to decrease the size of the subsequent packets below 1280, but must include a slice first in these packets, enabling a router responsible for converting between IPv6 to IPv4 to get an appropriate identifier. Value, used to generate IPv4 shards. It should be noted that this means that the effective data will be reduced to 1232 eight groups (1280 minus the 40 and fragmentation of the IPv6 header 8), if there are other extension heads, valid data will become more small. 6.
Data Stream Label IPv6 First 20 Bit Data Signature Signature Fields are used for source nodes identify sequences that require IPv6 routers specially processed, such as non-default quality services or "real-time" services. This article is generated, IPv6 is still in this experimental phase, and as the requirements on the Internet support data streams are getting clearer, it may also have changed. Hosts and routers that do not support the data stream signature feature should set this field to zero when initialize the packet, and remain unchanged when the transfer package is transferred. When the package is received, it is ignored. 7. Transmission Category IPv6 Thermal transfer category fields can be used for initial nodes and / or forward router identity and distinguishing between different IPv6 packages or priorities. When writing this specification, several experiences in the process of using IPv4 service types and / or priority bits (used to provide different forms of different forms ", differently than explicit establishment data flows) The transfer category field in the IPv6 head provides a similar function in IPv6. It is hoped that these experiences have enabled in which transmission classification has agreed on the most useful issues of IP packages. Detailed definitions of all or part of the data bits in the IPv6 transfer category, or experimental or final criteria, will be provided in additional articles. Below is a general request that the transfer category field should meet: O Node The service interface of the IPv6 service must specify a method of providing a transmission category data bit to the initial package to the initial package. o Nodes of a particular (experimental or final standard) usage of partial or all transfer category data bits can modify the values of these bits in which they generated, transmitted or received in their use. If the node does not support this, these bits should be ignored, and keep their values unchanged. o The upper protocol should not assume that the value of the transmitted category data bit in the received package is the same as the value of the source node. 8. Problem of the upper protocol 8.1 Upper-level protocol checks and transport layers or other upper-level protocols containing the address in the IP header when calculating the checksum must be transferred to the corresponding improvement through IPv6, change 32-bit IPv4 addresses to 128 Bit IPv6 address. In particular, the following example shows the IPv6 "false headers" of TCP and UDP: o If the IPv6 package contains a routing head, the destination address used by the pseudo head is the final destination address. In the initial node, this address is the last element of the routing head; one of the receiver, this address is in the destination address field of the IPv6 head. o The "next head" field value in the pseudo header identifies the type of the upper protocol (such as 6 is TCP, 17 UDP). If there is still an expanded header between the IPv6 header and the upper protocol head, the value of the "next head" field in the counterheader may vary with the value in the IPv6 header. o The length of the in-ordnance middle upper protocol package refers to the head and data of the upper protocol (for example, TCP's first plus TCP data). Some upper protocols carry their own length information (for example, the length field in the UDP header); for such a protocol, this information is the length information used by the pseudo head. Other protocols (such as TCP) do not carry their own length information, in which case the length used by the pseudo-headed part is the length of the valid data length field value in the IPv6 first subtracting the length of the IPv6 and the first protocol header. o Unlike IPv4, the UDP checksum is not optional when IPv6 nodes generate UDP packets. That is, as long as the UDP package is generated, the IPv6 node must calculate the UDP checksum of the packet and the pseudo head. Moreover, if the calculation result is 0, it must be changed to hexadecimal FFFF, put it in the UDP header. The IPv6 receives the Node must abandon the UDP package containing zero checksum and record this error. The IPv6 version of ICMP contains the above-described false header when calculating the check, which is a different place in the IPv4 version - IPv4 version does not contain the pseudo head in the checksum.
The reason for changes is to prevent the incorrect transmission of ICMP, and these fields in the IPv6 first occurred - they are not protected by network layer checksum. The value of the "next head" field in the pseudo-head of ICMP is 58, identifies IPV6 version of ICMP. 8.2 The maximum survival period of the package is different from IPv4. The IPv6 node does not have to force a maximum survival of a package. This is why the "Survival" field in IPv4 is renamed "Humping Limit" in IPv6. In practice, IPv4 achieves rarely enforcement of restrictions to restrict the survival period, so this is actually not changed. Any upper protocol that relies on the network layer protocol (IPv4 or IPv6) to restrict the survival of the package must be upgraded, providing the mechanism of detecting and abandoning expired packets. 8.3 The maximum effective data size of the upper protocol When calculating the maximum effective data size of the upper layer protocol data, the upper protocol must take into account the top of IPv6 than IPv4. For example, in IPv4, the TCP's MSS option is the maximum size of the package (default or value provided by the path MTU discovery technology) minus 40 eight groups (IPv4 first minimum length 20 and TCP header minimum length 20 ). When using TCP via IPv6, MSS must be changed to the maximum size of the package to reduce 60 eight groups, because the minimum length of the IPv6 header (iPv6 in the first) is the minimum length of the IPv4 first. Eight groups. 8.4 Response of the packet carrying the routing header should send one or more packets as a response to the packet containing the routing head, and the response package cannot contain a route that is automatically obtained by the received routing header "reverse". capital. Unless the integrity and reliability of the source address and routing headers have been verified (such as by using the authentication head in the received package). In other words, only the following types of packages can respond to packets orientations of routing heads: O does not carry the response package of the routing head. o Carry the response package of the routing head, but the routing of the route is not reflected in reverse from the routing the routing in the package (for example, the routing header provided by the local configuration information) O carries the routing header response package, The routing header is obtained by the routing the routing in the package. However, the integrity and reliability of the source address and routing in the package received must be verified by the responder. Appendix A. The semantics and usage data stream of the data stream label field refers to the sequence of the packet sent from a particular source node to a particular (unicast or multicast) destination node. Data streams can be used when the source node wants to perform some special processes in the middle of the router. The species of this special treatment can be transmitted to the router, such as a resource appointment protocol, such as a resource appointment protocol, or information in the packet in the data stream, as an option in the HOP-BY-HOP option header. The details of this control protocol or option have exceeded the scope of this article. There may be data streams from the source node to the destination node, and there may be a traffic that is independent of any data stream. A data stream is uniquely identified by a source address and a non-zero data stream tag. The package with zero value is not belonging to any data stream. The data stream is assigned a data stream tag for the source node of the data stream. The new data stream label must be randomly selected from 1 to FFF (hexadecimal). The purpose of the random allocation data stream label is to enable the router to use any of the data stream tag fields as a hash keyword, to query the status associated with the data stream. Packets belonging to the same data stream must have the same source address, destination address, and data stream tag. If some of them contains the HOP-BY-HOP option head, they must have the top of HOP-BY-HOP options in the same content (in addition to the "next head" field in the Hop-By-Hop option). If some of them contains the routing head, they must be the same before the routing header (including the routing head), must be the same (except "the next head" field in the routing). Allow but does not require the router or destination node to verify that the above conditions are met.
