If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
If you would like to read the next part in this article series please go to Recognizing IPv6 Address Types on Windows Systems in Support of DirectAccess – Part 1: Overview of IPv6 and DirectAccess.
ISATAP
The Intra Site Automatic Tunnel Addressing Protocol (ISATAP) allows computers that are configured to support ISATAP adapters to obtain an IPv6 address from the ISATAP server. Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 all have out of the box, native support for ISATAP.
The ISATAP client contacts the ISATAP server using a DNS query for isatap.company.com. In a Windows DNS server environment, you may need to unblock queries for ISATAP, as they are blocked by default in Windows Server 2008 and Windows Server 2008 R2 (and later versions of Windows 2003). After resolving the name of the ISATAP server, the ISATAP server is able to provide the client an IPv6 prefix (similar to a network ID in IPv4), and the host ID is based on the IPv4 address of the client. This combination of prefix and host ID (the prefix is always 64 bits and the host ID is always 64 bits)creates a native IPv6 address that can be used by IPv6 clients and servers to communicate with client and server applications that are written to support IPv6.
This ISATAP address is assigned to the ISATAP tunnel adapter on the system. When the ISATAP host want to connect to another ISATAP host, the communications are routed based on the IPv4 addresses of the source and destination, using the IPv4 header that encapsulates the communication. When the IPv4 packet reaches its destination, the IPv4 header is removed, and the IPv6 communication is exposed.
What’s interesting is that if you have a single ISATAP server on your network, it will seem from an IPv6 point of view that you have a single hop network, in spite of the fact that the IPv4 header that encapsulates that communication might see 5 hops.
ISATAP assigns “real” IPv6 addresses that can be used by IPv6 applications right now. Even if you do not have a “native” IPv6 infrastructure (with IPv6 routers, DNS, DHCP, and client/server applications), you can still roll out IPv6 applications on your network today because ISATAP makes this possible for you. In a DirectAccess deployment, the DirectAccess server can and often does act as your ISATAP router. ISATAP makes it easy to deploy DirectAccess because it removes much of the complexity inherent in a native IPv6 infrastructure and allows you to use DirectAccess in an environment where you have IPv6 aware operating systems, network stacks, and client/server applications.
Figure 1
6to4
There is a lot of talk about running out of IPv4 addresses. I read recently that predictions for us to run out of these address will happen in the next couple of years. Then measures will need to be taken to reclaim the multitude of unused addresses and redistribute addresses that are currently in use. The fact is that it is not only computers that need IP addresses anymore. Phones, PDAs, MP3 players, and any manner of device can be network enabled – this is causing an explosion of devices that need to be connected to the Internet. While NAT has been a solution to the address problem up to now, NAT introduces problems that make it difficult to work with for an increasing number of applications. IPv6 will provide about 3.4×10^38 addresses, which should be more than enough until they come out with IPv7.
However, until the Internet routing infrastructure updates to IPv6, we are all still working with an IPv4 Internet. In order for the DirectAccess client to work over an IPv4 Internet, we’re going to need to use some method of encapsulating the IPv6 packets in an IPv4 header so that it can be routed over the Internet.
One of those technologies is 6to4. A 6to4 client is one that is assigned a valid public Internet address. The Teredo client is configured to use a specific Teredo server. By default, the 6to4 client will use a pre-configured Teredo server used by Microsoft. However, in a DirectAccess environment, your Teredo clients will be configured to use the DirectAccess server as their Teredo server.
When the 6to4 client connects to the 6to4 server, the 6to4 server will assign a 64 bit prefix to the Teredo client. The 6to4 client will assign itself a host ID based on its own public IP address. This combination of prefix and host ID creates the IPv6 address that will be encapsulated in the IPv4 header so that it can be routed over the Internet.
Figure 2
When the encapsulated IPv6 packet reaches the 6to4 server (which will in most cases be your DirectAccess server) the IPv6 header is removed and it is then routed to the IPv6 destination over your network using IPv6.
Remember, 6to4 is only used when your client computer has a public IP address. This doesn’t happen very often, but you’ll notice that some hotels provide you the option of obtaining a public IP address when you sign up for their service. They do this primarily to support network layer VPN protocols that doesn’t work well across NAT devices, such as IPsec tunnel mode (when NAT-T isn’t available) and L2TP/IPsec (for the same reason, since NAT-T is required here too). In most cases, you’ll have a NATed, private address. In that case, you’ll use Teredo addressing.
Teredo
Teredo is another method that is used to encapsulate IPv6 packets in IPv4 headers so that they can travel over the IPv4 Internet. However, unlike 6to4, Teredo is only used when you are behind a NAT device. This can be a simple NAT router, or a firewall that uses NAT between the client and the Internet.
When you deploy a DirectAccess server, you will notice that you will need to assign two public addresses to the external interface of the DirectAccess server. The reason for this is to support Teredo clients. Teredo client use these two addresses to determine what type of NAT device they are behind. The Teredo protocol itself is fairly complex and we will save the deep dive for a later article. The key point you need to take away here is that Teredo is used encapsulate IPv6 packets in a IPv4 header so that they can be sent over an IPv4 Internet when the client is located behind a NAT device.
The Teredo address is a combination of a 64 bit prefix that is a combination of a Teredo pre-assigned value and the public IPv4 address of the Teredo server. Windows IPv6 capable clients will automatically configure themselves to use a Microsoft operated Teredo server, but when you deploy DirectAccess, you will configure the clients to use your DirectAccess server as their Teredo server. The Teredo client’s 64 bit host ID is derived from the UDP port used by the NAT device (and this is encoded to protect the client’s “privacy”) and an encoded value for the publicIPv4 address of the NAT device (for the same reason).
Figure 3
IP-HTTPS
There are going to be times when you do not have a public IP address, and you are behind a firewall or Web proxy on a private address IPv4 network that only allows outbound HTTP/HTTPS. That’s a tough place to be, because you are limited only to servers that allow access to the HTTP protocol. However, in order to realize the goal of DirectAccess, you should be able to connect to the corpnet regardless of your location, and that means you should be able to connect when your only option is HTTP.
DirectAccess clients support the IP-HTTPS protocol (IP over HTTPS). IP-HTTPS allows DirectAccess clients to connect to the DirectAccess server using HTTPS. This provides connectivity through firewalls that only allow HTTPS, and even through Web proxy devices. However, the Web proxy devices must not require authentication, because there is no provision in the DirectAccess client that allows the client to forward credentials to an authenticating Web proxy server.
IP-HTTPS is the worst case scenario for the DirectAccess client. There are two primary reasons for this:
- The client needs to use processor cycles to encrypt the HTTPS communications in an SSL tunnel. This encryption is on top of the IPsec encryption that automatically used to protect the DirectAccess communications between the DirectAccess client and server. This double encryption duty is not required when using Teredo from behind a NAT device.
- There is significant protocol overhead. The IPv6 packet is encapsulated in an IPv4, which is then encapsulated in an HTTP application layer protocol header, which is then encrypted with SSL
Your users will not be happy campers when using IP-HTTPS, at least they won’t be as happy as your Teredo and 6to4 users. However, they will probably be more happy than your L2TP/IPsec VPN users, because your IP-HTTPS users don’t have to manually establish their connections, and their overall end user experience is far superior than network layer VPN users. However, if they have to a lot of large file copies, they might want to move to a hotel that allows 6to4 or Teredo.
The IP-HTTPS 64 bit IPv6 address prefix is derived from a combination of a pre-define value, the public address of the DirectAccess server, and a subnet ID. The 64 bit host ID is a randomly assigned value created by the DirectAccess server. The combination of the prefix and host ID constitutes the complex IPv6 address.
Figure 4
Remember, IP-HTTPS is only used when the DirectAccess client is behind a firewall or Web proxy that won’t allow outbound access for Teredo connections. Teredo needs access to outbound UDP 3544. Many administrators might think that IP-HTTPS should be the preferred protocol since they are familiar with other HTTPS encapsulated protocols, such as RPC/HTTP, but the fact is that you want to avoid IP-HTTPS if you can.
Summary
In this article we discussed DirectAccess and IPv6, and how DirectAccess clients can take advantage of IPv6 transition technologies so that IPv6 client and server applications can communicate over an IPv4 Internet. The IPv6 transition technologies discussed included ISATAP, 6to4, Teredo and IP-HTTPS. ISATAP is used to assign IPv6 addresses and route packets over an IPv4 intranet, 6to4 is used to assign an IPv6 address to a host with a public IPv4 address and tunnel it over an IPv4 Internet, Teredo is used to assign an IPv6 address to a host behind a NAT devices and tunnel it over an IPv4 Internet, and IP-HTTPS is used to assign an IPv6 address to a host located behind a firewall or Web proxy that only allows outbound HTTP/HTTPS and tunnel it over an IPv6 Internet.
IPv6 transition technologies are key to a working DirectAccess solution. While a deep understanding of IPv6 would be nice, the fact is that you do not need a deep understanding of IPv6 to get a working DirectAccess solution going today. Since almost all networks are IPv4 at this time, if you get a working understanding of IPv6 address types and transition technologies, you’ll be in good shape to get your DirectAccess project going now. Your users will love you for it and your boss will give you a pat on the back and maybe even a raise!
I am going to continue next time by talking more about the different types of IPv6 addresses and give you some hints and tips on how to easily recognize them. I’ll also talk about how these addresses are created, which will help take some of the mystery out of them. I think this is important since one of the reasons why people shy away from IPv6 is that the addresses look scary! In the next article, I will do what I can to take the fear away from these initially scary addresses, and hopefully, show you that they actually fun.. See you then! –Deb.
If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
If you would like to read the next part in this article series please go to Recognizing IPv6 Address Types on Windows Systems in Support of DirectAccess – Part 1: Overview of IPv6 and DirectAccess.
