There aren't address conflicts. And users aren't choosing this, it's part of the IPv6 spec. Each interface has a unique address, but you can't tell from looking at an address which network it lives on.

I think the weirdness comes from the use of multiple addresses at once, specifically fe80::whatever addresses always being present and getting used even on normal setups when everything's working fine and a global address is configured, as opposed to 169.254.whatever addresses, which most networks never intend to use and so usually only show up when something is wrong.

The title of the post suggests the issue is allowing that syntax in URLs.

Is there an equivalent syntax for IPv4 addresses?

> I really do wish they'd just stuck with dots

Then it would get confused with domain names (e.g. babe.cafe).

Yeah. I think that's actually my one, biggest gripe about IPv6, those damn colons. And those damn brackets that were made to mitigate the colons, that just cause more problems:

Just yesterday I tried to use rsync (like I do all the time, in my mind there's no reason to use scp when rsync does everything better), but this time I needed to specify an IPv6 address. On the (admittedly ancient) rsync version that comes with macOS, this doesn't work:

rsync foo 'user@[fe80::4]:/tmp'

Note how I had to put the second argument in quotes, because otherwise the shell tries to expand the square brackets as filename expansion.

But even then rsync just complains, because rsync itself separates host from path through colon. I think the only workaround is to do something like `rsync -e 'ssh user@[fe80::4] ...'`... but I just used an updated rsync from homebrew, which is of course the saner method. Still, just another colon/bracket-caused issue.

I wonder why IPv6 didn't catch on! It's just unergonomic and ugly!

At work, I have a rare case of a useful application of IPv6: setting IPv4 addresses. We have multiple embedded devices in one product which all got the same default IPv4. But their serials map to their MACs which map to their link-local IPv6.

So workers scan the serial and I connect to all devices at once via their IPv6 address. Then, I set their individual IPv4 address and that's all I do via IPv6.

That RFC is obsoleted by https://datatracker.ietf.org/doc/html/rfc9844 which removes all guidance around URIs:

> This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.

I have published a fix to the post, it should be live within a minute. Thanks!

https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebd...

Link local addresses are exactly that. They don't route and they are for low level stuff like adding stuff to the routing table or BGP.

If you want to do this properly then you configure a Unique Local Addresses (ULA) out of the range fc00::/7. These are the equivalent of 192.168 or 172.16 or 10. and they can be routed.

Trying to run services on fe80: addresses is a mistake IMHO

No. A well set up network never needs them at all. But I can see the usefulness

Think of that you want to Provision a "smart device" with just a computer and no router.

These link local addresses are quiet handy. But sadly the parsing of these with modern browsers is a flame war ever since. I assume that's the reason why we don't see its usage that often.

Another nice use case is to use these link local addresses in cloud environments...

Who says Go's handling of the corner case is incorrect? The original IPv6 RFCs didn't address the case at all. Then in 2013 RFC6874[1] clarified that the % in the zone identifier MUST be percent encoded when used in a URI, just like Go requires. Then in 2025 this RFC was obsoleted by RFC 9844, which only talks about UI behavior and says nothing about URIs, basically reverting things back to the undefined state prior to 2013. What a fucking mess.

[1] https://www.rfc-editor.org/info/rfc6874/

[2] https://www.rfc-editor.org/info/rfc9844/

Added to https://github.com/globalcitizen/taoup/

Honestly, I can't really say he's wrong...

Except that % is already used to encode something else.

Now if someone else a URI, is there going to be any confusion on how many times a URI needs to be decoded?

If the answer is yes, then we have a problem.

(and by looking at the other comments in this thread, the answer is most definitely yes)