* Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 [not found] ` <76bd70e30906171223r1f286d0eg1e64510f106d3027-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-06-17 20:55 ` Jeff Layton [not found] ` <76bd70e30906171432m29b3f179y6d0f2111e205114c@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Jeff Layton @ 2009-06-17 20:55 UTC (permalink / raw) To: Chuck Lever; +Cc: linux-nfs 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <76bd70e30906171432m29b3f179y6d0f2111e205114c@mail.gmail.com>]
[parent not found: <76bd70e30906171432m29b3f179y6d0f2111e205114c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 [not found] ` <76bd70e30906171432m29b3f179y6d0f2111e205114c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-06-18 1:06 ` Jeff Layton [not found] ` <20090617210623.4c7860fb-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Jeff Layton @ 2009-06-18 1:06 UTC (permalink / raw) To: Chuck Lever; +Cc: linux-nfs 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20090617210623.4c7860fb-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>]
* Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 [not found] ` <20090617210623.4c7860fb-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org> @ 2009-06-18 4:28 ` Chuck Lever 0 siblings, 0 replies; 6+ messages in thread From: Chuck Lever @ 2009-06-18 4:28 UTC (permalink / raw) To: Jeff Layton; +Cc: Linux NFS Mailing list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 @ 2009-06-17 18:15 Jeff Layton 2009-06-17 18:47 ` J. Bruce Fields 0 siblings, 1 reply; 6+ messages in thread From: Jeff Layton @ 2009-06-17 18:15 UTC (permalink / raw) To: linux-nfs; +Cc: chuck.lever, bfields 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(-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 2009-06-17 18:15 Jeff Layton @ 2009-06-17 18:47 ` J. Bruce Fields 2009-06-17 19:01 ` Jeff Layton 0 siblings, 1 reply; 6+ messages in thread From: J. Bruce Fields @ 2009-06-17 18:47 UTC (permalink / raw) To: Jeff Layton; +Cc: linux-nfs, chuck.lever 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(-) > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 2009-06-17 18:47 ` J. Bruce Fields @ 2009-06-17 19:01 ` Jeff Layton 0 siblings, 0 replies; 6+ messages in thread From: Jeff Layton @ 2009-06-17 19:01 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-nfs, chuck.lever 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-18 4:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <76bd70e30906171223r1f286d0eg1e64510f106d3027@mail.gmail.com> [not found] ` <76bd70e30906171223r1f286d0eg1e64510f106d3027-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2009-06-17 20:55 ` [PATCH 0/4] nfsd: add support for NFSv4 callbacks over IPv6 Jeff Layton [not found] ` <76bd70e30906171432m29b3f179y6d0f2111e205114c@mail.gmail.com> [not found] ` <76bd70e30906171432m29b3f179y6d0f2111e205114c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2009-06-18 1:06 ` Jeff Layton [not found] ` <20090617210623.4c7860fb-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org> 2009-06-18 4:28 ` Chuck Lever 2009-06-17 18:15 Jeff Layton 2009-06-17 18:47 ` J. Bruce Fields 2009-06-17 19:01 ` Jeff Layton
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.