Subject: Fwd: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Jul 2021 14:41:05 +1200

Hi,

In case people aren't aware, no web browser that we know of supports
RFC6874, i.e. the extension to URI/URL syntax for a link-local
zone index in literal IPv6 addresses. This is annoying in several
use cases.

This new draft tackles what seems to be the main objection from
the browser community, namely that RFC6874 requires browsers to
remove the zone index before sending the URL out in a standard
HTTP message. That's a coding annoyance and it also breaks HTTP/1.1
rules for the "Host" header according to RFC7230.

There's background to this issue at:
https://bugzilla.mozilla.org/show_bug.cgi?id=700999 (still live but
officially closed WONTFIX) and
https://github.com/whatwg/url/issues/392

The new draft proposes to update the RFC accordingly. The changes
are relatively small but significant. There's a diff between the
RFC and this draft at:
https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html

Comments welcome. If we want to go ahead with this fix, we will need to
reach out to the URI specialists and the browser community, to be sure
it isn't a waste of time.

Regards
     Brian & Bob

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
Date: Sun, 04 Jul 2021 19:10:13 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
        Authors         : Brian Carpenter
                          Robert M. Hinden
	Filename        : draft-carpenter-6man-rfc6874bis-00.txt
	Pages           : 10
	Date            : 2021-07-04

Abstract:
   This document describes how the zone identifier of an IPv6 scoped
   address, defined as <zone_id> in the IPv6 Scoped Address Architecture
   (RFC 4007), can be represented in a literal IPv6 address and in a
   Uniform Resource Identifier that includes such a literal address.  It
   updates the URI Generic Syntax specification (RFC 3986) accordingly,
   and obsoletes RFC 6874.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jul 2021 09:06:11 +0100

Hi Brian, Bob,

Your draft says:

   In the spirit of "be liberal with what you
   accept", we also suggest that URI parsers accept bare "%" signs when
   possible (i.e., a "%" not followed by two valid and meaningful
   hexadecimal characters).  This would make it possible for a user to
   copy and paste a string such as "fe80::a%en1" from the output of a
   "ping" command and have it work.  On the other hand, "%ee1" would
   need to be manually rewritten to "fe80::a%25ee1" to avoid any risk of
   misinterpretation.

I would prefer the document without this suggestion, as I think the
resulting logic for a uri parser is a good bit harder than the " %s are
handled differently within IPv6 literals" approach.  This requires the
parser to treat %s  differently within IPv6 literals except when the result
would be a "valid and meaningful" pair of hexadecimal characters.  If I
follow your logic correctly, that would mean not simply checking to be sure
that these are hex but also checking to be sure that the resulting
characters are within the syntax for the ZoneID production.

I think the proposal is much cleaner without this, and I encourage you to
reconsider including it.

regards,

Ted Hardie

On Mon, Jul 5, 2021 at 3:41 AM Brian E Carpenter <
[email-masked]> wrote:

>         Title           : Representing IPv6 Zone Identifiers in Address
> Literals and Uniform Resource Identifiers
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian Carpenter <[email-masked]>
Date: Mon, 5 Jul 2021 21:06:22 +1200

Ted, I agree about the complexity. otoh I believe that at least one browser
used to do this. How about saying that such a mechanism is not forbidden?

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 05 Jul 2021 11:34:04 +0200

I am bit puzzled about the interface ID discussion. While I understand
that % inside square brackets is treated differently than outside, the
overall complexity still seems to be low, isn't it?

        On encountering "[ + valid IPv6 address" browsers should (must?)
        accept an interface identifier of the form of "%string]".

This covers automatically the integer case as well as the named network
interfaces. Or am I missing something?

--
Sustainable and modern Infrastructures by ungleich.ch

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jul 2021 11:08:24 +0100

Hi Nico,

Essentially, the % symbol in a URI is an indicator that what follows is
percent encoded; see RFC 3986, section 2.1.  Section 2.4 also says:

   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.

 This proposal treats the % which starts a scope identifier as "data within
a URI" and so it percent-encodes the percent symbol.  Other approaches,
such as a bare percent symbol within the square brackets have been rejected
(see the long Mozilla bug thread Brian posted).

I think that taking this approach is worth trying, but I believe that
consistency is needed.  Making this the valid form but accepting the bare %
in some circumstances seems likely to me result in lack of
interoperability.  If I can paste when going into browser 1 but not browser
2, the result is confusing for the user.

Just my two cents, of course,

Ted

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 5 Jul 2021 11:30:38 +0100

Ted Hardie wrote on 05/07/2021 09:06:
> I think the proposal is much cleaner without this, and I encourage you 
> to reconsider including it.

yip, agreed. This looks like it may be troublesome to implement, with 
marginal benefit.

Otherwise the ID update is useful and it would be good to get input from 
the URI + browser people to see whether they think that it's workable.

Nick

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 5 Jul 2021 14:44:49 +0000

<without any hat>

I agree with Nick:

1/ the paragraph identified by Ted can only bring confusion (e.g., when comparing two URI for the same address), so, better remove this kludge from the I-D [1]
2/ getting feedback from transport area is probably required for the URI syntax

In addition and with my AD hat, I am slightly annoyed that the lack of willingness to implement was not detected during the IETF Last Call in 2012.

Regards

-éric

[1] and this will be a real value for the bis document else I do not think that the -bis is really useful

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Date: Monday, 5 July 2021 at 12:31
To: Ted Hardie <[email-masked]>
Cc: 6man <[email-masked]>, Bob Hinden <[email-masked]>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

    Nick

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Jul 2021 11:28:52 -0400

First, I think that this work is really important, and I'd like to proceed.

    > https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html

I read the diff, and I was unable to actually figure out what had changed :-(

    > it isn't a waste of time.

Does the zoneid go into the Host: header or not?
I can't tell at this point.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jul 2021 08:49:23 +1200

> I can't tell at this point.

As I understand the HTTP/1.1 spec, the Host: header is required to include
the complete URI, so RFC6874 was wrong anyway because it did not claim
to update HTTP :-). So yes, and furthermore at least one deployed 
protocol (CUPS) relies on it.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jul 2021 08:52:50 +1200

Eric,

I think that we believed we were making it more implementable, and there
was certainly cross-checking within the IETF. And there will be this time
(with ART, not Transport, however).

What we missed last time was any direct interaction with WHATWG. I'm not
even sure that WHATWG existed then.

We're listening to the comments about Ted's point, of course.

Regards
   Brian Carpenter

On 06-Jul-21 02:44, Eric Vyncke (evyncke) wrote:
> <without any hat>
> 
> I agree with Nick:
> 
> 1/ the paragraph identified by Ted can only bring confusion (e.g., when 
comparing two URI for the same address), so, better remove this kludge from the I-D [1]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Jul 2021 20:56:12 +0000

Same here; this looks like a much needed bug fix.

Regards,

Pascal

> Le 5 juil. 2021 à 22:53, Brian E Carpenter <[email-masked]> a écrit :
> 
> Eric,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jul 2021 16:57:20 +1200

Ted,

percent encoded; see RFC 3986, section 2.1.  Section 2.4 also says:
>  This proposal treats the % which starts a scope identifier as "data within a URI" and so it percent-encodes the percent symbol.  Other approaches, such as a bare percent symbol within the square brackets have been rejected (see the long Mozilla bug thread Brian posted).
> 
> I think that taking this approach is worth trying, but I believe that consistency is needed.  Making this the valid form but accepting the bare % in some circumstances seems likely to me result in lack of interoperability.  If I can paste when going into browser 1 but not browser 

Yes, that is a fairly persuasive argument.

Just to play devil's advocate for a moment, once consequence of the % escape is that
the user could execute
   ping6  fe80::80b2:5c79:2266:e431%eth0
but in a browser window would have to type
   https://[fe80::80b2:5c79:2266:e431%25eth0]
so a simple cut-and-paste won't do it.

Appendix A of the draft, which is unchanged from RFC6874, summarizes the options considered the previous time round.

Regards
   Brian

> On Mon, Jul 5, 2021 at 10:33 AM Nico Schottelius <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Brian Carpenter <[email-masked] <mailto:[email-masked]>> writes:
> 
>     > On Mon, 5 Jul 2021, 20:06 Ted Hardie, <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >> Hi Brian, Bob,
>     >>
>     >> Your draft says:
>     >>
>     >> [email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >>> Hi,
>     >>>
>     >>> https://bugzilla.mozilla.org/show_bug.cgi?id=700999 <https://bugzilla.mozilla.org/show_bug.cgi?id=700999> (still live but
>     >>> https://github.com/whatwg/url/issues/392 <https://github.com/whatwg/url/issues/392>
>     >>>
>     >>> https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html <https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html>
>     >>>
>     >>> From: [email-masked] <mailto:[email-masked]>
>     >>> Reply-To: [email-masked] <mailto:[email-masked]>
>     >>> To: [email-masked] <mailto:[email-masked]>
>     >>>
>     >>>
>     >>>         Title        
   : Representing IPv6 Zone Identifiers in Address
>     >>>         Pages        
   : 10
>     >>>         Date        
    : 2021-07-04
>     >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/>
>     >>>
>     >>> https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html <https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html>
>     >>>
>     >>>
>     >>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>     >>>
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>
>     >>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>     >>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>     >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>
>     >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     > [email-masked] <mailto:[email-masked]>
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     Sustainable and modern Infrastructures by ungleich.ch <http://ungleich.ch>
>

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 06 Jul 2021 09:33:11 +0200

While copy & paste won't work with this proposal, I believe the %25
escape should be "good enough" for most daily usage.

I think we don't need to aim for a "perfect solution", which we will not
be able to achieve anyway, but a solution for reality.

In this regard, as a network operator, I can support this direction to
better have a, rather than no solution.

In a perfect world, the [...%] syntax would have been introduced (and
accepted) prior to % escape in URLs.

Another direction, which is probably also very unlikely to achieve,
would be to change the delimiter on OS basis and harmonise it with the
browser.

Best regards,

Nico

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jul 2021 08:47:49 +0100

Hi Brian,

In-line below

On Mon, Jul 5, 2021 at 9:50 PM Brian E Carpenter <
[email-masked]> wrote:

> the complete URI,

This is not correct.  Please see RFC 7230, Section 5.4.  The full URI would
include scheme and the path, which are not included in the host header.

regards,

Ted

> so RFC6874 was wrong anyway because it did not claim

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jul 2021 09:32:46 -0400

> escape should be "good enough" for most daily usage.

Also, ping and/or getaddrinfo() could become tolerant of %25 as a special
case (and given that few Windows machines have 25 interfaces), which would
let the copy&paste work the other way.

    > accepted) prior to % escape in URLs.

Agreed.

    > would be to change the delimiter on OS basis and harmonise it with the

We could document another deliminter as a recommendation transition.
Looking at my keyboard, it's hard to pick one.   Only $ comes to mind.

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 11:25:27 -0400

On Mon, Jul 05, 2021 at 11:08:24AM +0100, Ted Hardie wrote:
>    Hi Nico,
>    Essentially, the % symbol in a URI is an indicator that what
>    follows is percent encoded; see RFC 3986, section 2.1.  Section
>    2.4 also says:  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.
> 
>     This proposal treats the % which starts a scope identifier as "data
>    within a URI" and so it percent-encodes the percent symbol.  

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

We don't encode the '[' or the ':' either.  We only allow
percent-encoding in the percent-decoded data parts of the URI.  The '%'
is a delimiter between two separate data parts.  It is not a data part.
The user cannot input different values there.

No other percent-encoded character is allowed there.  It is not a data
part!  It is a constant, not a variable!  It is not a percent-decoded
component!

You are not allowed by RFC3986 to treat it as a data part, because that
document states correctly that it is not one.

Please remember two facts and a corollary that I posted here last week:

  1.  RFC3986 says percent-decoding is done AFTER parsing into components
      and subcomponents

  2.  The IPv6 literal subcomponent is NOT percent-encoded.

  2a. No percent-decoding is done (or allowed) on this parsed subcomponent.

(Ref:<https://mailarchive.ietf.org/arch/msg/ipv6/FPLeDZXqJ1zwE1yF_Qkh7Ldq120/>)

The technical question before us is whether to put a percent-encoded
character into a non-percent-decoded field!

The unfixable problem for implementors is where to strip the
redundantly-added "25".  The URL fragment needs to move like this:

  1.User --> 2.Location Bar --> 3. Web client --> 4.Web server --,
                                                                 |
                                       ,-- 5.Web application <---'
                                       |
                                       .------------------,
                                                          |
  8.User <-- 7.UA rendered content <-- 6.Web client <-----'

If a point of mangling is specified, then a corresponding point of
de-mangling must be specified.  Neither have been properly specified.

I claim ONLY if the fragment is mangled at 3 and de-mangled at 4, then
it can be made to work with the full range of addresses.  Mangle at the
latest possible chance, unmangle at the first possible chance.  Thus
protecting the user AND the developer of the web application AND the
developer of the OS insofar as the web application developer depends on
the OS interface.

In the case of {3,4} mangling is harmless -- but serves no purpose.

I claim no other choice of mangle/de-mangle locations even works.

Note: It is NOT acceptable to require the user to handle any mangling or
de-mangling at 1 or 8.

>    Other
>    approaches, such as a bare percent symbol within the square brackets
>    have been rejected (see the long Mozilla bug thread Brian posted).

That Mozilla bug thread explains the correct approach to the scopeid
parsing in comment 39:
https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c39

        heinz.repp
        Comment 39 • 5 years ago

        (In reply to Brian  E Carpenter from comment #38)
        > But the real objection from
        > the browser side is that it's a horrible thing to implement.

        I know, this stems from Ryan Sleevi's 2015 comment, but having
        some experience in networks and C programming for decades I can
        hardly understand this. I see only 2 distinct jobs here:

        1. expand the parser of the url-decoded URI that already can
        parse IPv6-address-raw: instead of

        IPv6-literal = '[', IPv6-address-raw, ']';

        parse

        IPv6-literal = '[', IPv6-address-raw, [ '%', IPv6-scope-id ], ']';
        IPv6-scope-id = '0'-'9' | 'a'-'z' | 'A'-'Z', { '0'-'9' | 'a'-'z' | 'A'-'Z' | ' ' | '_' | '-' };

        difficulty: 'create your own parser' course, beginner's lesson

This is the ONLY correct implementation because it is the ONLY
implementation that guarantees that information is not lost in between
the user and the server.  We do not need a special case that loses
information here.  That loss is simply a bug.  A standard that mandates
a bug itself has a bug.

We simply need to fix the bug to get implementation.  The bug cannot be
accepted.  The bug must be removed from all existing standards.

We cannot allow some other standard to block this standard that blocks
the software bugfix: instead, the bug in the software must be fixed, so
that all standards mandating the bug must surrender their priority to
the need to fix the software bug itself.

Any standard that claims to have higher priority than fixing the bug in
the code must be laughed at by the gods and looked at with suspicion by
mortals.

>    consistency is needed.  Making this the valid form but accepting the
>    bare % in some circumstances seems likely to me result in lack of
>    interoperability.  If I can paste when going into browser 1 but not
>    browser 2, the result is confusing for the user.

Yes.  The one correct solution is to fix the percent-encoding bug
entirely.  It does not make sense to try to support any mangling.

However, isn't this just about Microsoft, and theirs the sole broken
name-mangling implementation?  Is it just Microsoft here demanding that
everyone else match their bug?  Just one firm?

Then let Microsoft ignore the standard -- do not let them ruin it.
Their browser can be the one we call confusingly different.  It cannot
be allowed to lead.

Name-mangling is wrong.  It is anti-user.  It does not serve any user
interest.  It is an "anti-feature."

Name-mangling cuts off the user from access to software written by many
developers.

Name-mangling breaks much software written behind the web server _and_
potentially software written behind the /etc/nsswitch.conf module
system, which allows great diversity of supply of names into the system.

That is a system that allows developers to plug in their own new
implementations of new ideas.  Don't try to take that away!

# Solution to Problem #

The way to fix port 80 is to abolish the name-mangling middle-man
forever.

Let the server know exactly what the browser's location bar says.
Let the user tell the location bar exactly what the user will.
Make the unbroken user<->server bond a requirement of HTTP.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jul 2021 17:00:04 +0100

Hi Andrew,

A short reply in-line.

> That is a bug.  The '%' must be treated as the syntactic delimiter it is.
My apologies; it appears that I didn't get my intent across.  Let me try to
rephrase.  Because of a collision between the defined zone-id scope-id
separator and the URI syntax, this proposal percent encodes the zone-id
separator, and updates the URI syntax to permit the percent-encoded zone-id
separator to be included in the IP literal syntax.

Since this update RFC 3986, this would be permitted if this is approved,
even though this is a change from RFC 3986.

I hope that remedies any lack of clarity on my part,

regards,

Ted

> (Ref:<
> https://mailarchive.ietf.org/arch/msg/ipv6/FPLeDZXqJ1zwE1yF_Qkh7Ldq120/>)
>
>
>
>
>
>

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 11:45:45 -0400

> be able to achieve anyway, but a solution for reality.

The perfect solution is just the simple one of not introducing the
anti-feature of name-mangling.  It is simpler NOT to add that to Firefox
than to add it.  And it is more correct.  For the same reason!

> accepted) prior to % escape in URLs.

It doesn't matter that '%' is also an escape character in some of
the URI data segments.  Percent-decoding is done AFTER parsing into
segments.  We don't have to worry about implementations accidentaly
decoding segments that aren't even allowed to be encoded.

So that does not conflict with the use of a % as a delimiter ending a
data segment (such as IPv6-Literal) that is NOT percent-encoded.

It would only conflict if the IPv6-Literal field allowed % encoded
values!

The whole problem is imaginary.

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 12:00:27 -0400

> let the copy&paste work the other way.

I stated in another message today:

You are proposing de-mangling occur at (8).

Where should mangling occur?

Should it not occur at (1) to match?  Thus a {1,8} solution!  I had not
considered that!

In that case, no implementation of software need mangle any name.  We
rely on the user to provide the mangling AND the de-mangling.

* Require the user to strip "25" from browser output.
* Require the user to input "25" as browser input.

The symmetry is beautiful.

Acceptable?

Is there any name or address NOT supported by the {1,8} solution?

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 12:18:59 -0400

On Tue, Jul 06, 2021 at 05:00:04PM +0100, Ted Hardie wrote:
> 
>    My apologies; it appears that I didn't get my intent across.  Let me
>    try to rephrase.  Because of a collision between the defined zone-id
>    scope-id separator and the URI syntax

I've already explained to this list, last week, why there is no
collision.  So it appears to me, not that I've failed to understand your
intent, but that you didn't even read that.  :(

To be fair, it was long.  Today I reiterate everything.

There is no such collision because IPv6-Literal is not a percent-decoded
data component.  Percent-decoding is done AFTER parsing into components,
only some of which are encoded like that.  It's done on OTHER COMPONENTS
but not done on the component where you say it conflicts.

It would only be a conflict if it was in one of the components that
allowed that encoding.

>    Since this update RFC 3986, this would be permitted if this is
>    approved, even though this is a change from RFC 3986.

You acknowledge that the RFC specifies that the field is not subjected
to percent-decoding.

The point you miss is that therefore there is no conflict with using it
as a syntactic delimiter.

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 12:00:27 -0400

Acceptable?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jul 2021 12:54:01 -0400

> but not done on the component where you say it conflicts.

So why do the browser implementers have such difficulties with processing
this?    Running code wins.

You can argue forever that they are wrong, and yet, here we are, ten years
later, without anything working.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 6 Jul 2021 13:01:29 -0400

> On Jul 6, 2021, at 12:54 PM, Michael Richardson <[email-masked]> wrote:
> 

I have a general concern here that this is why network equipment that comes with a default IP address will continue to live on in IPv4 land, and may never see IPv6 configuration as a result.  I’m sure someone will suggest using mDNS to go to https://myrouter.local/ or similar, but the complexity introduced by link-local here is unlikely to see significant changes as a result on either side, we are in a classic standoff situation.

I hate to say it but mDNS is likely the way to go for many things, but you may not be able to tell the difference between raspberrypi.local vs raspberrypi-2.local which can often be a challenge.

- Jared

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 13:04:35 -0400

On Tue, Jul 06, 2021 at 12:54:01PM -0400, Michael Richardson wrote:
>     >> My apologies; it appears that I didn't get my intent across.
>     >> Let me try to rephrase.  Because of a collision between the
>     >> defined zone-id scope-id separator and the URI syntax
>
>     > I've already explained to this list, last week, why there is
>     > no collision.  So it appears to me, not that I've failed to
>     > understand your intent, but that you didn't even read that. :(
>
>     > There is no such collision because IPv6-Literal is not a
>     > percent-decoded data component.  Percent-decoding is done
>     > AFTER parsing into components, only some of which are encoded
>     > like that.  It's done on OTHER COMPONENTS but not done on the
>     > component where you say it conflicts.
>
> So why do the browser implementers have such difficulties with
> processing this?  Running code wins.

There is no difficulty implementing it the way that I say to do it!

The difficulty (or rather, refusal) is implementing it the broken way
that the standard says to do.

I say we fix the broken standard to get it implemented!

> later, without anything working.

Firefox DID implement this.  Mozilla REMOVED the implementation.
Mozilla refuses to add the feature BECAUSE OF THIS STANDARD.

That's the whole reason this standard is being re-opened.  The browser
devs refuse to implement first.  They demand standards change first.

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 06 Jul 2021 19:53:48 +0200

Jared Mauch <[email-masked]> writes:
> I hate to say it but mDNS is likely the way to go for many things, but
> you may not be able to tell the difference between raspberrypi.local
> vs raspberrypi-2.local which can often be a challeng

I don't think mDNS is feasible, as you often don't know the device
name. Let me illustrate a use case that is already there and is indeed
tricky for us at the moment:

We have a "bootstrap network" (layer 2) that contains dozens
or even low hundreds of unconfigured devices. All of these devices can
easily be *found* by using IPv6 multicast ff02::1.

However *some* of them might be broken, have configurations that need to
be repaired via HTTP. The device configuring these devices is usually
some kind of "admin notebook (or desktop)", which we try to configure
"as robust as possible", because there are tons of devices providing
IPv4, IPv6, etc. - it's basically the "device zoo".

Overall, most of these devices can be identified (EUI-64 embedding) and
configured (ssh, dhcp, etc.) automatically. However *some* need manual
care and the trend goes towards requiring an HTTP(s) connection.

What I want to show with this example is that you cannot easily rely on
more complex/upper layer protocols - the only identifier you have is the
link local address, the MAC and the open port list.

Cheers,

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 06 Jul 2021 20:03:29 +0200

> (Ref:<https://mailarchive.ietf.org/arch/msg/ipv6/FPLeDZXqJ1zwE1yF_Qkh7Ldq120/>)

I've skimmed RFC3986 and have a bit of trouble reading it - and maybe
that's also the reason why browser developers had trouble properly
implementing it.

For me the three statements from Andrew are well readable and
understandable.

Would it by any chance be easier to create a specific RFC
"Parsing of IPv6 literal addresses in URIs"
that basically re-iterates the three sentences above and maybe even
includes a parser description?

They are well reasoned, easy to understand and easy to implement. Given
that we add a "reference parser", which could even be a regexp,
developers might be able to "copy and paste" the parser into their code
(+/- language bindings).

Cheers,

Nico

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jul 2021 14:43:17 -0400

> I have a general concern here that this is why network equipment that
    > comes with a default IP address will continue to live on in IPv4 land,
    > and may never see IPv6 configuration as a result.  I’m sure someone
    > will suggest using mDNS to go to https://myrouter.local/ or similar,
    > but the complexity introduced by link-local here is unlikely to see
    > significant changes as a result on either side, we are in a classic
    > standoff situation.

    > you may not be able to tell the difference between raspberrypi.local vs
    > raspberrypi-2.local which can often be a challenge.

And no HTTPS.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jul 2021 14:45:41 -0400

> that the standard says to do.

Well, each time I read your (multiple) posts, I see you describing what I
think that the standard already says.  Obviously, I'm wrong.

You also seem to be disagreeing with Brian's text, which is why I'm confused.
Maybe you could just make a pull request to Brian's document?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Jul 2021 20:48:19 +0200

> And no HTTPS.

Unless we want that to work.

(This would require putting an identity into the reg-name part of the authority.)

Grüße, Carsten

---

From: Andrew Cady <[email-masked]>
Date: Tue, 6 Jul 2021 16:05:08 -0400

On Tue, Jul 06, 2021 at 02:45:41PM -0400, Michael Richardson wrote:
>     > The difficulty (or rather, refusal) is implementing it the
>     > broken way that the standard says to do.
>
> Well, each time I read your (multiple) posts, I see you describing
> what I think that the standard already says.  Obviously, I'm wrong.
>
> You also seem to be disagreeing with Brian's text, which is why
> I'm confused.  Maybe you could just make a pull request to Brian's
> document?

The problem isn't with the changes Brian made.  Those changes were
needed and good.  (By the way, thanks Brian.)

The problem is in what was left unchanged.  Brian did not break with
rfc6874 but that break is what is needed.  We need to propagate the fix
back to all relevant RFCs.

Specifically, these definitions must change:

    ZoneID = 1*( unreserved / pct-encoded )
    IPv6addrz = IPv6address "%25" ZoneID

These definitions can be used instead:

    ZoneID = 1*( unreserved )
    IPv6addrz = IPv6address "%" ZoneID

By the way, there is a relevant mistake of fact in rfc6874:

    According to URI syntax [RFC3986], "%" is always treated as an
    escape character in a URI,

The "always" part is untrue.  It is only treated that way where BNF says
"pct-encoded".  Inside of square brackets it must instead be treated as
an error.  Pct-encoded data is not allowed there.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 6 Jul 2021 17:02:41 -0400

If you can't trust on link you have larger problems than the lack of S

Sent from my TI-99/4a

> On Jul 6, 2021, at 2:43 PM, Michael Richardson <[email-masked]> wrote:
> 
> And no HTTPS.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jul 2021 14:16:51 +1200

Andrew,

>     IPv6addrz = IPv6address "%" ZoneID

Thanks for making a concrete proposal. My belief back when
we did RFC6874 was that this would not be acceptable in the
URI world. I'd be glad to test this belief again.
 
> an error.  Pct-encoded data is not allowed there. 

Well, it *is* allowed in a URI precisely because RFC6874 formally updates
RFC3986. I agree that the production for IPv6address in RFC3986 doesn't
include pct-encoded. However, RFC3986 section 2.4 says:

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

As I recall the discussion nine years ago, that statement was taken
literally to mean *anywhere* in a URI. You are probably correct that a
strictly ABNF-driven parser wouldn't apply the escape mechanism except
within pct-encoded, but what do real-world parsers do?

Personally I'd be happy if we could make the change you suggest, but
we'd need to hear from the implementers.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jul 2021 14:36:17 +1200

Ted,

Below...

On 06-Jul-21 19:47, Ted Hardie wrote:
> Hi Brian,
> 
> In-line below
> 
> On Mon, Jul 5, 2021 at 9:50 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>     >     > The new draft proposes to update the RFC accordingly. The changes
>     >     > are relatively small but significant. There's a diff between the
>     >     > RFC and this draft at:
>     >     > https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html <https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html>
>     >
>     >     > Comments welcome. If we want to go ahead with this fix, we will need to
>     >     > reach out to the URI specialists and the browser community, to be
>     sure
>     >     > it isn't a waste of time.
>     >
> This is not correct.  Please see RFC 7230, Section 5.4.  The full URI would include scheme and the path, which are not included in the 
host header. 

Correct, i.e.

  Host = uri-host [ ":" port ]

and if we follow the breadcrumbs to uri-host

  uri-host = <host, see [RFC3986], Section 3.2.2>

where

   host        = IP-literal / IPv4address / reg-name

and of course it's IP-literal that we redefine in RFC6874 and the present 
draft.
In the ideal world, RFC7230 should IMHO have cited RFC6874 as well as RFC3986.

However, what I was getting at is that a browser that mangles the IP-literal by
*removing* the ZoneID, as required by RFC6874, would be violating the behaviour described by RFC7230. Since we propose to delete that requirement anyway, the
issue is moot for the present draft. Sorry about my lack of clarity.

   Brian

>     > Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
>     >            Sandelman Software Works 
Inc, Ottawa and Worldwide
>     >
>     >
>     >
>     >
> 
<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jul 2021 14:44:37 +1200

Nico,
> includes a parser description?

I would think that *when* we have agreed on a definitive solution,
we should add that text as an appendix to rfc6874bis.

> developers might be able to "copy and paste" the parser into their code

I think the browser implementers know their business better than 6MAN does,
but having a sample implementation is never a bad thing.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jul 2021 14:51:27 +1200

Michael,

Below...
> Looking at my keyboard, it's hard to pick one.   Only $ comes to mind.

We did talk about that nine years ago (and used a hyphen as the example). See
https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html#appendix-A-3.3.1

   Brian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Jul 2021 08:39:26 +0100

Hi Brian,

> URI world. I'd be glad to test this belief again.
The difficulty with this approach is that it requires you to treat the %
with different semantics depending on where it occurs in the URI.  From a
specification perspective, that's a major change from the philosophy in the
development of URIs which were attempting to be, well, uniform.  From a
practical perspective, it may look easy when you use a parser with a
specific order of operations, but it ends up ossifying that order into the
base spec.  That may not be a great thing (or possibly, given the breadth
of schemes which might use this production).

I'd also like to draw your attention to RFC 8820, which updates RFC 3986 to
give best practices in defining structure and semantics in URIs.  Its
guidelines, specifically in section 2, may help guide your thinking here.

As a practical matter, I suggest you ask for a slot in the upcoming
DISPATCH/ART area open meeting; that will help get a different community
focused on your proposal.

best regards,

Ted Hardie

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Jul 2021 17:31:21 +0200

>let the copy&paste work the other way.

Instead of doing this, maybe we should pick a new character in an update of
RFC 4007 and deprecate '%' as a mistake?

Aternatively, if we make fe80::ABCD%0 a valid address in the socket API
(and do something sensible in operating systems to select a default interface)
then we can reduce the use of scoped addresses and thus the copy paste problem.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jul 2021 11:44:22 -0400

> RFC 4007 and deprecate '%' as a mistake?

I think it's worth thinking about again.

    > then we can reduce the use of scoped addresses and thus the copy paste problem.

Actually, that pretty much is the case,
(assuming that you consider getaddrinfo() to be part of the API).
A problem is that browsers don't use it directly, because
reasons... including Happy Eyeballs, and because the location bar is also
search, etc.
That's why Curl trivially works, but chrome doesn't.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Jul 2021 09:18:39 +1200

> RFC 4007 and deprecate '%' as a mistake?

Even 9 years ago the WG concluded that '%' was too engrained in code and
actual practice to deprecate it. Many libraries that handle IPv6 addresses
support '%' and that means that innumerable pieces of software would be
impacted, so deprecation seems impractical.

If this was a mistake, it was made in 2005 when we approved RFC4007.
 
> Aternatively, if we make fe80::ABCD%0 a valid address in the socket API

I think you'll find that it already is. I use the netifaces module in Python
and it returns things like [{'addr': '00:ff:19:f7:7d:9a'}], 23: [{'addr': 'fe80::216a:f0d3:2303:3d1%6', 'netmask': 'ffff:ffff:ffff:ffff::/64', 'broadcast': 'fe80::ffff:ffff:ffff:ffff%6'}]. It's a bit obscure, though. Also (before
Python 3.7) socket.getaddrinfo(socket.gethostname(),0) on Windows would
return fe80::216a:f0d3:2303:3d1%6, but somebody changed that behaviour.

I needed to make this work to implement RFC 8990 and it wasn't exactly
intuitive.

> (and do something sensible in operating systems to select a default interface)

But the interesting use cases are ones where the default won't do.

    Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Jul 2021 09:56:43 +1200

On 07-Jul-21 19:39, Ted Hardie wrote:
> Hi Brian,
> 
> On Wed, Jul 7, 2021 at 3:17 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Andrew,
> 
>     >>     >> So why do the browser implementers have such difficulties with
>     >>     >> processing this?  Running code wins.
>     >>
>     >>     > There is no difficulty implementing it the way that I say to do
>     >>     > it!
>     >>
>     >>     > The difficulty (or rather, refusal) is implementing it the
>     >>     > broken way that the standard says to do.
>     >>
> The difficulty with this approach is that it requires you to treat the % with different semantics depending on where it occurs in the URI.  
From a specification perspective, that's a major change from the philosophy in the development of URIs which were attempting to be, well, uniform.  From a practical perspective, it may look easy when you use a parser with a specific order of operations, but it ends up ossifying that order into the base spec.  That may not be a great thing (or possibly, given the breadth of schemes which might use this production). 

Exactly my point, Ted, but Andrew disputes it.
 
> I'd also like to draw your attention to RFC 8820, which updates RFC 3986 to give best practices in defining structure and semantics in URIs.  
Its guidelines, specifically in section 2, may help guide your thinking here.

I don't see much there that addresses our dilemma.
 
> As a practical matter, I suggest you ask for a slot in the upcoming DISPATCH/ART area open meeting; that will help get a different community focused on your proposal.

We will do that in any case.

Thanks
   Brian

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Jul 2021 11:53:20 +0200

>If this was a mistake, it was made in 2005 when we approved RFC4007.

If we started changing 9 years ago, we would be done now. What I see is
that addresses with zone IDs are used rarely and locally. And lots of software
doen't even know how to deal with it. 

If we now introduce, for example, '-' in addition to '%' and require parsers
to accept both, but canonical output remains at '%' for a while then we
will have a sensible input format for URLs.

Keeping '%' as the only option means that URLs will remain a mess.

>and it returns things like [{'addr': '00:ff:19:f7:7d:9a'}], 23: [{'addr': 'fe8
>0::216a:f0d3:2303:3d1%6', 'netmask': 'ffff:ffff:ffff:ffff::/64', 'broadcast': 
>'fe80::ffff:ffff:ffff:ffff%6'}]. It's a bit obscure, though. Also (before

I guess I was too terse.

>From a socket API point of view writing an IPv6 address without zone ID is
equivalent to using zone ID 0. So 2001:db8::1 and 2001:db8::1%0 are the
same. 

However, in the case of link local, the opengroup specifically disallows
the use of zone ID 0.

If we would introduce a command like
'set-default-interface-for-link-local eth0'
that makes zone ID 0 available, then a URL like http://[fe80::abcd]/
could work. No change needed to browsers, no complex syntax.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jul 2021 11:29:10 -0400

> could work. No change needed to browsers, no complex syntax.

That an interesting option/workaround.
I suspect that the Linux networking people would accept a patch.
I understand that Windows does this already when there is a single
non-loopback interface.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Jul 2021 10:16:29 +1200

> I understand that Windows does this already when there is a single

Windows just does it, no need for a pseudo-zone %0, although it does work.
This is desirable behaviour, but I don't see that it has anything to do
with the URI syntax.

In what follows, the target (Android phone) is on WiFi which is bridged to
Ethernet, and the Windows host is connected to both. %7 is Ethernet and
%23 is WiFi.

C:\WINDOWS\system32>ping fe80::de55:83ff:fe46:cdcb

Pinging fe80::de55:83ff:fe46:cdcb with 32 bytes of data:
Reply from fe80::de55:83ff:fe46:cdcb: time=553ms
Reply from fe80::de55:83ff:fe46:cdcb: time=50ms
Reply from fe80::de55:83ff:fe46:cdcb: time=68ms
Reply from fe80::de55:83ff:fe46:cdcb: time=77ms

Ping statistics for fe80::de55:83ff:fe46:cdcb:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 50ms, Maximum = 553ms, Average = 187ms

C:\WINDOWS\system32>ping fe80::de55:83ff:fe46:cdcb%7

Pinging fe80::de55:83ff:fe46:cdcb%7 with 32 bytes of data:
Reply from fe80::de55:83ff:fe46:cdcb%7: time=80ms
Reply from fe80::de55:83ff:fe46:cdcb%7: time=96ms
Reply from fe80::de55:83ff:fe46:cdcb%7: time=104ms
Reply from fe80::de55:83ff:fe46:cdcb%7: time=113ms

Ping statistics for fe80::de55:83ff:fe46:cdcb%7:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 80ms, Maximum = 113ms, Average = 98ms

C:\WINDOWS\system32>ping fe80::de55:83ff:fe46:cdcb%23

Pinging fe80::de55:83ff:fe46:cdcb%23 with 32 bytes of data:
Reply from fe80::de55:83ff:fe46:cdcb%23: time=47ms
Reply from fe80::de55:83ff:fe46:cdcb%23: time=53ms
Reply from fe80::de55:83ff:fe46:cdcb%23: time=66ms
Reply from fe80::de55:83ff:fe46:cdcb%23: time=74ms

Ping statistics for fe80::de55:83ff:fe46:cdcb%23:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 47ms, Maximum = 74ms, Average = 60ms

C:\WINDOWS\system32>ping fe80::de55:83ff:fe46:cdcb%0

Pinging fe80::de55:83ff:fe46:cdcb with 32 bytes of data:
Reply from fe80::de55:83ff:fe46:cdcb: time=206ms
Reply from fe80::de55:83ff:fe46:cdcb: time=107ms
Reply from fe80::de55:83ff:fe46:cdcb: time=216ms
Reply from fe80::de55:83ff:fe46:cdcb: time=19ms

Ping statistics for fe80::de55:83ff:fe46:cdcb:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 216ms, Average = 137ms

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Jul 2021 10:35:03 +1200

> However, in the case of link local, the opengroup specifically disallows

I think that derives from RFC4007:

'  An implementation should also support the concept of a "default" zone
   for each scope.  And, when supported, the index value zero at each
   scope SHOULD be reserved to mean "use the default zone".'

So you can't have a real zone/interface 0. As Michael said, WinSock
got this right (see my message just now). POSIX apparentlt didn't,
but it doesn't matter if you're writing code that is aware of
zone/interface indices.

> could work. No change needed to browsers, no complex syntax.

It works today on Windows with Firefox or Chrome.
http://[fe80::2e3a:fdff:fea4:dde7]/ goes straight to my router's
web interface. Fails on Android, which I suppose inherited
Linux's brokenness on this point.

However, this is beside the point for use cases that *need*
to specify the zone/interface index. We'll make doubly sure
that is clear in the next version.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jul 2021 20:35:20 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Philip Homburg <[email-masked]> wrote: > If we would
    >> introduce a command like > 'set-default-interface-for-link-local eth0'
    >> That an interesting option/workaround.  I suspect that the Linux
    >> networking people would accept a patch.  I understand that Windows
    >> does this already when there is a single non-loopback interface.

    > Windows just does it, no need for a pseudo-zone %0, although it does
    > work.  This is desirable behaviour, but I don't see that it has
    > anything to do with the URI syntax.

I suspect that the scope-id is simply left as 0 in the sockaddr structure
if you provide no %X, and that's how it knows that you want the magic scope 0.

    > Pinging fe80::de55:83ff:fe46:cdcb with 32 bytes of data: Reply from
    > fe80::de55:83ff:fe46:cdcb: time=206ms Reply from
    > fe80::de55:83ff:fe46:cdcb: time=107ms Reply from
    > fe80::de55:83ff:fe46:cdcb: time=216ms Reply from
    > fe80::de55:83ff:fe46:cdcb: time=19ms

    > Ping statistics for fe80::de55:83ff:fe46:cdcb: Packets: Sent = 4,
    > Received = 4, Lost = 0 (0% loss), Approximate round trip times in
    > milli-seconds: Minimum = 19ms, Maximum = 216ms, Average = 137ms

So, how is working even though you have one non-loopback interface?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Jul 2021 15:13:35 +1200

> So, how is working even though you have one non-loopback interface?

I'm not sure I understand that question. As far as I can tell, there is
no named interface in Windows that fulfills the function of 'lo' in Linux.
So I'm guessing it's special-cased in the code, but somebody at Microsoft
knows the answer.

Anyway... Wireshark tells me that the ping is going out on the Ethernet
interface, which is %7, rather than WiFi, which is %23. So Windows picks
Ethernet when given the choice.

   Brian

---

From: Andrew Cady <[email-masked]>
Date: Fri, 9 Jul 2021 01:19:43 -0400

On Thu, Jul 08, 2021 at 09:56:43AM +1200, Brian E Carpenter wrote:
> > The difficulty with this approach is that it requires you to treat
> > the % with different semantics depending on where it occurs in the
> > URI. 
> >
> > From a specification perspective, that's a major change from the
> > philosophy in the development of URIs which were attempting to be,
> > well, uniform.  From a practical perspective, it may look easy when
> > you use a parser with a specific order of operations, but it ends up
> > ossifying that order into the base spec.  That may not be a great
> > thing (or possibly, given the breadth of schemes which might use
> > this production).
>

I acknowledge that you can't pct-decode unreserved characters on a
first pass before parsing out the IPv6 literal field and still use the
unencoded % as syntax within that field.

Yet even a parser that _does_ decode unreserved before parsing still
won't ever mix up the _boundary_ of the IPv6 address based on whether %
is within it.  So why does it matter?

Either an implementation has been updated to support the fe80 address
syntax or not.

If not, the fact those addresses won't work doesn't matter.  It only
matters whether a failure mode is harmful.  It looks like the failure
mode is at worst IPv6 parse constructing an unzoned fe80 address that
can't be connected to, and in practice probably a parse error like "URL
using bad/illegal format or missing URL".

If the implementation has been updated, the update can simply include
not decoding %25 within the square brackets.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jul 2021 13:00:36 -0400

>> So, how is working even though you have one non-loopback interface?

Er, I mispoke.  More than one non-loopback interface.

    > no named interface in Windows that fulfills the function of 'lo' in
    > Linux.  So I'm guessing it's special-cased in the code, but somebody at
    > Microsoft knows the answer.

Really, no loopback?  What is ::1 attached to?

    > interface, which is %7, rather than WiFi, which is %23. So Windows
    > picks Ethernet when given the choice.

I thought it would only work when you had one (active) interface.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 09:10:19 +1200

> Really, no loopback?  What is ::1 attached to?

A mystery to me... amusingly enough, Windows allows this:

C:\WINDOWS\system32>ping ::1%0

Pinging ::1 with 32 bytes of data:
Reply from ::1: time<1ms

so I guess interface 0 is the loopback, but it is listed nowhere as such.

> I thought it would only work when you had one (active) interface.

Clearly they don't mimic the Unix/Linux model.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 09:32:57 +1200

Andrew,

> not decoding %25 within the square brackets.

We really need to hear from implementers about this. Assuming that we
have a constructive discussion during the upcoming 6MAN session,
outreach to implementers should be the next step, IMHO.

     Brian

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 9 Jul 2021 22:35:06 +0100

Microsoft seems to have dealt with this problem already:

> https://docs.microsoft.com/en-us/windows/win32/wininet/ip-version-6-support

tl;dr: windows requires "%25" instead of "%" as the scope delimiter.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 9 Jul 2021 23:11:31 +0100

this really is odd. The loopback interface is technically interface 1:

> C:\Users\nick>netsh interface ipv6 show address
> 
> Interface 1: Loopback Pseudo-Interface 1
> 
> Addr Type  DAD State   Valid Life Pref. Life Address
> ---------  ----------- ---------- ---------- ------------------------
> Other      Preferred     infinite   infinite ::1

and:

> C:\Users\nick>route print
> ===========================================================================
> Interface List
>   4...00 xx xx xx xx xx ......Intel(R) 82574L Gigabit Network Connection
>   1...........................Software Loopback Interface 1
> ===========================================================================

and using more up-to-date tools:

> PS C:\WINDOWS\system32> get-netipinterface -InterfaceIndex 1
> 
> ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
> ------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
> 1       Loopback Pseudo-Interface 1     IPv6            4294967295              75 Disabled Connected       ActiveStore
> 1       Loopback Pseudo-Interface 1     IPv4            4294967295              75 Disabled Connected       ActiveStore
> 
> 
> PS C:\WINDOWS\system32> get-netipinterface -InterfaceIndex 0
> get-netipinterface : No MSFT_NetIPInterface objects found with property 'InterfaceIndex' equal to '0'.  Verify the
> value of the property and retry.
> At line:1 char:1
> + get-netipinterface  -InterfaceIndex 0
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : ObjectNotFound: (0:UInt32) [Get-NetIPInterface], CimJobException
>     + FullyQualifiedErrorId : CmdletizationQuery_NotFound_InterfaceIndex,Get-NetIPInterface
> 
> PS C:\WINDOWS\system32>

"ping ::1%0" works, but "ping ::1%1" returns a general failure.  But if 
you attempt to scope a global IP address to the interface ID that the 
fe80: address is tied to, it will also fail.

So, not clear what the scope ID actually refers to here. Someone with 
more windows clue is going to have to answer this one, and you're right 
that there's a fairly deep lack of documentation on how this is supposed 
to work.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Jul 2021 00:00:58 -0400

Nick Hilliard <[email-masked]> wrote:
    >> Pinging ::1 with 32 bytes of data: Reply from ::1: time<1ms
    >>

    > this really is odd. The loopback interface is technically interface 1:

::1 is not a link-local address.
It gets routed as normal, and the scope-id is ignored, I think that "0" the
scope-id which means, "I have no scope"

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 16:14:54 +1200

> tl;dr: windows requires "%25" instead of "%" as the scope delimiter.

Sure, but not everywhere, e.g. not in the "DOS" command prompt. So you get the rather alarming result that in some contexts (e.g. ping) fe80::abcd%25 works if you have an interface #25, but in other contexts you must use [fe80::abcd%2525]. 

I just checked, and Internet Explorer (yes, it lives) does still accept http://[fe80::2e3a:fdff:fea4:dde7%257], but rejects http://[fe80::2e3a:fdff:fea4:dde7%7]. But other browsers on the same machine (including MS Edge) refuse to parse the zone index, of course.

>From the user's PoV this is not ideal.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 16:39:09 +1200

> scope-id which means, "I have no scope"

Correct, but as Nick said Windows seems very odd in this particular corner.

On July 6, 2012, Dave Thaler wrote:

>> You'll see at 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85).aspx
>> that alternative 3 is what is supported in IE7 and above, and the APIs are generally
>> available to Windows applications (i.e. not just IE7).

[Alternative 3 at that time was the %25 encoding]

By a miracle that URL still works but the content was updated in 2018.

Since Edge apparently does not accept the zone index at all, Dave (in Bcc), do you wish to modify your statement from 9 years ago :-?.

   Brian