Digging Tunnels

To support the customer-faced features discussed here, IPv6 rethinks the on-wire protocol and helps routers parse it quicker. IPv6 drops the convoluted IP options mechanism, replacing it with the so-called "extension headers" that routers ignore most of the time. This means the IPv6 header is always 40 bytes, which streamlines network hardware design and eventually makes routing faster. Moreover, IPv6 routers don't need to update the checksum after they decrement the TTL. IPv6 simply reuses the checksum field in the UDP or TCP payload and excludes TTL from the calculation. Finally, intermediate routers don't fragment IPv6 datagrams anymore. All fragmentation occurs at the source, where the Path MTU (PMTU) discovery process is employed to determine the maximum datagram size. PMTU also relies on ICMP6.

Note the Next Header field of the IPv6 header depicted in Figure 2. Normally it stores a transport layer protocol identifier, such as 6 for TCP or 17 for UDP. If the datagram uses extension headers, Next Header tells the extension header type. Extension headers have their own Next Header fields that are used for "chaining," which is how fragmentation and security extensions (which were backported to IPv4 as IPsec) work in IPv6.

Figure 2: IPv6 header, along with some extensions. This example shows a fragmented UDP packet.

IPv4 and IPv6 also have their own protocol numbers (Listing 3; taken from Ubuntu 16.04). What happens if you put 41, a protocol value for IPv6 itself, in the Next Header field?

You get an IPv6 datagram encapsulated in another IPv6 datagram. For IPv4 in IPv6, a value of 4 (IP-ENCAP or IPIP) does the trick. This is known as IP tunneling. It's not a technology you are likely to find in your living room, yet it comes in useful when you want to connect two IPv4 networks over an IPv6 transport network, or you could employ it as a simple network virtualization mechanism. You have a physical IPv6 network using one addressing scheme (often out of your control). When you create tunnels between hosts, you need to communicate and use the addressing you want. For instance, a load balancer can create tunnels to deliver traffic to your back-end servers as if they were connected directly. Despite the name, IPv6 tunnels don't add any security by themselves.

Linux supports IPv6 tunneling via the stock ip6_tunnel kernel module, and you create and manage tunnels with the ip command (Listing 4). Here, I create and set up the ip6tnl1 network interface, which encapsulates both IPv4 and IPv6. This is known as an any/ip6 tunnel. You should also tell ip the addresses for both the remote and local ends of the tunnel and then assign the ip6tnl1 interface some address, as I showed earlier. You also might want to add an explicit network route because tunnel interfaces are point-to-point devices, so it doesn't happen automatically.

Repeat the process on another box but reverse the local and remote peers and use fd5c:5053:5e0e::2 as an address. Now you should be able to ping both peers. If you spot an ip6tnl0 interface, please ignore it; it is there for internal reasons.

The Other Way Around

Alas, not all of the world is IPv6-ready yet. This varies from country to country, and although my ISP has offered IPv6 for a long time, you might not be that lucky. Things change, fortunately, but transition takes time, and for a time, we'll have to live in a dual-stacked world.

There are several ways to "convert" your IPv4 address to IPv6, and most of them rely on tunneling techniques similar to (but different from) those I covered in the last section. The most common mechanism is 6to4 [4]. It implies you have a public IP address, which is not the case for many of us behind our NATs. My personal favorite is Teredo, an open protocol (RFC 4380) developed by Microsoft well before it open-sourced .NET Core and friends. The protocol encapsulates IPv6 datagrams in UDP and delivers them over IPv4 networks to Internet servers, typically listening on port 3544. Teredo has its own IPv6 prefix (2001::/32). The other 96 bits encode client and server IPv4 addresses and some auxiliary information.

A de facto standard GPLv2-licensed Linux implementation is called Miredo [5], which you are likely to find in (maybe community) repositories, but it's equally straightforward to build yourself. Miredo is a pure userspace Teredo implementation relying on TUN devices for networking machinery. It usually installs itself as a system service and creates a teredo interface when you start it. The configuration file is usually at /etc/miredo/miredo.conf, but it's unlikely you'll have to adjust anything there.

You might have to make some adjustments if you try to use Teredo. Because Teredo is Microsoft technology, the company used to have a server farm to support it. Apparently, it's torn down now, because Teredo is considered deprecated (everyone should have native IPv6 connectivity today). The config file lists some other options (and you can google a few others), yet it points to teredo.remlab.net by default. This server is maintained by Miredo authors (if anybody), and it is for testing purposes only. Don't forget to use something else if you plan to deploy Miredo for real.

With teredo up and running (see Figure 3), your host now has global IPv6 connectivity, and it's reachable even if it is behind NAT, which makes Teredo a viable alternative to port forwarding (see the box "A Word on NAT"). If you drop a dynamic DNS into the mix, you can access your home NAS from wherever you are. Everyone else can do it too, though, so make sure you install the latest updates and use strong passwords. With great power comes great responsibility, you know.

Figure 3: With Miredo, you can enjoy IPv6, even if your ISP doesn't support it yet. It also works great for NAT traversal.

A Word on NAT

In today's IPv4, NAT is almost a must. IPv6 also has several NAT flavors: NAT46 (translates IPv4 to IPv6), NAT64 (the reverse; Figure 4), and NAT66, but their usage is discouraged. With address space so abundant and multiple addresses on a box being a norm, there is no need for "gray" addresses in IPv6 networks anymore, and you have better ways to bridge IPv4 and IPv6 networks, as I explain here. Many NAT46 and NAT64 implementations (e.g., Tayga [6]) are userspace, which affects performance. Some might argue that NAT hides network topology and adds some security. That's questionable. The real use case for NAT is when you connect an IPv6-only box to an IPv4-only host (e.g., github.com) over the Internet. For everything else, there is often a better alternative.

Figure 4: Tayga is a quite popular NAT64 implementation for Linux. Like Miredo, it uses TUN devices and runs in userspace.