Tell HN: IPv6-only still pretty much unusable

> 30-40% global adoption in ~10 years may or may not be a "dash", but it's also not nothing.

Still nowhere close to being remotely unusable after soon 30 years is very very close to nothing.

Regarding benefits: Amazon, Azure and all the other major VPS companies has a lot to gain from IP addresses being expensive, since it makes it almost impossible for new players to enter the market. ISPs may pay for CGNAT in terms of infrastructure and complexity, but they save in support and abuse mitigation cost by making it impossible for normal people to host their own stuff, they save in support cost by not dealing with customers' broken products which get confused by IPv6, and they gain financially from charging a ton for "pro"/"enterprise" non-CGNAT connections.

And for any kind of web service, supporting IPv6 is obviously just a net negative, since you have to deal with both v4 and v6 rather than just v4.

So I suppose I'm saying, sure, there are minor things to gain from v6, but it's not clear that they outweigh the (opportunity) cost of v6 for anyone, and for large sectors it's simply a cost with no upside.

I don't see a rush to support v6... ever. We'll keep growing steadily but slowly for a while, then adoption will taper off.

But hey, I may be wrong! I'd certainly be happy if you were right. The minuscule amount of progress across almost 30 years doesn't instill confidence though.

Where's the need for state? Please excuse the abuse of terms below, but you can probably figure out what I mean.

A v6 only host would send a v6 packet from it's full address to the v4+ address. A router on the path that has access to v4 internet would pull the v4 destination out, and reframe as a v4 packet (source ?, dest the v4 address), that's got the v6 packet, or maybe just the addresses, I dunno. This router would burn a lot of CPU doing this, but doesn't need any state.

The v4+ host has a little harder job, it needs to know a v4 address to send the tunneled packets to. But again, it's sending a tunneled packet, and whatever is processing that doesn't need state, it just needs cpu to inspect and untunnel. Of course, if the v4+ address is rfc1918 (or otherwise unroutable), then that's problematic. You _could_ do NAT at the router, but I'd say don't do that.

It might be useful for the v4 host to keep the v4 tunnel sender IP from incoming addresses to reframe on the back end.

You might also do something special with routing to the v4+ prefix... if you advertise the v4+ address, it indicates you want v6 -> v4+ traffic to go to your network as v6 and you'll encapsulate it, otherwise it would go a (hopefully local) router that advertised the /96 prefix. If this encap/decap turned out to be popular, you might see router ASICs accelerate it, but likely it's expensive, so the work should be distributed to end points as much as possible.

Of course, there was Teredo that kind of tried to do something like, but it didn't really work out, did it?

> How does this not see more abuse by bad actors?

Because this tech goes unused in almost all cases. Also doesn't work if your DNS client is secure against tampering (i.e. uses DNSSEC) without more configuration.

To make this work, you need to intercept and modify the victim's DNS traffic or reconfigure the victim's DNS server somehow. With that amount of control, IPv6 or IPv4 no longer matter; you apparently have full network or configuration access already.

There are protocols to automatically configure such workarounds intended for ISPs, but I don't think they see much use.

> which is why there are so few of these public gateways?

I think a bigger problem is that you're piping a lot of people's internet traffic through your own network for... fun, I guess? To make this sustainable you need a business model and I don't see why anyone would pay for such a service until IPv6-only hosts start becoming more common.

IPv6 is the Python 3 of networking, although adoption is taking far longer than Python 3. Hopefully the lesson has been learned and this won't happen again.

Quite a strange limitation in my opinion. I understand that dealing with subnetting/host network rebinding to allow full IPv6 can be a challenge (especially if you're on DHCPv6 or some other manually managed thing instead of normal SLAAC) but surely Microsoft could use whatever NAT solution they use for IPv4 to work on IPv6 as well?

Apparently support for the protocol can already be enabled (https://github.com/nathanchance/WSL2-Linux-Kernel/issues/25). This makes it technically possible to use a WireGuard tunnel for IPv6 support, at least...