Layers and abstractions

Posted Mar 24, 2019 2:10 UTC (Sun) by perennialmind (guest, #45817)
In reply to: Layers and abstractions by zlynx
Parent article: Layers and abstractions

The vast majority of web clients have been upgraded for IPv6, but most of them have lousy IPv6 access. IPv6 required upgrades along the entire path to be useful. Even then, anything short of full adoption makes use risky. For a decade, I tried to join in the 128-bit fun: tunnelbroker.net, 6to4, teredo (once I had the twin IPs for a relay), and finally a /48 of ~~my own~~ my company's from an ISP happy to provide it but bemused that I cared. And still, I have to grit my teeth and turn off IPv6 when some website we care about turns on IPv6 and the road gets all bumpy. "Happy Eyeballs" is all about compensating for the tendency of IPv6 to be so very bumpy. It's not the hosts at either end: it's the unloved links inbetween.

A larger address space in the 90's was primarily useful to client networks that were already resorting to NAT. That's where the incentive was, so start by addressing their problems. In the first phase, you don't run public servers beyond the IPv4 edge – I agree with you there! That happens once (1) there are few legacy IPv4 clients left and (2) all of your server software has support for the address extension. You don't disable the extended-address support on your IPv4.1 OS, because it's so very harmless. It's just one more upgrade like any other. No need for AAAA records at that point. 32-bit IPng destination addresses are normal. 🙃

It took so long before userspace had decent support for IPv6. Presumably because it was largely irrelevant. Once you have servers automatically upgrading connections to IPng, it becomes relevant! Upgrade your client OS and server OS, but keep the routers and userspace on IPv4 and still get bigger addresses on the wire? I have to think adoption would have been quicker!

Start small. Build up incrementlly. Let your chick grow up and you wind up with chicken and egg. 😊