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:
- 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.
- 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).
- 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.
- 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.
- 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.
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.
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:
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:
- 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.
- Name this machine
isatap.<dnssuffix>(or assign it as a CNAME via DNS or as as additional name via the
hostsfile). Alternatively set this machine as an ISATAP router for itself – via PowerShell,
netsh, or GPOs.
netsh:1C:\>netsh interface isatap set router 10.50.0.254
This enables ISATAP on WIN-GW01. It is still not ready as an ISATAP router, that will be done in the next step.
- 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.
12netsh interface ipv6 set interface isatap.rakhesh.local advertise=enablednetsh interface ipv6 add route fdcc:7c4e:3651:2002::/64 isatap.rakhesh.local publish=yes
fdcc:7c4e:3651::/48is a unique local prefix.
2002is a subnet I assigned for ISATAP hosts.
WIN-GW01 is now ready as an ISATAP router. That’s it!
Here’s the output of
ifconfigfor the ISATAP interface:12345678910111213Tunnel adapter isatap.rakhesh.local:Connection-specific DNS Suffix . : rakhesh.localDescription . . . . . . . . . . . : Microsoft ISATAP Adapter #5Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0DHCP Enabled. . . . . . . . . . . : NoAutoconfiguration Enabled . . . . : YesIPv6 Address. . . . . . . . . . . : fdcc:7c4e:3651:2002:0:5efe:10.50.0.254(Peferred)Link-local IPv6 Address . . . . . : fe80::5efe:10.50.0.254%18(Preferred)Default Gateway . . . . . . . . . :DNS Servers . . . . . . . . . . . : 10.50.0.2010.50.0.21NetBIOS over Tcpip. . . . . . . . : Disabled
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.
- 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:12netsh interface ipv6 set interface LAN-10.50.0 forwarding=enablednetsh interface ipv6 set interface isatap.rakhesh.local forwarding=enabled
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:1netsh interface ipv6 set interface isatap.rakhesh.local advertisedefaultroute=enabled
- 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:1C:\>netsh interface isatap set router 10.50.0.254
Here’s the output of
ifconfigfor the ISATAP interface on one of the clients:123456Tunnel adapter isatap.dyn.rakhesh.local:Connection-specific DNS Suffix . : dyn.rakhesh.localIPv6 Address. . . . . . . . . . . : fdcc:7c4e:3651:2002:0:5efe:10.50.1.202Link-local IPv6 Address . . . . . : fe80::5efe:10.50.1.202%5Default Gateway . . . . . . . . . : fe80::5efe:10.50.0.254%5
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).
- And that’s it. Let’s test IPv6 connectivity via
ping:12345678910111213C:\>ping -6 win-dc01Pinging win-dc01.rakhesh.local [fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b] with 32 bytes of data:Reply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time=2msReply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1msReply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1msReply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1msPing statistics for fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 2ms, Average = 0ms
Here’s the IPv6 routing table on the client:12345678910111213141516171819202122232425262728C:\>route print -6===========================================================================Interface List3...00 0c 29 a9 17 63 ......Intel(R) 82574L Gigabit Network Connection1...........................Software Loopback Interface 15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter===========================================================================IPv6 Route Table===========================================================================Active Routes:If Metric Network Destination Gateway5 266 ::/0 fe80::5efe:10.50.0.2541 306 ::1/128 On-link5 266 fdcc:7c4e:3651:1::/64 fe80::5efe:10.50.0.2545 266 fdcc:7c4e:3651:2002::/64 On-link5 266 fdcc:7c4e:3651:2002:0:5efe:10.50.1.209/128On-link3 266 fe80::/64 On-link5 266 fe80::5efe:10.50.1.209/128On-link3 266 fe80::5433:29e5:3d43:3e7c/128On-link1 306 ff00::/8 On-link3 266 ff00::/8 On-link===========================================================================Persistent Routes:None
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:
Set-NetIsatapConfiguration -Router ''
netsh interface isatap set router ''