Support IPv6 zone identifiers

[DemiMarie]

Currently, there is no way to point a browser at fe80::1%lo.

Proposed syntax: https://[fe80::1%25lo]:80

[annevk]

As noted at https://url.spec.whatwg.org/#concept-ipv6 this is intentionally omitted per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2.

[DemiMarie]

Does that mean that users are expected to use a proxy for such situations? Most users do not have such a proxy installed.

…

On Mon, Jun 4, 2018, 12:19 AM Anne van Kesteren ***@***.***> wrote: As noted at https://url.spec.whatwg.org/#concept-ipv6 this is intentionally omitted per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#392 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB-oQ7hfKNXsBMDK_DInSeZM4efoVks5t5LVigaJpZM4UYPOB> .

[annevk]

They have to find an alternative, yes.

[DemiMarie]

What about requiring browsers to prompt the user for an interface whenever an address in the fe80::/10 block is entered into the URL?

…

On Thu, Jun 7, 2018, 11:22 PM Anne van Kesteren ***@***.***> wrote: They have to find an alternative, yes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#392 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB4-MGN77dhpVZNwFpjthSnlVfVEWks5t6e4GgaJpZM4UYPOB> .

[annevk]

What would the prompt say? (FWIW, I doubt any browser would find that acceptable, and it adds a lot of complexity as we'd have to handle the syntax everywhere, which would lead to tons of issues.)

[DemiMarie]

“Please select a network that your computer is connected to” with a pop-up listing of all interfaces. That said, considering the super-niche nature of this, I feel like one approach that might work would be to allow users to pass the interface as a command line argument.

…

On Fri, Jun 8, 2018, 11:28 PM Anne van Kesteren ***@***.***> wrote: What would the prompt say? (FWIW, I doubt any browser would find that acceptable, and it adds a lot of complexity as we'd have to handle the syntax everywhere, which would lead to tons of issues.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#392 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBxrzlGgcDdQLRL-eW47Fr4otrkIbks5t60D6gaJpZM4UYPOB> .

[telmich]

With reference to https://bugzilla.mozilla.org/show_bug.cgi?id=700999 I request this bug to be re-opened. I will re-iterate the problem that is caused by the lack of link local address support in here for completeness:

I've subscribed to this bug some time ago, because Firefox is essentially preventing to configure newer network devices. I'll elaborate shortly and I ask for clarification from the Mozilla team how to handle this:

• newer devices all support IPv6 and configure link local addresses
• Using the multicast address ff02::1 it is possible to find out the link local address of any directly connected device

Given this background, we often have the situation of devices coming back from customers with any kind of IP configuration. The only plausible way to find the device is using above link local discovery. The IPv4 addresses are often unknown or undiscoverable.

• Some devices can only be configured via http (i.e. ssh, telnet, tftp are off)

So we are basically in the situation that the link local address is the only reliable address that can be used to configure a whole class of devices.

I often hear the argument that with link-local addresses it would be possible to do Javascript based LAN scanning. I am not denying that, however the same is true for IPv4 - you can easily scan 192.168.x.y/24.

Even with this inconsistent security claim in mind, I ask the mozilla developers to at least include support for link local with something on the line of about:config->ipv6-allow-link-local: [false,true] to not stop all network engineers from working.

Can we reopen this bug or create a new one for realising this?

[telmich]

Update: as this bug is cross-referencing other resources in each and every bug report, I tried to summarise it on https://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/

[afcady]

This needs to be reopened because firefox is citing this bug as blocking its own fix of the issue.

This issue is holding up the entire IPv6 project, in case that isn't clear.

There's a lot of game playing around these issues because a lot of money is at stake when it comes to who controls domain names, and this is a way to break domain name systems that compete with ICANN & CAs.

So the developers of browsers are pretending that this is complicated when it isn't.

It's actually very simple and there's exactly one way to implement it which is very obvious. But implementing it that way is going to step on some toes of people who don't want IPv6 global connectivity and a new p2p internet foundation to happen. It goes against a lot of business models.

[afcady]

By the way. It's a bug to ever strip the zone identifier before sending it from the client.

The way that HTTP works is, the client sends its own name for the server to the server itself. The server never uses this name to establish IP connectivity. The server can then send the name back to the client in links, who can use it to re-establish IP connectivity by clicking a link, or bookmarking it and opening the bookmark, for example.

Since the server NEVER uses the name to establish IP connectivity, but only sends it to the client;
and since the client MAY use the name to establish IP connectivity,
therefore: the name MUST be the name that establishes IP connectivity on the client's system.

[becarpenter]

To try and unblock this issue, we've posted a draft update to RFC6874 and discussion is open. Details at https://mailarchive.ietf.org/arch/msg/ipv6/i5LUQN9vU9MryNWtvS_M_O7Wgjc/.
The draft itself is here.

[telmich]

Much appreciated, @becarpenter !

[afcady]

That doesn't fix the percent encoding.

[becarpenter]

@afcady, we are stuck with % meaning two things. The discussion on ipv6@ietf.org is tending towards requiring only the %25eth0 escape encoding and dumping the suggestion to allow %eth0 heuristically.