IPv6-Only Users: The Hidden Downtime You Might Miss

Your uptime report says 99.99%. Your customers say they cannot reach your site. Both statements are true at the same time, and the explanation is simple: your monitoring checks IPv4, and your customers are on IPv6. This is not a hypothetical scenario. It is happening right now to businesses that have not updated their monitoring to reflect how the modern internet actually works.

The shift to IPv6 is not a future event. It is already the present for hundreds of millions of internet users. And for a growing number of them, IPv6 is not just preferred -- it is the only protocol available. If your service fails on IPv6, these users experience complete downtime, and your monitoring system will not tell you about it.

The Scale of IPv6-Only Internet Access

Understanding who is affected requires looking at how internet access has evolved over the past decade. The exhaustion of IPv4 address space forced ISPs and mobile carriers to find alternatives, and IPv6 deployment has been the primary solution.

Mobile carriers leading the transition

The most aggressive IPv6 adoption has come from mobile networks. Major carriers in key markets have moved to IPv6-only or IPv6-preferred connectivity for their mobile subscribers:

• United States: T-Mobile reports over 90% of its traffic on IPv6. Verizon Wireless and AT&T both exceed 70%. Most smartphone users on these networks connect via IPv6 by default.
• India: Reliance Jio, which serves hundreds of millions of subscribers, operates an IPv6-only mobile network with NAT64/DNS64 for backwards compatibility with IPv4 services.
• Europe: Deutsche Telekom, Sky Broadband UK, and other major ISPs have rolled out IPv6 to residential and mobile customers at scale.
• Brazil: Major carriers including Claro and Vivo have deployed IPv6 across their mobile networks.
• Japan and Southeast Asia: NTT, KDDI, and regional carriers in Vietnam, Thailand, and Malaysia have significant IPv6 deployment.

Google's IPv6 adoption statistics show that globally, over 45% of connections to Google services use IPv6. In the United States, this figure is above 50%. In India, it exceeds 70% during peak mobile usage hours. These are not projections; these are current, measured numbers.

IPv6-only networks with NAT64

Many of these carriers operate what are called IPv6-only networks with NAT64. In this architecture, the user's device has only an IPv6 address. When the user tries to access an IPv4-only service, the carrier's NAT64 gateway translates the traffic from IPv6 to IPv4 on behalf of the user.

This means:

• If your service has both IPv4 and IPv6, users connect natively via IPv6. No translation is needed, and the connection is direct and fast.
• If your service is IPv4-only, users connect via NAT64 translation. This adds latency, uses carrier resources, and introduces an additional point of failure.
• If your service has a broken IPv6 endpoint (AAAA record exists but the server does not respond), the user's device tries IPv6 first, waits for a timeout, and then falls back to IPv4 via NAT64. This fallback can take 10-30 seconds, creating a terrible user experience even if the site eventually loads.

The third scenario is the worst of all worlds. Having no IPv6 at all is better than having broken IPv6, because a missing AAAA record lets the client go directly to IPv4 via NAT64 without the timeout delay. A broken AAAA record forces the client to wait for a timeout on IPv6 before falling back.

Why Your Monitoring Misses IPv6 Downtime

If your uptime monitoring only checks IPv4, it operates in a parallel reality from your IPv6 users. Here is exactly how this blind spot forms:

Default monitoring behavior

Most monitoring tools, when given a domain name like example.com, resolve it and connect via whichever protocol the monitoring server's OS prefers. On most Linux servers, this defaults to IPv4. Some tools explicitly resolve only the A record and never query for AAAA. Unless you have deliberately configured separate IPv6 monitors, your monitoring system is testing only the IPv4 path.

The dashboard shows 100% while users cannot connect

Consider this timeline:

1. Your server's IPv6 interface goes down at 2:00 AM due to a firewall rule change.
2. Your monitoring system checks the site every minute via IPv4. Every check returns 200 OK.
3. At 6:00 AM, mobile users in India (IPv6-only network) start trying to access your service. They get connection timeouts.
4. At 7:00 AM, users in the US on T-Mobile (IPv6-preferred) experience the same issue.
5. At 9:00 AM, your support team arrives and sees a clean dashboard and a queue of angry tickets.
6. At 10:00 AM, someone thinks to check IPv6 and discovers the firewall issue.

Eight hours of downtime for a significant portion of your user base, completely invisible to monitoring. This is not theoretical downtime cost -- it is real revenue loss.

The "works for me" problem

When the support team tries to reproduce the issue, they load the site from their office network. It works. They try from their phones on office Wi-Fi. It works. They try from their personal laptop at home. It works. Because all of these tests happen over IPv4 (office networks, Wi-Fi, residential broadband), and the issue is IPv6-only. Read more about this phenomenon in our guide to checking if your site is down for everyone or just you.

Types of IPv6-Specific Failures

IPv6 downtime is not just one type of failure. Multiple infrastructure components can fail independently for IPv6:

DNS failures

• Missing AAAA record: No IPv6 address published. Users go through NAT64 (slower but functional).
• Stale AAAA record: Points to a decommissioned IPv6 address. Users experience timeout, then slow NAT64 fallback.
• DNS server unreachable over IPv6: If your authoritative DNS server is not reachable over IPv6, some resolvers may fail to query it for AAAA records.

Firewall and security group failures

• ip6tables not configured: IPv6 packets dropped at the OS firewall level.
• Cloud security group missing IPv6 rules: AWS, GCP, and Azure security groups require explicit IPv6 CIDR entries (::/0).
• DDoS mitigation blocking IPv6: Some DDoS protection services do not fully support IPv6 traffic filtering, causing legitimate IPv6 traffic to be dropped during mitigation.

Web server configuration failures

• No IPv6 listener: Web server configured with listen 443 ssl; but missing listen [::]:443 ssl;.
• SSL certificate not served on IPv6: The HTTPS listener exists but does not have the correct certificate attached.
• Virtual host mismatch: IPv6 requests fall through to the default virtual host, returning wrong content or 404.

CDN and load balancer failures

• CDN edge not configured for IPv6: The CDN publishes an AAAA record but the edge server does not serve your content on IPv6. See our detailed article on IPv6 and CDN failures.
• Load balancer IPv6 listener disabled: Cloud load balancers may need separate configuration for IPv6 listeners.
• Health checks IPv4-only: The load balancer checks backend health over IPv4 and does not detect IPv6-specific backend failures.

Routing and transit failures

• ISP IPv6 peering issues: Your server's IPv6 route to certain ISPs may be down while IPv4 routes remain healthy.
• BGP route leak: An IPv6 routing incident can make your server unreachable from specific networks or regions.
• Tunnel failures: Some networks still rely on IPv6 tunneling mechanisms that add fragility.

The Business Impact of Hidden IPv6 Downtime

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

Lost mobile traffic

Mobile users represent the majority of web traffic globally. In many markets, mobile users are predominantly on IPv6. If your site is down for these users, you are losing a disproportionately large segment of your potential audience. For e-commerce sites, this directly translates to lost sales. For SaaS platforms, it means failed logins and churned users who blame your reliability.

SEO impact

Googlebot has been crawling over IPv6 for years. If your IPv6 endpoint is intermittently down, Googlebot may encounter errors when crawling via IPv6, potentially affecting your crawl budget and indexing. While Google has not confirmed that IPv6 reachability directly affects rankings, crawl errors from any source can reduce how frequently and thoroughly your site is crawled.

Misleading uptime SLAs

If you report uptime to customers based on IPv4-only monitoring, your reported SLA may be significantly higher than the actual availability experienced by a portion of your users. This creates a credibility gap. When a customer says "your service was down for 3 hours" and you say "our monitoring shows 100% uptime," neither side trusts the other.

Delayed incident response

Without IPv6 monitoring, the time between an IPv6 failure and its detection depends entirely on how quickly users complain. If the affected users are in a different timezone, it could be hours before anyone reports the issue. Compare this to automated monitoring that detects the failure within minutes and alerts your on-call team immediately. Use our Downtime Cost Calculator to estimate the cost of delayed detection.

How to Detect IPv6-Only Downtime with UptyBots

UptyBots is built for exactly this kind of protocol-specific monitoring. Here is how it addresses each dimension of the problem:

Setting up dual-stack monitors takes only a few minutes. See our step-by-step guide to creating separate IPv4 and IPv6 monitors for detailed instructions.

Quick Verification: Is Your IPv6 Working Right Now?

Run these commands from your local machine to check your IPv6 status:

# Check if your domain has an AAAA record
dig AAAA yourdomain.com +short

# Test IPv6 HTTP connection
curl -6 -I https://yourdomain.com

# Test IPv6 ping
ping6 yourdomain.com

# Compare IPv4 vs IPv6 response times
curl -4 -w "IPv4: %{time_total}s\n" -o /dev/null -s https://yourdomain.com
curl -6 -w "IPv6: %{time_total}s\n" -o /dev/null -s https://yourdomain.com

If any of these fail while the IPv4 equivalent works, you have an IPv6-specific issue that needs attention. See our guide on diagnosing IPv6 failures with ping, traceroute, and DNS tools for a complete troubleshooting workflow.

What You Should Do Today

1. Audit your current monitoring. Do you have separate IPv6 monitors, or is your monitoring IPv4-only? If you are not sure, it is almost certainly IPv4-only.
2. Add IPv6 monitors. For every critical endpoint you monitor over IPv4, create an equivalent IPv6 monitor. Match the check type (HTTP, ping, port, SSL) and interval.
3. Check your infrastructure. Verify that your web server, firewall, load balancer, and CDN all correctly serve IPv6 traffic. Do not assume that because you enabled IPv6 once, it still works.
4. Set up alerts. Configure notifications so that IPv6 failures reach your on-call team immediately, not hours later through customer complaints.
5. Review regularly. Any infrastructure change (firewall rules, load balancer config, CDN settings, server migrations) can break IPv6 even if IPv4 is unaffected. Re-verify after every change.

The hidden downtime problem is real, it is growing as IPv6 adoption accelerates, and it is entirely preventable with proper monitoring. The businesses that add IPv6 monitoring today will catch outages that their competitors are silently losing customers to. The businesses that wait will continue to see perfect uptime dashboards while their real-world availability tells a different story.

For more context on why both protocols need independent tracking, read why monitoring IPv4 and IPv6 separately matters.

See setup tutorials or get started with UptyBots monitoring today.