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

[Toerless Eckert <[e-mail]>]

Inline.

On Wed, Mar 20, 2024 at 07:53:56AM +1300, Brian E Carpenter wrote:
> >     RFC4007 says that an implementation MAY have a default interface for link locals when the user doesn't supply one via fe80::1%name. Linux doesn't do that. Since link-locals aren't routeable, you just get 'invalid argument' from sendmsg()  if you don't supply a valid interface number.
> > 
> > 
> > It's pretty trivial for a browser to do this though: whenever it converts a link-local address from a URL to its internal data structures, determine the system default network and use that to populate the scope ID.
> 
> Except that
> (a) No browser does that (it works on Windows because the network stack does it).
> (b) afaik there is no such thing as a system default interface on Linux, there's only routing which doesn't apply here.

It would be a fairly useful pragmatic solution for a subset of use-cases for
the browser (or some library used by it), to determine the IPv6 default route's zone_name
and then supply this to the socket API when connecting to a link-local IPv6 address.

> (c) the use cases we list want a specific interface not a default

Yes, and i am happy to repeat that i think it is very inappropriate for Murray to reject the
document based on what likely is the unwillingness of two browser implementers to implement it,
given the as i mentioned in a prior, uncommented email in this thread, much broader candidate target
of possible software that might use URLs also for more specialized use-cases.

There is the much bigger issue, that the zone_id/zone_name distinguisher is rejected on the bounds
of conflicting with the browser (not URL!) origin concept, but given how the concept of zone_id/name
are intrinsic properties of the IPv6 network layer, i firmly believe that it is the responsiblity
of browsers to at least archtiecturally own how to solve supporting it, if they want to reject the
rfc6874(bis) solution for their environments.

The reason why this is all such a surreal discussion is because the origin concept does already not work
correctly for any link-local IPv6 AND IPv4 addresses (192.168.x.y/16) even absent the use of
zone_id/name, for example when changing WiFi SIDs, and/or any other similar case. Its just that that
case too is likely "too insignificant" to justify fixing up terribly complex browsers. Which is fine.
It's just not fine to make IETF standards track 6MAN rejections based on such convoluted business
problems of maybe as few as 2 application implementations.

But it would certainly extremely helpful for the browser community to try to figure out how theoretically
link-local addresses would have to be supported if not how rfc6874(bis) wants it. If and when three is
a better proposal, then it makes sense to add specific requirements to exclude browsers from rfc6874
and point to such other option(s). Which also does not mean that such another option would have to be
immediately implemented on browsers if there is not enough business case for those browsers, if the
minimum needed users for any feature exceeds e.g.: 10 million users.

Cheers
    Toerless