Michael,
>> 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".
how is this different from any other application using link-local addresses?
the application has to be 'bound' to the given zone. if a host receives an RA
from a router, it learns the link-local address of the router,
but it locally ties that link-local address to the zone it belongs to.
given that you cannot use link-locals in referrals outside of the correct zone,
why doesn't this also work for your application?
client connects to http:://[fe80::1%Ethernet0/0]
the client has to assume that all embedded URIs with link-local addresses
belong to the same zone that it connected to.
after all they cannot belong to any other zone... the server obviously has to
make sure it never gives out these URIs
to a client connecting using non-link-local addresses multiple hops away.
> 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?
to reword. you need something for which the client gives the server some opaque
information that it can use to identify interface when it gets the embedded
URIs in the reply back?
again I don't understand why the client doesn't know the interface to use
already.
cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
