> Michael Sweet <mailto:msw...@apple.com> > 29 May 2013 01:27 > Ray, > > On 2013-05-28, at 3:34 PM, Ray Hunter <v6...@globis.net> wrote: >> Warning: post contains dumb questions. > > No such thing! :) > >>> ... >>> 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? > > It is the interface on the client. ACK.
So the server's CGI script echoes the HTTP request header field "Host" set by the client browser back to the client in the URI so that when the link to the next request is clicked at the client's browser (or interpreted by another app on the client), it knows which local interface to use to reach the server again? Where's the standard that says ZoneID MUST be included in the Host header? I presume this is rfc2616#page-128. And the value of "Host" is always set to the host portion of the original URI [which will currently include a ZoneID on current implementations]? Do you think that 6874 mandates that the ZoneID MUST be stripped from the "Host" HTTP request header, as Host is sub-string of a URI? > >> 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? > > The only thing it learns is "this is the address the client is using to talk > to me". ACK. >> 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? > > Well, for starters none of that is standardized, whereas "Host" is a required > HTTP request header that printers (and web servers) already support. > > Also, passing the information back from the server in a cookie doesn't > address the client-sde URI rewriting problem: it is much simpler (and less > error prone) for the server to use the client-supplied address for the URIs > in its response than for the client to parse and rewrite all of the URIs in > the server's response. ACK. >> 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. > > The server knows its own link-local addresses and doesn't need the zoneid > information. I don't understand this logic. I'm presuming the outbound interface for replies is being selected by mirroring the inbound addresses of the request [quoting RFC6724: "In many cases, this is trivially dealt with by an application using the source address of a received packet as the response destination and the destination address of the received packet as the response source."] However I thought one of the use cases was the printer sending unsolicited information such as "out of paper". How would the server then select its correct local outbound interface, if it had multiple? Does the client supply a "callback address/port" that the printer stores/caches? > For the use case under discussion, the client only knows its zoneid > information because the user/administrator has supplied it along with the > printer's link-local address. Right. That was going to be my next question. How does the very first URI learn the correct ZoneID in the first place? Manually. >> Shouldn't both nodes be using ND to learn this information? >> If there's nothing in the cache, try all interfaces? > > > It would be awesome if printers supported Neighbor Discovery, but of the four > printers in my home office only three support IPv6 and only one supports ND. > One of the IPv6 printers is 3 years old, the other three are less than a year > old... Understood. > > On the client side you'll find a similar story - sporadic support, and in > many cases the ND information isn't wired into the resolver libraries, making > it impossible to use a bare IPv6 link-local address without the zoneid added > at the end... > > _________________________________________________________ > 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 --------------------------------------------------------------------
