The Private Cloud Man

Private Cloud Technologies, Architecture and more!

Clearing the Air on ISATAP

Clearing the Air on ISATAP

  • Comments 9
  • Likes

imageFor companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx

However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.

However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.

Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx 

In that article, I said:

“In general, ISATAP is a good thing…”

Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:

Appropriate Uses for ISATAP on Intranets
ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”

Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.

Let me explain.

What Does ISATAP Actually Allow You To Do?

To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.

ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.

The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.

When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.

In Figure 1, you can see three networks:

  • The DirectAccess clients network (which is an IPv6 only network),
  • an IPv4 only network, and
  • an IPv6 only network.

When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.

The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.

 

image

Figure 1

As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.

ISATAP and the Special Case of DirectAccess

However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.

The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).

Conclusion

In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog :
http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter:
http://twitter.com/tshinder
Facebook:
http://www.facebook.com/tshinder

Visit the TechNet forums to discuss all your UAG DirectAccess issues
http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads

Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx

Comments
  • Well Tom, this was one of topics i've covered in the "still unanswered" notes i send to you...

    "Firstly, after reading your “Don’t Fear the Reaper” blog post, I’ve to agree your words; It’s indeed very easy to build an ISATAP enabled IPv6 infrastructure in a demo lab or even a small company network – thanks to the amazing wizards of Windows DA or UAG.

    But once the networks are getting a little more complexity, the needed planning would become comprehensive too. Even worse, if not planed carefully you might even get into serious trouble - when trying those things in a production environment. Well, at least I’ve heard about some really “unlucky” pilot deployments which were causing a lot of troubles in the production environments. The Joe Firewall Admin tent to underestimate the DA wizards and resulting GPO changes…

    Just clicking Next, Next, Next, Finish could be a beast if not planed and also done carefully. In addition to the GPO settings of the DA wizards, a lot of things should be considered. Hence, having one big fat ISATAP cloud across a multisite active directory enabled network isn’t always a good idea, tbh^^ Maybe you should warn the people a little in the future?"

    BTW: So thanks for speaking out the problems involved and also feel free to delete this post^^

    -Kai

  • Hi Kai,

    I would never delete your posts! :)

    You are correct regarding the complexities that are hidden behind the wizards, and the use of ISATAP. That was my motivation for writing this article - to show that while ISATAP has a special purpose for a DirectAccess configuration, in general you want to consider ISATAP a *temporary* solution that enables you to transition to a full, native IPv6 network.

    Thanks!

    Tom

  • Any idea why I'm getting the following message when trying to activate DirectAccess (which was working fine and is now broken)....  "The ISATAP router cvannot be deployed. The ISATAP interface with the IPv6 address generated from the internal facing IPv4 address selected in the wizard, does not exist."  ISATAP DNS record exists - I've checked that......

    Thanks, Simon

  • Hi Simon,

    Not sure what's up with that. Did you change the IP addresses on the DA server?

    Thanks!

    Tom

  • From someone who's network has been a little toasted by ISATAP, I think it's very benefitial to explain the consequences of enabling it in DNS, and that is still lacking in this article.

    ISATAP enables a tunneling adaptor on each of your 2K8 Servers and Windows 7/Vista Workstations.  This tunneling adaptor will be used for ALL client to client communications on these ISATAP supported clients.

    This seems harmless enough, but it is effectively like having every machine on your network connecting via a single VPN server.  The throughput of your network is now dictated by the network and performance characteristics of your UAG server, whilst also adding overhead to each and every packet.

    If you have a very small network all located on a good LAN, then this isn't going to be that big a deal.  If you have a few hundred hosts and servers, all using this ISATAP tunnel, then you'll run into some pretty serious network degredation.  

    ISATAP = Running your entire network through a HUB.

    Use with care!  Those with networks that would benefit from the manage out functionality are probably of the size where you should not consider enabling this feature.

    Jason

  • Hi Jason,

    That's not true. When the ISATAP enabled hosts communicate with each other over ISATAP, they communicate with each other directly, unless the communciations need to cross over to a native IPv6 network, in which case the communication will go through an ISATAP router. But for computer to computer communication over ISATAP, they do *not* need to go through the ISATAP router. They only receive addressing information from the ISATAP router in this scenario.

    HTH,

    Tom

  • I know I'm late to this party, but it strikes me that Jason may be experiencing the same thing we ran into with a multi-site network, and the UAG ISATAP router:

    social.technet.microsoft.com/.../8fe62be2-720c-472d-b40f-357e64bfeed0

    Turns out, it was a problem with the UAG configuration of the ISATAP router, not a fault with ISATAP itself. The symptoms of it however were exactly as Jason describes - all communication between two PCs sitting on the desk next to each other were being routed over the WAN and through the central UAG server. Painful when trying to push a 2Gb WIM image down and back via a 1Mb DSL link :).

    I believe the issue that causes the configuration problem has been resolved in UAG SP1.

    Cheers,

    Matt Russell

  • PS - I've just realised Tom that you were one of the MSFT people to help me out with that original thread two years ago. Small world.  The help that yourself and Yaniv gave was instrumental in allowing us to get both our Win7 deployment and UAG/DA setup in and working. Yaniv gave a lot of his time to delve into the problem, which I'm still very grateful for.

    Again, thanks for your help, and for such an informative blog.

    Cheers,

    Matt Russell

  • ISATAP for production is bad. M'kay?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment