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

[Erik Nygren <[e-mail]>]

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.
There's a precedent for this model already with the IDNA conversion between
punycode and UTF-8 already.

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

  Erik



     Erik





On Wed, Nov 1, 2023 at 3:03 AM Brian E Carpenter <
[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_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/.
>
> 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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>