'Re: Strange use of link-local'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Strange use of link-local
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2013-05-29 21:46:04
Message-ID: 51A6771C.5030805 () gmail ! com
[Download RAW message or body]

On 29/05/2013 11:57, Michael Sweet wrote:
> Brian,
> 
> On 2013-05-28, at 4:38 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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 <huitema@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".
> > > 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
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > > 
> 
> _________________________________________________________
> 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
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread] 