You keep postponing IPv6 until the next redesign. Two years pass; the host starts charging more for dedicated IPv4. Logs show a quarter of traffic already arrives over v6 through the CDN — but origin only answers on v4. Meanwhile, firewall rules for v6 were never written, and nobody knows whether TLS renewal works on both protocols.
Enabling IPv6 on a new site is not a datacenter migration. It is not a six-month networking project either. It means ticking an option at the host, adding an AAAA record in DNS, opening ports 80 and 443 on v6 like v4, and verifying everything works. The reasonable 2026 strategy for a new site: dual-stack from day one, without dropping IPv4.
IPv4 remains essential for universal compatibility. IPv6 avoids address scarcity and some suboptimal network paths. Both coexist without conflict — provided you remember that email and the website do not follow the same rules.
Dual-stack — enough for most projects
For a brochure site, online store, or typical web app, dual-stack is the proportionate answer. Keep the A record pointing to your server or shared host IPv4 address. Add an AAAA record to the v6 address assigned in the panel. Browsers or the CDN pick the available protocol; origin answers both ways.
At OVHcloud, Infomaniak, or Hetzner, procedures differ slightly — enable in the panel, sometimes an explicit request on shared hosting — but the principle is the same. The common mistake is publishing AAAA without confirming the web server listens on v6, or forgetting the v6 firewall while 443/tcp is open on v4.
Behind a CDN (Cloudflare, Fastly, etc.), the edge often already serves v6. Origin can stay v4-only in some setups — but full dual-stack simplifies troubleshooting and avoids surprises if you remove the CDN later.
DNS, TLS, and firewall — three checkpoints
IPv6 activation rarely happens at the application layer. It plays out in three layers teams often forget to check together.
On DNS, the AAAA must point to the correct v6 address — not a stale test address. Check TTL too: a very long TTL delays fixes after mistakes. On TLS, Let's Encrypt and most CAs cover both protocols, but HTTP-01 renewal must stay reachable on v4 and v6. A cert valid on v4 and expired on v6 produces odd monitoring alerts.
On firewall, this is the classic trap: nginx listens on v6, but ufw or the cloud firewall only allows v4 traffic. Result: silent timeouts for some visitors. Open 80/tcp and 443/tcp explicitly for IPv6, or confirm your ufw allow rules cover both address families. For network hardening, see our VPS firewall guide.
| Step | Common oversight | Consequence |
|---|---|---|
| AAAA without A | IPv4 removed by mistake | v4-only clients blocked |
| Missing v6 firewall | Ports open on v4 only | Timeouts for v6 visitors |
| Rushed mail AAAA | v6 MX without PTR or SPF | Spam rejections |
| CDN without v6 origin | v6 edge, v4-only origin | Acceptable but harder to debug |
When not to overcomplicate
Some situations justify delaying or limiting IPv6 — not ignoring it forever, but not forcing full dual-stack until prerequisites are met.
A legacy app that hard-codes IPv4 addresses will not tolerate AAAA without code fixes. Partner allowlists on IPv4 only require documenting the exception and keeping the A record. Admin access over a VPN without v6 routing can stay on v4 — that is not an argument against public dual-stack.
For region choice and broader network architecture, IPv6 is one brick among many. See our cloud region guide if the project goes beyond a simple website.
The climax — delayed IPv6 becomes IPv4 cost tomorrow
Postponing IPv6 because nobody asks forgets a measurable reality: mobile carriers and ISPs already route a growing share of traffic over v6. On a new site, activation costs an hour of DNS and firewall work. On a mature site, debt becomes expensive IPv4 addresses, duplicated firewall rules, and forgotten tests on every deploy.
Decide and move forward without blind spots
Start by enabling dual-stack at your host and adding the AAAA record in DNS while keeping the IPv4 A record. Test HTTP and HTTPS over v6 with curl or an online tool, and confirm TLS renewal works on both protocols. Keep mail on IPv4 until SMTP v6 is ready. Finally, compare hosts with native IPv6 through our directory if you are still choosing a provider.
Frequently asked questions
Is IPv6 mandatory for a website in 2026?
No, it is not a legal requirement for a typical site. However, a growing share of users already arrive over v6 through their ISP. For a new site, dual-stack A + AAAA is best practice: you stay compatible with all clients without giving up IPv4.
My shared host offers IPv6 — what should I do?
Enable the v6 address in the control panel, add the AAAA record in your DNS zone, and keep the existing A record. Test site access in v6-only mode before considering the rollout complete.
Does IPv6 hurt SEO?
No, if content and HTTP responses are identical on v4 and v6. Problems usually come from mishandled duplicate content, TLS errors, or inconsistent redirects — not from an AAAA record itself.
What about mail over IPv6?
Treat mail separately from the website. MX, SPF, and DKIM often stay on IPv4 at first. Do not publish a mail AAAA without PTR and proper SMTP v6 configuration — see our mailing lists guide.
On a new site, IPv6 boils down to: AAAA in DNS, v6 firewall open, test a URL. If that feels like a project, your host or DNS process is too complicated — not the protocol.