GeorgeNmp
Member
OP
AS64512
- Joined:
- May 2024
- Posts:
- 218
- From:
- Ashburn, US
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
danfra
Member
- Joined:
- Jun 2024
- Posts:
- 159
- From:
- Frankfurt, DE
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
kate3
Member
- Joined:
- Jul 2024
- Posts:
- 208
- From:
- Utrecht, NL
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
tallinnying
Member
Night Shift
- Joined:
- Aug 2024
- Posts:
- 268
- From:
- Tallinn, EE
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
Zurich1984
Member
- Joined:
- Jun 2024
- Posts:
- 118
- From:
- Zurich, CH
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.