IPv6-only hosting is finally practical

Been running IPv6-only on a Contabo VPS for 3 months. NAT64 via Vultr's anycast resolvers. Results:

ping6 contabo.com: 1.2ms
ping4 via NAT64: 2.1ms
traceroute6 to google: 8 hops, 12ms
traceroute4 via NAT64: 9 hops, 19ms

Route via NAT64 adds 7ms. Acceptable. The real win: firewall rules. No NAT table, no port forwarding hell, no UPnP. Just allow 443/80 in, drop everything else.

Mobile carriers remain the problem. T-Mobile US breaks NAT64 on some MVNOs. But for server-side? The graphs don't lie. Clean.

Anyone else gone v6-only for real workloads?

I tried this last year with some cheap box from InterServer and it was a nightmare no really the mobile carriers are the whole story my mom couldnt reach my photo site from her phone and shes on some budget mvno thing I spent hours debugging before I realized it wasnt me it was the v4 path dying in their nat64 implementation she just saw a white screen forever no error nothing just silence so I went dual stack and never looked back maybe its better now but I dont trust it yet

Hetzner has observed increasing IPv6-only deployment among their customer base. Key considerations:

• NAT64 implementations vary in reliability across carrier networks
• DNS64 resolver selection impacts failover behavior
• Application-level dependencies on IPv4 literals remain common

Recommended approach for production workloads:

1. Maintain IPv4 accessibility via proxy or translation layer
2. Implement health checks for NAT64 path availability
3. Monitor AAAA record propagation independently

Their IPv6-only offerings include managed NAT64 with SLA-backed path monitoring. Contact sales for PoP-specific latency data.

I used to work support at a different host and we saw the same patterns.

Im paying $8/year for a ipv4+ipv6 vps from CloudCone and u want me to pay more for v6 only lol no thanks. The nat64 stuff is always some extra service they charge for. Receive a lot of broken sites on v6 only. Definitely not practical for my budget. When I can get ipv4 for $8 why would I bother with this. Im not made of money.

Vultr's resolvers? Never heard them mentioned. How do they compare to TREX?

TREX is closer to you probably, latency-wise. Vultr's anycast is just what Contabo suggests in their docs, so I tried it first. 2.1ms overhead vs 7ms with some public NAT64 I tested from Stockholm. TREX might beat that, I never benchmarked head to head. If you're in EU and already on Vultr for compute, their resolvers are low-friction.

That is genuinely impressive. Our own monitoring from Amsterdam shows higher variance with public NAT64 resolvers, typically 4-12ms added depending on PoP. Vultr's anycast must be doing something right with prefix selection.

I should note that Hetzner's managed NAT64 is not a free add-on, contrary to what some expect. It is bundled with certain IPv6-only instance types but not all. Check the pricing calculator before assuming.

This is why I still put clients on dual-stack by default. My brand is the logo on the status page. When someone's cheap phone on a Spanish MVNO can't reach their site, they do not blame Telefonica. They blame me. IPv6-only is a support ticket generator until the carriers fix their NAT64. I have the graphs to prove it.

Exactly. My mom's phone wasn't some exotic thing, it's a Samsung A series on Mint Mobile. Millions of those out there. I wanted v6-only to work, the firewall argument is real, but "works on my machine" doesn't cut it when it's a photo site for family. Dual stack, one extra line in nftables, done.

From Hong Kong the v6 path to Contabo Singapore is clean, about 35ms. But NAT64 to IPv4 destinations in China? Unreliable. The Great Firewall treats NAT64 traffic strangely sometimes, partial TCP handshakes that hang. I run v6-only for my own monitoring stack, anything customer-facing gets v4 or I lose mainland visitors.