Closed Bug 700999 Opened 13 years ago Closed 2 months ago

Firefox does not appear to support IPv6 link-local addresses

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kerlyn, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: regression, Whiteboard: [ipv6][necko-triaged]) 

User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110920 Firefox/3.6.23
Build ID: 20110920075126

Steps to reproduce:

This bug is a regression of #392428 (see comment there as well).  When I enter e.g.,
"http://[fe80::206:98ff:fe00:232%tap0]/" in the location bar in either Firefox 7.0.1 or 8.0 it
fails with an Alert.  Works with Firefox 3.6.23.  This bug is probably in the Networking
component (which no longer appears to be a choice in Bugzilla).


Actual results:

Alert "The URL is not valid and cannot be loaded."


Expected results:

The website should have loaded.
> This bug is probably in the Networking component
Yes, in Product: Core
Blocks: 392428
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Component: General → Networking
Keywords: regression
Product: Firefox → Core
QA Contact: general → networking
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Sorry, no duplicate)
The regressing change seems to have been security bug 504014. The commit message is "Enforce RFC 3986 syntax for IPv6 literals" and indeed RFC 3986 disallows interface specifiers. The validator can certainly be amended, but I guess we'd need policy approval from someone involved with whatever caused us to choose RFC 3986 syntax.
I can sort of understand why the standard for URLs don't allow IPv6LL addresses: and URL is supposed to be something that you can communicate to others, and link local addresses are by definition bound to a machine (as they contain the interface name or number).
Still I agree with Kerry Lynn that they are genuinely useful, especially to connect to devices for which you know the interface (as it is created by them), like network adapters.
IPv6 heavily uses LL addresses, and being able to use them in the browser is useful also for debugging purposes.

I don't think that allowing %interface in the IPv6 address poses a real security risk, at least for the addresses written by the user (one could maybe argue that it gives access to the local network, but that is exactly the reason we want it), neither it can mislead the user about the real recipient of the url (unlike the @ for example).
The problem with just allowing LL addresses is that it could be used by scripts on public network to scrape private addresses (tricky, but has been done in the past).  You'd have to put LL addresses into another security zone to prevent this.  Also you could provide an interstitial like invalid https certs have.
I would be very interested in knowing how you can scrape the addresses, and how this is different than trying to load internal addresses behind a NAT or firewall, in fact given the huge search space of IPV6LL it would be far easier to try to get the internal non LL addresses.
Unless you think about badly configured proxies (because the case of firefox running on the firewall/bridge does not make much sense), and I cannot think of other cases where specifying the interface can help an attacker.

Anyway the putting them in a security zone and maybe showing an interstitial would be good if deemed necessary.
I'd like to add that there is now a 6man WG draft to update
the RFC 3986 ABNF to allow zone IDs:
http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid
Any new updates? I wanted to use link-local addresses today in 20.0-beta6, and it didn't worked (with or without %eth0 suffix). I wanted to use it to login into my router webadmin interface. At least error message could be a bit better, why it is not supported.
Actually there is an update.  RFC 6874 "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" was released earlier this month so Firefox is now officially non-conformant with an IETF Proposed Standard.  Since this code *used* to exist in Firefox, it would sure be helpful if someone would put it back.
This should block 136898.

(In reply to Fawzi Mohamed from comment #4)

> Still I agree with Kerry Lynn that they are genuinely useful, especially to
> connect to devices for which you know the interface (as it is created by
> them), like network adapters.

It seems to me to be essential to be able to configure e.g. IPv6 network printers (which is where I find a lot of trouble in the current Linux eco system).
(In reply to Norman Rasmussen from comment #5)
> The problem with just allowing LL addresses is that it could be used by
> scripts on public network to scrape private addresses (tricky, but has been
> done in the past).  You'd have to put LL addresses into another security
> zone to prevent this.

Btw. it is kind of funny to have privacy concerns about this but then make firefox send link local addresses directly to google if they are entered in the URL bar.
Whiteboard: [ipv6]
I can CONFIRM this.

We really need to get this fixed. Example use case:

We have a program that connects to a database. It doesn't use a hostname, fqdn, or an IP address to connect to this database. Instead, it uses a UDP broadcast to find and connect to this database.

We need to be able to launch the default browser to connect to a web server on the same machine that the database runs on. So, we ask the database what it's endpoint is on the tcp connection to the databse from the client:

SELECT CONNECTION_PROPERTY('ServerNodeAddress')

getting back something like this:

fe80::230:48ff:fed9:40f5%2

Our application then attempts to start the default browser on Windows, passing a the link as a parameter:

start http://[fe80::230:48ff:fed9:40f5%252]

Firefox doesn't handle the scope identifier. If we strip it, it might work, but it's not guaranteed to, because the address can be ambiguous in cases with multiple network interfaces.

See RFC6874 for implementation details. 
http://tools.ietf.org/html/rfc6874
:valentin is rapidly becoming the expert here.. thoughts?
Flags: needinfo?(valentin.gosu)
changing status -> NEW just based on previous comments
Status: UNCONFIRMED → NEW
Ever confirmed: true
Seems like a good idea to implement the RFC correctly.
I'm going to take a shot at fixing this in the next couple of days.
Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)
URL: http://tools.ietf.org/html/rfc6874
Keywords: dev-doc-needed
OS: Linux → All
Hardware: x86 → All
Version: 8 Branch → Trunk
(In reply to Valentin Gosu [:valentin] from comment #15)
> Seems like a good idea to implement the RFC correctly.
> I'm going to take a shot at fixing this in the next couple of days.

As I said in the initial bug report, this feature *used* to work in
older versions of Firefox, so code was *removed* at some point.  If
you can access earlier releases, then it should be a simple matter
to fix it.

Good luck, -K-
Somewhat hilariously, the RFC specifically mentions the old Firefox code:

-- BEGIN QUOTE --

   Due to the lack of defined syntax, web browsers have been
   inconsistent in providing for ZoneIDs.  Many have no support, but
   there are examples of ad hoc support.  For example, some versions of
   Firefox allowed the use of a ZoneID preceded by a bare "%" character,
   but this feature was removed for consistency with established syntax
   [RFC3986].  As another example, some versions of Internet Explorer
   allow use of a ZoneID preceded by a "%" character encoded as "%25",
   still beyond the syntax allowed by the established rules [RFC3986].
   This syntax extension is in fact used internally in the Windows
   operating system and some of its APIs.

   It is desirable for all browsers to recognise a ZoneID preceded by a
   percent-encoded "%".  In the spirit of "be liberal with what you
   accept", we also suggest that URI parsers accept bare "%" signs when
   possible (i.e., a "%" not followed by two valid and meaningful
   hexadecimal characters).  This would make it possible for a user to
   copy and paste a string such as "fe80::a%en1" from the output of a
   "ping" command and have it work.  On the other hand, "%ee1" would
   need to be manually rewritten to "fe80::a%25ee1" to avoid any risk of
   misinterpretation.
-- END QUOTE --

If we choose to implement the fuzzy unencoded % interpretation, then a little regexp magic will be needed. I don't like the fuzzy suggestion at all, since it could be ambiguous.

Scope identifiers in GNU/Linux are typically eth0/wl0/etc (something without valid hexadecimal digits). However, in yonder Windows land, scope identifiers are decimal numbers. Once you hit 10 network interfaces, there is ambiguity. However, 10 NIC's in Windows would be very rare. It's probably very safe to assume that http://[fe80::230:48ff:fed9:40f5%2] really means http://[fe80::230:48ff:fed9:40f5%252]. If other browsers do the fuzzy interpretation, we should do it, since the Firefox installer allows importing of IE shortcuts as bookmarks. It'd be a shame for a user to shortcut something, switch to Firefox, and then think we broke it.
If at all possible I think we should accept both fuzzy and specific syntaxes. If nothing else, it will be more consistent for copy and paste. I do:

ping6 fe80::230:48ff:fed9:40f5%em1 

all the time. The ability to copy and paste that directly in to Firefox would be handy.
I'm not sure who should be shot... the person who chose % as the delimiter in IPv6 literals or the person who picked bare integers as the scope identifiers in Windows.
(In reply to Scott Baker from comment #18)
> If at all possible I think we should accept both fuzzy and specific
> syntaxes. If nothing else, it will be more consistent for copy and paste. I
> do:
> 
> ping6 fe80::230:48ff:fed9:40f5%em1 
> 
> all the time. The ability to copy and paste that directly in to Firefox
> would be handy.

Scott, this was precisely the point of the debate in IETF and of the subsequent
RFC.
(In reply to Matthew Mellon from comment #17)

> Scope identifiers in GNU/Linux are typically eth0/wl0/etc (something without
> valid hexadecimal digits). However, in yonder Windows land, scope
> identifiers are decimal numbers. Once you hit 10 network interfaces, there
> is ambiguity. However, 10 NIC's in Windows would be very rare. It's probably
> very safe to assume that http://[fe80::230:48ff:fed9:40f5%2] really means
> http://[fe80::230:48ff:fed9:40f5%252]. If other browsers do the fuzzy

Actually it should only be ambiguous if one uses more than 250 network interfaces and then use an address like [fe80::1%251], which is actually the address for the first interface. IIRC other percent encodings except %25 are invalid within an IPv6 address, so an easy algorithm is to check whether a percent occurs within an IPv6 address. If it does, see if the next characters are 25. If they are, everything until the closing square bracket is the zone identifier. Otherwise everything after the percent sign till the closing square bracket is the zone identifier. IMHO this should not cause much trouble.

Actually the possible values for zone identifiers are more restricted, so further checks for the identifier are possible.
(In reply to Till Maas from comment #21)
> (In reply to Matthew Mellon from comment #17)
> 
> > Scope identifiers in GNU/Linux are typically eth0/wl0/etc (something without
> > valid hexadecimal digits). However, in yonder Windows land, scope
> > identifiers are decimal numbers. Once you hit 10 network interfaces, there
> > is ambiguity. However, 10 NIC's in Windows would be very rare. It's probably
> > very safe to assume that http://[fe80::230:48ff:fed9:40f5%2] really means
> > http://[fe80::230:48ff:fed9:40f5%252]. If other browsers do the fuzzy
> 
> Actually it should only be ambiguous if one uses more than 250 network
> interfaces and then use an address like [fe80::1%251], which is actually the
> address for the first interface. IIRC other percent encodings except %25 are
> invalid within an IPv6 address, so an easy algorithm is to check whether a
> percent occurs within an IPv6 address. If it does, see if the next
> characters are 25. If they are, everything until the closing square bracket
> is the zone identifier. Otherwise everything after the percent sign till the
> closing square bracket is the zone identifier. IMHO this should not cause
> much trouble.
> 
> Actually the possible values for zone identifiers are more restricted, so
> further checks for the identifier are possible.

Agreed. I hadn't thought about the prohibition of percent-encodings for ASCII-encodable characters in the host specification. I double checked your recollection.

In RFC3986, percent-encodings are prohibited anywhere in the host portion of a URI unless they are used to represent a UTF-8 character sequence (for characters that cannot be represented in ASCII). The percent-encoding for % suggested in RFC6874 seems to be a new exception to the rule.

Firefox currently does not decode such prohibited percent-encodings (for example, http://www.%47oogle.com or http://10%2e1.100.18).

However, at least the way I read RFC6874, a scope identifier could have characters which cannot be represented as ASCII (sounds pretty far fetched). In that case, they must be percent encoded.

For example, if the scope identifier in some IPv6 implementation could be nét0, then the corresponding representation in a URI might look like:

http://[fe80::230:48ff:fed9:40f5%25n%C3%A9t0]

I wonder if some operating system out there allows non-ASCII characters in the scope identifiers. I guess it only matters for systems that Firefox runs on. I've got Windows 8.1, MacOS 10.9.2, and CentOS 6.4 in front of me, and it doesn't seem possible on any of these systems. Therefore, I think it's safe to interpret the % without a 25 and the %25 as both meaning %.
(In reply to Matthew Mellon from comment #22)

<snip>

> 
> I wonder if some operating system out there allows non-ASCII characters in
> the scope identifiers. I guess it only matters for systems that Firefox runs
> on. I've got Windows 8.1, MacOS 10.9.2, and CentOS 6.4 in front of me, and
> it doesn't seem possible on any of these systems. Therefore, I think it's
> safe to interpret the % without a 25 and the %25 as both meaning %.

Not if you're running on a Windows system with at least 25 interfaces.  In
that case, I believe %25 and %2525 would have to map to the same interface.
Summary: Firefox does not appear to support IPv6 link-local addresses → Firefox does not appear to support IPv6 link-local addresses (RFC 6874)
We don't refer RFC to implement the URL parser in these days. The URL Standard [1] needs to be updated first.

[1] https://url.spec.whatwg.org/
Summary: Firefox does not appear to support IPv6 link-local addresses (RFC 6874) → Firefox does not appear to support IPv6 link-local addresses
"We don't refer RFC to implement the URL parser in these days."
That makes no sense; the URI syntax is defined jointly by IETF and W3C so the RFCs are definitive. For this bug the latest RFC is http://tools.ietf.org/html/rfc6874
(Agreed, there are browser practices that the "URL [pseudo]standard" describes but the syntax comes from the RFCs.)
RFC does not define all details (including error handling) to implement interoperable URL parser between browsers. Anyway, let's argue in the W3C bug, not here.
(In reply to Masatoshi Kimura [:emk] from comment #26)
> RFC does not define all details (including error handling) to implement
> interoperable URL parser between browsers. Anyway, let's argue in the W3C
> bug, not here.

Well, I am not in that discussion but yes, there is a problem because the RFC
standards do not describe the text that goes in a browser box, only the
formal URI that goes on the wire. They are two separate things. We do discuss
that in http://tools.ietf.org/html/rfc6874#section-3 and propose browser
behaviour.
Resolving WONTFIX per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2.
Status: NEW → RESOLVED
Closed: 13 years ago → 9 years ago
Resolution: --- → WONTFIX
Any chance we could just make this work anyway? Link-locals can be extremely useful for connecting to routers, especially if you've screwed up the networking config on them. We don't need to get them working perfectly for them to be useful.

(I just encountered somebody on Reddit who broke his router config, but might well be able to log in via the LL address... except I had to tell him to download Firefox 6 to try. I don't really want to be stuck with a version of Firefox that old every time I want to use a link-local.)
+1

I opened this bug almost 4 years ago, asking that we simply restore code THAT USED TO WORK.
I totally agree with Kerry and dagger.
Dear developers, please, take a look on that situation from our point of view:
every professional-grade network utility (which supports connections to IPv6 address scope) supports connection to LL-addresses. Will it be ssh, nmap, curl (!), mtr, whatever. Even lynx supports it.
Even firefox *was* support it. And that was fine. But then become <somebody> and brake that in firefox.

Then, this bug waiting in the air for 4 years, and then become <another somebody> and said... WONTFIX "because of chromium team thinks it is too complicated".

So, I just adding my vote for resurrection this feature back. Even if this will require to enable something in about:config (to protect stup^Wmost people from problems with that).

// just my 5 cents
Flags: needinfo?(annevk)
As co-author of RFC6874 I am very willing to take suggestions from the developers about how we could tune it. RFCs aren't sacred. We already have some complaints about it from the designer of the CUPS protocol. If the stuff about never exporting a URL with a ZoneID from the host is unreasonable to implement, we should take account of that. (But anyway, there are no protocol police.)
If you want this to work I recommend working with Ryan Sleevi on a solution of sorts that works within the constraints of https://url.spec.whatwg.org/.
Flags: needinfo?(annevk)
I am also think there MUST be a solution for this problem. I encounter it on a IoT-Apllication. I my case it is just a Lab for Students but the use case could be real life just as well.

If you have a device in a network you don't control like a smart-plug, network printer etc., ipv6 link local may be the only way to connect to it. And as mentioned above all tools I tried support it may it be ping6, nmap etc.

I can see that choosing the %sign was not the cleverest idea, but only implementing for link local and dismiss it if the URL is sent outwards seems not that hard to do. I would strongly suggest to implement RFC6874. If there is to much hassle because of the %sign  it would still be an improvement to support it with a firefox-specific identifier.

I believe there are just to many real use-cases in ipv6 link local addresses to ignore this issue.
(In reply to vondemleschker@hotmail.com from comment #34)
> I am also think there MUST be a solution for this problem. 

if so, this specification issue has to be discussed elsewhere (see comment 33)
Commenting on 33 and 34:

> [33] a solution of sorts that works within the constraints of https://url.spec.whatwg.org/.

Please don't overlook that the URI syntax is controlled by IETF+W3C. Whatwg would need to join that discussion rather than riding alone. Happy to help with that.

> [34] choosing the %sign was not the cleverest idea

The issue (both for that and for the choice of : as the separator within IPv6 addresses) is that the IPv6 readable format was invented before the W3C/IETF liaison was working properly and it just got overlooked. Sorry, because I was one of the people who overlooked it. (I'm not sure I even knew in 1996 that literal addresses in URLs were possible, despite being one of the people Tim asked to try out this new thing called www in 1991. Of course, he told me to use http://info.cern.ch .) We fixed the : by adding the [] round literal IPv6 addresses. But after a lot of debate and discussion with the URI folk, we decided we couldn't fix the % problem any better than by using %25.
(More details are at [https://tools.ietf.org/html/rfc6874#appendix-A] )
Please reopen. This issue's importance increases with the event of IoT. There is an increasing lot of small gadgets with network connectivity, web administration, and IPv6 support. Whenever such a gadget looses its configured IP address (or you forget it, or the default is not in your local IPv4 network AND unknown), there is a simple measure to reconfigure it: run a ping for all local IPv6 nodes, and then open a browser and configure it using the so acquired IPv6 local link address - right? - no. The only browser you could use is Lnyx, but text only, bad for all web configurations that depend heavily on graphical elements. Using an outdated version of Firefox or Internet Explorer isn't an option either. This shows once more how far IPv6 is still away from being mainstream.

To the technical side:
RFC4007 says clearly how local link addresses should be written, and wonder how, all major OS do support it since long. RFC6874 updates RFC3986 to use it with URIs in a reasonable way - now you could implement it.

Regarding the objections:
1. There are virtually no websites with local link addresses:
Right, besides the fact that nearly no browser supports them, they are NEVER useful on a WEBSITE. LL address are only meaningful for ONE SINGLE COMPUTER, the one that sends out the request, i.e. the client. You could only expect a local HTML file an administrator made for himself to make his job easier, but usually those local link addresses are hand typed or copied locally from the output of e.g. a ping command.
2. You should not send the interface identifier to the server:
better not. The OSes do a great job in keeping the TCP connection, so all the server has to do is to send the response through the open socket. It never should use the source information sent within the HTTP request. The browser should use the interface id only when communicating with the OS: it knows how to handle it, and it needs it to be able to select the interface to send the request. On the other side, it should not hurt to send the meaningless identifier also within the HTTP request: you could include it in the Request-URI, most HTTP servers included within hosts you want to address by local link address won't bother about the server name. But IIRC, are 1.1-clients only expected to send absolute addresses when used with proxies? Then why should we care about stripping the LL id when it is not sent at all? Or simply send only relative requests with local link addresses?

In the Errata discussion of RFC6874 we find an striking example of misunderstanding I also seem to find in comments here: the server does not need the interface id to answer the request, it must append the id of his own interface, because the answer must return through the same interface it came in, and only the server knows this. Fortunately neither web server nor browser program have to pay attention, because their TCP stack on both sides handles this gracefully - and it knows how to handle scope ids.
Heinz is correct about the RFC6874 errata - a host can detect which interface a link-local packet arrived on, and remember the interface number or zone ID for corresponding outgoing messages. (I know, I've written Python code that does that.) But Michael Sweet's shipped code for IPP isn't designed that way, so I understand his problem. But the real objection from the browser side is that it's a horrible thing to implement. Being a pragmatist, I could live with changing both the MUSTs in https://tools.ietf.org/html/rfc6874#section-4 to SHOULD. Would that be enough to persuade implementers to implement the rest of the RFC and claim an RFC2119 exemption to the SHOULDs? If so, I will propose this in the IETF.

So anyway: this is still a defect in Firefox.
(In reply to Brian  E Carpenter from comment #38)
> But the real objection from
> the browser side is that it's a horrible thing to implement.

I know, this stems from Ryan Sleevi's 2015 comment, but having some experience in networks and C programming for decades I can hardly understand this. I see only 2 distinct jobs here:

1. expand the parser of the url-decoded URI that already can parse IPv6-address-raw:
instead of
IPv6-literal = '[', IPv6-address-raw, ']';
parse
IPv6-literal = '[', IPv6-address-raw, [ '%', IPv6-scope-id ], ']';
IPv6-scope-id = '0'-'9' | 'a'-'z' | 'A'-'Z', { '0'-'9' | 'a'-'z' | 'A'-'Z' | ' ' | '_' | '-' };
difficulty: 'create your own parser' course, beginner's lesson

2. When opening a IPv6 socket, add (pseudo code):
if IPv6-scope-id
    if isNumber(IPv6-scope-id)
        sockaddr_in6.sin6_scope_id = atoi(IPv6-scope-id)
    else
        ifreq.ifr_name=IPv6-scope-id
        call the netdevice with IOCTL SIOCGIFINDEX
        if error
           give a meaningful description to the knowing user; abort
        sockaddr_in6.sin6_scope_id = ifreq.ifr_ifindex
    endif
endif
difficulty: beginner

End of job - this is the only place this scope id is meaningful and needed. Everything else needs not to be changed - reverse dns, request setup, ...

jm2c
(In reply to heinz.repp from comment #39)

> I know, this stems from Ryan Sleevi's 2015 comment, but having some
> experience in networks and C programming for decades I can hardly understand
> this. I see only 2 distinct jobs here:
> 
> 1. expand the parser of the url-decoded URI that already can parse
> IPv6-address-raw:

> 2. When opening a IPv6 socket, add (pseudo code):

> End of job - this is the only place this scope id is meaningful and needed.
> Everything else needs not to be changed - reverse dns, request setup, ...

I believe you missed other problems/open questions regarding the HTTP level that were raised here:

a) Should the scope ID be included in the host header?
b) What happens with scope IDs that are used in links, location headers, html/javascript redirects?
c) Which interface will be used to sent the follow-up request of a redirect if the redirect contains a link-local address?

Nevertheless browsers should support link-local addresses since managing local devices such as priners via link-local addresses is very convenient. :-)
(In reply to Till Maas from comment #40)
> I believe you missed other problems/open questions regarding the HTTP level
> that were raised here:

I did not miss them, I said, everything else needs not to be changed.

> a) Should the scope ID be included in the host header?
No, why would you want to? It is not meaningful anywhere else. If you assemble the host header from already parsed data, ignore the scope id, so no change. If you copy the URI verbatim, nothing is lost if it contains a scope id: it is of no use, but it doesn't hurt either, so no change needed

> b) What happens with scope IDs that are used in links, location headers,
parse them as every URI; this allows to keep link lists with link-local addresses for housekeeping - so no change needed

> html/javascript redirects?
redirects to link-local addresses are INVALID when they come from a server (the server does not know your interfaces), they are rarely useful when they origin from the own host - and then the one writing the redirect should know the interface, if not the socket creation will fail anyway. But they pose no threat, an attacker would have to know MAC and interfaces of your local setup: if he knows this, it would be much easier to redirect to the local IPv4 or global/site-local IPv6 address, so it does not hurt to follow this redirect: proceed as always, no change needed

> c) Which interface will be used to sent the follow-up request of a redirect
> if the redirect contains a link-local address?
as I already said, every redirect to link-local addresses sent over the network is INVALID. But: it does not hurt to follow it, but most likely the socket creation will fail. If not, this request will choose an arbitrary port and an IPv6 interface identifier that most likely does not exist, a chance of 1 in 2.81475E+14 when using EUI-64, or else 1 in 1.84467E+19: no need for special treatment, so no change needed

> Nevertheless browsers should support link-local addresses since managing
> local devices such as priners via link-local addresses is very convenient.
> :-)

Yes, it is, and increasingly so ...
(In reply to heinz.repp from comment #41)
> (In reply to Till Maas from comment #40)
...
> > a) Should the scope ID be included in the host header?
> No, why would you want to? It is not meaningful anywhere else.

As I understand the IPP/CUPS case, that is true but the other side uses
it to construct a URL that the sender will use to reach the printer.
In other words it reflects the scope ID back to the node where it
*is* meaningful.

(Michael Sweet made his case in a draft, but the IETF wasn't interested:
https://tools.ietf.org/html/draft-sweet-uri-zoneid-01 )
(In reply to Brian  E Carpenter from comment #42)
> (In reply to heinz.repp from comment #41)
> > (In reply to Till Maas from comment #40)
> ...
> > > a) Should the scope ID be included in the host header?
> > No, why would you want to? It is not meaningful anywhere else.
> 
> As I understand the IPP/CUPS case, that is true but the other side uses
> it to construct a URL that the sender will use to reach the printer.
> In other words it reflects the scope ID back to the node where it
> *is* meaningful.

This is true for any protocol that generates individual links for the individual client where it can reach resources directly on the server. In the HTTP protocol this might happen with the Location field of the HTTP answer header (used in redirects, with 3xx codes). But please stay focused to the use case of link-local addresses in a browser: it is only relevant for a small minority of users, that know what link-local addresses are and why they want to use it. The only application I can think of is administration of local hosts, be they IoT-gadgets, printers, WLAN extenders and such. This justifies only limited effort for the most requested use case, and (absolute) redirects can safely be ignored (relative will work). And then the scope ID is only needed when opening a socket.

Btw: this is only discussing implementation issues, and thus can focus on the use case. Defining an URI syntax for every possible application requires a wholly different approach.
(In reply to heinz.repp from comment #43)
> (In reply to Brian  E Carpenter from comment #42)
> > (In reply to heinz.repp from comment #41)
> > > (In reply to Till Maas from comment #40)
> But please stay focused
> to the use case of link-local addresses in a browser: it is only relevant
> for a small minority of users, that know what link-local addresses are and
> why they want to use it. The only application I can think of is
> administration of local hosts, be they IoT-gadgets, printers, WLAN extenders
> and such. 

There are also diagnostic uses. Nothing operational for users.

> This justifies only limited effort for the most requested use
> case, and (absolute) redirects can safely be ignored (relative will work).
> And then the scope ID is only needed when opening a socket.

Agreed.

> 
> Btw: this is only discussing implementation issues, and thus can focus on
> the use case. Defining an URI syntax for every possible application requires
> a wholly different approach.

And doesn't beling here ;-)
I want to propose a compromise.
1) LL % addresses won't be processed in the Location bar due to the complexity cited.
2) LL % addresses would be processed in file: hosted HTML, and possibly (with some permission) generated by extensions.

This lets someone build an extension that can do things like mDNS or other browsing that finds IoT devices and generates HTML output that can be clicked on.

The really sad part is:
Microsoft Edge (as well as Microsoft Explorer) works well with link local IPV6 addresses.
So, for the past 2 years were are saying to our customers:
"if you want to use IPV4 address recovery functionality, you have to use Microsoft Edge..."

And I can bet - there is a lot of other companies working with IoT devices that are telling the same to their customers as well...

It is now even worse than before, when I type: http://[fe80::201:2eff:fe6c:1234%enp66s0]/ into Firefox's address bar, it immediately send me to Google and searches for "http://[fe80::201:2eff:fe6c:1234%enp66s0]/". That is a bit sad.

(In reply to Witold Baryluk from comment #47)

It is now even worse than before, when I type: http://[fe80::201:2eff:fe6c:1234%enp66s0]/ into Firefox's address bar, it immediately send me to Google and searches for "http://[fe80::201:2eff:fe6c:1234%enp66s0]/". That is a bit sad.

Frankly that's catastrophic and led me to the only sensible solution of setting keyword.enabled = false in the advanced config.

Please reconsider supporting this.

Good morning,

as more and more devices come without IPv4 addresses and the only way to connect to them is via IPv6 link local, I was wondering if this bug report can be reopened.

I agree with the previous writers that this functionality is mostly of interesting for developers/IoT users and as such does not need to come with all bells and whistles, but it should be in firefox so that Linux users don't have to install Windows to configure their IoT devices.

Dear Mozilla team, can you re-open this bug and work together with the community to get this fixed? It's been 9 (!) years since this bug was opened; I think it is more than very late to address this issue.

The browser implements the URL spec, which intentionally omits zone identifiers:
https://url.spec.whatwg.org/#concept-ipv6
https://github.com/whatwg/url/issues/392

Please make your case in the github issue.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #51)

The browser implements the URL spec, which intentionally omits zone identifiers

If so, the resolution of this bug should be "INVALID" rather than "WONTFIX", no?

" The browser implements the URL spec, which intentionally omits zone identifiers
If so, the resolution of this bug should be "INVALID" rather than "WONTFIX", no?"

That would be circular. The last time I looked at the WHATWG site, which purports to provide a URL spec, they had decided to ignore the official URI spec and not implement the Zone ID feature, but they cited this Bugzilla thread as the justification for that choice. So it is not invalid according to the URI syntax, it's a bug, so WONTFIX is honest.

If you think the URI syntax is wrong, go tell it to the IETF. If you think it's right, go tell it to WHATWG.

(In reply to Andrew Cady from comment #55)

Just the idea that the developer of a work of network software has personal discretion to break IP connectivity that exists on the underlying OS.

Just the audacity of that.

The hostility of this code base to its users.

Much as I wish Firefox would implement this feature per RFC6874, the reason for the WONTFIX is nothing to do with comments #54 and #55 and is purely for technical reasons (which I disagreee with).

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?

Flags: needinfo?(valentin.gosu)
At stake is:

Which group of humans gets the power to choose the meaning of the location bar:

    CAB Forum

  or

    OS developers ?

Statement of interest: I side with OS developers because I use free software and modify the OS myself.

I configured many hardware devices according to IPv6 spec and, in debugging IPv6 issues, traced the bug all the way up to the politics that keep Firefox from getting fixed. So ironically even though I'm tagged as advocacy, and intend to engage in some, I'm actually talking about the politics of this because I consider this entire technical and approach it from a technical mindset.

I am willing to treat all people involved as being themselves computers -- whose inputs include not just words but money, and who can be much more easily reprogrammed by one than the other, unfortunately it's by the expensive one.

Goal is IP connectivity and understanding true nature of the bug that breaks connectivity. I claim ultimate source of bug is inside Mozilla social organization and financial interests, as a technical diagnosis.

If my diagnosis is correct the bug can't be fixed by inputting only technical information into the organization. Because technical information cannot change financial interests. Solution is to alter Mozilla's interests. (Hard yes, but possible.)

Right now, as documented, Chromium and Firefox teams consider it more important to match each other's name semantics than to match up with the underlying OS name semantics.

The browsers have chosen to re-reimplement the name resolution functions of the OS.

The re-implemenation is:

  1. Incompatible with standards.
  2. Incompatible with the OS way of resolving.
  3. Incompatible with local system administrator policy as might be defined unpredictably (and that's OK and what standards are for).
  4. Incompatible, even, with the constraint of simply maintaining connectivity in the application layer that the OS provides at the IP layer.

Firefox is trying to edge out OS developers and impose a single global view of the location bar. Abolishing local names.

Local names don't make anyone money!

Most people don't even understand that namespaces are big money. It's niche information.

CAB Forum is filled with people making millions of dollars from artificial scarcity in global namespaces. Pure coincidence? Maybe.

I think getting this bug fixed is going to require big political organization and mobilization, as much as was required to force browsers to accept LetsEncrypt.

And that's worth it because (re-)establishing internet p2p connectivity will enable entirely new ways of using computers to communicate and collaborate and so push global human society forward. It will raise the collective intelligence of humanity. Earth's total collective processing power (brain+silicon) will be much more greater because it is so much more internally connected. The leap from NAT-over-LAN to real internet access will be huge -- once software starts getting built on it.

You need to have some vision to see that connectivity is just a foundation. These people talking about "niche" don't have it, don't want it.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #51)

The browser implements the URL spec, which intentionally omits zone identifiers:
https://url.spec.whatwg.org/#concept-ipv6
https://github.com/whatwg/url/issues/392

Please make your case in the github issue.

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!

Flags: needinfo?(valentin.gosu)

As this bug is not only related to Firefox and has a lot of cross references, I took the time to summarise them on https://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/ - in case you find any mistakes or have updates, please let me know.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #59)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #51)

The browser implements the URL spec, which intentionally omits zone identifiers:
https://url.spec.whatwg.org/#concept-ipv6
https://github.com/whatwg/url/issues/392

Please make your case in the github issue.

As I recall, that issue is entirely circular because it cites this Firefox WONTFIX as the source for saying it's too hard. And anyway, whatwg is not the relevant standard. The URI spec is the relevant standard for what goes on the wire, and the URI spec as updated by https://www.rfc-editor.org/rfc/rfc6874.html defines how link locals are specified in a URI.

If you disagree with RFC6874 that's an IETF issue for the 6man WG - you can write to ipv6@ietf.org to make the case. But for now, Firefox says WONTFIX for a missing feature of the official URI syntax.

As a co-author of RFC6874, I agree with the criticism that "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." is really messy to implement. I offered 4 years ago to work to get this and another annoying MUST downgraded to a SHOULD, which allows implementers to ignore it where justified. Nobody seemed interested.

Putting this defect in the too hard bucket is a cop-out IMHO, since you will find several descriptions of use cases up thread.

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.

If you pass a non-existent interface ID to a socket, you get an error code.

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.

whatwg is not the relevant standards organization for URI syntax, which is the basis for URL syntax.

Thank you!

@Brian: thanks a lot for the clarification. I also have the impression that this bug is rather circular.

Team firefox: can we discuss the bug in a different medium or different way on how to get it restarted with some fresh eyes on it?

Our team does not have a lot of resources to spend on this. If this were properly specified and had good web-platform tests I'd be happy to implement it. That's why the starting point is the whatwg issue.

You don't have to implement it. You just have to agree that you'd accept a patch.

By the way, you need to send the interface ID back over the wire unchanged. You need to treat the URL as an opaque string and never edit it. So that part of the spec is a bug.

Sending the interface ID over the wire is fine on a link-local network! It's guaranteed to be over the same link, so the network ID is always correct when the web server sends the string back to the web client.

The client NEEDS that interface idea and to receive it over the fe80 link.

Just ignore the bug in the spec, and implement it the only possible way that will work, by making the entire domain string an opaque string.

If you don't do that, it won't ever work, because the server won't know how to send a link to itself back to the client.

(In reply to Andrew Cady from comment #64)

You don't have to implement it. You just have to agree that you'd accept a patch.

Given that we'd have to maintain it in the future, if we were to accept a patch it would need to:

  • Not regress any of the existing web platform tests (or any other tests for that matter)
  • Include thorough tests for this feature (zoneid containing percent encoded characters, unicode characters, control characters, special characters, etc)
  • Be concise, readable, modern C++ (I am reluctant to accept any C-style string parsing code)

Can you clarify that those three conditions are SUFFICIENT and not merely necessary?

I would say it's a fairly high bar alread, but I think it's sufficient 🙂

You think. So you don't really commit to anything.

It's not a high bar to get very high quality code written from very high quality programmers. A lot of people all around the world are trying to make IPv6 work and putting in thousands of hours of volunteer effort already. This bug is a major break in global IPv6 connectivity.

Code is easy to come by. Permission to get that code onto real IPv6 nodes is much harder.

Permission is what we need here. Permission, from you, to fix those computers.

We don't have unambiguous permission yet. So it's MUCH harder to get anybody willing to write code for free or donate money for code.

(In reply to Andrew Cady from comment #64)

You don't have to implement it. You just have to agree that you'd accept a patch.

By the way, you need to send the interface ID back over the wire unchanged. You need to treat the URL as an opaque string and never edit it. So that part of the spec is a bug.

Andrew, that is your opinion. It is not a bug in the RFC; it was intentional. Agreed, that requirement in the RFC breaks your use case. It isn't for Mozilla or whatwg to address that, because it's an IETF issue. I will re-open this discussion at ipv6@ietf.org, because if updating the RFC is the way to get whatwg and Mozilla to revisit the issue, we need to do that. In fact whatwg does matter because this affects all browsers, not just Firefox.

Brian

Sending the interface ID over the wire is fine on a link-local network! It's guaranteed to be over the same link, so the network ID is always correct when the web server sends the string back to the web client.

The client NEEDS that interface idea and to receive it over the fe80 link.

(In reply to Brian E Carpenter from comment #70)

(In reply to Andrew Cady from comment #64)

You don't have to implement it. You just have to agree that you'd accept a patch.

By the way, you need to send the interface ID back over the wire unchanged. You need to treat the URL as an opaque string and never edit it. So that part of the spec is a bug.

Andrew, that is your opinion.

In my opinion, it's a mathematical fact.

It is not a bug in the RFC; it was intentional.

Being intentional isn't the same thing as not being a bug.

Agreed, that requirement in the RFC breaks your use case.

It breaks HTTP's required assumptions for client-server connectivity over that URL. That's why it's a bug.

If connectivity cannot be achieved when code meets the spec, but CAN achieve connectivity when code does NOT meet the spec, then the spec has a bug. Even if spec was deliberately chosen that way because of evil desire to break connectivity. Still a bug.

Just like, if the spec says to use some eliptic curve, but the curve is compromised, then the spec has a bug. Whether intentional or not.

It isn't for Mozilla or whatwg to address that,

It doesn't make sense for them to wait for a standard to fix a bug, before they fix their own code base.

Especially since there is a whole dev branch to put it in first. You could literally implement both versions, give them to WHATWG people to download, and they can verify that the only "advantage" of doing it the spec way is to break some connections.

your use case

It's not some special use case. It's just basic assumptions about how HTTP works. Firefox wants to violate these assumptions introducing special cases. Remove all the special cases because the general solution is what we want anyway.

(In reply to Andrew Cady from comment #71)

(In reply to Brian E Carpenter from comment #70)

(In reply to Andrew Cady from comment #64)

You don't have to implement it. You just have to agree that you'd accept a patch.

By the way, you need to send the interface ID back over the wire unchanged. You need to treat the URL as an opaque string and never edit it. So that part of the spec is a bug.

Andrew, that is your opinion.

In my opinion, it's a mathematical fact.

It is not a bug in the RFC; it was intentional.

Being intentional isn't the same thing as not being a bug.

Agreed, that requirement in the RFC breaks your use case.

It breaks HTTP's required assumptions for client-server connectivity over that URL. That's why it's a bug.

This point in the HTTP spec is rather subtle. https://www.rfc-editor.org/rfc/rfc7230#section-5.4 defines that HTTP must carry a Host: header which includes a uri-host that (if you follow the breadcrumbs via RFC3986) may be an IP address literal as defined in RFC6874. So since RFC6874 formally updates RFC3986, it indirectly updates RFC7230. This may or may not be a mistake but that doesn't make it a bug.

If connectivity cannot be achieved when code meets the spec, but CAN achieve connectivity when code does NOT meet the spec, then the spec has a bug. Even if spec was deliberately chosen that way because of evil desire to break connectivity. Still a bug.

Can you try to stay a bit professional in your choice of language, please? Also, your comment is inconsistent with the nature of IPv6 "Zone IDs" as defined in RFC4007 and used in RFC6874. The precise reason that RFC6874 forbids sending the Zone ID on the wire is that it is by definition meaningless outside the host. Example: if it's %eth0 and it happens to arrive in a remote host on the interface known there as %eth99, it won't work there and might even accidentally point to a third host.

[I've written code dealing with IPv6 link-locals and it's quite a lot of bother to keep track of interface identifiers for incoming messages, but one thing you never, never rely on is the interface identifier used in the remote host.]

We will, I think, reopen the RFC in the IETF WG. You can subscribe via https://datatracker.ietf.org/wg/6man/about/

Just like, if the spec says to use some eliptic curve, but the curve is compromised, then the spec has a bug. Whether intentional or not.

It isn't for Mozilla or whatwg to address that,

It doesn't make sense for them to wait for a standard to fix a bug, before they fix their own code base.

Especially since there is a whole dev branch to put it in first. You could literally implement both versions, give them to WHATWG people to download, and they can verify that the only "advantage" of doing it the spec way is to break some connections.

your use case

It's not some special use case. It's just basic assumptions about how HTTP works. Firefox wants to violate these assumptions introducing special cases. Remove all the special cases because the general solution is what we want anyway.

It is definitely alright to echo a local name back and forth over a TCP link, which is guaranteed to route such a message to a host where it is meaningful. So "meaningless by definition" just implies the definition is wrong.

Example: if it's %eth0 and it happens to arrive in a remote host on the interface known there as %eth99

To be clear: whether it's on a server or a client, the address is always the server from the client's perspective and interface specifier always contains the client's interface name. The server's interface name is never sent over the wire.

The HTTP client does not accept a response coming from another interface than the one on which it made the request.

(If somehow the ongoing TCP connection could be migrated between interfaces, even then, the link would merely be stale, not meaningless.)

[I've written code dealing with IPv6 link-locals and it's quite a lot of bother to keep track of interface identifiers for incoming messages, but one thing you never, never rely on is the interface identifier used in the remote host.]

The entire principle of HTTP is to rely on the remote host to tell you where to go.

The server can send you to any IP it chooses.

The server knows how to send back the same string that the client sent -- when it wants to keep the client on the same link.

The server chooses whether to send back the string you sent it. It can send any other string.

There is no need or benefit on the client to censor the string and not supply the server with the exact name it actually used to access the server.

The principle of HTTP1.1 is that the client tells the server its own name for the session. The name of the server on the server is only supposed to be meaningful from the perspective of the client. For example, the server could be given a name for itself that is a different IP than it's listening on from a network perspective, and that name would be the IP address that the client uses, from its perspective, to reach the server.

If the client redirects IP 127.0.0.2 on their own machine to a google IP, and visits that way, then the google web server will be told that its name is "127.0.0.2" and google will be able to send that IP back to clients if they choose. And the users will be able to actually connect to google through that meaningless (to google) IP.

Meaningfulness here, on both client and server, is defined from the client's perspective. So it's fine. It's meaningful.

The whole point of the Host: header is to give the server a piece of the client's perspective.

So a rule that forbids sharing because it leaks the client's perspective is inapplicable in this case.

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,

You can.

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.

That was a bug in the developer who failed to understand the API. It was not a bug in the API. (So it goes.)

The developer believed the parser from the API would match against the end of the string but in truth it matched against the end of the word.

You only need to properly validate the input to the API. Not to re-implement any of its internal functionality.

The crucial thing here is not technical details, but that there be a sacred covenant between the programmer who creates the web client and the user who inputs a name that the program will faithfully deliver the name to the web server.

A covenant that the browser, recognizing its own power over both user and server (being positioned as man-in-the-middle), will never filter nor break any name. Recognizing the danger of this power, and promising restraint, to guarantee full agency to the user.

Valentin, can Mozilla agree to that principle?

To try and unblock this issue, we've posted a draft update to RFC6874 and discussion is open. Details here.
The draft itself is here.

And the draft has been updated, with live discussion planned at the upcoming IETF meeting.

A diff from the previous version is available.

The draft has been updated again following the IETF discussion. In particular, two open issues have been highlighted and they need feedback from the implementation side.
Once again, a diff from the previous version is available.

I'm running into this too from time to time. Does anybody happen to know of a workaround at least?

Julius, I'm not aware of a workaround except using Internet Explorer as long as it still exists - it does support RFC6874 syntax, e.g. [fe80::abcd%257], but of course it's only Windows and a very outdated browser in other respects.
If you want support in wget() I patched it: https://github.com/becarpenter/wget6

Nico Schottelius's link above https://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/ has a couple of workaround, including a LD_PRELOAD library and an iptables trick.

After bumping into this problem, I also made a workaround in the form of a SOCKS5 proxy server, that rewrites a "magic escape sequence" host name into IPv6 address literals. This should work on a variety of browsers and operating systems. https://github.com/twisteroidambassador/prettysocks/tree/ipv6-literal

I think this bug was closed on the wrong premises. It requests supporting connecting to IPv6 link-local addresses. However it was closed due to a particular URL syntax that's commonly used for such addresses being unsupportable.

I think supporting these URLs is not that important, but at least having the ability to connect to hosts on their link-local addresses is. Especially in a home network sometimes the only address available to reach a device is its link-local address (for instance a wireless access point with a missing uplink won't have any other reachable address).

Hopefully such use cases can still be supported despite the lack of support for those particular URLs. Maybe the interface that needs to be used could be specified in a different way?

Julius, it is not really the syntax details that cause the reluctance to implement this, it is the complexity of actually doing the work on the URL parsers of the browsers. As noted above, the fix for wget is rather easy, but we (the IETF authors involved) have reached out to the browser developers, and I've personally spent a few days looking at the Firefox code. Bottom line: this is a non-trivial amount of work for the mainstream browsers and a lot more pressure from the user side will be needed for it to happen.

All the same, watch out for a new version of our draft; it will show up here within a week.

Brian, thanks a lot for the response and also great that a new draft is coming up! Hopefully this bug can be reopened soon with a good standard way in place!

None the less, for the sake of this bug, I think it's important to distinguish between "accessing through a URL, working non-relative links, etc." and "supporting connections to link-local addresses". Although it might seem even harder, theoretically one could establish a connection without any concept of a URL :)

Hopefully a full solution can be built, but otherwise it would be good to think a bit more out of the box on this one, because it would be super-useful to have this functionality!!

I landed here because I am working on the administration of IPv6 only networks. I am very surprised that such a fundamental function is not (any more) implemented in Firefox, and hope it will be soon.

The IETF 6MAN WG has just formally adopted our document draft-ietf-6man-rfc6874bis-00. All we need is a developer who understands all the places where URLs are parsed (there are several) and where the actual socket calls are made. I'm glad to help if such a developer contacts me.

@Dan Weiss, in bug 1759739 you said:

In Windows 10, a WSD printer will have with a URL like this: http://[fe80::822b:f9ff:fe6a:d7de%10]:80/WebServices/Device
According to https://superuser.com/questions/99746/why-is-there-a-percent-sign-in-the-ipv6-address, this is caused by Windows adding a percent sign (%) and a number to identify which network the link-local address corresponds to. But Firefox doesn't accept this kind of URL with a percent sign (%), and instead opens a web search.

If I remove the "%10" from the URL, Firefox visits the page fine. It seems that the only web browser that accepts this kind of URL is Microsoft Internet Explorer.

Actual results: Firefox gets confused by the percent sign % in the URL and opens a web search instead of accessing the printer's web interface.

Expected results: Firefox should ignore or discard the percent sign % and local network identifier number if it appears after a link-local IPV6 address.

That's not quite right. On a host with two interfaces active, e.g. WiFi and Ethernet, %10 is necessary to select one or the other. See the above mentioned draft for details.

New version of the draft published: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html.
Among other things it adds the Microsoft use case flagged by @Dan Weiss.

All we need is a developer who understands all the places where URLs are parsed (there are several) and where the actual socket calls are made.

Would it not help in attracting a developer, to re-open this issue as an open bug so that someone could find it and fix it?

@Ian!, I agree, but perhaps we should wait until the IETF draft is approved to become an RFC. Comments on the draft are more than welcome, preferably directed at the mailing list.

Note that the IETF working group has reached consensus on the latest version: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-02.html and it is now under review by the appropriate IETF Area Director. Comments still very welcome at ipv6@ietf.org.

Thank you for all the great work, Brian!
I'll reopen the bug for future work into supporting this.

It would be nice if we could restart discussions in https://github.com/whatwg/url/issues/392 to ensure webcompat, but I don't think that's a blocker.

Blocks: url
Severity: normal → N/A
Status: RESOLVED → REOPENED
Type: defect → enhancement
Priority: -- → P3
Resolution: WONTFIX → ---
Type: enhancement → defect

Not going to work on this right away.

Assignee: valentin.gosu → nobody
Severity: N/A → S3

The severity field for this bug is relatively low, S3. However, the bug has 20 votes.
:valentin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(valentin.gosu)

The URI syntax update is now in IETF Last Call, i.e. the last opportunity for public comments: https://mailarchive.ietf.org/arch/msg/ietf-announce/BqBF9qvZ8qZR4ZPlawPvQSe0WbU/

Flags: needinfo?(valentin.gosu)
Whiteboard: [ipv6] → [ipv6][necko-triaged]

Worth mentioning that the draft has been updated following Last Call comments: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-03.html.

According to the comments in bug 392428 this was regressed by bug 504014 in Firefox 7.

(In reply to Mathew Hodson from comment #99)

According to the comments in bug 392428 this was regressed by bug 504014 in Firefox 7.

Ancient history. The [xxx] syntax is only for IPv6 literals.

It is good to see that finally (after 11 years) there will probably be a fix.

While maybe 5-10 years ago it was not that important or common, having support for link local autoconfiguration addressess in web browsers (other that Microsoft) is important for network management, and increasingly important for configuration of home devices via a web interface.

There has been RFC6874 for a long time, so any argument that "there is no standard for it" disappeared a long time ago.

The new, about to be finalised, RFC874bis provides an even simpler specification, limiting the scope of required changes (although all URL handling will need updating).

Note that it is also important to ensure the support includes default zone (i.e. zone 0), as specified in RFC4007 https://datatracker.ietf.org/doc/html/rfc4007

This allows devices to include something like a QR code with "http://[fe80::2001:db8:1234:abcd%0]" and then a mobile phone will be able to scan and reach the device. (Just "http://[fe80::2001:db8:1234:abcd]" should probably also work, if default zone is correctly handled)

For network management, it also becomes easy to access upstream router/gateway via "http://[fe80::1]" (with the default zone)

As far as I can tell, Linux itself doesn't support the default zone, and Windows does. That can't be fixed by the browser, which makes the fix even more important for Linux.
If you want Linux to support zone 0, that needs to be raised elsewehere.
(I don't know the situation for BSD etc.)

Yes, good point.

Ultimately support for default zone depends on the underlying OS, although a test case is that "http://[fe80::1%0]" should have the same result as "http://[fe80::1]".

i.e. on an OS with default zone support, it will show the device (if it exists and has a web UI), or on an OS with no support (or where it does not exist) it will give a timeout with no response.

What is should NOT do is an Internet search for the string "http://[fe80:1%0]"

Supporting on desktop/laptop Linux is useful for network administrators, but for home users it is probably more important to have it supported on mobile browsers, e.g. the scenario where a user points a phone at a QR code.

New version of the draft today : https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html
There's one change, adding a note that zone IDs with upper case letters won't work.
(That's an issue we can't fix, due to a shortfall in RFC4007.)

Status: REOPENED → NEW
Priority: P3 → P5

Worth noting the the draft has been significantly updated following initial IESG review; we are now waiting for further IESG review. In particular we now cross-reference the W3C community work on CORS.

https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-08.html

The more important recent changes:

  • Added NMEA use case.
  • Clearly explained cut-and-paste requirement.
  • Clarified character set restrictions and the applicability of numeric identifiers as a work-around.
  • Updated ABNF to require lower case (due to host component case normalization)
  • Mentioned .local as another case of locally significant URIs.
  • Expanded text on handling of zone ID at server.
  • Added discussion of CORS.
  • Noted parsing fragility re % sign.
  • Noted potential exposure of MAC addresses in zone IDs.
Duplicate of this bug: 1843887

And in other news, the IETF draft is now at version 9, https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-09.html, but still held up from approval as an RFC even though version 9 responds to the remaining objections. If you really want to see this sausage being made, https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/

@scunnane@mozilla.com : http://[fe80::58bc:daff:fe86:ba71%2525]/ is valid under RFC6874 but http://[fe80::58bc:daff:fe86:ba71%25]/ is valid under the replacement draft, i.e. percent-encoding not needed inside the square brackets. Yes, it's a syntax change but since no browser currently supports RFC6874 we can change it.

Depends on: 412457
No longer depends on: 1023468
No longer blocks: 392428
Depends on: CVE-2011-3670, 392428
Whiteboard: [ipv6][necko-triaged] → [ipv6][necko-triaged][necko-priority-new]

As far as I can tell, none of the other browser engines have expressed an interest in supporting IPv6 link-local addresses.
While that doesn't mean it will never happen, the amount of engineering effort to handle this corner case compared to the relatively minor benefit of this feature means that we're unlikely add this to Gecko at the moment.
If this becomes part of the URL standard I'm open to reopening this conversation.

Status: NEW → RESOLVED
Closed: 9 years ago → 2 months ago
Resolution: --- → WONTFIX
Whiteboard: [ipv6][necko-triaged][necko-priority-new] → [ipv6][necko-triaged]
You need to log in before you can comment on or make changes to this bug.