Is this really a Python problem? `subprocess.run` for example defaults to `shell=False` so you have to set `shell=True`, and on top of that be building up argv?

The "default" API for `subprocess.run` has you doing `subprocess.run(["ping", ip])` which... I think just entirely avoids this problem?

There's def a general sort of "oh people will just copy/paste stuff into a shell" or the whole shell script arg escaping mess. Just feels like Python is not really doing anything bad here.

Granted, a lot of software works like that, but the command line was invented as a human interface, we just bungee-strapped a computer instead.

  --- a/netwerk/base/nsURLHelper.cpp
  +++ b/netwerk/base/nsURLHelper.cpp
  @@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) {
   bool net_IsValidIPv6Addr(const nsACString& aAddr) {
  -  return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr);
  +  return true;
   }

  bool net_IsValidIPv6Addr(const nsACString& aAddr) {
    struct addrinfo *res, hints = {.ai_flags = AI_NUMERICHOST};
    int err = getaddrinfo(aAddr.get(), nullptr, &hints, &res);
    if (err) return false;

    bool isValid = res[0].ai_family != AF_INET;

    freeaddrinfo(res);
    return isValid;
  }

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.

Just give me GUAs and be done with it.

Is there an equivalent syntax for IPv4 addresses?

The _routing_ system does. You have the same problem if you have multiple public IPs on a machine. Your local routing will not automatically return packets back through the address they came to. They will go to the _default_ route. So if you have this configuration you need to setup either the routing tables or the firewall to re-route packets "back out" the proper interface or IP address.

This is strictly a routing problem and not an addressing problem.

Ideally, you’d be able to connect a PC and a printer with an Ethernet cable, they would both (having failed to find a better alternative) allocate a link-local address for themselves, and then the PC would use DNS-SD over mDNS to discover the printer and show it to you. Similar story with PCs exporting their media files over the network, a—say—set-top box, and a switch they’re all plugged into.

And for some combinations of parts this actually works. It’s just that the functionality is not always well-exposed by the OS, that a switch + DHCP server in a box (in practice, a consumer router) can work just as well with no configuration as an unmanaged switch can, and that people are not that interested in local-only wired networks anymore.

There’s also the “having failed to find a better alternative” part: unlike with IPv6, the RFC does not endorse always assigning a link-local address as the second one next to a static or DHCP-provided one, I’m guessing for software compatibility. Thus you really only see 169.254.* in your interface configuration when DHCP is borked, and it’s kind of useless in that case.

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

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 already, 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.

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.

Link-local ipv6 addresses are not designed for the use case of serving web applications.

  fe80::/64 dev eth0 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.11 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.13 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.14 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.15 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.16 proto kernel metric 256 pref medium

NDP. That's a discovery protocol not an elimination protocol. There's no guarantee that a link local address isn't available on multiple networks.

> the OS will pick the one

Linux will simply pick the first entry in the routing table. It may make this appear as if it's working by default or some underlying magic; however, it's literally just the very first entry that matches.

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

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...

> 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.

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

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

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

Even though it's rare, I actually do use it if I want to talk to another host on a very specific interface. Sometimes there's multiple paths.

If the mapping between the logical and physical interfaces changes, that probably means that your NICs lack proper IDs to differentiate them or the bus topology is somehow not stably sorted. I wouldn't blame the OS for this.

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)