ADMIN
Nuts and Bolts IPv6 Tunneling Options Lead image: © Tramper2, fotolia.com
© Tramper2, fotolia.com
 

IPv6 tunnel technologies

Dug Out

Now that IPv6 is the official Internet protocol, all that remains is the simple task of migrating all the machines on the Internet. Until that happens, tunnel technologies provide an interim solution. By Eric Amberg

Migration to IPv6 is picking up speed. In the fall of 2012, Deutsche Telekom announced that new DSL customers would have dual stack connections (IPv4+IPv6). Other providers will be following suit in the next few months. For many larger companies, migration to IPv6 is not a matter of a few days but of years. As early as the design phase, the IPv6 developers took into account the fact that the introduction of IPv6 to existing IPv4 networks would, in some cases, involve a long transition period where both technologies would exist side by side. This article describes some tunnel technologies for implementing IPv6 in an IPv4 world.

In the transition phase, IPv6 systems must be able to communicate both with each other and with IPv4 systems. The term "node" in IETF terminology describes an active system on the network that communicates via IPv4 or IPv6. This includes normal workstations and servers as well as routers. RFC 4213 (Basic Transition Mechanisms for IPv6 Hosts and Routers) describes the following node types:

In the following section, the question is how to gradually introduce IPv6 parallel to IPv4. In the process, the challenge of merging the two worlds must be considered. In principle, the following approaches are available:

Although dual-stack implementations are the preferred choice in the parallel introduction of IPv6 into an existing IPv4 network, translation technologies do offer a transition from one IP stack to the other. However, only tunnel technologies are capable of connecting IPv6-only nodes with one other through an intervening IPv4-only infrastructure.

Tunnel Digging

IPv6 is being introduced gradually rather than immediately into many networks. A typical scenario in the transitional period is thus communication between IPv6 nodes on an IPv4 network. IPv6 communication needs to be transported over IPv4, that is, IPv6 needs to be tunneled into IPv4. This means that the IPv6 data packet is encapsulated in an IPv4 packet. The IPv6 node itself or a gateway wraps the IPv6 packet in IPv4 and sends it on its way. In doing so, it sets the protocol field in the IPv4 header to a value of 41 (Figure 1).

IPv6 encapsulated in IPv4: The IPv6 packet is wrapped in an IPv4 packet.
Figure 1: IPv6 encapsulated in IPv4: The IPv6 packet is wrapped in an IPv4 packet.

The IPv6 header contains the IPv6 addresses of the end-to-end communication, (i.e., of the communicating endpoints). The IPv4 header contains the source and destination addresses of the endpoints within the IPv4 network. These endpoints can be the "real" endpoints of the IPv6 communication in certain tunneling mechanisms. Most of the time, encapsulation is handled by the tunnel gateways. These are usually the border routers or firewalls of the local network.

From the point of view of an IPv6 packet, IPv4 encapsulation is nothing but ordinary encapsulation at link-layer level, like in Ethernet. In such tunnel scenarios, completely different structures can exist for the IPv6 network and the IPv4 network. For example, a complete IPv4 infrastructure, consisting of many routers and network segments, can be transcended in a single hop between the source and the destination from an IPv6 point of view.

The advantage of tunnel solutions is their flexibility in connecting individual IPv6 islands in the "IPv4 ocean." Nevertheless, tunnel technologies are always going to be second choice compared to native IPv6 communication, because they can be complex to configure and also prone to error. Thus, the Teredo tunneling mechanism (described later in this article) is regarded as only partially usable, because it does not work properly in the majority of cases [1].

Tunnel Configurations

Similarly to VPN tunnels, IPv6 tunnels can connect remote locations on the network. RFC 4213 provides for the following tunnel configurations:

Router-to-router tunnels connect IPv6 infrastructures via a single virtual hop in an IPv4-only infrastructure. This is the simplest and most common case of a tunnel, because the tunnel configuration is only needed on one or a few systems of the network, and the IPv6-only nodes do not need to know about it. A typical example of router-to-router tunnel is a 6to4 tunnel. In many cases, the tunnel connects two corresponding routers over the IPv4 Internet, in order to connect IPv6 networks across multiple locations (Figure 2).

Router-to-router tunnels connect, for example, two IPv6-enabled sites.
Figure 2: Router-to-router tunnels connect, for example, two IPv6-enabled sites.

The host-to-router tunnel connects an IPv6/IPv4 node on an IPv4-only network with an IPv6/IPv4 router (Figure 3). To do this, the host uses a tunnel interface and appropriate routing entries (e.g., in the form of the default gateway), which route the corresponding traffic to the tunnel interface. The tunnel interface wraps the IPv6 packets in IPv4 packets and sends them to the IPv6/IPv4 router, which forwards the IPv6 packets to the IPv6 destination. The way back (router-to-host) is similar. ISATAP is a tunneling technology that works on this principle. This tunnel type is mainly used to connect IPv6 nodes within an enterprise network.

A host-to-router tunnel connects an IPv6-enabled computer over IPv4 to an IPv6 router.
Figure 3: A host-to-router tunnel connects an IPv6-enabled computer over IPv4 to an IPv6 router.

A host-to-host tunnel connects the communicating endpoints directly with one another through an IPv4 tunnel. The encapsulated IPv6 packet is unpacked again only at the endpoint of the communication. This principle is also used in ISATAP tunneling technologies and is used to support communications between two IPv6 nodes within an IPv4 network.

Tunnel Types

Basically two different types of IPv6 tunnels are available: configured tunnels and automatic tunnels. With configured tunnels, the administrator needs to set up the tunnel manually on the tunnel endpoints. In this case, the IPv4 destination address of the remote endpoint is not embedded in the IPv6 address, as is typically the case with automatic tunnels. Configured tunnels use manually created tunnel interfaces that define fixed source and destination addresses.

No manual configuration is necessary for automatic tunnels. The tunnels are set up dynamically when needed; the IPv4 destination addresses are typically embedded in the IPv6 address. Tunnel technologies include:

In the rest of this article, I will take a closer look at how these technologies work.

6to4 – For the Internet

6to4 can act as a router-to-router, host-to-router, and router-to-host tunnel [2]. However, you will typically build the tunnel as a router-to-router configuration. 6to4 treats the entire IPv4 Internet as a single link. The prefix of 6to4 is 2002::/16, that is, it always begins with 2002. The use of a single address prefix means you can always identify a 6to4 tunnel address. The next 32 bits of the address contain the hexadecimal IPv4 address of the remote endpoints of the tunnel, which is a 6to4 router or 6to4 relay. Next are the 16-bit subnet ID and the interface ID of the target system (Figure 4).

6to4 embeds the target IPv4 address in the IPv6 packet.
Figure 4: 6to4 embeds the target IPv4 address in the IPv6 packet.

Windows systems as of Windows Vista automatically create a 6to4 tunnel interface, if the system uses a public IPv4 address on one of its interfaces and no other IPv6 connectivity (native or on ISATAP) exists. In this case, the 6to4 tunnel interface is assigned an IPv6 address of 2002:WWXX:YYZZ::WWXX:YYZZ, where WWXXYYZZ stands for the public IPv4 address. If the public IPv4 address of a Windows Server 2012-based computer is, for example, 131.107.1.1, then the 6to4 tunnel address is 2002:836B:101::836B:101.

6to4 uses various components to handle different tasks, as follows:

Each 6to4 site has its own 6to4 prefix (2002:WWXX:YYZZ::/48). The rest of the 6to4 address defines the subnet and the interface ID of the host on the network. From the perspective of a 6to4 host or router, the entire 6to4 site is comprised of a single computer: itself.

How 6to4 Works

For a 6to4 router, the 6to4 site can comprise up to 65,536 subnets. In any case, it sees all the subnets on the site. A 6to4 site can, on the other hand, comprise a single IPv4 address through which the site is accessible. In its router advertisements, the 6to4 router propagates the 6to4 prefix to the internal nodes so that 6to4 also works well with autoconfiguration.

The trick here is that the IPv4 address of the target host's site is embedded in the 6to4 address. The stakeholder systems extract this address and use it to bridge the IPv4 part of the route. In the example scenario from Figure 5, WKS1 wants to communicate with WKS2 and resolves the Fully Qualified Domain Name (FQDN) of WKS2. The DNS server returns the address 2002:9D3C:101:F::1. From the prefix, WKS1 sees that this is a 6to4 address.

A sample scenario for the use of 6to4.
Figure 5: A sample scenario for the use of 6to4.

As a 6to4 host/router with a public IPv4 address, WKS1 is itself in a position to tunnel the IPv6 packet in IPv4, so it references bits 17 through 48 to identify the prefix of the 6to4 router's IPv4 address as 157.60.1.1. The tunneled packet is now sent to the 6to4 router, which again unpacks the packet and accordingly forwards it internally. Because WKS1 uses its 6to4 tunnel address of 2002:836B:101::836B:101 as the from address, the 6to4 router can deliver the response packet from WKS2 to the correct IPv4 address, 131.107.1.1, which it extracts from the prefix for WKS1.

To address native IPv6 addresses on the IPv6 Internet, the 6to4 router or 6to4 host/router looks for a 6to4 relay in the neighborhood. The IPv4 Anycast address 192.88.99.1 exists for this purpose. In other words, IPv6 packets to native IPv6 addresses are also encapsulated by 6to4-enabled nodes, where the destination address of the IPv4 header is 192.88.99.1. These packages go to the nearest 6to4 relay and are delivered there with the help of normal IPv6 routing.

The response of the IPv6-only node is also routed via a 6to4 relay, although this is not necessarily the same relay as the one used on the outbound route. This variation in the path can lead to the typical problems associated with asymmetrical routing; for example, a stateful firewall might not be able to correctly assign the response packets. In this context, the nodes on the IPv6 Internet must know a route to a 6to4 relay – but this is not always the case. Additionally, 6to4 has the disadvantage that NAT is only supported if the 6to4 router or the 6to4 relay is also the NAT device. 6to4 is supported by most popular operating system platforms.

6rd – The Evolution

6rd [3] tunneling technology is based on 6to4 and was designed by Rémi Després. 6rd was introduced in 2007 by French provider FREE. The letters "RD" stand for rapid deployment and also happen to be the developer's initials. In contrast to 6to4, 6rd uses end customer prefixes, instead of a separate prefix of its own. This feature contributes to the success of 6rd. After Després published RFC 5569 as an informational RFC, the IETF went on to prepare 6rd for standardization as RFC 5969.

In contrast to 6to4, the data for the communications is transported between internal and external IPv6-only nodes that are connected via the IPv4 Internet by the provider's own 6rd relays (Figure 6). The provider retains full control over IPv6 communications crossing its networks and can therefore also use its own prefixes. Because the public IPv4 address of the 6rd relay must be communicated here, too, it is also embedded in the IPv6 address.

In 6rd, the data for communications between internal IPv6-only nodes is transported via the provider's own 6rd relays.
Figure 6: In 6rd, the data for communications between internal IPv6-only nodes is transported via the provider's own 6rd relays.

One special feature of 6rd is the fact that the prefix assigned to a provider is variable, so, in the case of longer prefixes, there are not enough bits in the IPv6 address. If the provider receives a standard prefix (/32) from the Regional Internet Registry (RIR), it can accommodate the IPv4 address in the following 32 bits. But, the provider can only provide a single subnet to the customer, because the last 64 bits of the IPv6 address are reserved for the interface ID. In the case of FREE, the provider later received a /26 prefix. The address was divided so that the IPv4 hex address was embedded after the prefix; then two reserved bits followed, and, finally, the 4-bit subnet ID.

Another approach to the problem of saving static bits for the purpose of supporting longer provider prefixes is to omit redundant parts of the IPv4 address. If a provider, for example, always uses a specific /18 subnet for its customers, the provider can omit the first 18 bits of the IPv4 address without losing any relevant information. The 6rd technique is an interesting approach with the potential of replacing the legacy 6to4 system in the medium term.

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).

The ISATAP protocol configures computers automatically. However, its use is restricted to intranets.
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:

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:

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:

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:

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.

A Teredo address encodes the Teredo server, the NAT flags, the port, and the external 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.

Conclusions

If you have the choice, you should always opt for native IPv6 connections. Unfortunately, that is only possible in the rarest of cases so far. IPv6 tunnels are thus frequently the only option that IPv6 systems have for connecting. Depending on the application, the various tunneling solutions presented in this article each have their advantages and disadvantages.

In principle, however, none of these tunneling mechanisms is designed for the long term – ultimately, all tunnels will be replaced at some time by native IPv6 connections. This factor should also be taken into account when planning a migration, because removing a well-established tunnel mechanism in a few years may well involve additional overhead.

Besides the technologies presented here, tunnel brokers (e.g., SixXS) can give the end user the ability to access IPv6 systems on the Internet through various technologies, including tunnel client software. Again, these approaches are ultimately just interim solutions designed to bridge the period up to the deployment of native IPv6 connections. In some cases, however, an interim fix can turn out to be the best permanent solution.