[neilalexander]

Having services be accessible on a link-local address and then advertising that service via mDNS is a completely legitimate use-case that works extremely well and is extremely common with Apple devices amongst others. The advantage being that it still works just the same even without a router handing out addresses or if you just connect two devices directly to each other.

Also what gives you the impression that zones were “deemed a mistake”? They may be awkward in URIs but they are very much not a mistake, they are a deliberate part of ensuring that each link has its own link-local subnet without any ambiguity. It solves the problem of what the operating system should do if you need to access a link-local address that shows up via more than one network interface, which is a very real problem with unscoped IPv4 link-local addresses.

Finally, ULAs don’t and were never intended to replace link-local addresses, they serve a different purpose entirely.

[labcomputer]

> Finally, ULAs don’t and were never intended to replace link-local addresses, they serve a different purpose entirely.

Right, but ULAs are the correct answer here because the purpose they serve is exactly the one the article is trying to hack around with link-local addresses. Like most "IPv6 is hard" articles, the main issue with this one is the author simply refusing to learn how IPv6 works or follow best practices.

ULAs are not hard to set up. You just need one device to broadcast Router Advertisements with the "A" flag set and router priority 0. That device may be the same one hosting the service!

> Also what gives you the impression that zones were “deemed a mistake”?

I disagree that zones are a mistake, but a good rule of thumb is that if you're trying to use zones and you're not writing system code, you're probably holding it wrong. Use IPv6 the right way and your life will be so much easier.

> Having services be accessible on a link-local address and then advertising that service via mDNS is a completely legitimate use-case that works extremely well and is extremely common with Apple devices amongst others.

Apple devices actually advertise services to hostnames via mDNS. Hostnames are then resolved to IP addresses, again via mDNS. While link-local address are populated in the host table, so are the routable addresses as well as the ULA-prefixed addresses (if your network uses ULAs).

[Dagger2]

Note you can also advertise a ULA prefix without the A flag. The advertisement tells other machines that the IP is on-link, and they can use their own GUA addresses to connect without needing a ULA address of their own.

You could also assign a single address (e.g. fd53::1/128) and advertise the corresponding prefix of fd53::1/128, so you don't even need a whole ULA prefix, just individual addresses. (This is sometimes useful if you use a router you can't configure and it's advertising a DNS server you don't want to use.)

[dcow]

When I say “zones” I’m referring to site-local addresses specifically which were deprecated and replaced by ULAs because zones in anything other than link local addresses were declared stupid and hard to implement. That may be where the confusion is coming from. I’m sorry I didn’t use specific language. I understand what we commonly call the “interface scope” is technically a “zone id”.

mDNS working on link-local means you can advertise your service over mDNS so no user ever types this shit into their address bar in the first place.

I still maintain that the interface leaking into the address is a bad thing from a design perspective even though I very much appreciate that everything works naturally on v6 LL addresses after applying this one small fix… no user should ever by typing a v6 LL into a browser, and probably every use case you can imagine that isn’t managing network link topology or NDP/bootstrap or running LL name resolution can be solved with ULAs or DNS.