On Wed, 17 Jun 2009 14:32:16 -0700 Chuck Lever <chucklever@xxxxxxxxx> wrote: > On Wed, Jun 17, 2009 at 1:55 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > > Site local addresses are considered deprecated but AFAIK, they are > > indistinguishable from "normal" IPv6 addresses. > > > My impression was site-local addresses may also use a scope ID. > I don't think so. Site local addresses are considered routable and should be unique within a "site". I think the intent with them was to provide an address space analogous to RFC 1918 addresses. There should be no need for a scopeid with them since it's not likely that 2 interfaces would have the same subnet ID (doing so would be silly given the large address space) and site-local addresses are not autoconfigured like link-local ones. In any case, site-local is deprecated and is supposedly being replaced by ULA's which are also routable within cooperating sites: http://en.wikipedia.org/wiki/Unique_local_address AFAICT, ULA's also have no need for a scope id. > > > They just have a > > designated prefix which should really only have meaning to routers. I > > don't think that we have to do anything special in order to support > > them. > > > > We really can't reasonably support link-local addresses with this. To > > use a link-local address you need to know the scopeid. That value only > > has meaning within a single host. The client has no way to know what > > scopeid to send to the server, so it can't send that information along > > in the callback address. > > > Right. The callback presentation address string passed via SETCLIENTID is > an RPC universal address, which doesn't have the ability to represent a > scope ID. However, there are ways around this limitation. An incoming > site- or link-local universal address in an RPCB_GETADDR inherits the scope > ID from the address used to send the RPCB_GETADDR request, for example. > Yes, that's the only real way to do that. At the end of the day (at least on linux and windows), scopeid == interface number. A machine will have no idea what the interface number will be in another machine. Therefore that info can only reasonably be filled out by the host that intends to connect to the remote link-local address. What we should probably do here for the server is to make sure that when a SETCLIENTID call comes in, that we can get the number of the interface that received the call and then stuff that info into the scopeid if the clientaddr has a link-local prefix. > > > knfsd *might* be able to look for link-local prefixes and determine the > > scopeid if it knows what interface the connection came in on. I'm not > > clear if that information bubbles up from the RPC layer however. > > > > I don't think there's anything in this work that prevents us from > > adding link local support later, but it'll probably take some research > > and work to determine how to make it happen. > > > > There are client-side implications here too. We'll have to consider how > > to generate callback addresses when the server's address is a > > link-local address (mostly, make sure you use the link-local callback > > address for the correct interface). > > > See mount.nfs. It strips the scope ID off of link-local clientaddr=, and > assumes the server will know how to glue an appropriate scope ID back in. > (Or, it _should_ do that... it probably does something that only > approximates this now). > > That's probably the right thing to do. The only real trick for mount.nfs is to make sure that when the server's address is a link-local addr, that it autogenerates the clientaddr= with the link-local address of the interface that matches the provided scopeid. PS: I think you can post to linux-nfs@xxxxxxxxxxxxxxx from non-subscribed addresses. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
