Configuring IPv6 Routing through IPv4 in a Microsoft Windows Environment

Providing Support for IPv6 in a world still predominantly IPv4 based

In this blog post on IPv6, I’m going to cover:

  • How to support transitional routing of IPv6 through IPv4
  • Configuring 6to4 and Teredo
  • Configuring IP-HTTPS and Microsoft DirectAccess
  • Understanding Tunnel Brokers

This is the fifth technical blog post on configuring IPv6 in a Windows networking environment.  My previous posts include:

Basic understanding of IPv6 addressing, and acquiring an IPv6 address block

Configuring Static IPv6 addresses on Windows 2008 R2 servers, Windows 7 workstations, and configuring DNS

Setting up DHCPv6 to Dynamically Issue IPv6 Addresses in a Network

Configuring Active Directory to Support IPv6

In this posting, I’m going to cover transitional routing, which is basically how you can setup IPv6 on your systems today, and route IPv6 over an IPv4 network.

How to support transitional routing of IPv6 through IPv4Transitional routing is needed because much of the public internet is still plain IPv4, so even if you setup you laptop with IPv6 and all of your servers at your office are IPv6, when you are at your office everything is completely IPv6, but the minute you go to an Internet café, you can’t access your office because the IP address you get from the Internet café is an IPv4 address.  So transitional routing encapsulates your IPv6 traffic into IPv4 packets and tunnels your IPv6 traffic over the IPv4 network.Configuring 6to4 and Teredo routing6to4 and Teredo are two of transitional routing standards for IPv6, which Windows 2008, 2008 R2, Vista, and Windows 7 fully support these standards.  In fact when you setup IPv6 and IPv4 on your system(s), when you type  IPconfig /all, you may notice the 6to4 and/or Teredo routing setup.  But you may also notice that while it notes 6to4 or Teredo, many times it’ll note “media disconnected” as shown below:

What that typically means is the “adapter” for Teredo and 6to4 have not been setup on your system.  You need to install the “network adapter” drivers for Teredo and 6to4 for them to work.  To do so, do the following:

1) Start | Control Panel | System and Security | System | Device Manager

2) Expand Network Adapters and see if 6to4 and Teredo are there, likely not (just your network adapter)

3) Add the 6to4 and Teredo by selecting Action | Add Legacy Hardware

4) Click Next through the Welcome screen

5) Choose to “Install the hardware that I manually select (Advanced)”, click Next

6) Click on Network Adapters, then Next

7) Click on Have Disk, then Cancel and wait a couple seconds.  A list of Manufacturers will show up

8) Choose Microsoft and select Microsoft 6to4 Adapter, Click Next, Next

9) Click next to install

10)  Repeat this process to install Teredo and IP-HTTPS

Now, after installing the adapter drivers, you might find that in Device Manager, the adapters still don’t show up, basically just your physical network adapter.  Or you might find that these new adapters installed, but they have a yellow triangle with an exclamation point noting that the adapters “did not start”.  The common reason for the Teredo and 6to4 adapters not to install or start is because your physical LAN adapter does not support Teredo or 6to4.  Check with the hardware vendor that makes your network adapter and download and install the latest physical network adapter driver and see if that solves the problem.  I’ve also seen users running virtualized Windows guest sessions on an Apple Mac try to configure 6to4 or Teredo on the virtual guest session, that won’t work.  Being that your actual network adapter is the physical adapter of the host (Apple Mac) system, the Teredo and 6to4 setup needs to be done on the adapter of the host, not in the virtual guest session.  I have successfully gotten 6to4 and Teredo to work within a HyperV host guest session, so if you wanted to test these transitional technologies on a HyperV guest in the lab, or your production routers are going to be virtualized guest sessions, this all works under HyperV.

(Hint:  Before you waste a lot of time trying to get a Teredo or 6to4 driver to configure and install on your system, keep reading this article because in about 6 paragraphs down, I’m going to tell you that Teredo and 6to4 likely are’t going to be necessary and instead work to configure IP-HTTPS instead)

So you might have to tinker with drivers to make sure you get the drivers installed and working.

Once you get the hardware stuff working, now you have to do the configuration.

To configure Teredo routing, on the “server side”, you need to have a server with 2 consecutive public IP addresses (ie: x.x.x.100 and x.x.x.101).  Teredo on a Windows server needs this as a listener adapter port, and a Teredo communications adapter port.  On the server that’ll be your Teredo endpoint, you would then type in   Netsh interface Teredo set state server {the first IP address}, so it’ll look like   Netsh interface Teredo set state server x.x.x.100    (with x.x.x.100 being the first of your two consecutive IP addresses)

On the client side, you would type in   netsh interface ipv6 set teredo client      This will enable Teredo on your Windows 7 client (assuming your hardware supports the Teredo adapter and everything installed properly in Device Mgr).  You now need the client to know where your Teredo server is, so on the client you would type in     Netsh interface teredo set state server=x.x.x.100   (with x.x.x.100 being the first of your two consecutive IP addresses of your Teredo server).  With the Teredo server and the Teredo client configured, your client can communicate IPv6 (over IPv4) to the end server.

If you want the Teredo server to be a relay so that it accepts this remote client traffic and relay the IPv6 traffic on to another IPv6 server in your network, then on the Teredo server, you would type in    Netsh interface ipv6 set interface {interface #} forwarding=enabled    (where you can find the interface # by typing     Netsh int ipv6 show int   and look for the enabled connection (usually the Local Connection) that corresponds to the working network adapter.  When I covered this in the article on DCHPv6, I gave a screenshot that shows this command and that my network adapter was 11, so in that case the command would be    Netsh interface ipv6 interface 11 forwarding=enabled   (see my blog post on DHCPv6 linked above for more on finding the interface and running the netsh command)

So all of the above will get Teredo to work so that your IPv6 client sitting at some internet café can route IPv6 traffic through IPv4 back to a Teredo server (or relay server) that’ll then get the IPv6 traffic to your end destination.  BUT, after all this, most of the time, the routing of IPv6 traffic still won’t work!  (hopefully you read through the article and got to this point before you were sitting there struggling to configure it up until now).  6to4 does not route through NAT, and being that when you go from hotspot to hotspot, you are almost always setup on the inside of NAT, 6to4 plain won’t work.  And in order for Teredo to work, IPv6 packets are encapsulated inside UDP packets, which are frequently not routed or specifically blocked by routers and firewalls.  For transitional routing to work, the IPv4 WiFi hotspot or wherever your user is connecting to must have routers that support the routing of Teredo communications.  For WiFi access points and routers that are at Internet cafes, hotels, airports, coffee shops, I rarely find Teredo to work.

So I’ve found it kind of useless trying to get 6to4 and Teredo to work as I travel around the world from hotspot to hotpot, so for all of you who were fighting to download the latest network adapter driver to support Teredo and 6to4 for your laptop and couldn’t get the Teredo or 6to4 drivers to start, again, I hope you read through this and got to this point so that “it doesn’t matter” that those drivers don’t work…

Configuring IP-HTTPS & Microsoft DirectAccessOkay, so since Teredo and 6to4 rarely work in the real world because most routers are not configured to allow Teredo or 6to4 traffic to route through the systems, what’s one to do?  This is where Microsoft came up with IP-HTTPS.  IP-HTTPS is effectively taking IPv6 traffic and tunneling it within an HTTPS stream.  This is exactly like RPC over HTTPS that we’ve been doing for years with Outlook to Exchange.  Since all WiFi hotspots allow HTTPS (SSL) traffic, having your IPv6 traffic slip through this HTTPS tunnel is the way Microsoft accomplishes this, and any time I’m traveling with my laptop and communicating over IPv6, I’m either talking to my servers natively over IPv6, or my laptop tries Teredo (and fails), tries 6to4 (and fails) and then tries IP-HTTPS, and as long as I have a good basic Internet connection, my laptop is able to communicate back to my office using IPv6 over IP-HTTPS.

Rather than going into the step by step of configuring IP-HTTPS generically, what I’m going to do is refer you to content I wrote on Microsoft DirectAccess.  DirectAccess is one of the first apps that Microsoft is providing that uses IPv6 natively and provides a VPN-less secured and encrypted tunnel from Windows 7 clients back to and into a company’s network.  DirectAccess uses IPv6, and in the real world, since I find myself seeing my laptop connecting over IP-HTTPS for DirectAccess, it’s a great tool to setup, configure, and experience IPv6 (and IP-HTTPS) firsthand.

For my content on DirectAccess, the information is as follows…

Deployment Guide for DirectAcces (  This is a step by step guide I wrote on installing and configuring DirectAccess.  I go through the process of configuring all of the server points, and configuring systems (Windows 7 end client and the DirectAccess server).  The DirectAccess server is actually an IPv6 “router”.  It is configured to support Teredo, 6to4, and IP-HTTPS for incoming communications, and the end client communicates with the DirectAccess server.  Most of what I covered earlier in this article on setting up two consecutive IP addresses for the external NIC, setting up forwarding, etc are all embedded in this configuration guide.

Video on Setting up DirectAccess (  I actually led a 70-minute session at TechEd 2010 where I went through this deployment guide I reference and go through a step by step implementation of DirectAccess.  Between the deployment guide, and watching the video, much of the basic IPv6 configuration stuff covered in the past 4 technical blog posts I’ve written on IPv6 now start to come together.

It’s actually fun to fiddle with DirectAccess (although warning, it is not a simple whip together in a couple hours solution, it’s for those who really like to get technical with this stuff and like a challenge…)  But what you’ll find with DirectAccess is a real world solution based on IPv6 that utilizes IP addressing and everything to prove out that you can really use IPv6 for practical purposes!

Understanding Tunnel Brokers

Okay, before I end this blog post on routing IPv6 through IPv4, I need to touch on Tunnel Brokers.  So there are “tunnel brokers” out there that are available to help you take your IPv4 and IPv6 client systems, and access IPv6 content on the Internet.  Effectively, you load on a driver / applet on your client system, and you establish a tunnel from your system, through the Tunnel Broker’s network to access servers and services, things like over IPv6.

For the individual or small business that doesn’t want to setup it’s own DirectAccess server and relay/routing setup, the Tunnel Broker can drastically simplify the process.  Say for example you want to access the latest IPv6 Facebook site from your home office, but your DSL provider doesn’t have IPv6 support yet and your company hasn’t setup IPv6 routing on their end, you can simply download the Tunnel Broker driver(s), install them on your home system, and within about 10 minutes, your home system is now configured using IPv6 to Facebook’s IPv6 site.

For larger businesses, you will likely want to setup your own IPv6 architecture and get ahead of the curve so that your employees are configuring their home systems to communicate IPv6 over a corporate tunnel back to your office using something like Microsoft DirectAccess.  You can do all of the IPv6/IPv4 tunneling on your own straight from your end users to your corporate network without going through a middleman like a Tunnel Broker, but they serve a purpose for small businesses or individuals who may want or need IPv6 functionality without having to setup an entire IPv6 infrastructure.

There are a handful of Tunnel Brokers out there, one that serves the United States is Hurricane Electric (  This Wikipedia site lists various Tunnel Brokers around the world:

So that’s it on routing IPv6 over an IPv4 network.  With the past handful of blog posts on IPv6, you now have the basis for getting official IPv6 addresses, assigning them to servers and workstations (statically and dynamically), and providing a way for your end clients to communite IPv6 to your network, even through they may be connecting to an older IPv4 WiFi Hotspot or network connection.

My next blog post will be titled “Best Practices at Configuring Applications for IPv6” where I’m going to address getting things like Exchange, SharePoint, Web servers, and the like active on IPv6.  I’ll address server naming (ie: do you keep the same name for your IPv6 servers as your IPv4 servers, or do you make special server addresses), and the like.  On to application servers…


Copyright © 2011 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022