IPv6

IPv6 (Internet Protocol version 6) is the current version of the Internet Protocol, specified by RFC 8200 and designed as the successor to IPv4. It is the network layer that carries every packet, not a CDN feature, not an application protocol, and not simply IPv4 with a bigger address field. The address size, the packet header, fragmentation and the DNS record type all change. Its 128-bit addresses are written in hexadecimal, like 2001:db8::1, and published in DNS as AAAA records. For a CDN the practical stake is simple. Publish an AAAA record, and an IPv6-only client reaches your edge directly. Otherwise that client is routed through a NAT64 translator on the way to an IPv4-only address. On the latest day in Google's published series, 17 August 2026, 47% of Google's users reached Google over IPv6 (Google IPv6 adoption statistics). This is a mainstream client population, not a pilot.

How it works

Addressing. IPv6 increases the IP address size from 32 bits to 128 bits (RFC 8200 section 1). That is 2^128 addresses, quoted as 3.4*10^38 in RFC 4864 section 1. An address identifies an interface, not a node. A single interface may also have multiple IPv6 addresses of any type or scope (RFC 4291 section 2.1). In text an address is eight groups of one to four hexadecimal digits separated by colons. The token :: stands for one or more groups of 16 zero bits, and it may appear only once in an address (RFC 4291 section 2.2). For every unicast address, except those beginning with the binary value 000, the interface identifier must be 64 bits long (RFC 4291 section 2.5.1). That is why an IPv6 subnet is normally a /64. It is also why the IETF recommends that an end site be able to obtain a block larger than a single /64, rather than one address (RFC 6177 section 5).

Anycast is a unicast address in disguise. An IPv6 anycast address is allocated from the unicast space. It is syntactically indistinguishable from a unicast address. What makes it anycast is that it is assigned to more than one interface. A packet sent to it is routed to the nearest of those interfaces, by the routing protocols' measure of distance (RFC 4291 section 2.6). The same section warns that an anycast set with no topological locality must be carried as a separate routing entry throughout the entire internet, "a severe scaling limit". So CDN anycast works on aggregatable prefixes announced from many locations, not on single host routes spread worldwide.

The packet header. Some IPv4 header fields were dropped or made optional. This reduces the common-case processing cost of packet handling (RFC 8200 section 1). One of the casualties is the header checksum. Unlike IPv4, fields of the IPv6 header are not covered by an internet-layer checksum. So upper-layer protocols such as TCP and UDP must include the 128-bit addresses in their own checksums. By default, a UDP checksum is no longer optional. The one exception is protocols that use UDP as a tunnel encapsulation and deliberately enable zero-checksum mode (RFC 8200 section 8.1). Optional internet-layer information moves out of a variable-length header into separate extension headers, placed between the IPv6 header and the upper-layer header (RFC 8200 section 4). The header is also bigger, and that costs bytes on every packet you serve. A minimum-length IPv6 header is 20 octets longer than a minimum-length IPv4 header. So TCP's Maximum Segment Size over IPv6 must be computed as the maximum packet size minus 60 octets, instead of 40 (RFC 8200 section 8.3).

Fragmentation and MTU. Routers never fragment an IPv6 packet. Fragmentation is performed only by source nodes, using the Fragment header to send a packet larger than would fit in the path MTU (RFC 8200 section 4.5). Every link in the internet must have an MTU of 1280 octets or greater. This is the IPv6 minimum link MTU. A node must also be able to accept a reassembled packet as large as 1500 octets (RFC 8200 section 5). Compare that to the 576-octet datagram every IPv4 destination must be able to receive (RFC 791 section 3.2). To use a path wider than 1280 octets, a node runs Path MTU Discovery. This relies on ICMPv6 Packet Too Big messages to learn the path MTU (RFC 8201 section 1).

How a client actually gets there. Each IPv6 address is stored in its own AAAA resource record. So a host with more than one IPv6 address must have more than one record (RFC 3596 sections 2 and 2.1). A dual-stack client sends the AAAA query first, immediately followed by the A query, and races the results: this is Happy Eyeballs. Its recommended Resolution Delay is 50 milliseconds, and its recommended default Connection Attempt Delay is 250 milliseconds. RFC 8305 assumes that the host's address preference favours IPv6 over IPv4 (RFC 8305 sections 2, 3, 5 and 8). So a working AAAA record wins the race. An AAAA record that answers DNS but fails to connect costs the client a staggered fallback attempt, rather than a broken page.

Why it matters for a CDN

No NAT is a design goal, and it is about address conservation. NAT's primary benefit is amplifying a scarce address space. IPv6 does not need that, and it was designed with the intention of making NAT unnecessary (RFC 4864, abstract). By removing the need for address conservation, and therefore NAT, IPv6 returns the any-to-any connectivity model. It also removes the limitations on application developers that NAT traversal imposed (RFC 4864 appendix A.1). None of that removes the need to firewall and filter. It removes one reason to translate.

IPv6-only clients otherwise arrive through a translator. RFC 6146 was written on the expectation that IPv4 address depletion would make new clients IPv6-only, while the servers they wanted stayed IPv4-only (RFC 6146 section 1). The standard answer is stateful NAT64 together with DNS64. DNS64 synthesises AAAA records from A records, so an IPv6-only client can talk to an IPv4-only server with no change to either end, for the class of applications that work through NATs (RFC 6147, abstract). That gateway shares one or more public IPv4 addresses among several IPv6-only clients. It keeps per-session state binding an IPv6 address and port to an IPv4 address and port. Absent preexisting state, it only permits IPv6 nodes to initiate sessions. As specified, it translates only TCP, UDP and ICMP (RFC 6146 sections 1.1 and 1.2), so QUIC traverses it as UDP, while anything more exotic is undefined. Every one of those properties is a shared bottleneck, a state table and an extra hop between the user and your edge servers. An AAAA record on your edge hostname takes the whole apparatus out of the path.

A client IPv6 address is not a stable identity. This is the part that breaks CDN configuration. Hosts generate temporary addresses with randomised interface identifiers per prefix. This limits address-based correlation of a host's activity. By default such an address stops being preferred for new connections after one day (TEMP_PREFERRED_LIFETIME, less a random desync factor). It becomes invalid after two days (TEMP_VALID_LIFETIME). Implementations should let users override both (RFC 8981, abstract and section 3.8). So a single subscriber can present many /128 addresses inside one /64 in a day. Rate limiting, WAF rules, allow-lists, geo policies and abuse blocking that key on the exact address will leak and misfire. They need to key on the prefix instead. Cloudflare's IP lists, for example, accept IPv6 CIDR ranges with a prefix from /12 to /128 (Cloudflare custom lists). The same caveat applies to RFC 4864's own remark that all flows become better traceable, due to a unique and globally routable source and destination IPv6 address (RFC 4864 appendix A.4). That is a 2007 statement about routability. Temporary addresses, which the same document recommends, deliberately cut the other way.

What CDNs do

• Cloudflare enables IPv6 on all domains without extra configuration or hardware, as long as the host provides IPv6 support. It auto-generates AAAA records for proxied records, but IPv6 compatibility does not apply to the apex domain on hosting-partner or partial (CNAME) setups. For proxied records with both an IPv6 and IPv4 origin address, Cloudflare prefers the IPv4 address when connecting to the origin. Only Enterprise accounts can turn IPv6 compatibility off. Everyone else whose origin software only understands IPv4-formatted addresses keeps IPv6 on and configures Pseudo IPv4. Pseudo IPv4 hashes the client's IPv6 address into a Class E IPv4 address. It either adds a Cf-Pseudo-IPv4 header or overwrites Cf-Connecting-IP and X-Forwarded-For, while preserving the real address in CF-Connecting-IPv6 (Cloudflare IPv6 compatibility, Cloudflare Pseudo IPv4).
• Fastly supports dualstack connections, serving traffic over both IPv4 and IPv6. Client-side and origin-side IPv6 are configured separately, the latter in host settings. Fastly-shared hostnames alphabetically before v.sni are opt-in, by prefixing the CNAME record with dualstack. Shared hostnames from v.sni onwards, and newly created customer-specific hostnames, have IPv6 enabled by default. Once enabled, clients connect over whichever protocol is faster. Fastly notes that most modern clients implement Happy Eyeballs, which prefers IPv6 when both protocols perform equally. If you use Fastly's Anycast IPv4 addresses for apex domains, you must ask support for the matching Anycast IPv6 addresses (Fastly dualstack guide).
• Amazon CloudFront supports both IPv4 and IPv6 from clients to edge locations. It separately supports IPv6 and dual-stack connectivity towards origins. For custom origins, excluding S3 and VPC origins, the choices are IPv4 only (the default), IPv6 only, or dual-stack. With dual-stack, CloudFront picks per connection to prioritise performance and availability. Enabling IPv6 on the viewer side does not guarantee IPv6 is used. CloudFront responds to viewer requests using IPv4 if its data suggests IPv4 will provide a better user experience. You measure the split from the c-ip column of the access logs (CloudFront enable IPv6).
• Akamai automatically generates a dual-stack IPv4+IPv6 edge hostname when a property is onboarded with a Default DV certificate (Akamai Property Manager onboarding). The origin side is a separate Origin IP Version choice of IPv4-Only, Dual Stack or IPv6-Only. Picking Dual Stack or IPv6-Only requires adding the Origin IP Access Control List behavior to the same rule or a parent rule (Akamai Origin Server behavior).

Watch out for

• Path MTU Discovery is a single point of failure, because routers cannot fragment. A node that implements Path MTU Discovery and sends packets larger than the IPv6 minimum link MTU is susceptible to problematic connectivity if ICMPv6 messages are blocked or not transmitted. The TCP handshake completes correctly, and then the connection hangs when data is transferred. This is a black-hole connection (RFC 8201 section 1). Filtering ICMPv6 the way many operators filtered ICMP is the classic self-inflicted IPv6 outage.
• IP-based access control is where IPv6 rollouts break. On CloudFront specifically, do not enable IPv6 if you use signed URLs or signed cookies with a custom policy containing the IpAddress parameter. AWS's own workaround is two distributions, one IPv6-enabled without the IP restriction (CloudFront enable IPv6). More generally, any allow-list, token authentication policy or origin firewall rule that only enumerates IPv4 ranges silently excludes every IPv6 client, the moment you publish the AAAA record.
• An AAAA-only name excludes IPv4-only clients. A dual-stack client queries for both records. An IPv4-only client has nothing but the A query to work with (RFC 8305 section 3). DNS retains its existing support for IPv4 addresses, precisely so both can coexist (RFC 3596 section 1). Treat IPv6 as an addition, and keep the A record through the transition.
• "No NAT" does not mean no translation and no filtering. NAT64 still sits in the path wherever an IPv6-only client has to reach an IPv4-only server (RFC 6146). Once addresses are globally routable, the stateful filtering that NAT gave you as a side effect has to be configured deliberately.
• Address literals have syntax traps. :: compresses one run of zero groups, and it may appear only once in an address (RFC 4291 section 2.2). So a second :: or a wrong group count makes the literal invalid. In URLs and anything that borrows URL syntax, an IPv6 literal is enclosed in square brackets, as in [2001:db8::1]:443. This keeps the colons from being read as a port separator (RFC 3986 section 3.2.2).

Best practice

• Publish an AAAA record for every hostname you serve over IPv6, and keep the A record alongside it. Dual-stack, not cutover, is what the CDN guidance assumes (Fastly).
• Enable IPv6 on the viewer side first. Leave the origin on IPv4 until the origin, its firewall and its log pipeline are genuinely IPv6-ready. Then move that leg to dual-stack or IPv6-only (CloudFront, Akamai).
• Verify rather than assume. Dig for AAAA records on your map or edge hostname (Fastly testing IPv6). Then fetch with curl -6 and curl -4 and compare, since the edge may still answer some viewers over IPv4 (CloudFront).
• Re-key every IP-based control on prefixes, not addresses, before you turn IPv6 on. This includes allow-lists, rate limits, abuse blocks and IP-pinned signatures. A subscriber's temporary addresses rotate by default within a day (RFC 8981 section 3.8), so a /64 is the useful unit. IPv6 CIDR entries are what the tooling accepts (Cloudflare custom lists).
• Permit ICMPv6 Packet Too Big end to end through every firewall and security group in the path, or Path MTU Discovery will black-hole your large transfers (RFC 8201 section 1).
• Keep firewalling, logging and monitoring first-class on a globally addressable network. IPv6 removes the address-conservation reason to translate, not the need for network protection (RFC 4864).