Subject: Re: Issue 70762 in chromium: Can't specify ScopeID when using link-local IPv6 address. (fwd) [email-masked]: Re: Issue 70762 in chromium: Can't specify ScopeID when using link-local IPv6 address.

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2015 18:03:36 +0900

I think that these are really good questions about IPv6 link local scopes
and HTTP.  I think that we probably aren't done fixing this problem, perhaps.

Subject: Re: Issue 70762 in chromium: Can't specify ScopeID when using link-local IPv6 address.
From: [email-masked]
To: [email-masked]
Date: Sun, 08 Nov 2015 12:41:59 +0000

Comment #35 on issue 70762 by [email-masked]: Can't specify ScopeID
when using link-local IPv6 address.
https://code.google.com/p/chromium/issues/detail?id=70762

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.

--
You received this message because you starred the issue.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

Reply to this email to add a comment.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2015 08:27:31 +1300

It doesn't look to me as if they are aware of RFC 6874; they aren't even using correct
terminology and they are suggesting invalid syntax.

If you feel like it, please point them at RFC 6874.

Over in Mozillaland they have largely washed their hands of the issue (RESOLVED WONTFIX):
https://bugzilla.mozilla.org/show_bug.cgi?id=700999

Regards
   Brian

On 09/11/2015 22:03, Michael Richardson wrote:
> 145
> Subject: 
> Re: Issue 70762 in chromium: Can't specify ScopeID when using link-local IPv6 address.
> From: 
> [email-masked]
> Date: 
> 09/11/2015 01:41
> To: 
> [email-masked]
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Nov 2015 12:28:46 +0100

>https://bugzilla.mozilla.org/show_bug.cgi?id=700999

I wonder if it would help to have something like a default interface on
hosts for link locals.

With the current scheme I'm afraid that users and application developers
will just regard link locals as something weird and ignore them as much
as possible.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Nov 2015 10:07:33 -0500

Brian E Carpenter <[email-masked]> wrote:
    > It doesn't look to me as if they are aware of RFC 6874; they aren't
    > even using correct terminology and they are suggesting invalid syntax.

    > If you feel like it, please point them at RFC 6874.

I've already said things.
I'm posting here because I think that we need more people to say things.

    > Over in Mozillaland they have largely washed their hands of the issue
    > (RESOLVED WONTFIX): https://bugzilla.mozilla.org/show_bug.cgi?id=700999

Yes, I'm aware of that too.

I think 6man chairs should visit: http://openbadges.org/
and create a "badge" for "Egrevious violation of IPv6 architecture" and
award it to these two browsers.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2015 14:23:03 +1300

> I wonder if it would help to have something like a default interface on

There really is one, according to RFC 4007:

   An implementation should also support the concept of a "default" zone
   for each scope.  And, when supported, the index value zero at each
   scope SHOULD be reserved to mean "use the default zone"...

Effectively that means interface index 0. I don't think we can impose a default
interface *name* though, because the names are entirely local and unrestricted.

> will just regard link locals as something weird and ignore them as much

They are weird in that using them in referrals to any other node that
isn't on the same interface is broken. But for any two-party communication,
they are just the same as any other address.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Nov 2015 13:15:46 +1100

Hi,

> and HTTP.  I think that we probably aren't done fixing this problem,
perhaps.

So I posted this to v6ops recently, just because that seemed more suitable
as a first place to look for feedback.

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/id/draft-smith-ipv6-link-locals-apps-00.txt

It looks like some discussion of LL user interface issues should be
discussed/expanded upon.

Regards,
Mark.

>
> ---------- Forwarded message ----------
> Cc:

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2015 11:38:03 +0100

>interface *name* though, because the names are entirely local and unrestricted

The problem is that it doesn't seem to work.

I tried on Linux, OSX, FreeBSD. 

ping6 fe80::1 
and
ping6 fe80::1%0

fail immediately. No (ND) packets go out.

>they are just the same as any other address.

I don't know where it is coming from, but there is the suggestion that
trying to use link locals with the default scope will always fail.

Maybe somebody remembers where that notion was first introduced.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Nov 2015 10:54:28 -0800

At Thu, 12 Nov 2015 11:38:03 +0100,

> fail immediately. No (ND) packets go out.

FreeBSD supports the concept of default zones, although it might look
hidden (and probably not documented explicitly):

# ndp -I lo0
ND default interface = lo0
# sysctl -w net.inet6.ip6.use_defaultzone=1
# ping6 fe80::1
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1
16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.093 ms
^C
# ssh -v fe80::1
OpenSSH_6.6.1, OpenSSL 0.9.8zd-freebsd 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to fe80::1 [fe80::1] port 22.
debug1: Connection established.

The same ndp option and sysctl exist on OSX (10.9.5, which happens to
be the latest version I have access right now), so it could
potentially work in the same manner.  But it failed for me when I
tried it right now.  Maybe there's some custom change that prevents it
from working.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Nov 2015 11:05:10 -0800

At Tue, 10 Nov 2015 08:27:31 +1300,
> https://bugzilla.mozilla.org/show_bug.cgi?id=700999

Actually, the conclusion in Mozillaland appears to come from an
argument by a Chrome developer:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2

So basically they both have "washed their hands" in Mozillaland and in
chromium.

--
JINMEI, Tatuya

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 17 Nov 2015 14:15:27 -0500

On Tue, Nov 17, 2015 at 1:54 PM, 神明達哉 <[email-masked]> wrote:

> > >Effectively that means interface index 0. I don't think we can impose a
> defaul
> > >t
> In a perfect world, the default zone would be named '%25" across systems.
This
would probably cover 99.9% of the browser use cases while keeping the URL
police happy.

Kerry

---

From: Philip Homburg <[email-masked]>
Date: Wed, 18 Nov 2015 13:46:35 +0100

>16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.093 ms

It would be nice if in some host requirements RFC we can say:
Hosts SHOULD set the default zone to something sensible (with a suitable
definition of sensible). Admins SHOULD be able to override this manually.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Nov 2015 08:26:44 +1100

> definition of sensible). Admins SHOULD be able to override this manually.

Actually I would prefer there to not be a default zone.  All it does is
hide application bugs like this one.

The %scopeid is local to the browser.  It shouldn't be going over
the wire.  Link locals received in a document as a href need to
have the appropriate scopeid added by the browser or it needs to
remember over which interface it received to document so it can add
them when it makes a subsequent connect() call.

Servers should qualify link locals in the received Host: based on
the interface the connection was received on.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Thu, 19 Nov 2015 12:35:18 +0100

>hide application bugs like this one.

I think forcing a user to type in a scope id when there is only one network
interface is a complete UI bug.

Introducing UI bugs to force application developers to do the right thing
sounds like a horrible approach to me.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Nov 2015 23:27:46 +0900

> interface is a complete UI bug.

No host that you use has only one interface. They all have at least
loopback and something else. Many (e.g., your phone) likely have more
than one besides loopback.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 19 Nov 2015 15:39:14 +0100

>than one besides loopback.

Right. So a user can't ping fe80::1 because it is not clear if the user wanted
to ping to loopback interface? Really?

My phone is old enough that it seems to switch between the wifi and 3g. If
the phone can explicitly switch between the two and it can also switch
the default zone.

Yes, if a host is truely multihomed, there is no clear default. If a host
wants to disable the default zone in that case, its fine with me.

But as long as the host has very clearly one interface over which packets
go out, then I expect the default zone to be set accordingly.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Nov 2015 16:18:23 -0300

> to ping to loopback interface? Really?

Well... fe80::1 is not loopback, so....

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Nov 2015 08:19:53 +1100

> Well... fe80::1 is not loopback, so....

I think it would be possible to come up with a set of rules about what the
default zone should be, however the rule set itself then becomes the
complicated thing to remember if you're deviating from the convenient
default case (e.g., troubleshooting). It creates tension between the user
friendliness principles of convenience, simplicity and consistency.

e.g.,

If the host has no default routers, and the host has only two interfaces, a
loopback and a physical interface, the physical is the default zone while
the physical interface is administratively up. If it is admin down,
loopback becomes the default zone.

If the host has one or more default routers, limited to one of its physical
interfaces, then then that physical interface is the default zone.

If the host has multiple default routers over multiple physical interfaces,
then loopback (or the first loopback if there are multiple) is the default
zone.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Nov 2015 19:48:50 -0300

On 11/19/2015 06:19 PM, Mark Smith wrote:
> 
> On 20 Nov 2015 06:25, "Fernando Gont" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> >> <[email-masked]
> <mailto:[email-masked]>> wrote:
> I think it would be possible to come up with a set of rules about what
> the default zone should be, however the rule set itself then becomes the
> default case (e.g., troubleshooting). It creates tension between the
> user friendliness principles of convenience, simplicity and consistency.
> 
> e.g.,
> 
> If the host has no default routers, and the host has only two
> interfaces, a loopback and a physical interface, the physical is the
> default zone while the physical interface is administratively up. If it
> is admin down, loopback becomes the default zone.
> 
> If the host has one or more default routers, limited to one of its
> physical interfaces, then then that physical interface is the default zone.
> 
> If the host has multiple default routers over multiple physical
> interfaces, then loopback (or the first loopback if there are multiple)
> is the default zone.

Since doing an "ifconfig -a" and later doing say, "ping6 fe80::1" cannot
possibly be done as an atomic operation, an interface might come up
after the "ifconfig -a", and hence the "default zone" could change and
therefore you could e.g. end up ping'ing a different node than you think
you're pinging.

IMO, such "default zone" thing seems to be, in principle, like asking
for trouble.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Philip Homburg <[email-masked]>
Date: Fri, 20 Nov 2015 10:59:36 +0100

>IMO, such "default zone" thing seems to be, in principle, like asking

You already have that problem on v4. If you ping 169.254.0.1 or even
192.168.0.1, you don't know which interface is going to be used.

As far as I know, nobody every complained about that.

Note, I'm not against leaving the default zone undefined if there is too
much ambiguity.

I.e., set the default interface if there is only one interface with a default
router. Or, if there are no default routers, if there is only one active
interface that has any connectivity to the outside world.

Otherwise leave it undefined.

And make sure that the user can set it explictly.

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Nov 2015 21:27:40 +1100

> As far as I know, nobody every complained about that.

I understand and mostly agree with your point, however I would ask how
often that has actually happened?

Is the example use case all that common? To techs like us, maybe, but to
ordinary users, is it common, even when under instruction from techs like
us?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 20 Nov 2015 15:02:36 +0100

>ordinary users, is it common, even when under instruction from techs like

I'd say general purpose multihoming is relatively uncommon in the IPv4 world
(and is likely to remain uncommon in the IPv6 world).

The reason is that most applications don't provide an easy way to specify the
outgoing interface and the system is not smart enough to pick one.

Say you have a mobile phone and it brings up both the wifi interface and the
4g interface and now you start watching movie. It is possible that you
want it to be over 4g because the wifi is crap. It is also possible that 
suddenly you are exceeding your monthly download limit on 4g and never
realised it.

The best way to not confuse the user is to have only one active interface at a
time.