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!)
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...
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.
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.
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:
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 184.108.40.206, 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, "ipv6.L.google.com." That's Step One before we try to connect the Hong Kong office with the Galax, VA office.)
The problem boils down to this:
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 ipv6.L.google.com. (You will not believe how different Facebook is on IPv6.) In any case, that leads me to the next thought:
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:
Thus, to live in the IPv6 future today, you need
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 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:
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, 220.127.116.11 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 18.104.22.168, no matter what their real IP addresses are. You just tell your 6to4 software to go use the 6to4 relay at 22.214.171.124, 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 126.96.36.199, 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 188.8.131.52" 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 184.108.40.206 from Cox or Charter got me to a well-known source of IPv6-related assistance, "Hurricane Electric" at tunnelbroker.net. 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
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" -- 220.127.116.11, 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 ipv6.L.google.com -n 1 Pinging ipv6.L.google.com [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 http://v6.testmyipv6.com/ 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 : 6to4.ipv6.microsoft.com. 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 18.104.22.168
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:
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 Sixxs.net 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 http://www.sixxs.net/wiki/Routers) 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.
In contrast, in a world without NAT routers, the system would be
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.
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.)
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.
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
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 bigfirm.com, then a query to ISATAP.bigfirm.com 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 bigfirm.com 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 (howfunky.com) for helping me out with the ISATAP concepts. Nobody knows IPv6 like that guy!
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 http://www.minasi.com/nwsreg.htm.
To change e-mail or other info, drop me a line (haven't figured out a secure method yet).
To read old newsletters: visit http://www.minasi.com/nwstoc.htm and, if you like 'em, please consider subscribing.
To send me a comment: I'm at email@example.com.
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.