Address types [LWN.net]

Address types

Posted Jul 24, 2026 9:16 UTC (Fri) by cortana (subscriber, #24596)
In reply to: Address types by farnz
Parent article: Firefox 153 released

I was under the impression that some browsers don't let you access link-local addresses anyway. If you don't know the interface identifier (which varies between machine & platform) then you can't form a URL to it, and the URL spec doesn't officially support interface identifiers in any case... or so it was when I last looked at it. That is what brought me around to thinking that link-local addresses are not suitable to use for accessing services, and that a ULA prefix should be used if GUA is not available. In practice (sadly) we'll always have IPv4!

to post comments

Address types

Posted Jul 24, 2026 9:33 UTC (Fri) by farnz (subscriber, #17727) [Link] (6 responses)

It varies - IME, they can do it via mDNS names, using the mDNS link to choose the interface to use, but not when typed in manually or via a link unless you know the platform-specific interface identifier (which, of course, malicious code can guess via the Navigator.platform property).

Address types

Posted Jul 24, 2026 11:14 UTC (Fri) by cortana (subscriber, #24596) [Link] (5 responses)

Huh, I thought that NSS didn't pass the interface identifier determined by Avahi back to the application doing the lookup, making it impossible to access a service with a link-local address.

Address types

Posted Jul 24, 2026 22:12 UTC (Fri) by neggles (subscriber, #153254) [Link] (4 responses)

I'm not sure if that's true, but even if so, NSS isn't the only way to do name:address mappings (systemd has an alternative interface IIRC?), and the application could just look for the address's entry in the neighbour list (`ip neigh`) to determine which interface to use; if the mDNS lookup succeeded, the target address will be in there

Address types

Posted Aug 21, 2026 11:03 UTC (Fri) by cortana (subscriber, #24596) [Link] (3 responses)

I don't think applications would want to have to implement logic like "resolve the address, oh it's IPv6 link-local, let's look at the neighbour table to find out which interface to use..."

As for the problem with Avahi: it appears that Avahi's nss_mdns implements _nss_mdns_gethostbyname2_r which can't pass interface identifiers back to glibc; whereas systemd's nss_resolve implements _nss_resolve_gethostbyname4_r which can pass interface identifiers back to glibc.

So Firefox would be able to connect to services identified via mDNS but only if nss_resolve is used for mDNS instead of nss_mdns; as far as I am aware, this is not the case in Fedora or Debian at least. Maybe it's time to put Avahi out to pasture, but I presume there are good reasons that it's still used in preference to systemd-resolved by these distros.

Address types

Posted Aug 21, 2026 11:27 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (2 responses)

Given mDNS implementation in systemd, I was expecting Avahi to be long dead and systemd to hijack Avahi's DBUS interface.

That didn't happen?

Maybe systemd still lacks ability to publish static services? My /etc/avahi/services contains couple of files, last touched twenty years ago.

Address types

Posted Aug 21, 2026 14:18 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

Maybe systemd still lacks ability to publish static services? My /etc/avahi/services contains couple of files, last touched twenty years ago.

systemd-resolved does not, in fact, lack the ability to publish static services (systemd.dnssd(5) tells us how), but it does lack the ability to publish dynamic services (or compatibility with Avahi's D-Bus interface in general), which is why we can't get rid of Avahi altogether (highly unfortunately).

Address types

Posted Aug 22, 2026 21:30 UTC (Sat) by intelfx (subscriber, #130118) [Link]

but it does lack the ability to publish dynamic services

Oh, I was wrong here.

$ busctl --system introspect org.freedesktop.resolve1 /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager
NAME                               TYPE     SIGNATURE     RESULT/VALUE                             FLAGS
<...>
.RegisterService                   method   sssqqqaa{say} o                                        -
<...>
.UnregisterService                 method   o             -                                        -

But, no compatibility with the (much more extensive) Avahi D-Bus interface—or any of Avahi's alternative APIs which are wrappers over the above.