208.255.238.250.0.16.239.109.89.54.222.189.74.21.22.9I mean look, a few days ago Comcast had an outage and I plugged my phone into my USB port to tether it for internet access. It hijacked my DNS entirely, and I couldn't turn on my damn lights or change my thermostat which were on my LAN. Thankfully I know their LAN IPv4 addresses from memory, 10.10.10.x and 10.10.10.y, and I was able to issue CURL commands directly to their local, non-cloud APIs to manipulate them. With IPv6 hell knows what their hex-colon monstrosities would be.
dns: maniacal laughter
You would know exactly, because every IPv6-enabled interface has a link-local predictable IPv6 address derived from its MAC address.
The reality is with IPv4 I can memorize all of the IPv4 addresses of every light bulb, every robot, every thermostat, every plant watering device in my residence, and I can hammer out CURL commands to control everything almost from muscle memory in the event of a DNS hijacking.
Windows and many Linux distros by default enable the privacy extensions on the link local address; it's randomized for a period of time. This is right off a Windows 10 VM:
ipconfig:
Link-local IPv6 Address . . . . . : fe80::9aaf:a280:d593:db1%2
Notice that there's no ff:fe in the middle of the address?RHEL 9:
[user@localhost ~]# ip addr | grep fe80
inet6 fe80::3544:fe14:5cf:5ad9/64 scope link noprefixroute
Fedora Core 35: [user@fedora ~]$ ip addr | grep fe80
inet6 fe80::7752:d2c6:82c3:482c/64 scope link noprefixroute
Ubuntu 22.04: user@ubuntu:~# ip addr | grep fe80
inet6 fe80::5ffe:c565:9de2:58f8/64 scope link noprefixroute
I don't have a Debian right on hand but IIRC they do the same thing. Alpine uses EUI64 I think though.If the problem wasn't obvious, the problem is that IPv6 addresses (and also MAC addresses) are not human readable. IPv4 addresses, on the other hand, are.
IPv6 adoption might be farther along if the addresses were human readable instead of eye-rolling machinations of a small subset of people who speak strictly in hexes.