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

[Toerless Eckert <[e-mail]>]

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, 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")

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

-- 
---
[e-mail]