IPv6 Reachability Monitoring: Dual-Stack Done Right

Half the user base is currently not being measured

Google has been measuring the share of its own users reaching the service over native IPv6 continuously since 2008. The curve has more than quadrupled in ten years: the annual mean was 11.0 percent in 2016, 29.9 percent in 2020, 43.4 percent in 2024 and 47.0 percent so far in 2026 (Google, IPv6 Adoption Statistics). The daily series is more revealing than the annual mean: on 28 March 2026 a daily value above 50 percent was recorded for the first time at 50.1 percent, and it has happened on several days since, most recently at 50.9 percent on 18 July 2026 (Google, IPv6 Adoption Statistics).

A second, methodologically independent series comes from APNIC Labs, the research arm of the Regional Internet Registry for the Asia-Pacific region. It does not measure access to a single service but uses distributed measurement campaigns to establish what share of end devices can use IPv6 at all, and what share actually prefers IPv6 when both protocol versions are on offer. Globally, 41.9 percent of users are IPv6 capable and 40.0 percent prefer IPv6 (APNIC Labs, IPv6 Capability Measurement, as of 21 July 2026). For Germany the figures are 72.1 percent IPv6 capable and 71.1 percent IPv6 preferring (APNIC Labs, IPv6 Capability Measurement). Two surveys, two methods, one conclusion: in Germany the IPv6 path is the normal case, not the exception.

The share also varies systematically across the week. Over the last 90 days the global daily value averaged 50.1 percent on Saturdays but 46.3 percent on Tuesdays (own analysis of the published daily values, Google, IPv6 Adoption Statistics). The explanation is straightforward: residential lines in Germany are largely dual stack, many corporate networks are not. For a shop with evening and weekend business that means the IPv6 share peaks precisely in the highest-revenue time slots — which is also when a one-sided outage is most expensive.

Dual stack: one hostname, two entirely separate paths

IPv6 has been an Internet Standard since July 2017 (IETF RFC 8200, STD 86) and does not replace IPv4, it runs alongside it. Under dual stack the same hostname carries two kinds of address in DNS: an A record with a 32-bit IPv4 address and an AAAA record with a 128-bit IPv6 address. Which of the two paths a client tries first is the client's decision. From the DNS answer onwards the two paths are technically independent: they can traverse different routers, pass different firewall rules, terminate on different load balancers and, in the worst case, be answered by different server processes.

The economic pressure behind this shift comes from address scarcity. The RIPE NCC allocated the last of its freely available IPv4 pool on 25 November 2019; since then members can only obtain a single /24 from recovered space via a waiting list (RIPE NCC, IPv4 Run-out). New access networks — mobile first — are therefore built IPv6 first, with IPv4 supplied through translation mechanisms. For website operators that reverses the burden of proof: IPv6 is no longer the special case you test occasionally, IPv4 is increasingly the path that is provided synthetically.

One uncomfortable consequence follows: every layer can break on one side only, and every one-sided fault is invisible to an IPv4 measurement. Anyone already monitoring DNS propagation across several resolvers has the first building block in place — the extension is to treat AAAA as rigorously as A. In DNS and domain monitoring both record types belong in the same target-versus-actual comparison.

Happy Eyeballs v2 hides faults and costs load time

To keep users from noticing a broken IPv6 path, browsers and operating systems use a procedure the IETF standardised in December 2017 as RFC 8305 under the name Happy Eyeballs Version 2. The client issues the AAAA query first and the A query immediately afterwards; it is not supposed to wait for both answers but to treat name resolution asynchronously (IETF RFC 8305, section 3). If the AAAA answer arrives first and contains at least one valid record, the first IPv6 connection attempt starts immediately.

The client then sorts all addresses received so far using destination address selection from RFC 6724 and interleaves the address families so that the first IPv4 address follows the first IPv6 address (IETF RFC 8305, section 4). Connection attempts then run on a staggered schedule. Four timing values determine how long a broken IPv6 path holds up the connection:

• Resolution Delay — 50 milliseconds. If the A answer arrives before the AAAA answer, the client waits this long so that IPv6 keeps its preference (IETF RFC 8305, section 3).
• Connection Attempt Delay — 250 milliseconds. The recommended default gap between two connection attempts. It must not fall below 10 milliseconds, and 100 milliseconds is the recommended lower bound (IETF RFC 8305, section 5).
• Maximum Connection Attempt Delay — 2 seconds. The upper bound for that gap, relevant when an implementation derives it from historical round-trip times (IETF RFC 8305, section 5).
• Last Resort Local Synthesis Delay — 2 seconds. In IPv6-only networks, how long the client waits before giving up on the AAAA addresses it received and synthesising a substitute from the A record (IETF RFC 8305, section 7.2).

A simple implementation can have a fixed delay for how long to wait before starting the next connection attempt. One recommended value for a default delay is 250 milliseconds.

— IETF RFC 8305, Happy Eyeballs Version 2, section 5

The mechanism does exactly what it was designed to do: it hides a fault from the user. Operationally that is treacherous. A server that refuses IPv6 connections on port 443 does not produce an error page, it produces a delay. If the far side answers with an immediate TCP reset the penalty stays small. If a firewall silently drops the packets instead, the client waits out the full stagger. And the effect applies per connection target: a page that loads assets from three of your own hostnames and has the same defect on each pays the penalty several times over — with a direct effect on the page's loading metrics.

Five patterns that hit exactly one protocol version

One-sided faults rarely arrive with fanfare. They appear during migrations, rule-set clean-ups, proxy updates and certificate changes — routine work after which the IPv4 check stays green and nobody looks further. The following patterns cover most of the cases we encounter in operations projects (project experience).

A typical real-world finding looks like the diagram above: HTTP status and certificate are identical across both protocol versions, but over IPv6 the request runs through two redirects instead of one, one of them over unencrypted HTTP, two of six security headers are missing, and the 95th percentile response time sits at 740 milliseconds instead of 182 milliseconds (project experience). None of these three points triggers an alert over IPv4. Together they add up to a measurably worse experience for a substantial share of visitors. How to quantify such differences cleanly is covered in the article on response time percentiles p95 and p99.

IPv6-only networks, NAT64 and the broken AAAA record

In mobile networks dual stack is frequently no longer the operating model. The device receives IPv6 only, and access to IPv4 destinations runs through a combination of NAT64 (IETF RFC 6146) and DNS64 (IETF RFC 6147): the network's resolver synthesises AAAA answers pointing at a translation prefix for names that have no AAAA record, and a translator in the network converts the packets to IPv4. Many platforms additionally implement 464XLAT (IETF RFC 6877) so that applications relying on fixed IPv4 addresses keep working.

To perform that synthesis the client has to know the network's translation prefix. It discovers it using the procedure from IETF RFC 7050 and builds the address according to the encoding rules in IETF RFC 6052. Both work for names only, not for IPv4 addresses hard-wired into configurations, scripts or security policies. Anyone placing an IPv4 literal in a content security policy, an API base URL or a form action is building in a spot that depends on extra translation steps in IPv6-only networks.

• Do not publish an AAAA record that is not reachable. A name without AAAA works in IPv6-only networks via DNS64; a name with a broken AAAA does not (IETF RFC 6147, section 5.1.1).
• Check subdomains and third-party systems too. Image, asset, API and form hostnames often carry their own record sets — and get reviewed far less often than the main domain during migrations.
• Remove IPv4 literals from configurations. Names instead of addresses keep the translation mechanism intact and avoid special handling in the client (IETF RFC 8305, section 7.1).
• Treat mobile networks as their own test case. A request from a mobile network with Wi-Fi switched off is the simplest available test for the IPv6-only case and surfaces faults that stay invisible in the office network.

What needs checking separately per protocol version

The basic rule is simple: anything that can happen between client and response can differ between the protocol versions — and therefore has to be recorded per version in its own right. A combined check that picks some path internally ends up producing a status value that has lost the decisive piece of information.

Two of these points deserve separate attention because they cause trouble even without an IPv6 angle: redirect chains and TLS configuration. The article on redirect chains and their side effects describes the basic pattern, and the article on hardening TLS cipher suites covers the checkpoints at the encryption layer. Running both checks twice — once over IPv4, once over IPv6 — is the actual work, and it stays manageable as soon as the probe can force the address family.

Practice 1: an inventory of every hostname with and without AAAA

Before alerts make sense there has to be an inventory. The question is not "is our website reachable over IPv6?" but "which of our hostnames have an AAAA record, which do not, and is that intentional in each case?". In our experience this step alone surfaces half the later findings (project experience), because secondary domains, asset hosts and legacy systems rarely receive the same care as the main domain.

1. Collect hostnames. Main domain with and without www, shop and login subdomains, asset and image hosts, API endpoints, mail hosts, status and support systems, plus every name from certificates carrying multiple SAN entries.
2. Query A and AAAA per hostname. From at least two independent resolvers, so that a cache artefact does not get mistaken for a configuration error.
3. Define the target state. For every name decide: dual stack intended, deliberately IPv4 only, or legacy to be switched off. Without that column no later deviation can be assessed.
4. Test reachability per address family. Connection setup, TLS handshake and HTTP status separately over IPv4 and IPv6, not just the DNS answer.
5. Document the deviations. Record differences in status code, redirects, headers and response time — they are the work list for remediation.
6. Move the inventory into monitoring. Every name with a target state of "dual stack" gets two checks and a rule that reports a one-sided outage.

Hostname                 A        AAAA     Target         Finding
-----------------------------------------------------------------------
example.com              ok       ok       dual stack     fine
www.example.com          ok       ok       dual stack     fine
shop.example.com         ok       ok       dual stack     p95 740 ms instead of 182 ms
cdn.example.com          ok       missing  dual stack     AAAA missing since move
api.example.com          ok       ok       dual stack     502 over IPv6
status.example.com       ok       ok       dual stack     HSTS missing over IPv6
legacy.example.com       ok       stale    decommission   AAAA points at foreign system

Practice 2: alerting on a one-sided outage

An alert is only as good as the question it answers. "Website unreachable" is the wrong question under dual stack, because the answer is usually no as long as one path works. The right question is: does the result over IPv6 differ from the result over IPv4, and for longer than a short-lived glitch would explain?

• One-sided connection failure. No connection over one protocol version while the other succeeds — report after two consecutive checks from at least two locations.
• Status code divergence. Different final HTTP status codes per protocol version are usually a configuration error rather than coincidence — report immediately.
• Response time divergence. A persistently higher p95 on one protocol version, say a factor of three over at least an hour, points to a network path that needs attention.
• AAAA change without approval. Treat every change to the AAAA record like a change to the A record: record it, compare it against the target value, report deviations.

To keep such rules from turning into constant noise, the same principles apply as with any availability monitoring: confirmation from a second location before escalating, and a check interval matched to the detection time you are willing to accept. The relationships are described in the articles on choosing the right check interval and monitoring from multiple locations; how to damp flapping alerts further is covered in the alerting overview.

Practice 3: testing without your own IPv6 connection

Many businesses still have no IPv6 connectivity in their own network — and conclude that they cannot test IPv6. That is only true for the most convenient route. Four approaches work without a connection of your own and can be set up in minutes.

• Mobile data instead of Wi-Fi. A smartphone with Wi-Fi switched off is already an IPv6-only client with NAT64 in many networks — the most realistic available test for the case in section five.
• Check DNS first. dig AAAA and dig A per hostname from two resolvers give you the foundation before any connection is tested at all.
• Force the address family. Command line tools can be pinned to one protocol version with -4 and -6; comparing the two runs shows status, header and timing differences straight away.
• Use external vantage points. Monitoring whose probes sit in dual-stack data centres delivers the IPv6 view permanently — regardless of what your own office line supports.

Keeping dual stack under permanent observation

The numbers are clear enough to shift priorities: globally the native IPv6 share at Google has risen above 50 percent on several days since late March 2026, in Germany it stands at 75.7 percent (Google, IPv6 Adoption Statistics), and APNIC Labs measures 72.1 percent IPv6-capable users for Germany (APNIC Labs, IPv6 Capability Measurement). Monitoring that measures over IPv4 only therefore describes the minority variant of your own traffic. The effort to correct that is modest: an inventory, two checks per hostname and one rule that reports one-sided deviations.

If you are building evidence for regulatory requirements anyway, this step fits alongside it — for example in parallel with the NIS2 registration with the BSI and the extended deadline of 31 July 2026 or the transparency obligation for website chatbots under the AI Act. All three cases rest on the same principle: traceable, timestamped data rather than snapshots. What separate recording per protocol version looks like in practice is shown in the uptime monitoring overview; the demo environment holds the full data set without a login, and the pricing overview puts the scope in context.