A corporate client calls: "your site won't load on office Wi-Fi." Everything looks green on your side. The NOC explains: pilot IPv6-only network with NAT64 to IPv4 — and your domain has only an A record. This is not science fiction; it is the kind of incident that revisits "IPv4 is enough."
IPv4-only remains the majority of shared hosting stacks. Dual stack (A + AAAA) announces the site on both protocols. The question is not ideological: what inaccessibility risk do you accept to avoid a few hours of configuration and testing?
State of play
| Aspect | IPv4 only | Dual stack |
|---|---|---|
| Compatibility today | Very broad | Broad if well tested |
| Future IPv6-only networks | Depends on NAT64/DNS64 | Native |
| Addressing | Scarcity, dedicated IP cost | Abundant |
| DNS config | A record | A + AAAA |
| Firewall / WAF | One family | v4 + v6 |
| Monitoring | Standard | Verify both paths |
Ignoring IPv6 is not a strategy — it is a bet that nobody will cut IPv4 for your visitors soon enough to worry you.
IPv4 only: when still defensible
Legacy intranet, IPv4 VPN. Controlled perimeter, no public stakes.
App with IPv4 partner constraints. Old B2B integrations — dated migration plan.
Host without IPv6 and distant migration. Explicit risk acceptance plus connection error monitoring if available.
Temporary mitigation: dual-stack CDN in front of IPv4-only origin — CDN terminates IPv6, speaks IPv4 to origin. Works if all traffic goes through CDN (no direct API).
Dual stack: checklist without blind spots
Verify host assigns IPv6 to server or load balancer — OVH, Hetzner, Infomaniak offer it; see directory. Publish AAAA consistent with A record. TLS certificate covers name, not protocol — Let's Encrypt handles both.
Open ports 80/443 on v6; block SSH v6 admin if unmonitored. Test with curl -6 https://yoursite from IPv6-only network. Watch forgotten API subdomains (api.example.com).
Common traps: AAAA published but service not listening on [::] → long client timeout; IPv6 open without same hardening as IPv4; outbound SMTP on v4 only while web is dual stack.
The summit: accessibility is asymmetric
Decide and move forward without blind spots
Check if your current host offers IPv6. If yes, deploy AAAA on staging, test from v6-only network, then switch production. If no, choose dual-stack CDN in front of IPv4 origin or plan host migration — not default inaction. Monitor connection errors in support and edge logs. Compare dual-stack hosts via comparator and read HTTP/2 or HTTP/3 for transport layer.
Frequently asked questions
Does my site need IPv6 in 2026?
Not legally mandatory, but increasingly recommended. Without AAAA, you depend on NAT64 on IPv6-only networks — with slowdown or failure risk.
Does dual stack complicate operations?
Slightly: AAAA, v6 firewall, end-to-end tests. Main cost is verification, not an extra license at most European hosts.
Does IPv6 improve SEO or speed?
No direct SEO boost. Future accessibility and sometimes better native v6 latency — not a magic PageSpeed shortcut.
What if my host does not offer IPv6?
Temporary tunnel broker or migration to dual-stack host. Do not stay without a client connection monitoring plan.
Before deferring IPv6, ask your host: is v6 included or billed — and who will monitor AAAA after deploy? Without a clear answer, the risk stays yours.