Home / Blogs

Are We Ready to Switch Off IPv4?

Marco Hogewoning

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.

By Marco Hogewoning, External Relations Officer, Technical Adviser at RIPE NCC

Related topics: IP Addressing, IPv6

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Good article. Chris Buijs  –  Dec 16, 2013 1:39 AM PST

Enjoyed reading this and see some real "problems" concerning IPv6 adoption/usage and solutions around it.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Dyn Adds Chris Griffiths As New VP of Labs

IP Geolocation: Four Reasons It Beats the Alternatives

Nominum Releases New Security Intelligence Application

New Nixu NameSurfer 7.3 Series Powers the Software-Defined Data Centre

New Nixu Solution Slashes Cloud Application Delivery Times from Weeks to Milliseconds

Domain Name Registrations Pass 233 Million in the First Quarter Of 2012

Automate IPAM Set-up with Nixu NEE 1.3 Series

Nominum selected as 2012 AlwaysOn Global 250 Top Private Company

Streamline Application Delivery Processes with Nixu NameSurfer 7.2.2

Nominum Releases New Version of Carrier-Grade DHCP Software for Telecom Providers

Nominum Survey of World's Leading ISPs Shows Nearly 60% of ISPs Plan to Roll-Out IPv6 by End of 2012

Frontline and Nominum Deliver Integrated DNS-Based Platform to Enhance Enterprise Security

Nominum Sets New Record for Network Speed and Efficiency

Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)

Nominum and Nixu Software to Deliver Centralized DNS and DHCP Management Solution

Nixu NameSurfer 7.2 Strikes Rich at Dojo

DotConnectAfrica Participates at ICANN 43 In Costa Rica, the "Rich Coast"

Nominum Launches World's First Purpose-Built Suite of DNSā€Based Solutions for Mobile Operators

Is IPv6 the New Y2K? (Primer)

Sponsored Topics

Verisign

Security

Sponsored by
Verisign
dotMobi

Mobile

Sponsored by
dotMobi
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Afilias

DNS Security

Sponsored by
Afilias