My plan is to use an AF_INET listener on systems that support only IPv4,
and an AF_INET6 listener on systems that can support IPv6. Incoming
IPv4 packets will be posted to an AF_INET6 listener with a mapped IPv4
address.
Max Matveev <[email protected]> says:
Creating a single listener can be dangerous - if net.ipv6.bindv6only
is enabled then it's possible to create another listener in v4
namespace on the same port and steal the traffic from the "unifed"
listener. You need to disable V6ONLY explicitly via a sockopt to stop
that.
Set appropriate socket option on RPC server listener sockets to prevent
this.
Signed-off-by: Chuck Lever <[email protected]>
---
net/sunrpc/svcsock.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 3e65719..f91377c 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1114,6 +1114,7 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
struct svc_sock *svsk;
struct sock *inet;
int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
+ int val;
dprintk("svc: svc_setup_socket %p\n", sock);
if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
@@ -1146,6 +1147,18 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
else
svc_tcp_init(svsk, serv);
+ /*
+ * We start one listener per sv_serv. We want AF_INET
+ * requests to be automatically shunted to our AF_INET6
+ * listener using a mapped IPv4 address. Make sure
+ * no-one starts an equivalent IPv4 listener, which
+ * would steal our incoming connections.
+ */
+ val = 0;
+ if (serv->sv_family == AF_INET6)
+ kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
+ (char *)&val, sizeof(val));
+
dprintk("svc: svc_setup_socket created %p (inet %p)\n",
svsk, svsk->sk_sk);
On Thu, Aug 14, 2008 at 04:45:31PM -0400, Chuck Lever wrote:
> On Aug 14, 2008, at 4:38 PM, J. Bruce Fields wrote:
>> On Thu, Aug 14, 2008 at 04:34:14PM -0400, Chuck Lever wrote:
>>> On Aug 14, 2008, at 4:05 PM, J. Bruce Fields wrote:
>>>> On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
>>>>> My plan is to use an AF_INET listener on systems that support only
>>>>> IPv4,
>>>>> and an AF_INET6 listener on systems that can support IPv6. Incoming
>>>>> IPv4 packets will be posted to an AF_INET6 listener with a mapped
>>>>> IPv4
>>>>> address.
>>>>
>>>> How will the nfs server choose whether to use AF_INET or AF_INET6?
>>>> Will
>>>> we need some new user interface?
>>>
>>> [PATCH 2/8] changes svc_create() to take an additional argument which
>>> specifies the listener's address family. This value is stored in
>>> svc_serv.
>>
>> Right, but I'm asking about the nfsd server, not the rpc server, and
>> the
>> user interface, not the in-kernel interface:
>
> Ah. That wasn't clear before.
>
>> so suppose I'm a server
>> administrator, and want my nfs server to listen for ipv6 connections.
>> Will there be some switch I'll need to flip?
>
> I don't know how that UI will be designed. So far, I've focused only on
> the pieces needed for client side IPv6 support. I figured the Bull team
> had something figured out for the server, and didn't think any more about
> it.
I've forgotten who was working on that; Aurelien Charbon?
--b.
>
>>>>> Max Matveev <[email protected]> says:
>>>>> Creating a single listener can be dangerous - if
>>>>> net.ipv6.bindv6only
>>>>> is enabled then it's possible to create another listener in v4
>>>>> namespace on the same port and steal the traffic from the "unifed"
>>>>> listener. You need to disable V6ONLY explicitly via a sockopt to
>>>>> stop
>>>>> that.
>>>>>
>>>>> Set appropriate socket option on RPC server listener sockets to
>>>>> prevent
>>>>> this.
>>>>>
>>>>> Signed-off-by: Chuck Lever <[email protected]>
>>>>> ---
>>>>>
>>>>> net/sunrpc/svcsock.c | 13 +++++++++++++
>>>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>>>>> index 3e65719..f91377c 100644
>>>>> --- a/net/sunrpc/svcsock.c
>>>>> +++ b/net/sunrpc/svcsock.c
>>>>> @@ -1114,6 +1114,7 @@ static struct svc_sock
>>>>> *svc_setup_socket(struct svc_serv *serv,
>>>>> struct svc_sock *svsk;
>>>>> struct sock *inet;
>>>>> int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
>>>>> + int val;
>>>>>
>>>>> dprintk("svc: svc_setup_socket %p\n", sock);
>>>>> if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
>>>>> @@ -1146,6 +1147,18 @@ static struct svc_sock
>>>>> *svc_setup_socket(struct svc_serv *serv,
>>>>> else
>>>>> svc_tcp_init(svsk, serv);
>>>>>
>>>>> + /*
>>>>> + * We start one listener per sv_serv. We want AF_INET
>>>>> + * requests to be automatically shunted to our AF_INET6
>>>>> + * listener using a mapped IPv4 address. Make sure
>>>>> + * no-one starts an equivalent IPv4 listener, which
>>>>> + * would steal our incoming connections.
>>>>> + */
>>>>> + val = 0;
>>>>> + if (serv->sv_family == AF_INET6)
>>>>> + kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
>>>>> + (char *)&val, sizeof(val));
>>>>> +
>>>>> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
>>>>> svsk, svsk->sk_sk);
>>>>>
>>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Bruce Fields a =E9crit :
>On Thu, Aug 14, 2008 at 04:45:31PM -0400, Chuck Lever wrote:
> =20
>
>>On Aug 14, 2008, at 4:38 PM, J. Bruce Fields wrote:
>> =20
>>
>>>On Thu, Aug 14, 2008 at 04:34:14PM -0400, Chuck Lever wrote:
>>> =20
>>>
>>>>On Aug 14, 2008, at 4:05 PM, J. Bruce Fields wrote:
>>>> =20
>>>>
>>>>>On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
>>>>> =20
>>>>>
>>>>>>My plan is to use an AF_INET listener on systems that support onl=
y
>>>>>>IPv4,
>>>>>>and an AF_INET6 listener on systems that can support IPv6. Incomi=
ng
>>>>>>IPv4 packets will be posted to an AF_INET6 listener with a mapped
>>>>>>IPv4
>>>>>>address.
>>>>>> =20
>>>>>>
>>>>>How will the nfs server choose whether to use AF_INET or AF_INET6?
>>>>>Will
>>>>>we need some new user interface?
>>>>> =20
>>>>>
>>>>[PATCH 2/8] changes svc_create() to take an additional argument whi=
ch
>>>>specifies the listener's address family. This value is stored in
>>>>svc_serv.
>>>> =20
>>>>
>>>Right, but I'm asking about the nfsd server, not the rpc server, and=
=20
>>>the
>>>user interface, not the in-kernel interface:
>>> =20
>>>
>>Ah. That wasn't clear before.
>>
>> =20
>>
>>>so suppose I'm a server
>>>administrator, and want my nfs server to listen for ipv6 connections=
=2E
>>>Will there be some switch I'll need to flip?
>>> =20
>>>
>>I don't know how that UI will be designed. So far, I've focused only=
on=20
>>the pieces needed for client side IPv6 support. I figured the Bull t=
eam=20
>>had something figured out for the server, and didn't think any more a=
bout=20
>>it.
>> =20
>>
>
>I've forgotten who was working on that; Aurelien Charbon?
> =20
>
Hi,
Sorry for not answering before, I am back from vacation.
Aurelien is no longer directly working on that even he can answer any=20
questions.
It is me now who tess NFSV4 IPV6 with the patches Aurelien delivered=20
to Bruce a few months ago.
But since Chuck has delivered several new patches which affect
the NFS server side about the way nfsd can listen for ipv6 connections.
To have NFSV4 IPV6 working with those changes, what it would be nice=20
to have a complete list
on what are the changes.
Is there now a complete release for which we can test those latest=20
changes? If not which one will be?
Are there any other changes still planned?
Best Regards
>--b.
>
> =20
>
>>>>>>Max Matveev <[email protected]> says:
>>>>>>Creating a single listener can be dangerous - if =20
>>>>>>net.ipv6.bindv6only
>>>>>>is enabled then it's possible to create another listener in v4
>>>>>>namespace on the same port and steal the traffic from the "unifed=
"
>>>>>>listener. You need to disable V6ONLY explicitly via a sockopt to
>>>>>>stop
>>>>>>that.
>>>>>>
>>>>>>Set appropriate socket option on RPC server listener sockets to
>>>>>>prevent
>>>>>>this.
>>>>>>
>>>>>>Signed-off-by: Chuck Lever <[email protected]>
>>>>>>---
>>>>>>
>>>>>>net/sunrpc/svcsock.c | 13 +++++++++++++
>>>>>>1 files changed, 13 insertions(+), 0 deletions(-)
>>>>>>
>>>>>>diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>>>>>>index 3e65719..f91377c 100644
>>>>>>--- a/net/sunrpc/svcsock.c
>>>>>>+++ b/net/sunrpc/svcsock.c
>>>>>>@@ -1114,6 +1114,7 @@ static struct svc_sock
>>>>>>*svc_setup_socket(struct svc_serv *serv,
>>>>>> struct svc_sock *svsk;
>>>>>> struct sock *inet;
>>>>>> int pmap_register =3D !(flags & SVC_SOCK_ANONYMOUS);
>>>>>>+ int val;
>>>>>>
>>>>>> dprintk("svc: svc_setup_socket %p\n", sock);
>>>>>> if (!(svsk =3D kzalloc(sizeof(*svsk), GFP_KERNEL))) {
>>>>>>@@ -1146,6 +1147,18 @@ static struct svc_sock
>>>>>>*svc_setup_socket(struct svc_serv *serv,
>>>>>> else
>>>>>> svc_tcp_init(svsk, serv);
>>>>>>
>>>>>>+ /*
>>>>>>+ * We start one listener per sv_serv. We want AF_INET
>>>>>>+ * requests to be automatically shunted to our AF_INET6
>>>>>>+ * listener using a mapped IPv4 address. Make sure
>>>>>>+ * no-one starts an equivalent IPv4 listener, which
>>>>>>+ * would steal our incoming connections.
>>>>>>+ */
>>>>>>+ val =3D 0;
>>>>>>+ if (serv->sv_family =3D=3D AF_INET6)
>>>>>>+ kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
>>>>>>+ (char *)&val, sizeof(val));
>>>>>>+
>>>>>> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
>>>>>> svsk, svsk->sk_sk);
>>>>>>
>>>>>>
>>>>>> =20
>>>>>>
>>>>--
>>>>Chuck Lever
>>>>chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>--
>>Chuck Lever
>>chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
>>the body of a message to [email protected]
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>> =20
>>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" i=
n
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> =20
>
--=20
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (http://www.bull.com)
Name : Aime Le Rouzic=20
Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail : [email protected]
Phone : 33 (4) 76.29.75.51
=46ax : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20
> J. Bruce Fields a =C3=A9crit :
>>>> so suppose I'm a server
>>>> administrator, and want my nfs server to listen for ipv6 connectio=
ns.
>>>> Will there be some switch I'll need to flip?
>> On Thu, Aug 14, 2008 at 04:45:31PM -0400, Chuck Lever wrote:
>>> I don't know how that UI will be designed. So far, I've focused on=
ly=20
>>> on the pieces needed for client side IPv6 support. I figured the=20
>>> Bull team had something figured out for the server, and didn't thin=
k=20
>>> any more about it.
>>
>> I've forgotten who was working on that; Aurelien Charbon?
On Thu, Aug 21, 2008 at 02:11:49PM +0200, Le Rouzic wrote:
> Sorry for not answering before, I am back from vacation. Aurelien is
> no longer directly working on that even he can answer any questions.
> It is me now who tess NFSV4 IPV6 with the patches Aurelien delivered
> to Bruce a few months ago. But since Chuck has delivered several new
> patches which affect the NFS server side about the way nfsd can liste=
n
> for ipv6 connections.
I merged the last patch I can remember from Aurelien (f15364bd "IPv6
support for NFS server export caches"). Are there some others floating
around that I should look at?
> To have NFSV4 IPV6 working with those changes, what it would be nice
> to have a complete list on what are the changes. Is there now a
> complete release for which we can test those latest changes? If not
> which one will be? Are there any other changes still planned?
I was hoping you or Chuck would know; I don't know of anyone else
working on nfs over ipv6.
--b.
J. Bruce Fields a =C3=A9crit :
>>J. Bruce Fields a =C3=A9crit :
>> =20
>>
>>>>>so suppose I'm a server
>>>>>administrator, and want my nfs server to listen for ipv6 connectio=
ns.
>>>>>Will there be some switch I'll need to flip?
>>>>> =20
>>>>>
>
> =20
>
>>>On Thu, Aug 14, 2008 at 04:45:31PM -0400, Chuck Lever wrote:
>>> =20
>>>
>>>>I don't know how that UI will be designed. So far, I've focused on=
ly=20
>>>>on the pieces needed for client side IPv6 support. I figured the=20
>>>>Bull team had something figured out for the server, and didn't thin=
k=20
>>>>any more about it.
>>>> =20
>>>>
>>>I've forgotten who was working on that; Aurelien Charbon?
>>> =20
>>>
>
>On Thu, Aug 21, 2008 at 02:11:49PM +0200, Le Rouzic wrote:
> =20
>
>>Sorry for not answering before, I am back from vacation. Aurelien is
>>no longer directly working on that even he can answer any questions.
>>It is me now who tess NFSV4 IPV6 with the patches Aurelien delivered
>>to Bruce a few months ago. But since Chuck has delivered several new
>>patches which affect the NFS server side about the way nfsd can liste=
n
>>for ipv6 connections.
>> =20
>>
>
>I merged the last patch I can remember from Aurelien (f15364bd "IPv6
>support for NFS server export caches"). Are there some others floatin=
g
>around that I should look at?
>
> =20
>
>> To have NFSV4 IPV6 working with those changes, what it would be nice
>> to have a complete list on what are the changes. Is there now a
>> complete release for which we can test those latest changes? If not
>> which one will be? Are there any other changes still planned?
>> =20
>>
>
>I was hoping you or Chuck would know; I don't know of anyone else
>working on nfs over ipv6.
> =20
>
Hi,
About changes I was talking about changes introduced for IPv6 RPC=20
services via rpcbind
at least thoses published on the 19th on this mailing list can be=20
considered like the last
ones.
Cheers
>--b.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" i=
n
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> =20
>
--=20
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (http://www.bull.com)
Name : Aime Le Rouzic=20
Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail : [email protected]
Phone : 33 (4) 76.29.75.51
=46ax : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20
On Thu, Aug 21, 2008 at 11:32 AM, Le Rouzic <[email protected]> w=
rote:
> J. Bruce Fields a =E9crit :
>
>>> J. Bruce Fields a =E9crit :
>>>
>>>>>>
>>>>>> so suppose I'm a server
>>>>>> administrator, and want my nfs server to listen for ipv6 connect=
ions.
>>>>>> Will there be some switch I'll need to flip?
>>>>>>
>>
>>
>>>>
>>>> On Thu, Aug 14, 2008 at 04:45:31PM -0400, Chuck Lever wrote:
>>>>
>>>>>
>>>>> I don't know how that UI will be designed. So far, I've focused =
only
>>>>> on the pieces needed for client side IPv6 support. I figured the=
Bull team
>>>>> had something figured out for the server, and didn't think any mo=
re about
>>>>> it.
>>>>>
>>>>
>>>> I've forgotten who was working on that; Aurelien Charbon?
>>>>
>>
>> On Thu, Aug 21, 2008 at 02:11:49PM +0200, Le Rouzic wrote:
>>
>>>
>>> Sorry for not answering before, I am back from vacation. Aurelien =
is
>>> no longer directly working on that even he can answer any question=
s.
>>> It is me now who tess NFSV4 IPV6 with the patches Aurelien delivere=
d
>>> to Bruce a few months ago. But since Chuck has delivered several n=
ew
>>> patches which affect the NFS server side about the way nfsd can lis=
ten
>>> for ipv6 connections.
>>>
>>
>> I merged the last patch I can remember from Aurelien (f15364bd "IPv6
>> support for NFS server export caches"). Are there some others float=
ing
>> around that I should look at?
>>
>>
>>>
>>> To have NFSV4 IPV6 working with those changes, what it would be nic=
e
>>> to have a complete list on what are the changes. Is there now a
>>> complete release for which we can test those latest changes? If no=
t
>>> which one will be? Are there any other changes still planned?
>>>
>>
>> I was hoping you or Chuck would know; I don't know of anyone else
>> working on nfs over ipv6.
>>
>
> Hi,
> About changes I was talking about changes introduced for IPv6 RPC ser=
vices
> via rpcbind
> at least thoses published on the 19th on this mailing list can be con=
sidered
> like the last ones.
My complete IPv6 patch set is available here:
http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
The tags that start "cel-ipv6-..." contain the IPv6-related patches.
I see the latest one is still two weeks old, so I should update it
with what I sent to Bruce recently.
--=20
Chuck Lever
On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
> My plan is to use an AF_INET listener on systems that support only IPv4,
> and an AF_INET6 listener on systems that can support IPv6. Incoming
> IPv4 packets will be posted to an AF_INET6 listener with a mapped IPv4
> address.
How will the nfs server choose whether to use AF_INET or AF_INET6? Will
we need some new user interface?
--b.
>
> Max Matveev <[email protected]> says:
> Creating a single listener can be dangerous - if net.ipv6.bindv6only
> is enabled then it's possible to create another listener in v4
> namespace on the same port and steal the traffic from the "unifed"
> listener. You need to disable V6ONLY explicitly via a sockopt to stop
> that.
>
> Set appropriate socket option on RPC server listener sockets to prevent
> this.
>
> Signed-off-by: Chuck Lever <[email protected]>
> ---
>
> net/sunrpc/svcsock.c | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 3e65719..f91377c 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -1114,6 +1114,7 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
> struct svc_sock *svsk;
> struct sock *inet;
> int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
> + int val;
>
> dprintk("svc: svc_setup_socket %p\n", sock);
> if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
> @@ -1146,6 +1147,18 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
> else
> svc_tcp_init(svsk, serv);
>
> + /*
> + * We start one listener per sv_serv. We want AF_INET
> + * requests to be automatically shunted to our AF_INET6
> + * listener using a mapped IPv4 address. Make sure
> + * no-one starts an equivalent IPv4 listener, which
> + * would steal our incoming connections.
> + */
> + val = 0;
> + if (serv->sv_family == AF_INET6)
> + kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
> + (char *)&val, sizeof(val));
> +
> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
> svsk, svsk->sk_sk);
>
>
On Aug 14, 2008, at 4:05 PM, J. Bruce Fields wrote:
> On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
>> My plan is to use an AF_INET listener on systems that support only
>> IPv4,
>> and an AF_INET6 listener on systems that can support IPv6. Incoming
>> IPv4 packets will be posted to an AF_INET6 listener with a mapped
>> IPv4
>> address.
>
> How will the nfs server choose whether to use AF_INET or AF_INET6?
> Will
> we need some new user interface?
[PATCH 2/8] changes svc_create() to take an additional argument which
specifies the listener's address family. This value is stored in
svc_serv.
>> Max Matveev <[email protected]> says:
>> Creating a single listener can be dangerous - if net.ipv6.bindv6only
>> is enabled then it's possible to create another listener in v4
>> namespace on the same port and steal the traffic from the "unifed"
>> listener. You need to disable V6ONLY explicitly via a sockopt to
>> stop
>> that.
>>
>> Set appropriate socket option on RPC server listener sockets to
>> prevent
>> this.
>>
>> Signed-off-by: Chuck Lever <[email protected]>
>> ---
>>
>> net/sunrpc/svcsock.c | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>> index 3e65719..f91377c 100644
>> --- a/net/sunrpc/svcsock.c
>> +++ b/net/sunrpc/svcsock.c
>> @@ -1114,6 +1114,7 @@ static struct svc_sock
>> *svc_setup_socket(struct svc_serv *serv,
>> struct svc_sock *svsk;
>> struct sock *inet;
>> int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
>> + int val;
>>
>> dprintk("svc: svc_setup_socket %p\n", sock);
>> if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
>> @@ -1146,6 +1147,18 @@ static struct svc_sock
>> *svc_setup_socket(struct svc_serv *serv,
>> else
>> svc_tcp_init(svsk, serv);
>>
>> + /*
>> + * We start one listener per sv_serv. We want AF_INET
>> + * requests to be automatically shunted to our AF_INET6
>> + * listener using a mapped IPv4 address. Make sure
>> + * no-one starts an equivalent IPv4 listener, which
>> + * would steal our incoming connections.
>> + */
>> + val = 0;
>> + if (serv->sv_family == AF_INET6)
>> + kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
>> + (char *)&val, sizeof(val));
>> +
>> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
>> svsk, svsk->sk_sk);
>>
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Thu, Aug 14, 2008 at 04:34:14PM -0400, Chuck Lever wrote:
> On Aug 14, 2008, at 4:05 PM, J. Bruce Fields wrote:
>> On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
>>> My plan is to use an AF_INET listener on systems that support only
>>> IPv4,
>>> and an AF_INET6 listener on systems that can support IPv6. Incoming
>>> IPv4 packets will be posted to an AF_INET6 listener with a mapped
>>> IPv4
>>> address.
>>
>> How will the nfs server choose whether to use AF_INET or AF_INET6?
>> Will
>> we need some new user interface?
>
> [PATCH 2/8] changes svc_create() to take an additional argument which
> specifies the listener's address family. This value is stored in
> svc_serv.
Right, but I'm asking about the nfsd server, not the rpc server, and the
user interface, not the in-kernel interface: so suppose I'm a server
administrator, and want my nfs server to listen for ipv6 connections.
Will there be some switch I'll need to flip?
--b.
>
>>> Max Matveev <[email protected]> says:
>>> Creating a single listener can be dangerous - if net.ipv6.bindv6only
>>> is enabled then it's possible to create another listener in v4
>>> namespace on the same port and steal the traffic from the "unifed"
>>> listener. You need to disable V6ONLY explicitly via a sockopt to
>>> stop
>>> that.
>>>
>>> Set appropriate socket option on RPC server listener sockets to
>>> prevent
>>> this.
>>>
>>> Signed-off-by: Chuck Lever <[email protected]>
>>> ---
>>>
>>> net/sunrpc/svcsock.c | 13 +++++++++++++
>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>>> index 3e65719..f91377c 100644
>>> --- a/net/sunrpc/svcsock.c
>>> +++ b/net/sunrpc/svcsock.c
>>> @@ -1114,6 +1114,7 @@ static struct svc_sock
>>> *svc_setup_socket(struct svc_serv *serv,
>>> struct svc_sock *svsk;
>>> struct sock *inet;
>>> int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
>>> + int val;
>>>
>>> dprintk("svc: svc_setup_socket %p\n", sock);
>>> if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
>>> @@ -1146,6 +1147,18 @@ static struct svc_sock
>>> *svc_setup_socket(struct svc_serv *serv,
>>> else
>>> svc_tcp_init(svsk, serv);
>>>
>>> + /*
>>> + * We start one listener per sv_serv. We want AF_INET
>>> + * requests to be automatically shunted to our AF_INET6
>>> + * listener using a mapped IPv4 address. Make sure
>>> + * no-one starts an equivalent IPv4 listener, which
>>> + * would steal our incoming connections.
>>> + */
>>> + val = 0;
>>> + if (serv->sv_family == AF_INET6)
>>> + kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
>>> + (char *)&val, sizeof(val));
>>> +
>>> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
>>> svsk, svsk->sk_sk);
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
On Aug 14, 2008, at 4:38 PM, J. Bruce Fields wrote:
> On Thu, Aug 14, 2008 at 04:34:14PM -0400, Chuck Lever wrote:
>> On Aug 14, 2008, at 4:05 PM, J. Bruce Fields wrote:
>>> On Wed, Aug 13, 2008 at 06:39:54PM -0400, Chuck Lever wrote:
>>>> My plan is to use an AF_INET listener on systems that support only
>>>> IPv4,
>>>> and an AF_INET6 listener on systems that can support IPv6. Incoming
>>>> IPv4 packets will be posted to an AF_INET6 listener with a mapped
>>>> IPv4
>>>> address.
>>>
>>> How will the nfs server choose whether to use AF_INET or AF_INET6?
>>> Will
>>> we need some new user interface?
>>
>> [PATCH 2/8] changes svc_create() to take an additional argument which
>> specifies the listener's address family. This value is stored in
>> svc_serv.
>
> Right, but I'm asking about the nfsd server, not the rpc server, and
> the
> user interface, not the in-kernel interface:
Ah. That wasn't clear before.
> so suppose I'm a server
> administrator, and want my nfs server to listen for ipv6 connections.
> Will there be some switch I'll need to flip?
I don't know how that UI will be designed. So far, I've focused only
on the pieces needed for client side IPv6 support. I figured the Bull
team had something figured out for the server, and didn't think any
more about it.
>>>> Max Matveev <[email protected]> says:
>>>> Creating a single listener can be dangerous - if
>>>> net.ipv6.bindv6only
>>>> is enabled then it's possible to create another listener in v4
>>>> namespace on the same port and steal the traffic from the "unifed"
>>>> listener. You need to disable V6ONLY explicitly via a sockopt to
>>>> stop
>>>> that.
>>>>
>>>> Set appropriate socket option on RPC server listener sockets to
>>>> prevent
>>>> this.
>>>>
>>>> Signed-off-by: Chuck Lever <[email protected]>
>>>> ---
>>>>
>>>> net/sunrpc/svcsock.c | 13 +++++++++++++
>>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>>>> index 3e65719..f91377c 100644
>>>> --- a/net/sunrpc/svcsock.c
>>>> +++ b/net/sunrpc/svcsock.c
>>>> @@ -1114,6 +1114,7 @@ static struct svc_sock
>>>> *svc_setup_socket(struct svc_serv *serv,
>>>> struct svc_sock *svsk;
>>>> struct sock *inet;
>>>> int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
>>>> + int val;
>>>>
>>>> dprintk("svc: svc_setup_socket %p\n", sock);
>>>> if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
>>>> @@ -1146,6 +1147,18 @@ static struct svc_sock
>>>> *svc_setup_socket(struct svc_serv *serv,
>>>> else
>>>> svc_tcp_init(svsk, serv);
>>>>
>>>> + /*
>>>> + * We start one listener per sv_serv. We want AF_INET
>>>> + * requests to be automatically shunted to our AF_INET6
>>>> + * listener using a mapped IPv4 address. Make sure
>>>> + * no-one starts an equivalent IPv4 listener, which
>>>> + * would steal our incoming connections.
>>>> + */
>>>> + val = 0;
>>>> + if (serv->sv_family == AF_INET6)
>>>> + kernel_setsockopt(sock, SOL_IPV6, IPV6_V6ONLY,
>>>> + (char *)&val, sizeof(val));
>>>> +
>>>> dprintk("svc: svc_setup_socket created %p (inet %p)\n",
>>>> svsk, svsk->sk_sk);
>>>>
>>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com