Loading...

CDN basics · 7 min read

IPv6 for websites: what changes, what does not, and what the CDN handles

IPv4 ran out of addresses years ago; the internet kept working because carriers translate and share them. IPv6 is the version with enough addresses for everyone, and in 2026 it is no longer optional on mobile networks or in procurement checklists. The good news: behind a CDN, giving your site IPv6 is a DNS record you may already have, not a project.

Updated

IPv6 for websites: what changes, what does not, and what the CDN handles

Why IPv6 is back on the agenda

IPv4 has about four billion addresses and the last free blocks were handed out in the 2010s. The internet did not stop: carriers put many customers behind one shared address (carrier-grade NAT) and translate between the two worlds. That works, but it adds a middlebox to every connection, makes per-IP rules meaningless when a thousand phones share one address, and costs the carriers money — which is why most mobile networks now run IPv6 natively and treat IPv4 as the legacy path. Add the procurement side: public tenders and enterprise security questionnaires ask whether a service is reachable over IPv6, and a plain no is a lost point.

What actually changes for a website

Almost nothing in your HTML or application. A dual-stack website has two kinds of DNS records — A for IPv4, AAAA for IPv6 — and a front door that listens on both address families. A modern browser resolves both, tries them nearly in parallel and keeps whichever connects first (the Happy Eyeballs rule), so a broken IPv6 path does not strand a visitor. Once the connection is open, HTTP is HTTP: the same cookies, the same cache headers, the same TLS certificate. The visible difference is in your logs, where client addresses like 2a01:4f9:... start showing up next to the familiar dotted ones.

What the CDN already does for you

The CDN.com.tr edge has been dual-stack since September 2026: every CDN hostname carries AAAA records beside its A records and the edge accepts connections on both. If your site points at us with a CNAME — the usual setup for www and subdomains — it inherited IPv6 on that day with no change on your side. Your origin server does not take part: the edge terminates the visitor's connection, whichever family it arrived on, and fetches from your origin over IPv4 exactly as before. The visitor gets an IPv6 site; your server never needs an IPv6 address.

A CNAME inherits both families from the CDN hostname

$ dig +short www.example.com AAAA
www.example.com.cdn.com.tr.
2a03:35e0:9700::9

$ dig +short www.example.com A
www.example.com.cdn.com.tr.
185.70.97.9

How to check your own site

Two commands answer the question for any hostname: dig for the records, curl for a real connection. In a browser, DevTools → Network → right-click the columns → Remote Address shows which family was used. If curl -6 fails while curl -4 works, the site is not reachable over IPv6 from where you are — which may be the site or may be your own network, so test from a phone on mobile data before opening a ticket.

Records, then a real IPv6 connection

$ dig +short AAAA www.example.com
2a03:35e0:9700::9

$ curl -6 -sI https://www.example.com/ | head -1
HTTP/2 200

$ curl -4 -sI https://www.example.com/ | head -1
HTTP/2 200

The things that actually break

IPv6 does not break pages; it breaks assumptions about addresses. First, allow and deny lists: a rule that names IPv4 addresses simply never matches an IPv6 visitor, so an office allow-list for an admin path stops admitting colleagues on IPv6-only mobile until you add their IPv6 range. Second, per-IP rate limits and counters: one IPv6 visitor may legitimately rotate through addresses inside a /64, so count per /64, not per address, or your limits become both leaky and unfair. Third, analytics and geolocation: databases and dashboards built for dotted addresses need IPv6-aware versions, and a stored IPv4 field of 15 characters truncates a 39-character IPv6 address. Fourth, the parts of your stack that are not behind the CDN — an API on another host, a mail server, a webhook receiver — are still IPv4-only, and an IPv6-only client cannot reach them at all.

IPv6 and HTTP/3 belong together

The same edge change that brought IPv6 also turned on HTTP/3, and the two share a reason: both remove a middlebox or a round trip from the visitor's path, and both are announced by the edge and adopted by the browser without a setting on your side. If your goal is speed rather than reachability, HTTP/3 is the lever that shows in Core Web Vitals; the guide on HTTP/2 vs HTTP/3 covers what it changes and how to see it in DevTools.

Frequently asked questions

Do I need to change my DNS to get IPv6?

If your hostname is a CNAME to your CDN hostname, no — the AAAA records come with it. If you point an apex domain at edge IP addresses with A records at another DNS provider, add matching AAAA records; support will give you the addresses for your delivery point.

Will IPv6 make my site faster?

Not by itself. It removes the carrier's translation layer for visitors on IPv6-only networks, which helps a little, and it makes your site reachable for them at all. The speed lever on the same edge is HTTP/3.

Do IPv6 visitors see the same cache?

Yes. Cache keys are built from the URL and the rules you set, not from the address family. A page cached by an IPv4 visitor is served from cache to an IPv6 visitor and vice versa.

Does my origin firewall need IPv6 rules now?

No. The edge still connects to your origin over the address family it uses today, usually IPv4, from the same edge addresses as before. Only the visitor-facing side changed.