[IPv6] Link-local URI status (rfc6874bis)

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

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