If you would like to write IPv6 addresses in the same style as IPv4, they would look something like
208.255.238.250.0.16.239.109.89.54.222.189.74.21.22.9 208.255.238.250.0.16.239.109.89.54.222.189.74.21.22.9The :: only expands to fill all-zero hextets.
Oh and I'd actually prefer the 65520.
The huge prefixes allow for a simple hierarchical network structure and gives us room to redo the address scheme if we end up wanting to (only a portion of addresses space is currently allocated right now) without having to go through this entire upgrade the internet again.
As an end user who has a choice, they have to give me something that's not harder to use than before. I think they could have managed that if it were a priority.
I 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.
Yes but my phone hijacked all the LAN DNS when I plugged it into a USB port for tethering when Comcrap went down for a few hours
Also separately, when Comcrap is working, my phone on Wi-Fi refuses to ever use the router DNS, http://xyz.local addresses are only available on desktops/laptops and not phones, therefore IPv4 addresses it is when trying to visit a LAN site on a phone.
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
RHEL 9:
[user@localhost ~]# ip addr | grep fe80
inet6 fe80::3544:fe14:5cf:5ad9/64 scope link noprefixroute
[user@fedora ~]$ ip addr | grep fe80
inet6 fe80::7752:d2c6:82c3:482c/64 scope link noprefixroute
user@ubuntu:~# ip addr | grep fe80
inet6 fe80::5ffe:c565:9de2:58f8/64 scope link noprefixroute
Linux will use EUI-64 if left to its own devices, or privacy extensions if you're using something like networkmanager. This makes sense because a desktop oriented distro will typically use networkmanager while a server oriented distro will not, and having a predictable eui-64 address is usually beneficial for a server.
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.
Sometimes we need to deal with raw IP addresses instead of abstraction layers, and IPv6 fails hilariously because it clearly goes beyond the realm of direct human consumption.
You saying a non-human readable thing is human readable if it's passed through an abstraction layer to make something human readable only reinforces the argument IPv6 is not human readable.