Notes on setting up ISATAP

IPv6 and IPv4 nodes can’t talk to each other. These are two separate protocols, both of the Internet layer. So when some nodes in a network have moved on to IPv6 we need a transition mechanism to enable the remaining IPv4 nodes to talk to these IPv6 nodes. ISATAP is one such transition mechanism.

ISATAP stands for Intra-Site Automatic Tunnel Address Protocol. From the name itself we get an idea of what it is about:

  1. Intra-Site: It is meant for use within a site. That is in an Intranet, LAN, private network. Not for communication over the public Internet.
  2. Automatic: All configuration is automatic. Once the network is “aware” that ISATAP is in use, all hosts will auto-configure themselves (without the need for DHCP, static IPs, etc).
  3. Tunnel: Communication happens via tunneling of IPv6 packets within IPv4 packets. That is how IPv4 nodes are able to communicate with IPv6 nodes and vice versa. IPv4 packets have a field in their header called “Protocol”. This field tells the receiving end of the type of data in the packet. Usually the data is TCP, UDP, or ICMP (protocol numbers 6, 17, or 1) but other types too are possible (when and IPv4 packet contains an IPv6 packet the Protocol field is set to 41). This is an efficient way of carrying IPv6 packets within IPv4 because the only additional bits to the IPv6 packet are the IPv4 headers (20 bytes). Since the MTU of Ethernet is 1500 bytes a single IPv4 packet can carry up to 1480 bytes of an IPv6 packet.
  4. Address: ISATAP interfaces automatically configure themselves with an IPv6 address. The 64 bit network prefix could be a link-local, unique local, or global prefix. The 64 bit interface address is the IPv4 address (32 bits) prefixed with 0000:5EFE (for a private IPv4 address) or 0200:5E5E (for a public IPv4 address) (32 bits). The IPv4 address is written in the dot-quad notation (a.b.c.d) so it is easy to identify the IPv4 address from an ISATAP IPv6 address.
  5. Protocol: ISATAP is a protocol that defines all the above as well as the communication between the IPv4 and IPv6 nodes. ISATAP is defined in RFC 5214

ISATAP is not meant to be a permanent solution or for organization-wide deployment. It is only a transition strategy, for use in test labs or for parts of the Intranet while IPv6 addressing schemes and routing are being planned.

Windows Vista and above have ISATAP built into the OS. Separate ISATAP interfaces are created for each physical interface connected to a different DNS suffix. On Windows Vista (with Service Packs) and above, the interfaces are left in a “media disconnected” state unless the name isatap.<dnssuffix> can be resolved. If the name can be resolved then ISATAP IPv6 addresses are assigned to that virtual interface. On Windows Vista ISATAP IPv6 addresses are assigned anyways and the state is not “media disconnected”. In both cases the ISATAP IPv6 addresses have a link-local prefix but additional ISATAP addresses can be assigned via SLAAC (more details later). This way two hosts with ISATAP interfaces can talk to each other through IPv6, without any additional configuration, simply by using the link-local ISATAP addresses.

The isatap.<dnssuffix> name is supposed to point to an ISATAP router.

Native IPv6 hosts discover the IPv6 routers on their network via multicast messages (they send a Router Solicitation message to the multicast address fe02:2 which stands for link-local scope, all routers, and is subscribed to by all routers on that link). Routers that receive this message respond with a Router Advertisement message to the host. But… on an IPv4 network there’s no way for hosts to discover an IPv6 router – unless they use IPv4 multicast as some transition technologies tend to do, something that may not always be possible – so what we need is for a way to specify the router address to hosts directly. This is what the isatap.<dnssuffix> address is supposed to be. It is an ISATAP router that will help hosts with auto-configuring as well as routing to other IPv6 networks. Hosts contact this router by sending Router Solicitation messages to this unicast address, and the router will respond.

The isatap.<dnssuffix> name is only one way of specifying the ISATAP router address. (The isatap.<dnssuffix> name can be resolved using DNS, the hosts file, or NetBIOS). Other ways are to specify the router address are directly via PowerShell, netsh, or GPOs.

Turning on ISATAP is a very easy process. Consider the network below:

IPv6-ISATAP

WIN-DC01, WIN-DC02, and WIN-GW01 are IPv6 enabled machines Windows Server machines. They have both IPv4 and IPv6 addresses, but the IPv4 addresses don’t matter as I want clients to connect to these servers via IPv6. WIN-CLIENT03 and WIN-CLIENT12 are Windows 8 and Windows 7 machines. They are in a separate IPv4 only network, connecting to the main network through a router. The fact that they are in a separate network doesn’t matter. I just put them in a separate network to illustrate something later.

I want WIN-CLIENT03 and WIN-CLIENT12 to connect to WIN-DC01 and WIN-DC02 through IPv6. Currently they can connect via IPv4 but soon the servers will be IPv6 only and I want to ensure everything works well over IPv6. As this is a temporary situation I will use ISATAP to ensure the clients can connect to the servers until the permanent solution is ready. Here’s what I have to do:

  1. Decide a machine that will act as the ISATAP router (any Windows Server would do; you can use Linux too). The ISATAP router will have a virtual ISATAP interface created on it. If the idea is to have ISATAP hosts connect to an IPv6 network then the router must have an IPv6 interface too on which it will send and receive IPv6 packets. On the other hand if hosts won’t be connecting to any IPv6 network and all you need is automatic configuring then the IPv6 interface is not needed.

    I chose WIN-GW01 as my ISATAP router. Note that it’s in a separate network from the clients but that doesn’t matter.

  2. Name this machine isatap.<dnssuffix> (or assign it as a CNAME via DNS or as as additional name via the hosts file). Alternatively set this machine as an ISATAP router for itself – via PowerShell, netsh, or GPOs.

    I used netsh:

    This enables ISATAP on WIN-GW01. It is still not ready as an ISATAP router, that will be done in the next step.

  3. To configure WIN-GW01 as an ISATAP router I have to enable advertising on the ISATAP virtual interface. Optionally, if I want the clients connecting to it to have a global or unique local prefix, I can configure one.

    fdcc:7c4e:3651::/48 is a unique local prefix. 2002 is a subnet I assigned for ISATAP hosts.

    WIN-GW01 is now ready as an ISATAP router. That’s it!

    Here’s the output of ifconfig for the ISATAP interface:

    Notice it has a link-local address – which would be the only address if I hadn’t specified a unique-local prefix – and also a unique-local address. Both have the IPv4 address embedded in it.

  4. Optionally: Since WIN-GW01 has an IPv6 and ISATAP interface, I can enable routing between them and also advertise WIN-GW01 as the default router for the ISATAP hosts connecting to this.

    On WIN-GW01, I do the following:

    The first command enables routing on the 10.50.0.0/24 interface. The second command enables routing on the ISATAP interface. Lastly, I advertise to hosts on the ISATAP network that WIN-GW01 is the default router:

  5. All that’s left to be done now is to enable ISATAP on the clients. One can use DNS, GPOs, PowerShell, or netsh. I went with netsh. The command is same as that on the ISATAP router:

    Here’s the output of ifconfig for the ISATAP interface on one of the clients:

    It has picked up a unique-local ISATAP address, auto-configured a link-local ISATAP address, and is correctly pointing to the ISATAP interface of WIN-GW01 as the default router. The unique-local address would have also registered with DNS (this is why I created unique-local addresses).

  6. And that’s it. Let’s test IPv6 connectivity via ping:

    Here’s the IPv6 routing table on the client:

The neat thing about such tunneling mechanisms is that the underlying IPv4 link is treated as a local link. Even though the clients and servers are in different networks, that does not matter for IPv6. As far as IPv6 is concerned they are on the same link and it is up to the underlying IPv4 protocols to route packets between the IPv4 networks.

Also notice from the routing table above how the fdcc:7c4e:3651:2002::/64 network has an on-link route rather than via the ISATAP router. This is because communication between ISATAP hosts happen directly, without router involvement. The hosts know each others IPv4 address from destination IPv6 address, so the ISATAP interfaces talk to each other over IPv4. The IPv4 address is still required because unlike native IPv6 which discovers the MAC address of an IPv6 address through Neighbour Discovery, ISATAP has no such luxury. It must discover the MAC address through other means – i.e. use the IPv4 address and leave it to the IPv4 protocols to do the routing.

And that’s all! Pretty straightforward stuff.

Update: To disable ISATAP if you set the router via netsh or PowerShell do either of the following:

-or