Subject: Next steps for rfc6874bis

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 10:17:04 +1200

Hi,

As far as I can see we have one major issue, which needs to be
taken to the browser community for discussion, and one recurrent
issue that we probably need to resolve first.

Recurrent issue:
================

During the original discussion in 2012, and again recently, it
was suggested to change the delimiter from "%" to something else.
(The discussion in 2012 suggested "-", e.g. http://[fe80::abcd-en1].)
This was rejected in 2012 because it "Requires all IPv6 address
literal parsers and generators to be updated in order to allow
simple cut and paste; inconsistent with existing tools and practice."

Do we want to revisit this?

Major issue:
============

Should it be fe00::abcd%25eth0 or fe80::%eth0 ?

That is to say, should be formal ABNF be

   IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
   ZoneID = 1*( unreserved / pct-encoded )
   IPv6addrz = IPv6address "%25" ZoneID

or

   IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
   ZoneID = 1*( unreserved )
   IPv6addrz = IPv6address "%" ZoneID

(Ack to Andrew Cady for the second version.)

IMHO the answer on that issue must come from the browser community.
Operationally, the second form is more convenient, but if browsers
will never support it, it would be pointless to specify it.

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 18:37:15 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Recurrent issue: ================

    > During the original discussion in 2012, and again recently, it was
    > suggested to change the delimiter from "%" to something else.  (The
    > discussion in 2012 suggested "-", e.g. http://[fe80::abcd-en1].)  This
    > was rejected in 2012 because it "Requires all IPv6 address literal
    > parsers and generators to be updated in order to allow simple cut and
    > paste; inconsistent with existing tools and practice."

    > Do we want to revisit this?

If it means that we can get the browser people onboard, then I'm open to
doing this.

Looking at my keyboard and thinking about shells and globs,
I see other possibilities as: "=", "+", ";", ",". Maybe "!"
But, I don't think we have to pick one until we have the bigger discussion.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 2 Aug 2021 23:05:59 +0100

> Do we want to revisit this?

Definitely, but can we deal with more tractable issues first, e.g. 
global warming, slaac vs dhcpv6, world peace, etc?

> Major issue:

 From the worm's-eye view, I'd prefer "%" instead of "%25". As you point 
out, we need input from the browser wonks this one, as it's largely 
their turf.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Aug 2021 16:11:13 +1200

> global warming, slaac vs dhcpv6, world peace, etc?

Since nobody has argued against Nick, can we put this issue to one
side (as we did 9 years ago)? If we do that, we can have a fairly
straightforward discussion with the URI and browser community,
focusing entirely on % vs %25.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Aug 2021 10:28:32 -0400

Brian E Carpenter <[email-masked]> wrote:
    >>> discussion in 2012 suggested "-", e.g. http://[fe80::abcd-en1].)
    >>> literal parsers and generators to be updated in order to allow simple
    >>> cut and paste; inconsistent with existing tools and practice."
    >>>

    bc> Since nobody has argued against Nick, can we put this issue to one
    bc> side (as we did 9 years ago)? If we do that, we can have a fairly
    bc> straightforward discussion with the URI and browser community,
    bc> focusing entirely on % vs %25.

I disagree.
I think that changing the delimiter should be on the table in the discussion.
If the browser community doesn't like it, then fine, but let's let the group
make the decision.

My argument is:

1) in order to maintain cut&paste, if we do %25, then we have to change
   everything anyway.

2) people using command-line tools probably can cope with swapping around
   stuff in the short-term.

3) On GNU-Linux glibc systems, it's probably an update to getaddrinfo() only.
   A new character is probably easier to put in than %25.
   That could happen really quickly.  Of course, it doesn't have to stop
   understanding %.
   Ditto BSD systems.  Few utilities parse that stuff themselves.

4) If we'd started in 2012, we'd already be done.  We don't have
   interoperability now anyway.

[I abhor %25, btw]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Aug 2021 14:19:58 +1200

Hi Michael,
> If the browser community doesn't like it, then fine, but let's let the group

OK, but maybe we should update the draft to state that clearly as an
open issue.

> 1) in order to maintain cut&paste, if we do %25, then we have to change

I agree; it would be wonderful if the browser implementors could deal
with a non-encoded % but that is unclear right now.
 
> 2) people using command-line tools probably can cope with swapping around

Certainly it's better than no way of using a browser at all.

>    A new character is probably easier to put in than %25.

Much easier. I would never envisage supporting percent-encoding in
the socket API.

>    That could happen really quickly.

I'm not convinced. Across all o/s and all libraries? Quickly?

> Of course, it doesn't have to stop
>    understanding %.

I agree, although in my GRASP code, I needed to parse it on Windows
until a fairly recent Python change. And in Posix systems, it has
to be done too. GRASP is very dependent on getting link-local
stuff right.

---

From: David Farmer <[email-masked]>
Date: Wed, 11 Aug 2021 23:03:29 -0500

I’m probably about as enthusiastic as Nick is for actually changing the
delimiter. However, I think it is premature to take any valid solution off
the table until we have had a conversation with the browser people. If
there was an easy answer to this, it would have been solved by now.

At this point, taking any valid option off the table is more likely to lead
to another failed attempt, than lead to a successfully outcome. And,
however much I dislike it, changing the delimiter is a valid option. In my
opinion the only thing worse that changing the delimiter, is another failed
attempt to fix this.

We need to get it right this time, whatever the solution is, so be it.

Thanks.

On Wed, Aug 11, 2021 at 21:20 Brian E Carpenter <[email-masked]>
wrote:

> was
> simple
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Aug 2021 11:30:55 +0100

> OK, but maybe we should update the draft to state that clearly as an

well, is there a reasonable chance that this can be dealt with in 
future?  If not, then the most realistic option is to mark it as CANTFIX 
and move on.  Maybe in this case, the draft could note that there's an 
issue but no real hope of resolution?

Nick

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Aug 2021 10:16:01 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> 1) in order to maintain cut&paste, if we do %25, then we have to
    >> change everything anyway.

    > with a non-encoded % but that is unclear right now.

I mean that command-line tools will need to support %25.

    >> 3) On GNU-Linux glibc systems, it's probably an update to
    >> getaddrinfo()
    > only.

    > Much easier. I would never envisage supporting percent-encoding in the
    > socket API.

I would. If the goal is to have a consistent thing we can copy and paste,
then we should support that.

    > I'm not convinced. Across all o/s and all libraries? Quickly?

In less than the 2021-2011 = 10 years, we've just spent? sure.

Would OSes with LTS releases do it within their LTS release? Maybe.
If not, we are looking at 4-5 years for it to become ubiquitous.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 12 Aug 2021 13:24:03 -0400

If I could add my $0.02 (even though I'm not current on all the
discussions and details):
- I believe http://[fe80::%eth0] _used to work_ in Mozilla browsers;
  we're talking maybe early 2000s. The earliest version I can find online
  is c. 2015. Pretty sure I might have old VMs that can demonstrate
  the functionality. (Let's assume there's an existence proof for parsing
  a naked '%' between square brackets.)
- If this has to be approved by the browser community as a condition
  of it becoming widely available, do we know if they will support link
  local addresses in principle? (If not, then the utility of this for e.g.
  consumer router setup is moot.)
- If the browser community can support this in principal, then we can
  discuss EBNF. I strongly favor the syntax above, but any single char
  is better than "%25". Certain OSes (not naming any names) use
  numeric ZoneIDs and I think the cognitive dissonance of "%25<nn>"
  is problematic.
- If the browser community cannot support this, then we could perhaps
  develop a patch for cURL to make it available at least for the engineering
  community (I haven't checked cURL to see if it's already supported).

Cheers, Kerry

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Aug 2021 14:12:31 -0400

Kerry Lynn <kerlyn=[email-masked]> wrote:
    > discussions and details): - I believe http://[fe80::%eth0] _used to
    > work_ in Mozilla browsers; we're talking maybe early 2000s. The

I concur. It did work.
In the days when it was just a location bar, and not a search bar.
I'm told that it's the combinatorics that is part of the challenge.

    > cognitive dissonance of "%25<nn>" is problematic.  - If the browser
    > community cannot support this, then we could perhaps develop a patch
    > for cURL to make it available at least for the engineering community (I
    > haven't checked cURL to see if it's already supported).

The current syntax works in curl.
I think it also works in the midori browser.

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Aug 2021 05:21:05 +1000

> discussions and details):

As I'm not either, however another 2c.

Non-technical end users shouldn't be exposed or have to even enter
IPv6 addresses, including link-locals. While convenient to be able to
enter them into a URL field in a browser, it shouldn't be a common
thing to do.

For user friendly end user access to device web GUIs over link-local
addresses, the devices announcing themselves via MDNS would be better.
I have a laser printer that already uses MDNS to announce its IPv6
address.

Web browsers could provide a user-friendly selection list showing
devices discovered via MDNS. An extension for Firefox that looks to do
this already exists -
https://addons.mozilla.org/en-US/firefox/addon/mdns-discover/

For technical users who need to enter link-local addresses and
interface/zone IDs, having a technical dialog box, with separate IPv6
address and interface/zone ID fields, hidden away under more technical
menu options (like Firefox's "More Tools" menu) should be adequate to
resolve this thread's issue by avoiding it.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Aug 2021 15:34:53 -0400

Mark Smith <[email-masked]> wrote:
    > Non-technical end users shouldn't be exposed or have to even enter IPv6
    > addresses, including link-locals. While convenient to be able to enter
    > them into a URL field in a browser, it shouldn't be a common thing to
    > do.

USers also want a pony.

    > I have a laser printer that already uses MDNS to announce its IPv6

When that doesn't work, and a technical support person arrives to debug the
situation,  they are going to put an IPv6 LL in in order to determine what's
up.

    > resolve this thread's issue by avoiding it.

I agree: It doesn't even have to be the Location bar.
They could be some special box that is opened up, that can't do search.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 12 Aug 2021 16:41:56 -0400

> I'm told that it's the combinatorics that is part of the challenge.

That sounds like the sort of point you'd raise iff you really didn't want to
support ZoneIDs, period. I think we can all agree that any string that
begins with "http://[<stuff>]" is definitely a location. Hence, we should
maybe do some probing to find out what the real objection(s) may be.

> I have a laser printer that already uses MDNS to announce its IPv6

You are preaching to the choir, but even Apple has ripped Bonjour
support out of Safari. And then there's the IoT crowd who might argue
that mDNS is too costly to implement (but Apple is working to fix that).

I think, at the end of the day, we're looking for the path of least
resistance to a solution that is as useful and ubiquitous as today's
"http://192.168.1.1".

Cheers, Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2021 09:25:48 +1200

Kerry,

>   local addresses in principle?

That is exactly what we need to check, but not on this list because they
aren't here. We (the co-authors) will take this on.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2021 09:27:47 +1200

> enter them into a URL field in a browser, it shouldn't be a common

Of course. The use cases are not ones that ordinary users should need.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2021 09:30:50 +1200

> They could be some special box that is opened up, that can't do search.

That seems like a red herring to me, as far as the current draft is
concerned. (But then, I use a frozen-in-time Firefox version with all
search options switched off.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2021 09:33:36 +1200

> then we should support that.

Hmm. But anyway, this is all handwaving until we have a sensible dialogue
with the browser people.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2021 09:34:51 +1200

> issue but no real hope of resolution?

We don't know yet. We'll start the discussion with browserland.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Aug 2021 15:25:23 +0200

>I think that changing the delimiter should be on the table in the

I agree. In my opinion, using the '%' sign as the delimiter is a serious
mistake due to the incompatibility with the URL syntax. 

Yes, it will take a while before most software will accept a new character.
That's why we need to start now. 

Obviously, URL parsers should accept both %25 and the new delimiter. We
should not introduce special '%' hacks in the URL syntax.

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 16 Aug 2021 15:47:03 +0200

> That's why we need to start now. 

10 years? 20 years? This address format is out in the wild for years
now. Lets look at an example: changing the IP address formats defined
in RFC 6991 (published 2013, updating RFC 6021 published 2010) would
likely be a non-backwards compatible change and thus all YANG modules
importing from RFC 6991 may need updates and then these updates need
to be implemented and finally shipped and deployed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Aug 2021 16:02:51 +0200

>to be implemented and finally shipped and deployed.

I assume we start with an RFC that says that IPv6 address parsers SHOULD
accept '-' in addition to '%'.

I don't see how that would invalidate YANG modules.

Next step, in some years, to to change the canonical IPv6 address
representation to use '-'.

Obviously, that would trigger the need to update YANG modules, but old ones
will continue to work.

At some point we can make '%' to be something the MAY be supported. But I
assume that will only happen after we have mostly switched to the new
character.

Is this annoying maintainance work, yes. But being stuck forever with the
wrong character is also not something the wider internet community is going
to appreciate.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Aug 2021 17:13:10 +0100

> assume that will only happen after we have mostly switched to the new

Given the IETF's general reluctance to deprecate standards, the most 
likely outcome of this suggestion would be that both "%" and "-" would 
need to be supported indefinitely.  This would be a regression.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Aug 2021 18:21:30 +0200

>need to be supported indefinitely.  This would be a regression.

I disagree. Yes, mistakes result in cruft. But that is not a good reason
to continue with the mistake.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 16 Aug 2021 09:37:40 -0700

All good comments, but as Brian noted earlier, the only thing that really matters here is what the web browsers implementors/vendors are willing to do.   Producing a document that they ignore isn’t useful.

Bob

> On Aug 16, 2021, at 9:21 AM, Philip Homburg <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2021 08:46:03 +1200

> to continue with the mistake.

It isn't even obvious that this was a mistake. If you accept Andrew
Cady's argument, it was not a mistake at all. (The mistake was in
assuming that percent-encoding of "%" is required, by Andrew's
argument.) As Bob says, we need to hear from the browser people.
The next version of the draft will set this out as an open issue.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Aug 2021 11:29:17 +0200

>The next version of the draft will set this out as an open issue.

I'm quite curious how something like 
https://[fe80::1%eth0]/
conforms to RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax)
which says in Section 2.4:
"Because the percent ("%") character serves as the indicator for
"percent-encoded octets, it must be percent-encoded as "%25" for that
"octet to be used as data within a URI.

In any case, the important part is that when we talk to the web community
we offer a different character, such as '-', as an option. Instead of just
focussing on the '%' or '%25' issue.

In my opinion making https://[fe80::1%25]/ a valid URL that refers to the
25th interface is going to lead to a huge number of parsing errors.

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 17 Aug 2021 21:36:23 +1200

Philip,
Andrew offered ABNF to back up his assertion, I can't point to it from my
phone but you'll find it upthread somewhere. Whether real world parsers can
respect it is a question for the parser authors.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Aug 2021 12:30:54 +0200

>respect it is a question for the parser authors.

If I got it correct he is basically saying that RFC 3986 is wrong. 
>From https://mailarchive.ietf.org/arch/msg/ipv6/ocNXw2Tl7YnOXOVjnUJ_VS7PI88/
"That is a bug.  The '%' must be treated as the syntactic delimiter it is.

If RFC 3986 is wrong, then that must be updated. I don't know how tricky
that will be, it is an old RFC and the original RFC 1738 dates from 1994
and also has text that '%' needs to be encoded.

I'm curious how they want to update RFC 3986.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Aug 2021 08:39:41 +1200

> "That is a bug.  The '%' must be treated as the syntactic delimiter it is.

Well, the issue is that the prose in RFC3986 isn't really consistent
with the ABNF, where the pct-encoded construct is precisely defined and used.
A parser that strictly follows the ABNF will only apply percent encoding
(and decoding) where the ABNF tells it to, not to the whole string. That's
exactly the point we need to discuss with the implementers in WHATWG.
 
> I'm curious how they want to update RFC 3986.

We (the IETF) are "they". Unfortunately, there's another "they", the
implementers, and in the end the implementers win, because running
code trumps rough consensus.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 18 Aug 2021 15:18:43 +0200

>exactly the point we need to discuss with the implementers in WHATWG.

I checked some running code:
https://f%31.example.com/
is accepted by Chrome, Firefox, and Safari as https://f1.example.com/.
Curl doesn't do percent processing and seems to be clearly wrong here.

https://192.168.1.%31/
is accepted by Chrome, Firefox, and Safari as https://192.168.1.1/.
Curl doesn't do percent processing and tries to resolve '192.168.1.%31'.

https://[2001:0DB8::%31]/
is accepted by Chrome as https://[2001:0DB8::1]/
It is rejected by Firefox and Safari as invalid.
Curl doesn't do percent processing and possibly treats it as a zone ID.

So it seems that curl violates Section 3.2.2 of RFCC 3986, because that
section explicitly calls for percent processing for 'registered' names.

Chrome is consistent and applies percent processing to both IPv4 and IPv6
literals even though the RFC does not explictly require that.

Firefox and Safari seem inconsistent in applying percent processing to
IPv4 literals but considering IPv6 literals with percents as invalid.

>code trumps rough consensus.

So it seems that the running code does random things unrelated to the
RFC. And there is not a lot of agreement in the running code.

Best to avoid this mess and pick a new separator for zone IDs.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Aug 2021 20:53:40 +0200

> is accepted by Chrome, Firefox, and Safari as https://f1.example.com/.

Correct, reg-name includes pct-encoded.

> Curl doesn't do percent processing and seems to be clearly wrong here.

Indeed.

> is accepted by Chrome, Firefox, and Safari as https://192.168.1.1/.

Incorrect.

> Curl doesn't do percent processing and tries to resolve '192.168.1.%31'.

Correct.

> is accepted by Chrome as https://[2001:0DB8::1]/

Incorrect, IPv6address does not include pct-encoded.

> It is rejected by Firefox and Safari as invalid.

Correct.

> literals even though the RFC does not explictly require that.

It’s not that it doesn’t require that; it does not allow that.

> IPv4 literals but considering IPv6 literals with percents as invalid.

Of course, the problem as usually is that ABNF is being used to describe the input to a process (pct-decoding), when implementers are quite likely to apply it to the output of the process.  But at least RFC 3986 appears to be self-consistent here.

> Best to avoid this mess and pick a new separator for zone IDs.

Note that, when fixing this, there is absolutely no reason to change 4007 from “%” — note that 4007 doesn’t have square brackets either.  6874bis could (continue to) introduce square brackets and a new delimiter with that.  Choosing, say, / would probably be not too wise, but just about anything else that cannot go into IPv6address (HEXDIG, :, .) is fair game.

Grüße, Carsten