While DirectAccess seems like an attractive proposition to most network admins, there is often a concern about IPv6. These admins have read about the Windows Server version of DirectAccess (DA) and they’re concerned that they’ll need to upgrade their servers and configure their routers and other network gear to support IPv6. In other cases, network security personnel have issued edicts stating that “no IPv6 will traverse our networks”.

Will DirectAccess work in a no IPv6 environment? What do I mean by a no IPv6 network? I mean that you either have no computers or applications that are IPv6 aware, or you have machines and applications that are IPv6 aware, but do not take advantage of IPv6 transition technologies (such as ISATAP, which is typically used on a network that has IPv6 capable hosts, but the entire network isn’t IPv6 capable yet).

-----------------------------------------------------------------------------------------
Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag
-----------------------------------------------------------------------------------------

DirectAccess will work in an IPv4 only network, but only if you deploy DirectAccess with Forefront UAG. The reason why you can have a no IPv6 (or a IPv4 only network, it’s the same thing) network using UAG DA servers is that UAG includes two key pieces of functionality not included with the Windows only DA solution that allow the DA client to connect to a IPv4 only network:

  • NAT64 – this feature allows the IPv6 communications from the DA client to the DA server to be NATed from an IPv6 address (the DA client) to a IPv4 address (the destination server)
  • DNS64 – this feature allows the DA client to believe it’s connecting to an IPv6 host when connecting to an IPv4 server on the IPv4 only network. DNS64 on the UAG DA server will send a DNS query for the name requested by the DA client, and then replace an IPv6 address for the IPv4 address returned by the DNS query and forward the IPv6 address to the DA client. The DA server stores this IPv4 to IPv6 address mapping. When the DA client tries to connect to the IPv4 only resource, it uses this mapped IPv6 address to connect. The DA server then forwards the connection to the IPv4 address associated with the IPv6 using NAT64

However, like any other NAT based solution, there are going to be some limitations. That’s just the nature of NAT. When using NAT64 to enable your DA clients to connect to your IPv4 only network, there are several issues of which you need to be aware:

  • Any application protocol that imbeds IP addresses in the protocol header may not work, since the NAT64 feature doesn’t include NAT editors for any specific application protocol. This is especially problematic when there are IPv4 addresses imbedded in the application layer header
  • You cannot fully “manage out” DA clients when NAT64 is required, because our implementation of NAT64 doesn’t enable “reverse NAT” mappings.

Note that I say that you cannot “fully” manage out DA clients. The reason why I say this is in the vast majority of management scenarios, there is an agent on the client that calls the management server and uses a “pull” method to receive updates, configuration information and other settings that are required to make the DA client a fully managed client. This works fine with NAT64. However, if you want to initiate the connection from a management computer located on the corpnet, that won’t work, because that would require a reverse NAT mapping and we don’t have that capability at this time.

There are also some corner-case issues that might take place on an IPv4 only network. For example, if the DA client is able to resolve the name of the IP-HTTPS when it is on the corpnet, and is able to reach the IP-HTTPS listener, the IP-HTTPS adapter on the DA client will stay up. This can have some unintended side effects that I’ll share with you in a blog post in the near future.

For more information on NAT64/DNS64, check out:

http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx