Re: [IPv6] rfc6874bis (was: Re: [v6ops] IPv6 link-local and URLs @ IETF119)

[Brian E Carpenter <[e-mail]>]

On 20-Mar-24 11:29, Toerless Eckert wrote:
> On Wed, Mar 20, 2024 at 11:05:27AM +1300, Brian E Carpenter wrote:
>>> Ok. Did this happen ? No IESG member beside Murray had a discuss,
>>
>> Rob Wilton also holds a DISCUSS. Francesca Palombini supported Murray's DISCUSS.
> 
> I actually very much support Robs comments, but i think they are easy to address. Aka: I wish we would explain and allow
> both zone_name and zone_id, 

If you mean %1 if eth0 happens to be interface #1, that isn't contentious. It works today, but not in URIs. It's more that network devices use quite complex names with special characters, and may be case-sensitive, which is an absolute no-no in the host part of a URI.

> as used in routers in the field to make useful progress over
> rfc6874.
> 
> There is also the more fundamental naming issue unveiled by the discussion and Davids comment/writeup,
> that what we call zone_id/zone_name are not really what one expect to be that, because they are
> randomnly locally allocated instead of assumed to be consistent across the nodes participating in the
> zone. So we should add explanation, if not name improvements to highlight this limitation ("local_zone_name"/
> "local_zone_id" - or honeslty, even "interface_name", "interface_id")

That's well understood and isn't really an issue for the URI discussion.

Whether we should explode RFC 4007 and tackle this issue is a much bigger question with many implications.

    Brian

> 
>>> and it would be a sad state of
>>> affairs if now all of a sudden, the rest of the IESG would buy into his business argument.
>>
>> I'll leave Murray to respond, but the arguments from the W3C side are not really business related.
> 
> Please read David Schinazi's draft, especially https://www.ietf.org/archive/id/draft-schinazi-httpbis-link-local-uri-bcp-03.html#handling .
> 
> "If it's clear the browser community does not want (and maybe will not implement) this, what is our justification for proceeding?  In particular, that fact appears to me to eliminate half of the supporting use cases presented in Section 1."
> 
> I simply don't think we should constrain our specifications for IPv6 based on a snapshot
> of what likely amounts to two browser core implementations (maybe three). If we would have
> used the same logic at the start of IPv6 we would be nowhere. If/when the browser community
> comes back with a better proposal, fine, then we'll update the rfc again.
> 
> I also think the use-case list is incomplete. It does not list the use of URLs in any form
> of programming language, such as anything that uses URLs for API calls, such as restconf. Those
> applications may not need to apply the same origin concept (ability to only refer to URLs with same
> origin for example.
> 
> And also as mentioned in before: the origin concept is already broken for non-zones linklocal IPv4/IPv6
> addresses, and IPv4 link local addresses are happily used in probably billins of browser
> 
> (let me configure my router on 192.168.1.1 - oh wait, why the heck does this look like the web page
>   of my backup internet router web page on my second SSID... ;-)
> 
>> I agree that "we won't implement" in itself is not an argument the IETF should weight too heavily.
>>> Also the origin argument AFAIK does not apply to all use of URL for which rfc6874(bis) applies.
>>> And the origin problems also exist for other cases (e.g.: non-zoned IPv4/IPv6 link local addresses),
>>> and browsers also simply live with those problems.
>>
>> Sure, and the browser community is very concerned about this. Hence https://wicg.github.io/private-network-access/
> 
> Thanks... need to figure out if/what they imply in that text about avoe example dual SSID
> with same addresses case.
> 
> Cheers
>      Toerless
>>
>>     Brian
>>
>>>
>>> Cheers
>>>       Toerless
>>>
>>>>       Brian
>>>>
>>>>>
>>>>> Cheers
>>>>>        Toerless
>>>>>> Murray Kucherawy has offered to try to drop in for this discussion, if
>>>>>> he can step away from his working group when the topic comes up.
>>
>