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

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

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

Ira McDonald blueroofmusic at gmail.com
Thu May 10 23:20:40 UTC 2012


Hi Mike,

I concur w/ this I believe, certainly for IPv6 link-local addresses.

Does this also apply to ZeroConf IPv4 link-local addresses?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Thu, May 10, 2012 at 1:59 PM, Michael Sweet <msweet at apple.com> 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* <http://www.mailscanner.info/>, 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/7b9b4f65/attachment-0001.html>


More information about the ipp mailing list