attachment-0001
Hi Mike,<br><br>I concur w/ this I believe, certainly for IPv6 link-local addresses.<br><br>Does this also apply to ZeroConf IPv4 link-local addresses?<br><br>Cheers,<br>- Ira<br><br><br clear="all">Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div><br>
<br><br><div class="gmail_quote">On Thu, May 10, 2012 at 1:59 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">All,<div><br></div><div>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.</div><div><br>
</div><div>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:</div><div><br></div><div> <a href="http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt" target="_blank">http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt</a> (expired)</div>
<div> <a href="http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01" target="_blank">http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01</a></div><div><br></div><div>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.</div>
<div><br></div><div>What I'd like to do in IPP Everywhere is:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>4. Add security considerations text talking about DNS rebinding attacks - Printers SHOULD NOT allow requests with unknown or invalid Host values, including "localhost".</div><div><br></div><div>
5. Add security considerations text referencing security consideration in current mDNS draft.</div><div><br></div><div>Thoughts?</div><div><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div>__________________________________________________</div><div style="font-family:Helvetica">Michael Sweet, Senior Printing System Engineer, PWG Chair<span class="HOEnZb"><font color="#888888"><br>
</font></span></div></span><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br></font></span></div><span class="HOEnZb"><font color="#888888"><br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</font></span></div>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></div><br>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.