Introduction
Link Local addresses (fe80::/10) are used for addressing devices in your local subnet. They can be automatically generated and using the IPv6 multicast address ff02::1, all hosts on the local subnet can easily be located.
However browsers like Chrome or Firefox do not support entering link local addresses inside a URL, which prevents accessing devices locally with a browser, for instance for configuring them.
Link local addresses need zone identifiers to specify which network device to use as an outgoing interface. This is because you have link local addresses on every interface and your network stack does not know on its own, which interface to use. So typically a link local address is something on the line of fe80::fae4:e3ff:fee2:37a4%eth0, where eth0 is the zone identifier.
Them problem is becoming more emphasised, as the world is moving more and more towards IPv6 only networks.
You might not even know the address of your network equipment anymore, but you can easily locate iit using the ff02::1 multicast address. So we need support in browsers, to allow network configurations.
Status of implementation
The main purpose of this document is to track the status of the link-local address support in the different browsers and related standards. The current status is:
- Firefox says whatwg did not define it
- Whatwg says zone id is intentionally omitted and and reference w3.org
- w3.org has a longer reasoning, but it basically boils down to "Firefox and chrome don't do it and it's complicated and nobody needs it"
- Chromium says it seems not to be worth the effort
Given that chain of events, if either Firefox, Chrome, W3.org or Whatwg where to add support for it, it seems likely that the others would be following.
IPv6 link local address support in Firefox
The progress of IPv6 link local addresses for Firefox is tracked on the mozilla bugzilla. The current situation is that Firefox references to the lack of standardisation by whatwg as a reason for not implementing it. Quoting Valentin Gosu from the Mozilla team:
The main reason the zone identifier is not supported in Firefox is
that parsing URLs is hard. You'd think we can just pass whatever
string to the system API and it will work or fail depending on whether
it's valid or not, but that's not the case. In bug 1199430 for example
it was apparent that we need to make sure that the hostname string is
really valid before passing it to the OS.
I have no reason to oppose zone identifiers in URLs as long as the URL
spec defines how to parse them. As such, I encourage you to engage
with the standard at https://github.com/whatwg/url/issues/392 instead
of here.
Thank you!
IPv6 link local address support in whatwg
The situation at whatwg is that there is a closed bug report on github and in the spec it says that
Support for <zone_id> is intentionally omitted.
That paragraph links to a bug registered at w3.org (see next chapter).
IPv6 link local address support at w3.org
At w3.org there is a bug titled Support IPv6 link-local addresses? that is set to status RESOLVED WONTFIX. It is closed basically based on the following statement from Ryan Sleevi:
Yes, we're especially not keen to support these in Chrome and have
repeatedly decided not to. The platform-specific nature of <zone_id>
makes it difficult to impossible to validate the well-formedness of
the URL (see https://tools.ietf.org/html/rfc4007#section-11.2 , as
referenced in 6874, to fully appreciate this special hell). Even if we
could reliably parse these (from a URL spec standpoint), it then has
to be handed 'somewhere', and that opens a new can of worms.
Even 6874 notes how unlikely it is to encounter these in practice -
"Thus, URIs including a
ZoneID are unlikely to be encountered in HTML documents. However, if
they do (for example, in a diagnostic script coded in HTML), it would
be appropriate to treat them exactly as above."
Note that a 'dumb' parser may not be sufficient, as the Security Considerations of 6874 note:
"To limit this risk, implementations MUST NOT allow use of this format
except for well-defined usages, such as sending to link-local
addresses under prefix fe80::/10. At the time of writing, this is
the only well-defined usage known."
And also
"An HTTP client, proxy, or other intermediary MUST remove any ZoneID
attached to an outgoing URI, as it has only local significance at the
sending host."
This requires a transformative rewrite of any URLs going out the
wire. That's pretty substantial. Anne, do you recall the bug talking
about IP canonicalization (e.g. http://127.0.0.1 vs
http://[::127.0.0.1] vs http://012345 and friends?) This is
conceptually a similar issue - except it's explicitly required in the
context of <zone_id> that the <zone_id> not be emitted.
There's also the issue that zone_id precludes/requires the use of APIs
that user agents would otherwise prefer to avoid, in order to
'properly' handle the zone_id interpretation. For example, Chromium on
some platforms uses a built in DNS resolver, and so our address lookup
functions would need to define and support <zone_id>'s and map them to
system concepts. In doing so, you could end up with weird situations
where a URL works in Firefox but not Chrome, even though both
'hypothetically' supported <zone_id>'s, because FF may use an OS
routine and Chrome may use a built-in routine and they diverge.
Overall, our internal consensus is that <zone_id>'s are bonkers on
many grounds - the technical ambiguity (and RFC 6874 doesn't really
resolve the ambiguity as much as it fully owns it and just says
#YOLOSWAG) - and supporting them would add a lot of complexity for
what is explicitly and admittedly a limited value use case.
This bug references the Mozilla Firefox bug above and RFC3986 (replaced by RFC 6874).
IPv6 link local address support in Chrome / Chromium
On the chrome side there is a huge bug report which again references a huge number of other bugs that try to request IPv6 link local support, too.
The bug was closed by cbentzel@chromium.org stating:
There are a large number of special cases which are required on core
networking/navigation/etc. and it does not seem like it is worth the
up-front and ongoing maintenance costs given that this is a very
niche - albeit legitimate - need.
The bug at chromium has been made un-editable so it is basically frozen, besides people have added suggestions to the ticket on how to solve it.
Work Arounds
IPv6 link local connect hack
Peter has documented on the IPv6 link local connect hack to make firefox use fe90:0:[scope id]:[IP address] to reach fe80::[IP address]%[scope id]. Checkout his website for details!
IPv6 hack using ip6tables
Also from Peter is the hint that you can also use newer iptable versions to achieve a similar mapping:
"On modern Linux kernels you can also run
ip6tables -t nat -A OUTPUT -d fef0::/64 -j NETMAP --to fe80::/64
if you have exactly one outbound interface, so that fef0::1 translates to fe80::1"
Thanks again for the pointer!
The prettysocks SOCKS5 proxy (update 2021-11-24)
On 2021-11-23 we have been notified that there is a new workaround available: prettysock is a Socks5 proxy written in python that allows the use of Microsoft's ipv6-literal.net domain, but from any OS or browser, which is pointed to the proxy. So to access fe80::1ff:fe23:4567:890a%3, configure your browser to use the local prettysocks Socks5 proxy, replace the link local address with fe80--1ff-fe23-4567-890as3.ipv6-literal.net and there you go.
There are two interesting things to say about this solution:
- It is a very simple solution
- It is surprising that browser vendors haven't implement such a simple solution themselves so far - does it need an RFC that defines the domain to be used?
Other resources
If you are aware of other resources regarding IPv6 link local support in browsers, please join the IPv6.chat and let us know about it.