ISATAP - Intra-Site Automatic Tunnel Addressing Protocol

ISATAP was originally specified as experimental in RFC 4214, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", October 2005. This was completely replaced by a new version, as informational (still not standards track) in RFC 5214, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", March 2008. There is actually a website devoted to ISATAP.

From the RFC:

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
dual-stack (IPv6/IPv4) nodes over IPv4 networks.  ISATAP views the
IPv4 network as a link layer for IPv6 and supports an automatic
tunneling abstraction similar to the Non-Broadcast Multiple Access
(NBMA) model.

Like any IPv6 over IPv4 tunneling mechanism, ISATAP connects two regions of IPv6 via a tunnel that will transit any existing IPv4 infrastructure. Like all the other mechanisms described here, it is built on top of 6in4 tunneling. It does not require IPv4 multicast. It uses the existing IPv4 Internet as a "Link Layer" (L2). ISATAP does not include NAT traversal, so the IPv4 address below must be a public (globally routable) IPv4 address (not an RFC 1918 address from 10/8, 172.16/12 or 192.168/16). It solves the same problem as basic 6in4 tunneling, but can automatically configure the tunnel. Once there is an ISATAP compliant router in your subnet, and a PRL is defined in your local DNS, tunnel creation is automatic. ISATAP is designed to route a block of IPv6 (/64, /48, etc) through the tunnel. Once you have the tunnel in place, your node can obtain regular IPv6 addresses from it. Your router should advertise the tunneled IPv6 prefix(es) so that internal nodes can generate compatible addresses via SLAAC. You can also manually configure IPv6 addresses in the advertised IPv6 prefix(es).

ISATAP is really designed to tunnel between routers, although it is specified to work router-router, router-host or even host-host. Each endpoint must have a public IPv4 address (just like with 6in4 tunnels), which limits its ability to work on hosts. The router must support ISATAP (most Cisco IOS based routers do, but not many others do - few if any SOHO style modem/routers support ISATAP). Like any tunneling scheme it is two-ended - there must be another ISATAP compliant router somewhere else that has access to the IPv6 Internet for your ISATAP router to build a tunnel to. I was unable to locate any sources of free ISATAP tunneled service, such as exists for 6in4, TSP (from freenet6) and AYIYA (from

ISATAP routers should be published in DNS, so that its IPv4 address resolves (via reverse lookup) to a name including "isatap" (e.g. "").

ISATAP nodes generate a link local IPv6 address from your IPv4 address, and provides a mechanism for performing Neighbor Discovery on top of IPv4. The generated address is created by appending your public 32-bit IPv4 address onto the special IPv6 prefix fe80:0:0:0:0:5efe::/96. For example, if your public IPv4 address is, in hexadecimal this would be 0xc000028f. The generated ISATAP address would be fe80::5efe:c000:28f (or in mixed mode notation, fe80::5efe:

The Link Layer (L2) address from the viewpoint of ISATAP is not a MAC address, but an IPv4 address. Since the IPv4 address is just the low 32 bits of the ISATAP address, "address resolution" (mapping the Internet Layer (L3) address onto the Link Layer (L2) address) simply retains the low 32 bits of the IPv6 ISATAP address (hence no ND address resolution mechanism is needed).

Router Discovery is more difficult without IPv4 multicast (which is required with 6over4 tunneling). ISATAP nodes are configured with a Potential Routers List (PRL). Each of the routers on this list is probed by an ICMPv6 Router Solicitation message to determine which of them are functional and willing to act as a gateway. Note that in the ISATAP world, "link local" includes the entire IPv4 Internet (or at least those parts of it that include ISATAP support). This also obtains a list of on-link IPv6 prefixes that can be used to create global unicast IPv6 addresses.

ISATAP tunneling is implemented in all versions of Windows (since Vista), in Linux (since kernel 2.6.25), in FreeBSD, and in Cisco IOS. Information on building your own ISATAP router with Linux is available here.

There is a much more advanced version tunneling mechanism based in ISATAP, which is specified in RFC 5720, "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", February 2010. This is just an informational RFC, not standards track. It adds support for scalable routing and addressing, provider independent addressing, site mobility and multi-homing, address and prefix auto-configuration, border router discovery, router/host to router/host tunneling, neighbor discovery over tunnels and MTU determination for tunnels. RANGER combines elements from Virtual Enterprise Traversal (VET) (RFC 5558) and Subnetwork Adaptation and Encapsulation Layer (SEAL) (RFC 5320). I was unable to locate any current implementations of RANGER, but perhaps some vendors will implement it in the future.


Analysis of IPv6 Connection Types over a Six Year Period

These statistics are from data collected by Eric Vyncke. They involve tens of thousands of connections to a site since 2008. During that time, ISATAP usage (as a percentage of all IPv6 traffic) started around 2.5% in 2008, and has declined to 0.08% today (virtually non-existent). The breakdown by year and connection type are as follows (note that "native" includes 6in4, since there is no way to tell the difference).

Year   Native   Teredo   6to4     6rd     ISATAP

2008 21.75 35.57 21.89 18.29 2.50


23.78 46.68 18.07  9.99 1.48
2010 25.53 48.37 19.80  5.70 0.60
2011 27.06 53.92 16.78  1.94 0.30
2012 24.07 60.48 14.14  1.12 0.19


48.50 12.16  1.40 0.08

Native connections had been around 20-25%, but suddenly jumped to almost 40% in 2013. Teredo is remaining at about 50% (with a peak in 2012 to 60%). 6to4 has decreased from about 22% to just over 12%. 6rd started big (from then has not grown at all, while others have grown a lot. It is now insignificant. ISATAP started small and has almost vanished.



Since there must be at least one ISATAP compliant router in your subnet (most routers aren't), it is not simple to set up ISATAP.

Therefore, you should not consider using ISATAP unless you just happen to have the requirements. Even then there are security issues with it (you should terminate all tunnels at the border gateway and block any tunnels trying to terminate inside your LAN). The low (and decreasing) usage of it is proof of the difficulty of deploying it.