« Blog Home

Top Ways Web Properties Deploy IPv6 – with Pete Sclafani and Ed Horley

The Top Ways Web Properties Deploy IPv6 with Pete Sclafani and Ed Horley

When you roll out IPv6 for your web property, you have several options available depending on your technical level and preference. To recap and provide some context on the how and why, we teamed up with Ed Horley from Hexabuild, to talk shop and see how business realities reflect IPv6 deployment options.

Pete: So Ed – IPv6 is the future. Major enterprises and governments around the world are adopting the new protocol and incentivizing its use, and every single Internet registry strongly urges organizations to make the transition as soon as possible. Are you seeing a sense of urgency in your prospects or are enterprises still in the “IPv6 hasn’t arrived” mentality?

Ed: We see a mix and it really depends on the vision of the company. Do they see technology as a driving innovation force in their business or just an expense category? Those that are making strategic investments to use technology to out-innovate their competition and grow their businesses are very interested in how they can use IPv6 to do that. They understand the technical debt and limitations of IPv4 and also the lost market opportunity of not adopting IPv6 early enough. They get that it is a journey and they don’t have to do it overnight. We have seen an increase in interest from enterprises and the Fortune 1000 in adopting as a result.

Pete: Deploying IPv6 in a network can be…interesting depending on a variety of factors. Usually implementing some simple dual stack on the front end of your key web properties is an easy way to get started as it is targeted and may not even need to involve any of your core network hardware. Ed, when talking with your prospects/clients – what are some of the low hanging fruit regarding IPv6 deployment that they can tackle without having to go “all in”?

Ed: As you mentioned, the Internet edge is a great place to start getting key web services up and working with IPv6. After that, it depends on the use cases that each company is trying to solve for. If, for example, the company is trying to leverage IoT platforms, that might be the driver for broader IPv6 deployment. In some cases, it might be a public cloud and enabling that platform for customers to reach their services via IPv6. Many times, after doing that work they realize they need to monitor and test reaching those services on IPv6 and that expands the need for IPv6 on their internal network. The good news is they can do this incrementally, it doesn’t have to be done in a single upgrade or even as a single project.

Pete: That being said – let’s talk through a few common options for deploying IPv6 for web properties and see what we come up with in terms of implementation realities.

1. Add a AAAA record for your domain if you already have an IPv6 interface.

Ed: After enabling IPv6 from a network perspective and validating that it works to route out to the greater IPv6 Internet it is common to turn up a set of web services at the Internet edge. I typically start with DNS itself along with email. These services are much more graceful in regards to their failback and retry methods between IPv4 and IPv6. Once you have those services operational then setting up a AAAA record for your website makes a lot of sense. Once you do that, you can even test IPv6 only if you want.

Pete: This seems pretty straightforward and seems pretty sound. For the newly initiated – the Domain Name System (DNS) resolution process involves the translation of hostnames to their corresponding IP addresses, and two DNS record types are responsible for this conversion: A records and AAAA (or quad-A) records. An A record is the most basic type of DNS record – it translates a hostname to its corresponding IPv4 address. The AAAA record performs a similar task, but for IPv6 addresses. 

Since IPv4 is currently still the most widely used protocol, A records are the most prevalent worldwide. However, given the global trend toward the successor protocol, IPv6, version 6 will eventually become the new standard – and AAAA records will replace A records in due time. 

Adding a AAAA record for your domain will place you in the company of some of the world’s biggest content providers and other major players like Google, YouTube, Facebook, Wikipedia, Yahoo, Instagram, Blogspot, and Netflix. Currently, about 29% of Alexa Top 500 servers support IPv6 – check out our 2019 progress report here

By joining these ranks, your domain will be IPv6-capable and ready to serve all visitors, regardless of whether they’re using IPv4 or IPv6. Consider the fact that global IPv6 traffic has grown more than 5000% since 2012 – with the numbers only increasing – so adding IPv6 functionality with a AAAA record is certainly a forward-looking step to take.

2. Leverage a service like Cloudflare.

Ed: Cloudflare and other CDN’s provide a safe way of getting content accessible via IPv6. Many companies are leveraging CDN’s to deliver their IPv4 content and all of them make it easy to do the same for IPv6. One of the great advantages of Cloudflare is their “on by default” for IPv6. So existing Cloudflare customers are automatically providing their content via IPv6. This is a win for the businesses that leverage their service.

Pete: That seems simple enough especially if you get all the upsides with minimal technical hassles to worry about. I appreciate the IPv6 being a default setting as well, that’s a great way to check the box, but unfortunately still requires some other expertise to look at deploying IPv6 for other internal enterprise services.

If you’re not currently IPv6-ready in any other way, taking advantage of IPv6 support via a service like Cloudflare is a great temporary fix. With this solution, your site will be seen on both IPv4 and IPv6 networks, adding to the growing IPv6 content online and improving accessibility for all Internet users. As Cloudflare CEO Matthew Prince puts it, “If you can’t speak across the networks, that’s broken.”

3. Work with a conventional CDN (e.g. Akamai, Fastly). 

Ed: Even if you don’t have Cloudflare but instead are using another CDN they likely support IPv6, you might just have to go through the effort to turn it on. Typically, that is a simple toggle switch and you are up and going. Many of the older CDN services just didn’t have IPv6 enabled by default. It is a legacy issue, Cloudflare being younger could do that without issue. Older more established CDN’s had to be more careful since they had larger installed customers who could have been impacted by that sort of change. If you are a CDN user, take a moment to go enable IPv6.

Pete: I would also say that there are still plenty of providers that haven’t deployed IPv6 yet, so don’t be afraid to ask as well if it isn’t obvious. I know of one CDN that up until this year, would only enable IPv6 via a phone conversation/request from the customer – there was nothing in their portal advertising or documenting IPv6 support in an official capacity.

Thankfully, leading conventional CDNs have also recognized the benefits of using IPv6 to connect customers’ content to site visitors. Many of them may not offer the breadth of services or IPv6 offerings that Cloudflare does, but you’ll certainly be able to achieve IPv6 connectivity with any of a long list of CDNs, including Akamai and Fastly as well as smaller providers like BelugaCDN for those who need a more economical option.

As one of the oldest and largest global CDN providers, Akamai also offers web security and DDoS mitigation services and has supported IPv6 for many years. (For an interesting glimpse into IPv6 adoption trends across the globe through Akamai, check out their IPv6 Adoption Visualization.) 

Last year, Akamai published an overview of IPv6 content availability on Akamai, growth in client addresses, and end-user adoption of IPv6 versus IPv4. One notable statistic is that for dual-stacked hostnames, there is typically a higher average estimated throughput over IPv6 than over IPv4. Over half of dual-stacked hostnames – weighted by daily bytes delivered – have IPv6 estimated throughput at least 50% faster than IPv4, while a full 90% of these hostnames have IPv6 estimated throughput at least 10% faster than IPv4. The general trend, confirmed by results from Facebook, LinkedIn, and others, shows that IPv6 delivers significantly better performance.

Fastly is newer to the CDN scene but has gained momentum as a strong advocate for IPv6 adoption. In fact, Jason Evans of Fastly has written a detailed article on why it’s a good idea to enable IPv6 with Fastly and how to do configuration and testing; you can read it here

One of the primary advantages of using a CDN for IPv6 termination, as Evans writes, is to “reap the benefits of IPv6 seamlessly, without incurring the cost of overhauling backend infrastructure.” Of course, this solution may not be your end goal (and we do encourage everyone to work toward eventually achieving end-to-end native IPv6 connectivity), but it’s a step in the right direction. 

Where to Go From Here

The above methods are a good start for any organization looking to put an IPv6 face on an IPv4-only site. But if you’d like to go even further and you’re not well-versed in all things IPv6, check out our post titled “IPv6 and the Transition from IPv4, Explained” for a detailed outline of why the new protocol is needed, how the transition is taking place in the real world, and what to consider as you look toward an IPv6 future.

We realize there are some concerns you may have about making the switch to IPv6 – it’s a pretty complex undertaking, after all! – so to help you move forward with confidence, we’ve addressed the most commonly cited issues in a previous blog post here. As reviewed above – with IPv6, it doesn’t have to happen all at once. Leverage your DNS platform(s), communicate internally and pick some internal efforts to test out IPv6 first to start making progress.

And once you’re ready to make a full transition to IPv6 in your own organization, our “Six Steps to IPv6” guide can help you kick off your migration plan.