Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6

[Chuck Lever <chuck.lever@oracle.com>]

On Jun 17, 2009, at 6:06 PM, Jeff Layton wrote:

> On Wed, 17 Jun 2009 14:32:16 -0700
> Chuck Lever <chucklever@gmail.com> wrote:
>
>> On Wed, Jun 17, 2009 at 1:55 PM, Jeff Layton <jlayton@redhat.com>  
>> 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.

RFC 3879, which deprecates site local addresses, does discuss the  
concept of using a scope ID with a site-local address (to distinguish  
which site the address belongs to, as a router could be connected to  
two separate subnets that contain hosts with the same site-local  
address).  The wikipedia page you cite below indicates that the  
administrative oversight for ULAs has not been established yet.  So  
the deprecation may or may not be entirely premature.

Anyway, this is all pretty academic at this point.  By the time we get  
global IPv6 address support working, we may come back to do link-local  
and discover the standards have all been changed again.

> 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.

That's one way to write a scope ID.  Another is to use a device name.   
Scope ID support, such as it is now in the NFS client, supports both.

> 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.


mount.nfs relies on the network layer to do that, I think.  It  
connects a socket to the server address, then scrapes the source  
address off the connected socket.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com