Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: cata_xu (cata_xu amethyst@theory.issp.ac.cn)
Translation time: 2001-9-11
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must
Keep the translation and copyright information of this document.
Network Working Group S. DeERING, XEROX PARC
Request for Comments: 1883 R. Hinden, Ipsilon NetWorks
Category: Standards TRACK DECEMBER 1995
Internet Agreement, Version 6 (IPv6) Manual
(RFC1883 - Internet Protocol, Version 6 (IPv6) Specification)
The state of this memo
This document tells the Internet standard tracking protocol of an Internet community, which requires further discussion and construction.
It is improved. Please refer to the latest version of the Internet Formal Protocol Standard (STD1) to get the standardization of this agreement.
The degree and state. The release of this memo is not restricted.
Summary
This document details Internet Protocol Version 6 (IPv6), and sometimes it is also a next-generation IP or IPNG.
Table of contents
table of Contents
Introduction 2
2. Terminology 3
3. IPv6 header format 3
4. IPv6 expansion header 5
4.1 Extended header sequence 6
4.2 Options 7
4.3 Topbele Options Head 8
4.4 Routing Head 10
4.5 Split Head 14
4.6 Destination Options Header 18
4.7 No next header 19
5. Group size problem 19
6. Flow label 20
7. Priority 21
8. Upper level agreement 22
8.1 upper checksum 22
8.2 Maximum Grouping Survival Period 23
8.3 Maximum upper payload size 23
Appendix A Format Guide Policy 24
Example 1 24
Example 2 25
Example 3 26
Safety considerations 26
Acknowledgments 27
Reference 27
1 Introduction
IP version 6 (ipv6) is a new version of the Internet protocol, which is set up as a follow-up of IP version 4 (IPv4) [RFC-791]
meter. Changes between IPv4 to IPv6 can be simply broken down to the following range:
o Extended address characteristics
IPv6 expands IP address size from 32 bits to 128 to support more address level, more address nodes
In
And the simpler address is automatically configured. The measurementability of broadcast routing is by increasing a "range" used to broadcast addresses.
The domain is improved. IPv6 defines a new address called "any address", usually used to send a group to
Any one in a set of nodes.
o Snapup format
Some IPv6 headers have been removed or optionally to reduce the universal events of the packet handles and
Process overhead has restricted bandwidth overhead of IPv6 headers.
o Improve support for extensions and options
Changes on the IP header option coding take into account more effective forwarding, less restrictions on the options and future
Greater flexibility in the new option.
O stream tag characteristics
IPv6 adds a new feature that can be required to require special handle senders, non-default or "real-time" services, which belong to a particular communication "stream".
o Identification and privatization characteristics
Extension to support identification, complete data, and (optimized) data confidentiality is IPv6 unique.
This document details the basic IPv6 header and the initial defined IPv6 extension header and option, and also discusses the packet size.
Questions, stream labels and priority semanties and IPv6 in the upper protocol. IPv6 address format and semantics
Described in [RFC-1884]. ICMP IPv6 version is illustrated in [RFC-1885], where all IPv6
It is now required to include.
Term
Node - Equipment that implements IPv6.
Router - A forwarding does not clearly point to its own IPv6 packet. [See the attention below]
Host - any node that is not a router. [See the attention below]
The upper layer - next to the previous protocol layer of IPv6. Examples are transport protocols such as TCP and UDP, control protocols such as
ICMP, routing protocols such as OSPF and Internet or low-level as "tunneling" (ie packaging)
IPv6 protocols such as IPX, AppleTalk, or IPv6 itself.
Link - a communication facility or medium that can communicate with a node that communicates with the link layer (i.e., one layer of IPv6).
Examples are Ethernets (simple or bridged), PPP links, X.25, frame relays, or
ATM network, and "tunnel" in the Internet, such as tunneling IPv4 or IPv6 itself.
Neighbor - Node connected to the same link.
Interface - Node Connection Settings to a link.
Address - an IPv6 identifier for an interface or a set of interfaces.
Group - coupled with the IPv6 header of the payload.
Link MTU - a maximum transmission unit that can be transported on a link, that is, the maximum size of the eight-bit byte packet.
Path MTU - The minimum link MTU of all links in the path between the source node and the destination node.
Note: Although some are unusual, but configure it into some interface groups for multiple interfaces.
(Less than all) from the non-own predetermined grouping, and abandon the non-own predetermined packet arriving from other interfaces.
possible. Such settings when receiving a packet with a front (being forwarded) interface and the neighbor interact
It is necessary to follow the routing protocol requirements. When you receive the interface from the latter (non-forward) and the neighbors
Such devices must follow the protocol requirements of the host when used.
3. IPv6 header format
- - - - - - - - - - - - - - - -
| Version | Priority | Distance |
- - - - - - - - - - - - - - - | True load length | Next header | Jump limit |
- - - - - - - - - - - - - - - -
| | |
| | |
Source address
| | |
| | |
- - - - - - - - - - - - - - - -
| | |
| | |
Destiny Address
| | |
| | |
- - - - - - - - - - - - - - - - version 4 Internet protocol version number = 6
Priority 4 bit priority. See Section 7.
Stream label 24 bit flow label. See Section 6.
The length of the payload is 16-bit no symbol integer, the length of the payload, that is, the grouping part of the IPv6 header is eight
Bit byte form. If it is zero, it means that the payload length is carried in a huge effective
Loads in the tap.
The next header 8-bit selector. Identify the header of the IPv6 header. And IPv4 protocol domain
of
Is the same value [RFC-1700 later is described later].
]
The next hop is limited to 8-bit unsigned integers, and each node that is forwarded to this group is subtracted. If the next hop is limited
This packet is abandoned if it is reduced to zero.
The 128-bit address of the source address packet originator. See [RFC-1884].
The destination address group specifies the 128-bit address of the recipient (if a routing header appears, may not
Is the final recipient). See [RFC-1884] and 4.4.
4. IPv6 extension header
In IPv6, optional Internet layer information is encoded in a separate header, which may be in group IPv6
Between the header and the last layer. There is a small amount of this extension header, each being identified by a clear next report.
As in these examples, IPv6 packets can have zero, one, or more extended headers, each packet is
The next header field of the previous header:
--------------------------------------
| IPv6 header | TCP header data
| | |
| Next header = |
| TCP |
--------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------
| IPv6 header | Routing header | TCP header data
| | | | |
| Next header = | Next header = |
| Routing | TCP |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - -----------------
| IPv6 header | Routing header | Split header | TCP slide
| | | | Header Data
| Next header = | Next header = | Next header = |
| Routing | Segment | TCP |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - ----------------- There is an exception, unless the group arrives in a node that is identified in the address domain of the IPv6 header (or in a set of nodes)
Each, passed in the form of multicast), otherwise the extended header will not be along any node on a packet transfer path.
Check or handle it. In this way, if there is no extended header, then normal multiplex decomposition on IPv6 next header field
This module will be stimulated to deal with the first extended header, or to process the upper header when the extended header does not appear.
The content and semantics of each extended header decide whether to continue to the next header. So the extended header must strictly press them.
Process it in the order in the group. For example, a receiver cannot find a special purpose by scanning a packet.
Other extended headers and take precedence to all previous groups to process it.
The exception mentioned in the previous paragraph is a header option header, and the information carries must be along the packet transfer path.
The node is handled, including the source and destination address. The IPv6 must be immediately then the IPv6 header when the header appears. its
The appearance of the value zero in the IPv6 next newspaper field.
As a result of processing a header, if a node continues to pass to the next header but in the current header
The header value is not recognized by the node, the node will discard the group and send an ICMP parameter information, including an ICMP editor.
Code value 2 (meaning "encounter" unopened next header type ") and compensation for unfounded values in the original group
ICMP pointer domains to packet source. If a node encounters the next report value of zero in a non-IPv6 header, the same
Measures will also be taken.
Each extension header is an integer multiple of 8 8-bit bytes, which is to reserve 8 8-bit bytes to the later header.
team
Column. Multiple 8-bit fields in each extended header are arranged on their original boundaries, namely n = 1, 2, 4, or
8 For n 8-bit bytes wide domains are placed on the N 8-bit bytes starting from the header.
A complete implementation of an IPv6 includes the implementation of the following extended headers:
Take an item
Routing (model 0)
Fragmentation
Purpose option
Authorize
Package safety payload
The four items will be detailed in this document, and the latter two will be described in [RFC-1826] and [RFC-1827].
4.1 Extended header order
When more than one expanded header is used in the same group, it is recommended that those headers appear in the following order:
IPv6 header
Take a header
Purpose option header (Note 1)
Routing header
Split header
Authorized header (Note 2)
Package safety payload (Note 2)
Purpose option header (Note 3)
Upper header
Note 1: Refers to the options that will be processed by the first destination address, this destination address appears in the IPv6 destination address
The options in the domain should be added to the routing header.
Note 2: Consider the additional recommendation of the authorization and package safety payload header related sequence is given in [RFC-1827].
Note 3: Refers to options that will only be handled only by the final destination.
In addition to those destination options, the header will appear twice (before the routing header, the other before the upper stage), each
An extension header will appear at most once.
If the upper header is another IPv6 header (in IPv6 is tunneled or encapsulated in IPv6), then it can
It can be followed by its own extended headers, these two headers belong to the recommendation of the same level.
If otherwise, if other extensions are defined, they must be described in order to constrain the sequence constraints of the headers listed above.
.
In addition to only constraints, IPv6 nodes must accept and tries immediately outside the step-by-step option header after IPv6 header.
The drawing processes an extended header in any order in the same group. However, adhesive proposed order IPv6 packets have been carefully considered until they can revise the recommendation order unless they will be revised.
4.2 Options
Two extended headers currently defined - Top option headers and destination options - The following formats are encoded
Type length value for "option" (TLV) variable
- - - - - - - - - - - - - - - - - -
| Option Type | Option Data Length | Option Data
- - - - - - - - - - - - - - - - - -
The 8-bit identifier of the option type option type.
Option data length 8-bit unmarked integer. The option data length domain of this option is in the form of an 8-bit byte.
Option data variable length domain. Option type precise data.
The option option in the header must be processed in the order in which they appear in the header; for example, a recipient
You cannot search for a header to find a special option and processed priorlicate before processing all the options preceded.
The option type identifier is inherently encoded so that if the node that is being processed, the option type is not recognized.
Identifier is the highest word energy to explain this behavior.
00 - Skip this option and continue to process the header.
01 - Abandon this group
10 - Abandon this group and whether this group destination address is not a broadcast address to send an ICMP parameter
Question (Code 2) Packet gives the source address of the packet to indicate the type of options that are not recognized.
11 - Abandon this group and only send ICMP parameters when the group destination address is not a broadcast address
(Code 2) The packet gives the source address to indicate the type of options that are not recognized.
The third highest bit byte of the option type indicates whether the option data of that option can change the last middle-line selection to the group.
purpose. When the authorization header appears in the group, for any of its data, it may change the option of the intermediate selection.
It must be seen as a zero-value byte when calculating or verifying the grouping authorization.
0 - Option data does not change the intermediate selection
1 - Option data must change the intermediate selection
A single option may have a special queue requirement to ensure that the multi-byte value in the option data field points to the original boundary. An option
The queue requirement is specified by using symbol XN Y, meaning that the option type must appear from the beginning of the header.
X byte multiplied integer plus Y bytes. E.g:
2N means any two 8-bit bytes from the beginning of the header.
8n 2 means any 8 8-bit bytes from the beginning of the header plus 2 8-bit bytes.
When you must arrange the later options and the heads included in the liner reach the multiple of 8 8-bit bytes in length,
Two filler options are used. These filler options must be recognized by all IPv6:
Filler 1 option (Queue requirements: None)
- - - -
| 0 |
- - - -
note! The format of the filler 1 option is a special form - it has no length and value domain.
The filler 1 option is used to insert an 8-bit byte packing into the selection area of the header. If you need more than one 8 digits
word
If the packing of the section, the filler n option is as mentioned below, and should be used instead of multiple packing 1 options.
Filler N option (Queue requirements: None) - - - - - - - - - - - - - - - - -
| 1 | Option Data Length | Option Data
- - - - - - - - - - - - - - - - - -
The filler n option is used to insert two or more 8-bit bytes of filler insertional sections. For n 8-bit bytes
For packing, the option data length domain contains a value of N-2, and the option data consists of an 8-bit byte of the N-2 zero value.
Appendix A contains the formatting wizard for design new options.
4.3 Take the header
Topbee option headers are used to carry optimized information that must be checked by each node of the packet transmission path. Take an item
The header is identified by the next header of the zero value with the IPv6 header, and has the following format:
- - - - - - - - - - - - - - - -
| Next report | Head extension length | |
- - - - - - -
| | |
.
Options.
.
| | |
- - - - - - - - - - - - - - - -
The next header 8-bit selector. Identify the header type of the header option header. use
And the same value of the IPv4 protocol domain [as described in RFC-1700].
The header extension is 8-bit unmarked integers. Topbele option header length is unit 8 bytes,
Does not include the first 8 bytes.
Option variable length domain, its length allows the topbeat option header integrity of 8 bytes
Multiplier. As in Section 4.2, one or more TLV encoding options are included.
In Section 4.2, there is an additional instruction to the filler 1 and the filler N, the following is the definition of the hop -oul option:
Giant Output Load Option (Queue Requirements: 4N 2) - - - - - - - -
| 194 | Option Data Length = 4 |
- - - - - - - - - - - - - - - -
Giant Treatment Load Demand |
- - - - - - - - - - - - - - - -
The giant profile option is used to send a payload greater than 65,535 bytes and IPv6 packets. Giant payload length
Is the packet length of bytes, remove the IPv6 header but including the header option header; it is more than 65,535
byte. If a packet and a giant active load option containing less than or equal to 65,535 bytes giant load length
If you received, then a code is zero and points to the ICMP parameter error in the high byte of the ineffective drainable load length domain.
The packet should be sent to the source of the packet.
The payload length domain in IPv6 should be set to zero in each packet carrying a giant valid load option. If group
And one code is received together with a current giant prosthetic load option and a non-zero IPv6 payload length domain, one code is zero
The ICMP parameter error message of the option type field pointing to the giant valid load option should be sent to the source of the packet.
The dramatic load option cannot be used in a packet carrying a slice header. If you contain a packet with a valid giant product load option
If you encounter a slice header, a code is zero and points to the ICMP parameter error message of the fragmentary header first byte shall be sent.
The source of the packet.
A implementation that does not support the giant payload option has an interface to the link, its link MTU is greater than 65,575 bytes (40 bytes)
IPv6 plus 65,535 bytes payload).
4.4 Route
The IPv6 source uses routing headers to list the intermediate nodes to "Access" on the address of the packet destination address. This function is
The source routing option for IPv4 is very similar. The routing header is determined by the next header of the continued head value of 43.
The format is as follows:
- - - - - - - - - - - - - - - -
| Next header | Head extension length | Route type | Leave part |
- - - - - - - - - - - - - - - -
| | |
.
Special type data.
.
| | |
- - - - - - - - - - - - - - - -
The next header 8-bit selector. Identify the key type of the routing header. And IPv4 protocol domain
The value is used [as described in RFC-1700]
Extended header length 8-bit unmarked integer. Routing header of 8 bytes, not including head 8 words
Section.
Routing type Specific routing header variable 8-bit identifier.
Left partial 8-bit unmarked integer. The remaining routing part is clearly listed in the most
The number of intermediate routes that still need to be accessed before the final place.
Special type data variable length domain, its format is determined by the routing type, and its length can make the complete
The routing header is an integer multiple of 8 bytes.
If the node is handling a routing header with unspected routing type when processing a packet, this node is
The required behavior relies on the legacy domain value as follows:
If the legacy part is zero, the node must ignore the routing header and continue to handle the next header in the group, this
The type of header is identified by the next news header field in the routing header.
If the legacy fragment is not zero, the node must discard this group and send code to zero and point to unforeseen routing types.
ICMP parameter error code message to the source of the packet.
Zero routing header type has the following format:
- - - - - - - - - - - - - - - -
Next header | Head extension length | Routing type = 0 | Levings section |
- - - - - - - - - - - - - - - -
| Predict | Strict / loose bitmap |
- - - - - - - - - - - - - - - - | |
|
|
Address [1]
| | |
| | |
- - - - - - - - - - - - - - - -
| | |
| | |
Address [2]
| | |
| | |
- - - - - - - - - - - - - - - -
.
.
.
- - - - - - - - - - - - - - - - | |
| | |
Address [N]
| | |
| | |
- - - - - - - - - - - - - - - -
The next header 8-bit selector. Identify the key type of the routing header. And IPv4 protocol domain
The value is used in the same value [as described in RFC-1700]
Extended header length 8-bit unmarked integer. Routing header of 8 bytes, not including head 8 words
Section. For zero routing headers, the length of the header extension is equal to the number of addresses
Betal, and must be an even number equal to 46.
Routing type 0.
Left partial 8-bit unmarked integer. The remaining routing part is clearly listed in arrival.
The number of intermediate nodes that still need to be accessed before the final destination.
The maximum legal value is 23.
Reserve 8 reserved domains. For the initial turn of transmission; negligible when receiving.
Strict / loose bitmap 24 bitmap, value from 0 to 23, and from left to right. For each piece of the route
For the bitmap, the bitmap must be the next destination address must be the neighbors of the previous address.
:: 1 means strict (must be neighbors), 0 means loose (no need to be neighbors
Home).
Address [1 ... n] 128-bit address vector, number from 1 to n.
Multicast addresses do not have to appear in the type of zero routing, or IPv6 destination with zero-routing header type grouping
The address domain appears.
If the bit value of the strict / loose bitmap is zero, the destination address domain of the IPv6 header in the source packet must identify the source node.
A neighbor. If the bit is zero, the source is required to use any legal, non-multicast addresses as the initial destination address.
Bits larger than n must be set by the source from zero and is ignored by the recipient, where n is the number of addresses in the routing header.
The routing header will not be inspected or handled unless it arrived in the node identified in the address domain of this IPv6 header destination. In that one
Node, in the next report of the next newspaper in the previous header causes the routing header module to be called so that the following algorithms are performed in a zero routing form:
IF legacy fragment = 0 {
Continue to handle the next header in the group, and its type is identified by the next news header in the routing header.
}
ELSE IF header extension is odd or greater than 46 {
Send code is zero and points to the header extension length domain, and discards the ICMP parameter error message to the packet.
site.
}
Else {
Use the extended header length to calculate the number of addresses in the routing header in the length of the extended header length.
IF legacy fragment is greater than n {
Send code is zero and points to the legacy fragment domain, and discard the ICMP parameter error message to the source.
site.
}
Else {
Legal fragment reduction;
By subtracting the legacy fragment to calculate the I, i is an index of the next address to be accessed in the address vector.
IF address [i] or IPv6 destination address is broadcast {
Abandon
}
Else {
Exchange IPv6 destination address and address [i]
The iF strict / loose bitmap is 1 and the new destination address is not a neighbor of this node.
address{
Send ICMP destination is not accessible message - this is not a neighbor message from the source address and throws
Discard this group.
}
ELSE IPv6 hop limit is less than or equal to one {
Send ICMP time exceeds - the hop limit in the transmission message of the source address exceeds and discards this
Group
}
Else {
Split 1 from the hop limit
Re-deliver the transmission IPv6 module to the new destination
}
}
}
}
As an example of the above algorithm, it is considered that a packet from the source node S transmits a group to the destination node D, which is used.
The packet is routed by the routing of the routing by next to the nodes I1, I2, and I3. Related to each segment of the pass path
The value of the IPv6 header and the routing header domain is as follows:
When packets from S to I1:
Source address = s header extension length = 6
Destination address = I1 legacy fragment = 3
Address [1] = i2
(If the zero bit of the bitmap is 1, address [2] = i3
Then S and I1 must be neighbors, address [3] = D
This will be checked by S)
When packets from i1 to i2:
Source address = s header extension length = 6
Destination address = I2 legacy fragment = 2
Address [1] = i2
(If 1 bit of the bitmap is 1, address [2] = i3
Then I1 and I2 must be neighbors, address [3] = D
This will be checked by I1)
When packets from I2 to i3:
Source address = s header extension length = 6
Destination address = I3 legacy fragment = 1
Address [1] = i1
(If 2 of the bitmap is 1, address [2] = i3
Then I2 and I3 must be a neighbor, address [3] = D
This will be checked by I2)
When packets from I3 to D:
Source address = s header extension length = 6
Destination address = D legacy fragment = 0
Address [1] = i1
(If the 3 digits of the bitmap are 1, address [2] = i2
Then I3 and D must be a neighbor, address [3] = i3
This will be checked by I3)
4.5 Split header
The IPv6 source is sent to the slice header to send than the destination that can be fitted in the path MTU. (note:
Unlike IPv4, the slice in IPv6 is implemented only through the source node, not by the router along the packet delivery path - see Section 5. The fractional header is achieved by the next report value of 44 in the previous header, and there is
The following format:
- - - - - - - - - - - - - - - -
| Next header | pre-levy | Split compensation | Reserved | M |
- - - - - - - - - - - - - - - -
| ID |
- - - - - - - - - - - - - - - -
The next header 8-bit selector. Identifies the graphics part of the initial packet (as defined below)
Initial header. Use the value as the IPv4 protocol domain [as described in RFC-1700].
Reserve 8 reserved domains. The initial is zero during transmission, and it is ignored when receiving it.
Split compensation 13-bit unmarked integers. As related to the fragmentation part of the initial packet,
The header is compensated for data from 8 bytes.
Reserved 2 bits of reserved domains. The initial is zero during transmission, and it is ignored when receiving it.
Sign M 1 = More fragments; 0 = Last fragmentation.
Identify 32 bits. See the description below.
In order to send a packet that is too large to the path MTU to its destination, the source node can divide the packet component
The sheet is sent to each slice as an independent grouping, and these packets are reached when the recipient is reached.
For each packet that will be shard, the source node generates the identifier value. This logo must be in the same source of the same source
Different from any other fragmentation packets on the address and destination address. If the routing header appears, the destination address to consider is the most
The following destination address.
* "Recently" means that within the maximum possible survival time of the group, including transmission from the source to destination
Time and flowers on the remaining fractions of the same packet waiting to be reorganized. However, this does not require source nodes
Know the maximum survival cycle of the group, but assume that it is maintained as a simple, 32-bit, "loopback" count
The identifier value that can be increased at each packet must be added when the packet must be fragmented. Is this to maintain one
Simple nodes are also achieved by multiple counters, for example, each possible source address of this node is used
A counter, or each active (source address, destination address) connected to a counter.
The initial large unscapsted packets are referenced as "raw grouping" and is considered to be composed of two parts, as follows: Original packet:
-------------------------------------- // ------ ----------------
| Unsecured | Split |
| Part | section |
-------------------------------------- // ------ -----------------
The unseaped portion consists of IPv6 header and extended header, and it must be processed by nodes on the intermediate circuit of the destination.
Also, all the headers including routing headers (if they appear), also include topbeat option headers (if present
The words) but do not include extended headers.
The fragmentation portion consists of the remainder of this group, that is, any extended header that only needs to be processed by the final destination node and on
Layers and data.
The fractional portion of the initial packet is divided into a divider, in addition to the fragmentation of the last "rightmost", each fragment length
Is an integer multiple of 8 bytes. Split will transmit according to the independent "fragmentation group" below:
Original group:
------------------------------------ - / / - ----------
| Unsecured | The first | Second | | Final |
| Part | Split | Split | .... | Split |
------------------------------------ - / / - ----------
Split group:
-------------- --------------
| Unsecured | Split | First |
| Part | News | Split |
-------------- --------------
-------------- --------------
| Unsecured | Split | Second |
| Part | News | Split |
-------------- --------------
o
o
o
-------------- --------------
| Unsecured | Split | Final |
| Part | News | Split |
-------------- --------------
Composition of each fragmentation group:
(1) The unparalleled portion of the initial packet and the payload length of the initial IPv6 header change to only this point
The length of the tile group (remove the length of IPv6 header itself), and the last header of the unwrapped part
One reported domain changed to 44.
(2) A fragmentary header includes:
Identifies the next header value of the first header of the initial packet fragment section.
Contains fractional compensation relative to the initial packet fractional portion, and fragmentation of 8 bytes
Compend. The first fragment ("leftmost") fragmentation compensation is zero.
A flag M, when the slice is the last ("rightmost") one value is zero, otherwise the flag M value is 1.
(3) Split itself. .
The length of the fragment must be selected to produce a fragmentation packet that is suitable for the MTU to the packet destination path.
In the destination, the fragmentation group is re-combined into the original, unsaled form, as follows:
Recombinant raw group:
-------------------------------------- // ------ ------------------
| Unsecured | Split |
| Part | Part |
-------------------------------------- // ------ ------------------
The following rules dominate the reorganization:
The original packet can only be reorganized from a slice group with the same source address, destination address, and fragmentation identifier.
The unseaped portion of the recombinant group is composed of all headers that are straight until the first fragmentation packet (that is
It is said that the fractional compensation of the group is zero), there are two changes:
The next reported head field of the last header of the unparalleled part is obtained from the first slide of the fragmentary header.
The payload length of the recombinant group is calculated from the length and compensation of the unscapted portion and the last fragmentation. example
For example, a formula for calculating the payload length of the recombinant initial packet is:
Pl.ORIG = Pl.first - fl.first - 8 (8 * fo.last) fl.last
Here
Pl.ORIG = The payload length domain of the restructuring group.
Pl.First = The first slice packet payload length domain.
Fl.first = Split length with the slide header of the first fragmentation.
Fo.last = Split Compensation Domain of the Fragmentary Header of the Last Split Packet.
Fl.last = Split length with the final fragmentation header.
The fractional portion of the recombinant group is established from the slice of the fragmented header that follows each slice. Length of each fragment
It is calculated by subtracting the length between the IPv6 header and the slice itself from the packet payload length. It is in the fragmentation unit
The relative position of the division is calculated by the fragmentation compensation value.
Split headers do not appear in the final restructuring group.
The following error type may be generated when the recombinant fragmentation packet:
If the number of fragments received is insufficient to complete the restructuring within 60 seconds of the first arrival fragment, grouping
The restructuring must be terminated and all the packet fractions that have been received must be discarded. If the first fragmentation (ie, slide
The one that is zero is already received. The ICMP time is exceeded - the slice restructuring time exceeds the message should be sent to the shard.
Source of origin.
If the fragmentation length is not 8 bytes from the fragmentation packet payload length domain and the flag M of the fragmentation is
1. Then this fragment must be abandoned and transmitted to the code to zero and point to the ICMP parameters of the slide packet payload length domain.
The error code message is sent to the source of the group.
If the length and compensation value of the fragmentation causes more than 65,535 bytes from the packet payload generated from the fragmentation restructuring.
This fragment must be abandoned and transmitted by zero and pointing to the ICMP parameter error code message for fragmentation packet shard compensation domain.
To the source of the packet.
The following cases are undesirable, but if there is, it should not be considered an error:
The number of headers and contents of the front sharpening headers of the same initial packets may be different. No matter how the header appears, each of the slice packet slides in front is first procedure when the packet is arrived before being arranged. only
Those headers that compensate for zero slice groups remain in groups after the restructuring.
The next reported header value of the different fractional slices of the same raw group may be different. Split separation from the compensation value of zero
The value coming in the group is used to reorganize.
4.6 Destination Options Head
The destination option header is used to carry optimization information that only needs to be sentenced to the destination node of the group. Destination option header
Take the next header value for 60 in front of a header, the format is as follows:
- - - - - - - - - - - - - - - -
| Next header | Extended header | |
- - - - - - -
| | |
.
Options.
.
| | |
- - - - - - - - - - - - - - - -
The next header 8-bit selector. Identifies the header type of the header immediately. Use
The value of the IPv4 protocol domain [as described in RFC-1700].
Extended header length 8-bit unmarked integer. The destination option header length is unit 8 bytes,
Does not include the first 8 bytes.
Option variable length domain, its length allows the destination option header integrity of 8 bytes
Multiplier. As in Section 4.2, one or more TLV encoding options are included.
The unique destination options defined in this document are filler 1 and packing N described in Section 4.2.
Note that there are two possible methods to compile optimized destination information in IPv6 packets: either as a destination option
One option of the header is either be a separate extension header. Split headers and authorization headers are the latter method example.
Which way to use depends on what behavior expects to be desirable to understand the purpose of optimization information:
o If the destination node expects behavior to abandon the group and the destination address of the group is not a multicast address,
Then information is either encoded as a separate header or as an option in the destination option.
The option type in the destination option is at its own highest two-digit value of 11. This choice may depend on
Use fewer bytes, or how to produce better queues, or more efficient syntax. o If you expect any other behavior, the information must be encoded into one option in the destination option.
Its maximum two option types is 00, 01, or 10, used to illustrate the desired behavior (see Section 4.2).
4.7 No next header
The value of the IPv6 header is 59 or any extended header pointed out that there is no header after this header. in case
These bytes indicate that the bytes appear late from the end of the header of 59 later than one next newspaper.
Will be discarded, and if the packet is forwarded, the byte will not be changed.
5. Group size problem
IPv6 requires each link on the Internet, there are 576 or more bytes of MTUs. In any one that cannot handle 576
A
On the link of bytes or more byte packets, link-specific slice or restructuring must be available next to IPv6.
From each link to its direct connection, the node must be able to receive the same packet as the link MTU. One
Configurable MTUs (such as PPP link [RFC-1661]) must be configured to have at least 576 bytes of MTUs. recommend
Configure a larger MTU to adapt to possible packages that may not recruit fragments.
In order to find and utilize the path with greater than 576 byte MTU, IPv6 node implementation path MTU discovery
[RFC-1191]. However, minimized IPv6 implementation (such as in importing ROM) may simply limit itself
After 576 bytes of grouping, the implementation of the path MTU discovery is ignored.
In order to send a packet larger than the path MTU, the node can use the IPv6 shard header to separate the packet in the source and in the purpose.
Reorganization group. However, this fragment is in any adjustment itself to fit the standard path MTU (ie, drop to 576 bytes)
It is unsuccessful in the application.
A node must be able to receive a slice packet with a larger number of 1500 bytes after the recombination, and the packet includes an IPv6 header. Node allows
A slice group greater than 1500 bytes after receiving the recombination. However, the node cannot send a reorganized size greater than 1500 bytes.
The film unless it has clearly known that the purpose of the destination recombination such large-sized grouping.
The response to IPv4 destination as an IPv6 group (ie, packets experience from IPv6 to IPv4), initial
The IPv6 node may receive a report of less than 576 ICMP packets under the report. This way IPv6 node is not
Be required to reduce subsequent packet size to less than 576 bytes, but must include a slice header in group to make IPv6
The IPv4 conversion router can obtain a valid identifier value that causes IPv4 shards. Note that this means payload
Maybe it must be reduced to 528 bytes (576 minus the 40 bytes of the IPv6 header), and if attached
If you are using an extended header, it can be smaller.
Note: Path MTU finds must be consistent, here the host "think" destination is connected to itself
On the link.
Note: Not like IPv4, in order to perform the path MTU discovery, IPv6 does not have to set "no slide" tag in points
Group header. That is, this is an implicit feature in each IPv6 group. And those in the RFC-1191 program
The part of the MTU "step" table cannot be applied to IPv6, because "from" self-contained address information packet
The IPv6 version of the big "message has identified the accurate MTU to be used.
6. Flow label
The 24-bit stream tag field in the IPv6 header can be used by the source to mark the special control of the IPv6 router (eg
Non-default QoS or "real-time" service) packets. When writing this document, IPv6's problem is still experimentally
And attributed to a clearer change in the stream tag requirements in the Internet. Hosts do not support streaming domain function
And the router is required to be set to zero during the initial packet, and pass through this domain when forwarding the packet, and
Ignore this domain when you receive a packet.
The stream is a group sequence transmitted from a particular source to a particular destination (unicast or multicast). For streaming, the source is required to perform special controls during the period. The nature of special control can pass through the control protocol, such as
Resource reservation agreement, or through information in the circulating group, such as information in the step-bybeat option, to the router.
This control protocol or option has exceeded the scope of this document.
And without any stream in communication, there may be multiple active streams from a source to the destination. One
The stream is uniquely identified by the source and non-zero flow labels. Flow label that does not belong to a stream
To zero.
The source node of the stream assigns a stream tag to a stream. The new stream label must be (pseudo) random selection and range is
From 1 to 0xffffFFF. The purpose of the random allocation is to set in the course signature suitable for the router to do the hash key value.
Any set of positions used to query and stream joint state.
All groups belonging to the same stream must be sent along with the same source address, destination address, priority, and stream tags.
If any of those groups include header option headers, they must be headed by the same topbeat option.
The content (excluding the next newspaper domain) of the step-by-step option is to initially. If any group includes a header, then
They must be used until all extended headers including routing headers (excluding the next report of the next routing header)
The same content is initially. Use routers and destinations to check if these conditions are satisfied, but not required.
If you are detected, the node must be zero by sending code and pointing to the stream tag domain (that is
IPv6 Packet Compensation Value 1) ICMP Parameter error code message to the source of the packet.
For any flow, the router can set the stream control state as "icon chambers", even without pass.
The overlapped protocol, trip option, or other method provides a clear stream establishment of the router. For example, once received from one
Packets with unknown and non-zero flow labels, the router can handle the group of IPv6 headers and anything
What must be extended, just like this flow label is zero. Such processing will include determining the next hop interface and
Other behaviors, such as updating the step-by-edge option, pointer and address in front of the header, or determine how to be based on
Significance to arrange the group. Then the router may select "Remember" the results of the processing steps and cache this information.
Use the source address plus the stream tag as the cache key value. Then, then the group with the same source address and stream tag can then
Reference cached information to manipulate, rather than checking all those who can assume as a stream as according to the requirements of the article
The domain that has not been changed from the first packet.
As mentioned earlier, whether or not other groups continue to arrive, randomly set cache stream controls are built
It must be abandoned within 6 seconds after standing. If you have a packet with one source address and stream label after the cache state is abandoned
If the group will be complete and normal processing (as if it's a stream tag is different), it may cause this stream.
Rebuild the cache flow.
For example, the survival cycle of the cache stream control state that is controlled protocols and step-bybeat options must be used as a clear setup mechanism.
Part of the specification will be described.
Source is no longer a new stream in the survival period of the flow control state that may have been pre-used for stream labels.
Use stream tags. This is because the internal control state can be randomly established in the 6-second survival period, and the same current standard is used.
The last packet of the signed stream and the first packet interval between the new stream are 6 seconds. Have a longer lactational survival
Clean streaming stream labels must remain not used for those longer life cycles before being re-used.
When a node stops and restarts (such as as a result of "crash", it must carefully do not use a
It is used earlier, and there is no flow label that may not have expired flow. This may be recorded on a stable memory
The stream label can be remembered after the stream label is crash, or through the maximum life of the flow that is previously possible.
Period (for at least 6 seconds; if there is a longer life-saving setup mechanism has been used to use any stream tags before being used. If the minimum time of the node (often more than 6 seconds) is known, then start
This minimum time before the distribution label can be deducted from the time of the period.
There is no special requirements for all or even most of the stream, that is, the packet carrying non-zero labels. This
Evaluation is placed here to make the agreement designer and realizes don't consider other aspects. For example, only assume that most packets belong to flow
Just want to design a performance-complete router or to design a header pressure on the packet that works in a stream.
The shrink mechanism is unwise.
7. Priority
The 4-bit priorities in IPv6 can make the source to transmit from other packets from the same source to its desired transmission
Priority is identified. The priority is divided into two ranges: 0 to 7 value is used to designate communication priority to providing the resistance
The source of the plug protocol, namely, as a "returned" communication, "returning", such as TCP communication. The value of 8 to 15 is used to give
Communication that cannot be returned in response occurs, such as the "real-time" packet sent by the constant rate, is prioritized.
For constrained blocking communications, recommend the following priorities to specific applications:
0 - free communication
1 - "Fill in the blanks" communication (such as online news)
2 - Not paying attention to data transmission (such as email)
3 - (Reserved)
4 - Terms of charge (such as FTP, NFS)
5 - (Reserved)
6 - Interactive communication (such as Telnet, X)
7 - Internet Control Communication (such as routing control protocol, SNMP)
For unconstrained blocking communications, the minimum priority value (8) under blocking conditions should be used to do those senders
I hope to abandon the group (such as high fidelity video communication), the highest priority value (15) should give those senders least
Prouded groups (such as low furnish audio communication). Inconstrained obstruction priority and unconstrained priority
There is no implied relative order.
8. Upper layer protocol
8.1 upper checksum
Any transport layer or other upper layer protocol included from the IP header must be modified in its verification and calculation.
Use 128-bit IPv6 addresses to replace 32-bit IPv4 addresses in IPv6. Special, below
IPv6 TCP and UDP "pseudo-header".
- - - - - - - - - - - - - - - -
| | |
| | |
Source address |
|
| | - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | |
| | |
Destiny Address
| | |
| | |
- - - - - - - - - - - - - - - -
| Payload Length |
- - - - - - - - - - - - - - - -
| Zero | Next header |
- - - - - - - - - - - - - - - -
o If the group contains a routing header, which destination address in the dummy head is the final destination. in
Source node, this address will be the last part of the routing header. This address will be in IPv6 reporting
The head of the destination address domain.
o The next report value in the pseudo-header identifies the upper protocol (eg, the TCP corresponds to 6, UDP is 17). Such as
If there is an extended header between the IPv6 header and the upper header, then the next report of the pseudo header and
The next news header in the IPv6 header will be different.
o The payload length in the pseudo-headed head is the length of the upper group, including the upper header. If there is an extended header between the IPv6 header and the upper header, then the payload of the pseudo head will be less than IPv6.
The payload length in the header (or in the giant "load option).
o is not like IPv4, when the UDP packet is initially initially, the UDP checksum is not optimized. Be
Say that when you initially a UDP group, IPv6 nodes must calculate UDP on grouping and pseudo-states.
The checksum, and if the result is generated by zero, the location in the UDP header must also be changed to
0xfff. The IPv6 recipient must discard the UDP group containing zero checksum and log errors.
IPV6 version of ICMP [RFC-1885] includes the above pseudo headers in its checksum, and IPv4 version is not verified
And in the sum of pseudo headers, this is a change in IPv4 version from ICMP. The reason for this change is to protect ICMP
It does not interrupt or mislead on its dependent IPv6 header field, not like IPv4, is covered by network layer checksum. ICMP
The value of the next report in the pseudorated head is 58, which identifies the IPv6 version of ICMP.
8.2 Maximum Group Survival Period
Not like IPv4, IPv6 nodes do not need to enhance maximum packet survival cycle. This is because IPv4 "survival" field in IPv6
Rename "Switch". In fact, even if you want, only very little IPv4 implementation complies to their restriction grouping
The requirements of the survival cycle have not changed in practice. Any relying on the network layer protocol to restrict the group survival week
The upper level agreement (regardless of IPv4 or IPv6) must first upgrade to provide itself to explore and abandon the waste group
Mechanisms.
8.3 Maximum upper payload size
When calculating the maximum payload size is feasible to the upper data, the upper protocol must consider the relative IPv4 header.
The larger size of the IPv6 header. For example, the MSS of TCP in IPv4 is used in maximum packet size (default or passing
path
MTU finds the value of learning) minus 40 bytes (20 bytes is minimizing IPv4 header length and 20-byte minimization
TCP
The length of the header is calculated. When using TCP on IPv6, because the minimum length of IPv6 header is (ie said,
IPv6 header does not extend the header) More than 20 bytes higher than the minimized IPv4 length, MSS must reduce 60 with maximum packet size
Bytes are calculated.
The formatting guidance policy of the appendix A option
This appendix on how to design a header (as in Section 4.2) in the design of a header or destination option (like the 4.2)
The placement domain gives some suggestions when the new option. This guidance policy is based on some assumptions:
O A desired feature is a multi-byte that is arranged on their original boundaries in the options of the option.
The domain, ie the width of the N-byte should be placed in the n-byte of the n-byte from the beginning of the header or destination option.
Double position, n = 1, 2, 4, or 8 here.
o Because the header is a total of 8-bytes long integer times, another desired feature is a top jump or purpose option.
The header should be established as small as possible.
o Announces any of the selected items that can be assumed to carry a very small option, usually only 1.
These assumptions provide the following methods to place the domain: no internal filling, sort the domain from the minimum to maximum, then send
Birth is based on the maximum domain arrangement (until the Maximum Queue of 8 bytes). This method uses the following
Method is illustrated:
Example 1
If the option x requires two data fields, 8-bytes long domains, and 4-word-wide domain, they can be placed as follows:
- - - - - - -
Option type = x | Option data length = 12 | - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
| | |
8-word somewhere
| | |
- - - - - - - - - - - - - - - -
In order to ensure that the 8-byte domain is started from the 8-byte multiples compensated from the beginning of the package header, it is required to be 8n 2.
A complete jump or destination option, including one such option, should look as follows:
- - - - - - - - - - - - - - - -
Next header | extended head length = 1 | Option type = x | Option data length = 12 |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
| | 8-Word Shan Domain
| | |
- - - - - - - - - - - - - - - -
Example 2
If the option y requires three data fields, 8-bytes long domains, 4 word-wide domains have been one 1-bytes long domain, as
Lower placement:
- - - -
| Option type = Y |
- - - - - - - - - - - - - - - -
| Option Data Length = 7 | 1 - Word Day Domain | 2-Word Domain |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
In order to ensure that the 4-byte domain is started from the 4-byte multiples compensated from the beginning of the package header, it is required to be 4N 3.
A complete jump or destination option, including one such option, should look as follows:
- - - - - - - - - - - - - - - -
Next header | Extended header = 1 | Filler 1 option = 0 | Option type = Y |
- - - - - - - - - - - - - - - | Option data length = 7 | 1-byteen area | 2-word sield |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
| Filler n option = 1 | Option data length = 2 | 0 | 0 |
- - - - - - - - - - - - - - - -
Example 3
The hop and destination option headers in Example X and Example 2 in Example 1 are the following, according to the options appearing according to the option.
One of two formats:
- - - - - - - - - - - - - - - -
Next header | Extended header = 3 | Option type = x | Option data length = 12 |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - - | |
8-word somewhere
| | |
- - - - - - - - - - - - - - - -
| Filler n option = 1 | Option data length = 1 | 0 | Option type = Y |
- - - - - - - - - - - - - - - -
| Option Data Length = 7 | 1 - Word Day Domain | 2-Word Domain |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
| Filler n option = 1 | Option data length = 2 | 0 | 0 |
- - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - | Next header | Extended header length = 3 | Pack 1 option = 0 | Option type = Y |
- - - - - - - - - - - - - - - -
| Option Data Length = 7 | 1 - Word Day Domain | 2-Word Domain |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - -
| Filler n option = 1 | Option data length = 4 | 0 | 0 |
- - - - - - - - - - - - - - - -
| 0 | 0 | Option Type = x | Option Data Length = 12 |
- - - - - - - - - - - - - - - -
| 4-Word Festival Domain |
- - - - - - - - - - - - - - - - | |
8-word somewhere
| | |
- - - - - - - - - - - - - - - -
Safety Considering Reference on Security Architecture in Internet Protocol [RFC-1825], this document illustrates with IPv6
IP Authorized Head [RFC-1826] and IP Package Safety Payload [RFC-1827].
Thank you
The author expresses sincerely for the IPNG Working Group, End-to-End Protocol Research Group, and many beneficial recommendations of the Internet community member.
Thanks.
Author address
Stephen E. Deering Robert M. Hinden
Xerox Palo Alto Research Center Ipsilon NetWorks, Inc.
3333 Coyote Hill Road 2191 E. Bayshore Road, Suite 100
Palo Alto, CA 94304 Palo Alto, CA 94303
USA USA
Phone: 1 415 812 4839 Phone: 1 415 846 4604
Fax: 1 415 812 4471 Fax: 1 415 855 1414
Email: deering@parc.xerox.com email: hinden@ipsilon.com
reference
[RFC-1825] Atkinson, R., "Security Architecture for the Internet
Protocol, RFC 1825, Naval Research Laboratory, August
1995.
[RFC-1826] Atkinson, R., "IP Authentication HEADER", RFC 1826,
Naval Research Laboratory, August 1995.
[RFC-1827] Atkinson, R., "IP ENCAPSULATING Security Protocol
(ESP) ", RFC 1827, Naval Research Laboratory, August
1995.
[RFC-1885] Conta, A., And S. Deering, "Internet Control Message
Protocol (ICMPV6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 1885, DIGITAL EQUIPMENT
Corporation, Xerox Parc, December 1995.
[RFC-1884] Hinden, R., And S. DeERING, Editors, IP Version 6
Addressing Architecture, RFC 1884, IPSILON NETWORKS,
Xerox Parc, December 1995.
[RFC-1191] Mogul, J., And S. Deering, "Path Mtu Discovery", RFC
1191, Decwr, Stanford University, November 1990.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
USC / INFORMATION sciences institute, SEPTEMBER 1981.
[RFC-1700] Reynolds, J., And J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC / INFORMATION sciences institute, October
1994.
[RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol
(PPP) ", STD 51, RFC 1661, Daydreamer, July 1994.
RFC1883 - Internet Protocol, Version 6 (IPv6) Specification
Internet Agreement, Version 6 (IPv6) Manual
RFC1883 - Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Manual
2
RFC Document Chinese Translation Program
