Celebrating IPv6 Day 2024

Reflecting on 25 years of IPv6: A journey from hype to hurdles

The 2024 year marks 25 years since I established my first IPv6 connection, using an IPv6 over IPv4 tunneling service from Hurricane Electric in the USA while I was working at The University of Western Australia in 1999.

It appeared that IPv6 was about to go mainstream back then, resolving some of the issues that had only become apparent with Vint Cerf’s 32-bit IPv4 networking as it reached global saturation. Software had to be changed, and hardware had to have new firmware to support this.

It has been a quarter of a century, and despite IPv6 being a good solution, I guess it's unlikely that we’ll ever take on another network address change like this, given the difficulty in getting this rolled out.

The sad thing is that there is no end date. As long as cheap IT hardware—typically—only supports IPv4 networking, we’ll have remnants stuck on IPv4.

Telco hesitation, ISP innovations, and cloud computing advancements 

Only a few telecommunications companies have invested in the engineering to deploy IPv6 for their customer base. Many have left their existing telco hardware in place without investing in upgrading to more modern networking. It's not broken, per se, but it's not ready for the future, so the appetite for change in those organizations is low.

Twenty years ago, my (then) local ISP in Australia had a strong engineering team and was making signs of supporting IPv6. With mergers and acquisitions, the engineering staff left, and the organization's most notable achievement was having an "IPv6 Blog." Meanwhile, their competition kept innovating—and I churned to use them and haven't looked back.

Also, 20 years ago, I subscribed to a Virtual Private Server (VPS, as they were called) with a UK provider to host my affairs. Their service offered IPv6, and it has worked flawlessly all these years.

I put a lot of effort into pushing for IPv6 support in AWS services while working at AWS. It would become a key competitive advantage, permitting clients to progress their plans to remove IPv4 from some or all of their networking requirements. Initially, this was for public-facing services, like load balancers. Still, even for internal services like VPC, it was abundantly clear that most clients would need more allocated subnets to accommodate wildly varying demands of private virtual machines in Amazon Elastic Compute Cloud (EC2).  

Many AWS services now support IPv6 for private and public connectivity on both the data and control planes. It’s not complete yet, but there are a few releases currently lined up that I am excited about.

Selling unused IPv4 address blocks

In the last five years, my colleagues and I assisted a public sector agency offloading one of the unused IPv4 address allocation blocks they had been given in the 1990s. They had no plans to use it: they already had a small amount of another block in use, and the way their digital services were going, they were using hyperscalar Cloud-based IP addresses for most services, including DNS (which is typically what you care about having your own address space for – hosting your own DNS). 

With many of the hyperscalar provider DNS services, like Amazon Route53, having itself supported IPv6 records (AAAA) and being reachable using IPv6, then the effort to set up one’s own routing to multiple providers and running (and patching) your own DNS server seems like “undifferentiated heavy lifting.”

The market for legacy IPv4 address blocks continues to boom: for larger contiguous blocks (e.g., a “slash 16” or “/16”, which has 65 thousand IP addresses in one contiguous block, was $21 per address, has kept rising. Likewise, some cloud providers have started adding specific charges for clients that use publicly routable IPv4 addresses from their provider pool, encouraging appropriate use. As these costs and values continue to rise, eventually, there should be a tipping point whereby IPv6 becomes dominant, and the value falls out of the IPv4 resell market.

Visualizing IPv6 adoption

Google has some great information publicly available showing their view of IPv6 adoption by the world. That doesn’t mean it is correct – not everyone in the world uses Google -- but it’s a useful indicator. 

What’s interesting is that, for the most part, Google sees Internet traffic as marginally faster over IPv6 than IPv4. Some of these countries are quite well progressed into IPv6 adoption:

• Germany: 73.22%
• France: 75.26%
• India: 70.88%
• Belgium: 61.53%
• Greece: 61.04%
• Malaysia: 66.71%
• Saudi Arabia: 63.32%

Adopting IPv6 in your home

Your ability to adopt IPv6 will hinge upon the hardware (and software) you use and your provider's ability to enable IPv6.

Your mobile phone (or mobile enabled iPad and similar hardware) probably supports IPv6, if the wireless/cell provider supports it. It could be that they support it for some clients, based upon plan. I’ve seen access to IPv6 connectivity based upon configurations such as mobile APN (Access Point Name), as well as having a new physical SIM card issued that then enabled IPv6. Ask your mobile phone provider if they are supporting IPv6 for their consumer services and, if not, when they plan to.

Your home Wi-Fi router may support IPvb6; if it doesn’t, you probably have the cheapest, nastiest device that works. If that’s the case, you probably have support only for older Wi-Fi standards as well, and worse – you may have vulnerabilities in the Wi-Fi security that have not been patched. Depending on the vendor and their support approach, you may never get an update for these vulnerabilities – as was the case with my previous Australian ISP and their client Wi-Fi router devices. If you buy your own routers, you are the customer, not the ISP.

I was chatting with an agent from a federal cyber security agency a while back, and we discussed how one of the biggest cybersecurity risks in modern society is a slew of unsupported, out-of-date consumer devices like these home Wi-Fi routers. While they technically do work, they aren’t up to date.

Adopting IPv6 in your organization

Implementing support can be found in many places, including Office equipment, end-user computing, and “server-side” services and solutions your organization uses.

If your organization uses third-party hosted SaaS applications and services, you should ask those providers if they support IPv6. If you know the service hostname, then you can try an IPv6 lookup for that hostname using DNS. Using these commands (works from Windows CMD shell):

You can try the above with the query type “A,” which is the older IPv4 type. If you get a valid address for both queries, then the hostname is “dual stack.”

(The amusing part is that the “A” record type is for 32-bit IPv4 address space, but “AAAA” is for 128-bit, which is four times the size of 32, i.e., 4 x A, and 4x32=128)

Printers, VoIP phones, and other devices on people’s desks may be IPv6 capable; the manufacturer of those devices can guide each. If not, consider hardware with contemporary capabilities when they are due for replacement.

Ethernet switches and routers in your organization are likely capable; they just haven't been configured (yet). Get on to them. Work out how you’ll propagate and protect addresses.

Planning your deployment

Planning the rollout is important. Take small steps at a time and avoid one-way doors—steps that are not easily reversible.

If you supply digital solutions to your clients, dual-stack enabling the external-facing endpoints is a crucial first step. Your website is critical to start with, and you can use your data from logs to determine what percent of your clients are using IPv6.

Then, work your way through updating any other external-facing endpoints you have. 

Be sure to work with your suppliers and integration partners with whom you exchange data and see if they are ready to step up as well. Your digital solutions may connect outbound to them, or they may connect inbound to you.

For your corporate office locations, my recommendation is to start with IPv6 for the external-facing services first. Start with an IPv6 allocation from your corporate Internet Service Provider, and with a routable subnet, assign addresses to the interfaces that are supposed to be public-facing.

One of my favorite stops is to have any corporate Proxy servers with external interfaces upgraded to enable IPv6, instantly making all internal IPv4 clients able to request URLs that come from IPv6 sources. It's key to check that the configured DNS resolver for your proxy can perform AAAA DNS record resolution. 

If you have a mobile workforce and provide them with phones or mobile access points, ask your TelCo/Wireless provider if they can configure or enable IPv6 on your fleet side-by-side to IPv4.

Getting help

At Akkodis, we have been implementing IPv6 dual-stack solutions for clients for more than five years. It has never incurred additional costs or complexity, and it has never been a security risk. We account for IPv6 in our bespoke development services and our manager IT operations services. It’s not new or different from anything else we do.