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

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

[Jeff Layton]

On Wed, 17 Jun 2009 12:23:00 -0700
Chuck Lever <chucklever@gmail.com> wrote:

> Still no outgoing e-mail here.  Feel free to copy your reply to
> linux-nfs@vger.kernel.org (as chucklever@gmail.com is not subscribed
> to that list).
> 
> My two major comments are:
> 
> 1.  The CONFIG_IPV6 stuff in 4/4 is pretty messy.  Are you sure you
> need every one of those switches?  And, can you combine some of this
> into helper functions whose definition changes depending on how the
> kernel is built?
> 

Agreed, I'll see what I can do to clean it up.

I could probably eliminate some of the switches. Combining that into
helper functions will lead to a lot of "code sprawl" though (a lot of
little tiny functions).

> 2.  Does this implementation support link-local and site-local
> addresses?  Perhaps that's not important for your initial submission,
> but we should try to ensure that nothing in this design excludes
> support for the local address types.
> 

Site local addresses are considered deprecated but AFAIK, they are
indistinguishable from "normal" IPv6 addresses. 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.

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

-- 
Jeff Layton <jlayton@redhat.com>

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

[Jeff Layton]

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.

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@vger.kernel.org from
non-subscribed addresses.

-- 
Jeff Layton <jlayton@redhat.com>

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

[Chuck Lever]

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

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

[Jeff Layton]

On Wed, 17 Jun 2009 14:47:01 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Wed, Jun 17, 2009 at 02:15:37PM -0400, Jeff Layton wrote:
> > This patchset is a first pass at adding IPv6 callback channel support
> > for knfsd. The set is fairly straightforward, but it does require a
> > number of changes to server side NFSv4 related structs that store
> > addresses in places that are only suitable for IPv4 addresses.
> > 
> > I've tested this by having Linux and OpenSolaris clients mount the
> > server over an IPv6 socket, get a delegation and ensure that the server
> > can recall that delegation. It all seems to work as expected. IPv4
> > callbacks also seem to continue to work correctly.
> > 
> > This patchset does change the some of the new 4.1 functions
> > (nfsd4_exchange_id in particular). Those changes are untested as of yet
> > but I'll see if I can do so if the approach in this set seems
> > reasonable.
> 
> Thanks, just two quick comments:
> 
> 	1. I've been working on the callback code, so check that this
> 	applies against for-2.6.31 (at
> 	git://linux-nfs.org/~bfields/linux.git).

Sorry, I should have made it clear in the original email. This patchset
applies cleanly to your master branch. I just checked and it also
applies cleanly to your for-2.6.31 branch.

> 	2. Any IP address checks in setclientid or exchange_id are
> 	probably bogus; the former should be gone, the latter may still
> 	be there but there'll be a patch queued up for 2.6.31 to fix
> 	that.
> 

There are definitely still IP address comparisons in those functions,
though I confess I didn't look closely at the logic. My main concern
with this set was to move the IPv4 specific address containers to
sockaddr_storage, and to make the comparisons work for alternate
address families. I tried not to alter the logic however.

Thanks,
-- 
Jeff Layton <jlayton@redhat.com>

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

[J. Bruce Fields]

On Wed, Jun 17, 2009 at 02:15:37PM -0400, Jeff Layton wrote:
> This patchset is a first pass at adding IPv6 callback channel support
> for knfsd. The set is fairly straightforward, but it does require a
> number of changes to server side NFSv4 related structs that store
> addresses in places that are only suitable for IPv4 addresses.
> 
> I've tested this by having Linux and OpenSolaris clients mount the
> server over an IPv6 socket, get a delegation and ensure that the server
> can recall that delegation. It all seems to work as expected. IPv4
> callbacks also seem to continue to work correctly.
> 
> This patchset does change the some of the new 4.1 functions
> (nfsd4_exchange_id in particular). Those changes are untested as of yet
> but I'll see if I can do so if the approach in this set seems
> reasonable.

Thanks, just two quick comments:

	1. I've been working on the callback code, so check that this
	applies against for-2.6.31 (at
	git://linux-nfs.org/~bfields/linux.git).
	2. Any IP address checks in setclientid or exchange_id are
	probably bogus; the former should be gone, the latter may still
	be there but there'll be a patch queued up for 2.6.31 to fix
	that.

--b.

> 
> Comments welcome...
> 
> Jeff Layton (4):
>   nfsd: convert nfs4_callback struct to hold address in
>     sockaddr_storage
>   nfsd: break out setclientid port parsing into separate routine
>   nfsd: make nfs4_client->cl_addr a struct sockaddr_storage
>   nfsd: add support for NFSv4 callbacks over IPv6
> 
>  fs/nfsd/nfs4callback.c     |   11 +--
>  fs/nfsd/nfs4state.c        |  220 ++++++++++++++++++++++++++++++++++++-------
>  include/linux/nfsd/state.h |    6 +-
>  3 files changed, 189 insertions(+), 48 deletions(-)
> 

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

[Jeff Layton]

This patchset is a first pass at adding IPv6 callback channel support
for knfsd. The set is fairly straightforward, but it does require a
number of changes to server side NFSv4 related structs that store
addresses in places that are only suitable for IPv4 addresses.

I've tested this by having Linux and OpenSolaris clients mount the
server over an IPv6 socket, get a delegation and ensure that the server
can recall that delegation. It all seems to work as expected. IPv4
callbacks also seem to continue to work correctly.

This patchset does change the some of the new 4.1 functions
(nfsd4_exchange_id in particular). Those changes are untested as of yet
but I'll see if I can do so if the approach in this set seems
reasonable.

Comments welcome...

Jeff Layton (4):
  nfsd: convert nfs4_callback struct to hold address in
    sockaddr_storage
  nfsd: break out setclientid port parsing into separate routine
  nfsd: make nfs4_client->cl_addr a struct sockaddr_storage
  nfsd: add support for NFSv4 callbacks over IPv6

 fs/nfsd/nfs4callback.c     |   11 +--
 fs/nfsd/nfs4state.c        |  220 ++++++++++++++++++++++++++++++++++++-------
 include/linux/nfsd/state.h |    6 +-
 3 files changed, 189 insertions(+), 48 deletions(-)