In the previous articles in this series on IPv6 tunneling, we have mostly considered tunneling mechanisms that are used to connect two isolated IPv6 domains together over an IPv4 infrastructure; those two IPv6 domains were usually in different sites. However, in this article, we will be considering a tunneling mechanism that has application within a particular site. This tunneling mechanism is known as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

CCNA Training – Resources (Intense)

ISATAP allows dual-stack nodes connected within an IPv4 site to communicate with each other. ISATAP like 6to4 and 6rd treats the underlying IPv4 network as an NBMA link layer for carrying IPv6 traffic. The difference is that ISATAP is used within a site and not between sites. In the diagram below, notice that I have used “IPv4 Intranet” and not “IPv4 Internet”.

Operation of ISATAP

When an ISATAP host comes up, it attempts to find an ISATAP router to provide it with prefixes with which to configure its address. The ISATAP host may be manually configured with the address of this ISATAP router or it could request for this information via some other means like DNS. It is recommended that the DNS FQDN of the ISATAP router be used in the following convention: isatap.domainname e.g. isatap.example.com.

When the ISATAP host receives the IP address of the ISATAP router, it adds this to a Potential Router List and sends a router solicitation message to that ISATAP router. The ISATAP router will then send back a solicited router advertisement message to the soliciting ISATAP node. This router advertisement is not different from what we are already familiar with – among other things, it contains the IPv6 prefix to be used for address autoconfiguration.

When the ISATAP host receives this prefix(es), it uses it to generate ISATAP addresses which are generated from the received IPv6 prefix and the ISATAP interface identifier. The ISATAP interface is made up of “0000:5efe” followed by the 32 bits IPv4 address of the ISATAP interface. The part before the IPv4 address could also be “0200:5efe” if the IPv4 address is a public IPv4 address. According to RFC 5214, an ISATAP interface ID has the following format:

When the IPv4 address is globally unique, then the “u” bit is set to 1. This accounts for the change between the “0000:5efe” and the “0200:5efe” in the ISATAP interface identifier. You can refer to this article for more information on the “u” and “g” bit.

At this point, the ISATAP host can communicate using IPv6. Note that ISATAP does not have a reserved IPv6 prefix; therefore, the ISATAP router can send any unicast IPv6 /64 prefix including global unicast prefixes. Also keep in mind that an ISATAP host can communicate with the native IPv6 interface through the ISATAP router.

Configuration of ISATAP

Let’s look at a configuration exercise using the network scenario below:

I have set up the IPv4-only router between the ISATAP host and ISATAP router to serve as both a DHCP and DNS server for the ISATAP host. The configuration on the IPv4 router is as shown below:

ip domain name example.com
ip host ISATAP.example.com 192.168.66.2
!
ip dhcp pool DHCP
   network 192.168.56.0 255.255.255.0
   domain-name example.com
   default-router 192.168.56.10
   dns-server 192.168.56.10
!
interface FastEthernet0/1
 ip address 192.168.66.1 255.255.255.0
!
ip dns server

The configuration on the ISATAP router is as follows:

interface FastEthernet0/0
 ip address 192.168.66.2 255.255.255.0
!
interface Tunnel2
 no ip address
 ipv6 address 2001:DB8:1000::1/64
 no ipv6 nd ra suppress
 tunnel source FastEthernet0/0
 tunnel mode ipv6ip isatap
!
ip route 0.0.0.0 0.0.0.0 192.168.66.1

Hint: You have to add the no ipv6 nd ra suppress command on the tunnel interface because by default, router advertisement messages are not sent over tunnel interfaces.

Therefore, when the host comes online, it gets its configuration settings from the DHCP server as shown below:

Knowing its DNS server to be 192.168.56.10 and its domain name to be example.com, it begins to send DNS queries for isatap.example.com.

Receiving the query, the DNS server responds with the IP address of isatap.example.com (which we configured as 192.168.66.2).

Armed with the IPv4 address of the ISATAP router, the ISATAP host prepares to send a router solicitation message. This router solicitation message is not sent to the all-routers multicast address; rather, it is unicast to the ISATAP address of the ISATAP router itself. Therefore, the host will calculate the link-local ISATAP address of the ISATAP router using the method we specified above for ISATAP interface ID. In our case, the resulting ISATAP address for the ISATAP router will be fe80::0000:5efe:c0a8:4202 or simple fe80::5efe:c0a8:4202.

As you can see, this message is encapsulated inside IPv4 and sent over the ISATAP interface to the link-local address of the ISATAP router. We can also confirm the link-local address from our ISATAP router’s tunnel interface:

On receiving this router solicitation message, the ISATAP router will reply with a router advertisement message which will contain an IPv6 prefix among other information.

Notice that the IPv6 prefix contained in this message is the prefix we configured on the tunnel interface of our ISATAP router.

Having received the router advertisement message, the ISATAP host can now generate an address for its ISATAP interface using the prefix obtained.

With this address, it can communicate with other ISATAP hosts and even a native IPv6 network. For example, I can ping the IPv6 address on the ISATAP router’s loopback interface.

As the Wireshark capture shows, this ping traffic is sent towards the ISATAP router (the default gateway of the ISATAP interface) which then forwards it appropriately.

Summary

While many of the other tunneling mechanisms we have considered in this series are used to connect IPv6 network in different sites, ISATAP is deployed to allow dual-stack hosts within a site to communicate using IPv6. ISATAP hosts must find (or be configured with) an ISATAP router through which they can obtain IPv6 prefixes.

This brings us to the end of this series. We have covered several tunneling mechanisms like manual tunnels, 6to4 and 6rd. We didn’t cover other tunnel types such as Teredo and GRE but you can read about them if you need to. Also, we didn’t discuss issues like how NAT affects the operation of these tunneling mechanisms. This is open to further study and RFC 7059 provides a good overview.

I hope you have found this article and the entire series insightful.

References and further reading

  1. RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP): http://tools.ietf.org/html/rfc5214
  2. RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms: http://tools.ietf.org/html/rfc7059