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

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

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
  • 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

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
. 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


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

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