IPv6 for website owners: a practical dual-stack guide

Imagine a city that gave every building a short, simple house number. For decades it worked fine. But the city kept growing: new houses, new offices, a mailbox on every corner. One day the clerk at the records office opened the drawer of unused numbers and found it empty.

The city couldn't rename every street overnight, so it did the practical thing. It created a new, much longer numbering system and let every building post both numbers on the door. Mail carriers who know the new system use it. Everyone else keeps using the old one. Nothing breaks, and the city can keep growing.

That city is the internet. The short house numbers are IPv4 addresses, and the long new ones are IPv6. If you own a domain and a website, this guide explains what that means for you in plain language: what changed, what an AAAA record is, and how to add IPv6 without breaking anything.

A quick refresher: domains are names, IP addresses are numbers

People type names like example.com. Computers connect to numbers. The DNS is the directory that turns one into the other. When you point your domain at a server, you're writing the building's number into the directory.

For IPv4 that entry is an A record, and it looks like this: 192.0.2.10. For IPv6 it's an AAAA record ("quad-A"), and it looks like this: 2001:db8::10. (Both examples come from address ranges set aside for documentation, so they'll never point at a real server.)

If record types are new to you, our guide to every DNS record you'll actually use covers the basics. In this article we'll stick with A and AAAA.

Why the old numbers ran out

IPv4 addresses are 32 bits long. That allows 2³², or 4,294,967,296, possible addresses. It sounded like plenty when the system was designed. But laptops, phones, servers, cameras and home routers all need addresses, and a lot of the space was set aside for special uses or handed out in large blocks early on.

The drawer really did run empty. On 3 February 2011, the Number Resource Organization (NRO), the group that represents the five Regional Internet Registries (RIRs), announced that "the free pool of available IPv4 addresses is now fully depleted."

Here's how it happened, according to the NRO announcement:

• IANA hands out IPv4 space to the RIRs in blocks called "/8" ("slash-eight"). Each one is 1/256th of the entire IPv4 address space. IANA hands out IPv4 space to the RIRs in blocks called "/8" ("slash-eight"). Each one is 1/256th of the entire IPv4 address space.
• A global policy agreed by all five RIR communities, and ratified by ICANN in 2009, said that when IANA was down to five /8 blocks, it would give one to each RIR at the same time. A global policy agreed by all five RIR communities, and ratified by ICANN in 2009, said that when IANA was down to five /8 blocks, it would give one to each RIR at the same time.
• On 31 January 2011, IANA allocated two blocks to APNIC, the registry for the Asia-Pacific region. That triggered the policy, and the last five blocks were handed out. On 31 January 2011, IANA allocated two blocks to APNIC, the registry for the Asia-Pacific region. That triggered the policy, and the last five blocks were handed out.

The NRO chairman at the time, Raúl Echeberría, put it plainly: "The future of the Internet is in IPv6. All Internet stakeholders must now take definitive action to deploy IPv6."

If you want to know more about who hands out these numbers, see ICANN and IANA: the internet's address book.

The new numbering system: IPv6 in plain English

IPv6 is defined in RFC 8200 (July 2017). It's an Internet Standard, and it replaced the earlier specification, RFC 2460. The headline change is right in the introduction: IPv6 "increases the IP address size from 32 bits to 128 bits."

Adding 96 bits doesn't make the pool four times bigger. It makes it unimaginably bigger. 2¹²⁸ is a 39-digit number: 340,282,366,920,938,463,463,374,607,431,768,211,456. In city terms, we didn't add a few new streets. We switched to a numbering system so large that running out stops being a practical worry.

How to read an IPv6 address

IPv6 addresses look strange at first, but a few rules from RFC 5952 make them easier to read:

• They're written in hexadecimal (0–9 and a–f), in groups separated by colons. They're written in hexadecimal (0–9 and a–f), in groups separated by colons.
• Leading zeros are dropped inside each group. RFC 5952's example: 2001:0db8::0001 is written 2001:db8::1. Leading zeros are dropped inside each group. RFC 5952's example: 2001:0db8::0001 is written 2001:db8::1.
• A run of all-zero groups can be squeezed into a double colon (::), but only once per address. A run of all-zero groups can be squeezed into a double colon (::), but only once per address.
• Letters must be lowercase. Letters must be lowercase.

A few addresses you'll bump into:

You don't have to memorize any of this. You mostly copy and paste the address your host gives you. It just helps to recognize one when you see it.

Two numbers on the door: what "dual-stack" means

Remember the city's solution: keep the old number and post the new one next to it. On the internet this is called dual-stack. Your server has both an IPv4 and an IPv6 address, and your domain publishes both an A record and an AAAA record.

A dual-stack DNS setup for a website might look like this:

example.com.      3600  IN  A     192.0.2.10
example.com.      3600  IN  AAAA  2001:db8::10
www.example.com.  3600  IN  CNAME example.com.

The AAAA record type is defined in RFC 3596, which gives it the type number 28. It holds one 128-bit IPv6 address, just as an A record holds one 32-bit IPv4 address.

Nothing else about your domain changes. The name stays the same, your registrar and nameservers stay the same, and your HTTPS certificate stays the same. Certificates are issued for names, not IP addresses, so the same certificate works whichever address the visitor uses. (More on that in our SSL/TLS and ACME guide.)

How visitors choose which door to use

If your domain has both an A and an AAAA record, which one does a browser use? Modern software uses a method called "Happy Eyeballs," described in RFC 8305. Think of a delivery driver who sees two doors and knocks on both almost at the same time, then walks through whichever opens first.

In simple terms, RFC 8305 recommends that the client:

1. Ask the DNS for both the AAAA and the A record. Ask the DNS for both the AAAA and the A record.
2. If the A answer arrives first, wait briefly for the AAAA answer. The recommended "Resolution Delay" is 50 milliseconds. If the A answer arrives first, wait briefly for the AAAA answer. The recommended "Resolution Delay" is 50 milliseconds.
3. Try connecting, generally trying IPv6 first. If that doesn't succeed quickly, start an IPv4 attempt as well. One recommended default for the "Connection Attempt Delay" is 250 milliseconds. Try connecting, generally trying IPv6 first. If that doesn't succeed quickly, start an IPv4 attempt as well. One recommended default for the "Connection Attempt Delay" is 250 milliseconds.
4. Use whichever connection works first. Use whichever connection works first.

This is great news for site owners: a visitor with a slow or broken IPv6 path usually falls back to IPv4 without noticing. But it isn't a license to publish a broken AAAA record. Fallback takes time, and not every piece of software handles it gracefully. Only publish an AAAA record when the IPv6 address actually serves your site.

Do you actually need IPv6?

Your site will keep working over IPv4 for the foreseeable future. Dual-stack exists so that nobody has to choose. Here's why adding the second address is still worth it:

• A direct path for IPv6 visitors. Visitors whose networks and devices support IPv6 can reach your site over it directly, without depending on IPv4 alone. A direct path for IPv6 visitors. Visitors whose networks and devices support IPv6 can reach your site over it directly, without depending on IPv4 alone.
• Future-proofing. New IPv4 space doesn't come from IANA anymore. IPv6 is where the internet grows. Future-proofing. New IPv4 space doesn't come from IANA anymore. IPv6 is where the internet grows.
• Professional polish. A domain that answers on both IPv4 and IPv6 shows your setup is current. Technical partners and customers may check. Professional polish. A domain that answers on both IPv4 and IPv6 shows your setup is current. Technical partners and customers may check.

We won't give you adoption percentages here because they change constantly and vary by country and network. If you want current numbers, check public measurement dashboards run by network operators and researchers.

A safe, step-by-step checklist for adding IPv6

Think of this as posting the new number on your door in the right order: first make sure the door opens, then put the number up.

1. Find out whether your hosting has IPv6

Not every hosting plan includes an IPv6 address. Look in your hosting control panel or server dashboard. If you're not sure, ask your provider. SoxDomains customers can open a support ticket and ask whether IPv6 is available for their plan. The answer depends on the service, whether that's shared hosting, a VPS or a dedicated server. Our comparison of shared, VPS, dedicated and cloud hosting explains the differences.

2. Make sure the server is listening on IPv6

On a VPS or dedicated server, having an address isn't enough. Your web server (Apache, Nginx or similar) has to be set up to accept connections on it. Many configurations have a separate "listen" line for IPv6. Check that ports 80 and 443 are open on the IPv6 side.

3. Check the firewall, both of them

This is the step people miss most. Firewalls often keep separate rule sets for IPv4 and IPv6. It's common to lock down IPv4 carefully and leave IPv6 either wide open or completely blocked. Make sure the rules match: allow web traffic on both, and block the same things on both.

4. Test before touching DNS

Before you publish anything, test the IPv6 address directly from a machine that has IPv6. For example:

curl -6 -I https://example.com --resolve example.com:443:[2001:db8::10]

(Replace the name and address with your own.) If you get a normal response and a valid certificate, the new door opens.

5. Add the AAAA record

In your DNS zone, add an AAAA record with the same host name as your A record (for example @ and, if needed, www), pointing to your IPv6 address. If www is a CNAME to the root, it follows the root automatically. It can help to lower the TTL a day or so beforehand so you can undo the change quickly. Our guide on what happens after you change nameservers explains how caching affects timing.

6. Verify from the outside

Use the SoxDomains DNS lookup tool, which can look up A, AAAA, MX, NS, TXT, CNAME and CAA records, to confirm the AAAA record is published. Then load your site from an IPv6-capable connection and check that everything works: pages, images, logins and forms.

7. Update anything that "knows" IP addresses

Once IPv6 traffic arrives, your logs will show addresses like 2001:db8::abcd. Check:

• Allowlists and blocklists (admin panels, rate limits, security plugins). Rules written only for IPv4 won't match IPv6 visitors. Allowlists and blocklists (admin panels, rate limits, security plugins). Rules written only for IPv4 won't match IPv6 visitors.
• Analytics and log tools that parse IP addresses. Analytics and log tools that parse IP addresses.
• Any hard-coded IPs in scripts, monitoring or third-party integrations. Any hard-coded IPs in scripts, monitoring or third-party integrations.

What about email, reverse DNS and CDNs?

Email. If your mail server sends email over IPv6, the receiving servers will judge that IPv6 address. Two things matter:

• Your SPF record should include it. SPF has an ip6: mechanism for this, defined in RFC 7208. Our SPF, DKIM and DMARC guide shows how SPF records are built. SPF, DKIM and DMARC guide: https://www.soxdomains.com/blog/spf-dkim-dmarc-email-authentication-guide Your SPF record should include it. SPF has an ip6: mechanism for this, defined in RFC 7208. Our SPF, DKIM and DMARC guide shows how SPF records are built. SPF, DKIM and DMARC guide: https://www.soxdomains.com/blog/spf-dkim-dmarc-email-authentication-guide
• Reverse DNS should be set up. RFC 3596 defines the ip6.arpa domain for mapping an IPv6 address back to a name, the IPv6 version of a PTR lookup. Your server or network provider usually controls this, not your domain's DNS. Reverse DNS should be set up. RFC 3596 defines the ip6.arpa domain for mapping an IPv6 address back to a name, the IPv6 version of a PTR lookup. Your server or network provider usually controls this, not your domain's DNS.

If you use a hosted email service, it normally handles these details. You only need to worry about them if you run your own mail server.

CDNs and proxies. If your site sits behind a content delivery network or reverse proxy, visitors connect to the CDN's edge, not straight to your server. In that case, whether visitors can use IPv6 depends mostly on the provider's edge network. Check the provider's settings and documentation. Our guides to CDNs for domain owners and Anycast DNS vs CDN vs reverse proxy explain how that setup works.

Common mistakes to avoid

• Publishing an AAAA record "just in case" before the server responds on IPv6. That sends some visitors to a door that doesn't open. Publishing an AAAA record "just in case" before the server responds on IPv6. That sends some visitors to a door that doesn't open.
• Forgetting the IPv6 firewall, leaving a wide-open path around the security you built on the IPv4 side. Forgetting the IPv6 firewall, leaving a wide-open path around the security you built on the IPv4 side.
• Pointing the AAAA record at the wrong server after a migration. When you move hosts, update A and AAAA together. Our zero-downtime migration guide walks through a clean cutover. zero-downtime migration guide: https://www.soxdomains.com/blog/web-hosting-migration-guide-zero-downtime Pointing the AAAA record at the wrong server after a migration. When you move hosts, update A and AAAA together. Our zero-downtime migration guide walks through a clean cutover. zero-downtime migration guide: https://www.soxdomains.com/blog/web-hosting-migration-guide-zero-downtime
• Leaving an old AAAA record behind when you cancel a server. Remove it along with the A record. Leaving an old AAAA record behind when you cancel a server. Remove it along with the A record.

The bottom line

The internet's short house numbers ran out years ago, so the city built a new system with room to spare. You don't have to tear down the old sign. Keep your IPv4 address, add IPv6 next to it, and let visitors' software pick the door that opens fastest.

For most site owners, the whole job is three steps: confirm your host supports IPv6, make sure the server and firewall are ready, and add one AAAA record. Do it in that order, test it, and your domain will be ready for however the internet grows.

Sources

• NRO, Free Pool of IPv4 Address Space Depleted — https://www.nro.net/ipv4-free-pool-depleted/ (3 February 2011) NRO, Free Pool of IPv4 Address Space Depleted — https://www.nro.net/ipv4-free-pool-depleted/ (3 February 2011)
• IETF, RFC 8200: Internet Protocol, Version 6 (IPv6) Specification — https://www.rfc-editor.org/rfc/rfc8200 IETF, RFC 8200: Internet Protocol, Version 6 (IPv6) Specification — https://www.rfc-editor.org/rfc/rfc8200
• IETF, RFC 3596: DNS Extensions to Support IP Version 6 — https://www.rfc-editor.org/rfc/rfc3596 IETF, RFC 3596: DNS Extensions to Support IP Version 6 — https://www.rfc-editor.org/rfc/rfc3596
• IETF, RFC 4291: IP Version 6 Addressing Architecture — https://www.rfc-editor.org/rfc/rfc4291 IETF, RFC 4291: IP Version 6 Addressing Architecture — https://www.rfc-editor.org/rfc/rfc4291
• IETF, RFC 5952: A Recommendation for IPv6 Address Text Representation — https://www.rfc-editor.org/rfc/rfc5952 IETF, RFC 5952: A Recommendation for IPv6 Address Text Representation — https://www.rfc-editor.org/rfc/rfc5952
• IETF, RFC 3849: IPv6 Address Prefix Reserved for Documentation — https://www.rfc-editor.org/rfc/rfc3849 IETF, RFC 3849: IPv6 Address Prefix Reserved for Documentation — https://www.rfc-editor.org/rfc/rfc3849
• IETF, RFC 8305: Happy Eyeballs Version 2 — https://www.rfc-editor.org/rfc/rfc8305 IETF, RFC 8305: Happy Eyeballs Version 2 — https://www.rfc-editor.org/rfc/rfc8305
• IETF, RFC 7208: Sender Policy Framework (SPF) — https://www.rfc-editor.org/rfc/rfc7208 IETF, RFC 7208: Sender Policy Framework (SPF) — https://www.rfc-editor.org/rfc/rfc7208