Subject: The ongoing SAGA of some browsers vs link-local addresses

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2016 13:25:22 -0500

Is there some way we can provide some liason feedback from the IETF to the
w3c about the w3c's conformance testing?

Subject: Issue 70762 in chromium: Can't specify ScopeID when using link-local IPv6 address.
From: "[email-masked] via Monorail" <[email-masked]>
To: [email-masked]
Date: Tue, 01 Mar 2016 21:06:37 +0000

Updates:
	Labels: -Mstone-X mstone-X

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

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.

--
You received this message because:
   1. You starred the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

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

---

From: joel jaeggli <[email-masked]>
Date: Wed, 2 Mar 2016 10:56:59 -0800

> w3c about the w3c's conformance testing?

liason statements are within our remit. conformance testing generally is
not.

>  -= I6 IoT consulting =-
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 2 Mar 2016 14:12:13 -0500

FYI, the corresponding Firefox bug is
https://bugzilla.mozilla.org/show_bug.cgi?id=700999

Kerry

On Wed, Mar 2, 2016 at 1:25 PM, Michael Richardson <[email-masked]>
wrote:

> ---------- Forwarded message ----------
> Cc:
> > (
> https://developer.chrome.com/extensions/webNavigation#event-onBeforeNavigate)?

---

From: Brian Haberman <[email-masked]>
Date: Wed, 2 Mar 2016 20:48:15 -0500

Mark Nottingham ([email-masked]) is our W3C liaison manager. I suggest
discussing it with him.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 3 Mar 2016 09:49:20 -0500

And to be clear...

This topic has been discussed with Mark in the past. The exchange was:

>> Just to make sure I understand the use case, the device doing the
>> configuration is connected to multiple networks, so it needs the
>> scope-id to disambiguate which link-local address space is at issue
>> for the configuration?​  If that's the driving use case, then
>> articulating that concretely to the browser manufacturers may help
>> some or may help identify some other way of meeting the use case.
>> If that helps them see the bang for the buck, in other words, that
>> may move the needle.  I don't think asking the W3C to tell them to
>> do it will do so; they didn't do it when we did, and the underlying
>> calculus won't change just because the SDO did.
>
> You have correctly described the use case.
>
> How do we articulate that to the browser manufacturers?

My .02 -

I think it's unlikely this will convince the browser folks; reading
between the lines of Ryan's response, supporting this is perceived as
making things much more complex, and therefore increasing security
surface area.

Also, realise that despite the location of the bugzilla instance, this
is NOT a W3C decision -- it's WHATWG, in the URL spec.

The best I think you could do would be to go to them with the use case
and ask how it should be addressed, if not by RFC6874 support. I suspect
the result will still be effectively negative, because while it's a
legitimate use case, it's likely to end up pretty far down on the
priority list for the foreseeable future.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 3 Mar 2016 12:09:58 -0500

On Thu, Mar 3, 2016 at 9:49 AM, Brian Haberman <[email-masked]>
wrote:

> I don't see an easy way to configure an IPv6-only device without this
capability.
Therefore, I come to the conclusion that IPv6-only devices are unlikely in
the
foreseeable future.

Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2016 08:38:48 +1300

I think we should consider a 6874bis with a less imperative statement about
never exporting the Zone ID in a URI. I believe that the specific problem that
the browser people (and the CUPS protocol) have is with this:

  "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."

Firstly that is a pain to implement and breaks some assumptions about
the nature of a URI, and secondly it breaks CUPS.

If we do that, we'd need to use the liaison channel and contact the
whatwg.org folk as well, to check that any update would be effective.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Mar 2016 14:47:47 -0500

Kerry Lynn <[email-masked]> wrote:
    > capability.  Therefore, I come to the conclusion that IPv6-only devices
    > are unlikely in the foreseeable future.

if a LL+scope is returned via mDNS/Bonjour, can it be used?
Does having the name.local sufficiently hide the messy details?

---

From: Michael Sweet <[email-masked]>
Date: Thu, 03 Mar 2016 14:50:59 -0500

Michael,

> On Mar 3, 2016, at 2:47 PM, Michael Richardson <[email-masked]> wrote:

Yes, as long as mDNS works.  There are (unfortunately) a lot of situations where it does not... :/

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Mar 2016 08:28:18 +1100

> Yes, as long as mDNS works.  There are (unfortunately) a lot of
situations where it does not... :/

So isn't this really saying that MDNS needs the work?

It sounds like one of the common use cases is residential / SOHO networks.
I think exposing non-technical end users to link-local addresses (and
addresses in general) to work around failed service discovery is really
unacceptable in an age when we're able to build cars that can drive
themselves.

I've been thinking for a while that one of the ways that we could overcome
the scope issue with LLs is to use the same sort of approach used in ULAs,
by creating a globally unique and unambiguous LL prefix on the link, by
putting a random number in the FE80::/10-/64 bits.

The first router or host on a link would generate the unique LL prefix, and
start announcing it in a RA PIO (host would set router lifetime to zero).
Subsequent hosts or routers would generate addresses from that ULL prefix,
and if the seed host/router went away, one of the other routers or hosts
would take over announcing it, with routers preferred over hosts. (i.e.,
basically combining some ideas from ULAs and Appletalk seed routers (IIRC))

This would be in parallel to the existing FE80::/64 prefix on the link, and
used in preference to it, which I think would most of the time eliminate
the need to deal with LL scopes.

Haven't done much more thinking than that though.

Regards,
Mark.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 3 Mar 2016 16:57:39 -0500

> So isn't this really saying that MDNS needs the work?
I may have lost the plot here.

mDNS (and DNS-SD in general) is about locating services.  The UI generally
presents a list of instances.  It knows which port
the request went out on, so scope ID never needs to be exposed to the
user.  Similarly, there is no need for the responding service
to include a scope ID in its reply, as that parameter is only relevant at
the server and isn't needed by the client to reach the server.

In the browser case, the scope ID is required in order to specify the
_outgoing_ port that must be used by the client in order to
reach the link-local address specified by the host part of the URI.  If
you've ever used ping with a link-local address, it's the same
idea.

What I meant by my comment is that many consumer devices that you buy today
have a default config i/f at 192.168.1.1:80 (or
similar).  If we imagine a future where there are equivalent IPv6-only
devices, you'd want to connect at [fe80::1]:80 + scope (or
similar).  Problem is, scope would be a local matter and the user would
have to figure out the correct value to use.  This could
be exposed e.g. by the network control panel.

Kerry

> The first router or host on a link would generate the unique LL prefix,
> and start announcing it in a RA PIO (host would set router lifetime to
> zero). Subsequent hosts or routers would generate addresses from that ULL
> prefix, and if the seed host/router went away, one of the other routers or
> hosts would take over announcing it, with routers preferred over hosts.
> (i.e., basically combining some ideas from ULAs and Appletalk seed routers
> (IIRC))
>
> This would be in parallel to the existing FE80::/64 prefix on the link,
> and used in preference to it, which I think would most of the time
> eliminate the need to deal with LL scopes.
>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 03 Mar 2016 17:18:15 -0500

Mark,

> On Mar 3, 2016, at 4:28 PM, Mark Smith <[email-masked]> wrote:
> ...

Except with older, buggy home Wi-Fi routers that block all multicast traffic, mDNS generally "just works" on simpler home networks.

This problem happens most in commercial/university networks and P2P links, and again multicast traffic is often blocked for security and performance issues.  In the case of commercial/university networks, you are typically trying to configure the printer with a routable IPv6 address - since few printers actually support DHCPv6, this is largely still a manual process using the printer's web interface and address.  This (naturally) hampers implementing an IPv6-only network...

In the case of P2P connections (Wi-Fi Direct and the like), mDNS is one of the negotiated services so it may not be available at all times.

> I think exposing non-technical end users to link-local addresses (and addresses in general) to work around failed service discovery is really unacceptable in an age when we're able to build cars that can drive themselves.

in controlled environments and on clear roads... :/

The browser use case is generally limited to initial setup - we can typically configure the device with a routable address and/or a mDNS/DNS name and subsequently use those.  As long as browsers do not support IPv6 link local addresses, we will have to use IPv4 addresses to do that initial configuration step...

> I've been thinking for a while that one of the ways that we could overcome the scope issue with LLs is to use the same sort of approach used in ULAs, by creating a globally unique and unambiguous LL prefix on the link, by putting a random number in the FE80::/10-/64 bits.
> 
> The first router or host on a link would generate the unique LL prefix, and start announcing it in a RA PIO (host would set router lifetime to zero). Subsequent hosts or routers would generate addresses from that ULL prefix, and if the seed host/router went away, one of the other routers or hosts would take over announcing it, with routers preferred over hosts. (i.e., basically combining some ideas from ULAs and Appletalk seed routers (IIRC))
> 
> This would be in parallel to the existing FE80::/64 prefix on the link, and used in preference to it, which I think would most of the time eliminate the need to deal with LL scopes.
> 

Isn't the Homenet WG investigating something along these lines already?

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Mar 2016 09:25:25 +1100

On 4 Mar 2016 8:57 AM, "Kerry Lynn" <[email-masked]> wrote:
> mDNS (and DNS-SD in general) is about locating services.  The UI
generally presents a list of instances.  It knows which port
> idea.
>
> What I meant by my comment is that many consumer devices that you buy
today have a default config i/f at 192.168.1.1:80 (or
> be exposed e.g. by the network control panel.

So I think there should be an MDNS browser  built into browsers so there is
no need to type addresses into them to configure local devices with HTTP/S
based UIs.

If there was a universally agreed logo/symbol for MDNS (e.g. the Bluetooth
one), then all of the webrowser  vendors could add it to their toolbar near
the URL input box, and device vendors could then say in their configuration
instructions, "Click the MDNS symbol, and select the device named XYZ",
then a HTTP/S request sent to the device. I think that would be a more or
much more user friendly experience that the IPv4 address or reserved
locally served DNS name method used today.

Regards,
Mark.

> Kerry
>>
>> It sounds like one of the common use cases is residential / SOHO
networks. I think exposing non-technical end users to link-local addresses
(and addresses in general) to work around failed service discovery is
really unacceptable in an age when we're able to build cars that can drive
themselves.
>>
>> I've been thinking for a while that one of the ways that we could
overcome the scope issue with LLs is to use the same sort of approach used
in ULAs, by creating a globally unique and unambiguous LL prefix on the
link, by putting a random number in the FE80::/10-/64 bits.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 3 Mar 2016 17:27:00 -0500

> On Mar 2, 2016, at 1:25 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

This seems like a non-issue.  If I move from wired to wireless on the same subnet
having a URL break because that interface is no longer up is less than useful, we
have other technologies to resolve this, eg: mDNS and regular old DNS.  If neither
of those two work, other things are broken.

There have been so many cases of abuse that can be derived from embedded URLs and 
blocking ports, eg: http://127.0.0.1:19/ also won’t work in most browsers.

- Jared

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2016 11:43:10 +1300

On 04/03/2016 11:27, Jared Mauch wrote:
>> Is there some way we can provide some liason feedback from the IETF to the w3c about the w3c's conformance testing?
> 
> This seems like a non-issue.  If I move from wired to wireless on the same subnet having a URL break because that interface
> is no longer up is less than useful, we have other technologies to resolve this, eg: mDNS and regular old DNS.  If neither of
> those two work, other things are broken.

We've always said that Zone IDs in URLs are *only* useful for diagnostic
purposes. Like Kerry, I fail to see what (m)DNS has to do with this. The issue
is narrow: getting browsers to do what RFC6874 says seems to be impractical,
so let's change RFC6874 to something that browser developers can actually
implement.

    Brian

> 
> There have been so many cases of abuse that can be derived from embedded URLs and blocking ports, eg: http://127.0.0.1:19/
> also won’t work in most browsers.
> 
> - Jared -------------------------------------------------------------------- IETF IPv6 working group mailing list 
> [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 3 Mar 2016 17:49:08 -0500

On Thu, Mar 3, 2016 at 5:25 PM, Mark Smith <[email-masked]> wrote:

> > to include a scope ID in its reply, as that parameter is only relevant
> at the server and isn't needed by the client to reach the server.
> >
> So I think there should be an MDNS browser  built into browsers so there
> is no need to type addresses into them to configure local devices with
> HTTP/S based UIs.
>
Actually, Safari allows you to add the Bonjour logo to either Bookmarks or
Favorites.  It's a setting under Preferences->Advanced.

Kerry

> locally served DNS name method used today.
<snip>

---

From: Jared Mauch <[email-masked]>
Date: Thu, 3 Mar 2016 22:05:15 -0500

> so let's change RFC6874 to something that browser developers can actually

	mDNS is helpful for signaling things on-link where it may not be
in 'proper' DNS, eg: some IoT thing.   Having to specify %en0 or %en4
depending on what my local host is a barrier for the average user, but
I would expect isn't for someone on this list.

	Doing mylivingroomlightbulb.local instead of 
fe80::4211:3feb:b192:8c7c%p5p1 seems like a higher layer of abstraction 
can solve this for a user.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 04 Mar 2016 11:15:18 +0100

In your letter dated Fri, 4 Mar 2016 08:38:48 +1300 you wrote:
> I think we should consider
> a 6874bis with a less imperative statement about never exporting
> the Zone ID in a URI. I believe that the specific problem that the
> browser people (and the CUPS protocol) have is with this:
> 
>    attached to an outgoing URI, as it has only local significance
>    at the sending host."
> 
> Firstly that is a pain to implement and breaks some assumptions
> about the nature of a URI, and secondly it breaks CUPS.
> 
> If we do that, we'd need to use the liaison channel and contact
> the whatwg.org folk as well, to check that any update would be
> effective.

Alternatively, if this is only needed to configure IPv6-only devices from
laptops (and other UI devices), encourage OS vendors to provide a user
selectable default zone for link local.

Alternatively, patch a http proxy to allow a user configurable zone for link
local and run that proxy locally.

---

From: [email-masked]
Date: Fri, 4 Mar 2016 13:58:17 +0100

> local and run that proxy locally.

if I'm required to type in a link-local address in a browser to configure something, then someone has done something very wrong.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 04 Mar 2016 14:30:42 +0100

>if I'm required to type in a link-local address in a browser to 
>configure something, then someone has done something very wrong.

If today you can avoid typing hardwired rfc1918 addresses in a browser, then 
you may be able avoid typing link local addresses in the future.

I do see a lot of rfc1918 addresses printed in manuals though.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Mar 2016 11:10:18 -0500

[email-masked] wrote:
    >> Alternatively, patch a http proxy to allow a user configurable zone
    >> for link local and run that proxy locally.

    > configure something, then someone has done something very wrong.

We are talking about something like: [fe80::1]:80

and I sure that mDNS will fail sometimes, and technicians will need to do
things (or have unqualified remote hands) do things like this to diagnose
what is going on...

If we can say that mDNS will always work, or if we can find a way to create a
have a default scope... great.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Mar 2016 11:52:14 -0500

Brian E Carpenter <[email-masked]> wrote:
    > We've always said that Zone IDs in URLs are *only* useful for
    > diagnostic purposes. Like Kerry, I fail to see what (m)DNS has to do
    > with this. The issue is narrow: getting browsers to do what RFC6874
    > says seems to be impractical, so let's change RFC6874 to something that
    > browser developers can actually implement.

+1 on fixing 6874: we clearly didn't get enough implementor feedback.

====

With a openwrt-BB or CC image booted in a VM, and my desktop attached to the
"LAN" side (but with my desktop configured to ignore RAs), I can do:
      % ssh -l root 'fe80::1011:ff:fe01:3%bb3lan'
and   % lynx 'http://[fe80::1011:ff:fe01:3%bb3lan]/'

but I can't do this with a graphical browser.  If I had a name would I
be any better off?  I can't actually put:
   fe80::1011:ff:fe01:3%bb3lan       wrt3

into /etc/hosts, it seems that doesn't work.  It ought to, I think though.

openwrt-CC does not seem to announce itself via mDNS that I can see.
It ought to.

If it did, so that I can write, http://wrt3.local/, would that make
the browser people happier?   Would it actually work, given that they
don't seem to be using getaddrinfo()...

Maybe we have something to add to RFC7204?

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 4 Mar 2016 12:30:05 -0500

On Fri, Mar 4, 2016 at 11:52 AM, Michael Richardson <[email-masked]>
wrote:

> Try `dig -p 5353 @224.0.0.251 _http._tcp.local PTR` and see if it
responds.
(I have a patch to make this work with IPv6 as well.  It takes a scope ID
;-)

> This is not the typical UI model for mDNS.  Usually the user is asked to
choose
an instance from a list (and that's how Apple implements it in Safari).

Typing in a name would only work if:
- the underlying resolver conforms to RFC 6272
- the host is not multihomed (otherwise you're back to specifying which port
  to use for discovery)
- the target device supports mDNS
- there isn't more than one instance of foo.local on the LL (here's where I
  differ from the official Stuart/Apple position; I think it's acceptable
to embed
  some unique substring, e.g. low order symbols of MAC ID, in the initial
name.
  Note that matching that to the device may be as problematic as scope ID.)

All things considered, this sounds like a steeper hill to climb than adding
scope ID (and I'm a fan of mDNS).

Kerry

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Mar 2016 15:13:48 -0500

Kerry Lynn <[email-masked]> wrote:
    > responds.  (I have a patch to make this work with IPv6 as well. It
    > takes a scope ID ;-)

It returned the first reply, which in my office, was a colleagues' desktop,
not the openwrt instance on a virtual bridge attached to my desktop.

    > choose an instance from a list (and that's how Apple implements it in
    > Safari).

Sure, but when you choose from the list, does that turn into a request to
that name, or does it jump right to the underlying address that was returned?

It seems like it ought to connect to the name so that a bookmark could work.

    > All things considered, this sounds like a steeper hill to climb than
    > adding scope ID (and I'm a fan of mDNS).

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 4 Mar 2016 16:04:49 -0500

On Fri, Mar 4, 2016 at 3:13 PM, Michael Richardson <[email-masked]>
wrote:

> Well dig is not very sophisticated.  It's doing a "one-shot query", which
displays
the first response it gets.  Safari does a long-lived query, which builds a
list of
responses.

> The response from the remote server will contain SRV, TXT, A and/or AAAA
records.  I don't know enough about the resolver API to know whether port
comes back as a parameter or is specified before the search.

>
> Again, not sure of the details of the resolver API.  .local names are not
globally unique, so to avoid name conflicts on different links I think you'd
have to save off the scope ID with the name.  Full circle.

Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Mar 2016 11:00:09 +1300

On 05/03/2016 01:58, [email-masked] wrote:
>>>  "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."
>>>

I agree with that, but it's orthogonal to making browsers handle
Zone IDs, so it's another thread, along with (m)DNS.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 5 Mar 2016 09:41:37 +1100

On 5 March 2016 at 03:10, Michael Richardson <[email-masked]> wrote:
> If we can say that mDNS will always work,

So we can never say that, because too much packet loss will cause mDNS
and any other application or protocol to fail, or fail to be useful,
as retransmissions take too long to overcome the packet loss.

At some point you've exceeded your link layer capacity. Selectively
discarding some packets will obviously penalise the applications or
protocols trying to use those discarded packets. You're going to have
to increase link capacity if that is unacceptable.

> or if we can find a way to create a

I think there was a draft a while ago which proposed that the default
link-local scope should be the same as the interface used to reach the
host's default gateway. That would be ok if the majority of hosts were
single homed, however as in many markets smartphones have become the
most popular Internet access device, in those markets the majority of
hosts are now multihomed.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 5 Mar 2016 10:06:27 +1100

> Zone IDs, so it's another thread, along with (m)DNS.

So I think browsers should support Zone IDs for troubleshooting.

However I think the mDNS discussion is related, because it is helping
to measure how significant the problem of a browser not supporting
Zone IDs really is.

I think the problem being solved is "to allow a non-technical end user
to easily connect their newly attached device, to perform initial
configuration and other similar tasks."

Typing in factory configured addresses or similar is a very un-user
friendly way of solving that problem. Selecting the automatically
discovered device from a list, on the other hand, is very user
friendly and should be achievable by pretty much any computer user
(which, for example, Google have done well with their Chromecast
devices.)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 5 Mar 2016 10:16:01 +1100

>     > adding scope ID (and I'm a fan of mDNS).

So Openwrt uses Avahi as the mDNS daemon, and Avahi doesn't announce
LLs, despite the mDNS RFC saying they should (and possibly MUST) be.
I've suspected it is because it hasn't been all that clear or well
known as to how to use LLs in applications.

Avahi's lack of use of LLs is actually one of my primary motivations
for this draft:

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

which I'm planning to get back to starting to update with the feedback
I've received this weekend.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 5 Mar 2016 10:39:50 +1100

On 4 March 2016 at 09:49, Kerry Lynn <[email-masked]> wrote:

<snip>

> Favorites.  It's a setting under Preferences->Advanced.

It's good that it it supported, however putting it there is a bit like
putting the windscreen wiper switch under the bonnet (hood) of the
car.

Regards,
Mark.

>> instructions, "Click the MDNS symbol, and select the device named XYZ", then
>> a HTTP/S request sent to the device. I think that would be a more or much
>> more user friendly experience that the IPv4 address or reserved locally
>> served DNS name method used today.
>>
>> Regards,
>> Mark.
>
> <snip>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Mar 2016 11:12:53 -0500

> known as to how to use LLs in applications.

Ah. CC doesn't come up with avahi running at all, I was assuming dnsmasq was
performing that function.

But, my question still remains:  if browsers won't parse the scopeID, how can
it matter...

    > https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Thanks for this.
I suggest adding some comments about stable privacy enhanced addresses, and
how they can be input for the IID in section 2, point 11. (maybe number those points)

What do you intend to do with this document?

---

From: Mark Smith <[email-masked]>
Date: Tue, 8 Mar 2016 06:48:20 +1100

Hi Michael,

> how they can be input for the IID in section 2, point 11. (maybe number those points)

Thanks for that suggestion, I'll look to include it.

> What do you intend to do with this document?

I think when it is complete it would be useful to publish as an
Informational RFC.

One recent thought I've had about IPv6 adoption is that one of the
things that may be slowing it down are the lack of applications that
are using it, which I think might mean that either application
developers are not aware of how to use it, or they don't see benefits
in having their applications use it.

When IPv4 and IPv6 provide or are perceived to provide equivalent
service to an application, then I wouldn't think an application
developer sees a lot of incentive to IPv6 enable the application.
Making developers aware of the unique capabilities and benefits of
IPv6 over IPv4 and how to use them could provide that incentive.

In the case of LLs, I've thought their guaranteed presence, their
independence from a router and their level of inherent security by
being limited to a single link are benefits that may be useful for
applications.

Regards,
Mark.

---

From: Doug Barton <[email-masked]>
Date: Mon, 7 Mar 2016 13:34:15 -0800

Responding to no one in particular ...

y'all have leaped into solution space without fully understanding the 
problem (hint, it's not about mDNS).

can I suggest that before proceeding further it might be useful to 
examine the mozilla bug report (URL posted up thread) to really 
understand what people are asking for and why?

Doug