Tell HN: IPv6-only still pretty much unusable

That sounds like pMTUd failure. The easiest check for that would be to set your client machine's MTU to 1280 and see if it fixes it.

Most people work around that problem with TCP MSS clamping in v4. Sometimes they don't apply the workaround for v6, then blame v6 for the problems.

What I think (or at least hope) that this post is missing, is the ever-growing opportunity cost of having a population of people that are flat out unable to access your service. Google's IPv6 page currently has almost all of Africa at near-0% v6 adoption, but this map https://data.worldbank.org/indicator/IT.NET.USER.ZS?view=map shows a lot of African countries that still have low internet access. With such a long way to go towards full access, and in a lot of countries, exponentially rising populations, could a lot of African ISPs give up on the cost and/or CGNAT complexity of trying to magic up so many new IPv4 connections, and go all in on v6? That's only my layman speculation though.

I could say IPv6 addresses should have been 8 bits because it would have been more usable but that's not reasoning I'm right and IPv6 is a mediocre design-by-committee protocol it's just me lambasting the designers based on some number I thought sounded nice.

If the addresses were 64 bit instead of 128 bit the situation wouldn't be any different, beyond IPv6 would be harder to use. For humans unused bits end up hidden when written out and for machines most of the bits are used and are used in a way that make it scale and be simplified over using fewer bits. E.g. the assumption that every user subnet is a /64 instead of based on the number of devices in it is a massive simplification that hides a ton of complexity people ran into with IPv4 networks. /48 being the minimum aggregate advertisable on the internet makes the number of participants in the internet scale much better. Giving RIRs blocks of /23 leaves room to expand as assignments grow in the future - avoiding the problem we hit with IPv4. Just saying "half the bits is simpler" doesn't actually make your assumptions correct or the deployment happen any faster.

To re-iterate on this part: The problem isn't the protocol it's that there is little incentive for the average user to switch to anything else on their own volition when most didn't even really set up what they are switching from (and already working on today) anyways.

That's not to say the end user needs a more "usable" protocol so it becomes attractive to switch - that's not where the lack of attractiveness sources. The cost to use the protocol could be 0 (and IPv6 is actually extremely close to that to be honest) and there is still no incentive for consumers or businesses to make the switch yet. Even if everything goes perfect and is 100% done without any human intervention it still provides them no benefit until very recently when IPv4 prices started to rise so why would anyone have rushed to make the switch 20 years ago?

An example of this comes back to the cell carriers - they didn't go to IPv6 because they just like and have the time to do complicated things it was the simplest way to enable mobility across their networks with a large scale of devices. They hit this need much sooner than the price of a /24 went up enough for people to start caring so they pushed for their networks and phones to support this faster (on top of needing to build out a lot of new greenfield stuff anyways so why bother building greenfield with the old).

> Right now, most application software need non-trivial rewrite to add ipv6 support:

That's not right.

If you've been using the platform network libraries for things then IPv6 will just work with anything more recent than Windows XP. Unless you've been hardcoding IP length expectations then there is basically nothing to do.

Seriously, use the platform libraries. They handle all the edge cases and stop storing IP address in a uint32.

My company runs an API SaaS; my impressions come from a hobby I have of looking up the hosting providers behind our customer IPs as seen in our request logs (to find out what people think is a good idea for hosting a production web- or mobile-app service backend these days.)

By and large, our very-much "real world" customers are "self hosting" — usually on bare metal rather than a VPS, and usually with providers you've probably never heard of (ColoCrossing and ServerMania seem to come up fairly often among our US-based customers.) These hosting providers are all very much in the style of "you lease each machine as a separate contract; each machine gets one public IPv4 address included in the cost; private networking [i.e. an explicit VLAN] is an extra optional feature you can enable after the fact, and only works between higher-end machine types, rather than being a given, because our lower-end machines only have a single NIC in them [besides the one that's part of the BMC used for IPMI]."

What I assume is happening here isn't literal "self hosting" — these random non-IT-oriented customers wouldn't know the first thing about it — but rather that a given customer of ours has paid some "vertically-integrated IT consultancy" to both build and host their service for them; and said consultancy has chosen to use bare-metal hosting to host the resulting service, to minimize their own OpEx, and therefore maximize their margins. (In fact, I bet they're often packing several such customers onto a single box.)

---

Also, in a more professional capacity, I investigate the hosts behind IP addresses behind bulk-registration / DDoS attacks against our platform, in order to create signatures for them. Given the way some of these attacks seem to work, a large number of machines on the Internet — especially in Russia and [some parts of] Africa — seemingly aren't only un-NATed, but in fact have a public /24 or even /22 directly attached to a single box! (If traffic was originating from a random subset of a /24, it could just be someone spinning up a hundred VMs on top of some small colo's OpenStack deployment, sure. But tandem traffic from every IP in a /24, and only exactly said /24? That looks pretty much exactly like the sort of tandem IPv6 traffic that is generated when a box has a /48 or /56 assigned to it.)