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".
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
--------------------------------------------------------------------
