How to Make Your Website Faster with IPv6

• The Internet backbone uses IPv6 and most client devices are IPv6-connected.
  
• The most popular websites use IPv6.
  
• Using IPv4 and IPv6 connectivity for websites makes them accessible by clients using either protocol.
  
• Client web browsers can choose whichever protocol connects faster.
  
• All public-facing applications should be configured to use IPv6 to take advantage of performance improvements resulting in better end-user experience.
  

 

Case for IPv6-Enabling Applications

Many website owners do not realize how extensively IPv6 is used today, and they have not given any consideration to their client’s perspective of the Internet.  A website developer should consider how their clients might connect to them using IPv4 and how IPv6 might change user experience.

IPv6 has now surpassed IPv4 to become the dominant protocol used on the Internet.  It is estimated that there are approximately four billion devices that access Google’s Internet applications, and their IPv6 Statistics indicate that 50% of them use IPv6.  APNIC’s IPv6 Capable Rate by country measurements show the number of IPv6 capable and IPv6 preferred nodes and their statistics estimate the number of IPv6-capable hosts to be about the same.  Another graphical view of the global IPv6 hosts now surpassing 50% can be found on IPv6Matrix.org.

Website owners should consider the different possibilities of their client’s connectivity and how that might result in performance degradation or improvement.  There are four primary scenarios for Internet application client/server connectivity that might occur.  The blue areas and blue lines represent IPv4, and the green areas and lines represent IPv6 connectivity.

All Possible IPv4/IPv6 Connectivity Cases

Case 1) IPv4-only (or dual-protocol) client <-> IPv4-only website

For an IPv4-only or dual-protocol client, if it only finds an IPv4 A-record via its DNS resolver then an IPv4 connection is the only option.  As a result, the client will attempt an IPv4 connection to the IPv4-only website which likely uses some form on Network Address Translation (NAT).  IPv4-only clients often pass through several NAT44 translators to reach legacy IPv4-only websites.  For clients connected to ISPs relying on Carrier-Grade NAT (CGN) there can be several different NATs along the transmission path.  There may be a NAT on their CPE device, there is a CGNAT in the ISP’s realm, there might be other proxy servers near the webserver, and possibly a NAT in the software container environment.  This could be written as NAT444 (or even NAT44444 in some extreme situations).

Case 1

It’s not that the individual NATs introduce any measurable latency, but it’s the backhaul of the traffic through the NAT that forces a less optimal path.  If the CGN is in a nearby city, then the client’s IPv4 traffic will suffer additional latency and packet loss related to congestion.  Over time there will be increased use of additional layers of NAT and CGN systems by ISPs and the overall IPv4 performance will get worse.

 

Case 2) IPv6-only client <-> IPv4-only website

For an IPv6-only node to communicate with an IPv4-only node, a protocol translation IPv6 transition mechanism is required.  An IPv6-only client often uses a DNS64 (RFC 6147) address synthesis process and then passes through a stateful NAT64 (RFC 6146) to reach legacy IPv4-only website.  The DNS64/NAT64 process is used if it is the target application’s FQDN DNS resolution only returns IPv4 A record.

Case 2

If the application does not rely on DNS and it has a hard-coded IPv4 address dependency, then the 464XLAT (RFC 6877) translation method could be used to facilitate the IPv6-only client reaching the IPv4-only website.  In this situation, the IPv6-only client’s IPv4-based connection goes through the local CLAT (customer-side translator) and is converted to an IPv6 connection.  Then a PLAT (provider-side translator) translates the IPv6 connection back to an IPv4 connection to reach the IPv4-only destination application.

The added backhaul through the stateful NAT64 or PLAT can introduce added latency to the connection to the IPv4-only website.  The NAT64 could be in a nearby city or across the country which would introduce many milliseconds of delay.

 

Case 3) Dual-protocol client <-> IPv6-enabled (dual-protocol) website

Now, if the destination website was configured with both IPv4 and IPv6 simultaneously, it would be accessible by any client using either Internet protocol.

Case 3

The dual-protocol client would send DNS queries for the A and AAAA records for the destination website and determine that it has IPv4 and IPv6 addresses.  When a dual-protocol client makes a connection attempt to a dual-protocol server it could be using Happy Eyeballs (HEv2 RFC 8305) using IPv4 and IPv6 in parallel and choose the best one.  Windows clients use Network Connectivity Status Indicator (NCSI) to determine IPv4 and/or IPv6 Internet reachability.  Apple devices use the NSURL objects to perform DNS lookups and make choices regarding IPv4 or IPv6 connections.  The aim of these methods is for the client to use whichever protocol is available and provides the fastest response.  DNS servers also perform this type of comparison of IPv4 and IPv6 and use whichever has a lower latency.

If the IPv4 connection is slower, because of NAT444, then IPv6 will have a lower latency and will be chosen, providing better customer experience.  However, if IPv6 is slower for some strange reason, and the IPv4 website is reachable, then IPv4 will be chosen.  If IPv4 and IPv6 are both available and they have similar performance, then client applications will default to using IPv6.  By making the webserver accessible over IPv4 and IPv6 the protocol chosen will be which is available and higher-performing from the client’s perspective.

 

Case 4) IPv6-only client <-> IPv6-enabled website

If a website uses IPv6, then it could be directly accessed by IPv6-only client devices.  Many mobile service providers have been connecting their subscribers and provisioning them as IPv6-only devices.  These Android and Apple mobile devices function as IPv6-only clients and connect directly to IPv6-enabled websites avoiding any translation.  This is the simplest best-path communication that results in the lowest latency and highest performance.

Case 4

There shouldn’t be any NAT taking place for IPv6 Internet connections.  Even though IPv6 NAT is rare, IPv6 NAT is feasible that it could exist in some isolated cases.

 

Measuring IPv6 Performance Improvement

When websites are accessible over IPv6, they experience better performance.  The amount of Round-Trip-Time (RTT) performance improvement varies based on the location of the client and where the measurement is taken.  Even a decade ago, IPv6 was measurably faster than IPv4 (on average) over the Internet (Part 1, Part 2).

APNIC maintains a site that shows their global measurements of IPv6 RTT improvement and they show this data broken out by country.  They subtract the IPv4 latency from the IPv6 latency, so a negative number of milliseconds means that IPv6 is faster than IPv4 by that amount.  In North America and Europe, there can be a five to ten millisecond performance improvement for IPv6 communications.  However, there are regions where the IPv6 performance is tens of milliseconds.

A few milliseconds may not sound like much, but this is multiplied by the number of objects fetched and rendered by the browser.  Some websites can have up to 100 RTTs, which would mean an IPv6-enabled website could load one or more seconds faster on an IPv6-enabled client.  However, in some geographies, an IPv6-only client could experience many seconds faster response when connecting to an IPv6-capable website.

It should also be mentioned that HTTP/2 (and Server Push) reduces the number of connections allowing browsers to fetch multiple objects with a single connection.  The use of QUIC is also used to optimize performance for websites and other applications. Regardless, there are still many round trips required to fetch all the objects on the page and IPv6’s lower average RTT is a benefit, even if it may seem small.

 

Today’s IPv6-Enabled Websites

Many websites now use IPv4 and IPv6 Internet connectivity and would be reachable by any client using either protocol.  Since World IPv6 Day (June 6, 2011) and World IPv6 Launch (June 6, 2012), many of the world’s most popular websites have been using IPv6.  Websites, like Google and Facebook, were early adopters of IPv6 and have charted the growth of IPv6 from their perspectives as more client devices used IPv6.

The Internet Society (ISOC) tracks the use of IPv6.  Cloudflare’s Radar site shows IPv6 usage from their global CDN perspective.  W3Techs also tracks the usage of IPv6 by websites and ranks that by popularity of the website.  From this graph, the more popular the website, the more likely it is to be using IPv6.

Papers have been published of research done on dual-protocol websites, their performance, and analysis of why connections to websites fail.  Towards a Non-Binary View of IPv6 Adoption, by Sulyab Thottungal Valapu, John Heidemann, October 9, 2025, shows a revealing sankey diagram and tabular breakdown of the Tranco top 100,000 websites, classified into IPv4-only, IPv6-partial, or IPv6-full.  IPv6 Adoption Across the Top 100,000 Web Hosts, by Thom Vaughan, March 16, 2026, documents a measurement study using the Common Crawl Web Graph finding 71% of the top 100 hosts support IPv6.  They also found that the more popular a website is the more likely it is to use IPv6.  They also found 1,212 hosts (1.2%) published AAAA records but failed reachability tests which could be a result of misconfiguration or firewall policy issues.

It is still surprising to see that many large organizations still have websites that are only accessible using IPv4.  Even though one might expect that these companies are tech-forward and have plenty of resources to keep their IT systems modernized, they are still lagging the majority.

 

Enabling IPv6 for Websites

With around two billion Internet IPv6-capable users and measurable performance penalties for IPv4-only websites, organizations should not compress their IPv6 deployment timelines any further and should IPv6-enable their websites immediately.

The steps for configuring IPv6 reachability to a website are easier than many realize.  It starts with IPv6-enablement of the application network environment.  Today, most cloud providers, service providers, hosting providers often furnish IPv6 connectivity.  IPv6 may not be enabled by default, so IPv6 will need to be turned on intentionally.  However, this is an easy task, and organizations really don’t have any excuse to have an IPv4-only website.

To configure a website with a global unicast IPv6 address the firewall and upstream routing path should have contiguous IPv6 Internet reachability.  The next step is to configure IPv6 on the first-hop router, or AWS VPC Subnet, or Azure VNet.  However, you don’t need to configure that router to send ICMPv6 Router Advertisements (RAs) to servers on the local segment.  The webserver doesn’t need a dynamic address from DHCPv6 or SLAAC and instead should have a static IPv6 address.  Configuration of the upstream firewall or AWS/Azure security group would be required to permit IPv6 connectivity to the webserver IPv6 address.  Once the IPv6 Internet connectivity is established, the next step is to configure an IPv6 AAAA record in your authoritative DNS server for the host’s FQDN.  Finally, testing IPv6 reachability from various Internet geographies will confirm it works as intended and measure the performance improvement.

A common approach is to utilize a dual-protocol reverse-proxy, server load balancer (SLB), or application delivery controller (ADC).  This could be an AWS ALB/NLB, an Azure Load Balancer, or Google Cloud Load Balancer.  Organizations should start implementing IPv6 at their Internet edge and leverage load balancers to help facilitate IPv6 reachability.

Another option is to use a Content Delivery Network (CDN) to IPv6-enable the website for the clients.  CDN providers like Cloudflare, Akamai, AWS CloudFront are all good choices and IPv6 connectivity is enabled by default for their customers.

The IPv6 enablement of a website is a much more attainable task than trying to transition an entire enterprise network to IPv6.  In fact, it could be performed during a sprint cycle if you are using an Agile methodology.  Whichever IPv6-enablement approach a website uses will result in overall faster response times for their clients and better experience for users.

 

Scott Hogg has over 30 years of network and security experience and is president of Hogg Networking (HoggNet.com). Scott Hogg specializes in teaching Internet Protocol version 6 (IPv6) and providing implementation guidance to large organizations. Scott is CCIE #5133 (Emeritus) and CISSP #4610.  Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF) and co-author of the Cisco Press book on IPv6 Security.