All,
RFC 3986/STD 66 (Uniform Resource Identifier (URI): Generic Syntax) did not define a syntax for specifying IPv6 link-local addresses with zone identifiers (interface names/numbers). Back in 2005, I requested clarification and received the following advice: use the IPvFuture syntax and "+" as a separator between the IPv6 address and Zone ID, for example an IPP URI at address FE80::1234 on interface "en0" would be encoded as follows:
ipp://[v1.fe80::1234+en0]/ipp/print
For IPP Everywhere we require that Clients use this form in the Host: header when submitting a request to a Printer so that the Printer can provide the Client with link-local addresses containing the Client's Zone ID information. This allows referenced URIs in IPP responses to work from the Client, and similarly for URLs in HTML returned by the Printer's Embedded Web Server (EWS).
Fast forward (!) 8 years and now the IETF has finally published an official extension to RFC 3986 titled Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (RFC 6874). Unfortunately, the extension introduces an incompatible new address format (IPv6addrz); for the previous example the URI would be encoded as:
ipp://[fe80::1234%25en0]/ipp/print
However, applications conforming to RFC 3986 will reject this address information since percent-encoding and Zone ID information is not allowed for an IPv6address literal. In particular, all versions of CUPS since 2005 will reject IPv6 link local addresses using this format.
In addition, RFC 6874 introduces some unfortunate conformance requirements: Clients MUST NOT include their Zone ID in URIs or the HTTP Host header for the reason that the Server has no use for the information (!).
I have had some fruitful initial discussions with the IETF Area Directors and the 6man (IPv6) working group chairs about updating this document and will be preparing a replacement for RFC 6874 with review from the PWG IPP WG to ensure that our needs are met. My planned changes are as follows:
1. Add the IPvFuture encoding ([v1.address+zoneid]) as an alternate, backwards-compatible encoding. The new percent-encoded format will still be preferred. Provide implementation guidance with an eye towards backwards-compatibilty.
2. Add use cases and discussion concerning why/when IPv6 link-local addresses are used, and how clients and servers can use the zone ID to provide/generate accessible URIs
3. Modify the current conformance terms to align with our usage in IPP (Host header) and require servers to validate and use the Host value as supplied
In the meantime, please make sure to *NOT* strictly follow RFC 6874 as it will break your printers when used with IPv6 link-local addresses. My recommendation would be to support consumption/use of RFC 6874 URIs but continue to include and accept the Zone ID in the Host header. For printers this means returning URIs using the same format as supplied, i.e. if a Client supplies an RFC 6874 address, return an RFC 6874 URI, otherwise return an RFC 3986 URI.
References:
RFC 3986/STD 66: Uniform Resource Identifier (URI): Generic Syntax
http://tools.ietf.org/html/rfc6874
RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
http://tools.ietf.org/html/rfc6874
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130523/8589d1a6/attachment-0001.html>