Address types [LWN.net]

Address types

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

In practice it seems that you can configure Chrome and Firefox with additional address ranges to be considered 'local', so in that regard the spec is probably doing all it can in the absence of a mechanism to signal that information to clients automatically.

I'm still not sure what I think about the spec allowing access to link-local IPv6 addresses at all... I wonder if browsers will also have a mechanism to specify address ranges that should be blocked entirely...

to post comments

Address types

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

Access to link-locals is necessary in some circumstances, and I'd be annoyed if it were completely blocked, because (for example), I've encountered devices that use mDNS and their IPv6 link-local to advertise their presence if there's no IPv4 or RAs on the link, and I'd be unhappy if browsers made the decision that the only way to configure such devices was with a manufacturer app, and not the browser I already use.

That doesn't mean this shouldn't be locked down and trigger warnings - just that it should be possible for me to click through and tell the browser that when I went to home-gateway-setup.local, I'm not surprised that I ended up accessing fe80::abcd:1234:5678:9abc%eno1.

Address types

Posted Jul 24, 2026 9:16 UTC (Fri) by cortana (subscriber, #24596) [Link] (7 responses)

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!

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.

Address types

Posted Jul 24, 2026 10:15 UTC (Fri) by taladar (subscriber, #68407) [Link]

The prime example of address ranges that should be blocked entirely are those blocks reserved for example/documentation purposes.