Getting ready for IPv6

IPv6 is the next generation of the IP protocol that will make it much easier to pull off more sophisticated types of networking. Here are some things you need to know to get ready for the transition.

You've probably read the Doomsday articles about the world running out of IP addresses. Such articles insist that the only way for the world to avoid such a catastrophe is for everyone to upgrade from version 4 of the IP protocol (IPv4) to version 6 (IPv6). Of course, NAT and similar technologies have so far kept the world from running out of IP addresses without switching to IPv6. Even so, it is only a matter of time before IPv6 becomes the protocol of choice. The fact is that although IPv4 is a great protocol, it is roughly 40 years old, and was never designed to do a lot of the things that people are using it for. IPv6 is a next-generation version of the IP protocol that will make it much easier to pull off more sophisticated types of networking. Here are some things you need to know to get ready for the transition.

Why not flip a switch?

Ideally, everyone in the world would switch to IPv6 tomorrow and be done with it. Realistically, though, there are a lot of problems with a mass conversion. IPv6 uses a different IP address format than IPv4 does. That means that when you make the switch to IPv6, your IP address must change. If that doesn't sound like a big deal to you, then imagine what it would be like if the phone number of every person in the world suddenly changed. That's the same type of effect that a rapid migration to IPv6 would have on the Internet.

Of course the Internet is huge and uncoordinated, so let's look at what would happen if a midsize company migrated to IPv6. The first issue would be the initial transition. While machines were being upgraded, there would be a period of time when both IPv4 and IPv6 would exist on the same network. Even so, that wouldn't be a huge problem because the entire migration could happen within a day or two. What would be a big deal, though, is that there are almost certainly some computers or other devices that would not be IPv6 compatible. For example, machines with older operating systems might not support IPv6. Likewise, the company's routers or gateways might not support IPv6.

Hopefully, you are starting to see what a big deal switching to IPv6 could be and why so few people have made the switch. There is some good news, though. When IPv6 was designed, the engineers who created it specified certain transition criteria in RFC 1752. These criteria state the following:

  • Existing IPv4 hosts can be upgraded at any time, independent of the upgrade of other hosts or routers.
  • New hosts, using only IPv6, can be added at any time, without dependencies on other hosts or routing infrastructure.
  • Existing IPv4 hosts, with IPv6 installed, can continue to use their IPv4 addresses and do not need additional addresses.
  • Little preparation is required to either upgrade existing IPv4 nodes to IPv6 or deploy new IPv6 nodes.

So if the transition criteria that I have spelled out above basically allow you to mix and match IPv4 and IPv6 in any way necessary, why haven't more people started to implement IPv6? The reason is that although the IPv6 protocol is designed for coexistence with IPv4, there is only so much that the protocol can do by itself. The actual hosts on a mixed network must be aware of both protocols and have certain transition technologies built into them. Until fairly recently, these transition technologies simply weren't available. In fact, the only Microsoft operating systems that support them are Windows XP Service Pack 1 and above, and Windows Server 2003.

During a transition period, a transition mechanism must exist that allows IPv4 hosts to communicate with IPv6 hosts, and vice versa, while still allowing for an eventual transition into an IPv6-only environment. There are three primary mechanisms used for this co-existence: dual IP layers, IPv6-over-IPv4 tunneling, and a DNS infrastructure.

Dual IP layers

To really understand how the dual IP layers mechanism works, you have to know something about the OSI model for networking. As you may know, this model takes a layered approach to networking and prescribes how communications should occur from an application, down to the physical network. The layers of the OSI model are:

  • Application
  • Presentation
  • Session
  • Transport
  • Network
  • Data Link
  • Physical

Normally, the TCP and UDP protocols are implemented in the transport layer. The IP protocol is then implemented in the network layer. In Windows XP, though, an additional layer is inserted between the transport layer and the network layer. This layer implements IPv4 and IPv6. The layer contains two separate modules, one for each protocol. Both modules interact with the transport layer and the network layer completely independently from the other module.

The dual IP layer implementation works a bit differently in Windows Server 2003. In Windows Server 2003, the additional layer does exist, just as it did in Windows XP SP1. The difference, however, is that the transport layer is also split. IPv4 and IPv6 each link to their own copy of the TCP/UDP stack.

IPv6 over IPv4 tunneling

In networking, tunneling refers to encapsulating packets within a different protocol so that they can be safely sent across either an insecure or otherwise unsupported network type. For example, imagine that your company had offices in Las Vegas, New Orleans, and Miami. Now imagine that the Las Vegas office had a link to the New Orleans office, and the New Orleans office had a link to the Miami office, but that no direct link existed between Miami and Las Vegas. The only way to move data between Miami and Las Vegas is to pass it through New Orleans.

To further complicate things, let's pretend that the offices in Las Vegas and Miami have been completely converted to IPv6, but the office in New Orleans is still running IPv4. This would mean that if someone in Miami needed to communicate with someone in Las Vegas, they would be sending the packet in IPv6 format, and the packet would be destined for an IPv6 network. The problem is that it has to pass through an IPv4 network to get there.

This is where tunneling comes in. The tunneling process would take the IPv6 packet and encapsulate it inside of an IPv4 packet so that it can travel across the IPv4 network in New Orleans. Once the packet arrives in Las Vegas, the IPv4 encapsulation is stripped away, leaving behind the original IPv6 packet.

This process looks good in theory, but it raises a lot of questions. For example, how does the network in Las Vegas tell the difference between an IPv4 encapsulation packet and any other IPv4 packet? It's possible to tell the difference by looking at the packet's header.

As you probably know, there are many different protocols in the TCP/IP protocol suite. TCP/IP uses a few bits within the protocol header to designate the protocol type. This allows TCP/IP to tell the difference between HTTP, FTP, SMTP, etc. Typically, humans look at the port number to determine the protocol, but it is easily possible to transmit a protocol over a port that it was never intended to use. For this reason, IP numerically identifies the protocol that it is carrying. When IPv6 is encapsulated in an IPv4 packet, the IPv4 packet is assigned a protocol identification number of 41. Upon arrival at an IPv6-aware network, the identifier of 41 tells the receiving network to strip away the IPv4 encapsulation.

One caveat in regard to IPv6-over-IPv4 tunneling is that the TCP/IP protocol is designed to fragment packets when needed. However, because the IPv4 packet contains a complete IPv6 packet, fragmenting the IPv4 packet would destroy the IPv6 packet that it contains. Sure, the IPv4 packets are reassembled at the destination—but the destination is expecting to unwrap a complete IPv6 packet.

To prevent packet fragmentation from occurring, the IPv6 path maximum transmission unit (MTU) is typically limited to the IPv4 path MTU minus 20. However, there are situations that prevent the IPv4 path from being stored for each tunnel. To prevent fragmentation from occurring, the IPv4 packet sets the Do Not Fragment bit in the IPv4 header to zero.

Of course, this is just a general description. There are actually several different types of IPv6-over-IPv4 tunnels. These tunnels can be divided into two types: configured and automatic. A configured tunnel is one that you have manually created, while an automatic tunnel is a tunnel that does not require manual configuration. Manual tunnels can be created by using the NETSH command in Windows Server 2003. The actual command that you would use is:

netsh interface ipv6 add v6v4 tunnel

There are four different types of automatic tunnels:

  • 6to4
  • IPv6 Automatic Tunneling
  • 6over4

In Windows Server 2003, 6to4 and ISATAP tunnels are enabled by default, while IPv6 Automatic Tunneling and 6over4 are disabled by default. In the sections below, I will discuss the basics of 6to4 and ISATAP automatic tunneling.


6to4 tunneling is typically used for automatic tunneling between IPv6 routers over an IPv4 network, similar to my earlier example in which packets had to be routed through New Orleans on their way to Las Vegas. 6to4 tunneling works by placing a special header on an IPv6 packet.

So what's so special about the packet header? Well, the header starts with the numbers 2002 and a colon. This designates the packet as a 6to4 packet. The next portion of the packet header is a hexadecimal notation of the destination host's IPv4 address. For example if the IPv4 source address was, then the IPv6 equivalent would be 2002:9D3C:5B7B:1:ID_A. The 9D3C portion of the address corresponds to 157.60, while the 5B7B portion corresponds to 91.123. The 1:ID_A portion of the header indicates that indicates that host A resides on subnet 1 of site 1.


ISATAP stands for Intra-Site Automatic Tunnel Addressing Protocol. It can be used for router-to-router communications or for host-to-router communications. Like the 6to4 protocol, ISATAP embeds the IPv4 address in the packet header. The difference, though, is that communications are facilitated by appending the IPv4 address to an adapter's link local address. For example, imagine that you had a Windows 2003 Server with an IP address of Since Windows Server 2003 uses a link local address of FE80::5EFE, the server's ISATAP address would be FE80::5EFE:

The DNS infrastructure

One of the key ingredients in a transition from IPv4 to IPv6 is a supportive DNS infrastructure. As you may know, a DNS server is used in host-name-to-IP-address resolution and vice versa. For example, if you were to enter into your Web browser, your computer would have no idea how to get to the TechRepublic Web site. Instead, it would forward the request to a DNS server, which would then query a database and match the domain that you entered to an IP address. The trick during an IPv4-to-IPv6 transition is to get the DNS server to return the IP address in the correct format. While this might not be a huge deal for surfing Web sites, it is important to remember that Windows' Active Directory service is absolutely dependant on DNS.

There are a lot of different types of DNS records and a full-blown discussion of DNS is beyond the scope of this article. At a minimum, though, an IPv4 network typically uses an A record for resolving IP addresses to host names. Once IPv6 is added to the network, the A record will only work for clients who are still running IPv4 or who are running both IPv4 and IPv6. If you have clients who are running only IPv6, then the DNS server must have a corresponding AAAA record for every A record. Clients running both IPv4 and IPv6 can reference either the A or the AAAA record.

Another important DNS function is a reverse query. A reverse query is the process of resolving an IP address to a domain name. Reverse queries are made possible through the use of pointer records. Normally, an IPv4 domain uses pointer records in the IN-ADDR.ARPA domain for resolving reverse queries. However, a host that is running only IPv6 will look for reverse lookup pointers in the IP6.ARPA domain instead. Clients who are running both protocols can use either domain for performing reverse lookups.


One last concept that I want to briefly address is Teredo. Toward the beginning of this article, I mentioned that the problem in the late 1990's of running out of IP addresses was solved by implementing NAT. Since that time, NAT has become a very heavily used mechanism. Teredo is basically an IPv6/IPv4 version of NAT.

Suppose, for example, that your entire network is based on IPv6. Even if you have made the conversion, the Internet is still based on IPv4. To get around this problem, you can use Teredo to act as a NAT device that will facilitate communications between your network and the Internet.

Teredo works very similarly to the 6to4 protocol discussed above, but the problem is that it requires the router that connects your company to the Internet to support the 6to4 protocol. Since 6to4 isn't exactly a popular protocol, it is unlikely that the router would include the necessary support. Even if the router did happen to have 6to4 support, you are still better off using Teredo because 6to4 requires that any other NAT devices that the outbound packets might pass through on the way to their destination also support 6to4. Since 6to4 is an obscure protocol, you are best off not even trying to use it.

Not as easy as it sounds

As you can see, there are several logistical issues that prevent you from being able to make an instantaneous switch to IPv6. For the time being, the easiest way to switch from IPv4 to IPv6 is to create an environment of coexistence, and then gradually start removing the IPv4 nodes. I've discussed various protocols here, but going into great detail is impossible within this amount of space. If you would like additional information about anything that I have discussed, Microsoft has published an excellent paper on the subject. You can download this paper from Microsoft's Web site.

Editor's Picks

Free Newsletters, In your Inbox