IPv6-Only Users: The Hidden Downtime You Might Miss

Your monitoring dashboard shows 100% uptime. Your status page is green. Your customers seem happy. But somewhere out there, a growing number of users cannot reach your website at all. They are on IPv6-only networks, and your site is silently broken for them. You do not see it because your monitoring checks only IPv4.

This is hidden downtime: outages that exist for a segment of your users but remain invisible to your standard monitoring setup. It is one of the most common blind spots in modern infrastructure, and it is becoming more costly every year as IPv6 adoption accelerates worldwide.

What Are IPv6-Only Networks?

An IPv6-only network is one where devices receive only IPv6 addresses and cannot use IPv4 natively. To reach IPv4-only servers, these networks rely on transition mechanisms like NAT64 and DNS64, which translate IPv6 requests into IPv4 connections. When these mechanisms work, the user does not notice the difference. When they fail or when your server has a broken IPv6 configuration, the user gets a timeout or error page.

IPv6-only networks are more common than most people realize:

T-Mobile US: One of the largest mobile carriers in the United States, T-Mobile has operated an IPv6-only mobile network since 2014. Over 90% of their mobile traffic uses IPv6, with NAT64/DNS64 for IPv4 fallback.
Reliance Jio (India): With over 400 million subscribers, Jio deployed an IPv6-only network from day one. India now leads the world in IPv6 traffic volume.
SK Telecom (South Korea): Major Korean carriers have shifted to IPv6-only for mobile data, with IPv4 available only through translation.
Corporate networks: Large enterprises like Facebook, Microsoft, and Apple run internal IPv6-only networks. Employees accessing external services go through NAT64.
Cloud-native environments: AWS, Google Cloud, and Azure offer IPv6-only subnets for cost savings and simplified networking.
University and research networks: Many academic institutions have moved to IPv6-only as part of network modernization programs.

How Hidden Downtime Happens

There are several common scenarios where IPv6-only users experience downtime while IPv4 users browse happily. Understanding these scenarios helps you audit your own infrastructure for potential blind spots.

Scenario 1: Missing or Stale AAAA Records

Your domain has an A record pointing to the correct IPv4 address, but no AAAA record at all. IPv6-only users rely on DNS64 to synthesize an IPv6 address from your A record, routing traffic through NAT64. This usually works, but adds latency and introduces a single point of failure at the NAT64 gateway. If the gateway is overloaded or down, your site is unreachable.

Worse: if you once had a AAAA record but removed it (e.g., during a server migration), some DNS resolvers may still cache the old IPv6 address. Users connecting to the stale address get Connection refused or a timeout, depending on whether the old server is still online.

Scenario 2: Firewall Rules Missing IPv6

You configured your server firewall carefully for IPv4: allow ports 80, 443, and SSH; block everything else. But you forgot that iptables and ip6tables are separate rule sets. Your IPv6 firewall is either wide open (a security risk) or completely closed (blocking all IPv6 traffic). The latter creates a situation where ping6 fails, curl -6 times out, and IPv6-only users see nothing.

A particularly dangerous variant: blocking ICMPv6 entirely. Unlike IPv4, where blocking ICMP is a debatable security measure, blocking ICMPv6 breaks fundamental IPv6 operations including Path MTU Discovery and Neighbor Discovery. Large HTTP responses (like your homepage with images) may fail while small responses (like a health check endpoint) succeed. Your monitoring says "up" because it checks a lightweight endpoint, while real users cannot load the full page.

Scenario 3: Web Server Not Listening on IPv6

Your server has an IPv6 address. DNS resolves correctly. The firewall allows traffic. But your Nginx or Apache configuration only binds to the IPv4 address. The relevant configuration lines:

Nginx (broken): listen 80; and listen 443 ssl; only bind to IPv4.

Nginx (correct): Add listen [::]:80; and listen [::]:443 ssl; to bind to IPv6 as well.

Apache (broken): Listen 80 without specifying Listen [::]:80 on systems where the two are separate.

This is easy to miss because many server setups default to dual-stack (listening on both protocols). But if you manually configure virtual hosts or use container-based deployments, the IPv6 listener can be omitted without any error or warning.

Scenario 4: CDN or Load Balancer IPv6 Gap

You use a CDN (Cloudflare, AWS CloudFront, Fastly) for your main domain, which handles IPv6 automatically. But your API runs on a separate subdomain pointing directly to an origin server without IPv6. Mobile apps using the API over an IPv6-only carrier fail, while browser users on the CDN-fronted domain work fine.

Similarly, some load balancers support IPv6 on the frontend but only forward traffic to IPv4 backends. If the load balancer fails or is misconfigured, IPv6 users lose access while IPv4 users continue through a different path.

Scenario 5: SSL/TLS Certificate Issues over IPv6

Your SSL certificate is configured correctly for IPv4 connections but the IPv6 virtual host serves a different certificate (or the default self-signed one). Users on IPv6-only networks see a browser security warning or the connection is rejected entirely. This happens when you have multiple virtual hosts and the IPv6 one does not have the correct ssl_certificate directive.

Why Standard Monitoring Misses This

Most monitoring services check your website over IPv4 by default. When you add a target, the monitoring system resolves your domain to an A record (IPv4) and connects to that address. The AAAA record (IPv6) is never queried, and the IPv6 path is never tested.

This creates a dangerous false sense of security. Your dashboard says 99.99% uptime. But for the 10%, 20%, or even 50% of your users who connect over IPv6, the actual uptime could be significantly lower. You are measuring only half of your infrastructure.

Even if your monitoring tool supports IPv6, many administrators never configure separate IPv6 checks. They assume that if IPv4 works, IPv6 works too. This assumption is wrong because the two protocols use completely different network paths, firewall rules, DNS records, and sometimes different server configurations.

The Real Business Impact

Hidden IPv6 downtime is not just a technical curiosity. It has measurable business consequences:

Lost Revenue

If your e-commerce site is unreachable for IPv6-only mobile users in India (Jio) or the US (T-Mobile), you are losing potential customers during every outage. These are not obscure edge cases. T-Mobile alone has over 100 million subscribers, and Jio has over 400 million. Even a 1-hour outage affecting these networks represents massive lost opportunity. Use our Downtime Cost Calculator to estimate the financial impact for your business.

SEO Degradation

Google crawls websites over both IPv4 and IPv6. If your site responds slowly or returns errors over IPv6, Googlebot may record higher error rates, slower response times, or reduced crawlability. Over time, this can negatively affect your search rankings. The effect is subtle and hard to diagnose because Google does not tell you which protocol it used for a specific crawl.

Customer Trust and Support Burden

Users on IPv6-only networks who cannot reach your site do not know it is an IPv6 issue. They see a generic timeout or error page. Many will contact your support team. Some will leave and never come back. Your support team cannot reproduce the issue because their office network uses IPv4. Everyone is confused, and the root cause remains hidden until someone thinks to check IPv6.

SLA Violations

If your SLA promises 99.9% uptime but you only measure IPv4, you may be in technical compliance while delivering significantly less reliability to a subset of users. As IPv6 adoption grows, customers and auditors may start asking whether your uptime metrics include IPv6. Being unable to answer confidently is a red flag.

How to Detect Hidden IPv6 Downtime

The first step is acknowledging that IPv6 monitoring requires separate, dedicated checks. Here is a practical approach:

1. Audit Your DNS Records

For every domain and subdomain you operate, check whether AAAA records exist and point to valid, current IPv6 addresses. Use dig AAAA yourdomain.com +short to verify. If you intend to support IPv6, the records must be accurate. If you do not intend to support IPv6, remove the AAAA records entirely so that IPv6-only users go through NAT64 cleanly instead of trying to connect to a broken address.

2. Set Up Separate IPv6 Monitoring

In UptyBots, create dedicated monitoring targets for your IPv6 endpoints. Do not rely on a single check that might use either protocol. Create explicit IPv4 checks and explicit IPv6 checks for each critical domain. This gives you independent uptime statistics, separate alert thresholds, and clear visibility into protocol-specific issues. For a broader perspective on dual-stack monitoring, read why monitoring both IPv4 and IPv6 matters for modern websites.

3. Compare IPv4 vs IPv6 Metrics

Once you have both checks running, compare response times, uptime percentages, and error patterns between the two protocols. Consistent differences (e.g., IPv6 always 50 ms slower) indicate routing or configuration issues worth investigating. Intermittent IPv6 failures that do not appear on IPv4 point to protocol-specific problems like firewall rules or server binding issues.

4. Test Manually When Alerts Fire

When UptyBots alerts you to an IPv6 failure, use command-line tools for deeper investigation. Run ping6, traceroute6, and curl -6 to pinpoint whether the issue is at the DNS, network, firewall, or application layer. For a detailed guide on manual testing workflows, see how to test IPv6 connectivity manually and compare results with automated monitoring.

5. Monitor SSL Over IPv6

Set up SSL certificate monitoring that tests the certificate over IPv6 connections specifically. A valid certificate on IPv4 does not guarantee the same certificate is served on IPv6. Use our SSL Expiry Countdown tool to check your certificate status right now.

Prevention Checklist

Use this checklist to prevent hidden IPv6 downtime before it affects your users:

Publish AAAA records for all domains that should be reachable over IPv6
Configure web servers to listen on both IPv4 and IPv6 (listen [::]:443 ssl; in Nginx)
Mirror iptables rules in ip6tables (or use nftables which handles both)
Allow ICMPv6 types 1-4 and 128-129 in your firewall
Verify CDN and load balancer IPv6 support for every domain, including API subdomains
Ensure SSL certificates are served correctly on IPv6 virtual hosts
Set up separate IPv4 and IPv6 monitoring targets in UptyBots
Compare IPv4 and IPv6 response times weekly and investigate significant gaps
Include IPv6 in your deployment checklist for new servers and services
Test from an IPv6-only network (e.g., mobile carrier data) after every infrastructure change

The IPv6 Adoption Curve Is Not Waiting

IPv6 adoption is not a future concern. It is happening now. Google reports over 45% of their global traffic arrives over IPv6. In India, France, and the United States, it exceeds 50%. Major mobile carriers have already committed to IPv6-only networks. Cloud providers are pushing IPv6-only deployments for cost efficiency.

Every month that passes without IPv6 monitoring is a month where you might be losing users, revenue, and search rankings without knowing it. The fix is straightforward: add IPv6 monitoring targets alongside your existing IPv4 checks, review the results regularly, and investigate any discrepancies.

For more on the common failures that IPv6 monitoring catches, read common IPv6 connectivity issues and how monitoring detects them.

See setup tutorials or get started with UptyBots monitoring today.