💾 Archived View for thrig.me › blog › 2024 › 06 › 16 › no-ips.gmi captured on 2024-06-16 at 12:03:41. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2024-06-20)

-=-=-=-=-=-=-

No IPs

gemini://thelambdalab.xyz/phlog/2024-06-16-cgNAT-blues.txt

Another problem is the exhaustion of the IPv4 space (therefore NAT shenanigans). Why IPv6 kinda sorta did not go anywhere in some places, probably mostly those that have "large enough" IPv4 allocations has various aspects, some of which are detailed below. This is for America; other nations with large IPv4 allocations may differ in detail.

Old Routers

Folks stick with the same router for years (it works good enough, but does not support IPv6), and the local ISP monopoly isn't in a hurry to upgrade to newer routers and other supporting gear. Why would they take a haircut on their profits? Any competition would be most unwelcome: race to the bottom, a need to actually benefit the customer, etc. Cooperatives granted federal money was one way rural America (the other 80% of the country) got electrified back in the 1930s, so one might expect the lawful evil ISP of today to either lawsuit or lobby against such, if they've learned anything at all from history. Lacking a Franklin D. Roosevelt and following Citizens United, alternatives to the local ISP monopoly may be limited to those without giant piles of cash to throw around.

There are mesh networks and such, but those may lack a clear goal, and you may need at least some centralization so that bad network activity (spam, botnets, etc) can be better managed, unless you hate the reputation of your allocation and never want to run a SMTP server there. What a cooperative or competitor ISP can do will also vary greatly by location, resources, and the people available.

An IPv6 Rollout

I rolled out IPv6 for a department at a university and it was pretty terrible. This was somewhere in the 2010s, for reference. One problem was that various sites broke because their IPv6 was broken, so operating systems on my networks would pick IPv6 by default, fail some download, users would complain to me, I'd complain to the broken site, and usually after a bunch of emails going around the site would remove support for IPv6. One could set IPv4 to be the default, but that's hardly a good way to encourage a move to IPv6, and that's a hard setting to make on all the random systems users were dragging onto the network.

The campus ran a central network authentication service for web stuff. This service was not available over IPv6, so the recommendation was to proxy through IPv4, somehow. One way to discover this is by setting a host to be IPv6 only, and then see what breaks. Oh, you want DNS over IPv6?

There was a charming bug where Dell systems running Windows and an Intel network card would, sometimes, upon system sleep, start forging around 6,000 packets per second of IPv6 network traffic, and then you'd learn that someone had not put the uplink cable on the expected and documented port number and moreover had duct taped the cables into neat and tidy bundles that made it difficult to figure out which cable went to the offending host.

Somewhere down the line a remote site informed me that my networks did not support IPv6 (according to someone in the campus network group) so therefore we cannot do IPv6 with you, and I was like, wtf?, because the campus network group had helped get IPv6 going. I had ticket numbers and correspondence and everything, but reality had apparently distorted meanwhile and now denied the existence of the IPv6. Dealing with such takes time and generates stress when one could be doing more productive things, and always remember that IT is a cost center.

A few years (or decades?) spent fixing bugs and open sourcing and documenting everything from the hardware up instead of churning out new features might be nice, but that would cost money, and few vendors will want to reveal what a dumpster fire their ACPI implementation is so one should not expect improvements here.