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

[Ted Lemon <[e-mail]>]

For extra credit, the browser could do happy eyeballs across all the
interfaces...

On Tue, Mar 19, 2024 at 4:01 PM Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> FWIW I don't think it makes sense to put scoped addresses in URLs, because
> the scope portion cannot be known in advance.
>
> 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. I
> 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.
>
> 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.
>
> 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
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>