Re: [v6ops] IPv6 link-local and URLs @ IETF119

[Toerless Eckert <[e-mail]>]

On Tue, Mar 19, 2024 at 04:00:39PM +1000, Lorenzo Colitti wrote:
> FWIW I don't think it makes sense to put scoped addresses in URLs, because
> the scope portion cannot be known in advance.

Consider you're programming an application which uses some form of restconf or similar
API using URI talking via IPv6 link-local address neibhbors. SUch an app would need
to know which interface the neighbor is on, when using a link-local address, and
thats the zone-id or zone-name that would need to be in the URL of the API.

I think this would be the mayority use case for such URLs.

> So it basically requires that the user who types in the URL to somehow
> figure out what interface needs to be used and what its scope ID is. The
> set of users that is capable of doing this is vanishingly small.

Thats exactly what i said: No user should ever have to do it, but i do know that
i have had to do it repeatedly in ipv6 network management. Alas, even when just
trying to get to ipv6 link-local only address on a wifi/ethernet notebook it too
is an important diagnostics option.

See: I don't think this is a case where we must prove some size of business case
volume. Nobody is forced to implement it. It is fine to have a standard, and
let the industry figure out how to serve minority users such as IPv6 network
operators. 

Of course, if we do find better solutions that would be a good reason to not
pursue such technology, and for normal users, mDNS should be able to get a long
way (not all the way right now). But not IMHO for what programming with URLs needs
and/or v6 network operators.


> certainly don't - while I use linux which uses the interface name, I never
> remember that my wlan interface is called wlp0s20f3. My ethernet interface
> name is even worse, it's enxx<mac address>. I also don't necessarily know
> whether the device is on wifi or ethernet.

Sure. We need to figure out how to fixup multi-homed local mDNS to avoid you having to
do this. I hope we can get that done through Davids drafts or followups to that.

> There's a simple solution to this problem: if the user types in a
> link-local address the browser should *open the connection on the default
> network interface*, just like what it would do with any other connection.
> This will address the common "I need to configure my home router" use case.
> It wouldn't address the "I need to configure a home router on this other
> interface that isn't the default interface", but I think that is super rare.

See above. for actual well worked out user-use-cases i hope we find a working way for
mDNS requesting on multiple interfaces and then implying the interface. Aka: no
IPv6 addresses needed. But for those API and v6 operator cases, unless we find
a way to represent the actual same information - link-local address plus zone-id/name
better in a URL tthan right now, we should just leave it be, even at the risk of
slow/bad adoption in browsers.

Cheers
    Toerless

> 
> On Tue, Mar 19, 2024 at 11:21 AM Brian E Carpenter <
> [e-mail]> wrote:
> 
> > Murray, Erik,
> >
> > Please read both draft-schinazi-httpbis-link-local-uri-bcp and
> > draft-carpenter-6man-zone-ui carefully. Or look at some relevant slides,
> > especially slide 5 in the first talk:
> >
> > 6man:
> > https://datatracker.ietf.org/meeting/119/materials/slides-119-6man-entering-ipv6-zone-identifiers-into-user-interfaces
> >
> > iepg:
> > https://datatracker.ietf.org/meeting/119/materials/slides-119-iepg-sessa-make-firefox-visit-an-ipv6-link-local-address
> >
> > (which is proof of concept for both drafts)
> >
> > Regards
> >     Brian Carpenter
> >
> > On 19-Mar-24 13:39, Murray S. Kucherawy wrote:
> > > Looping in Erik, the AD for the older of the two documents we're talking
> > about here.
> > >
> > > On Tue, Mar 19, 2024 at 10:38 AM Murray S. Kucherawy <
> > [e-mail] <mailto:[e-mail]>> wrote:
> > >
> > >     I may not be able to attend that session (HTTPBIS on Friday,
> > according to its agenda) due to other conflicts.  I'll try to get free.
> > However, there are very likely to be people in that room able to represent
> > the concern that was raised to me, such as in the ARTART review, which
> > motivated my DISCUSS position.  I will reach out to them.
> > >
> > >     -MSK
> > >
> > >     On Tue, Mar 19, 2024 at 9:27 AM Toerless Eckert <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > >
> > >         Dear v6ops
> > >
> > >         You may want to think going to http(bis) WG this week for the
> > slot on
> > >         draft-schinazi-httpbis-link-local-uri-bcp. In it, he argues that
> > rfc6874 should be
> > >         retired/made-historic, because it was never implemented in
> > browsers.
> > >
> > >         For those who've been absent to the discussion:
> > >            rfc6874 says URLs can represent IPv6 link-local addresses as
> > [<ipv6addr>:<zone-name>]
> > >              and David Drafts lays out why this is difficult for browsers
> > >            rfc6874bis was held up (indefinitely) by Murray (ART AD) on
> > the prmise that the
> > >              browser vendors decided to not implement it rfc6874 nor bis.
> > >            draft-carpenter-6man-zone-ui from Brian Carpenter was
> > receiving various criticisms in 6MAN,
> > >              leading to David to write his draft. Where he primarily
> > promotes to use .local mDNS
> > >              instead of IPv6 link local addresses
> > >
> > >         My take on this:
> > >
> > >         1. The only poor souls who should ever have to use IPv6
> > link-local addresses in a browser
> > >             field are IPv6 Network Opertors (aka: here, this group),
> > when interacting in a browser
> > >             with a router (e.g.:web interface off a browser) and
> > entering URLs. Everybody else
> > >             should use names (including .local), so it is certainly a
> > minority use-case, but
> > >             i would hope an important minority use-case. Without network
> > admins being able to
> > >             troubleshoot even if/where DNS is not working, we can not
> > provide running IPv6 networks.
> > >
> > >         2. I find Murray's DISCUSS on rfc6874bis not convincing, because
> > scoped IPv6 link-local
> > >             addresses in URLs are not only needed for browsers, but for
> > any type of API in programming
> > >             languages that use URI, such as restconf or the like.
> > Besides, i do not see why we as
> > >             the IETF should constrict what we deem to be necessary by
> > the implementation problems
> > >             of effectively very few browser cores in the industry,
> > neglecting the broader use
> > >             of URLs. The argument alone that the IETF should not be able
> > to demand what's needed
> > >             for an IPv6 network archtiecture because some application
> > land work is hard is just
> > >             what has continued to slow down adoption of anything IPv6
> > for now 2 decades.
> > >
> > >         3. That being said, i would love to see Davids draft progress to
> > help eliminate the
> > >             non-working of .local addresses in Browsers today (aka:
> > create standadrd/demand for
> > >             mDNS in browsers to work), because they actually do have a
> > good
> > >             amount of actual really cool IoT use-cases (not v6ops). I
> > just don't want the work to call
> > >             for retiring rfc6874. I just want it for rfc6874 to become
> > only necessary where no other
> > >             option helps.
> > >
> > >         Cheers
> > >              Toerless
> > >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >

-- 
---
[e-mail]