The answer is “no” – but its important to understand the function of ISATAP and why or why not you might consider deploying ISATAP in your environment.
Why ISATAP?
ISATAP is the Intra-site Automatic Tunnel Addressing Protocol. The purpose of ISATAP is to allow you to use IPv6 aware applications on a network that hasn’t moved to an IPv6 infrastructure – or what we often call “native IPv6”.
A native IPv6 network has all it’s network infrastructure aware of and configured to support IPv6. This can include routers, switches, DNS, DHCP, network IDS and other network-centric applications. When the entire infrastructure is aware of IPv6 and all the clients and servers on the network work natively with IPv6 and use globally routable IPv6 addresses, then you have what we would call a native IPv6 network.
However, there are very few native IPv6 networks out there in the wild. One of the reasons for this is that not all of our server operating systems or server applications or client-side applications are IPv6 aware or IPv6-capable. Some are, but likely most aren’t.
So how do you enable your IPv6 aware applications to work in an IPv4 network infrastructure? One way to do that is to use something to help you during your transition to IPv6 (the time it takes to complete that transition may be months, years, or decades). That’s the function of ISATAP, to help you deploy IPv6 applications while you’re “in transition” from an IPv4 network to an IPv6 network.
How’s it Work?
The way it works is that the ISATAP adapter on the ISATAP enabled host will encapsulate the IPv6 packets in an IPv4 header to allow routing of those packets through your IPv4 infrastructure. The ISATAP adapter is assigned a “real” IPv6 address (an ISATAP address that is based on a IPv6 prefix obtained from an ISATAP router and a host ID based on the IPv4 address of the ISATAP enabled host), and that address is registered in DNS (if your DNS server is configured to accept dynamic updates).
Applications that are IPv6 capable will preferentially use the ISATAP adapter to communicate with other IPv6 systems on your network. The end result is that you have enabled IPv6 addressing on your clients and servers (that are ISATAP capable) and they can still communicate over your IPv4 routing infrastructure.
Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 are all IPv6 capable operating systems – which means you can assign them a globally routable IPv6 address (sometime referred to as a “native” IPv6 address), or you can assign them ISATAP addresses, which are still valid IPv6 addresses, they’re just not globally routable. However, in order for ISATAP capable hosts to configure their ISATAP IPv6 address, they need to get information from an ISATAP router. When you use the UAG DirectAccess solution, the UAG DirectAccess server or array will act as your ISATAP router.
Do You Need ISATAP?
If you’re using the Windows DirectAccess solution, which is part of the Windows Server 2008 R2 platform, you need to be able to assign IPv6 addresses to all intranet hosts that you want the DirectAccess clients to connect to. If you are using globally routable IPv6 addresses on your network then your work is done – and DirectAccess clients will be able to connect to all hosts with globally routable IPv6 addresses and reach all subnets on your intranet using your IPv6 aware routing infrastructure. However, if you don’t have a native IPv6 network yet, then you will need to find another way to assign IPv6 addresses to the hosts you want the DirectAccess clients to connect to – and that way is to deploy ISATAP.
However, if you are using the UAG DirectAccess solution, you have another option. You can avoid IPv6 addressing on your intranet altogether and take advantage of the UAG DirectAccess server’s NAT64/DNS64 IPv6/IPv4 protocol translator. When you use these two technologies that are available only with the UAG DirectAccess solution, DirectAccess clients can connect to IPv4 resources on your intranet. For more information on how NAT64/DNS64 work, check out the UAG Team Blog over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
However, NAT64/DNS64 is similar to other NAT solutions. Some applications don’t work well with NAT. In addition, the NAT64 solution doesn’t allow for “reverse NAT” from the intranet to the DirectAccess clients. What this means is that if you want to initiate a connection from IPv4 only client or server on the intranet to a DirectAccess client on the Internet, you won’t be able to, because that would be a “reverse NAT” scenario and we don’t support reverse NAT with the current version of NAT64. Because of this, your “manage out” capabilities are limited somewhat.
So to answer the question “do you need ISATAP?”, the answer is “no”. However, your manage out capabilities will be limited.
What is this “Manage Out” of Which You Speak?
“Manage out” is a term we use informally for remote management. There are actually two manage out scenarios:
- An agent on the DirectAccess client makes a call to a management server on the intranet in order to participate in the “management” process. This connection is initiated by the DirectAccess client
- The management server makes a call to the DirectAccess client. This connection is initiated by the management server on the intranet.
When you have an IPv4 only network and none of your intranet resources are IPv6 capable through ISATAP, then only the first “manage out” scenario is available to you. The second one requires that the management server on the intranet be IPv6 capable, using either a native IPv6 address or one assigned by ISATAP.
Why Do You Need IPv6 to “Manage Out”?
The reason why you need IPv6 to manage out is related to the fact that the DirectAccess client only uses IPv6 to connect to the intranet. This connection is initially terminated as an IPv6 IPsec tunnel on the external interface of the UAG DirectAccess server. When the DirectAccess client establishes it’s connection to the UAG DirectAccess server, it also registers it’s own IPv6 address in the corporate DNS. If you want to connect to the DirectAccess client, you have to use its IPv6 address. You can do it directly by connecting to its IPv6 address, or you can connect to the DirectAccess client by the name it registered in DNS.
If an IPv4 server on the intranet tried to connect to the DirectAccess client, it would send a name query to the DNS server and receive only a AAAA record. Since the IPv4 only host doesn’t know what to do with a AAAA record, it will not be able to connect to the IPv6 address of the DirectAccess client.
“So What Should I Do?”
The answer it that it depends on what you need and your constraints.
In general, if you don’t have a native IPv6 network yet, it’s a good idea to deploy ISATAP. That will enable the DirectAccess clients to connect to your ISATAP hosts on the intranet by using IPv6 from end to end – which creates fewer application/NAT related issues. It also allows your ISATAP capable management servers to support the manage out scenario where those servers need to initiate connections to the DirectAccess clients. The only reason why you might not want to deploy ISATAP is if you have investments in network IDS gear that doesn’t understand ISATAP. In addition, when using the UAG DirectAccess server as your ISATAP router, your entire IPv4 infrastructure will be represented as a single IPv6 ISATAP cloud. Depending on your environment, this may or may not be problematic.
In addition, you can reduce the load on the UAG DirectAccess servers by taking advantage of both ISATAP and NAT64/DNS64. The reason for this is that it takes memory and processor cycles to process the NAT64/DNS64 sessions. If you deploy ISATAP, you reduce the number of sessions that require NAT64/DNS64 and potentially increase the number of connections per server in your UAG DirectAccess array.
Of course, the best of all possible worlds is that you have a native IPv6 network, and all your network devices, servers and clients and IPv6 capable. Then you never have to worry about IPv4 only resources – but that’s not likely to happen in the near future.
I hope this clears up the issue for you a bit. if you still have questions, please feel free to write to me at the address you see in my sig line.
HTH,
Tom
Tom Shinder
tomsh@microsoft.com
Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder
