That's a good question. But before we go there, we have to think about connectivity between the DirectAccess server and the DirectAccess client. The DirectAccess client always communicates with the DirectAccess server using IPv6. There is no IPv4 application traffic moving between the DirectAccess client and DirectAccess server. This means that the client side applications running on the DirectAccess client must be IPv6 aware.
On the server side it doesn't matter - you can run IPv4 only server applications on an IPv6 capable operating system, or you can run IPv6 aware server applications on an IPv4 only operating system. IPv4 isn't an issue when using UAG DirectAccess, because we have the DNS64/NAT64 feature to support IPv4 communications between the DirectAccess server and the destination server on the intranet. There are some exceptions to this, such as not being able to initiate a connection from an IPv4 only server or server application to a DirectAccess client, or when there are “call-backs” required or when there are addresses imbedded in the application protocol, but for the most part the IPv4 only server application will not be a problem.
This means that if your client side applications don't support IPv6, you're going to have to think about a solution. Some things to consider include:
Something that I want to make clear is that if you are running into problem with your client-side applications, we’re here to help you. We’ve helped customers get some applications working with DirectAccess that at first didn’t seem to work. If you want to deploy DirectAccess but are facing a difficult application that doesn’t seem to work with DirectAccess, we want to know about your problem and see if we can help you solve it. Please contact me at firstname.lastname@example.org and I will put you in contact with the team who can help you move forward in helping to solve the application issue.
There is one important issue that you should be aware of, and this relates to those organizations that plan on using Force Tunneling. By default, UAG DirectAccess (as well as the Windows DirectAccess) enables a form of split tunneling, by virtue of the fact that requests for non-intranet resources are sent directly to the Internet server, and not tunneled through the DirectAccess links to the DirectAccess server and out through the corporate firewall or proxy.
Some IT groups are hesitant to support split tunneling based on assumptions made during the 1990s regarding VPN client behavior and the nature and capabilities of malware at that time in history. The networking and threat management landscape is very different now and issues that we're important in a split tunneling configuration 15 years ago are no longer extant. However, not all IT groups have caught up with this or have their hands forced by other decision makers, and therefore may choose to disable the split tunneling configuration by enabling Force Tunneling.
If you do enable Force Tunneling, be aware that all communications will be sent through the DA tunnels. This means you will not have the option to use a Internet facing proxy or relay for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN, PPTP VPN, L2TP/IPsec VPN, or even an SSL VPN.
The decision to use Force Tunneling should be made with the knowledge that all your client side applications must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.
Tom Shinder email@example.com Microsoft ISD 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