diff --git a/content/u/blog/ipv6-link-local-support-in-browsers/contents.lr b/content/u/blog/ipv6-link-local-support-in-browsers/contents.lr new file mode 100644 index 0000000..49e30b0 --- /dev/null +++ b/content/u/blog/ipv6-link-local-support-in-browsers/contents.lr @@ -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 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 +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 that the 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 '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 '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 '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. +```