Introduction

DirectAccess client to server connections are established exclusively over IPv6. To allow for this communication to take place over the public IPv4 Internet, DirectAccess uses IPv6 transition protocols – 6to4, Teredo, and IP-HTTPS – to tunnel IPv6 communication over IPv4. 6to4 is supported when the DirectAccess server is edge facing with a public IPv4 address assigned to its external network interface. Two consecutive public IPv4 addresses are required to support Teredo. IP-HTTPS is used in all scenarios, and exclusively when the DirectAccess server is located in a perimeter or DMZ network behind a NAT device.

6to4 and Teredo Advantages

Not all IPv6 transition protocols are created equal. For Windows 7 clients, 6to4 and Teredo provide significant performance advantages when compared to IP-HTTPS (Windows 8.x clients can use null encryption for IP-HTTPS, which eliminates this performance advantage). 6to4 and Teredo offer nearly identical performance, but 6to4 suffers from some unique challenges and should be disabled by default for all DirectAccess deployments.

Note: IP-HTTPS null encryption is disabled for all clients when client-based remote access VPN or one-time password (OTP) authentication is configured on the DirectAccess server, which can impact performance for Windows 8.x clients using IP-HTTPS.

Unreliable Fallback

The 6to4 IPv6 transition protocol is used when a DirectAccess client has a public IPv4 address assigned to its network interface. 6to4 uses IP protocol 41 for transport, and does not work when the client is behind a NAT. If outbound IP protocol 41 is blocked (a common scenario) then the client should fallback to Teredo or IP-HTTPS. In my experience this doesn’t always happen. In fact, the protocol fallback fails with enough regularity that it is the primary reason I recommend disabling it by default.

Active Directory IP Subnet Assignment

6to4 is also problematic when it comes to configuring Active Directory IP subnets for clients in a multisite DirectAccess deployment. 6to4 addresses begin with the 2002::/16 prefix followed by the IPv4 address of the client represented in hexadecimal using the form WWXX:YYZZ::WWXX:YYZZ. For example, if the DirectAccess client’s public IPv4 address is 198.51.100.83, its 6to4 address would be 2002:c633:6453::c633:6453. Since this IPv6 address is created using only the client’s IPv4 address, there is no way to associate the client to a specific entry point. The administrator is left with assigning the 2002::/16 prefix to the most centrally located AD site. This will undoubtedly result in some DirectAccess clients using domain controllers that are not ideal, which will ultimately lead to slow log on times and mapped drive failures.

Summary

In some deployment scenarios, 6to4 and Teredo offer performance advantages when compared to IP-HTTPS. Performance is identical for both 6to4 and Teredo, and considering the challenges that 6to4 poses, it should be disabled by default for DirectAccess deployments. This eliminates the possibility of associated connectivity issues, while still allowing DirectAccess clients to use the Teredo IPv6 transition protocol and not incur any performance penalty. Details about disabling IPv6 transition protocols can be found here.