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

[Brian E Carpenter <[e-mail]>]

On 07-Nov-23 06:53, Erik Nygren wrote:
> I'd propose that we decouple what is in the URI on the wire and what is in the user interface, similar to rfc5894 / IDNA.
> That way we stick with always using %25 as in rfc6874 on the wire and in any URI references (eg, in an href, etc)
> to keep things unambiguous and protocol-compliant.  For example:
> 
>      http://[fe80::a%25en1]
> 
> We can separately define that user interfaces may do a conversion to add/remove this escaping as appropriate.

Which user interfaces? If you mean the dialogue box in browsers, I am definitely no expert, but these days it seems that any deviation from accepted URI syntax sends you off into search mode.

> There's a precedent for this model already with the IDNA conversion between punycode and UTF-8 already.

Yes, but of course punycode looks like standard ASCII fodder for hostname parsing. So when I type https://smörgåsbord.blåbærsyltetøy.com into Firefox, it echos https://xn--smrgsbord-82a8p.xn--blbrsyltety-y8ao3x.com and that parses just fine.

> 
> This approach seems like it might be the best compromise:
> * It will keep the HTTP and URI people happy by not adding in some weird special-case which seems like a non-starter.

I'm not sure about that. That is of course the syntax of RFC6874, but from what I've gathered about the wide variety of URI parsers in the world, whether or not a % is treated as an escape at that particular point in a URI (inside the host part, inside square brackets, inside a numeric address) isn't necessarily consistent. Changing to a different symbol definitely avoids that inconsistency.

> * It is a minimum change to what is already specified (eg, rfc6874)
> * It doesn't change how we encode interface names in a way that would be exposed to users.
> * It still allows users to interact with interface aliases with an experience that hides them from this complexity.
> 
> There is still the ambiguous case (eg, interface  "251") but perhaps we can strongly discourage
> naming interfaces in such a way that they start with "25".  Messy, but might be the least bad option.

It isn't ambiguous if we make the %25 mandatory, but this is precisely the grey area where some parsers will get it wrong. And unfortunately %2525 is very likely to occur - the Windows machine on which I am typing has interface index 22 for Wi-Fi, for example.

But the other point is that this only resolves one of the three blocking issues.

    Brian

> 
>    Erik
> 
> 
> 
>       Erik
> 
> 
> 
> 
> 
> On Wed, Nov 1, 2023 at 3:03 AM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi 6man,
> 
>     Since I will not be in Prague or on-line, this is an update for the WG
>     on the status of draft-ietf-6man-rfc6874bis.
> 
>     If you've forgotten, the draft allows http://[fe80::1%eth0] as a valid URI.
> 
>     In summary: it is blocked in the IESG. Possible WG actions are listed
>     at the end.
> 
>     There are two unresolved DISCUSS ballots:
>     https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/#draft-ietf-6man-rfc6874bis_robert-wilton <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/#draft-ietf-6man-rfc6874bis_robert-wilton>
>     https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/#draft-ietf-6man-rfc6874bis_murray-kucherawy <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/#draft-ietf-6man-rfc6874bis_murray-kucherawy>
> 
>     Here is my personal summary of the remaining issues, and what we
>     have done since IETF Last Call and IESG review to resolve them:
> 
>     1. Re Rob Wilton's DISCUSS: We clarified character set restrictions needed
>     for compatibility with URI rules, and the applicability of numeric identifiers
>     as a work-around for these character set restrictions. I believe these are
>     the only changes possible, given RFC4007, the ~20 years of history in the
>     POSIX and Winsock APIs, and the widespread implemention of these in host
>     stacks.
> 
>     The difficulties that Rob has are not so much with this draft but more
>     with that underlying model. Quoting his off-list message: "I don’t regard
>     interfaces on network devices as inherently having a numeric identifier."
>     But like it or not, the nodes on which browsers normally run follow
>     RFC4007 and *do* inherently have numeric interface indices. We don't
>     have any choices there. (I do think that RFC4007 is inadequate and
>     needs to be updated to reflect current reality, but that's orthogonal.)
> 
>     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.
> 
>     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/ <https://wicg.github.io/private-network-access/>.
> 
>     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.
> 
>     The draft has been updated several times in an attempt to
>     resolve these two DISCUSSes, and a couple of side meetings have
>     been held at recent IETFs. We tried to set up a video chat
>     before IETF 118 but it didn't work out.
> 
>     Possible WG actions:
> 
>     1. Drop the draft and leave the use cases unsolved.
> 
>     2. Accept the change to http://[fe80::1-eth0] and push the
>     IESG to dismiss the other objections as beside the point.
> 
>     2a. Also undertake a major revision of RFC4007.
> 
>     3. Something else.
> 
>     I'd be interested to hear opinions about these options.
> 
>     Regards
>          Brian Carpenter
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>