Firefox does not appear to support IPv6 link-local addresses

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
7 years ago
2 years ago

People

(Reporter: kerlyn, Assigned: valentin)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ipv6], URL)

(Reporter)

Description

7 years ago
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.

Comment 1

7 years ago
> This bug is probably in the Networking component
Yes, in Product: Core
Blocks: 392428
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Component: General → Networking
Keywords: regression
Product: Firefox → Core
QA Contact: general → networking
Resolution: --- → DUPLICATE
Duplicate of bug: 392428

Updated

7 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 2

7 years ago
(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.

Comment 4

7 years ago
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).

Comment 5

7 years ago
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.

Comment 6

7 years ago
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.
(Reporter)

Comment 7

7 years ago
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

Comment 8

6 years ago
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.
(Reporter)

Comment 9

6 years ago
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.

Comment 10

5 years ago
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).

Comment 11

5 years ago
(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]

Comment 12

4 years ago
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)

Comment 14

4 years ago
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)

Updated

4 years ago
Keywords: dev-doc-needed
OS: Linux → All
Hardware: x86 → All
Version: 8 Branch → Trunk
(Reporter)

Comment 16

4 years ago
(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-

Comment 17

4 years ago
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.

Comment 18

4 years ago
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.

Comment 19

4 years ago
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.
(Reporter)

Comment 20

4 years ago
(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.

Comment 21

4 years ago
(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.

Comment 22

4 years ago
(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 %.
(Reporter)

Comment 23

4 years ago
(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.

Updated

4 years ago
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

Comment 25

4 years ago
"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.

Comment 27

4 years ago
(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.

Comment 28

3 years ago
Resolving WONTFIX per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2.
Status: NEW → RESOLVED
Last Resolved: 7 years ago3 years ago
Resolution: --- → WONTFIX
Keywords: dev-doc-needed

Comment 29

3 years ago
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.)
(Reporter)

Comment 30

3 years ago
+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)

Comment 32

3 years ago
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.)

Comment 33

3 years ago
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.

Comment 35

3 years ago
(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)

Comment 36

3 years ago
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] )

Comment 37

2 years ago
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.

Comment 38

2 years ago
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.

Comment 39

2 years ago
(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

Comment 40

2 years ago
(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. :-)

Comment 41

2 years ago
(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 ...

Comment 42

2 years ago
(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 )

Comment 43

2 years ago
(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.

Comment 44

2 years ago
(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 ;-)
You need to log in before you can comment on or make changes to this bug.