On February 1, Amazon Web Services started charging half a cent an hour for every public IPv4 address, including the ones attached to running instances that used to be free. It doesn't sound like much. It's about $44 a year per address, and for companies running thousands of them it adds up to real money. Analysts estimated it would bring AWS somewhere between $400 million and $1 billion a year.
That's the clearest sign yet that IPv4 is no longer a technical limitation. It's a scarce commodity with a market price, and the market just sent everyone a bill.
How we got here
IPv4 was standardized in 1981 with 32-bit addresses, about 4.3 billion of them. That seemed like plenty for a research network. It was not plenty for a planet with more phones than people.
The central pool at IANA ran dry in February 2011. The regional registries followed: Asia-Pacific that April, Europe in 2012, and North America in September 2015. Since then, the only way to get IPv4 addresses has been to buy them from someone who has spare ones, on a transfer market where a single address costs tens of dollars.
The internet kept growing anyway, mostly by hiding. Network Address Translation puts many devices behind one public address, and mobile carriers and some ISPs now put whole customer bases behind carrier-grade NAT, where thousands of subscribers share a pool of addresses. It works, more or less. It also breaks anything that expects to receive a connection, makes abuse reports point at a whole neighborhood instead of one customer, and needs expensive stateful boxes in the middle of the carrier's network.
IPv6 was designed in the mid-1990s to end all that, with 128-bit addresses, about 340 undecillion of them. Your home network typically gets a /56 or a /64, and a single /64 holds more addresses than the entire IPv4 internet, squared.
What IPv6 actually fixes
- End-to-end addressing. Every device can have a globally unique address again. No port forwarding, no NAT traversal tricks for VoIP and games, no hairpin NAT. Your firewall decides what's reachable, which is where that decision should live.
- Simpler routing. A fixed-size header, no checksums recalculated at every hop, and no fragmentation by routers. Hosts handle it instead.
- Autoconfiguration. With SLAAC, hosts configure their own addresses from router advertisements, no DHCP server required. DHCPv6 is still there when you want central control.
- Cheaper at scale. For carriers, running IPv6-only with a translation layer for the shrinking IPv4 internet is cheaper than buying addresses and running carrier-grade NAT. That's why mobile networks moved first. T-Mobile US runs its network IPv6-only.
What it doesn't fix
A couple of claims get repeated in nearly every article on this, and they aren't true.
"IPsec is mandatory in IPv6, so it's more secure." The original specs said every IPv6 implementation must support IPsec. That was never the same as using it, and in 2011 RFC 6434 dropped even the support requirement to "should." IPv6 traffic is no more encrypted than IPv4 traffic. You get security from TLS, SSH and WireGuard, on either protocol.
"No NAT means it's less secure." NAT was never a firewall. It just happened to drop unsolicited inbound connections as a side effect. A stateful firewall that denies inbound by default does the same job explicitly, and every consumer router that ships IPv6 does exactly that.
The mistakes that bite sysadmins
Turning IPv6 on is mostly easy. These are the ways it goes wrong:
- The forgotten firewall. The classic: a careful iptables ruleset, and an empty ip6tables one. The server is locked down over IPv4 and wide open over IPv6. If you're still on iptables, move to nftables and use the
inetfamily, so one ruleset covers both protocols. - Services listening where you don't expect. A daemon bound to
::usually accepts IPv4 too, and one bound to0.0.0.0doesn't accept IPv6 at all. Check withss -tlnpafter enabling IPv6, not before. - Mail. Big mail providers are stricter with IPv6 senders. Gmail expects a matching reverse DNS (PTR) record and proper SPF or DKIM authentication from IPv6, and rejects mail without them. Set up your PTR record before your mail server starts preferring IPv6, or your mail will start bouncing.
- ICMPv6 blocked. IPv6 depends on ICMPv6 for neighbor discovery and path MTU discovery. Block it all, the way many people block IPv4 ICMP, and things break in strange, intermittent ways. Allow the types RFC 4890 recommends.
- Containers. Docker's IPv6 support works, but it's still opt-in and fiddly, and it's easy to end up with containers that only talk IPv4 on an otherwise dual-stack host.
- Privacy. SLAAC addresses used to be derived from the network card's MAC address, which made a device trackable across networks. Modern operating systems use temporary, randomized addresses for outgoing connections by default. Servers should use stable, deliberately assigned addresses instead.
How to start
- Check what you have. Most ISPs and every major cloud provider support IPv6 now. Often it's a checkbox.
- Go dual-stack. Run both protocols side by side. Clients will prefer IPv6 where it works and fall back automatically. That's what Happy Eyeballs is for.
- Fix the firewall first, then enable addresses. In that order.
- Add AAAA records for public services once they're listening and tested.
- Monitor both. A service that's up on IPv4 and down on IPv6 looks fine to anyone testing from an IPv4-only network, which may include your monitoring.
- Consider IPv6-only for internal networks and new cloud workloads, with NAT64 and DNS64 for the parts of the internet still stuck on IPv4. With AWS charging rent on IPv4, the business case writes itself.
Today, roughly 45 percent of Google's users reach it over IPv6. The other 55 percent will keep IPv4 alive for years. But the question isn't whether to switch anymore. It's how much you want to pay to wait.
Since then
Added October 2026. Google's IPv6 measurement crossed 50 percent in March 2026, about thirty years after the protocol was first specified. Half the internet's traffic to Google now arrives over IPv6.