Mark Minasi's Windows Networking Tech Page
Issue #105 March 2013

Document copyright 2013 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text. (Thank you for respecting my intellectual property rights!)

What's Inside

  • News
    • Learn with My Seminars, Audio Recordings and More!
  • Tech Section
    • Understanding (and Maybe Killing) the ISATAP, Teredo, and 6to4 "Imaginary" NICs
  • Conferences
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

As I have observed before in this periodical, I don't know about you, but I like a clean IPConfig.  Getting one, however, seems to get harder with time, particularly with those bogus extra NICs that have something to do with IPv6.  You've seen them  --Teredo, ISATAP, 6to4 -- and they really chap my hide.  I mean, what are they supposed to do for me, anyway?  And how do I get rid of them?

Well, in fact they are called pseudo interfaces and you know, once you get to know them, they're not all that bad.  So in this newsletter, we'll get two things done: first, you'll see how at least one of those pseudo NICs might be pretty useful and, second, you'll see how to get rid of the bunch of 'em, if you don't think they'll do much for you.  As the End of IPv4 gets a bit closer, it's not a bad thing to learn a few new IPv6 tricks and we'll get right to them but first, a word from our sponsor...

Don't Miss ITEdge Intersection!

Windows Server 2016 is coming, are you ready? Server 2016 and many other important topics are the focus of ITEdge Intersection at the MGM Grand in Las Vegas, Oct 25-29. Your favorite speakers are there, including Scott Guthrie, Brad Anderson, Jeffrey Snover and of course, Mark Minasi. Register today for the conference and a workshop and you can go home with an XBOX One S, Surface 3 table or MS Band 2. Register at

Bring Mark's Windows 10 Support Class and Our PowerShell Classes to Your Site

Mark has delivered his new "Deploying, Managing and Securing "the Last Windows: Working with Windows 10" class to nearly a dozen clients, and the reviews are uniformly great.  Designed for the Windows 7 support pro, this course tells you everything you need to know to support, deploy, or manage Windows 10 systems.  Fast-paced, lecture-based and entertaining, this course gives you the shortest path to Windows 10 expertise. Learn about Windows 10's completely new licensing approach.  See how to enable the new "parallel universe" security tools.  Discover the cloud-y new tools in Windows 10 like joining a system not to an Active Directory but instead to a cloud.  Find out what you can learn at our course outline at 

To bring this class to your site, just drop us a line at

And while you're at it, are your folks PowerShell adepts?  There really isn't a productivity-enhancer available for Windows support people like PowerShell.  Bring Mark's "Learning PowerShell: Hands-On with AD, Networking, and More" class to your site and he'll make your command-line-hating techies into PowerShell fans.  Outline at 

Understanding (and Maybe Killing) the ISATAP, Teredo, and 6to4 "Imaginary" NICs

Now, anyone who knows me knows that I'm a huge fan of IPv6.  I've been running it out of one of my locations for years and can't wait for the folks who provide my business Internet, Cox Cable, to make me "official" and get my network that /48 network that I so fervently desire, rather than the miserly one or two IPv6 addresses they give me now.  I mean, who doesn't love the idea of having more routable IP addresses than you can shake a stick, or a plenitude of sticks, at?  Who wouldn't like to never, ever again have to subnet a network, or deal with trying to connect two systems, both behind NAT routers?  Nobody.  Noooobody.

But take a look at this IPConfig output, and you'll see -- if you didn't already know -- what I mean.

An IPCONFIG grown sadly obese

This is an IPConfig for a Windows tablet, for heaven's sake.  What a mess.  We can, however, fix it, and I'll show you how to do it from the GUI, netsh, and PowerShell. Before we do, though, here's a very brief look at what they are and why they are in Windows in the first place.  Before I do that, though...

Killing 6to4, ISATAP and Teredo for the Impatient

 If you're in a rush, this Registry entry will kill 6to4, Teredo and ISATAP in one shot.  Heck, it's a Registry entry, so you could even roll it out as a group policy.

  1. Look in the Registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters for a REG_DWORD entry called DisabledComponents.  If it's not there, create it in Parameters.
  2. Set its value to 1.  (It confused me a little, as the docs call for a decimal "1" and the Registry screen wanted hex, but I figured it out.)
  3. Restart the computer.

Dumb hex joke aside, it's actually a pretty nice setting, as it doesn't kill IPv6, just these "pseudo"  guys.

The Dark in the Middle of the Tunnel:  What Problem 6to4, ISATAP and Teredo Solve

As you probably know, the Internet has a problem:

  • It was built atop "IPv4" that was only intended to last for just a few years until the "OSI" protocols got finished. (We're still waiting on that.)
  • IPv4 only includes about four billion addresses, in a world of seven billion people, many of which want more than one IP address.  (One for the tablet, one for the smart phone, one for the laptop...)
  • A central group called "ICANN" (Internet Corporation for Assigned Names and Numbers) are the folks who hand out blocks of those four billion IPv4 addresses.  They don't give them to you and me, they give them to five sort of "regional distributors" called Regional Internet Registries or RIRs.  There's one for North America (ARIN), Europe (RIPE), Asia (APNIC), South America (LACNIC) and Africa (AfriNIC).  (Yup, Antarctica and Australia got left out, continent-wise.  I guess they missed the meeting.)
  • When ICANN gives (gave, actually) blocks of IP addresses to RIRs, they handed them out in 16-million-address chunks.  In February of 2011, however ICANN handed out the last blocks to its RIRs.  That's it, there's no more.  RIRs then tear off smaller chunks and give them to groups like big organizations and ISPs.
  • Since February 2011, APNIC (Asia) and RIPE (Europe) have become essentially depleted.  North and South America are on track to run out some time in 2014.  After that, all available blocks of IP addresses will only be in the hands of ISPs and, well, AfriNIC.  (Note to cloud vendors:  you need lots of IP addresses.  Start building those cloud centers in Cape Town, it's supposed to be nice there year-round.)
  •  So are we out of IPv4 addresses?  Sort of.  Think of it like this:  imagine if Ford stopped making F150 trucks back in 2011.  The "regional dealerships" would still have them in storage, as would Ford dealerships ("ISPs") all around the world.  It'd take time, but eventually the last dealer would sell the last F150, and that'd be it.  Restated, at some point in the next couple of years, it'll become impossible for a business to get the static addresses it'll need to set up a new Web, mail, DNS or whatever Internet server. 

There is, however, an answer to the problem of IPv4 depletion.  It's a replacement for IPv4 called IPv6 and it supports enough addresses to support literally trillions of organizations, each of which would have enough addresses to manage networks of over 65,000 geographical sites, and up to 18 quintillion computers at each of those sites.  IPv6 has been around for quite a while and works pretty well.  Organizations like Microsoft have been running their internal networks on it for years.  The Windows OS has supported it for seven years.  The Mac does.  Linux does, and so on. 

Of course, moving to v6 involves some changes.  For one thing, IPv6 addresses are longer than IPv4 addresses.  For example, where an IPv4 address looks like, an IPv6 address might look like 2607:f8b0:400c:c01::69 -- weird-looking, yes, but you get used to it.  You've got to reconfigure your routers and mess with DNS a bit.   But it's not bad overall, and solves the "we don't have enough addresses problem" forever.  (Yes, I did say forever, unless you can figure out how the planet would survive having a trillion humans on it at the same time.)

So why doesn't everyone use IPv6 now?  There are lots of little reasons, many of which are invalid and basically boil down to "I'm too busy to worry about v6," or "I think I can retire before I have to worry about it," but the main legitimate reason for un-Six-ing is coverage.  You can find an ISP and get connected to the v4 Internet almost anywhere on the planet.  There is also a parallel "v6 Internet" but, well, it's not so widespread as I write this.  In some cases, you can't get it at all -- Skunk Hollow Internet and Bowling Alley, Ltd isn't going to start supporting v6 until they absolutely have to.  Nor is this confined to small ISPs, as Charter Communications doesn't either, as far as I can see.   Other ISPs may support it, but tentatively.  Cox Communications, who provides my business Internet, has started handing out IPv6 addresses to home customers, but business customers still can't get a block of IPv6 addresses, although Cox says that may change later this year.  Similarly, my Verizon hotspot gets two IPv6 addresses, which is great, but I'm told that getting IPv6 for a business isn't so easy. 

Thus, for some lucky folks, IPv6 is simple -- just readjust your router, dial up some DHCP settings, and you're on the v6 Internet.  For the rest of us, however, we've got to wait for our ISP before we can do even the most basic IPv6ish thing.  (Which seems to be by the way, to ping a Google address that only responds to IPv6, ""  That's Step One before we try to connect the Hong Kong office with the Galax, VA office.)

The problem boils down to this:


Problem:  an IPv6 client can't get to an IPv6 server because of incomplete IPv6 coverage

In "IPv6 transition talk," here we see two "IPv6 islands."  In the real world, that might mean that you've got offices in different cities and want their IPv6 addresses to talk to one another -- Chicago's one island, Atlanta's the other.  Or it might mean that you're sitting on your home network -- :"IPv6 Island, Population = 1" -- and want to connect to that office in Chicago as a telecommuter, or just want to ping  (You will not believe how different Facebook is on IPv6.)  In any case, that leads me to the next thought:


An answer:  tunneling


For folks who are impatient to get to v6, this is pretty neat stuff.  IPv6 over IPv4 tunnels let us set up our network to use the actual incomplete IPv6 Internet where possible, but where it doesn't yet exist, we can do a bit of the "insert magic here" stuff and create an interim IPv6-over-IPv4 link.  Eventually wherever we needed to install a tunnel actually will get IPv6 connectivity and, when that happens, we just turn the magic off and just use straightforward native ISP-provided IPv6 goodness.  Here's some more detail:

Requirements: tunnel protocol and tunnel relay/routers


Thus, to live in the IPv6 future today, you need

  • IPv6 software on your servers and clients (which is easy, assuming that everything is Vista/Server 2008 or later)
  • IPv6 tunnel software-awareness on your servers and clients.  Windows supports some of the tunnel protocols out there, but not all of them.
  • This isn't an exact requirement, but in many cases your local router -- which might have to be the one at your house -- needs to be a router that understands IPv6 and understands the tunnel protocols.  Failing that, there are public routers that'll do the tunneling for you, but access to them may cost a bit and/or those routers may not be particularly fast.
  • That goes for the router on the other side as well -- it's got to be tunnel-smart or have access to a tunnel-smart one on the Internet.

In case that's not clear yet, here's another way of thinking about tunneling.  Imagine that you decide that you're going to ride your jet ski from Salt Lake City to Honolulu, using the "interwaterway."  Hop on the jet ski, head west and the first 20 miles is sort of okay, but soon you end up on the western shore of the Great Salt Lake with several hundred miles of land -- very dry land -- between you and the Pacific Ocean.  Undaunted, you rent a truck and hire someone to get a big tub of water, put the tub into the back of the truck, fill it with water and then pick you and the jet ski up and put you in the tub.  (Let's hope he has some big friends.)  Your new assistant then starts up the truck and takes off, and you can enjoy "tunneling" your water-borne device through the "interlandway."  Eventually, you get to the sea, at which point you get "un-tunneled" by  enlisting a few large people to move you and the jet ski into the Pacific, and off you go, Oahu or bust!  Technically, then, you've been on the water the whole time.

The idea of stuffing one set of packets (like an IPv6 conversation) into another set of packets (like an IPv4 conversation between two tunnel routers) is not unusual or new.  But the specifics of making the tunnel work have necessitated different tunneling approaches.  Microsoft supports three out of the box -- here's why each is there.

6to4 Tunneling

6to4 is the simplest of the three tunnels.  Laid out in RFC 3056 and 3068 (released 2001), 6to4 works by creating a sort of imaginary NIC ("pseudo adapter") that gives you a peculiar-looking but functional IPv6 address even if your local network's not running IPv6 much.  Then it tries to automatically  locate a router that can do the 6to4 tunnel thing -- there's an automatic method, or you can hand-configure one.  The catch is that it needs to start from a routable public IPv4 address, and really doesn't like to run behind a NAT router.  Here are more details.

Step One:  An IPv6 Address, Born from an IPv4 Address

With 6to4, you have that "Tunnel Adapter 6to4" NIC reported in the IPConfig output in the earlier screen.  Microsoft's 6to4 software constructs an IPv6 address for the pseudo-adapter like so:

  • An IPv6 address is written in 32 hex digits with colons between each group of four hex digits.
  • The leftmost four digits for a 6to4 address is "2002."
  • The next eight digits come from your system's IPv4 address.  6to4 takes that eight-bit IPv4 address and converts it to eight hex digits.  For example, suppose your IPv4 address were""  In binary, that would be 10000111 00000100 00000110 00000010, which in hex becomes 87 04 06 02, and so at that point we'd have 12 of the hex digits for the address covered -- 2002:8704:0602.
  • Then add 12 zeros to get 2002:8704:0602:0000:0000:0000
  • Finally, round things out with a repeat of the hex-ized IPv4 address, and you're at 2002:8704:0602:0000:0000:0000:8704:0602.

If you're not a v6 tech, then you may not know that in v6 you're allowed to take any one contiguous group of zeros and just write them as "::," and so the final address would be written as 2002:8704:0602:0::8704:0602.  So remember:  if you see v6 traffic from an address starting in 2002, it's from a 6to4 adapter, and the next eight hex digits gives the IPv4 address of the sender.

Getting a Relay, and Anycast Addresses

Having a 6to4-ish IPv6 address and an imaginary 6to4 NIC's a start to get on the v6 Internet but you won't get far with just that.  As the earlier diagram showed, you can't use a 6to4 tunnel (or any tunnel, for that matter) without being able to find a kindly router that can do the tunneling for you.  In the 6to4 world, that's called a "6to4 relay."  Some ISPs have set up 6to4 relays, but as far as I can see most don't because honestly any public router just hanging out and offering to do all of that packing and unpacking is going to be very, very busy, and one wonders who'd pay for that?  Some generous souls have put 6to4 relays on the public Internet, but you needn't look, as Microsoft has for years run a free, publicly-available 6to4 relay, as we'll see in a minute.

But even if Microsoft didn't offer us a 6to4 relay, we might be able to find one automatically, with the help of a nearby Internet border router.   RFC 3068 specifies another approach whereby you needn't look for a 6to4 relay, but instead just ask for one by specifying a router's address as being anywhere within a special range of addresses, 192.88.99.x.  That's an address called an "anycast" address, which means "something that looks like a regular old IP address but that in fact can be responded to by any of a number of systems that have all agreed to respond to that address."  In other words, lots of 6to4 relays out on the Internet have all agreed to answer to, no matter what their real IP addresses are.  You just tell your 6to4 software to go use the 6to4 relay at, and through the magic of "anycast," your request eventually finds its way into the lap of one of those many thankless 6to4 relays.

More specifically, the idea is that if you are a 6to4 relay, then you should advertise that you respond to anycast IPv4 address, even though other systems also respond to that address.  (No matter how many systems can respond to a given IPv4 anycast address, only one will respond, and the backbone routers on the Internet handle the "find me the closest system that responds to" part.)  Once you've found someone with a public 6to4 relay, you may have to contact them to get a logon account on that relay (and if you do, it'll probably be free), or it'll drop your traffic.  Pinging from Cox or Charter got me to a well-known source of IPv6-related assistance, "Hurricane Electric" at  Pinging it from Verizon turned up a provider in Germany.  You probably won't have to worry about that, though Microsoft runs a 6to4 relay as well and the Windows 6to4 adapter is configured to use it by default.

Want to try it out?  You can, and as the Microsoft relay's name is baked into it it should be effortless, except for just one thing:

If 6to4 sees that your IPv4 address is not a public, routable address, then the adapter simply refuses to work

Rephrased, if your v4 address starts with 10.something or 192.168.something or 172.16.something, then 6to4 will just say "Media disconnected."  Microsoft had it do that because if you've got one of those ranges, then the chances are very good that you're behind a NAT router.  (If you're working from a home or small business network and your router says "Belkin,"Linksys," "Netgear" or the like on it and/or you paid less than $200 for it, then you're almost certainly behind a NAT router.  The problem is that NAT routers simply don't know how to handle 6to4, as 6to4 is built not atop the TCP or IPv4 protocol, but instead one called simply "Protocol 41."  (I don't know about you, but the whole thing seems a bit sinister-sounding; "very well, Mister Bond, you leave us no choice but to employ Protocol 41."  Say it with a sinister British accent and you'll see.  Seriously, IPv4 is also known as "Protocol 4," TCP is number 6, and actually Protocol 41 is also known as IPv6.  NAT not understanding IPv6 makes a lot of sense, as NAT was basically invented to make it easier to avoid IPv6.)

Before You Disable It, Here's How to Try It Out

So... want to try out connecting to IPv6 over your v4 connection?  Assuming that you haven't disabled IPv6 or 6to4 explicitly, then from a Vista or later box (I've only tried this on a Windows 8 desktop, but it should work on any of the Vista and later OSes), then

  1. Connect your computer directly to the Internet, as in "disconnect your DSL or cable modem from your router, turn the Cable/DSL box off, connect the Ethernet cable coming from the cable modem/DSL router directly into your computer's Ethernet port, turn it back on, wait 30 seconds, and do an IPConfig /release and then an IPConfig /renew."
  2. Fire up IPConfig /all and you may see something like this:

Sample functioning 6to4 output

Look to the bottom part of the output, and you see that 6to4 doesn't report "Media disconnected" but instead now looks like a real NIC.  The important things to notice here are the IP address under "Ethernet" --, a public routable address and one that does not start with 10, 192.168 or 172.16 -- and the made-by-6to4 IPv6 address, 2002:4757:98cd::4757:98cd. 

Ready to try out something IPv6ish?  Ping that Google address that only responds to IPv6.  It should look like

PS C:\> ping -n 1

Pinging [2607:f8b0:4002:c04::6a] with 32 bytes of data:
Reply from 2607:f8b0:4002:c04::6a: time=63ms

Ping statistics for 2607:f8b0:4002:c04::6a:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 63ms, Maximum = 63ms, Average = 63ms
PS C:\>

Or fire up IE and visit for more v6-only goodness.

If you're on Windows 8 or Windows Server 2012, you can ask PowerShell for a bit more information with get-net6to4Configuration.  Mine looks like

PS C:\> Get-Net6to4Configuration

Description : 6to4 Configuration
State : Enabled
AutoSharing : Default
RelayName :
RelayState : Default
ResolutionIntervalSeconds : 1440

You can see the shout-out to Microsoft's 6to4 relay.  If you're a regular PowerShell user, then you may have guessed that you can use set-Net6to4Configuration to point to another relay, as in

Set-Net6to4Configuration -relay

So what about 6to4 -- why not use it?  Again, the vast majority of Windows users won't find it useful because of the can't-work-with-NAT issue, and some will find it less than useful because of the relatively small number of 6to4 relays on the Internet.  (And besides, consider that by default every Windows box using 6to4 runs through that one Microsoft relay.)  Many folks who use v6/v4 tunnels tell me that a newer tunnel type, "6rd," ("IPv6 rapid deployment") is a better choice in today's network world.  There's no built-in Windows support for it, but third parties offer 6rd Windows support.  Personally I've not worked with it so I can't say.

If, however, the simplicity of 6to4 appeals to you, you work from a house or small business and your IPv6 needs are meager, then you might just put the 6to4 routing on the one computer in your building that actually isn't behind a NAT router and does have a public, routable IP address... your router.  My ASUS RT-N66U access point/router does 6to4, and as a result my internal systems get an IPv6 address even if they've disabled all of the tunnel protocols.  (The router also does 6rd and 6in4, two other tunnel approaches.)

Shutting Off 6to4

6to4 not for you?  Then there are three ways that I know of to get rid of 6to4 and its IPConfig-cluttering pseudo-NIC.

Method One:  via Device Manager

We've seen that 6to4 creates an imaginary NIC, but no NIC, whether imaginary or not, will work without a driver, so disabling the 6to4 driver is one pretty sure-fire way to get rid of it.  The steps are easy:

  1. Open Device Manager.
  2. On the MMC's menu, choose View / Show Hidden Devices.
  3. Open the "Network Adapters" icon.
  4. Under that, you'll see "Microsoft 6to4 Adapter."
  5. Right-click it, choose Disable, and click "Yes" to the inevitable "are you sure?" message.
  6. Close Device Manager.

Method Two:  Netsh

You can disable 6to4 with the netsh.exe command, a command-line tool.  This should work for any version of Windows from Vista on up.  From an elevated command prompt, type

netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled

You'll get a laconic "Ok." in response.   To re-enable 6to4, just replace "disabled" with "enabled." 

Method Three:  PowerShell

PowerShell is slowly replacing things like the netsh commands.  To remove 6to4 from PowerShell, type

set-net6to4configuration -state disabled

To re-enable it, run the same command and replace "disabled" with "enabled."  That command's only in Windows 8, Server 2012 and later versions of Windows.

Teredo:  Another Tunnel, But it Can Work Behind NAT

6to4 is a useful way to get to a v6 location while we're waiting for the world-wide IPv6 Internet, but it's got two problems. 

First, there's that NAT thing.  Easily 90-plus percent of Internet users are behind NAT routers, meaning that 6to4's not going to be very much use to them.  Again, if they're attached to an access point/router that has 6to4 router software on it, then they can use the router's 6to4-ness to get to v6 transparently, and a 2002: address will pop up in IPConfig even on a system without pseudo interfaces.  But unless you've got a router of that type -- and the vast majority of small business and home routers do not -- then you'll need to run the transition stuff right on your Windows boxes in order to get to V6, and that's a pain.  (Tunnel broker has a page listing small routers that they've found support v6 and in some cases v6 tunnel protocols.  Not complete but helpful, and it's at  Bottom line:  most of us can't use 6to4 on our small networks.

The second problem 6to4 presents is that it needs some server out on the Internet packing and unpacking that data -- the 6to4 relay -- and that burns up CPU and network time.  It's nice that folks like Hurricane Electric and Microsoft run free public 6to4 routers, but in the end analysis that's a lot of heavy lifting for just a few companies.  (Imagine if everyone who wanted to use DirectAccess ran that traffic through Microsoft's 6to4 server.  Ugly.  Slow.)  Instead of needing good Samaritans to keep 6to4 going, simple economics might suggest lots of 6to4 routers operated by the people who want you to be able to get to their stuff.  Thus, if Amazon wants me to be able to get to their v6 stuff, then maybe Amazon should run a 6to4 relay, and it'd be quite fair if that 6to4 relay only helped me get to Amazon's stuff.  Yahoo could do the same, as could Google and so on.  Of course, for that to work it'd have to be easier for my client to find X site's 6to4 server and then change over to on the fly as necessary.  6to4 doesn't do that and never will.

Teredo (RFC 4380, 2006) aims to solve those problems with a tunnel protocol that is built with NAT in mind, requiring anyone who wants clients to be able to Teredo to their servers to run "Teredo relays" to support those clients.

The problem with building a protocol that lets machine A behind one NAT router to talk to machine B behind another router is that NAT -- which is a regrettable, protocol-killing, innovation-stifling chimerical piece of crap -- only allows machines behind a NAT router to begin a conversation, not be solicited to start a conversation.  For example, suppose I'm sitting at a computer behind a NAT router and want to view a Web page.  I do that by firing up IE and typing in that Web server's address into my address bar, which has the effect of my browser sending a message to that Web server saying, "I'd like to talk, is that all right with you?"  Now, I can do that because the Web server has a public, routable IP address -- it doesn't sit behind a NAT router.  (It might, but it'd involve a lot of firewall work.)  Once a system behind a NAT router has initiated a conversation, that NAT router is now listening for a response from that Web server, and at this moment, the NAT router is essentially acting for my computer like a firewall that says, "no messages get through me unless they are responses to requests made from a system on my network."   (Another way to think about this is that NAT says to the rest of the Internet, "speak to me only when spoken to -- when I start the conversation."  That's fine, but now let's return to machines A and B.  They'd like to start a conversation, but how?  They're both behind NAT routers, so if A tries to start communicating with B, then B's NAT router will discard the message, and the same would happen if B tried to strike up a conversation with A.

This is an old problem (and one of the many reasons why I can't wait until NAT withers away and dies) called "NAT Traversal," and a number of protocol vendors have had to tackle it.  For example, consider instant messaging -- it seems to be peer-to-peer, but it clearly can't be because of NAT.  Instead, here's how machines A and B exchange instant messages over NAT.

  • Someone -- Microsoft, AOL, or whomever -- sets up a server on a static public IP address.
  • Clients, like machines A and B, regularly ask that server, "are there any messages for me?"
  • As the client has opened the door to the IM server by asking the question, the NAT router will now accept answers from the IM server and pass them to the client.
  • In order for this to be "instant," machines A and B have to constantly poll the IM server, burning up CPU cycles on the client and server and wasting bandwidth.

In contrast, in a world without NAT routers, the system would be

  • When A or B have nothing to say, then don't bother the IM server.
  • When A or B do have something to say, they directly contact the IM server with their message. 
  • Whenever the IM server has a message for a system, it breaks its silence and directs an IP communication to A or B to send them their messages.

This "waste resources constantly polling some server on the Internet because I'm behind a NAT router" stuff is something service providers have been having to cope with for ages, and Teredo's creator employed some of those ideas -- of necessity -- to make Teredo NAT-proof.  Teredo's fairly complex, but here's roughly what happens.

  1. As with 6to4, you start with a system that understands IPv6 (Vista and later) but lacks an IPv6 infrastructure, like a home or small business user.  If you don't see a Teredo adapter, just open up PowerShell and type Set-NetTeredoConfiguration -type default.   You have Teredo installed, and so you've got a another pseudo-NIC, the "Teredo Tunneling Pseudo-Interface."  An IPConfig /all shows me this on my system:
Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:422:1d86:b8a8:63a3(Preferred)
Link-local IPv6 Address . . . . . : fe80::422:1d86:b8a8:63a3%34(Preferred)
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled

(By the way, notice the "NetBIOS over Tcpip disabled."  That's always the case in any kind of v6, as IPv6 does not support NetBIOS at all.  WINS couldn't run on it if it wanted to.  And you thought you needed a reason to like IPv6.)

  1. That Teredo IPv6 address is, like the 6to4 address, a prefix and then some other addresses encoded.  The first eight hex digits are "2001:0000."  The rest is a bit more complex than 6to4 was because working around NAT involves so much jiggery-pokery, but one big part of the address is interesting.  Remember that 6to4 needs the address of a router that can tunnel 6to4, and that you either manually configure it or use that 192.88.99.x anycast address?  Teredo includes the address of the first Teredo router-ish system to talk to right in the Teredo address.  (On a Windows system, it's Microsoft's Teredo server dy default.) So 2001:0000 means it's a Teredo address, and the next XXXX:XXXX -- 4137:9e76 in the case of this Windows system -- is the encoded address of the server to talk to in order to start finding your way through the Teredo process. The address also imbeds the UDP port to use in communicating.
  2. That embedded server address is for what's called the "Teredo Server."  In 6to4, you just needed a "6to4 router," but in Teredo, your packet goes -- I'm simplifying -- to a Microsoft server.  But this Microsoft server's not going to do all of the tunneling; nope, all it does is to see if there's a server over near where you're trying to get to that'll handle all of that for you.  In order to get from point A to point B via Teredo, you need two helpers:  the Teredo Server (run by Microsoft probably, with its IP address packed into your Teredo address), and the "Teredo Relay," which does most of the work.  Teredo relays are typically near a destination, and so some domains might have them, some might not.  You can get to Google over Teredo because Google has a Teredo relay.  In contrast, some other v6 addresses work -- I've pinged them on the v6 Internet and 6to4 -- but I can't get to them from Teredo because apparently those sites don't have a Teredo relay.
  3. The Teredo server -- the machine at Microsoft -- doesn't have to do all that much, but it has to find the Teredo relay for the destination.  It finds that by pinging the destination, which (with a bit if IPv6 routing magic) causes the ping response to go not to the Teredo server but instead to the Teredo relay.  The Teredo relay then introduces itself to the Teredo server, and at that point all of the pieces are in place for Teredo to work.

You needn't worry about how it all works, though -- assuming that the Teredo server automatically finds a Teredo relay for wherever you want to communicate, then you're in business.

Shutting Off/Re-enabling Teredo

Like 6to4, there is a driver for Teredo that you can see if you've got Teredo enabled.  As with 6to4, look in Device Manager, ensure that View / Show hidden devices is enabled, and look under Network Adapters to see the driver "Teredo Tunneling Pseudo-Interface."  Its actual driver name is c:\windows\system32\drivers\tunnel.sys, which is the same driver for the ISATAP and 6to4 pseudo-NICs.  You certainly could kill Teredo by uninstalling the driver, but netsh (pre-Windows 8/2012) or PowerShell (Windows 8/2012) are the easier answers.

From PowerShell,

Set-NetTeredoConfiguration -type disabled

(Undo it with Set-NetTeredoConfiguration -type default.)

Or, if you're working with Windows 7/R2 or earlier, the PoSH cmdlet doesn't exist.  Just type

netsh interface teredo set state disabled

Change that to "Enabled" to turn it back on.

ISATAP:  LAN Manager Networking, 2013-Style

The last of our three built-in IPv6 transition technologies is the Intra-Site Automatic Tunnel Addressing Protocol or ISATAP.  It's different from 6to4 and Teredo in that it doesn't help you get connected to IPv6 addresses from your computer at home or a small business.  Teredo and 6to4, as you've read, stuff v6 packets into v4 packets so they can travel across the Internet.  But now consider this:  what if your intranet is v4?  What if you've got three offices or, heck, more than one subnet and want to get IPv6 packets from one internal subnet to another?  Possible answers might include

  • Come in one Saturday, turn on all the v6 routes on your routers and firewalls, enable IPv6 on all of the Windows boxes, reboot everything and pray that you'll be fully native IPv6 when it's all over.
  • Set up a bunch of Teredo/6to4 servers and relays inside your organization.  (That wouldn't work.)
  • Or ... get started planning being fully IPv6 native inside your intranet, and until you get that done, set up ISATAP.

 I'm going to tell you what ISATAP does, but before I do, I need you to remember something:  this is a transition technology.  That means that it's an inefficient, sometimes goofy (spend some time studying in great detail how a Teredo packet gets from client to server; I recommend smoking some of Seattle's Finest first so it makes more sense) but ultimately "good enough" answer... in the interim.  Okay, here's what ISATAP does to your intranet, whether it's currently two subnets or two hundred subnets:  it makes your entire intranet one subnet.  (That's why I called this section "LAN Manager 2013 Style," as Microsoft's late-80's networking software essentially required that your entire enterprise be one big broadcast domain.  It made for some interesting router configuration, but it could be made to work.  I fondly recall getting a few hooked up, and so ISATAP inspires a bit of nostalgia.)

To understand how ISATAP works, I've got to first talk about something called "link-local" IPv6 addresses.  You've probably seen them on an IPConfig, as they're the addresses that start with FE80.  (Look at the output above from Teredo to see an example.)  Every IPv6 adapter has one of them, and they're the v6 equivalent of those 169.254.x.x IP "APIPA" addresses that you get when your device can't contact a DHCP server.  In v4, APIPA addresses are generally bad news, but in v6, they're used all the time, and unlike IPv4, IPv6 stacks almost always put more than one IPv6 address on a given NIC, including an FE80 address on every NIC I've ever seen.  This FE80 address is, like an APIPA address, only valid inside your subnet, and trying to establish a link between an FE80 address on a NIC in one subnet and an FE80 address in another subnet normally just isn't going to work.  In v6 talk, we don't say "subnet" all that much, using the term "link" instead.  Thus, an address like an FE80 address that can't communicate outside of its subnet -- its link -- is said to be "link-local."

In an ISATAP world, you get, as before, an ISATAP pseudo-NIC.  That NIC needs a link-local address and, as in Teredo and 6to4, that gets built partially from your current IPv4 address.  If that IPv4 address is routable, then ISATAP puts the prefix "fe80:0000:0000:0000:0200:5efe:," and "fe80:0000:0000:0000:0000:5efe:" if it's a private address.  As ISATAP lets us pretend that our intranet is one big subnet and thus any FE80 address can communicate with any other FE80 address, it accomplishes that with systems running as ISATAP routers.  Much simpler than 6to4 and Teredo, mainly because intranet routing structures are much less diverse and demanding than are Internet routing methods.  ISATAP NICs find their ISATAP routers either by being pre-configured with a list of ISATAP routers (about as much fun as installing a custom HOSTS file on every system) or from DNS -- if you're an ISATAP pseudo-router in, then a query to gets you the name of one or more ISATAP routers.

One of the biggest reasons why some organizations are considering IPv6 is to use Microsoft's new DirectAccess VPN alternative, and so if someone asks you how to set up ISATAP on a Windows network, it's a pretty good bet that they're getting ready for DA.  If you want to know more I suggest a look at two nice ISATAP articles by my fellow network geek Deb Shinder. 

ISATAP's not a bad idea transition-wise but do remember that your ISATAP server or servers can become a new bottleneck in your network.  For example, suppose an imaginary organization called had 1000 sites across the world and currently has a terrific IPv4 infrastructure.  Then imagine that two things happen.  First, someone puts up an ISATAP router and ensures that v6 and the ISATAP tunnel driver are running on all corporate systems.  Then, second, imagine that some important network protocol decided that it should prefer IPv6 over v4, and starts deciding to route mail, https or the like over v6.  That one small fact would cause all of Bigfirm's networking to run through that one server acting as an ISATAP server.  That would be, as they say, the beginning of a bad day at the office!

Tapping Out ISATAP:  How to Disable ISATAP

It will not surprise you that again we've got three approaches to killing ISATAP:  device manager, netsh and PowerShell.

Device Manager in "show hidden devices" mode will, under "Network Adapters," show one or more ISATAP adapter drivers unless you've disabled v6 and tunnel protocols altogether, and you can disable that driver if you like.

The netsh command to disable ISATAP is

netsh interface ipv6 isatap set state state=disabled

The PowerShell command to disable it is

set-netisatapconfiguration -state disabled


I must admit that my goal here was to write a nice half-page newsletter article about how to get rid of the pseudo adapters.  But in truth they're all interesting and solve real problems for those of us on the road from pure v4 to at least some v6.  So even if the only reason you're putting in v6 is to do DirectAccess, it's kinda hard not to like the little guys just a bit.  I hope this was a readable introduction to these transition technologies, and that you'll play around with them a bit.

 Acknowledgement:    big thanks to my buddy Ed Horley ( for helping me out with the ISATAP concepts.  Nobody knows IPv6 like that guy!

Upcoming Conferences

  • I will be keynoting the free Tampa IT Pro Camp 2016 on 20 August 2016. Great speakers, sign up now to learn great stuff from some terrific speakers. and tell 'em Mark sent you.
  • I will be presenting at IT/Dev Connections in Vegas the week of 10 October. Http:// for more info.
  • I will also be speaking at the Intersection show also in Vegas the week of 24 October.  Visit for more info. 
  • December TechMentor is in Orlando this year and I'm keynoting about Server 2016. for all the scoop!
I hope to see some of you at one of these shows!

To Subscribe, Read Old Newsletters, Send Me a Comment or Change Your Email Address

To subscribe: (which just means I'll send you about a three-tweet-sized message in plain text via email including a link to my latest newsletter), please visit

To change e-mail or other info, drop me a line (haven't figured out a secure method yet).

To read old newsletters: visit and, if you like 'em, please consider subscribing.

To send me a comment:  I'm at

All contents copyright 2013 Mark Minasi.  I encourage you to quote this material, so long as you include this entire document. Thanks very much for reading, and see you next time.