On Fri, May 24, 2013 at 2:27 PM, Michael Sweet <msw...@apple.com> wrote:
> Christian,
>
> On 2013-05-24, at 1:45 PM, Christian Huitema <huit...@microsoft.com>
> wrote:
> > Can we move from the process discussion to the technical discussion?
> >
> > Michael raised an interesting issue, and we have to analyze it. The
> consensus of the working group so far is that interface identifiers are
> private to the host, that any leakage outside the host should be prevented,
> and that a way to prevent that leakage is to ask proxies to erase them
> whenever they have an opportunity. Michael points that some servers take an
> opposite approach, want to record the interface from which the host called
> them, and want to ensure that further calls in the same session use exactly
> the same interface. That seems that a fairly legitimate debate, and I can
> see two alternatives -- one would be to reaffirm the old guidance and
> provides alternative to ensure session continuity, and the other would be
> to reverse the guidance and accept that the layer violation performed by
> servers is just fine.
>
>
> (the following is printer-centric, but the same applies to network video
> cameras and other embedded network devices)
>
> Some background: HTTP and IPP services in printers include absolute URIs
> in the content they return. For IPP this can be http/https URLs to the
> printer's web page, ICC profiles, and other resources, along with the
> ipp/ipps URIs that the printer supports. For HTTP the most common are https
> URLs for "secure" areas of the printer's web interface. Because a printer
> is often known by multiple names and addresses ("printer.local.", "
> printer.example.com.", 192.168.0.100, fe80::1234, etc.), the
> implementation guidance (and in IPP Everywhere, this is a conformance
> requirement) is that the server use the HTTP Host header provided in the
> request in the host/address field of its responses, subject to the usual
> security considerations (SHOULD validate Host value, etc.) This allows the
> client to use the name or address it can resolve/connect to and makes sure
> that the printer-generated absolute URIs lead back to same printer.
>
> All of this falls apart with link-local addresses and RFC 6874. Because
> the client is required to remove the zoneid from the outgoing request, the
> URIs it gets back from the server are no longer "reachable".
>
> Just so we're clear, I assume this does NOT work today with link-local
IPv6 addresses (because no print client yet
constructs a Host URI with link-local address and zoneID according to RFC
6874)? And you're saying that RFC 6874
does not improve on the current situation?
-K-
What I propose is that we change the wording to allow the zoneid in the
> Host header but not in the Request-URI. HTTP proxies would be required to
> strip any zoneid information in the Host header. HTTP servers would be
> required to ignore any zoneid information for purposes of address
> validation but include it for any absolute URIs to the server they generate.
>
> Thoughts?
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
