Which browsers support IPv6 link-local addresses

[sput]

Hi there


Does anyone know which browsers support IPv6 link-local addresses?


Regards,
Rob

[kasperd]

Does anyone know which browsers support IPv6 link-local addresses?

The answer might depend on a few more details than just which browser you use.

Because the link local prefix is the same on all network segments, the address may need to explicitly specify an interface. For example to access fe80::1 through eth0, you may have to write the IP address as fe80::1%eth0. However this introduces another possibility for misunderstandings, because it is not immediately obvious, if the % character is supposed to be URL encoded or not.

I tested the following formats in one version of Chromium
http://[fe80::1]/
http://[fe80::1%eth0]/
http://[fe80::1%25eth0]/

The first format appeared to be supported by the browser, but was rejected by the kernel due to missing identifier specification. The other two formats did not work at all, it seems the browser didn't even try to load them, so I guess it just doesn't support either format. I have no idea if that means Chromium expects another format, than what I tried, or that it does not properly support link local addresses.

I have used link local addresses in a Firefox version dating about three years back. But that was on a computer with only one active network interface, which may have helped. Putting a link local address in a AAAA record is not considered good practice, but it might just work, if you only have one interface active - that is. There is no ambiguity about the format in that case, but specifying a network interface is not possible.

My personal opinion on how this problem should be solved is, that if an application try to connect to a link local address without explicitly specifying an interface, then the default behaviour of the kernel should be to perform neighbor discovery on all interfaces, unless it already know an interface, which can be used to reach that IP address.

[sput]

Hi there


'http://[fe80::1%25eth0]/' is the correct syntax. Some systems support interface numbers, EG: 'http://[fe80::1%251]/'.
Chromium does not support IPv6 link-local addresses. Older versions of Firefox did, more recent do not.


Regards,
Rob

[kasperd]

Older versions of Firefox did, more recent do not.

Why would they remove the support, if it was working already?

[sput]

Hi there

Why would they remove the support, if it was working already?

If you do a bit of searching you'll find that;
- There have been numerous bug reports.
- The responses to these don't make sense.
- Sometimes using the IPv6 link-local address is the only way to access
  an embedded device.


Regards,
Rob

[kasperd]

If you do a bit of searching you'll find that;
- There have been numerous bug reports.

The bug reports I could find are older than a version of Firefox, which I know works. However they do suggest the problem is that the browser lacks support for any format of device identifier, and not that it won't accept a link-local address.

That means there is a few different possible ways around this limitation

• Fix the URL parsing in the browser
• Have the browser try all available interface identifiers after parsing a link-local address without scope
• Have the kernel do neighbor discovery on all interfaces, when an application gives a link-local address without scope
• Use a computer with only one active interface

- Sometimes using the IPv6 link-local address is the only way to access
  an embedded device.

That is actually my preferred method because the link-local address is usually static regardless of the configuration of the device. There are however exceptions. For example I have come across Netgear modems, which actually have a different MAC address depending on how they are configured. In bridging mode they use one single MAC address, which appear to be identical across all modems of that model. When configured as a router, they use their own MAC addresses.

[kasperd]

I found that lynx can handle interface specification in URLs, as long as the % is not URL encoded. It works both with interface names and interface indices.

[sput]

Hi there

I found that lynx can handle interface specification in URLs, as long as the % is not URL encoded. It works both with interface names and interface indices.

Indeed!
Apparently Lynx doesn't support ip addresses in the 'no_proxy' environment variable, so I had to disable http_proxy.
Hostnames pointing to IPv6 link-local addresses (reverses look nice in netstat) don't work. It has to be addresses.
Apache chokes on the 'Host: ' request header line. A small httpd which I wrote recently (I get bored sometimes) works (it ignores the 'Host: ' request header line).

You are right about the device identifier / zone index bit.
So my question should be: Which (GUI) webbrowsers support zone indices?


Regards,
Rob

[kasperd]

You could use a proxy to work around the problem. If you have an http proxy listening on localhost, then that proxy could take requests for link local addresses and attempt to connect to the address through every interface. Then you just need to get the browser using that proxy whenever a link local address is entered. It would be a very simple proxy selection script to instruct the browser to use that proxy only if the hostname starts with fe80::

Firefox can be instructed to load the proxy selection script from a local file.

[sput]

Hi there


I was trying to avoid this;
- Made a list of all FOSS cross platform browsers.
- Looked at which ones are available as Debian package.
- Installed them.
- Tested them.

Conclusion;
None of the GUI browsers support zone indices. But (at least) some text mode browsers do.


Regards,
Rob

[kasperd]

I noticed something, which might be relevant to this thread. The version of mtr installed on my system does not support interface identifiers. If I try to specify an interface identifier, it is just ignored. However if the link local address I try to reach is already in the neighbor cache, then mtr can reach it without needing an interface identifier.

It may be worth testing if any of the browsers which support an IPv6 address in the URL, but not an interface identifier, behaves in a similar way. So from a command line ping the target IPv6 address on the proper interface. And while that ping command is running try to type the address in a browser without interface identifier. I have no idea if this has any chance of working, but I think it may be worth a try.

[kasperd]

I came across this list on Wikipedia, which says Konqueror and Firefox support Zone ID.

[kasperd]

I found a workaround, which solves this problem for me. I needed to access the webserver on a cablemodem of which I only had the IPv6 link local address readily available. Moreover I happened to not be on the LAN where the modem is connected, so I had to use ssh portforwarding to be able to reach the modem. So I used this command on my laptop:

Code Select Expand

ssh -L '8080:[fe80::209:5bff:fede:ad02%eth0]:80' redacted.kasperd.netIt turns out this works just fine. Now I can just point the browser at localhost:8080 and access that webserver. The reason I used the port forwarding was that I was on a different LAN, but it turns out a side-effect is working around the lack of scope identifier in the URL. So if I were already on the same LAN, I could just ssh to ::1 instead and use the exact same workaround.