Why actually run IPv6 on a server?
IPv6 is often framed in simple terms: we ran out of IPv4 addresses, so IPv6 exists to give every device a unique address. That much is easy. What's less obvious is why server operators should bother adding IPv6 support, especially when high-profile sites like twitter.com, github.com and stripe.com don't appear to use it. If you look up their AAAA records (which hold IPv6 addresses), they simply aren't there.
$ dig AAAA twitter.com
(empty response)
$ dig AAAA github.com
(empty response)
$ dig AAAA stripe.com
(empty response)
Part of the answer lies in understanding that not all internet users need IPv6 to reach an IPv4-only site. There are two types of ISPs: those that have enough IPv4 addresses for all their customers, and those that don't. In the second case, ISPs give customers a unique IPv6 address while making large groups share IPv4 addresses, typically using carrier-grade NAT (CGNAT) or 464XLAT. This is why an IPv4-only site like twitter.com remains accessible to most users. But this workaround comes with significant motivations for going IPv6-native.
The network-level arguments for IPv6
The most persuasive case for supporting IPv6 is that CGNAT is a bottleneck. It adds an extra translation layer that can degrade performance, and the problem will only get worse as IPv4 address scarcity grows. CGNAT is also an attractive target for denial-of-service attacks: because it concentrates many users behind a small number of gateways, flooding one CGNAT server can ruin internet access for a large population. When servers support IPv6, users can connect directly, reducing the need for CGNAT and improving the overall health of the internet—a "public commons" benefit that matters especially in regions where IPv4 is scarce.
There are also practical performance reasons. For users on dual-stack connections with a shared IPv4 address, IPv6 is often faster because it avoids the translation step entirely. Clients typically use the "Happy Eyeballs" algorithm to test both protocols and pick the one that appears faster, so supporting IPv6 can give some users a speed boost. There are even suggestions that the performance difference can translate into a search-engine ranking advantage, and that IPv6 traffic may traverse newer, faster network hardware.
Operational and resilience benefits
Supporting IPv6 improves resilience in ways that aren't immediately obvious. There have been real incidents where BGP poisoning or routing failures took down IPv4 traffic while IPv6 continued to work, allowing IPv6-enabled sites to remain partially online during an outage.
For those hosting services at home, IPv6 simplifies things a lot. Instead of configuring port forwarding on a router for each service, each server can get its own unique IPv6 address and be reached directly—provided the client also has IPv6 connectivity, which is increasingly the case.
Running an IPv6 server also offers practical advantages for learning and experimentation. Security professionals may want hands-on experience with the protocol, since attackers certainly understand it. The vast IPv6 address space makes it easy to grab a subnet, try something out, and never worry about reusing that space. Attackers also can't easily port-scan an entire IPv6 network, so an IPv6-only server gets a degree of "security by obscurity"—not a primary defense, but a useful extra layer compared with constantly scanned IPv4 hosts.
Some operators run IPv6 for more direct reasons: they need to reach servers that are IPv6-only with no IPv4 fallback, or they run their own autonomous system (AS) and find IPv6 addresses far more affordable than IPv4 ones. A few even admit to supporting IPv6 simply because it's the current standard and they don't want to maintain "legacy" IPv4-only infrastructure.
When it's easy—and when it's not
In many cases, adding IPv6 support is nearly free. Hosting providers often assign an IPv6 address automatically, so it's just a matter of adding an AAAA record. If the site sits behind an IPv6-capable CDN, no extra work is needed at all.
But IPv6 deployment isn't always smooth. One operator of a large service reported trying to enable IPv6 multiple times over seven years, and each attempt caused problems. The failure mode was this: once an AAAA record was advertised, users would try IPv6 connections, and broken network equipment somewhere in their ISP or internal network would cause those connections to fail—making the service inaccessible for those dual-stack users. That's a reminder that adding IPv6 can genuinely make things worse for some people if the path between them and the server isn't reliable.
The overall takeaway is that the reasons to run IPv6 are more varied than the simple "we ran out of addresses" story suggests. They include performance, resilience, operational simplicity, cost, security and even a bit of fun—Facebook's 2a03:2880:f10e:83:face:b00c:0:25de address with its embedded face:b00c is a memorable easter egg in the protocol's generous address space. But the decision also depends heavily on the cost and risk of deployment for each operator, and that can range from trivial to genuinely difficult.
