230 lines
8.8 KiB
Markdown
230 lines
8.8 KiB
Markdown
title: Support for IPv6 link local addresses in browsers
|
|
---
|
|
pub_date: 2021-06-14
|
|
---
|
|
author: ungleich
|
|
---
|
|
twitter_handle: ungleich
|
|
---
|
|
_hidden: no
|
|
---
|
|
_discoverable: yes
|
|
---
|
|
abstract:
|
|
Tracking the progress of browser support for link local addresses
|
|
---
|
|
body:
|
|
|
|
## Introduction
|
|
|
|
Link Local addresses
|
|
([fe80::/10](https://en.wikipedia.org/wiki/Link-local_address)) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=700999). 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](https://whatwg.org/) is that there is a
|
|
[closed bug report on github](https://github.com/whatwg/url/issues/392)
|
|
and [in the spec it says](https://url.spec.whatwg.org/#concept-ipv6)
|
|
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](https://www.w3.org/) there is a
|
|
bug titled
|
|
[Support IPv6 link-local
|
|
addresses?](https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2)
|
|
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)](https://datatracker.ietf.org/doc/html/rfc6874#section-2).
|
|
|
|
## IPv6 link local address support in Chrome / Chromium
|
|
|
|
On the chrome side there is a
|
|
[huge bug
|
|
report](https://bugs.chromium.org/p/chromium/issues/detail?id=70762)
|
|
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](https://website.peterjin.org/wiki/Snippets: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](https://github.com/twisteroidambassador/prettysocks/tree/ipv6-literal)
|
|
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](https://IPv6.chat) and let us
|
|
know about it.
|