Tunnel brokers for IPv6 in 2026 — still relevant or legacy crutch?

I keep seeing new entrants on the Contabo VPS thread asking how to get IPv6 working on their 2 USD/month NAT instances. The stock answer is still "use a tunnel broker." But I am starting to question whether this is responsible advice in 2026.

Context: I operate a small ASN (64512, yes, the documentation block, this is a lab) and peer at an IX where I can observe v6 adoption curves directly. Native v6 prefix announcements have crossed 95 percent of routed ASNs by most metrics. RPKI ROA coverage for v6 is actually better than v4 in some RIR regions. The major transit providers have stopped charging premiums for v6 commit levels.

Yet tunnel brokers persist. Hurricane Electric's tunnelbroker.net, SixXS successors, various WireGuard-based implementations. The technical trade-offs are well-known: MTU reduction to 1480 or lower, encapsulation overhead, added latency, stateful endpoint dependency. What I am questioning is whether recommending them to new operators in 2026 is setting them up for subtle failures.

My specific concern: path MTU discovery blackholes are still prevalent in 2026, and tunnels amplify them. Encapsulation hides packet boundaries from the underlying network. TCP works until it doesn't. UDP-based protocols (QUIC, WireGuard itself) fail silently or with confusing symptoms.

For a home user on a v4-only ISP, tunnels are a valid stopgap. For a production VPS? I am leaning toward "get a provider with native v6 or run v4-only." The $2/month savings is not worth the debugging hours.

Curious if anyone has measured tunnel vs native failure rates at scale.

Virtualization tax strikes again

@GeorgeNmp: OpenVZ containers sharing a kernel namespace can't do sit/gre/6in4 without host support anyway. The "tunnel" on those platforms is usually just a routed /64 on a veth pair, not real encapsulation. You're paying the virtualization tax twice: once for containerization, once for fake v6.

On proper KVM with virtio-net you can do 6rd or wireguard-based tunnels at line rate on a single core now. Kernel 6.8+ has the wireguard fast path in NAPI so cpu overhead is sub-1% for 1Gbit. But why bother when even Hetzner's 3.50 EUR tier gives you a /56 native now?

I still keep a HE tunnel on my home lab router for prefix stability. Native v6 from my residential ISP changes if I sneeze. The tunnel endpoint has been stable since 2019. That's the only production use I tolerate.

HE tunnels add 15-40ms depending on PoP. Saw a 1.2 Tbps reflection hit a client last month, tunnel endpoint was in Fremont. Scrubbing center couldn't rate-limit the encapsulated stream without breaking the tunnel state. Native v6 got filtered at the edge, tunnel went down for 8 minutes.

Anycast for tunnel PoPs is mostly marketing. BGP healthchecks don't help when the encapsulation path is congested but the PoP still answers ICMP.

For DDoS: native or don't bother.

HE still gives you a /48 on request though. That's the only reason I keep mine. My ISP (Verizon FiOS) hands out a /56 but it changes every time I sneeze on the ONT. The tunnel endpoint IP has been stable since 2019.

For actual traffic? Native wins. For prefix stability on a home lab? Tunnel still has a niche.

That's the stability argument I hear most, and I don't dismiss it. But I want to separate "tunnel broker as prefix stability tool" from "tunnel broker as v6 enablement for cheap VPS." The latter is what I see pushed on new users who don't know the difference between NAT64, 464XLAT, and a routed /64.

The real question: if you're on a 2 USD/month NAT VPS, do you actually need v6? Most of what people want it for (outbound Git, package mirrors, Let's Encrypt) works fine behind NAT64 these days. Cloudflare and Google both run public NAT64 gateways. The "v6 or bust" mentality is cargo-culting 2015.

Living in Marseille I see the other side. My residential ISP (Free) has had native v6 since 2013 but their CPE implementation is garbage. Prefix delegation works for 48 hours then stops until reboot. I ran HE for two years because it was more reliable than the native path.

Switched to a 4G failover router with WireGuard to a Hetzner VM for v6 instead. Same prefix stability, no GRE state to worry about.

Strong disagree on NAT64 for anything interactive. The latency hit on DNS64 synthesis is real, and ALG-less protocols (think SIP, but also anything custom on UDP) fall over. I've debugged enough "why doesn't my game server work" tickets where the answer was "you're behind NAT64 and the client assumes v4 literals."

For a web scraper or apt mirror, fine. For general purpose compute? You're pushing complexity onto users who won't know how to debug it.

Stability until HE decides your tunnel is "abuse" and null-routes it with no appeal process. Saw this twice last year. Both users were doing completely legitimate traffic (one was a Tor exit, which HE's AUP allows explicitly, but the automated system flagged anyway). Took 6 days to restore.

Native prefix: you control the LOA. Tunnel: you're a guest at someone else's party.

Tallinn perspective: my ISP (Telia) finally rolled v6 to residential last year but only as DS-Lite. No prefix delegation at all, just a single /128 on the WAN side and MAP-T behind it. I keep HE purely because I need more than one address for my lab.

The "just get native v6" advice assumes your ISP isn't stuck in 2014. Half of Eastern Europe is still there.

Finland is weird. DNA has had proper v6 for years, Elisa only on business lines. I have a Hetzner VM in Helsinki that I use as a WireGuard endpoint for v6 at home, same as naildude's setup. 3 EUR/month, native /64, I control the firewall rules.

HE tunnel was free but the PoP latency to Helsinki was 35ms through Stockholm. WireGuard to Falkenstein is 12ms. Easy math.