Re: Strange use of link-local

[Brian E Carpenter <[e-mail]>]

On 29/05/2013 11:57, Michael Sweet wrote:
> Brian,
> 
> On 2013-05-28, at 4:38 PM, Brian E Carpenter <[e-mail]> wrote:
>> I'm increasingly baffled by the use case. If the host is
>> in a context where it can reach a server *and* has more than
>> one interface (such that a ZoneID is needed at all), it
>> shouldn't be using a link local address anyway - it
>> should have configured a global scope address (possibly
>> under a ULA prefix). Discussion of this use case surely
>> belongs in MIF or HOMENET.
> 
> Most hosts (and probably all of the ones we care about) have multiple network interfaces, if only the loopback interface plus some sort of external network interface, forcing the use of the zoneid.  Also, the most common place you would need to use a link-local address for access is the place where global scope addresses are basically never used - the home.
> 
> So I agree that the MIF or HOMENET working groups might have something to say here, but RFC 6874 was published by *this* group and IPv6 link local addresses have broader context than either of the other groups.

Yes, but the limitation of the meaning of the Zone ID to a single
host isn't new; RFC 6874 simply reiterates it. The problem is that
the whole notion of scope is defective as currently defined (hence
http://tools.ietf.org/html/draft-carpenter-referral-ps, which we plan
to come back to when time permits). Today, the only clean fix is
to use a global-scope address, which means a ULA for disconnected
networks.

    Brian

>>    Brian
>>
>> On 29/05/2013 07:34, Ray Hunter wrote:
>>> Warning: post contains dumb questions.
>>>
>>> Michael Sweet wrote:
>>>> Christian,
>>>>
>>>> On 2013-05-24, at 1:45 PM, Christian Huitema <[e-mail]> 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".
>>> Trying to understand what's going on here and what the root problem is.
>>>
>>> I have some dumb questions:
>>>
>>> Is the zoneid in the URI the interface on the client or the server node?
>>>
>>> What does other party learn from this information, since zoneid is
>>> currently defined as being local to the node and has no significance
>>> outside the context of the node?
>>>
>>> If the other party learns nothing, and the originating node just needs
>>> to hear an echo of it's own information for it's own use, what's wrong
>>> with using a cookie (server originated), or a hidden variable (client
>>> originated), to transport this interface information along with the
>>> request/reply?
>>>
>>> What if both the server AND the client have multiple interfaces: how do
>>> they both know which local interface on their own node is mutually
>>> connected and to be used for communication? There's only one single
>>> zoneid in the URI, so presumably one of the nodes is lacking some
>>> information.
>>>
>>> Shouldn't both nodes be using ND to learn this information?
>>> If there's nothing in the cache, try all interfaces?
>>>
>>> regards,
>>> RayH
>>>
>>>> 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
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
>