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 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. ``` 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.