Subject: Fwd: New Version Notification for draft-sweet-uri-zoneid-00.txt

From: Michael Sweet <[email-masked]>
Date: Tue, 27 Aug 2013 11:59:26 -0400

All,

This is my promised ID that updates RFC 6874 to add the IPvFuture syntax that was adopted from the previous, abandoned draft on this subject (back in 2005) and is implemented widely in clients and printers, and also updates the HTTP conformance requirements and guidance to include the client's zone ID in requests sent to the server (so that the server can generate link-local URIs the client can actually use...)

Comments welcome...

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-sweet-uri-zoneid-00.txt
> Date: 27 August, 2013 11:55:38 AM EDT
> To: Stuart Cheshire <[email-masked]>, Michael Sweet <[email-masked]>, "Robert M. Hinden" <[email-masked]>, Brian Carpenter <[email-masked]>
> 
> 
> A new version of I-D, draft-sweet-uri-zoneid-00.txt
> has been successfully submitted by Michael Sweet and posted to the
> IETF repository.
> 
> Filename:	 draft-sweet-uri-zoneid
> Revision:	 00
> Title:		 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
> Creation date:	 2013-08-27
> Group:		 Individual Submission
> Number of pages: 11
> URL:             http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid
> Htmlized:        http://tools.ietf.org/html/draft-sweet-uri-zoneid-00
> 
> 
> 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.
> 
>   [ Editor's note: This draft adds the IPvFuture format used by CUPS
>   since 2005, addresses some misconceptions of how zoneid's are not
>   useful to HTTP servers, and is intended to replace RFC 6874. ]
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Aug 2013 08:33:18 +1200

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

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.

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.

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.

Regards
   Brian

On 28/08/2013 03:59, Michael Sweet wrote:
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Sweet <[email-masked]>
Date: Tue, 27 Aug 2013 21:24:38 -0400

Brian,

I contacted the authors of RFC 3986 back in 2005 and got the following response from Bill Fenner:

> From: Bill Fenner <[email-masked]>
> Message-Id: <[email-masked]>
> 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...

> Going back to them with another formal syntax change would be a very

Understood.

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

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