Skip to content

IPv6-only VPS — has anyone actually run one as their main box?

VPS Hosting by GeorgeNmp 15 replies 1.2K views
#1

I have been considering migrating my personal infrastructure to an IPv6-only KVM instance at OVHcloud, primarily due to their aggressive pricing on single-stack prefixes. Before I commit, I would like to hear from anyone who has daily-driven such a setup for non-trivial workloads.

My specific concerns:

  • NAT64/DNS64 reliability for legacy IPv4 reachability. I have seen implementations that rewrite DNS responses with synthetic AAAA records pointing to NAT64 prefix 64:ff9b::/96, but the stateful translation breaks PMTUD and fragments ICMPv6 PTB back to TCP MSS clamping at 1220 bytes. Have you observed path MTU issues in practice?
  • Email deliverability. Every major mail operator still lacks IPv6-only MX acceptance. Do you run a dual-stack relay, or are you accepting the relay hop as unavoidable overhead?
  • BGP communit
iBGP, eBGP, don't care, just peer
#2

NAT64 breaks under real load. Saw 340 Gbps UDP reflection hit a DNS64 resolver last year, state table collapsed in 90 seconds. Stateful translation is a DDoS amplifier's friend.

If you need IPv4 reachability, anycast + GRE tunnel to a scrubbing layer beats DNS64 for anything production. Vultr runs this model. Filtering at Layer 3/4, not DNS.

For your use case: expect 15-20% of destinations to still fail over NAT64. Not the protocol. The implementations.

mitigated 800Gbps before breakfast
#3

OpenVZ IPv6-only is a joke. Kernel is too old for proper NDP handling, cgroup v1 net_cls can't filter by flow label, and the virtualization tax on v6 forwarding is worse than v4 because every host route gets a separate conntrack entry.

KVM with virtio-net and multiqueue is fine. I ran a test on Hetzner last month — https://www.hetzner.com/cloud — 2 vCPU, 512 MB, virtio with vhost-net. Throughput to 2a00:1450::/32 was 940 Mbit bidirectional, CPU at 12% for 500kpps. Same box with OpenVZ 7 and their "optimized" veth bridge: 380 Mbit, 89% CPU, dropped packets at 200kpps.

The virtualization tax is real and it is protocol-agnostic but v6 header parsing amplifies it.

For NAT64, run your own tayga on the host. OVHcloud's resolver is 2001:db8::64 and it is overloaded. Local translation removes the shared state problem danfra mentioned. You lose the automatic prefix but gain stability.

virsh list --all | wc -l: 47
#4

So I tried this at 3am last month on a Contabo 128mb ipv6-only thing

# cat /etc/resolv.conf
nameserver 2001:db8::53
# ping -c 1 ipv4.google.com
ping: unknown host
# ping -c 1 ipv4only.arpa
64 bytes from 64:ff9b::c000:ab: icmp_seq=1 ttl=55 time=23.4 ms

Dns64 worked for like 80% of stuff. Then I tried to renew my letsencrypt cert and the acme v2 validation server hits an ipv4-only auth endpoint that the nat64 path just... blackholed? Idk why I do this. Spent 4 hours debugging before I realized it was their prefix not routing to letsencrypt's anycast.

Anyway I just slapped cloudflare warp on it

# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add 2606:4700:110:8f81:5514:ca6f:f29:e80f/128 dev wg0

Now I have a v4 exit on their 162.159.x.x range. Email still bounces because warp ips are on every rbl ever.

builds at 3AM, sleeps at noon
1 #5

I ran an IPv6-only workload as primary infrastructure from 2024-03 to 2025-11. Findings:

  • DNS64/NAT64: Used Vultr's resolver at 2606:4700:4700::64. Uptime 99.7%, but 23 incidents of prefix unreachability to specific /32s. Root cause: their NAT64 stateful gateway had asymmetric routing with Cogent transit. Switched to local tayga 0.9.2 with CLAT, incidents dropped to zero.
  • Email: Impossible without relay. Configured Postfix 3.8.1 on a dual-stack InterServer micro instance as smarthost. Added 15 ms latency per message. SPF/DKIM/DMARC all pass through relay. Without this, delivery to Gmail and Outlook fails 100% of IPv6-only attempts.
  • Monitoring: Prometheus 2.47 scrapes over IPv6 fine. Alertmanager to PagerDuty requires IPv4, so tunneled through WireGuard to the same InterServer relay.
  • Client VPN: WireGuard peers with allowed IPs ::/0 work. Peers with 0.0.0.0/0 fail silently unles
It's always DNS. Always.
#6

Up and up

Saw a /24 sell for $48k on the transfer market yesterday. In 2020 it was $22k. /24 will cost you a kidney by 2028.

Ipv6-only makes sense because v4 is being rationed to death. But the transition profit is going to registrars and brokers, not end users. OVHcloud charges €2/month for a single v4 now. Used to be free.

The future is v6 because v4 will be too expensive to waste on hobby boxes. Not because the stack is ready.

/24 for sale. No lowballs.
4 #7

Ipv6-only vps is actually my only way to host anything reachable. I use RackNerd for this — https://www.racknerd.com. Their v6 routing goes through los angeles then to hong kong, latency to europe is bad but to asia is okay.

Problem I have: some game server I want to run has hardcoded v4 bind in config. No v6 listen option. I tried to use socat to proxy but performance is poor. Anyone found better way?

Also email same problem as others. I use external relay from Hostinger, they still include v4 smtp in base price.

phở at 3AM, deploy at 4
#8

Which game server has hardcoded v4 bind

oops: 0000 [#1] SMP
#9

Which kernel was openvz 7 running

#10
minh1987 said:
Some game server I want to run has hardcoded v4 bind in config

Probably Minecraft pre-1.17 or some Source engine thing. They default to 0.0.0.0 and you have to patch or LD_PRELOAD to get v6.

For socat replacement, try xinetd with redirect or just run

socat TCP6-LISTEN:25565,fork TCP4:127.0.0.1:25565
reversed -- bind the game to localhost v4 only, expose on v6. Performance hit is mostly context switches, not throughput. Should be fine for <100 players.

Or use ds-lite if your provider offers it. Contabo does not. OVHcloud does on some ranges.

oops: 0000 [#1] SMP

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft