Lan? [LWN.net]

Lan?

Posted Jul 23, 2026 9:31 UTC (Thu) by taladar (subscriber, #68407)
In reply to: Lan? by mbunkus
Parent article: Firefox 153 released

You can probably assume at the very least that IPv6 link-local addresses should not be accessed from public addresses since those don't even map to the same device on every client.

to post comments

Lan?

Posted Jul 23, 2026 20:32 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (15 responses)

"Public" is not really a thing in IPv6 land. Other terms are, such as "globally routable". You're absolutely correct that link-local addresses aren't globally routable; it's in the name, after all — they only have meaning in combination with a single link (interface), hence the <address>%<link> syntax (e.g. fe80::1%ens18) and aren't routable as interface names are machine-local and not part of the IPv6 header itself.

That doesn't mean that those link-local addresses reachable from but not belonging to your machine are in any way trustworthy (think e.g. DMZs are network segments shared with other customers and bad isolation at the layer 2 level).

Address types

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

Part of the issue is that the very concept of "public" and "private" addresses isn't really something the network knows about, and we have no protocol to tell applications where the network boundaries actually are.

On the other hand, humans have no problem knowing where the boundaries are, and expect (sometimes unreasonably) that the computer will know which addresses go to their current ISP, and which ones stay within the site.

This is an unresolvable tension in general (and can happen even with IPv4 - for example, in places that are moving towards a "BeyondCorp" setup, but where you still have privileged access to hosts if you're on the VPN or the corporate network, which results in the host having a globally routable address that should be treated as "local", not "public"), and thus the "local network access" restrictions are inevitably an approximation, not perfection.

Now, maybe there should be a mechanism that lets the network stacks tell the client "all of 2001:db8:104::/48 is local" (from a DHCP option, or a router advertisment, perhaps), and lets the VPN client add "and 192.0.2.0/24 is also local", but today that mechanism doesn't exist.

Address types

Posted Jul 24, 2026 8:53 UTC (Fri) by cortana (subscriber, #24596) [Link] (10 responses)

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

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.

Address types

Posted Jul 24, 2026 9:12 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (2 responses)

Spot on.

I'd even go one step further and argue that "private" or "local" doesn't even have any real meaning wrt. security. Just because it runs on the same layer 2 broadcast domain doesn't mean it should be trusted. Just because it runs in the same physical or virtual machine doesn't mean it should be trusted. And yes, this includes the loopback interface[1].

Security has meaning in specific contexts & under well-stated conditions. It can mean that you trust "local" machines in the same "private" subnet enough to allow ssh connections from them, because you control all of them & the underlying network hardware, but that's a policy decision by assigning semantics to the property "source IP subnet". Those semantics aren't inherent or automatically detectable.

[1] There have been way too many instances of incredibly sensitive programs such as anti-virus tools have a port open on 127.0.0.1 & trusted connections from it, only to be exploited by malware running in your browser or elsewhere on your host.

Security of "private" or "local" addresses

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

In the browser context, the meaning is reversed from what you're saying - which is the "BeyondCorp" position of "everything must be treated as exposed to attackers anyway, so why not set things up such that you don't trust the local network more than the wider Internet?.

Browsers want to treat the local network as less trusted than the wider Internet, on the basis that it's more likely that someone has unintentionally trusted the local network than that they've unintentionally trusted the wider Internet.

Security of "private" or "local" addresses

Posted Jul 24, 2026 10:27 UTC (Fri) by knewt (subscriber, #32124) [Link]

Isn't it actually the opposite of this? It's still that you're not trusting the wider Internet here, right?

The way the new restrictions work, iirc, is that a website from a 'less trusted' address space is not allowed to talk to devices from a 'more trusted' address space unless you give specific permission.

So a 'remote' website that wants to do so - eg, a device/iot management page that wants to talk directly to the device from within your browser, or the plex.tv web app talking directly to your local media server - is not trusted to talk to the local device by default.

And iirc it also goes local -> localhost. So in the common situation nowadays of having software running on your local machine that uses a web management interface as the UI, listening only on localhost, some random website - even a website running on another local machine - can't access that without you giving it permission.