On 29/05/2013 11:57, Michael Sweet wrote: > Brian, > > On 2013-05-28, at 4:38 PM, Brian E Carpenter <brian.e.carpen...@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 <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". >>> 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 --------------------------------------------------------------------
