New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 70762 link

Starred by 48 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Nov 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Can't specify ZoneID when using link-local IPv6 address.

Reported by cnep...@gmail.com, Jan 25 2011

Issue description

Chrome Version       : 7.0.517.41
Other browsers tested:
       IE 7/8: OK

What steps will reproduce the problem?
1. Have a web site available through link-local IPv6 connectivity.
2. Try specifying the IPv6 link-local scope ID in the URL.
Example: http://[fe80::240:8cff:fe9d:65da%13]/

What is the expected result?
The URL is parsed accordingly, and the connection is made to the IPv6 link-local address on the correct network adapter (as specified by the scope ID).

What happens instead?
The parsing of the IPv6 address & scope Id fails, so a Google search is launched instead of accessing the resource specified.


IPv6 link-local address MUST be suffixed with the scopeID as the following notation: Address%ScopeID. I know that Windows 7 "helps" users by allowing an IPv6 link-local address to be routed through the correct interface, even if the scope ID is not specified. Although this is not standard. Try pinging an IPv6 link-local address in a Linux shell without specifying scope ID...

 

Comment 1 by eroman@chromium.org, Jan 25 2011

Labels: -Area-Undefined Area-Internals Internals-Network
Status: Untriaged
Lorenzo/Paul, how important is support for the scope IDs?

In http://codereview.chromium.org/99183 I was advised that support for it wasn't necessary in our canonicalizer, since it wasn't a part of the RFC:

> Also, I think you may want to drop the "%" interface identifier parsing.
> See RFC3986, section 3.2.2: "This syntax does not support IPv6 scoped
> addressing zone identifiers."

Adding it in will cause additional complexity throughout the code, since all consumers of GURL will have to be more aware of this field, and how to use it correctly in comparing URLs and equality of hosts.

Thanks for advise.

Comment 2 by pmarks@google.com, Jan 25 2011

Well, as you quoted me saying, the current implementation does comply with the RFC, so the question is whether Chrome should go beyond the RFC.

My understanding is that link-local addresses are primarily an abstraction layer that lets you avoid dealing with MAC addresses in low-level code, so I'd question the utility of accessing one from a web browser.  If an HTTP server is meant to be accessed remotely, then it should have a global or unique-local address.

I wouldn't be *opposed* to supporting scope IDs, it just seems like unnecessary complexity.

Comment 3 by wtc@chromium.org, Jan 31 2011

Labels: Mstone-X
Status: Available
I think the support of scope ID won't add complexity.  It should
not require a new field for GURL.  The scope ID is part of an IPv6
address literal, so the existing "host" field of GURL should suffice.

HostResolver will need to be able to convert a host name that contains
a scope ID to a sockaddr_in6 structure.  getaddrinfo or getnameinfo
can do that.

I discussed this issue with eroman in person.  eroman doesn't want
Chrome to send a Host header that contains an IPv6 address literal
with a scope ID (because the scope ID is meaningless to the server),
but Chrome already sends "Host: localhost" or "Host: 127.0.0.1" to
a server, so this problem isn't new.

Another issue we should consider is whether this complicates
same origin security policies.

Re: URL canonicalization (http://codereview.chromium.org/99183):
I suggest that we not canonicalize scoped IDs.

Comment 4 by lorenzo@google.com, Jan 31 2011

I have found scope IDs useful for things like configuring IPv6-capable home routers (e.g., by typing http://[fe80::218:e7ff:fef3:67f7%eth0]/ ). getaddrinfo() should already be able to deal with scoped addresses in hostnames, though I suppose it depends on the quality of the underlying getaddrinfo implementation.

If we do support this kind of URL, my feeling is that we shouldn't pass the %eth0 on to the server. Paul?

Comment 5 by pmarks@google.com, Jan 31 2011

Firefox 3.6.13 strips the scope ID:
Host: [fe80::21a:a0ff:fe17:9b27]:8080

ELinks leaves it in:
Host: [fe80::21a:a0ff:fe17:9b27%eth0]:8080

curl, wget, Konqueror, and Arora weren't able to connect.

Comment 6 by ek@google.com, Feb 1 2011

I think the right thing to do is going to be to support this (even though it may be a PITA).  Other browsers are supporting it, and it may very well come in handy for configuring IPv6-only home networking gear.  Sadly, I see little choice if mDNS and MLLNR aren't universally supported.

That being said, I think that sending the scope_id to the server in the Host: header is probably going to be required.  Otherwise, non-relative URL redirecting won't make sense to the client.

Specifically, I'm thinking that an IPv6-only device's web server might want to redirect from http to https.  I think it would have to send a 30x with Location: https://[fe80::f00%eth0]/.  Otherwise, yes, the server can be required to always use relative links.  But I think this one case may require it.  (And yes, the TLS cert will not validate, but that's the nature of these home devices anyway.)

As for URL equality/comparison, [fe80::foo%eth0]:8080 should equal [fe80::foo%1]:8080, iff. if_nametoindex("eth0") == 1.  This is something that can only be validated in a local context, clearly.  But it may not be exercised very often; nothing should be altering link-local URIs this way since it's not safe if the server and client aren't on the same host.

Man this stuff is edge-casey.

Comment 7 by Deleted ...@, Aug 3 2011

From a network management card embedded engineer developer point of view, YES, please support the link local scope ID.  Link-local is the most straightforward way for me to test out my many network devices using IPv6, since the address is created automatically.  It would be a huge pain to go through and set up static addresses for every device that comes by my desk.  IE8 forces me to use "%25" in place of the "%" sign.  Firefox works fine. Chrome doesn't work at all.  I'm sticking to using Firefox for my development until it is supported by the other browsers.

Comment 8 by pmarks@google.com, Jan 30 2012

It looks like Firefox has dropped its support for scoped IPv6 addresses, and there's been some IETF discussion about extending the URL syntax to support them properly:

http://www.ietf.org/mail-archive/web/ipv6/current/msg14977.html
http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-00

this is a must-have for ipv6-only networks. imagine a wireless-ap with its web front-end. link-local addresses are well supported on those devices but other types of autoconfiguration may not so link-local address is the only way to actually reach the device...

Comment 10 by pmarks@google.com, Jan 11 2013

> imagine a wireless-ap with its web front-end

Could you imagine telling someone to visit http://[fe80::f00%bar]/ where %bar depends on the source machine?  It'd be a train wreck.  This sort of thing should probably be done using unique-local addresses.

imho, it's not really about telling someone but scanning the network segment and using the link-local address to connect to the device. unique-local would work, just as would global addressing but the problem is delivering the address to the device. in my experience, they usually don't care about router advertisements nor dhcp6 so the only way to configure them is setting static address... ...which sucks when you can't reach them in the first place. ;-)

anyway, what i wanted to say was: link-local addresses are there and it's a great way to address device without any manual configuration. i don't know whether these are mandatory or not but every piece of ipv6-capable hardware i've used just had one.

Comment 12 by pmarks@google.com, Jan 14 2013

The IETF is still specifying how this should work:
http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-06

When the draft becomes an RFC, this issue should probably be revisited.

Project Member

Comment 13 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
The IETF has finished considering this, and it's waiting for publication.
http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/

Comment 15 by pmarks@google.com, Apr 30 2013

Looks like it's an RFC already: http://tools.ietf.org/html/rfc6874

I think the use of "%25" as a separator is quite hideous, especially on Windows, where it's not uncommon for interfaces to be identified using a 2-digit number.

Even if hideous, it's now a standard, and should be implemented ASAP. 


Still experiencing this in 33.0.1750.152 on OS X.  Tried using a link-local address to set up a new wireless AP, but I was unable to get Chrome to recognize the scope identifier (%en0 in the case of my Mac, encoded to %25en0), so it kept initiating a search.  The bare IPv6 address literal was accepted by Chrome, but the default interface on the machine was not en0, so Chrome was unable to establish a connection.
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]

Chromium 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

Comment 19 by bbitt...@gmail.com, Feb 27 2015

i can confirm this with 41.0.2267.0 dev - really annoying.

e.g. cURL added these fixes, see:
https://github.com/bagder/curl/commit/9a452ba3a16bb51249e1d1be5a5b6e47a255c064
https://github.com/bagder/curl/commit/9081014c2c467077723d5ae1d0081003b3eb3504


Comment 20 by laforge@google.com, Apr 28 2015

Cc: -wtc@chromium.org

Comment 21 by b...@chromium.org, May 6 2015

Labels: -Cr-Internals

Comment 22 by zull...@gmail.com, Aug 25 2015

We, as a company, also require a web browser that's able to access embedded devices which only have a link local address.
Another year, and still this an issue.  Could this be fixed with an extension/plugin?

Comment 24 by chadm...@gmail.com, Aug 29 2015

Mcharl, Socket set-up is deep in networking code. Extensions can't get
anywhere near that.

Comment 25 by chadm...@gmail.com, Aug 29 2015

Mcharl, Socket set-up is deep in networking code. Extensions can't get
anywhere near that.

Comment 26 by Deleted ...@, Oct 31 2015

HOLY SHIT

Comment 27 by Deleted ...@, Oct 31 2015

5 Years

Comment 28 by cnep...@gmail.com, Nov 3 2015

Fix the issue or make a statement that Chrome doesn't support link-local IPv6 connectivity.

This infamous bug has been sitting around for five years. Take position and act.

- Original reporter
Owner: cbentzel@chromium.org
Chris, could you decide if this is worth our time to implement?

#29: Looking into this over the weekend. This will likely require both low-level networking changes as well as omnibox changes to make sure that it is treated as a navigatable-string rather than a searchable string. My initial reaction is that it seems like cost/benefit not worth it (both up-front as well as long-term maintenance) but want to educate myself a bit more about  this before making a call. 
Thanks for taking a look at this! This scenario is definitely an edge case in Web or normal Intranet usage. But it comes up in practice when working with embedded devices or devices on the Internet of Things; there's a lot of ways to lose or not-have DHCP on their network interfaces when you're building them. I starred this issue after hitting a few of them in close succession one day at work. :)

Without this you need complicated forwarding, or a whole other browser as a workaround, even though the actual Web console for the device works fine in Chromium when you get a routable address for the device again.
#30:
>not worth it to implement (both up-front as well as long-term maintenance)

IPv6 usage is only gonna keep growing. Scope ID implementation in Chromium is an absolute /must/ for contacting fe80 addresses and configuring modems. Either implement it or lose users in the future when they figure out Chromium doesn't do scope IDs.

The way I see it, you either implement it:
>now
>later, when the system is more complicated
>even later when both the system is more complicated and you've got more people who want this feature and in the meanwhile (permanently) switch to another browser

Not my loss...

Comment 33 by zull...@gmail.com, Nov 7 2015

I As well want to stress the "usefulness" of this feature in IoT: Initially, we were very excited when using IPv6 for our embedded devices: Every device automatically gets it's unique IPv6 automagically. Even better: The LL-IPv6 even contained the MAC-address of the target (if it's not intentionally obfuscated). This is great, as the devices of the company I work for have their unique MAC prefix. So we could easily identify "our devices".

Unfortunately, we had to find out that LL-Addresses are completely useless with current browsers - unless working on Windows, which seems to automatically direct IPv6 packets for LL addresses to the right interface. But OSX, iOS, Linux (also Android of course) do not.

IOW: LL-IPv6 addresses are currently completely useless from a browser point of view. And, many (most?) modern devices do have a web interface, don't they? So one could say: LL-IPv6 are useless for a huge range of devices and therefore, using IPv6 devices always requires a full blown IPv6 network being setup - and that's something that's not given today in middle-europa as random tests at our customers have shown (in fact, not one of them has IPv6 properly setup so far on network infrastructure side!)
To re-iterate: without this feature, chrome, chromebooks, android phones and tablets will be unable to configure a router in a new home.  

Thanks for additional discussion - there's clearly reasonable cases for this, but it does introduce many complications.

One question (and others may know) is how the ScopeID should be part of the host when thinking about web origins. I worry that we are going to have to special case this, which makes things tricky. For example, we clearly need to include the symbolic ScopeID when doing getaddrinfo() calls and include the numerical ScopeID when doing UDP/TCP sockets. But since a host-local concept, sending out as Host header or Referer header seems like we'd want to strip it out. Also, should we expect it when getting a Location header for a 302-redirect? What host should we expose if doing proxy evaluation or going to WebRequest?

I'd like to work these out but it feels like we are going to have to not treat the host as consistent the whole way through the networking stack which worries me.
nd also, looking through low-level details:

HostResolver:
    * Need to make sure not to handle as strict IPv6 literal.
    * Caching and other grouping needs to include ScopeID to make sure different results go into place.
    * On platforms where we have built-in resolver we either need to do the mapping ourselves or pass these on to getaddrinfo (prefer getaddrinfo)
    * Will it need to also validate with FE80::/10 only address?

IPEndPoint:
    * IPEndPoint needs to contain a ScopeID. This might just require the addition of another constructor or setter.
    * ToSockAddr would need to fill this in.
    * FromSockAddr might also need to fill this in?
 
Socket classes.
    * Should just happen automatically. Both TCP and UDP sockets just use the sockaddr and don't inspect it. 
Other open questions to me, maybe this is easier:
  - How would this work with event filtering for the webNavigation extension API (https://developer.chrome.com/extensions/webNavigation#event-onBeforeNavigate)? Would the scope identifier be included in the host when matching, or would it be removed?

  - How many extensions (webRequest, webNavigation) would break when doing URL parsing if we include the scopeid? Right now URL is just passed as a string sp there may be some cases where this breaks.

  - How would omnibox treat this as a navigation? We'd have to make sure that the IPv6 literal parsing portion can handle this here.
So, overall I'm leaning towards WontFix. The low-level modifications to HostResolver and IPEndpoint seem fine and would be worth doing. But if there is inconsistency in whether the ScopeID is included in the hostname or not, and we have to deal with potentially broken extensions (would want to validate) and other pieces higher up the stack I think the complexity is too high to be worth the benefit.
The scope is not part of the address, and should be treated in the same way
we treat "username@" prefixes. Store and strip.

Any typed request to a link local address has to have a scope, and we
should even warn about it if it's not supplied.

The scope should be stored in the request context, and on any redirect or
other need to qualify or look up an address in the link-local range, we
apply what's stored in the request context. Just what we do for other
things already.

A scope is always local information, so redirects and such can't affect it
or even know about it. Scope strings coming from remote hosts has to be
discarded.

To construct a socket, we always use the same scope that led to this need
for a socket. Globally- or public-addressed requests can't refer or
redirect to link-local. One link can't refer or redirect to a different
link. (This solves all sorts of security problems too.)

Comment 40 by zull...@gmail.com, Nov 8 2015

(If you feel the following to be off-topic, then just ignore it.)

From an (ordinary) user pointer of view, I really don't want to specify the Scope ID. Usually, I'm already lucky to know the hostname or IP of a device - I may not even know about the existence of scope IDs. That said, I think that what Windows seems to do under the hood is what an end user actually wants: It somehow automatically detects the "right interface" for a given LL Pv6. I tried to find an explanation about the internals of that mechanism without luck. I suspect they check the "neighbour cache" to find the "right" interface.

At other places, I've read, that not specifying the desired interface can lead to security risks because LL-IPv6 are not necessarily unique. Honestly, I don't fully understand that, because:
 1) If devices use their MAC address to derive their IPv6 from, the LL IPv6 usually IS unique
 2) A malicious device may as well create non-unique non LL IPv6 addresses with collide with devices on other interfaces, don't they? (thus, I don't see much difference between non-LL IPv6 vs. LL IPv6 regarding security)
Because I'm under that impression (and I'm aware that I'm probably wrong because I missed something), I think it would be perfectly fine if Chrome could re-implement the Windows mechanism on non-Windows platforms: Self-determining the Scope ID.

Comment 41 by pmarks@google.com, Nov 8 2015

Automatic discovery could work in two ways:
1) Before connecting to a LL address, perform ND for it on every network interface.
2) Only permit connecting to LL addresses that already exist in the neighbor cache.

Option 2 would be relatively simple to implement (the netlink equivalent of "ip neigh show fe80::f00"), with the caveat that the user might need to drop to the command line and ping6 a device before connecting to it.

Both automatic approaches need to handle the situation where the address is reachable via more than one interface, even if "handle" means "pick one arbitrarily".
if there's any chance to add my humble opinion: i don't care how complicated the access will be (having to ping the device beforehand, specifying this and that extra info, ...) but i just care about being able to reach the host in the end - it's usually a one-time thing, anyway...

Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
Status: WontFix
I'm moving this to WontFix.

There are a large number of special cases which are required on core networking/navigation/etc. and it does not seem like it is worth the up-front and ongoing maintenance costs given that this is a very niche - albeit legitimate - need.
Hi,

I can imagine it's hard because, let's face it, linux support for ipv6
ll is very very bad, unless you are (like me) moving around embedded
systems.
But currently the status is that you are actually saying that ipv4
zeroconf should work, and ipv6 zeroconf users should just switch to
windows and sell their chromebooks, because users will not be able to
browser their local lan.
The RFC is clear though: %%<interface> name should work. I'm not
requesting to fix it now, I am requesting to set the status to long
term needs fixing. IPv4 *.lan still works for now, but that will
dissappear within 5..10 years, and it will be replaced by ipv6 link
local communications.
So preparing for that might be a very wise decission. But not
supporting it right away on linux is acceptable, since most of
link-local development has been held back by some weird rumour in
linux-land that link-local is only intended to reach the router.
Microsoft and apple has already full support for link-local and mdns.
And ipv6 zones in the url ;-).
#44: If this were simply a case of specifying how URLs would need to be, changing how we do name resolution, and passing scope id to socket connect calls I'd say we should do it. But #39 also points out additional cases of weirdness where Scope is kind-of part of the hostname, and kind-of not. We'd have to make sure to strip it out when doing input validation of redirects or other locales, as well as strip it out for host. But we'd have to remember it when normalizing URLs for subresources for example. This lack of consistency means a lot of corner-cases throughout the resource loading stack of Chrome.
Labels: -Mstone-X mstone-X
I am very disappointed (and vigorously disagree) with the decision for
this to classified as `WontFix`.

I ran into this issue this weekend while setting up new network
equipment at my house. I was able to work around it, but I should have
been able to just type in the URL with the link-local address and
interface identifier into my browser and have it work.

We are so close to realizing the IPv6 dream, and IPv6 link-local
addressing is a big part of that vision.

It's even worse than IPv4, because IPv4 stateless auto-configured
addresses are at least still accessible from the browser (if you can
figure out that the address is).

Regarding comment #43:

> ... does not seem like it is worth the ... ongoing maintenance costs

If "ongoing maintenance costs" are REALLY a consideration, then
perhaps you should also consider removing URL-based usernames and
passwords. Handling those special cases has much more nuance to
ongoing maintenance. I mean, those are niche *AND* a significant
security problem. But I'm sure those are here to stay regardless, so
let's forget the "ongoing maintenance costs" and focus on "up-front
costs".

Regarding comment #36,

> HostResolver:
>
>  *  Caching and other grouping needs to include ScopeID to make sure
>     different results go into place.

Is there any way to just not do any caching when the IPv6 address has
a scope id? We don't care about performance.

>  *  On platforms where we have built-in resolver we either need to
>     do the mapping ourselves or pass these on to getaddrinfo (prefer
>     getaddrinfo)

I would absolutely rely on `getaddrinfo`. Don't go trying to do the
mapping yourself. Rely on the operating system to handle parsing this.

>  *  Will it need to also validate with FE80::/10 only address?

I do not understand what you mean by "validate". Ideally, you would
pass the string to `getaddrinfo` and let it figure it out.

Regarding comment #37:

> How would this work with event filtering for the webNavigation
> extension API
> (https://developer.chrome.com/extensions/webNavigation#event-onBeforeNavigate)?
> Would the scope identifier be included in the host when matching, or
> would it be removed?

I'd prefer included (Everything between the square brackets, after
unescaping, should be considered the host string), but I'd but this in
the beggars-can't-be-choosers category. Whichever is easier is fine by
me.

>  *  How many extensions (webRequest, webNavigation) would break when
>     doing URL parsing if we include the scopeid? Right now URL is
>     just passed as a string sp there may be some cases where this
>     breaks.

Seems pretty easy to test. As long as the URL parsing is done
correctly, the `%25`-style interface identifier should parse just
fine. There always might be that busted case, but it seems pretty
tragic to simply give up because there might be cases where it doesn't
behave properly.

To the extent that handling it doesn't introduce a security issue, I'd
much rather have support for interface identifiers with a few buggy
edge cases than no support at all. I just want to be able to
occasionally connect to my equipment when there are no routers on the
network (and, thus, everything is link-local only) to change a few
settings on the web interface.

>  *  How would omnibox treat this as a navigation? We'd have to make
>     sure that the IPv6 literal parsing portion can handle this here.

This seems like it would be a fairly easy thing to do. The most simple
approach would be to consider any host enclosed by square brackets
that is properly escaped as a valid URL (at least as far as the host
part is concerned). If the user really wants to do a google search for
`http://[i%20have%20no%20idea%20what%20im%20doing]`, then they should
probably end up going to google.com and typing it in the old fashioned
way.

All that being said, one way to possibly stop the bleeding would be to
simply always include an "assumed" interface identifier (chosen using
some as-of-yet-undefined heuristic) when parsing a link-local address.
This would allow the use of link-local addresses in most cases that
people care about, without needing to plumb interface identifiers
everywhere. I'm not a fan of this, because the heuristic might be
fragile, but if the heuristic more often than not did the right thing
(picking the current primary network interface, whatever that means),
then it would certainly help when setting up network equipment.

Please consider re-evaluating the status of this issue.

Comment 47 by ar...@maven.pl, Dec 8 2016

Wanted to connect to my router admin panel on link-local address and ended up here, reading this bug :-(


It is inacceptable that this is a "WontFix".
I have a situation right now where my router doesn't react on IPv4, but not on IPv6 link-local and I need to check why that is before trying to reboot the device or it might get bricked, if the developer of the software on it did something stupid.
Neither Firefox nor Chromium support specifying the scope or device in the URL, so I can't access the user interface (except with curl, but the UI is something with JS and digest mechanism built in JS).
Great work.
Why won't fix? This is unacceptable!

Comment 50 by kwaak...@gmail.com, Nov 23 2017

What is even worse is that chromium also can't handle link local proxy
addresses. I have to install a proxy (socat) on the machine that
connects to the real proxy. Oh wait, that's not possible on chromeos.
One of the many reasons I always need a real laptop with me onstead of
a chromebook.
I put a considerable amount of thought and effort into writing comment #46, discussing all sorts of various alternatives to the presented problems: including one that involves no URL parsing changes (suboptimal, but better than the current state of things) that seems relatively straightforward.

I would appreciate it if at least some of my suggestions were evaluated and discussed.

I believe that someone simply has to write the code, contribute it as a
patch to chromium via a debian/ubuntu patch file, and then we can bug
google to adopt the code publically.
The inability to handle a link-local proxy (#50) seems especially annoying. Using SLAAC addresses isn't a good solution because those will change if the router gets a new prefix, mysteriously breaking things. The ability to use a link-local address there would significantly improve robustness.
Labels: Restrict-AddIssueComment-EditIssue
As per Comment #43, there are no plans to support this.
Labels: -mstone-X
Summary: Can't specify ZoneID when using link-local IPv6 address. (was: Can't specify ScopeID when using link-local IPv6 address.)

Sign in to add a comment