ungleich-staticcms/content/u/blog/ipv6-link-local-support-in-browsers/contents.lr

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.