| IPv6 Network - IPv6 Internals |
Differences Between IPv4 and IPv6 All knowledge about IPv6 begins with studying the IPv6 header format and the ways in which it is different from the IPv4 header format. Even though at the time the IPv6 specifications were written, 64-bit CPUs were few and far between, the IPv6 designers elected to optimize the IPv6 header for 64-bit processing. For this reason, I’ve drawn the IPv6 header “64-bit wide” , which is a little different from the way it’s usually depicted. Because 64-bit CPUs can read 64-bit wide memory words at a time, it’s helpful that fields that are 64 bits (or a multiple of 64 bits) wide start at an even 64-bit boundary. Because every 64-bit boundary is also a 32-bit boundary, this doesn’t get in the way of 32-bit CPUs. The IPv4 header is presented in the usual form that highlights its 32-bit background.
The Internet Header Length (IHL) field that indicates the length of the IPv4 header is no longer needed because the IPv6 header is always 40 bytes long. Type of Service is now Traffic Class. The original semantics of the IPv4 Type of Service field have been superseded by the diffserv semantics per RFC 2474. However, in IPv4, both interpretations of the field are in use (although most routers aren’t able or configured to look at the field anyway). The IPv6 RFCs don’t mandate a specific way to use the Traffic Class field, but generally the RFC 2474 diffserv interpretation is assumed.
The Flow Label is new in IPv6. The idea is that packets belonging to the same stream, session, or flow share a common flow label value, making the session easily recognizable without having to look “deep” into the packet. Recognizing a stream or session is often useful in Quality of Service mechanisms. Although few implementations actually look at the flow label, most systems do set different flow labels for packets belonging to different TCP sessions. A zero value in this field means that setting a flow label per session isn’t supported or desired.
The Total Length is the length of the IPv4 packet including the header, but in IPv6, the Payload Length doesn’t include the 40-byte IPv6 header. This saves the host or router receiving a packet from having to check whether the packet is large enough to hold the IP header in the first place, making for a small efficiency gain.
The Identification, Flags, and Fragment Offset fields are used when IPv4 packets must be fragmented. Fragmentation in IPv6 works very differently (explained later this chapter), so these fields are relegated to a header of their own. Time to Live is now called Hop Limit. This field is initialized with a suitable value at a packet’s origin and decremented by each router along the way. When field reaches zero, the packet is destroyed. This way, packets can’t circle the network forever when there are loops. Per RFC 791, the IPv4 Time to Live field should be decremented by the number of seconds that a packet is buffered in a router, but this turned out to be too hard to implement, so each router lowers the contents of the field by one, regardless of buffering time. The new name is a better description of what actually happens. The Protocol field in IPv4 is replaced by Next Header in IPv6. In both cases, the field indicates the type of header that follows the IPv4 or IPv6 header. In most cases, this would be 6 for TCP or 17 for UDP.
Because the IPv6 header has a fixed length, any options such as source routing or fragmentation must be implemented as additional headers that sit between the IPv6 header and the higher-layer protocol such as TCP, forming a “protocol chain.” The IPv4 Header Checksum was removed in IPv6. The Source Address and Destination Address serve the same function in IPv6 as in IPv4, except that they are now four times as long at 128 bits.
| Users' Comments (0) |
|
No comment posted
