Lan? [LWN.net]

Lan?

Posted Jul 22, 2026 11:04 UTC (Wed) by cortana (subscriber, #24596)
In reply to: Lan? by farnz
Parent article: Firefox 153 released

Sadly hardcodes way too many address space assumptions. Networks which use allocated IPv4 address space, and all IPv6 GUA and ULA addresses are considered 'public' by the specification!

to post comments

Lan?

Posted Jul 22, 2026 11:24 UTC (Wed) by TomH (subscriber, #56149) [Link]

Yes which leads to the kind of hilarious issue I saw this morning where Chrome reported a CORS issue doing an HTTP load from a machine to itself, claiming that it needed HTTPS to load from a less-public context than the page.

The reason? The initial page load happened over IPv6 which has a real public address, and was therefore public context, while the resource it tried to load was loading (for whatever reason) over IPv4 which was an RFC1918 address behind NAT and was hence considered a private context.

Lan?

Posted Jul 22, 2026 13:07 UTC (Wed) by dskoll (subscriber, #1630) [Link] (22 responses)

That seems bizarre. Shouldn't all networks actually associated with interfaces on the machine be considered local?

Lan?

Posted Jul 22, 2026 13:19 UTC (Wed) by TomH (subscriber, #56149) [Link] (3 responses)

That might make sense, but it's not how https://wicg.github.io/local-network-access/#ip-address-s... says the decision should be made.

Lan?

Posted Jul 22, 2026 13:29 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

I think the Mozilla developers have made a fundamental misunderstanding. The document you link to that defines "local" addresses refers, I believe, to those addresses that may be managed locally without requiring coordination with the wider Internet.

But for security purposes, again IMO, "local" addresses should refer to those addresses that are directly on the LAN... in other words, everything that is 1 hop away at most. For more security, it should probably also refer to locally-managed addresses described in your link because a lot of companies do route those addresses internally and they may be more than 1 hop away. So a union of the two.

Lan?

Posted Jul 22, 2026 17:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Welcome to IPv6, the world of recursive WTFs!

There is no concept of "local" networks in IPv6, there is a notion of "on-link" networks. Which does not _necessarily_ correspond to the networks that are directly accessible in the same Ethernet collision domain.

That's because IPv6 uses multicasts instead of broadcasts for neighbor discovery, so you can have a multicast router bridging multiple Ethernet segments together. Just like proxy ARP in IPv4, but in IPv6 it's actually exposed to the host.

For an additional fun, on-link relations do not necessarily have to be transitive and they can have overlapping prefix lengths.

See: https://datatracker.ietf.org/doc/html/rfc5942 and https://datatracker.ietf.org/doc/html/rfc4943

Lan?

Posted Jul 23, 2026 9:23 UTC (Thu) by taladar (subscriber, #68407) [Link]

While most (non-server) devices are not directly connected to the internet you can not necessarily assume that just because a device has a subnet on a local interface that that subnet isn't a public network.

Lan?

Posted Jul 22, 2026 17:12 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (17 responses)

I know several hosters that hand out one public IPv6 (GUAs) with a 64 subnet mask per VM. This means that all the VMs of other customers are on the same /64 subnet as yours. An effed up practice, no doubt.

On the other hand you usually use GUA IPv6 addresses on truly local networks, too, meaning in the same sense that e.g. all neighboring machines on a 192.168.1.0/24 is usually considered to be "local" & part of the same security zone.

Therefore you cannot derive any kind of sense of "belongs to the same security zone"from the IPv6 addresses assigned to a machine's interfaces.

Lan?

Posted Jul 23, 2026 9:31 UTC (Thu) by taladar (subscriber, #68407) [Link] (16 responses)

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.

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.

Lan?

Posted Jul 22, 2026 15:36 UTC (Wed) by cortana (subscriber, #24596) [Link]

Self-correction: ULA is considered private. Sorry.