Brian, On 2013-08-27, at 4:33 PM, Brian E Carpenter <[email protected]> wrote: > Michael, > > I don't know where the decision to use this syntax in CUPS > (IPv6addrz = IPv6address "%25" ZoneID / "v1." IPv6address "+" ZoneID) > was debated - I don't think it was here, and I don't generally > follow the URI discussions. My opinion, fwiw, is that the "IPvFuture" > branch invented by the URI people (again without any discussion here, > iirc) is exactly the sort of vague extensibility that we should avoid > (RFC 6709).
I contacted the authors of RFC 3986 back in 2005 and got the following response from Bill Fenner: > From: Bill Fenner <[email protected]> > Message-Id: <[email protected]> > Subject: RE: RFC 3986 and IPv6 Link-Local Addresses > Date: Fri, 21 Oct 2005 11:05:05 -0700 > > > >See http://lists.w3.org/Archives/Public/uri/2004Nov/0056.html > >and following discussion. > > Also http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt . > Mike's examples were the first ones we thought of, but even using > [v1...], %-escaping is still not permitted, thus requiring a different > character. The current I-D says "_", but we realized that was no good > when we saw it on a web page and the underlining of the URL obscured > the underscore. I've tentatively picked "+", e.g., > ipp://[v1.fe80::200:1234:5678:9abc+eth0]/ipp > > The document was adopted as an IPv6 WG work item but I missed the -00 > deadline for submitting it, so I'll be submitting a revised version > as draft-fenner-literal-zone-02.txt this weekend. > > Bill The code to support this was added to CUPS about a day later and has been the recommended method of supporting IPv6 link-local addresses for IPP printers since then (although we naturally prefer DNS/mDNS names over numeric addresses...) However, this draft did not advance any further, and since I wasn't monitoring the 6man WG I completely missed the subsequent work that became RFC 6874... > The other thing you should realise is that the URI people were already > quite annoyed by the RFC 6874 update, which took a lot of persuasion. > Going back to them with another formal syntax change would be a very > hard slog. Understood. > That said, documenting something that is actually used, even if it's > a formal syntax violation, is always a good thing. I think your path > of least resistance is a short informational RFC describing the > practice adopted in CUPS. Well, *technically* the syntax is already allowed by RFC 3986 (the IPvFuture rule in the ABNF) even if the content of a "v1" address string was never formally defined. Thus, a parser will be able to extract the address string even if the application using it doesn't understand the format. (I know I'm mincing bits here...) But I have no objection to making this an Informational RFC and rewriting the draft to simply reference RFC 6874 if you think it will be an easier "sell". > However, I don't think we should change the formal statement that > a ZoneID must not be sent out on the wire; again, documenting the > practice may be advisable, but encouraging it certainly isn't, > for the reasons given in the Security Considerations of RFC 6874. So WRT the security considerations in RFC 6784, I agree with everything up to the last paragraph. Regardless of whether clients strip the zone ID, HTTP servers that validate the Host header already need to special-case link-local addresses when comparing the incoming address to any of its own, and that code can easily be written to avoid the security issues identified in RFC 4007. However, RFC 6874 puts the burden entirely on the client, both to strip IPv6 link-local addresses *and* retain such information as long as is needed to rewrite URIs in the response from the server. Allowing the client to include the zone ID (and explaining why a client might do so) simplifies client code with no added burden to the server. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
