Re: [IPv6] Link-local URI status (rfc6874bis)

[Michael Sweet <[e-mail]>]

Brian,

Comments inline...

> On Oct 31, 2023, at 10:02 PM, Brian E Carpenter <[e-mail]> wrote:
> ...
> 2. Re Murray Kucherawy's DISCUSS:
> 
> 2.1 The fact that almost no developers have decided to implement
> this so far seems non-blocking to me. For all the use cases listed in
> the draft, there is a user-side view that this just ought to work,
> and when it fails, this is perceived as a bug.
> 
> Arguments that it's 'unimplementable' or 'insecure' deserve answers:
> 
> 2.2 The 'unimplementable' argument is based on using the '%' sign
> as a separator, whereas its normal role in a URI is as an escape
> character. Roy Fielding has argued that there are many URI parsers
> around that handle percent-encoding in different ways (somewhat
> regardless of the formal ABNF syntax). As result, he asserts
> that stepwise introduction of the draft is impossible in practice.
> 
> The draft argues that it doesn't matter if unmodified parsers
> throw an error if they see the new syntax, because that is what
> they do today anyway, so the new syntax can be deployed
> progressively.
> 
> There is an alternative (discussed in this WG years ago):
> use a different separator, e.g. http://[fe80::1-eth0]
> This still requires URI parsers to be modified and progressively
> deployed, but without interacting with percent-encoding.
> That is mainly a simplification of the programming problem. It
> does have its own programming complication - the '-' must be
> replaced by '%' before making relevant socket calls.

WRT this, CUPS first added support for the Fenner draft in January 2006:

    https://datatracker.ietf.org/doc/html/draft-fenner-literal-zone-02

This format (scheme://[v1.fe80::0123:4567:89ab:cdef+eth0]/resource) requires rewriting ("+" to "%") and hasn't been an issue for implementation in the billions of IPP printers and client devices that use it...

One advantage of using "-" instead of "%" is that it is both unambiguous (there is no other meaning for a "-" between the address and zone ID portions) and allows existing RFC 6874 implementations (like CUPS) to continue working unchanged and support the new "-" delimiter as well.

Regardless, today you basically can't use IPv6 link local addresses in browsers at all.  Claiming that you can't add a new format because it wouldn't work everywhere immediately makes no sense - better stop developing new protocols and standards then...

> 2.3 The 'security' argument is related to what the Web community
> calls Cross-Origin Resource Sharing (CORS). This is a very
> complex topic that I do not claim to understand and will not
> attempt to summarise here. IPv4 and IPv6 link-local address
> literals are considered problematic, like other IP addresses
> with local (a.k.a. private) scope, such as ULAs. The background
> is at https://wicg.github.io/private-network-access/.

OK, so this is a little different from the normal CORS issues...  

> What I do not understand about this argument is that the CORS
> issue exists for http://[fe80::1] already, and as far as
> I can see is identical for http://[fe80::1%eth0]. If so,
> that is no reason to block rfc6874bis.

Agreed.  I suspect that, for any numeric address, the answer for CORS is simply to compare any two address fields and if they match, it is the same origin, otherwise it is not.  If you have a FQDN, then any numeric address does not match.

The zone ID can be part of this address string comparison because CORS applies to "security" restrictions the client browser is applying...
> ...
> 1. Drop the draft and leave the use cases unsolved.

That's what was done back in 2005 and the problem hasn't gone away...

> 2. Accept the change to http://[fe80::1-eth0] and push the
> IESG to dismiss the other objections as beside the point.

See above.  I've always been uncomfortable with a bare "%" given that it has a special meaning in URLs, can be misinterpreted with numeric zone IDs, and isn't backwards-compatible with RFC 6874.  If using "-" is enough to get this draft advanced, I'd go for it.

> 2a. Also undertake a major revision of RFC4007.

Barn | Door | -------------------> Horse

________________________
Michael Sweet