Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Getting to Know IPv6

While the share of IPv6 traffic is currently tiny, it is growing rapidly.

This story originally appeared in TV Technology.

Now that World IPv6 Day (June 8) is behind us, we can all take comfort in the fact that the Internet didn’t collapse when major companies including Google, Facebook and Yahoo! enabled IPv6 on their main URLs for 24 hours.

For the next few years (or decades?) there will be a transition period when both IPv4 and IPv6 will be used on the Internet. While the share of IPv6 traffic is currently tiny, it is growing rapidly, and soon, some users will only have IPv6 addresses. For companies that deliver content over the Internet (many local broadcasters), now is the time to begin implementing IPv6 on their website servers.


IPv6 replaces the familiar IPv4 packet header with a completely new header, which supports 128-bit IP addresses in place of the 32-bit ones that are so familiar.

In addition, most of the other fields and flags are reconstituted, replacing some functions and removing some others. As a result, IPv6 and IPv4 are not forward/backward compatible, and require different software procedures to handle them.

Fortunately, both IPv4 and IPv6 can work over the same physical layer, so existing Ethernet infrastructure can be used, and the MAC addressing scheme remains unchanged.

Fig. 1 shows both the IPv4 and IPv6 packet header formats. Here are the changes in the IP header between the versions:

The Ver field indicates which version of IP is being used for this packet. For IPv4, Ver=0100 (binary 4); for IPv6, Ver=0110 (binary 6).

The HL (Header Length) and Total Length fields of IPv4 have been replaced with the Payload Length field in IPv6.

Fig. 1: IPv4 and IPv6 packet header formats

The TOS field was redefined in IPv4 to contain two values—the 6-bit DSCP (Differentiated Services Code Point) field, and the 2-bit ECN (Explicit Congestion Notification) field. These two fields now make up the 8-bit Traf Cl (Traffic Class) field in IPv6.

IPv4’s fragmentation feature (managed with the Fragment ID and Fragment Control fields), which is used to break up long packets into shorter ones for some types of physical network, has been heavily modified. In its place, IPv6 connections are supposed to figure out the maximum packet size (called “MTU” for Maximum Transmission Unit) of the end-to-end connection before using sending packets. This process, called Path MTU Discovery, is used because IPv6 routers will not perform fragmentation, as their IPv4 predecessors would. This means that any packets that exceed the MTU on a link are dropped, with a message sent back to the packet’s source. One improvement in IPv6 is an increase in the minimum MTU on every link to 1280 bytes versus 576 bytes in IPv4; this helps avoid the need for breaking data up into smaller packets. IPv6 does have a mechanism for fragmenting packets at their origin; this requires the use of an extension header within IPv6 and is quite complex.

The TTL (Time to Live) field in IPv4 is used to limit the amount of time an IP packet can live on the network; it is a counter that is decremented each time a packet passes through a router. In IPv6, this same function is performed by the Hop Lim (Hop Limit) counter. When the Hop Limit field reaches zero, the packet is discarded.

The 8 bits that make up the Protocol field in IPv4 are renamed as the Next HD (Next Header) field in IPv6. These values are used to identify the type of protocol being carried in the packet, such as TCP or UDP. The values that make up this field are controlled by the IANA (Internet Assigned Numbers Authority) and are the same for both IPv4 and IPv6.

The Header Checksum field in IPv4 has been eliminated. This reduces the load on routers, which will no longer need to recalculate and reinsert this value every time a packet is processed.


Most websites adopting IPv6 today use “dual-stack” technology, which supports both IPv4 and IPv6 packet reception and transmission. By using this approach, website providers can maintain compatibility with existing users while allowing newer, IPv6-only users to also have access. This arrangement will likely be necessary for many years to come, as there is not yet any plan to phase out IPv4 in the future.

One barrier to proving IPv6 services to the public for many website owners will be the capability of their ISP (Internet Service Provider) to support IPv6 traffic. While a number of providers do offer IPv6, many do not. In addition, website owners will need to work with their Domain Name registrar to enable users to get IPv6 addresses in response to DNS queries. Currently, major websites such as Google use two different domain names—queries for will return an IPv4 address and those to will return an IPv6 address.


IPv6 is inevitable, and website owners must develop a strategy to accommodate new users who will never have IPv4 addresses. Although many workarounds are being deployed today to recycle IPv4 addresses, the day is approaching when the 32-bit address space is truly exhausted. Forward-looking website owners should begin planning now for IPv6 deployment if they haven’t already started.

Wes Simpson is hoping for his ISP to support native IPv6, but is prepared for a long wait. He can be reached at [email protected].