Skip to content

The future of IPv6 after SixXS has shutdown

Today, SixXS is shutting down. After providing IPv6 connectivity via tunnels for many years, the people behind SixXS decided that it is now the job of each ISP to provide native IPv6 connectivity. While I fully agree with their sentiment, I still think that they leave a gap - not just because some ISPs might still not provide native IPv6, but because of the design of IPv6 itself. Just to make this clear: I do not blame the people and companies behind SixXS in any way. I am very grateful for the service they have provided for so many years and perfectly understand why they made this decision.

In order to understand why SixXS leaves a gap, one first has to understand how IPv4 and IPv6 are typically deployed and how they differ. It is safe to say that most local networks use private IPv4 addresses (as defined in RFC 1918). The only notable exception to this rule are large organizations that started to use the Internet so early that they still got large allocations of global IPv4 addresses (most universities and research institutes belong to this group).

The use of private IPv4 addresses for the internal network made it necessary to use network address translation (NAT) when connecting to the public Internet. Everyone involved with network administration knows from experience that NAT can be a headache, but due to its ubiquitous use in IPv4, most network applications expect it and know how to deal with it.

With IPv6, one of the main motivations for NAT disappeared: The address space is now large enough to provide a unique, public address for each device on the planet. This means that IPv6 was designed without NAT in mind, aiming to provide true end-to-end connectivity. However, this leaves us with one question: How does each device get its IPv6 address?

The idea in the design of IPv6 is that each network has its public IPv6 prefix (defining the first 64 bits of the IPv6 address) and that a device uses this prefix for generating an IPv6 address. Obviously, this only answers one part of the question. One question remains: How does each network get its IPv6 prefix?

The answer to this question is much more difficult. In general, one could say that each network gets its IPv6 prefix from the router that provides connectivity to the outside world. That router in turn will most likely get its (shorter) prefix from another router, and so on. This has been implemented with DHCPv6 prefix delegation (DHCPv6 PD).

The ideas is that you get an IPv6 prefix from your ISP and your Internet router will delegate slightly longer prefixes to each of the routers in your network which in turn will provide the prefixes to your devices. So everything should be great, right? Wrong. As the address of each device depends on the prefix assigned by your ISP, the address of each device will change when your ISP decides to change that prefix. Some ISPs (like my ISP, Deutsche Telekom), will actually change your IPv6 prefix periodically. Some ISPs (including Deutsche Telekom) might offer to provide you with a fixed prefix for a (significant) surcharge, but even that will not solve your problems completely. As soon as you decide to switch ISPs, all of your addresses are going to change, which means that you have to update your internal DNS, change the configuration of your firewalls, etc.

This is why the services provided by SixXS are still useful, even if an ISP provides native IPv6 connectivity. When using a tunnel, you can switch your ISP, but take your IPv6 addresses with you. In theory, there is a better way than using a tunnel: You could get your own IPv6 address space and have your ISP route it to you. The first part is actually not as hard as it sounds: There are providers (in Europe RIPE members) which will happily assist you with the registration process for a small few (I have seen such offers for only 10 EUR per month plus a one time fee). The second part however is quite hard: Yes, there are ISPs which will route traffic for your address space to you, but this typically means that you will have to get the expensive kind of Internet connectivity. At least I know of now DSL or cable provider that will route your own address space. This means that using PI addresses is not affordable for most individuals and small companies.

Effectively, this means that the technical standards provide solutions, but they are not feasible for many users. So the question is: Which alternatives do exist? With IPv4, using private addresses solved this problem and in IPv6 there is something very similar to private addresses: Unique local addresses (ULAs) are definded in RFC 4193 for specifically this purpose. By using such addresses, one can have fixed addresses in a private network without having to rely on any external entity.

There are two ways how ULAs may be deployed. Each local network can have both a ULA and a global prefix (the latter one being assigned by prefix delegation) or one can use ULAs exclusively. The first solution sounds more reasonable: ULAs can be used for internal communication, but each device still has a global address so that it can communicate with the outside world. Unfortunately, such a setup causes a lot of problems in my experience: There are many applications (in particular in Windows networks) that discover addresses automatically, and some of the internal communication will end up using the volatile global addresses instead of using the permanent ULAs. This means that you will still experience problems when the externally assigned prefix changes. In addition to that, your internal firewalls will have to deal with changing prefixes.

For this reason, the best approach in my experience is using ULAs exclusively. The main disadvantage of this solution is that now we again have to use NAT in order to provide connectivity with the Internet. Originally, NAT was not even specified for IPv6, but this gap has been closed by RFC 6296. In the case of IPv6, network prefix translation (NPT) is sufficient because there are enough addresses. This means that each ULA will be mapped to one global address and the other way round. It also means that UDP or TCP port numbers are not touched by the translation mechanism.

I adapted this scheme about a year ago, when SixXS first announced that they were going to discontinue their service. I described the details of the setup in my wiki. So far, it has been working very smoothly, with one notable exception: In many cases, IPv4 seems to be preferred when a host only has a ULA. This means that most communication will still use IPv4 and IPv6 is only going to be used when a hostname only resolves to an IPv6 address.

Apart from that, their might be issues with applications that use more than a single connection. RFC 6296 says:

End-to-end reachability is preserved, although the address used
"inside" the edge network differs from the address used "outside"
the edge network.  This has implications for application referrals
and other uses of Internet layer addresses.

Most IPv4 applications have developed techniques that work around these issues. Only the future will show if IPv6 applications will adapt the same techniques.

Last but not least, RFC 7157 describes how it might be possible to make hosts work with several addresses using different prefixes. If this RFC were to be adopted by the operating systems and applications, it might be possible to use ULAs and global addresses in parallel. Until then, the source address selection rules as described by RFC 6724 unfortunately are not sufficient to make such a scenario work reliably, so NPT seems to be the best choice for now.