And that's the problem! Who can memorize all that?

> With IPv6 hell knows what their hex-colon monstrosities would be.

You would know exactly, because every IPv6-enabled interface has a link-local predictable IPv6 address derived from its MAC address.

And so now I have to stick stickers on every light bulb with a huge address on it and then get up on a chair several times per bulb while I transfer chunks of its address from the sticker to my terminal?

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.

Why do you need stickers? You can just log into your router/switch and inspect the arp/nd table. You could just just use DNS records the first time you set a widget up and never have to remember an address again. Your router likely already does this automatically for you in IPv4 land via the DHCP server's database. The reality is that remembering IP addresses to access things has always been a band-aid fix. When's the last time you typed the IP address of hacker news into your browser's url bar? Using link-local addresses is usually a last-resort kind of scenario where you're glad it exists to save you some headache.

> router likely already does this automatically

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.

"Yes you would know exactly, because every hex-colon monstrosity has a predictable hex-colon monstrosity derived from its hex-colon monstrosity."

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.

Adding A-F to the 0-9 existing digits in ip addresses makes them non-human readable? Give me a break. We've had something human-readable since the dawn of the internet: it's called DNS and works with both IP families.

Tell me Google DNS's IPv6 addresses without looking them up. I won't wait.

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.

The way you see legacy IP addresses is also an abstraction layer, their actual form is as a 32bit integer.

.... ?

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.

Well, that is unfortunate because it invalidates a lot of the benefit of the link-local address while providing "pivacy" over the local link scope... I have not encountered any equipment in the wild that does this, thankfully. The only distros I use (NixOS and VyOS) do not have this behaviour by default so this was news to me.

The link-local address is generated when you first enable the interface (ie when you load the drivers for your NIC), it won't change unless you manually force it to.

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.

Seems like a complicated solution to a problem that does not exist. You cannot turn on lights at all without a working network? If your router crashes your whole house is stuck? Seems like there is a bigger issue than the IPv6 protocol

I agree with the complaint about IPv6, but in this situation couldn't you just use nmap?

ipv6: don't worry about the long addresses, you won't need them because DNS

dns: maniacal laughter

No, it'd usually look like v4, except in cases where you're actually using the entire address space and need to add more dots. NAT is here to stay, and a LAN doesn't need 128 bits of address space.

Like fd::1? Valid ipv6 that is shorter than an ipv4 address

Nah, "1.1" is a valid IPv4 address (Cloudflare DNS) and it's shorter

Touché, I guess I should’ve said a typical v4 address. Short hand v4 addresses aren’t as common knowledge though

fd::1 is a reserved address. Did you mean fd00::1?

fd::1 == 00fd::1. The :: expands to fill the available bits with 0

fd::1 == 00fd::0001, which is reserved by IETF.

The :: only expands to fill all-zero hextets.

Good catch, that is correct. Thank you

This thread shows that the ipv6 notation is more complicated. It's good to at least use a smaller address space on a LAN like this, but I want the basic decimal notation.

Decimal is actually a nightmare for dealing with common CIDR prefixes. Would you rather write '1111111111110000' as fff0 or 65520?

Yes, which is why they shouldn't use those huge prefixes. There's an existing 32-bit address space represented nicely like 8.8.8.8 or 192.168.1.2 for local. Now that we want to extend the address space for more users, the newer ones can be like 8.8.8.8.6 without messing with the existing ones.

Oh and I'd actually prefer the 65520.

You'd still need to upgrade and change every device. There have been transitional software that used ipv6 but allowed for ipv4 address notation. [1] Example: ::ffff:0:8.8.8.8

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.

[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism

Right, I've seen the padded v4-like v6 address spec, but that's not how they attempted to transition everything. ISPs gave everyone new v6 addresses, and the whole home/office router/NAT/PC ecosystem put v6 on a totally separate plane with ::: style addresses presented to users. I understand that the clean slate of reallocated addresses would solve some problems, but they could have focused on just getting all that hardware and software onto the ipv6 protocol with minimal changes before attempting to basically redo the entire Internet along with every LAN.

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.

Not sure I understand. Right now you should have dual stack, which should be easier than merging the v4 onto the v6 network. You didn't have to change anything to keep working with v4 and if you want to work with v6 then that's an option for you but you can disable if you really want.

I'd like to use v6 in the dual-stack setup, just with all the v4 addresses copied over so the only change is that I'm using a different protocol under the hood.