IPv6 deployment:header

From LQWiki
Jump to navigation Jump to search

IPv6 and IPv4 headers compared

Although we like to think of the Internet as a new technology, the actual design of the Internet infrastructure began in the late 1960's with contracts from the United States Department of Defense. By 1981, RFC 791 standardized IPv4, which is the key technology for building an "internet" of networks. In the past 22 years, we have seen quite a few changes to the Internet's infrastructure. To understand some of the issues with IPv4, let us take a look at its header layout.

http://dons.usfca.edu/buckwalt/ipv6/image002.jpg

Figure 1-1 IPv6, IPv4 Side by Side Comparison

In Figure 1-1, we can compare the IPv4 and IPv6 headers. In IPv4, the Version field (A) has a value indicating that this datagram is of type IPv4. The Header Length Field (B) indicates the length of the IPv4 header, (since the options field (N) is optional or can contain up to 40 bytes of data). The next field (C) represents what is generally considered to be 'Type of Service' and is a way to specify the priority of a packet. The Total Length of the packet is stored in field (D) and represents the size of the packet header + payload.

Fields E, F, G and H are used in fragmentation calculations. The Identification Header (E) is used to determine which group of fragmented packets a datagram belongs to. The 'Don't Fragment' Flag (F) (which follows an unused bit) is used to specify that this datagram should not be fragmented. The 'More Fragments' flag (G) specifies that fragment reassembly at the receiver must wait until the rest of the fragments are received. The last fragmentation field (H) specifies where the fragment fits within the original datagram.

The 'Time to Live' byte (I) specifies how long a packet can travel along a route until it is dropped (and an alert sent back to the originating host). The 'Time to Live' is now measured in hops. The 'Protocol' byte (J) tells the recipient about the type of protocol in its payload (typically TCP, UDP, etc). The header checksum (K) tells the recipient if there were any transmission errors in the header. And finally, the standard packet header ends with the Source (L) and Destination (M) addresses of the packet. If it exists, the options header (N) follows the standard packet header, and may be up to 40 bytes in length.

If reading the description of the headers is confusing, imagine how much computation must be done by the routers managing the packets. Imagine having to wade through a possible 40 more bytes of optional headers (twice the length of the standard header described on this page). The IPv4 software has to do a considerable amount of processing as each packet is received, analyzed, possibly fragmented, and then retransmitted. With knowledge of the complexities of IPv4, the designers of IPv6 decided to simplify the headers of the IPv6 protocol to eliminate many of these problems.

First, they eliminated the "options" header. There is a set of optional headers in IPv6, but unless the router sees a special routing header as the very first optional header (comprising 18 bytes) it is ignored. Because the "options" header was eliminated, packets would always be the same size. This means that the IPv6 header does not need a Header Length Field. Next, a decision was made on the way IPv6 behaves about packet fragmentation.... and the decision is that routers just won't do it. The end hosts are responsible for determining the maximum transmission unit of the link between it and its partner and sending datagrams of that size or smaller... thus fragmentation is eliminated in the routing consideration (and packet re-assembly phases). Finally, since modern routers have build in error detection at the datalink layer, it became unnecessary to compute header checksums for IPv6 headers.

In this way, the IPv6 header starts to look like a "stripped down" version of the original IPv4 specification. The first field (A) represents the version of the protocol (IPv6). The next field (B) represents the "Traffic Class" (a fancy way of saying Type of Service). The field (C) is the "Flow Label" and is a shortcut for the router that means the router has to make routing decisions on this packet insomuch as it must do to this packet the same thing it does to every other packet with the same flow label. The Payload Length (D) is the length of the entire datagram minus the header. The Next Header (E) is used by router only under very special circumstances but generally tells the receiving station the protocol of the datagram's payload (i.e. TCP, UDP, etc). Next, we have the "Hop Limit" (F) which is analogous to "Time to Live" in IPv4 but represents a simple counter that can be decremented (instead of a time to be computed). Finally, the Source (G) and Destination (H) headers are each 16 bytes long.

The IPv6 headers are always 40 bytes long. IPv4 headers are a minimum of 20 bytes long but are quite often longer (up to a rare maximum of 60 bytes long). This represents on a normal network (1500 bytes MTU) of 2.6 percent of the overall traffic for IPv6 and an estimate of 1.3 to 3.9% of traffic on an IPv4 network for headers alone.

Internal links

Next section: Addressing

Main article: IPv6 deployment