Subject: Options for draft-ietf-6man-uri-zoneid

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Apr 2012 08:54:16 +0100

Hi,

In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00,
there was no clear consensus on the approach to pursue. In fact,
almost the same discussion occurred around draft-fenner-literal-zone
several years ago, but at that time the topic was simply dropped.

This note summarises the main options. As a reminder, the problem to
be solved is how to tell a browser which interface to use when sending
packets to a literal link-local address. The reason for doing this is
purely for diagnostic purposes, since the Zone ID that identifies an
interface has no significance outside the sending host. For more details,
see the two drafts mentioned above.

What we have today: link local address with no Zone ID
   http://[fe80::a]

The user cannot select the outgoing interface if there is more than one.

The obvious solution would be to use the RFC4007 syntax (for an
example Zone ID of en1):

   http://[fe80::a%en1]

However, this is impossible because % is *always* an escape character in
URI syntax [RFC3986]. There is no chance of the URI community accepting
such a hack to the syntax, so it isn't an option for us.

The available options are therefore

1) Leave the problem unsolved.

This would mean that per-interface diagnostics would still have to be
performed using ping or ping6

   ping fe80::a%en1

Advantage: works today.

Disadvantage: less convenient than using a browswer.

2) Escaping the escape character as allowed by RFC 3986:

   http://[fe80::a%25en1]

Advantage: allows use of browser.
Disadvantage: ugly and confusing, doesn't allow simple cut and paste.

3) With alternative separator such as _

   http://[fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: doesn't allow simple cut and paste.

4) With the "IPvFuture" syntax left open in RFC 3986:

   http://[v6.fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: ugly and redundant, doesn't allow simple cut and paste.

Thus, the WG has to choose between options 1), 2), 3) and 4).

Opinions welcome!

    Brian Carpenter

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 29 Apr 2012 10:29:44 +0200

> Thus, the WG has to choose between options 1), 2), 3) and 4).

If we want to solve this at all, I think 2) is the way to go since
this format is after all easier to understand than format 3) or 4),
which add yet another notation, and also because there might be other
characters in the zone ID that need escaping as well.

And since URLs are used not just by plain good old http and web
browsers, I think we will have to find and document a common solution
for this.

/js

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

---

From: Kerry Lynn <[email-masked]>
Date: Sun, 29 Apr 2012 18:50:46 -0400

On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter <
[email-masked]> wrote:

> interface has no significance outside the sending host.

"Purely" may be overly strong here.  When I mentioned in Paris that
my mom might like to configure her spanking new IPv6 homenet router
using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1,
it was met with much ROTFL'ing.  But hey, my mom is no slouch.

In a more immediate case, people are currently using browsers to connect
to embedded 6LoWPAN web servers.  (Imagine a host with a 6LoWPAN
link on one interface and ethernet on another.)  I use Firefox 3.2x for
this,
because it supports the syntax above just fine.

Are such cases included in the "diagnostic" designation?  It seems not.

For more details,
> Well, this may be a case of "do what we mean, not what we say".   I agree
that "%" is the first octet of pct-encoded, but it's not clear that
pct-encoded
is permissible in all productions.  To wit, ( unreserved / sub-delims / ":"
) and
( unreserved / pct-encoded / sub-delims / ":" ) are apparently not
equivalent.
The basis of some comments in Paris was that escaped chars are currently
not permitted within IP-literal.  But I agree, in the end this may be an un-
winnable battle.

> And doesn't allow browsing; see above.  So I don't like this option.

> Well, if we took a purely *user-centric* approach, then we'd use a
consistent syntax for all utilities.  We have an existence proof (Firefox
3.2x) that demonstrates the desired syntax is possible (and parsible).
This option is just ugly.  If we have to map symbols, I'd rather use a
1:1 mapping than a 1:3 mapping.

> This is the simplest of the four alternatives.  It seems at this point we
could just discuss whether "_" is the best alternative.

> Yikes!  This one just screams OVERSIGHT.  I would frankly prefer
option 1 over having two ways to represent IPv6address.

Thanks, Brian and Bob, for taking this on.

-K-

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Apr 2012 07:51:55 +0100

Kerry,

> Are such cases included in the "diagnostic" designation?  It seems not.

Fair enough, this can easily be wordsmithed.

> not permitted within IP-literal.  But I agree, in the end this may be an un-

Exactly. I don't claim to understand every nook and cranny of the syntax,
but in practice it's unwinnable.

>> And doesn't allow browsing; see above.  So I don't like this option.

Yes, I overlooked that rather obvious disadvantage...

> 1:1 mapping than a 1:3 mapping.

If only we hadn't picked % in the first place...

> Thanks, Brian and Bob, for taking this on.

No problem.

   Brian