[IPP] RFC: Link local addresses in URIs, addition for IPP Everywhere

[IPP] RFC: Link local addresses in URIs, addition for IPP Everywhere

Mike Sweet msweet at apple.com
Fri May 11 04:58:42 UTC 2012


Randy,

The main issue is link local, but when you start getting a mix of traditional and multicast host names being used (common for today's network printers) with a new reliance on the information supplied by the printer, it is really important that the client be able to use it... If the printer reports a .local name the the resource won't be accessible from outside the subnet. Similarly, if you get foo.example.com a client might not be able to resolve that if it doesn't have a proper dns server configured...


Sent from my iPad

On May 10, 2012, at 8:48 PM, Randy Turner <rturner at amalfisystems.com> wrote:

> 
> 
> Hi Mike,
> 
> Can you just simplify 1-3 below by saying implementations MUST NOT use literal link-local addresses in URI values?
> 
> Everything else is ok, right?
> 
> Randy
> 
> 
> On May 10, 2012, at 10:59 AM, Michael Sweet wrote:
> 
>> All,
>> 
>> Another issue that has come to light recently is the use of link-local addresses by printers that haven't gotten an IP address from a DHCP server.
>> 
>> To summarize the issue: RFC 3986 does not address how to represent link-local addresses in URIs.  Two separate (and incompatible) methods have been proposed for IPv6 addresses:
>> 
>>     http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt       (expired)
>>     http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01
>> 
>> However, even if one of these methods is eventually adopted it is still impossible for a Printer to advertise the correct URI with a link-local address because zoneid strings are system-specific - they are basically the name of the network interface on the client.
>> 
>> What I'd like to do in IPP Everywhere is:
>> 
>> 1. Add rationale of not using link-local numeric addresses in printer-uri-supported and other URI values: Link-local numeric addresses cannot be represented by the Printer because the zone identifier is specific to the Client and not the Printer.
>> 
>> 2. Add normative requirement: Printers MUST NOT transfer/provide URI values using link-local addresses, SHOULD transfer/provide URIs values using the Host supplied in the Client HTTP request, SHOULD transfer/provide URI values using fully qualified domain names (FQDNs) in preference to numeric addresses, and SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols. Printers MAY advertise multiple printer-uri-supported values to cover all of the configured FQDNs and non-link-local numeric addresses.
>> 
>> 3. Add implementation discussion where the printer can tailor the addresses reported to the Host: value supplied in the client HTTP request; printer-icons, printer-supply-info-uri, printer-more-info are not as flexible as printer-uri-supported, so using the value supplied in the Host HTTP request header is important.
>> 
>> 4. Add security considerations text talking about DNS rebinding attacks - Printers SHOULD NOT allow requests with unknown or invalid Host values, including "localhost".
>> 
>> 5. Add security considerations text referencing security consideration in current mDNS draft.
>> 
>> Thoughts?
>> 
>> __________________________________________________
>> 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.
>> _______________________________________________
>> ipp mailing list
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
> 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean.
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

-- 
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/20120510/1b87680d/attachment-0001.html>


More information about the ipp mailing list