At the RIPE 67 meeting in Athens, Greece, the RIPE IPv6 Working Group ran a little experiment to test the feasibility of an IPv6-only network and to identify challenges in user experience. While the results were highly encouraging, they indicated that there is still work to be done before IPv4 can be switched off once and for all.

As IPv6 is slowly but surely deployed around the world, we’ve entered a phase where it’s necessary for your devices to be able to communicate using either of the two IP protocols currently in use. Called dual-stack, this is where a device uses both an active IPv4 and IPv6 address at the same time. The idea being that eventually, when IPv6 has been deployed widely enough, we can switch-off IPv4 altogether and thereby transition to an Internet that can grow unconstrained—the IPv6-only Internet.

Global supplies of IPv4 are running low—with the free IP address pools available from the Regional Internet Registries (RIRs) already exhausted in Europe, the Middle East, Asia and the Pacific (with North and South America not far behind). Demand for IPv4 will only increase as the Internet expands and this will necessitate the use of IP address sharing approaches such as Carrier Grade NAT (CGN). This can be costly to implement and can result in a compromised experience for customers: an inability to connect to devices behind the translator, the failure of devices that rely on rich connectivity, and the possible degradation of performance.

Sticking with IPv4 isn’t a viable long term option. One bold alternative would be to deploy an IPv6-only network, but the big question here is whether such a solution would provide a good customer experience. This is what we set out to find with our fledgling network at RIPE 67.

Of course, running a true IPv6-only network would render a lot of websites unreachable, as they will have not yet deployed IPv6 themselves. So that our users could reach these services, we deployed a form of Network Address Translation called NAT64. Using this technique, the clients are made to believe that a site or service is available over IPv6—even when it’s not. A router device at the network edge intercepts IPv6 connections and converts them to IPv4, using a small pool of shared IPv4 addresses.

While NAT64 shares all of the usual limitations of IPv4 address sharing techniques, it also allows users, service providers or applications to work around these issues by using the IPv6 protocol. And as IPv6 deployment continues, the demand for this translation will decrease over time (rather than increase in the case of IPv4 CGNs).

During the week-long experiment, we had over 40 people (10% of RIPE 67 attendees) using our IPv6-only network. Aside from one minor disruption caused by a faulty cable, the network ran smoothly and with comparable performance to the main dual-stacked network that the RIPE NCC provided. User feedback about the experimental network was very positive. Some people even admitted they didn’t realise when they were still on the experimental network for an entire day.

However, there were several problems with client software. Applications on smartphones and tablets were particularly difficult. While connectivity worked fine for basic applications such as web browsing or email, a lot of dedicated applications seemed to explicitly test for the presence of an IPv4 address and, finding none available, assumed there was no network connectivity and reported this as an error or switched to offline mode. We also found some interactive web-based applications that tried to set up connections in the background that relied on an IPv4 address for session tracking or authentication.

While these problems were not severe and could often be worked around, they increased the chance of users calling customer support, making the set-up in our experiment not fit for large scale consumer deployments. Despite ongoing efforts to reach out to software developers and urge them to not only build support for IPv6 into their products and to ensure they function correctly in an IPv6-only environment, it is unlikely that these problems will disappear anytime soon.

For this reason, the IETF has developed an alternative to the NAT64 translation we used at RIPE 67 called 464XLAT. Based on the same principles of translating IPv6 into IPv4-based connections, this technique relies on a small modification to the client operating system. This will ensure that any application that relies on an IPv4 address for the correct operation will appear to have IPv4 available. These applications are made to believe that a fully functional IPv4 network is available, while in the background all connections are translated and use the IPv6 protocol.

Several smartphone manufacturers are now including support for 464XLAT in their products. It is also being used by a large US-based telecommunications provider, that is deploying this with millions of users on its 4G network. This proves that while careful planning and testing is still required, in certain cases it is feasible to turn off IPv4 in access networks without any impact on network performance or increased demand on support channels.

Dual-stack remains the preferred solution. However, when you have to make a choice, why not choose to go IPv6-only? Doing so would ensure that your network is ready for the future and at the same time can release valuable IPv4 resources to deploy where IPv6 support remains a feature request.

And if you are developing software or apps—please consider building in IPv6 support and ensuring that your product functions correctly in the absence of a working IPv4 connection.