📄 rfc2460.txt
字号:
type-specific data Variable-length field, of format determined by the Routing Type, and of length such that the complete Routing header is an integer multiple of 8 octets long. If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows:Deering & Hinden Standards Track [Page 12]RFC 2460 IPv6 Specification December 1998 If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. If, after processing a Routing header of a received packet, an intermediate node determines that the packet is to be forwarded onto a link whose link MTU is less than the size of the packet, the node must discard the packet and send an ICMP Packet Too Big message to the packet's Source Address.Deering & Hinden Standards Track [Page 13]RFC 2460 IPv6 Specification December 1998 The Type 0 Routing header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[2] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Hdr Ext Len 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets. For the Type 0 Routing header, Hdr Ext Len is equal to two times the number of addresses in the header. Routing Type 0.Deering & Hinden Standards Track [Page 14]RFC 2460 IPv6 Specification December 1998 Segments Left 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Reserved 32-bit reserved field. Initialized to zero for transmission; ignored on reception. Address[1..n] Vector of 128-bit addresses, numbered 1 to n. Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0. A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. In that node, dispatching on the Next Header field of the immediately preceding header causes the Routing header module to be invoked, which, in the case of Routing Type 0, performs the following algorithm:Deering & Hinden Standards Track [Page 15]RFC 2460 IPv6 Specification December 1998 if Segments Left = 0 { proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header } else if Hdr Ext Len is odd { send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field, and discard the packet } else { compute n, the number of addresses in the Routing header, by dividing Hdr Ext Len by 2 if Segments Left is greater than n { send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Segments Left field, and discard the packet } else { decrement Segments Left by 1; compute i, the index of the next address to be visited in the address vector, by subtracting Segments Left from n if Address [i] or the IPv6 Destination Address is multicast { discard the packet } else { swap the IPv6 Destination Address and Address[i] if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet } else { decrement the Hop Limit by 1 resubmit the packet to the IPv6 module for transmission to the new destination } } } }Deering & Hinden Standards Track [Page 16]RFC 2460 IPv6 Specification December 1998 As an example of the effects of the above algorithm, consider the case of a source node S sending a packet to destination node D, using a Routing header to cause the packet to be routed via intermediate nodes I1, I2, and I3. The values of the relevant IPv6 header and Routing header fields on each segment of the delivery path would be as follows: As the packet travels from S to I1: Source Address = S Hdr Ext Len = 6 Destination Address = I1 Segments Left = 3 Address[1] = I2 Address[2] = I3 Address[3] = D As the packet travels from I1 to I2: Source Address = S Hdr Ext Len = 6 Destination Address = I2 Segments Left = 2 Address[1] = I1 Address[2] = I3 Address[3] = D As the packet travels from I2 to I3: Source Address = S Hdr Ext Len = 6 Destination Address = I3 Segments Left = 1 Address[1] = I1 Address[2] = I2 Address[3] = D As the packet travels from I3 to D: Source Address = S Hdr Ext Len = 6 Destination Address = D Segments Left = 0 Address[1] = I1 Address[2] = I2 Address[3] = I3Deering & Hinden Standards Track [Page 17]RFC 2460 IPv6 Specification December 19984.5 Fragment Header The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.) The Fragment header is identified by a Next Header value of 44 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet (defined below). Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Reserved 8-bit reserved field. Initialized to zero for transmission; ignored on reception. Fragment Offset 13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet. Res 2-bit reserved field. Initialized to zero for
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -