Follow both address families independently
Suppose api.example.com now has an A record and an AAAA record. Run controlled probes over forced IPv4 and forced IPv6 from affected access networks. Can both establish TCP, complete TLS and fetch the same authenticated endpoint? If IPv6 connects but the response stalls, inspect the return path, server bind configuration, routing, firewall policy and path MTU. IPv6 relies on ICMPv6 for essential functions, including Packet Too Big signaling. Blindly blocking all ICMPv6 can produce failures that look like application hangs.
A record existing in DNS is not evidence that your infrastructure is correctly reachable through that address family. Your public load balancer might listen on IPv6 while its security policy permits the wrong source ranges. A proxy might pass through the connection but an application allowlist might interpret IPv6-mapped or native IPv6 addresses incorrectly. On a mobile carrier, an IPv6-only access network can also use NAT64 and DNS64 to reach an IPv4-only origin. Hard-coded IPv4 literals or assumptions that every client has native IPv4 can fail on these networks.
The first diagnostic output I want is the breakdown of connection attempts and outcomes by address family. If application logs only record successful requests, they may hide all the connections that never reached the process. Add measurements from edge listeners and external probes: DNS result, selected destination family, connect outcome, TLS outcome, handshake time and fallback time. Group failures by carrier or source autonomous system rather than relying on a single office network test.
What Happy Eyeballs really promises
RFC 8305 describes Happy Eyeballs version 2. It resolves both families asynchronously, orders available addresses and starts connection attempts with a stagger so a nonworking choice doesn't stall the whole connection indefinitely. The RFC recommends an initial connection-attempt spacing around 250 milliseconds in a simple configuration, but that number is not a universal browser setting or a guaranteed fallback time. Implementations vary, historical RTT data can influence decisions, and application frameworks can behave differently.
Racing also does not make an unhealthy IPv6 service acceptable. At high request volumes, even a short fallback delay or extra connection attempt can affect user-perceived p99, radio power use and network traffic. Some clients are on IPv6-only networks and cannot rely on a direct IPv4 fallback at all. Happy Eyeballs improves connection establishment. It is not an availability substitute for operating both address families properly.
The overlooked policy boundary
Enabling IPv6 changes more than the socket type. IPv4 rate limits sometimes count source a.b.c.d addresses as client identities. With IPv6, customers may rotate privacy addresses inside a prefix. Rate-limiting every /128 address separately can allow a single actor to spread requests across many addresses. Blocking an entire /64 without considering shared networks and provider assignment can penalize legitimate users. The correct aggregation depends on the threat model and authentic user or device identity, not an arbitrary prefix constant.
Audit firewalls, WAF rules, monitoring dashboards, geo controls, access logs and TLS origin policies for both families. A service that processes the IPv4 path through an API gateway but sends IPv6 directly to an origin could accidentally bypass authentication or request limits. Check the entire policy chain before treating a successful IPv6 handshake as deployment approval.
Roll out with evidence, not faith
I would initially expose IPv6 to test domains and controlled clients, including IPv6-only and NAT64 networks. Then deploy AAAA gradually where the DNS and routing setup allows segmentation. Compare forced-family connection success, TLS success, end-to-end latency and fallback counts by region and carrier. If the canary fails, remove the new AAAA announcement where appropriate, but remember that cached DNS answers and existing connections won't disappear immediately. Keep the affected listener ready through the drainage period instead of assuming the DNS change instantaneously rolls back every client.
The interview answer is not simply "implement Happy Eyeballs." It is to separate name resolution, address-family selection, network reachability, client fallback and security policy. A new IPv6 address creates a new path through all of those controls. A reliable rollout proves that path works for users who cannot or do not take the old one.
