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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to