Configuring an ISATAP Router with Windows Server 2008 R2 (Part 1)

If you would like to read the next part of this article series please go to Configuring an ISATAP Router with Windows Server 2008 R2  (Part 2).


I remember back in the 1990s when Tom and I put together our first network. We were using Windows 95 and connecting the computers to each other using 10Mbps Ethernet and NetBEUI. It was almost a no brainer to get the network set up since we didn’t have to worry about addressing issues. You just plugged the computers into the hub (switches weren’t that popular for home networks at that time) and we were able to connect to each other and view network shares.

Times quickly changed when Microsoft recognized that the future of computer connectivity was the Internet. In order to connect to the Internet, we had to learn about TCP/IP. Oh, my. What happened to the simple life with NetBEUI? With the introduction of TCP/IP, we had to learn about IP addressing, subnet masks, and routing. Then we had to learn about binary notation, “dotted quads”, CIDR, and bit matching. It took a lot of work to master this “new” networking protocol but the efforts were worth it. What we learned about TCP/IP over 15 years ago, we continued to use every day in our consulting and writing practices.

Unfortunately, however, the version of TCP/IP we all learned about in the 1990s was based on IP version 4 (IPv4). When IPv4 was designed, they used a 32 bit addressing methodology that would theoretically enable over 4 billion IP addresses for the entire address space. And like the famous Bill Gates quote “640K should be enough for anyone”, the architects of IPv4 believed that 4 billion addresses should be enough to last for a very long time. It seemed like a reasonable assumption.

Running out of room

What the creators of IPv4 back in 1970s (primarily the engineers at the U.S. Defense Advanced Research Projects Agency – DARPA) didn’t know was how popular the Internet would become after it “went commercial” in the 90s. They never imagined the explosive growth of global networking, and couldn’t have predicted that so many different types of electronic devices would end up being connected to the Internet. Now, as we enter the second decade of the 21st century, those 4 billion addresses are almost used up – in fact, it’s been predicted that public IPv4 address exhaustion will take place sometime this year (2011) when the Internet Assigned Number Authority (IANA) runs out of addresses to assign.

I won’t be surprised if, when that last public IP address is allocated, there is a faux panic; you might see in the headlines that “the Internet is dying” and similar inaccurate overreactions. But like most pseudo-panics, it will get the attention of the decision makers and they’re going to expect you, the IT professionals, to be able to provide a reasonable response to the unreasonable headlines.

This is why IPv6 fits is important to your future. While most of you have been peripherally aware of IPv6 for a number of years, you probably really didn’t see a need to learn much about it. Why? No one was actually using IPv6 in production, almost no operating systems that people actually use were IPv6 capable, and even if you were using IPv6 capable operating system, the applications running on those operating systems were not IPv6 aware. Given these and other reasons, it seemed reasonable to avoid IPv6 until there was a compelling reason to get on top of it.

Getting to the next level

Let’s be honest here: there is one other important reason most of us avoided IPv6 – complexity. Many people forget how much time it took them to learn IPv4 since it was so long ago and now that you’ve been immersed in it for years, you’re fluent in the IPv4 language. But for most, it took a lot of effort to get to that point. You paid your IPv4 dues and are happy to live in an IPv4 world. IPv6 is even more complex than IPv4. While you can leverage some of the knowledge you have about IPv4 to understand how IPv6 works, there are still some significant changes to the IP protocol that will require you to spend many hours in the chair in front of a book (these days, probably an e-book).

But as Yoda might say, “IPv6 must you learn”. While the exhaustion of the public IPv4 space isn’t going to be the catastrophic event that some may try to imply, it is a harbinger of things to come. Microsoft has been aware of this issue for quite some time and has quietly but effectively enabled IPv6 in their operating systems since Windows XP and Windows Server 2003. However, the Windows Server 2003 and Windows XP IPv6 technologies were add-on features and not fully supported. Microsoft rectified this situation with Windows Server 2008 and Windows Vista – which were the first full-up IPv6 capable operating systems creating by Microsoft. Support for IPv6 became even more robust with Windows 7 and Windows Server 2008 R2.

It’s great that modern Microsoft client and server operating system are fully IPv6 capable, but there’s still a problem. If you’re like most of us, not all the operating systems and applications and network gear on your network are IPv6 capable. Most (all?) of today’s production networks are a mix of IPv4-only and IPv6 capable operating systems and applications. We can agree that the future is IPv6, but we have to deal with the present situation where there is a mixture of IPv6 and IPv4 resources.

IPv6 transition technologies

The industry has been aware for quite some time that this would be the case, and therefore the IETF has been working  on various IPv6 transition technologies that will provide you with a bridge between your IPv4 and IPv6 networks. The IETF realized that we were not going to rip-and-replace our current networks and applications just to support IPv6, but they did believe that if they could provide a collection of IPv6 transition technologies, IT pros could then use these technologies to slowly migrate/transition your existing infrastructures from IPv4 to IPv6.

The IPv6 transition technologies all have one thing in common – they tunnel IPv6 packets inside an IPv4 header, which means these are all tunneling technologies. When the IPv4 packets reach their destinations, the IPv4 headers are removed at the endpoint and the IPv6 packets are exposed and consumed by the endpoint device.

Several of these IPv6 transition technologies are aimed at allowing you to tunnel IPv6 packets over an IPv4 Internet. While there are some ISPs that have enabled IPv6 on their networks, you would be hard pressed to find a scenario where you can be guaranteed that there is going to be native IPv6 support for end to end connectivity. And even if the ISPs are all upgraded to support native IPv6, there is no guarantee that the endpoint (web server, mail server, etc.) is IPv6 capable.

IPv6 transition technologies that enable tunneling IPv6 packets over an IPv4 Internet include 6to4, Teredo and IP-HTTPS:

  • The 6to4 IPv6 transition technology is used when a client system is assigned a public IP address on the IPv4 Internet.
  • The Teredo IPv6 transition technology is used typically when the client system is assigned a private IP address (and for modern Windows clients, will be used when the client is assigned a public IP address and 6to4 isn’t available).
  • IP-HTTPS is a IPv6 transition technology developed by Microsoft that not only tunnels IPv6 packets in an IPv4 header, but then also tunnels the packets in an SSL tunnel, the premise being that not all firewalls or proxies will work with Teredo or 6to4, but almost every firewall and proxy will allow outbound access to SSL (TCP port 443).

While 6to4, Teredo and IP-HTTPS enable you to tunnel IPv6 packets over the IPv4 Internet, they are not used to tunnel IPv6 packets over an IPv4 intranet. So how do you handle that scenario?

ISATAP to the rescue

The IPv6 transition protocol you use to support intranet tunneling of IPv6 packets over an IPv4 intranet is ISATAP, the Intra-site Automatic Tunnel Addressing Protocol. ISATAP (RFC 4214) provides a way for you to use unicast IPv6 connections on an existing IPv4 intranet. With ISATAP, IPv4-only applications use IPv4 while IPv6capable applications can take advantage of IPv6 connectivity. Both IPv4 and IPv6 traffic share a single common IPv4 infrastructure, which includes IPv4 routers, IPv4 DNS and IPv4 DHCP. ISATAP enables you to immediately provide IPv6 connectivity while the IPv4-only infrastructure is slowly migrated to IPv6 capability.

Like the other IPv6 transition technologies, ISATAP tunnels IPv6 traffic across an existing IPv4 infrastructure by encapsulating IPv6 packets in an IPv4 header. This allows you to deploy IPv6 capable operating systems and services without having to redesign your entire network infrastructure. ISATAP emulates a logical IPv6 subnet to a set of ISATAP hosts over an IPv4 network infrastructure. This allows all ISATAP hosts to automatically tunnel IPv6 packets inside of an IPv4 header to connect to each other using IPv6. In addition, they can reach other IPv6-capable networks or the IPv6 Internet through an ISATAP router.

The ISATAP router is the key to a working ISATAP solution. The ISATAP hosts on the network will be able to query the router for IP addressing information, which is used to configure the ISATAP adapter on the ISATAP host. Modern Windows client and servers have their ISATAP adapters enabled by default. If they can resolve the name ISATAP to an ISATAP router and connect to the router, they will automatically configure their ISATAP interfaces.

Now that you understand the importance of transitioning to IPv6 and the role that ISATAP will play in that, in the second part of this article we’ll walk you through the details of how ISATAP works, and how to configure a Windows Server 2008 R2 computer as an ISATAP router. See you then! –Deb.

If you would like to read the next part of this article series please go to Configuring an ISATAP Router with Windows Server 2008 R2  (Part 2).

About The Author

1 thought on “Configuring an ISATAP Router with Windows Server 2008 R2 (Part 1)”

  1. I try to setup a tunnel broaker subnet (6to4) on my hostet vserver but it sucks, i can access from local host (no routing reqired) but from the internet nothing. How i can setup huricane in Windows Server 2008 r2. I think 2008 r2 is IPv6 compatible but the configuration is to stupid.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top