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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Brian,

Cc’ing Mahesh since he will have to decide whether to inherit my Discuss.

Please also see comments inline …

From: Brian E Carpenter <[e-mail]>
Date: Wednesday, 20 March 2024 at 10:23
To: Toerless Eckert <[e-mail]>
Cc: [e-mail] <[e-mail]>, Erik Kline <[e-mail]>, Lorenzo Colitti <[e-mail]>, George Michaelson <[e-mail]>, Murray S. Kucherawy <[e-mail]>, Rob Wilton (rwilton) <[e-mail]>
Subject: Re: rfc6874bis (was: Re: [v6ops] IPv6 link-local and URLs @ IETF119)
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.

I think that this may be a better path … I.e., by trying to avoid opening up RFC 4007, I wonder if we will just remain stuck in the mud.

I still think that if you want to use an interface identifier to identify a link-local zone that the solution support arbitrary case sensitive strings.  I also believe that in YANG models that if such zones need to be specified then it should be a separate interface name leaf rather than trying to combine that into the IP address definition.

Not an IPv6 expert so perhaps missing something basic … but, more fundamentally, I think that we should investigate to see if a solution is available where no separate zone identifier string is required at all, and instead the zone scoped information is embedded directly into the allocated IP address.  E.g., allocate an extra device-local v6 address (beyond the existing interface link-local address) where each interface on the device is on a different network, and thus the local IP address uniquely identifies the interface on the device without needing any separate zone identifier string.  I appreciate that would be a lot more work to specify (e.g., protocol changes to allocate them, etc, and so not a quick fix).  And perhaps I’m missing something obvious as to why this wouldn’t work and end up being a cleaner solution by allowing interface zone identifiers to be removed altogether.

E.g., I think that the address could look something like:
<some fixed prefix> - <a unique allocated network, negotiated/agreed with connected peers> - <a unique host address on that network, negotiated/agreed with connected peers>.

Unless I’m mistaken, currently link-local addresses only have the 1st and 3rd part and hence a zone identifier is required for the second part when being used outside the scope of the interface, and that, at least to me, seems to be the source of the problems.

Regards,
Rob



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