DirectAccess IPv6 Transition Protocols Explained

Introduction

From a client perspective, DirectAccess is an IPv6-only solution. The DirectAccess client communicates with the DirectAccess server exclusively using IPv6. However, IPv6 is not widely deployed, so the most common scenario will find your DirectAccess clients and servers on the IPv4 Internet.

To facilitate DirectAccess client to server communication with IPv6 when the client is on the IPv4 Internet, IPv6 transition protocols are employed. These protocols effectively tunnel IPv6 packets in IPv4 packets. DirectAccess makes use of three IPv6 transition protocols for client to server connections – 6to4, Teredo, and IP-HTTPS.

DirectAccess Transition Protocols

6to4 – The 6to4 IPv6 transition protocol works by encapsulating IPv6 packets in IPv4 packets using IP protocol 41. 6to4 does not work when the client or the server is behind a NAT, so this IPv6 transition protocol is only used when the client and server are assigned public IPv4 addresses. DirectAccess clients with public IPv4 addresses aren’t common though, and there are some challenges with the stability of 6to4. From experience I can tell you that 6to4 often fails when clients use a cellular Wi-Fi hotspot, for example. For this reason it is generally recommended that you proactively disable this transition protocol to avoid potential issues in the future.

TeredoTeredo is an IPv6 transition protocol that is designed to work when a DirectAccess client (but not the DirectAccess server) is behind a NAT. It works by encapsulating IPv6 packets in IPv4 packets using UDP on port 3544. Teredo will be used any time the DirectAccess client has a private IPv4 address, or when the client has a public IPv4 address and the 6to4 protocol is unavailable (e.g. 6to4 is disabled, or outbound access to IP protocol 41 is restricted by firewall policy). To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. In addition, Teredo uses ICMP for NAT detection (e.g. cone, restricted, symmetric), so ICMPv4 echo requests must be allowed inbound to any host with which the DirectAccess client communicates.

IP-HTTPSIP-HTTPS is an IPv6 transition protocol that works by encapsulating IPv6 packets in IPv4 packets using HTTP with SSL/TLS. It is the IPv6 transition protocol of last resort, and will be used any time that 6to4 or Teredo aren’t available. The advantage to using IP-HTTPS is ubiquitous firewall access. Any network with access to the public Internet should, at a minimum, allow outbound HTTP and HTTPS. In some deployment scenarios, IP-HTTPS can be disadvantageous. For example, when Windows 7 DirectAccess clients leverage this IPv6 transition protocol, IPsec-encrypted traffic is encrypted again using SSL/TLS. This double encryption results in high processing overhead and often translates to poor performance and limited scalability. Windows 8 and later clients do not suffer this limitation, as they support null encryption which eliminates the negative effects imposed by double encryption. For the best results using IP-HTTPS, use an application delivery controller to offload SSL, or deploy Windows 8 or later clients. In any case, do not collocate the client-based VPN role on the DirectAccess server, as doing so will remove support for null encryption completely and force even Windows 8 and later clients to perform double encryption for IP-HTTPS traffic.

DirectAccess Server Configuration

To support the 6to4 and Teredo IPv6 transition protocols, the DirectAccess server must be configured with two network interfaces; one internal and one external. The DirectAccess server must have public IPv4 addresses assigned to its external network interface. For Teredo in particular, the DirectAccess server requires two consecutive public IPv4 addresses. Beginning with Windows Server 2012, DirectAccess provides support for DMZ/perimeter network deployment behind a NAT device using RFC1918 private IPv4 addresses with either one or two network interfaces. In this deployment scenario, the DirectAccess server only supports the use of the IP-HTTPS IPv6 transition protocol. 6to4 and Teredo are not available when the DirectAccess server is located behind a NAT device and these IPv6 transition protocols should be disabled on all DirectAccess clients.

Leave a comment

9 Comments

  1. Ashish Vaidya

     /  December 8, 2015

    Hello Richard,

    I have a question for you which is will direct access work if the client get a real IPV6 address from the ISP? If so do can you also let me know or suggest me changes that we need to do in the DA configuration to make it work?

    Reply
    • Yes, it will. Even if the client has a globally routable unicast IPv6 address, unless the DirectAccess server is also on the public IPv6 internet, an IPv6 transition protocol is still required. No changes should be required on either the server or client for this to work. The point of this article is to disable any IPv6 transition protocols that aren’t going to be used. Also, I recommend disabling 6to4 because it is potentially problematic (based on my experience) and it provides no advantage over Teredo.

      Reply
  2. I have two questions as well. Kindly requesting your answer.

    1. If there’s a Windows Client server application works with Socket programming support only IPV4 (e.g: sockaddr structure), does that have to be re-written for supporting DirectAccess?.
    2. If so, Are there any ways of easy migration of the app to a IPV6 supporting platform?.

    Reply
    • For the most part, yes. If an application simply uses standard name resolution APIs to locate resources, you should be fine. However, any application that makes calls directly to IPv4 addresses will not work. There are some cases where a workaround might be available, but they aren’t very common.

      Reply
  1. Enable Teredo Support after DirectAccess Has Been Configured | Richard Hicks' DirectAccess Blog
  2. Weekly Link List - Savage Nomads
  3. DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101 | Richard Hicks' DirectAccess Blog
  4. DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler | Richard Hicks' DirectAccess Blog
  5. DirectAccess with Teredo Protocol requires ICMP traffic to be allowed - Xenit Technical

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: