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

No, that doesn't matter, it's fine if the name contains the separator. Only
the first one counts. An escape character is much harder to deal with.

(via tiny screen & keyboard)
Regards,
        Brian Carpenter

On Fri, 3 Nov 2023, 19:22 Eric Vyncke (evyncke), <evyncke=
40cisco.com@dmarc.ietf.org> wrote:

> 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 <ipv6-bounces@ietf.org> on behalf of Brian E Carpenter <
> brian.e.carpenter@gmail.com>
> *Date: *Thursday, 2 November 2023 at 20:41
> *To: *Michael Sweet <msweet@msweet.org>
> *Cc: *6man <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Stuart
> Cheshire <cheshire@apple.com>, Rob Wilton (rwilton) <rwilton@cisco.com>,
> Murray S. Kucherawy <superuser@gmail.com>
> *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 <
> brian.e.carpenter@gmail.com> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>