On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter < [email protected]> wrote:
> 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. "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, > 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. > > 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. > 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. > > And doesn't allow browsing; see above. So I don't like this option. > 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. > > 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. 3) With alternative separator such as _ > > http://[fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: doesn't allow simple cut and paste. > > This is the simplest of the four alternatives. It seems at this point we could just discuss whether "_" is the best alternative. > 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. > > 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- > Thus, the WG has to choose between options 1), 2), 3) and 4). > > Opinions welcome! > > Brian Carpenter > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
