Dug Out

ISATAP – For the Intranet

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is used for host-to-host, host-to-router, and router-to-host connections. Router-to-router connections are not envisaged. ISATAP is used to connect IPv6/IPv4 nodes over an IPv4 infrastructure on an enterprise network. This protocol is not designed for connecting over the Internet. ISATAP should not be used on production networks, because it is primarily used for testing purposes (Figure 7).

Figure 7: The ISATAP protocol configures computers automatically. However, its use is restricted to intranets.

ISATAP is defined in RFC 5214 and requires no manual configuration on the hosts. It was developed by Cisco and Microsoft, but it is also supported by Linux [4]. Like 6to4, ISATAP uses a virtual tunnel interface that is created automatically and assigned an IPv6 address. An arbitrary Unicast/64 prefix can be used (including link-local). The IPv4 address of the corresponding LAN interface is embedded at the end of the interface ID. Depending on whether they are global or private, according to RFC 1918, ISATAP addresses have the following format:

• Global addresses: 64-bit Unicast prefix:200:5EFE:w.x.y.z
• Private addresses: 64-bit Unicast prefix:0:5EFE:w.x.y.z

Here, w.x.y.z stands for an IPv4 address in the normal dotted decimal notation. A possible ISATAP address would be, for example, 2001:db8:200:5EFE:85.25.66.51. The ISATAP tunneling interface views the IPv4 part of the network as a single link-layer segment, in a similar way to Ethernet. From the point of view of ISATAP, link-layer encapsulation is thus handled by IPv4.

How ISATAP Works

A Windows system creates a separate ISATAP tunneling interface for each LAN interface, which receives its own DNS suffix (and thus resides on a separate subnet). The ISATAP interfaces initially have a status of "Disconnected" from Vista SP1 onward, as long as the ISATAP name cannot be resolved. This DNS name resolves to the IPv4 address of an ISATAP router. If "ISATAP" can be resolved, the following happens:

• The ISATAP interfaces assign themselves a link-local address: FE80::5EFE:w.x.y.z or FE80::200:5EFE:w.x.y.z.
• The ISATAP hosts use the ISATAP tunneling interface to send a router solicitation message unicast via IPv4 to the IPv4 address of the ISATAP router.
• The ISATAP router responds with an IPv4 router advertisement unicast to the IPv4 address of the ISATAP host, in which it announces itself as the default gateway and propagates the prefix for the ISATAP subnet. This can be a global unicast or a unique local prefix.

Communication with the router is handled via IPv4 unicast. The normal approach of using IPv6 multicast is not available for exchanging router solicitation and advertisement messages. IPv4 multicast cannot be used, because it would require an IPv4 multicast infrastructure across subnets.

The ISATAP router on an ISATAP network is mandatory for initial activation of the ISATAP tunneling interfaces. However, it does not need to assign prefixes because, in a local ISATAP segment, the ISATAP hosts can communicate via their link-local addresses. The ISATAP router can also connect ISATAP hosts with a native IPv6 part of an enterprise network. However, this approach requires a global unicast or unique local prefix, which must be assigned via router advertisements. In this case, the ISATAP hosts can use their autoconfigured addresses to communicate with IPv6 nodes outside of their own ISATAP subnet, by using the ISATAP router as the default gateway. In contrast to ISATAP hosts, the ISATAP router must be configured manually.

ISATAP has the advantage on Windows of being quickly implemented. The disadvantage is that communication is limited to the corporate network and not designed for communication with systems on the Internet. Additionally, ISATAP is not suitable for use in many NAT scenarios.

Teredo

6to4 offers an IPv6 tunnel over the IPv4 Internet, but it has the disadvantage that the 6to4 router always needs an official IPv4 address. If the router resides behind a NAT device, 6to4 does not work. This is where Teredo comes into its own. Teredo is a tunneling technology developed by Microsoft that is used, in particular, with Microsoft environments. However, a Teredo implementation is available for Linux [5]. Incidentally, the name is derived from Teredo navalis , which is the name for a shipworm.

Teredo is defined in RFCs 5991 and 4380 and provides IPv6 tunnels for IPv6 nodes that reside behind NAT devices and are not 6to4 routers. To do this, Teredo does not just tunnel IPv6 packets in IPv4 but also in UDP. Thus, the original IPv6 packet is transported by UDP as a payload, which improves the chances of getting through a NAT device. In principle, the tunneled packet can also pass through multiple NAT stages.

The NAT types play an important role. RFC 3489 distinguishes between the following types:

• Cone NAT: There is a 1-to-1 mapping between internal and external addresses, which can accordingly also be addressed from external locations.
• Restricted NAT: Contact from the outside is only possible if a connection was previously set up from the inside.
• Symmetric NAT: The internal address can be assigned to different external addresses and is therefore not clearly identifiable from the outside.

In practice, however, this distinction is only a guideline, because many NAT routers use a hybrid approach. Teredo basically works with Cone NAT and Restricted NAT. Teredo defines the following components:

• Teredo clients: These are IPv6/IPv4 nodes that support Teredo tunneling interfaces (as of Windows XP SP1).
• Teredo servers: IPv6/IPv4 nodes that are connected to both IPv4 and to the IPv6 Internet. They assign Teredo prefixes and help the Teredo clients to contact other Teredo clients or IPv6-only nodes. Teredo servers listen by default on port 3544/UDP.
• Teredo relays: IPv6/IPv4 routers that forward packets from Teredo clients on the IPv4 Internet to the IPv6 Internet. They work partly with Teredo servers.
• Host-specific Teredo relay: This relay is also connected to the IPv6 and IPv4 Internet. If an IPv6 node is also IPv4-capable, it can communicate directly over IPv4 with the Teredo client via a host-specific Teredo relay. In this case, no Teredo relay is needed, so there is no communication on the IPv6 Internet.

The Teredo address (Figure 8) consists of a 32-bit prefix (2001::/32), followed by the hexadecimal IPv4 address of the Teredo server. The last 64 bits are split into three parts. The flags (16 bits) define, in particular, the type of NAT. The encrypted external port (16 bits) states the port on which the internal Teredo client is accessible from the outside through the NAT device. The Teredo server determines this by analyzing the source port of the packets that reach it from the client and informs the client of the result in the response packet. Because some NAT devices try to translate a port contained in the payload to the internal port number, this value is XOR-encrypted. The last 32 bits contain the client's encrypted external IPv4 address.

Figure 8: A Teredo address encodes the Teredo server, the NAT flags, the port, and the external address.

Teredo addresses are assigned exclusively to Teredo clients. Teredo servers and relays only receive native IPv4 or IPv6 addresses. Communication is now initiated by the Teredo clients via the Teredo servers; the servers tell the clients which official IP addresses and ports they are visible on. Armed with this information, the Teredo session leverages the NAT entries to be able to address the internal systems from the outside. To keep the NAT sessions running, Teredo clients send bubble packets to the Teredo servers at regular intervals. A bubble packet is an "empty" IPv6 packet encapsulated in an IPv4 UDP packet.

If two Teredo clients want to communicate with each other on the same link, they use bubble packets as a replacement for the neighbor discovery process to initiate the conversation. If a Teredo client wants to communicate with another Teredo client on a remote site, the communication depends on the NAT type.

If both nodes reside behind a Cone NAT, the systems can connect directly, because a connection can be set up by any source IP address in line with the Cone NAT definition. However, if the nodes are located behind routers using Restricted NAT, bubble packets must first be sent to the remote sites and the Teredo server, which then initiates the connection. After the connection is opened, the actual communication is routed directly between the two peers; the Teredo server only helps to set up the connection.

Where a Teredo client connects with a native IPv6 node on the IPv6 Internet, the Teredo server also acts as a router on the IPv6 Internet. Connections that need to be set up from the IPv6 Internet to a Teredo client are implemented with the help of the nearest Teredo relay or host-specific relay.

These complex mechanisms make Teredo very slow when it comes to opening connections (because of timeouts, etc.) and also unreliable, because connections can only be established under specific conditions. Teredo is thus not suitable for production use right now.