Publishing an AAAA record does not make an IPv6-only endpoint reachable from IPv4-only networks. If a customer, payment gateway, partner webhook, or legacy monitoring probe lacks IPv6, DNS may still resolve, but the connection can fail.
IPv6-only can reduce public IPv4 dependency. Dual-stack remains safer for public apps unless NAT64, 464XLAT, or an IPv4-facing proxy passes end-to-end tests.
Dual-stack is safer for public US apps
Dual-stack accepts both IPv4 and IPv6 traffic. It uses DNS A and AAAA records.
This makes dual-stack the low-risk design for public SaaS apps, stores, APIs, portals, and webhook endpoints. These services often serve networks outside your control.
IPv6-only fits private Kubernetes clusters, service meshes, labs, and controlled corporate networks. It also fits public origins behind Cloudflare, Akamai, or a cloud load balancer.
Those edge services can accept both address families. They can then connect to the origin over IPv6.
B2B traffic is unpredictable. Partners may send webhooks from IPv4 allowlists, and integrations may run through IPv4-only tunnels.
A successful office-browser test does not prove reachability for IPv4-only customers or legacy vendors.
Choose dual-stack if your public client mix is unknown, contract-bound, or business-critical. IPv6-only is safe only when every IPv4 client reaches a tested IPv4-facing proxy, load balancer, or gateway.
Client mix matters more than IPv4 cost
A $3 to $5 monthly public IPv4 charge can prevent a failed checkout, login, or partner callback. Architecture should follow traffic sources and failure tolerance before address cost.
| Deployment condition | IPv4 edge needed | Best model | Main operational risk |
|---|
| Public consumer web app | Yes | Dual-stack | Lost IPv4 customers |
| Partner API and webhooks | Yes | Dual-stack | Allowlists and callback failure |
| CDN-fronted static site | Yes, at CDN | IPv6-only origin possible | Unverified edge-to-origin policy |
| Private Kubernetes service | No | IPv6-only possible | Tooling gaps |
Cloud and VPS checks that matter
AWS, Google Cloud, Azure, and DigitalOcean support IPv6 designs. But feature parity is not automatic.
Verify IPv6 support for your load balancer, WAF, DDoS plan, firewall, logging, and managed database. Check the selected tier too.
CDN and load-balancer patterns
A CDN can accept both address families and forward traffic to an IPv6-only origin. TLS termination, WAF rules, redirects, rate limits, and origin access must work identically on both paths.
Choose an IPv6-only origin only when the edge provider owns and tests IPv4 ingress. Use dual-stack at the origin if clients can bypass the edge or connect directly to a VPS.
Which architecture should your app use?
For most public applications, choose dual-stack first. Treat IPv6-only as a controlled exception.
IPv6-only shifts compatibility responsibility into a proxy, gateway, CDN, or client environment.
For a US public app, deploy dual-stack when any client, webhook sender, enterprise VPN, or direct API consumer is unknown. Use an IPv6-only origin only behind an IPv4-capable edge. That edge must pass separate IPv4 and IPv6 tests for DNS, TLS, WAF rules, authentication, redirects, logs, alerts, and rollback. Lower IPv4 spend is useful, but it does not justify an unmeasured reachability risk.
NAT64 does not serve IPv4 clients
NAT64 and DNS64 usually help an IPv6-only client reach an IPv4 destination. They do not normally let an IPv4-only customer reach an IPv6-only public app.
That customer needs explicit IPv4 ingress.
Test each family as a separate path
Run synthetic checks against the A and AAAA records separately. Measure TLS handshake success, time to first byte, HTTP errors, redirects, login flows, and health checks.
Then split dashboards and alerts by IP family.
Public traffic path to validate
IPv4 client→IPv4 edge→IPv6 originTest TLS, WAF, logs, alerts
IPv6 client→IPv6 edge→IPv6 origin
A gradual migration that can roll back
Enable IPv6 in staging for 7 to 14 days. Publish AAAA records behind a low TTL while retaining the A record.
Compare family-specific traffic, latency, errors, security controls, and rollback behavior.
Choose dual-stack for direct public endpoints, B2B systems, and migrations with limited coverage. Choose IPv6-only for controlled workloads or fully edge-fronted origins with documented compatibility tests.
This comparison matters less for an internal-only workload with no public clients. It also matters less for a short-lived lab. The same applies to apps fully fronted by a managed edge service. There, the provider, not the application team, owns Internet protocol compatibility.
Compatibility mechanisms solve different directions of the IPv4-to-IPv6 problem. DNS64 synthesizes IPv6 answers from IPv4-only DNS records.
NAT64 lets an IPv6-only workload start outbound connections to an IPv4 destination. Together, they help when an IPv6-only deployment calls an IPv4-only payment API, package mirror, or third-party SaaS endpoint.
464XLAT is common on mobile networks. It combines client-side translation with provider NAT64.
Application teams should not assume every network offers it.
For inbound public traffic, use an IPv4-facing proxy, gateway, CDN, or load balancer. It accepts IPv4 connections and forwards them to the IPv6 origin server.
Test that forwarding path separately.
Application boundaries often decide whether IPv6-only is practical. A mobile app may reach a dual-stack API over either family.
Its backend can still fail. It may call an IPv4-only identity provider or send partner webhooks to an IPv4 allowlist.
It may also depend on a vendor endpoint without AAAA DNS records.
In Kubernetes networking, check pod-to-service traffic and DNS resolution independently. Also check ingress controllers, egress gateways, network policies, image registries, and managed control-plane links.
Microservices can use IPv6 internally while exposing a dual-stack API at the edge. This limits public IPv4 usage without forcing partners, browsers, SDKs, or legacy automation tools to support IPv6 now.
Dual-stack networking needs two separately managed public paths.
A firewall rule, WAF exception, rate limit, DDoS control, or IP allowlist may exist only for IPv4. That can leave the IPv6 path less protected.
The reverse can block valid IPv6 users while IPv4 appears healthy. Inventory every public IPv4 address and IPv6 prefix.
Compare security policies across the CDN edge network and load balancer. Confirm that logs preserve the original client address across proxies.
Dashboards should split requests, authentication failures, blocked traffic, latency, and error rates by address family. An IPv6-only outage or abuse pattern can disappear inside aggregate metrics.
Questions & answers
Should i use both IPv4 and IPv6?
Yes, most public applications should use both IPv4 and IPv6. Dual-stack is safer when clients, webhooks, or partner networks are not fully controlled.
IPv6-only needs a tested IPv4-facing edge.
Can NAT64 support legacy IPv4 clients?
No, NAT64 usually lets IPv6-only clients reach IPv4 destinations, not the reverse. An IPv4-only customer needs an IPv4 reverse proxy, load balancer, or other explicit ingress path.
Does IPv6-only reduce latency?
IPv6-only does not automatically reduce latency. Test for at least 7 to 14 days by IP family.
Routing, CDN behavior, DNS, and the client network usually matter more than the address protocol.
What should i test before publishing an AAAA
Test DNS, TLS, redirects, WAF rules, rate limits, origin access, logs, alerts, and full login or checkout flows over IPv6. Keep the IPv4 A record during the first rollout.
That lets a rollback take minutes rather than a redeploy.
The essential points:- Dual-stack is the practical default for public US applications with unknown clients.
- An AAAA record proves only that an IPv6 address exists, not that the full service works.
- NAT64 is not an inbound bridge for IPv4-only customers.
- IPv6-only works best for controlled workloads or origins behind a tested IPv4-capable edge.
Related sources
These articles can help you explore the topic in more depth:
