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

["Eric Vyncke (evyncke)" <[e-mail]>]

Reacting to:

> Thanks for reminding us of that draft. I'm agnostic about "+" versus "-" for this.
> I've never really seen a reason for using the "IPvFuture" syntax in RFC 3986.
> If we decide to replace the "%", that seems to be enough to resolve the parsing problem.

With a big potential caveat that some interfaces may have a ‘-‘ in their names ?

-éric (obviously no hat)

From: ipv6 <[e-mail]> on behalf of Brian E Carpenter <[e-mail]>
Date: Thursday, 2 November 2023 at 20:41
To: Michael Sweet <[e-mail]>
Cc: 6man <[e-mail]>, Bob Hinden <[e-mail]>, Stuart Cheshire <[e-mail]>, Rob Wilton (rwilton) <[e-mail]>, Murray S. Kucherawy <[e-mail]>
Subject: Re: [IPv6] Link-local URI status (rfc6874bis)
Michael,
On 02-Nov-23 16:04, Michael Sweet wrote:
> 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

Thanks for reminding us of that draft. I'm agnostic about "+" versus "-" for this. I've never really seen a reason for using the "IPvFuture" syntax in RFC 3986. If we decide to replace the "%", that seems to be enough to resolve the parsing problem.

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

Yes. (But on a system such as Windows that implements a default Zone ID, you *can* use a link local address in any browser.)

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

Right, but also fe80::1 and fe80::1 might be two different addresses, if they arrived via two different interfaces. Link-local is a bit special in that way.

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

Yes.

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

Ack.

>
>> 2a. Also undertake a major revision of RFC4007.
>
> Barn | Door | -------------------> Horse

Yes, there is a lot of running code, but there are also some serious gaps in that RFC, and quite a bit of historical material. However, that's a problem for another day.

Regards
    Brian Carpenter

>
> ________________________
> Michael Sweet
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------