Tracking IPv6 link local support in browsers
This commit is contained in:
Nico Schottelius
parent
996b5826b2
commit
761a93ec7a
1 changed files with 173 additions and 0 deletions
173
content/u/blog/ipv6-link-local-support-in-browsers/contents.lr
Normal file
173
content/u/blog/ipv6-link-local-support-in-browsers/contents.lr
Normal file
|
|
@ -0,0 +1,173 @@
|
||||||
|
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
|
||||||
|
"Chrome does not do it and it's complicated and nobody needs it"
|
||||||
|
* Chromium says it seems not to be worth the effort
|
||||||
|
|
||||||
|
## 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 bugreport 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.
|
||||||
|
```
|
||||||
Loading…
Add table
Add a link
Reference in a new issue