An alternative to 6over4 is ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) [TGTT05]. ISATAP also uses the site’s IPv4 infrastructure as a virtual link, but it does not use IPv4 multicast, so the link is NBMA (Non-Broadcast Multiple Access).

ISATAP, like 6over4, creates an interface identifier based on the interface’s IPv4 address. ISATAP supports both autoconfiguration and manual configuration of addresses, but the IPv4 address of the interface will be embedded as the last 32 bits of the IPv6 addresses. As with 6over4, the IPv4-address needs only be unique in the network the service is deployed in.

Usually multicast is used for neighbour discovery operations like address resolution and router solicitations or advertisements. Since the IPv4 address is always embedded in the IPv6 address, address resolution is trivial. For router solicitations to work, the host must somehow have learned of IPv4 addresses of possible ISATAP routers (through DHCP, DNS, TEP, manual configuration etc.), and will then send solicitations as unicast. The router always sends advertisements as unicast and only as a reply to a host’s solicitation. Each ISATAP host will regularly send solicitations to the ISATAP routers it knows of.

ISATAP has been implemented on some platforms, e.g. Windows XP and IOS, although it has been removed from USAGI Linux now. The authors feel that while it has applicability in some sites, where a phased, managed introduction of IPv6 is desired, an approach like [Cho04b] is preferable. In either case, the solution is an interim step until dual-stack network elements are available for the site.