Whatever the technical merits/demerits of the protocol, I believe this brain-damaged approach to describing addresses is behind the “failure” of IPv6.
Whatever the technical merits/demerits of the protocol, I believe this brain-damaged approach to describing addresses is behind the “failure” of IPv6.
MAC addresses seem to thrive, both in Ethernet and Bluetooth. Sure, it's only 48 bits, but it's a bunch of hexadecimal digits with colons.
IPv6 failed because (1) it demanded too much of the networking hardware, (2) was a stupidly complex beast compared to IPv4 and (3) had the catch-22 of requiring both producers and consumers to upgrade at the same time to even make it usable, let alone widely beneficial. (Discounting 6to4 and other local patches.)
However, since I upgraded my AP, I realized my ISP actually does support IPv6 really well, so perhaps we're close now...
Grandparent is engaging in the classic tech industry tradition of talking confidently about something they have very little knowledge about. Surely old people learning hex isn't what's stopping IPv6 adoption but why not, they explained IP addresses it to their Nana once at Christmas (you never visit!) and she nodded politely and so they're an expert on networking.
I for one to still to this day and age don't really understand IPv6 addresses, and admittedly haven't tried much. I typically disable IPv6 at the kernel because it's been nothing but trouble.
On the contrary, the IPv6 headers have been explicitly simplified a lot in comparison with IPv4.
The increased complexity for the networking hardware has come only from the requirement of supporting both IPv4 and IPv6, instead of only one of them.
In my opinion, the most significant mistake of IPv6 has been that the IPv4 address space has not been considered a subset of the IPv6 address space.
Had this been done, it would have been relatively easy to mix arbitrarily in a network ancient IPv4 equipment that has never been updated with equipment implementing IPv6 and the gradual transition between the two protocols would have been very easy.
This suggestion has gotten brought up often over the past few decades.
Remember that every IP packet has a destination and source address. There is no physical way for a v4-only host to directly communicate with another host which has an address from a larger address space. Doing so requires NAT. Which can be and is used today for v4-v6 connectivity.
I'm rolling out services on v6 only now for my hobby projects. Just next week, I'll be switching over our company backups to v6 because I can have a dedicated port 22 on the backup machine instead of port forwarding. I've been running company VPNs v6-only (inside the VPNs) for some years now. Our corporate services and my private hobby projects are all v6-enabled (in addition to v4), the latter since 2018 or something.
A non-techie friend of mine has CGNAT at home on v4, and simply used his consumer-grade router to open a port to the v6 address of his NAS. He and some friends and colleagues from his Uni been using that for half a year before they stumbled into a situation where somebody had no v6 address and could not access the NAS.
I think we're getting there fast.
How are you measuring complexity?
IPv4 started simple, but had a lot of extensions (literally header "options") to fix and mitigate various issues and underspecified behaviour.
IPv6 started more complex, but had a lot of those shortcomings addressed from decades of experience in the real world.
In the Linux kernel, IPv6 is actually implemented with fewer lines of code than IPv4 (as of 6.12.19, IPv4 = 82kloc, IPv6 = 58kloc).