Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

Hi-

Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.

I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.

>> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
> 
> I still don't like that last sentence.

Can you say why?

While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.

Other comments:

  o "rdma6" is not supported, and should not be explicitly listed.

  o "mountproto=rdma[6]" is not supported.

  o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 8087 bytes --]

On Wed, 3 Oct 2012 21:15:16 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi-
> 
> Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.
> 
> I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.
> 
> >> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
> > 
> > I still don't like that last sentence.
> 
> Can you say why?

Its meaning is not at all clear.  It tells me that some set of circumstances
will "force the use of IPv4 or IPv6 networking" - given that their isn't
really any other sort of networking (except maybe RDMA?), I'm not at all
surprised that it will either use IPv4 or IPv6.  But the sentence doesn't
tell me how the netid has anything to do with this obvious outcome.

Even if I'm generous and understand that some specific netids will force IPv4
while other specific netids will force IPv6 (and conveniently forget that
'rdma' won't force either), this is true whether the NFS server is
dual-stack, or has either possible single stack.  So the introductory clause
it irrelevant to the conclusion.

> 
> While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.
> 
> Other comments:
> 
>   o "rdma6" is not supported, and should not be explicitly listed.

Even though support/nfs/getport.c mentioned it...
OK, I'll remove that.  I was assuming it might be close given that nfs-utils
seemed to support it, but apparently not.

> 
>   o "mountproto=rdma[6]" is not supported.
> 
>   o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."

It does work ...
I guess if I change it to "Supported options" rather than "Available options"
I can bring my self to remove those two...

Is this worth an acked-by yet :-)

Thanks,
NeilBrown

From d960e53f3271b9bc1d398d13aee856c4a675df81 Mon Sep 17 00:00:00 2001
From: Neil Brown <neilb@suse.de>
Date: Tue, 2 Oct 2012 15:21:46 +1000
Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
 'transport'

The mount option "proto=" actually set the "transport" which in
netconfig usage is the paring of a protocol (e.g. UDP, TCP) with
a protocol family (e.g. INET, INET6).

This can cause confusion if people naively except "proto=udp" to work
equally well on IPv6.

So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
clarify this.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index da6d6d3..1eeba80 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -1,5 +1,5 @@
 .\"@(#)nfs.5"
-.TH NFS 5 "2 November 2007"
+.TH NFS 5 "19 September 2012"
 .SH NAME
 nfs \- fstab format and options for the
 .B nfs
@@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
 for NFS versions 2 and 3 only.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-The value "rdma" may also be specified.
-If the
-.B mount.nfs
-command does not have TI-RPC support, then
+The
 .I netid
-is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Available options are
+.BR udp ", " udp6 ", "tcp ", " tcp6 ", and " rdma .
+Those which end in
+.B 6
+use IPv6 addresses and are only available if support for TI-RPC is
+built in. Others use IPv4 addresses.
 .IP
 Each transport protocol uses different default
 .B retrans
@@ -573,15 +564,14 @@ The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server's mountd service when performing
 this mount request, and when later unmounting this mount point.
 .IP
-If support for TI-RPC is built into the
+.I netid
+may be one of
+.BR udp ", " tcp ", and " rdma
+which use IPv4 address or, if TI-RPC is built into the
 .B mount.nfs
 command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
-.I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+.BR udp6 ", " tcp6 ", and " rdma6
+which use IPv6 addresses.
 .IP
 This option can be used when mounting an NFS server
 through a firewall that blocks a particular transport.
@@ -773,21 +763,15 @@ Use these options, along with the options in the first subsection above,
 for NFS version 4 and newer.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
+The
 .I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Supported options are
+.BR tcp ", " tcp6 ", and" rdma .
+Those which end in
+.B 6
+use IPv6 addresses and are only available if support for TI-RPC is
+built in. Others use IPv4 addresses.
 .IP
 All NFS version 4 servers are required to support TCP,
 so if this mount option is not specified, the NFS version 4 client
@@ -851,6 +835,8 @@ The DATA AND METADATA COHERENCE section discusses
 the behavior of this option in more detail.
 .TP 1.5i
 .BI clientaddr= n.n.n.n
+.TP 1.5i
+.BI clientaddr= n:n: ... :n
 Specifies a single IPv4 address (in dotted-quad form),
 or a non-link-local IPv6 address,
 that the NFS client advertises to allow servers
diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
index 12a3fe7..2258296 100644
--- a/utils/mount/nfsmount.conf.man
+++ b/utils/mount/nfsmount.conf.man
@@ -1,5 +1,5 @@
 .\"@(#)nfsmount.conf.5"
-.TH NFSMOUNT.CONF 5 "9 Mar 2008"
+.TH NFSMOUNT.CONF 5 "19 September 2012"
 .SH NAME
 nfsmount.conf - Configuration file for NFS mounts
 .SH SYNOPSIS
@@ -18,6 +18,10 @@ to particular variables using the
 .BR = 
 operator, as in 
 .BR Proto=Tcp .
+The variables that can be assigned are exactly the set of NFS specific
+mount options listed in
+.BR nfs (5).
+.PP
 Sections are broken up into three basic categories:
 Global options, Server options and Mount Point options.
 .HP
@@ -54,7 +58,7 @@ are defined in the configuration file.
     Proto=Tcp
 .RS
 .HP
-The TCP protocol will be used on every NFS mount.
+The TCP/IPv4 protocol will be used on every NFS mount.
 .HP
 .RE
 [ Server \(lqnfsserver.foo.com\(rq ]
@@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
     rsize=32k
 .br
     wsize=32k
+.br
+    proto=udp6
 .HP
 .RS
-A 33k (32768 bytes) block size will be used as the read and write
-size on all mounts to the 'nfsserver.foo.com' server.
+A 32k (32768 bytes) block size will be used as the read and write
+size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
+is the protocol to be used.
 .HP
 .RE
 .BR 



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

On Oct 7, 2012, at 11:35 PM, NeilBrown wrote:

> On Wed, 3 Oct 2012 21:15:16 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> Hi-
>> 
>> Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.
>> 
>> I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.
>> 
>>>> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
>>> 
>>> I still don't like that last sentence.
>> 
>> Can you say why?
> 
> Its meaning is not at all clear.  It tells me that some set of circumstances
> will "force the use of IPv4 or IPv6 networking" - given that their isn't
> really any other sort of networking (except maybe RDMA?), I'm not at all
> surprised that it will either use IPv4 or IPv6.  But the sentence doesn't
> tell me how the netid has anything to do with this obvious outcome.
> 
> Even if I'm generous and understand that some specific netids will force IPv4
> while other specific netids will force IPv6 (and conveniently forget that
> 'rdma' won't force either), this is true whether the NFS server is
> dual-stack, or has either possible single stack.  So the introductory clause
> it irrelevant to the conclusion.

Clarifying the last sentence would be less work than rewriting that whole paragraph.

Incidentally, "rdma" does force IPv4.  NFS/RDMA targets are identified by their IP address and a special port (20049).

> 
>> 
>> While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.
>> 
>> Other comments:
>> 
>>  o "rdma6" is not supported, and should not be explicitly listed.
> 
> Even though support/nfs/getport.c mentioned it...
> OK, I'll remove that.  I was assuming it might be close given that nfs-utils
> seemed to support it, but apparently not.

The issue is when the RDMA transport in the kernel will support IPv6.  Since no one is working on adding IPv6 support, it's not likely to happen soon.  The "rmda6" netid support in getport.c is merely for completeness.

> 
>> 
>>  o "mountproto=rdma[6]" is not supported.
>> 
>>  o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."
> 
> It does work ...
> I guess if I change it to "Supported options" rather than "Available options"
> I can bring my self to remove those two...

> Is this worth an acked-by yet :-)

I'm not happy about any of the proto= changes, but it's not worth arguing about.  Thanks for the opportunity to comment.  But see below.  You forgot to fix "mountproto=," that really does have to be fixed.

> Thanks,
> NeilBrown
> 
> From d960e53f3271b9bc1d398d13aee856c4a675df81 Mon Sep 17 00:00:00 2001
> From: Neil Brown <neilb@suse.de>
> Date: Tue, 2 Oct 2012 15:21:46 +1000
> Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
> 'transport'
> 
> The mount option "proto=" actually set the "transport" which in
> netconfig usage is the paring of a protocol (e.g. UDP, TCP) with

"pairing"

> a protocol family (e.g. INET, INET6).
> 
> This can cause confusion if people naively except "proto=udp" to work
> equally well on IPv6.
> 
> So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
> clarify this.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index da6d6d3..1eeba80 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfs.5"
> -.TH NFS 5 "2 November 2007"
> +.TH NFS 5 "19 September 2012"
> .SH NAME
> nfs \- fstab format and options for the
> .B nfs
> @@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
> for NFS versions 2 and 3 only.
> .TP 1.5i
> .BI proto= netid
> -The transport protocol name and protocol family the NFS client uses
> -to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> -.IP
> -If support for TI-RPC is built into the
> -.B mount.nfs
> -command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -The value "rdma" may also be specified.
> -If the
> -.B mount.nfs
> -command does not have TI-RPC support, then
> +The
> .I netid
> -is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
> +determines the transport that is used to communicate with the NFS
> +server.  Available options are
> +.BR udp ", " udp6 ", "tcp ", " tcp6 ", and " rdma .
> +Those which end in
> +.B 6
> +use IPv6 addresses and are only available if support for TI-RPC is
> +built in. Others use IPv4 addresses.
> .IP
> Each transport protocol uses different default
> .B retrans
> @@ -573,15 +564,14 @@ The transport protocol name and protocol family the NFS client uses
> to transmit requests to the NFS server's mountd service when performing
> this mount request, and when later unmounting this mount point.

Given your earlier objections, shouldn't this patch replace "transport protocol name and protocol family" in the same way that you've changed the other "proto=" language?

> .IP
> -If support for TI-RPC is built into the
> +.I netid
> +may be one of
> +.BR udp ", " tcp ", and " rdma

Again, "mountproto=rdma" is not supported.  Neither user space nor the kernel is prepared to perform a MNT operation on an RDMA transport.

> +which use IPv4 address or, if TI-RPC is built into the
> .B mount.nfs
> command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -Otherwise,
> -.I netid
> -is one of "tcp" or "udp," and only IPv4 may be used.
> +.BR udp6 ", " tcp6 ", and " rdma6
> +which use IPv6 addresses.
> .IP
> This option can be used when mounting an NFS server
> through a firewall that blocks a particular transport.
> @@ -773,21 +763,15 @@ Use these options, along with the options in the first subsection above,
> for NFS version 4 and newer.
> .TP 1.5i
> .BI proto= netid
> -The transport protocol name and protocol family the NFS client uses
> -to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> -.IP
> -If support for TI-RPC is built into the
> -.B mount.nfs
> -command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -Otherwise,
> +The
> .I netid
> -is one of "tcp" or "udp," and only IPv4 may be used.
> +determines the transport that is used to communicate with the NFS
> +server.  Supported options are
> +.BR tcp ", " tcp6 ", and" rdma .
> +Those which end in
> +.B 6
> +use IPv6 addresses and are only available if support for TI-RPC is
> +built in. Others use IPv4 addresses.
> .IP
> All NFS version 4 servers are required to support TCP,
> so if this mount option is not specified, the NFS version 4 client
> @@ -851,6 +835,8 @@ The DATA AND METADATA COHERENCE section discusses
> the behavior of this option in more detail.
> .TP 1.5i
> .BI clientaddr= n.n.n.n
> +.TP 1.5i
> +.BI clientaddr= n:n: ... :n
> Specifies a single IPv4 address (in dotted-quad form),
> or a non-link-local IPv6 address,
> that the NFS client advertises to allow servers
> diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
> index 12a3fe7..2258296 100644
> --- a/utils/mount/nfsmount.conf.man
> +++ b/utils/mount/nfsmount.conf.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfsmount.conf.5"
> -.TH NFSMOUNT.CONF 5 "9 Mar 2008"
> +.TH NFSMOUNT.CONF 5 "19 September 2012"
> .SH NAME
> nfsmount.conf - Configuration file for NFS mounts
> .SH SYNOPSIS
> @@ -18,6 +18,10 @@ to particular variables using the
> .BR = 
> operator, as in 
> .BR Proto=Tcp .
> +The variables that can be assigned are exactly the set of NFS specific
> +mount options listed in
> +.BR nfs (5).
> +.PP
> Sections are broken up into three basic categories:
> Global options, Server options and Mount Point options.
> .HP
> @@ -54,7 +58,7 @@ are defined in the configuration file.
>     Proto=Tcp
> .RS
> .HP
> -The TCP protocol will be used on every NFS mount.
> +The TCP/IPv4 protocol will be used on every NFS mount.
> .HP
> .RE
> [ Server \(lqnfsserver.foo.com\(rq ]
> @@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
>     rsize=32k
> .br
>     wsize=32k
> +.br
> +    proto=udp6
> .HP
> .RS
> -A 33k (32768 bytes) block size will be used as the read and write
> -size on all mounts to the 'nfsserver.foo.com' server.
> +A 32k (32768 bytes) block size will be used as the read and write
> +size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
> +is the protocol to be used.
> .HP
> .RE
> .BR 
> 
> 

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 9358 bytes --]

On Mon, 8 Oct 2012 11:51:29 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Oct 7, 2012, at 11:35 PM, NeilBrown wrote:
> 
> > On Wed, 3 Oct 2012 21:15:16 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:
> > 
> >> Hi-
> >> 
> >> Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.
> >> 
> >> I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.
> >> 
> >>>> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
> >>> 
> >>> I still don't like that last sentence.
> >> 
> >> Can you say why?
> > 
> > Its meaning is not at all clear.  It tells me that some set of circumstances
> > will "force the use of IPv4 or IPv6 networking" - given that their isn't
> > really any other sort of networking (except maybe RDMA?), I'm not at all
> > surprised that it will either use IPv4 or IPv6.  But the sentence doesn't
> > tell me how the netid has anything to do with this obvious outcome.
> > 
> > Even if I'm generous and understand that some specific netids will force IPv4
> > while other specific netids will force IPv6 (and conveniently forget that
> > 'rdma' won't force either), this is true whether the NFS server is
> > dual-stack, or has either possible single stack.  So the introductory clause
> > it irrelevant to the conclusion.
> 
> Clarifying the last sentence would be less work than rewriting that whole paragraph.
> 
> Incidentally, "rdma" does force IPv4.  NFS/RDMA targets are identified by their IP address and a special port (20049).
> 
> > 
> >> 
> >> While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.
> >> 
> >> Other comments:
> >> 
> >>  o "rdma6" is not supported, and should not be explicitly listed.
> > 
> > Even though support/nfs/getport.c mentioned it...
> > OK, I'll remove that.  I was assuming it might be close given that nfs-utils
> > seemed to support it, but apparently not.
> 
> The issue is when the RDMA transport in the kernel will support IPv6.  Since no one is working on adding IPv6 support, it's not likely to happen soon.  The "rmda6" netid support in getport.c is merely for completeness.
> 
> > 
> >> 
> >>  o "mountproto=rdma[6]" is not supported.
> >> 
> >>  o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."
> > 
> > It does work ...
> > I guess if I change it to "Supported options" rather than "Available options"
> > I can bring my self to remove those two...
> 
> > Is this worth an acked-by yet :-)
> 
> I'm not happy about any of the proto= changes, but it's not worth arguing about.  Thanks for the opportunity to comment.  But see below.  You forgot to fix "mountproto=," that really does have to be fixed.
> 

Thanks for your patience.  Sorry I missed the mountproto=rdma changes you
mentioned earlier - I've fixed that up now, as well as addressing your other
suggestion.

Thanks,
NeilBrown

From 0210f5c0cebd884335d2ced5cb3e680d9821e951 Mon Sep 17 00:00:00 2001
From: Neil Brown <neilb@suse.de>
Date: Tue, 2 Oct 2012 15:21:46 +1000
Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
 'transport'

The mount option "proto=" actually set the "transport" which in
netconfig usage is the pairing of a protocol (e.g. UDP, TCP) with
a protocol family (e.g. INET, INET6).

This can cause confusion if people naively except "proto=udp" to work
equally well on IPv6.

So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
clarify this.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index da6d6d3..d04e272 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -1,5 +1,5 @@
 .\"@(#)nfs.5"
-.TH NFS 5 "2 November 2007"
+.TH NFS 5 "9 October 2012"
 .SH NAME
 nfs \- fstab format and options for the
 .B nfs
@@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
 for NFS versions 2 and 3 only.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-The value "rdma" may also be specified.
-If the
-.B mount.nfs
-command does not have TI-RPC support, then
+The
 .I netid
-is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Available options are
+.BR udp ", " udp6 ", "tcp ", " tcp6 ", and " rdma .
+Those which end in
+.B 6
+use IPv6 addresses and are only available if support for TI-RPC is
+built in. Others use IPv4 addresses.
 .IP
 Each transport protocol uses different default
 .B retrans
@@ -569,19 +560,18 @@ This option can be used when mounting an NFS server
 through a firewall that blocks the rpcbind protocol.
 .TP 1.5i
 .BI mountproto= netid
-The transport protocol name and protocol family the NFS client uses
+The transport the NFS client uses
 to transmit requests to the NFS server's mountd service when performing
 this mount request, and when later unmounting this mount point.
 .IP
-If support for TI-RPC is built into the
+.I netid
+may be one of
+.BR udp ", and " tcp
+which use IPv4 address or, if TI-RPC is built into the
 .B mount.nfs
 command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
-.I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+.BR udp6 ", and " tcp6
+which use IPv6 addresses.
 .IP
 This option can be used when mounting an NFS server
 through a firewall that blocks a particular transport.
@@ -773,21 +763,14 @@ Use these options, along with the options in the first subsection above,
 for NFS version 4 and newer.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
+The
 .I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Supported options are
+.BR tcp ", " tcp6 ", and " rdma .
+.B tcp6
+use IPv6 addresses and is only available if support for TI-RPC is
+built in. Both others use IPv4 addresses.
 .IP
 All NFS version 4 servers are required to support TCP,
 so if this mount option is not specified, the NFS version 4 client
@@ -851,6 +834,8 @@ The DATA AND METADATA COHERENCE section discusses
 the behavior of this option in more detail.
 .TP 1.5i
 .BI clientaddr= n.n.n.n
+.TP 1.5i
+.BI clientaddr= n:n: ... :n
 Specifies a single IPv4 address (in dotted-quad form),
 or a non-link-local IPv6 address,
 that the NFS client advertises to allow servers
diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
index 12a3fe7..2258296 100644
--- a/utils/mount/nfsmount.conf.man
+++ b/utils/mount/nfsmount.conf.man
@@ -1,5 +1,5 @@
 .\"@(#)nfsmount.conf.5"
-.TH NFSMOUNT.CONF 5 "9 Mar 2008"
+.TH NFSMOUNT.CONF 5 "9 October 2012"
 .SH NAME
 nfsmount.conf - Configuration file for NFS mounts
 .SH SYNOPSIS
@@ -18,6 +18,10 @@ to particular variables using the
 .BR = 
 operator, as in 
 .BR Proto=Tcp .
+The variables that can be assigned are exactly the set of NFS specific
+mount options listed in
+.BR nfs (5).
+.PP
 Sections are broken up into three basic categories:
 Global options, Server options and Mount Point options.
 .HP
@@ -54,7 +58,7 @@ are defined in the configuration file.
     Proto=Tcp
 .RS
 .HP
-The TCP protocol will be used on every NFS mount.
+The TCP/IPv4 protocol will be used on every NFS mount.
 .HP
 .RE
 [ Server \(lqnfsserver.foo.com\(rq ]
@@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
     rsize=32k
 .br
     wsize=32k
+.br
+    proto=udp6
 .HP
 .RS
-A 33k (32768 bytes) block size will be used as the read and write
-size on all mounts to the 'nfsserver.foo.com' server.
+A 32k (32768 bytes) block size will be used as the read and write
+size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
+is the protocol to be used.
 .HP
 .RE
 .BR 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

On Oct 8, 2012, at 7:48 PM, NeilBrown wrote:

> On Mon, 8 Oct 2012 11:51:29 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> 
>> On Oct 7, 2012, at 11:35 PM, NeilBrown wrote:
>> 
>>> On Wed, 3 Oct 2012 21:15:16 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:
>>> 
>>>> Hi-
>>>> 
>>>> Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.
>>>> 
>>>> I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.
>>>> 
>>>>>> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
>>>>> 
>>>>> I still don't like that last sentence.
>>>> 
>>>> Can you say why?
>>> 
>>> Its meaning is not at all clear.  It tells me that some set of circumstances
>>> will "force the use of IPv4 or IPv6 networking" - given that their isn't
>>> really any other sort of networking (except maybe RDMA?), I'm not at all
>>> surprised that it will either use IPv4 or IPv6.  But the sentence doesn't
>>> tell me how the netid has anything to do with this obvious outcome.
>>> 
>>> Even if I'm generous and understand that some specific netids will force IPv4
>>> while other specific netids will force IPv6 (and conveniently forget that
>>> 'rdma' won't force either), this is true whether the NFS server is
>>> dual-stack, or has either possible single stack.  So the introductory clause
>>> it irrelevant to the conclusion.
>> 
>> Clarifying the last sentence would be less work than rewriting that whole paragraph.
>> 
>> Incidentally, "rdma" does force IPv4.  NFS/RDMA targets are identified by their IP address and a special port (20049).
>> 
>>> 
>>>> 
>>>> While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.
>>>> 
>>>> Other comments:
>>>> 
>>>> o "rdma6" is not supported, and should not be explicitly listed.
>>> 
>>> Even though support/nfs/getport.c mentioned it...
>>> OK, I'll remove that.  I was assuming it might be close given that nfs-utils
>>> seemed to support it, but apparently not.
>> 
>> The issue is when the RDMA transport in the kernel will support IPv6.  Since no one is working on adding IPv6 support, it's not likely to happen soon.  The "rmda6" netid support in getport.c is merely for completeness.
>> 
>>> 
>>>> 
>>>> o "mountproto=rdma[6]" is not supported.
>>>> 
>>>> o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."
>>> 
>>> It does work ...
>>> I guess if I change it to "Supported options" rather than "Available options"
>>> I can bring my self to remove those two...
>> 
>>> Is this worth an acked-by yet :-)
>> 
>> I'm not happy about any of the proto= changes, but it's not worth arguing about.  Thanks for the opportunity to comment.  But see below.  You forgot to fix "mountproto=," that really does have to be fixed.
>> 
> 
> Thanks for your patience.  Sorry I missed the mountproto=rdma changes you
> mentioned earlier - I've fixed that up now, as well as addressing your other
> suggestion.

Acked-by: Chuck Lever <chuck.lever@oracle.com>

> Thanks,
> NeilBrown
> 
> From 0210f5c0cebd884335d2ced5cb3e680d9821e951 Mon Sep 17 00:00:00 2001
> From: Neil Brown <neilb@suse.de>
> Date: Tue, 2 Oct 2012 15:21:46 +1000
> Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
> 'transport'
> 
> The mount option "proto=" actually set the "transport" which in
> netconfig usage is the pairing of a protocol (e.g. UDP, TCP) with
> a protocol family (e.g. INET, INET6).
> 
> This can cause confusion if people naively except "proto=udp" to work
> equally well on IPv6.
> 
> So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
> clarify this.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index da6d6d3..d04e272 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfs.5"
> -.TH NFS 5 "2 November 2007"
> +.TH NFS 5 "9 October 2012"
> .SH NAME
> nfs \- fstab format and options for the
> .B nfs
> @@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
> for NFS versions 2 and 3 only.
> .TP 1.5i
> .BI proto= netid
> -The transport protocol name and protocol family the NFS client uses
> -to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> -.IP
> -If support for TI-RPC is built into the
> -.B mount.nfs
> -command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -The value "rdma" may also be specified.
> -If the
> -.B mount.nfs
> -command does not have TI-RPC support, then
> +The
> .I netid
> -is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
> +determines the transport that is used to communicate with the NFS
> +server.  Available options are
> +.BR udp ", " udp6 ", "tcp ", " tcp6 ", and " rdma .
> +Those which end in
> +.B 6
> +use IPv6 addresses and are only available if support for TI-RPC is
> +built in. Others use IPv4 addresses.
> .IP
> Each transport protocol uses different default
> .B retrans
> @@ -569,19 +560,18 @@ This option can be used when mounting an NFS server
> through a firewall that blocks the rpcbind protocol.
> .TP 1.5i
> .BI mountproto= netid
> -The transport protocol name and protocol family the NFS client uses
> +The transport the NFS client uses
> to transmit requests to the NFS server's mountd service when performing
> this mount request, and when later unmounting this mount point.
> .IP
> -If support for TI-RPC is built into the
> +.I netid
> +may be one of
> +.BR udp ", and " tcp
> +which use IPv4 address or, if TI-RPC is built into the
> .B mount.nfs
> command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -Otherwise,
> -.I netid
> -is one of "tcp" or "udp," and only IPv4 may be used.
> +.BR udp6 ", and " tcp6
> +which use IPv6 addresses.
> .IP
> This option can be used when mounting an NFS server
> through a firewall that blocks a particular transport.
> @@ -773,21 +763,14 @@ Use these options, along with the options in the first subsection above,
> for NFS version 4 and newer.
> .TP 1.5i
> .BI proto= netid
> -The transport protocol name and protocol family the NFS client uses
> -to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> -.IP
> -If support for TI-RPC is built into the
> -.B mount.nfs
> -command,
> -.I netid
> -is a valid netid listed in
> -.IR /etc/netconfig .
> -Otherwise,
> +The
> .I netid
> -is one of "tcp" or "udp," and only IPv4 may be used.
> +determines the transport that is used to communicate with the NFS
> +server.  Supported options are
> +.BR tcp ", " tcp6 ", and " rdma .
> +.B tcp6
> +use IPv6 addresses and is only available if support for TI-RPC is
> +built in. Both others use IPv4 addresses.
> .IP
> All NFS version 4 servers are required to support TCP,
> so if this mount option is not specified, the NFS version 4 client
> @@ -851,6 +834,8 @@ The DATA AND METADATA COHERENCE section discusses
> the behavior of this option in more detail.
> .TP 1.5i
> .BI clientaddr= n.n.n.n
> +.TP 1.5i
> +.BI clientaddr= n:n: ... :n
> Specifies a single IPv4 address (in dotted-quad form),
> or a non-link-local IPv6 address,
> that the NFS client advertises to allow servers
> diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
> index 12a3fe7..2258296 100644
> --- a/utils/mount/nfsmount.conf.man
> +++ b/utils/mount/nfsmount.conf.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfsmount.conf.5"
> -.TH NFSMOUNT.CONF 5 "9 Mar 2008"
> +.TH NFSMOUNT.CONF 5 "9 October 2012"
> .SH NAME
> nfsmount.conf - Configuration file for NFS mounts
> .SH SYNOPSIS
> @@ -18,6 +18,10 @@ to particular variables using the
> .BR = 
> operator, as in 
> .BR Proto=Tcp .
> +The variables that can be assigned are exactly the set of NFS specific
> +mount options listed in
> +.BR nfs (5).
> +.PP
> Sections are broken up into three basic categories:
> Global options, Server options and Mount Point options.
> .HP
> @@ -54,7 +58,7 @@ are defined in the configuration file.
>     Proto=Tcp
> .RS
> .HP
> -The TCP protocol will be used on every NFS mount.
> +The TCP/IPv4 protocol will be used on every NFS mount.
> .HP
> .RE
> [ Server \(lqnfsserver.foo.com\(rq ]
> @@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
>     rsize=32k
> .br
>     wsize=32k
> +.br
> +    proto=udp6
> .HP
> .RS
> -A 33k (32768 bytes) block size will be used as the read and write
> -size on all mounts to the 'nfsserver.foo.com' server.
> +A 32k (32768 bytes) block size will be used as the read and write
> +size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
> +is the protocol to be used.
> .HP
> .RE
> .BR 

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Tue, 9 Oct 2012 11:01:32 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:


> > Thanks for your patience.  Sorry I missed the mountproto=rdma changes you
> > mentioned earlier - I've fixed that up now, as well as addressing your other
> > suggestion.
> 
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
> 

Thanks!  I've sent it off to Steve.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Steve Dickson]

On 09/10/12 11:01, Chuck Lever wrote:
> 
> On Oct 8, 2012, at 7:48 PM, NeilBrown wrote:
> 
>> On Mon, 8 Oct 2012 11:51:29 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>>>
>>> On Oct 7, 2012, at 11:35 PM, NeilBrown wrote:
>>>
>>>> On Wed, 3 Oct 2012 21:15:16 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>
>>>>> Hi-
>>>>>
>>>>> Unfortunately our corporate e-mail server lost your e-mail from yesterday.  I read it last night and was going to reply this morning, but it was gone from my mailbox.  I'm not sure how to preserve the thread structure at this point.
>>>>>
>>>>> I'm OK with the nfsmount.conf() changes, and the addition of IPv6 syntax to the clientaddr= option.
>>>>>
>>>>>>> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.
>>>>>>
>>>>>> I still don't like that last sentence.
>>>>>
>>>>> Can you say why?
>>>>
>>>> Its meaning is not at all clear.  It tells me that some set of circumstances
>>>> will "force the use of IPv4 or IPv6 networking" - given that their isn't
>>>> really any other sort of networking (except maybe RDMA?), I'm not at all
>>>> surprised that it will either use IPv4 or IPv6.  But the sentence doesn't
>>>> tell me how the netid has anything to do with this obvious outcome.
>>>>
>>>> Even if I'm generous and understand that some specific netids will force IPv4
>>>> while other specific netids will force IPv6 (and conveniently forget that
>>>> 'rdma' won't force either), this is true whether the NFS server is
>>>> dual-stack, or has either possible single stack.  So the introductory clause
>>>> it irrelevant to the conclusion.
>>>
>>> Clarifying the last sentence would be less work than rewriting that whole paragraph.
>>>
>>> Incidentally, "rdma" does force IPv4.  NFS/RDMA targets are identified by their IP address and a special port (20049).
>>>
>>>>
>>>>>
>>>>> While that sentence could be made more precise, this is one of the key reasons NFS with netids works the way it does.  Dual-stack NFS servers will be pervasive for some time to come.
>>>>>
>>>>> Other comments:
>>>>>
>>>>> o "rdma6" is not supported, and should not be explicitly listed.
>>>>
>>>> Even though support/nfs/getport.c mentioned it...
>>>> OK, I'll remove that.  I was assuming it might be close given that nfs-utils
>>>> seemed to support it, but apparently not.
>>>
>>> The issue is when the RDMA transport in the kernel will support IPv6.  Since no one is working on adding IPv6 support, it's not likely to happen soon.  The "rmda6" netid support in getport.c is merely for completeness.
>>>
>>>>
>>>>>
>>>>> o "mountproto=rdma[6]" is not supported.
>>>>>
>>>>> o We discourage the use of UDP with NFSv4 (in fact it may no longer be supported).  The NFSv4 proto= language should not list "udp" or "udp6."
>>>>
>>>> It does work ...
>>>> I guess if I change it to "Supported options" rather than "Available options"
>>>> I can bring my self to remove those two...
>>>
>>>> Is this worth an acked-by yet :-)
>>>
>>> I'm not happy about any of the proto= changes, but it's not worth arguing about.  Thanks for the opportunity to comment.  But see below.  You forgot to fix "mountproto=," that really does have to be fixed.
>>>
>>
>> Thanks for your patience.  Sorry I missed the mountproto=rdma changes you
>> mentioned earlier - I've fixed that up now, as well as addressing your other
>> suggestion.
> 
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
Committed..

steved.
> 
>> Thanks,
>> NeilBrown
>>
>> From 0210f5c0cebd884335d2ced5cb3e680d9821e951 Mon Sep 17 00:00:00 2001
>> From: Neil Brown <neilb@suse.de>
>> Date: Tue, 2 Oct 2012 15:21:46 +1000
>> Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
>> 'transport'
>>
>> The mount option "proto=" actually set the "transport" which in
>> netconfig usage is the pairing of a protocol (e.g. UDP, TCP) with
>> a protocol family (e.g. INET, INET6).
>>
>> This can cause confusion if people naively except "proto=udp" to work
>> equally well on IPv6.
>>
>> So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
>> clarify this.
>>
>> Signed-off-by: NeilBrown <neilb@suse.de>
>>
>> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
>> index da6d6d3..d04e272 100644
>> --- a/utils/mount/nfs.man
>> +++ b/utils/mount/nfs.man
>> @@ -1,5 +1,5 @@
>> .\"@(#)nfs.5"
>> -.TH NFS 5 "2 November 2007"
>> +.TH NFS 5 "9 October 2012"
>> .SH NAME
>> nfs \- fstab format and options for the
>> .B nfs
>> @@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
>> for NFS versions 2 and 3 only.
>> .TP 1.5i
>> .BI proto= netid
>> -The transport protocol name and protocol family the NFS client uses
>> -to transmit requests to the NFS server for this mount point.
>> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
>> -netid will force the use of IPv4 or IPv6 networking to communicate
>> -with that server.
>> -.IP
>> -If support for TI-RPC is built into the
>> -.B mount.nfs
>> -command,
>> -.I netid
>> -is a valid netid listed in
>> -.IR /etc/netconfig .
>> -The value "rdma" may also be specified.
>> -If the
>> -.B mount.nfs
>> -command does not have TI-RPC support, then
>> +The
>> .I netid
>> -is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
>> +determines the transport that is used to communicate with the NFS
>> +server.  Available options are
>> +.BR udp ", " udp6 ", "tcp ", " tcp6 ", and " rdma .
>> +Those which end in
>> +.B 6
>> +use IPv6 addresses and are only available if support for TI-RPC is
>> +built in. Others use IPv4 addresses.
>> .IP
>> Each transport protocol uses different default
>> .B retrans
>> @@ -569,19 +560,18 @@ This option can be used when mounting an NFS server
>> through a firewall that blocks the rpcbind protocol.
>> .TP 1.5i
>> .BI mountproto= netid
>> -The transport protocol name and protocol family the NFS client uses
>> +The transport the NFS client uses
>> to transmit requests to the NFS server's mountd service when performing
>> this mount request, and when later unmounting this mount point.
>> .IP
>> -If support for TI-RPC is built into the
>> +.I netid
>> +may be one of
>> +.BR udp ", and " tcp
>> +which use IPv4 address or, if TI-RPC is built into the
>> .B mount.nfs
>> command,
>> -.I netid
>> -is a valid netid listed in
>> -.IR /etc/netconfig .
>> -Otherwise,
>> -.I netid
>> -is one of "tcp" or "udp," and only IPv4 may be used.
>> +.BR udp6 ", and " tcp6
>> +which use IPv6 addresses.
>> .IP
>> This option can be used when mounting an NFS server
>> through a firewall that blocks a particular transport.
>> @@ -773,21 +763,14 @@ Use these options, along with the options in the first subsection above,
>> for NFS version 4 and newer.
>> .TP 1.5i
>> .BI proto= netid
>> -The transport protocol name and protocol family the NFS client uses
>> -to transmit requests to the NFS server for this mount point.
>> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
>> -netid will force the use of IPv4 or IPv6 networking to communicate
>> -with that server.
>> -.IP
>> -If support for TI-RPC is built into the
>> -.B mount.nfs
>> -command,
>> -.I netid
>> -is a valid netid listed in
>> -.IR /etc/netconfig .
>> -Otherwise,
>> +The
>> .I netid
>> -is one of "tcp" or "udp," and only IPv4 may be used.
>> +determines the transport that is used to communicate with the NFS
>> +server.  Supported options are
>> +.BR tcp ", " tcp6 ", and " rdma .
>> +.B tcp6
>> +use IPv6 addresses and is only available if support for TI-RPC is
>> +built in. Both others use IPv4 addresses.
>> .IP
>> All NFS version 4 servers are required to support TCP,
>> so if this mount option is not specified, the NFS version 4 client
>> @@ -851,6 +834,8 @@ The DATA AND METADATA COHERENCE section discusses
>> the behavior of this option in more detail.
>> .TP 1.5i
>> .BI clientaddr= n.n.n.n
>> +.TP 1.5i
>> +.BI clientaddr= n:n: ... :n
>> Specifies a single IPv4 address (in dotted-quad form),
>> or a non-link-local IPv6 address,
>> that the NFS client advertises to allow servers
>> diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
>> index 12a3fe7..2258296 100644
>> --- a/utils/mount/nfsmount.conf.man
>> +++ b/utils/mount/nfsmount.conf.man
>> @@ -1,5 +1,5 @@
>> .\"@(#)nfsmount.conf.5"
>> -.TH NFSMOUNT.CONF 5 "9 Mar 2008"
>> +.TH NFSMOUNT.CONF 5 "9 October 2012"
>> .SH NAME
>> nfsmount.conf - Configuration file for NFS mounts
>> .SH SYNOPSIS
>> @@ -18,6 +18,10 @@ to particular variables using the
>> .BR = 
>> operator, as in 
>> .BR Proto=Tcp .
>> +The variables that can be assigned are exactly the set of NFS specific
>> +mount options listed in
>> +.BR nfs (5).
>> +.PP
>> Sections are broken up into three basic categories:
>> Global options, Server options and Mount Point options.
>> .HP
>> @@ -54,7 +58,7 @@ are defined in the configuration file.
>>     Proto=Tcp
>> .RS
>> .HP
>> -The TCP protocol will be used on every NFS mount.
>> +The TCP/IPv4 protocol will be used on every NFS mount.
>> .HP
>> .RE
>> [ Server \(lqnfsserver.foo.com\(rq ]
>> @@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
>>     rsize=32k
>> .br
>>     wsize=32k
>> +.br
>> +    proto=udp6
>> .HP
>> .RS
>> -A 33k (32768 bytes) block size will be used as the read and write
>> -size on all mounts to the 'nfsserver.foo.com' server.
>> +A 32k (32768 bytes) block size will be used as the read and write
>> +size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
>> +is the protocol to be used.
>> .HP
>> .RE
>> .BR 
> 

Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]



It seems that with current nfs-utils, "proto=udp" (either
in /etc/nfsmount.conf or on the command line) restricts the mount to using
IPv4, not IPv6.
For IPv6 you need "udp6".

This isn't made crystal clear by the documentation.  I could fix the
documentation, but first I wanted to check if this really is appropriate.
Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
and require either "udp4" or "udp6" if we want a particular IP version.

i.e. instead of treating the "proto=" value as a "netid", should we treat it
as a "protoname" and match any "netid" in /etc/netconfig with that
"protoname"??

Thanks,
NeilBrown 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

Hi Neil-

On Sep 17, 2012, at 9:54 PM, NeilBrown wrote:

> It seems that with current nfs-utils, "proto=udp" (either
> in /etc/nfsmount.conf or on the command line) restricts the mount to using
> IPv4, not IPv6.
> For IPv6 you need "udp6".
> 
> This isn't made crystal clear by the documentation.  I could fix the
> documentation, but first I wanted to check if this really is appropriate.
> Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
> and require either "udp4" or "udp6" if we want a particular IP version.
> 
> i.e. instead of treating the "proto=" value as a "netid", should we treat it
> as a "protoname" and match any "netid" in /etc/netconfig with that
> "protoname"??

This is working as designed.

The meaning of each netid is defined in RFC 5665.  "udp" means UDP over IPv4.  This matches precisely what "proto=udp" meant before TI-RPC.  These netids force a particular protocol family when the server is specified by hostname and not IP address.

What's more, we mean this to match the behavior of the Solaris mount command, where "proto=udp" also has this meaning.

Which part of the documentation do you think is unclear?

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

On Tue, 18 Sep 2012 01:28:09 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Neil-
> 
> On Sep 17, 2012, at 9:54 PM, NeilBrown wrote:
> 
> > It seems that with current nfs-utils, "proto=udp" (either
> > in /etc/nfsmount.conf or on the command line) restricts the mount to using
> > IPv4, not IPv6.
> > For IPv6 you need "udp6".
> > 
> > This isn't made crystal clear by the documentation.  I could fix the
> > documentation, but first I wanted to check if this really is appropriate.
> > Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
> > and require either "udp4" or "udp6" if we want a particular IP version.
> > 
> > i.e. instead of treating the "proto=" value as a "netid", should we treat it
> > as a "protoname" and match any "netid" in /etc/netconfig with that
> > "protoname"??
> 
> This is working as designed.
> 
> The meaning of each netid is defined in RFC 5665.  "udp" means UDP over IPv4.  This matches precisely what "proto=udp" meant before TI-RPC.  These netids force a particular protocol family when the server is specified by hostname and not IP address.
> 
> What's more, we mean this to match the behavior of the Solaris mount command, where "proto=udp" also has this meaning.
> 
> Which part of the documentation do you think is unclear?
> 

Hi Chuck,
 Thanks for the reply.

It is unfortunate that the tag "proto" is used to choose the "netid".
In common parlance, "udp" and "tcp" are protocols independent of the
underlying transport (IPv4 or IPv6)  much as "nfsv3" or "nfsv4" are
independent of the underlying transport (tcp, udp6, rdma etc).

Give this obvious opportunity for confusion it would be good if the
documentation took significant steps to minimise it.

I note that nfs(5) does mention /etc/netconfig and the "netid"s that it
contains.  However "udp6" and "tcp6" are never given as examples - doing so
would help the reader see the import of the distinction.

       proto=netid    The transport protocol name and protocol family the  NFS
                      client  uses  to transmit requests to the NFS server for
                      this mount point.  If an NFS server has both an IPv4 and
                      an  IPv6  address, using a specific netid will force the
                      use of IPv4 or IPv6 networking to communicate with  that
                      server.

I don't think the second sentence would be very helpful to someone who didn't
already understand the subtleties. 
Something like:

    A particular netid completely specifies the protocol, so for example
    "tcp" is TCP over IPv4, and "udp6" is UDP over IPv6.  It is not possible
    to request "UDP" without also specifying which version of IP should be
    used.

man nfsmount.conf gives the example:

       [ NFSMount_Global_Options ]
           Proto=Tcp

              The TCP protocol will be used on every NFS mount.

which is incomplete.  Not just TCP, but TCP/IPv4 will be used on every NFS
mount.  And again, not IPv6 examples.

(and nfsmount.conf doesn't mention the "default$OPTION=value" syntax...)


For a usability perspective, I think that treating "udp" as meaning
"udp/ipv4" is a serious mistake and I'm not at all convinced that "Solaris
compatibility" is sufficient justification, but as I have no interest in
offering patches, I won't pursue that line of argument further :-)

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

On Sep 18, 2012, at 2:29 AM, NeilBrown wrote:

> On Tue, 18 Sep 2012 01:28:09 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> Hi Neil-
>> 
>> On Sep 17, 2012, at 9:54 PM, NeilBrown wrote:
>> 
>>> It seems that with current nfs-utils, "proto=udp" (either
>>> in /etc/nfsmount.conf or on the command line) restricts the mount to using
>>> IPv4, not IPv6.
>>> For IPv6 you need "udp6".
>>> 
>>> This isn't made crystal clear by the documentation.  I could fix the
>>> documentation, but first I wanted to check if this really is appropriate.
>>> Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
>>> and require either "udp4" or "udp6" if we want a particular IP version.
>>> 
>>> i.e. instead of treating the "proto=" value as a "netid", should we treat it
>>> as a "protoname" and match any "netid" in /etc/netconfig with that
>>> "protoname"??
>> 
>> This is working as designed.
>> 
>> The meaning of each netid is defined in RFC 5665.  "udp" means UDP over IPv4.  This matches precisely what "proto=udp" meant before TI-RPC.  These netids force a particular protocol family when the server is specified by hostname and not IP address.
>> 
>> What's more, we mean this to match the behavior of the Solaris mount command, where "proto=udp" also has this meaning.
>> 
>> Which part of the documentation do you think is unclear?
>> 
> 
> Hi Chuck,
> Thanks for the reply.
> 
> It is unfortunate that the tag "proto" is used to choose the "netid".
> In common parlance, "udp" and "tcp" are protocols independent of the
> underlying transport (IPv4 or IPv6)  much as "nfsv3" or "nfsv4" are
> independent of the underlying transport (tcp, udp6, rdma etc).
> 
> Give this obvious opportunity for confusion it would be good if the
> documentation took significant steps to minimise it.
> 
> I note that nfs(5) does mention /etc/netconfig and the "netid"s that it
> contains.  However "udp6" and "tcp6" are never given as examples - doing so
> would help the reader see the import of the distinction.
> 
>       proto=netid    The transport protocol name and protocol family the  NFS
>                      client  uses  to transmit requests to the NFS server for
>                      this mount point.  If an NFS server has both an IPv4 and
>                      an  IPv6  address, using a specific netid will force the
>                      use of IPv4 or IPv6 networking to communicate with  that
>                      server.
> 
> I don't think the second sentence would be very helpful to someone who didn't
> already understand the subtleties. 
> Something like:
> 
>    A particular netid completely specifies the protocol, so for example
>    "tcp" is TCP over IPv4, and "udp6" is UDP over IPv6.  It is not possible
>    to request "UDP" without also specifying which version of IP should be
>    used.

The "proto=" section is already five paragraphs long, thanks to the complexity of transport autonegotiation and RPC timeout settings.  What might be better is simply to add "See netconfig(5) for a description of netids."

> 
> man nfsmount.conf gives the example:
> 
>       [ NFSMount_Global_Options ]
>           Proto=Tcp
> 
>              The TCP protocol will be used on every NFS mount.
> 
> which is incomplete.  Not just TCP, but TCP/IPv4 will be used on every NFS
> mount.  And again, not IPv6 examples.

Agreed, that should be fixed.  A simple reference to nfs(5) would probably be enough.

> (and nfsmount.conf doesn't mention the "default$OPTION=value" syntax...)
> 
> 
> For a usability perspective, I think that treating "udp" as meaning
> "udp/ipv4" is a serious mistake and I'm not at all convinced that "Solaris
> compatibility" is sufficient justification, but as I have no interest in
> offering patches, I won't pursue that line of argument further :-)

Others have been concerned about this point in the past, so let me continue just for a moment.  The selling point is backwards compatibility, which beats usability nearly every time (for better or worse).

When support for IPv6 is introduced, we want the behavior of "proto=udp" to stay the same.  Without TI-RPC support, it means connect to the server via UDP on IPv4.  With TI-RPC, it means precisely the same thing.

For example, suppose an administrator upgrades a system from an O/S without NFS/IPv6 support to an O/S with NFS/IPv6 support.  Suppose further the upgrade was done to get critical bug fixes, and the administrator has no interest in IPv6 at the moment.

Without any further administrative action, should the new O/S now assume that it is OK to use IPv6 for NFS mounts?  Because of the amount of planning and configuration needed to transition a network from IPv4 to IPv6, it would be surprising to most people to find NFS suddenly going over IPv6 in this case.

Personally I think this is less confusing than "proto=udp" meaning something different on old systems, or newer systems built without TI-RPC support, than it does on typical newer systems built with TI-RPC.  Think how much harder it would be to explain in nfs(5).  ;-)

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 9619 bytes --]

On Tue, 18 Sep 2012 11:31:28 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Sep 18, 2012, at 2:29 AM, NeilBrown wrote:
> 
> > On Tue, 18 Sep 2012 01:28:09 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> > 
> >> Hi Neil-
> >> 
> >> On Sep 17, 2012, at 9:54 PM, NeilBrown wrote:
> >> 
> >>> It seems that with current nfs-utils, "proto=udp" (either
> >>> in /etc/nfsmount.conf or on the command line) restricts the mount to using
> >>> IPv4, not IPv6.
> >>> For IPv6 you need "udp6".
> >>> 
> >>> This isn't made crystal clear by the documentation.  I could fix the
> >>> documentation, but first I wanted to check if this really is appropriate.
> >>> Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
> >>> and require either "udp4" or "udp6" if we want a particular IP version.
> >>> 
> >>> i.e. instead of treating the "proto=" value as a "netid", should we treat it
> >>> as a "protoname" and match any "netid" in /etc/netconfig with that
> >>> "protoname"??
> >> 
> >> This is working as designed.
> >> 
> >> The meaning of each netid is defined in RFC 5665.  "udp" means UDP over IPv4.  This matches precisely what "proto=udp" meant before TI-RPC.  These netids force a particular protocol family when the server is specified by hostname and not IP address.
> >> 
> >> What's more, we mean this to match the behavior of the Solaris mount command, where "proto=udp" also has this meaning.
> >> 
> >> Which part of the documentation do you think is unclear?
> >> 
> > 
> > Hi Chuck,
> > Thanks for the reply.
> > 
> > It is unfortunate that the tag "proto" is used to choose the "netid".
> > In common parlance, "udp" and "tcp" are protocols independent of the
> > underlying transport (IPv4 or IPv6)  much as "nfsv3" or "nfsv4" are
> > independent of the underlying transport (tcp, udp6, rdma etc).
> > 
> > Give this obvious opportunity for confusion it would be good if the
> > documentation took significant steps to minimise it.
> > 
> > I note that nfs(5) does mention /etc/netconfig and the "netid"s that it
> > contains.  However "udp6" and "tcp6" are never given as examples - doing so
> > would help the reader see the import of the distinction.
> > 
> >       proto=netid    The transport protocol name and protocol family the  NFS
> >                      client  uses  to transmit requests to the NFS server for
> >                      this mount point.  If an NFS server has both an IPv4 and
> >                      an  IPv6  address, using a specific netid will force the
> >                      use of IPv4 or IPv6 networking to communicate with  that
> >                      server.
> > 
> > I don't think the second sentence would be very helpful to someone who didn't
> > already understand the subtleties. 
> > Something like:
> > 
> >    A particular netid completely specifies the protocol, so for example
> >    "tcp" is TCP over IPv4, and "udp6" is UDP over IPv6.  It is not possible
> >    to request "UDP" without also specifying which version of IP should be
> >    used.
> 
> The "proto=" section is already five paragraphs long, thanks to the complexity of transport autonegotiation and RPC timeout settings.  What might be better is simply to add "See netconfig(5) for a description of netids."

There are a lot of words in netconfig(5), very few of which are useful to a
sysadmin wanting to deploy NFS.  So I don't think that addition by itself
would be very helpful.

> 
> > 
> > man nfsmount.conf gives the example:
> > 
> >       [ NFSMount_Global_Options ]
> >           Proto=Tcp
> > 
> >              The TCP protocol will be used on every NFS mount.
> > 
> > which is incomplete.  Not just TCP, but TCP/IPv4 will be used on every NFS
> > mount.  And again, not IPv6 examples.
> 
> Agreed, that should be fixed.  A simple reference to nfs(5) would probably be enough.

Necessary, but not sufficient I think.  References are useful, but if you
have to follow them to understand the documentation, then the documentation
is lacking.

> 
> > (and nfsmount.conf doesn't mention the "default$OPTION=value" syntax...)
> > 
> > 
> > For a usability perspective, I think that treating "udp" as meaning
> > "udp/ipv4" is a serious mistake and I'm not at all convinced that "Solaris
> > compatibility" is sufficient justification, but as I have no interest in
> > offering patches, I won't pursue that line of argument further :-)
> 
> Others have been concerned about this point in the past, so let me continue just for a moment.  The selling point is backwards compatibility, which beats usability nearly every time (for better or worse).
> 
> When support for IPv6 is introduced, we want the behavior of "proto=udp" to stay the same.  Without TI-RPC support, it means connect to the server via UDP on IPv4.  With TI-RPC, it means precisely the same thing.
> 
> For example, suppose an administrator upgrades a system from an O/S without NFS/IPv6 support to an O/S with NFS/IPv6 support.  Suppose further the upgrade was done to get critical bug fixes, and the administrator has no interest in IPv6 at the moment.
> 
> Without any further administrative action, should the new O/S now assume that it is OK to use IPv6 for NFS mounts?  Because of the amount of planning and configuration needed to transition a network from IPv4 to IPv6, it would be surprising to most people to find NFS suddenly going over IPv6 in this case.
> 
> Personally I think this is less confusing than "proto=udp" meaning something different on old systems, or newer systems built without TI-RPC support, than it does on typical newer systems built with TI-RPC.  Think how much harder it would be to explain in nfs(5).  ;-)
> 

So if the sysadmin says "nfsvers=3", then upgrading could change that from
nfsv3/tcp/ipv4 to nfsv3/tcp/ipv6.  However if they say "proto=udp", then that
mustn't change from nfsv3/udp/ipv4 to nfsv3/udp/ipv6, even though it could
allow a change to nfsv4/udp/ipv4.
I don't really see that pattern here.

Isn't it much easier to say "proto=udp means use UDP over whatever network
protocol is available" that to mention netconfig which looks to me like some
sort of internal implementation detail.

Would you support the following patch?

Thanks,
NeilBrown

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index da6d6d3..72b8a09 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -1,5 +1,5 @@
 .\"@(#)nfs.5"
-.TH NFS 5 "2 November 2007"
+.TH NFS 5 "19 September 2012"
 .SH NAME
 nfs \- fstab format and options for the
 .B nfs
@@ -474,9 +474,17 @@ for NFS versions 2 and 3 only.
 .BI proto= netid
 The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
+A
+.I netid
+determines both the
+.I transport
+and
+.I network
+protocols, so for example
+.B udp
+selects UDP over IPv4 while
+.B tcp6
+selects TCP over IPv6.
 .IP
 If support for TI-RPC is built into the
 .B mount.nfs
@@ -775,9 +783,17 @@ for NFS version 4 and newer.
 .BI proto= netid
 The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
+A
+.I netid
+determines both the
+.I transport
+and
+.I network
+protocols, so for example
+.B udp
+selects UDP over IPv4 while
+.B tcp6
+selects TCP over IPv6.
 .IP
 If support for TI-RPC is built into the
 .B mount.nfs
@@ -851,6 +867,8 @@ The DATA AND METADATA COHERENCE section discusses
 the behavior of this option in more detail.
 .TP 1.5i
 .BI clientaddr= n.n.n.n
+.TP 1.5i
+.BI clientaddr= n:n: ... :n
 Specifies a single IPv4 address (in dotted-quad form),
 or a non-link-local IPv6 address,
 that the NFS client advertises to allow servers
diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
index 12a3fe7..2258296 100644
--- a/utils/mount/nfsmount.conf.man
+++ b/utils/mount/nfsmount.conf.man
@@ -1,5 +1,5 @@
 .\"@(#)nfsmount.conf.5"
-.TH NFSMOUNT.CONF 5 "9 Mar 2008"
+.TH NFSMOUNT.CONF 5 "19 September 2012"
 .SH NAME
 nfsmount.conf - Configuration file for NFS mounts
 .SH SYNOPSIS
@@ -18,6 +18,10 @@ to particular variables using the
 .BR = 
 operator, as in 
 .BR Proto=Tcp .
+The variables that can be assigned are exactly the set of NFS specific
+mount options listed in
+.BR nfs (5).
+.PP
 Sections are broken up into three basic categories:
 Global options, Server options and Mount Point options.
 .HP
@@ -54,7 +58,7 @@ are defined in the configuration file.
     Proto=Tcp
 .RS
 .HP
-The TCP protocol will be used on every NFS mount.
+The TCP/IPv4 protocol will be used on every NFS mount.
 .HP
 .RE
 [ Server \(lqnfsserver.foo.com\(rq ]
@@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
     rsize=32k
 .br
     wsize=32k
+.br
+    proto=udp6
 .HP
 .RS
-A 33k (32768 bytes) block size will be used as the read and write
-size on all mounts to the 'nfsserver.foo.com' server.
+A 32k (32768 bytes) block size will be used as the read and write
+size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
+is the protocol to be used.
 .HP
 .RE
 .BR 



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

On Sep 18, 2012, at 7:19 PM, NeilBrown wrote:

> On Tue, 18 Sep 2012 11:31:28 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> 
>> On Sep 18, 2012, at 2:29 AM, NeilBrown wrote:
>> 
>>> On Tue, 18 Sep 2012 01:28:09 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
>>> 
>>>> Hi Neil-
>>>> 
>>>> On Sep 17, 2012, at 9:54 PM, NeilBrown wrote:
>>>> 
>>>>> It seems that with current nfs-utils, "proto=udp" (either
>>>>> in /etc/nfsmount.conf or on the command line) restricts the mount to using
>>>>> IPv4, not IPv6.
>>>>> For IPv6 you need "udp6".
>>>>> 
>>>>> This isn't made crystal clear by the documentation.  I could fix the
>>>>> documentation, but first I wanted to check if this really is appropriate.
>>>>> Is there a good reason for this, or should we make "udp" mean "udp4 or udp6"
>>>>> and require either "udp4" or "udp6" if we want a particular IP version.
>>>>> 
>>>>> i.e. instead of treating the "proto=" value as a "netid", should we treat it
>>>>> as a "protoname" and match any "netid" in /etc/netconfig with that
>>>>> "protoname"??
>>>> 
>>>> This is working as designed.
>>>> 
>>>> The meaning of each netid is defined in RFC 5665.  "udp" means UDP over IPv4.  This matches precisely what "proto=udp" meant before TI-RPC.  These netids force a particular protocol family when the server is specified by hostname and not IP address.
>>>> 
>>>> What's more, we mean this to match the behavior of the Solaris mount command, where "proto=udp" also has this meaning.
>>>> 
>>>> Which part of the documentation do you think is unclear?
>>>> 
>>> 
>>> Hi Chuck,
>>> Thanks for the reply.
>>> 
>>> It is unfortunate that the tag "proto" is used to choose the "netid".
>>> In common parlance, "udp" and "tcp" are protocols independent of the
>>> underlying transport (IPv4 or IPv6)  much as "nfsv3" or "nfsv4" are
>>> independent of the underlying transport (tcp, udp6, rdma etc).
>>> 
>>> Give this obvious opportunity for confusion it would be good if the
>>> documentation took significant steps to minimise it.
>>> 
>>> I note that nfs(5) does mention /etc/netconfig and the "netid"s that it
>>> contains.  However "udp6" and "tcp6" are never given as examples - doing so
>>> would help the reader see the import of the distinction.
>>> 
>>>      proto=netid    The transport protocol name and protocol family the  NFS
>>>                     client  uses  to transmit requests to the NFS server for
>>>                     this mount point.  If an NFS server has both an IPv4 and
>>>                     an  IPv6  address, using a specific netid will force the
>>>                     use of IPv4 or IPv6 networking to communicate with  that
>>>                     server.
>>> 
>>> I don't think the second sentence would be very helpful to someone who didn't
>>> already understand the subtleties. 
>>> Something like:
>>> 
>>>   A particular netid completely specifies the protocol, so for example
>>>   "tcp" is TCP over IPv4, and "udp6" is UDP over IPv6.  It is not possible
>>>   to request "UDP" without also specifying which version of IP should be
>>>   used.
>> 
>> The "proto=" section is already five paragraphs long, thanks to the complexity of transport autonegotiation and RPC timeout settings.  What might be better is simply to add "See netconfig(5) for a description of netids."
> 
> There are a lot of words in netconfig(5), very few of which are useful to a
> sysadmin wanting to deploy NFS.  So I don't think that addition by itself
> would be very helpful.

We must be looking at different versions of netconfig(5).  My version has just 383 words (according to wc) and has a nice shiny table in it that precisely defines what each netid means.  I don't see how that is not relevant here.

My impression is that a man page is not a user guide; it is meant to be a command reference.  This is perhaps not the place for connecting every dot, but we can agree to disagree on that.


> 
>> 
>>> 
>>> man nfsmount.conf gives the example:
>>> 
>>>      [ NFSMount_Global_Options ]
>>>          Proto=Tcp
>>> 
>>>             The TCP protocol will be used on every NFS mount.
>>> 
>>> which is incomplete.  Not just TCP, but TCP/IPv4 will be used on every NFS
>>> mount.  And again, not IPv6 examples.
>> 
>> Agreed, that should be fixed.  A simple reference to nfs(5) would probably be enough.
> 
> Necessary, but not sufficient I think.  References are useful, but if you
> have to follow them to understand the documentation, then the documentation
> is lacking.

Doesn't "proto=tcp" here mean exactly what it means in nfs(5)?  Why repeat that information?  If it doesn't mean the same, then this is an ideal spot for explaining the difference.  Looks like you reached roughly the same conclusion below.

> 
>> 
>>> (and nfsmount.conf doesn't mention the "default$OPTION=value" syntax...)
>>> 
>>> 
>>> For a usability perspective, I think that treating "udp" as meaning
>>> "udp/ipv4" is a serious mistake and I'm not at all convinced that "Solaris
>>> compatibility" is sufficient justification, but as I have no interest in
>>> offering patches, I won't pursue that line of argument further :-)
>> 
>> Others have been concerned about this point in the past, so let me continue just for a moment.  The selling point is backwards compatibility, which beats usability nearly every time (for better or worse).
>> 
>> When support for IPv6 is introduced, we want the behavior of "proto=udp" to stay the same.  Without TI-RPC support, it means connect to the server via UDP on IPv4.  With TI-RPC, it means precisely the same thing.
>> 
>> For example, suppose an administrator upgrades a system from an O/S without NFS/IPv6 support to an O/S with NFS/IPv6 support.  Suppose further the upgrade was done to get critical bug fixes, and the administrator has no interest in IPv6 at the moment.
>> 
>> Without any further administrative action, should the new O/S now assume that it is OK to use IPv6 for NFS mounts?  Because of the amount of planning and configuration needed to transition a network from IPv4 to IPv6, it would be surprising to most people to find NFS suddenly going over IPv6 in this case.
>> 
>> Personally I think this is less confusing than "proto=udp" meaning something different on old systems, or newer systems built without TI-RPC support, than it does on typical newer systems built with TI-RPC.  Think how much harder it would be to explain in nfs(5).  ;-)
>> 
> 
> So if the sysadmin says "nfsvers=3", then upgrading could change that from
> nfsv3/tcp/ipv4 to nfsv3/tcp/ipv6.  However if they say "proto=udp", then that
> mustn't change from nfsv3/udp/ipv4 to nfsv3/udp/ipv6, even though it could
> allow a change to nfsv4/udp/ipv4.
> I don't really see that pattern here.

The NFS version setting does not control any aspect of the underlying transport, so I wouldn't expect it to have any influence on what address family is chosen.

Thus nfsvers option is, IMO, a red herring.  As we introduce support for TI-RPC, we are changing only the values that can be specified for "proto=" (and "mountproto=").  As such, we care only about the compatibility issues among the values of "proto=".

> Isn't it much easier to say "proto=udp means use UDP over whatever network
> protocol is available" that to mention netconfig which looks to me like some
> sort of internal implementation detail.

IPv6 support for NFS comes by virtue of TI-RPC.  I know there are folks in the Linux community who would prefer we didn't choose TI-RPC, but we really cannot provide interoperable support for NFS over IPv6 without TI-RPC.

Why are netids important for interoperability?  Because rpcbind on servers (eg. non-Linux systems like Solaris or NetApp) advertise IPv6 support by netid.  The "proto=" values match what is advertised.

Out of interest, do you have a use case that could make positive use of a "please use UDP but I don't care whether its IPv4 or IPv6" setting?


> Would you support the following patch?

I'm always game for improving our documentation.  Comment below.

> 
> Thanks,
> NeilBrown
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index da6d6d3..72b8a09 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfs.5"
> -.TH NFS 5 "2 November 2007"
> +.TH NFS 5 "19 September 2012"
> .SH NAME
> nfs \- fstab format and options for the
> .B nfs
> @@ -474,9 +474,17 @@ for NFS versions 2 and 3 only.
> .BI proto= netid
> The transport protocol name and protocol family the NFS client uses
> to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> +A
> +.I netid
> +determines both the
> +.I transport
> +and
> +.I network
> +protocols, so for example

"determines both the protocol family and transport" are closer to how these terms are defined in netconfig(5), and I prefer that formulation.  I still believe a citation of netconfig(5) would be correct and helpful.  A citation in the SEE ALSO section should also be added.

As a matter of word smithing, I think starting a new sentence at "so for example" would be easier to read.

> +.B udp
> +selects UDP over IPv4 while
> +.B tcp6
> +selects TCP over IPv6.
> .IP
> If support for TI-RPC is built into the
> .B mount.nfs
> @@ -775,9 +783,17 @@ for NFS version 4 and newer.
> .BI proto= netid
> The transport protocol name and protocol family the NFS client uses
> to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> +A
> +.I netid
> +determines both the
> +.I transport
> +and
> +.I network
> +protocols, so for example
> +.B udp
> +selects UDP over IPv4 while
> +.B tcp6
> +selects TCP over IPv6.
> .IP
> If support for TI-RPC is built into the
> .B mount.nfs
> @@ -851,6 +867,8 @@ The DATA AND METADATA COHERENCE section discusses
> the behavior of this option in more detail.
> .TP 1.5i
> .BI clientaddr= n.n.n.n
> +.TP 1.5i
> +.BI clientaddr= n:n: ... :n
> Specifies a single IPv4 address (in dotted-quad form),
> or a non-link-local IPv6 address,
> that the NFS client advertises to allow servers
> diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
> index 12a3fe7..2258296 100644
> --- a/utils/mount/nfsmount.conf.man
> +++ b/utils/mount/nfsmount.conf.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfsmount.conf.5"
> -.TH NFSMOUNT.CONF 5 "9 Mar 2008"
> +.TH NFSMOUNT.CONF 5 "19 September 2012"
> .SH NAME
> nfsmount.conf - Configuration file for NFS mounts
> .SH SYNOPSIS
> @@ -18,6 +18,10 @@ to particular variables using the
> .BR = 
> operator, as in 
> .BR Proto=Tcp .
> +The variables that can be assigned are exactly the set of NFS specific
> +mount options listed in
> +.BR nfs (5).
> +.PP
> Sections are broken up into three basic categories:
> Global options, Server options and Mount Point options.
> .HP
> @@ -54,7 +58,7 @@ are defined in the configuration file.
>     Proto=Tcp
> .RS
> .HP
> -The TCP protocol will be used on every NFS mount.
> +The TCP/IPv4 protocol will be used on every NFS mount.
> .HP
> .RE
> [ Server \(lqnfsserver.foo.com\(rq ]
> @@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
>     rsize=32k
> .br
>     wsize=32k
> +.br
> +    proto=udp6
> .HP
> .RS
> -A 33k (32768 bytes) block size will be used as the read and write
> -size on all mounts to the 'nfsserver.foo.com' server.
> +A 32k (32768 bytes) block size will be used as the read and write
> +size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
> +is the protocol to be used.
> .HP
> .RE
> .BR 
> 
> 

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]

On Tue, 18 Sep 2012 21:00:01 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:


> Out of interest, do you have a use case that could make positive use of a "please use UDP but I don't care whether its IPv4 or IPv6" setting?

No, but that isn't really the point.
The point is that to anyone not well verse in the lore of TI-RPC, "proto=udp"
looks like it means "set the protocol to UDP", not "set the protocol to UDP
and the protocol family to IPv4".
One way to clear up the confusion would be to change the meaning of
"proto=udp" to match what most people would epxect it to mean.
The other it to document the non-obvious semantics thoroughly.  I wanted to
consider both options.

> > +A
> > +.I netid
> > +determines both the
> > +.I transport
> > +and
> > +.I network
> > +protocols, so for example
> 
> "determines both the protocol family and transport" are closer to how these terms are defined in netconfig(5), and I prefer that formulation.  I still believe a citation of netconfig(5) would be correct and helpful.  A citation in the SEE ALSO section should also be added.

(SEE ALSO already mentions netconfig(5).)

Don't you love standards....

ISO OSI seems to use "network" for layer 3 and "transport" for layer 4, which
is where I got that names I used.

netconfig(5) uses "protocol family" and "protocol" respectively, and
"transport" to identify the combination of the two (which is also the
network_id).

socket(2) also uses "protocol family" and "protocol", but uses AF as the
prefix for "protocol family" aka "address family" :-)

This does serve to highlight the inappropriateness of using "proto=" to
specify the "transport", and the netconfig usage treats the "protocol" as a
just part of the "transport" (but allows e.g. "udp" to be both a protocol and
a transport depending on context).

It looks like  "protocol" and "protocol family" are the most appropriate
terms in the Unix world, and the examples can clear up any uncertainty:

------------
A
.I netid
determines both the
.I protocol
and
.IR "protocol family" .
So for example
.B udp
selects UDP over IPv4 while
.B tcp6
selects TCP over IPv6.
-----------------
> 
> As a matter of word smithing, I think starting a new sentence at "so for example" would be easier to read.

Agreed.

So how about this.

Thanks,
NeilBrown


From: Neil Brown <neilb@suse.de>
Date: Tue, 2 Oct 2012 15:21:46 +1000
Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
 'transport'

The mount option "proto=" actually set the "transport" which in
netconfig usage is the paring of a protocol (e.g. UDP, TCP) with
a protocol family (e.g. INET, INET6).

This can cause confusion if people naively except "proto=udp" to work
equally well on IPv6.

So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
clarify this.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index da6d6d3..2741a60 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -1,5 +1,5 @@
 .\"@(#)nfs.5"
-.TH NFS 5 "2 November 2007"
+.TH NFS 5 "19 September 2012"
 .SH NAME
 nfs \- fstab format and options for the
 .B nfs
@@ -474,9 +474,17 @@ for NFS versions 2 and 3 only.
 .BI proto= netid
 The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
+A
+.I netid
+determines both the
+.I protocol
+and
+.IR "protocol family" .
+So for example
+.B udp
+selects UDP over IPv4 while
+.B tcp6
+selects TCP over IPv6.
 .IP
 If support for TI-RPC is built into the
 .B mount.nfs
@@ -775,9 +783,17 @@ for NFS version 4 and newer.
 .BI proto= netid
 The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
+A
+.I netid
+determines both the
+.I transport
+and
+.I network
+protocols, so for example
+.B udp
+selects UDP over IPv4 while
+.B tcp6
+selects TCP over IPv6.
 .IP
 If support for TI-RPC is built into the
 .B mount.nfs
@@ -851,6 +867,8 @@ The DATA AND METADATA COHERENCE section discusses
 the behavior of this option in more detail.
 .TP 1.5i
 .BI clientaddr= n.n.n.n
+.TP 1.5i
+.BI clientaddr= n:n: ... :n
 Specifies a single IPv4 address (in dotted-quad form),
 or a non-link-local IPv6 address,
 that the NFS client advertises to allow servers
diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
index 12a3fe7..2258296 100644
--- a/utils/mount/nfsmount.conf.man
+++ b/utils/mount/nfsmount.conf.man
@@ -1,5 +1,5 @@
 .\"@(#)nfsmount.conf.5"
-.TH NFSMOUNT.CONF 5 "9 Mar 2008"
+.TH NFSMOUNT.CONF 5 "19 September 2012"
 .SH NAME
 nfsmount.conf - Configuration file for NFS mounts
 .SH SYNOPSIS
@@ -18,6 +18,10 @@ to particular variables using the
 .BR = 
 operator, as in 
 .BR Proto=Tcp .
+The variables that can be assigned are exactly the set of NFS specific
+mount options listed in
+.BR nfs (5).
+.PP
 Sections are broken up into three basic categories:
 Global options, Server options and Mount Point options.
 .HP
@@ -54,7 +58,7 @@ are defined in the configuration file.
     Proto=Tcp
 .RS
 .HP
-The TCP protocol will be used on every NFS mount.
+The TCP/IPv4 protocol will be used on every NFS mount.
 .HP
 .RE
 [ Server \(lqnfsserver.foo.com\(rq ]
@@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
     rsize=32k
 .br
     wsize=32k
+.br
+    proto=udp6
 .HP
 .RS
-A 33k (32768 bytes) block size will be used as the read and write
-size on all mounts to the 'nfsserver.foo.com' server.
+A 32k (32768 bytes) block size will be used as the read and write
+size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
+is the protocol to be used.
 .HP
 .RE
 .BR 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[Chuck Lever]

On Oct 1, 2012, at 10:24 PM, NeilBrown wrote:

> On Tue, 18 Sep 2012 21:00:01 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
>>> +A
>>> +.I netid
>>> +determines both the
>>> +.I transport
>>> +and
>>> +.I network
>>> +protocols, so for example
>> 
>> "determines both the protocol family and transport" are closer to how these terms are defined in netconfig(5), and I prefer that formulation.  I still believe a citation of netconfig(5) would be correct and helpful.  A citation in the SEE ALSO section should also be added.
> 
> (SEE ALSO already mentions netconfig(5).)
> 
> Don't you love standards....
> 
> ISO OSI seems to use "network" for layer 3 and "transport" for layer 4, which
> is where I got that names I used.
> 
> netconfig(5) uses "protocol family" and "protocol" respectively, and
> "transport" to identify the combination of the two (which is also the
> network_id).
> 
> socket(2) also uses "protocol family" and "protocol", but uses AF as the
> prefix for "protocol family" aka "address family" :-)
> 
> This does serve to highlight the inappropriateness of using "proto=" to
> specify the "transport", and the netconfig usage treats the "protocol" as a
> just part of the "transport" (but allows e.g. "udp" to be both a protocol and
> a transport depending on context).
> 
> It looks like  "protocol" and "protocol family" are the most appropriate
> terms in the Unix world, and the examples can clear up any uncertainty:
> 
> ------------
> A
> .I netid
> determines both the
> .I protocol
> and
> .IR "protocol family" .
> So for example
> .B udp
> selects UDP over IPv4 while
> .B tcp6
> selects TCP over IPv6.
> -----------------
>> 
>> As a matter of word smithing, I think starting a new sentence at "so for example" would be easier to read.
> 
> Agreed.
> 
> So how about this.
> 
> Thanks,
> NeilBrown
> 
> 
> From: Neil Brown <neilb@suse.de>
> Date: Tue, 2 Oct 2012 15:21:46 +1000
> Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
> 'transport'
> 
> The mount option "proto=" actually set the "transport" which in
> netconfig usage is the paring of a protocol (e.g. UDP, TCP) with
> a protocol family (e.g. INET, INET6).
> 
> This can cause confusion if people naively except "proto=udp" to work
> equally well on IPv6.
> 
> So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
> clarify this.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index da6d6d3..2741a60 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1,5 +1,5 @@
> .\"@(#)nfs.5"
> -.TH NFS 5 "2 November 2007"
> +.TH NFS 5 "19 September 2012"
> .SH NAME
> nfs \- fstab format and options for the
> .B nfs
> @@ -474,9 +474,17 @@ for NFS versions 2 and 3 only.
> .BI proto= netid
> The transport protocol name and protocol family the NFS client uses
> to transmit requests to the NFS server for this mount point.
> -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> -netid will force the use of IPv4 or IPv6 networking to communicate
> -with that server.
> +A
> +.I netid
> +determines both the
> +.I protocol
> +and
> +.IR "protocol family" .

Looking at this addition in context, the new sentence simply repeats the existing first sentence in the paragraph.  How about we clarify the existing first sentence, and just add your example:

> proto=netid
> 
> The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.

We have a slightly sticky problem, then.  TI-RPC brings more to the table than udp/udp6 and tcp/tcp6.  For instance, we also now have rdma/rdma6 netids (not mentioned anywhere, ha) and there is a local transport netid.  If there ever is support for RPC over SCTP, that would also get its own pair of netids.  The problem is that not all of these netids are supported by NFS right now.  I think nfs(5) might benefit by providing a list of supported netid values.

This could make the above paragraph perhaps too long.  We should consider adding a section to nfs(5) that discusses this in a little more detail.  That can be a separate patch, of course.

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

Re: Should "mount -o proto=udp" be usable against an IPv6 only server?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 11165 bytes --]

On Tue, 2 Oct 2012 07:24:23 -0700 Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Oct 1, 2012, at 10:24 PM, NeilBrown wrote:
> 
> > On Tue, 18 Sep 2012 21:00:01 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> >>> +A
> >>> +.I netid
> >>> +determines both the
> >>> +.I transport
> >>> +and
> >>> +.I network
> >>> +protocols, so for example
> >> 
> >> "determines both the protocol family and transport" are closer to how these terms are defined in netconfig(5), and I prefer that formulation.  I still believe a citation of netconfig(5) would be correct and helpful.  A citation in the SEE ALSO section should also be added.
> > 
> > (SEE ALSO already mentions netconfig(5).)
> > 
> > Don't you love standards....
> > 
> > ISO OSI seems to use "network" for layer 3 and "transport" for layer 4, which
> > is where I got that names I used.
> > 
> > netconfig(5) uses "protocol family" and "protocol" respectively, and
> > "transport" to identify the combination of the two (which is also the
> > network_id).
> > 
> > socket(2) also uses "protocol family" and "protocol", but uses AF as the
> > prefix for "protocol family" aka "address family" :-)
> > 
> > This does serve to highlight the inappropriateness of using "proto=" to
> > specify the "transport", and the netconfig usage treats the "protocol" as a
> > just part of the "transport" (but allows e.g. "udp" to be both a protocol and
> > a transport depending on context).
> > 
> > It looks like  "protocol" and "protocol family" are the most appropriate
> > terms in the Unix world, and the examples can clear up any uncertainty:
> > 
> > ------------
> > A
> > .I netid
> > determines both the
> > .I protocol
> > and
> > .IR "protocol family" .
> > So for example
> > .B udp
> > selects UDP over IPv4 while
> > .B tcp6
> > selects TCP over IPv6.
> > -----------------
> >> 
> >> As a matter of word smithing, I think starting a new sentence at "so for example" would be easier to read.
> > 
> > Agreed.
> > 
> > So how about this.
> > 
> > Thanks,
> > NeilBrown
> > 
> > 
> > From: Neil Brown <neilb@suse.de>
> > Date: Tue, 2 Oct 2012 15:21:46 +1000
> > Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
> > 'transport'
> > 
> > The mount option "proto=" actually set the "transport" which in
> > netconfig usage is the paring of a protocol (e.g. UDP, TCP) with
> > a protocol family (e.g. INET, INET6).
> > 
> > This can cause confusion if people naively except "proto=udp" to work
> > equally well on IPv6.
> > 
> > So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
> > clarify this.
> > 
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > 
> > diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> > index da6d6d3..2741a60 100644
> > --- a/utils/mount/nfs.man
> > +++ b/utils/mount/nfs.man
> > @@ -1,5 +1,5 @@
> > .\"@(#)nfs.5"
> > -.TH NFS 5 "2 November 2007"
> > +.TH NFS 5 "19 September 2012"
> > .SH NAME
> > nfs \- fstab format and options for the
> > .B nfs
> > @@ -474,9 +474,17 @@ for NFS versions 2 and 3 only.
> > .BI proto= netid
> > The transport protocol name and protocol family the NFS client uses
> > to transmit requests to the NFS server for this mount point.
> > -If an NFS server has both an IPv4 and an IPv6 address, using a specific
> > -netid will force the use of IPv4 or IPv6 networking to communicate
> > -with that server.
> > +A
> > +.I netid
> > +determines both the
> > +.I protocol
> > +and
> > +.IR "protocol family" .
> 
> Looking at this addition in context, the new sentence simply repeats the existing first sentence in the paragraph.  How about we clarify the existing first sentence, and just add your example:

Good point!

> 
> > proto=netid
> > 
> > The protocol and protocol family the NFS client uses to transmit requests to the NFS server for this mount point.  For example, udp selects UDP over IPv4, while tcp6 selects TCP over IPv6.  If an NFS server has both an IPv4 and an IPv6 address, using a specific netid forces the use of IPv4 or IPv6 networking to communicate with that server.

I still don't like that last sentence.

> 
> We have a slightly sticky problem, then.  TI-RPC brings more to the table than udp/udp6 and tcp/tcp6.  For instance, we also now have rdma/rdma6 netids (not mentioned anywhere, ha) and there is a local transport netid.  If there ever is support for RPC over SCTP, that would also get its own pair of netids.  The problem is that not all of these netids are supported by NFS right now.  I think nfs(5) might benefit by providing a list of supported netid values.
> 
> This could make the above paragraph perhaps too long.  We should consider adding a section to nfs(5) that discusses this in a little more detail.  That can be a separate patch, of course.
>

The current kernel only supports:

static const match_table_t nfs_xprt_protocol_tokens = {
	{ Opt_xprt_udp, "udp" },
	{ Opt_xprt_udp6, "udp6" },
	{ Opt_xprt_tcp, "tcp" },
	{ Opt_xprt_tcp6, "tcp6" },
	{ Opt_xprt_rdma, "rdma" },

	{ Opt_xprt_err, NULL }
};


So it seems reasonably just to list those.  nfs-tuils seems to support rdma6
too, so I assume that is coming soon to a kernel near me.

So how about we drop the reference to netconfig (though leave it in SEE ALSO)
and just be explicit about the short list.  That means 'rdma' is no longer a
special case.
??

Thanks,
NeilBrown

From 3d2fb5a4a091f00494c0f655e4a02041c1f05aa3 Mon Sep 17 00:00:00 2001
From: Neil Brown <neilb@suse.de>
Date: Tue, 2 Oct 2012 15:21:46 +1000
Subject: [PATCH] mount.nfs mapage: clear up confusion between 'proto' and
 'transport'

The mount option "proto=" actually set the "transport" which in
netconfig usage is the paring of a protocol (e.g. UDP, TCP) with
a protocol family (e.g. INET, INET6).

This can cause confusion if people naively except "proto=udp" to work
equally well on IPv6.

So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
clarify this.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index da6d6d3..11bbfc6 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -1,5 +1,5 @@
 .\"@(#)nfs.5"
-.TH NFS 5 "2 November 2007"
+.TH NFS 5 "19 September 2012"
 .SH NAME
 nfs \- fstab format and options for the
 .B nfs
@@ -472,24 +472,15 @@ Use these options, along with the options in the above subsection,
 for NFS versions 2 and 3 only.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-The value "rdma" may also be specified.
-If the
-.B mount.nfs
-command does not have TI-RPC support, then
+The
 .I netid
-is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Available options are
+.BR udp ", " udp6 ", "tcp ", " tcp6 ", " rdma ", and " rdma6 .
+Those which end in
+.B 6
+use IPv6 addresses and are only available if support for TI-RPC is
+built in. Others use IPv4 addresses.
 .IP
 Each transport protocol uses different default
 .B retrans
@@ -573,15 +564,14 @@ The transport protocol name and protocol family the NFS client uses
 to transmit requests to the NFS server's mountd service when performing
 this mount request, and when later unmounting this mount point.
 .IP
-If support for TI-RPC is built into the
+.I netid
+may be one of
+.BR udp ", " tcp ", and " rdma
+which use IPv4 address or, if TI-RPC is built into the
 .B mount.nfs
 command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
-.I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+.BR udp6 ", " tcp6 ", and " rdma6
+which use IPv6 addresses.
 .IP
 This option can be used when mounting an NFS server
 through a firewall that blocks a particular transport.
@@ -773,21 +763,15 @@ Use these options, along with the options in the first subsection above,
 for NFS version 4 and newer.
 .TP 1.5i
 .BI proto= netid
-The transport protocol name and protocol family the NFS client uses
-to transmit requests to the NFS server for this mount point.
-If an NFS server has both an IPv4 and an IPv6 address, using a specific
-netid will force the use of IPv4 or IPv6 networking to communicate
-with that server.
-.IP
-If support for TI-RPC is built into the
-.B mount.nfs
-command,
-.I netid
-is a valid netid listed in
-.IR /etc/netconfig .
-Otherwise,
+The
 .I netid
-is one of "tcp" or "udp," and only IPv4 may be used.
+determines the transport that is used to communicate with the NFS
+server.  Available options are
+.BR udp ", " udp6 ", "tcp ", " tcp6 ", " rdma ", and " rdma6 .
+Those which end in
+.B 6
+use IPv6 addresses and are only available if support for TI-RPC is
+built in. Others use IPv4 addresses.
 .IP
 All NFS version 4 servers are required to support TCP,
 so if this mount option is not specified, the NFS version 4 client
@@ -851,6 +835,8 @@ The DATA AND METADATA COHERENCE section discusses
 the behavior of this option in more detail.
 .TP 1.5i
 .BI clientaddr= n.n.n.n
+.TP 1.5i
+.BI clientaddr= n:n: ... :n
 Specifies a single IPv4 address (in dotted-quad form),
 or a non-link-local IPv6 address,
 that the NFS client advertises to allow servers
diff --git a/utils/mount/nfsmount.conf.man b/utils/mount/nfsmount.conf.man
index 12a3fe7..2258296 100644
--- a/utils/mount/nfsmount.conf.man
+++ b/utils/mount/nfsmount.conf.man
@@ -1,5 +1,5 @@
 .\"@(#)nfsmount.conf.5"
-.TH NFSMOUNT.CONF 5 "9 Mar 2008"
+.TH NFSMOUNT.CONF 5 "19 September 2012"
 .SH NAME
 nfsmount.conf - Configuration file for NFS mounts
 .SH SYNOPSIS
@@ -18,6 +18,10 @@ to particular variables using the
 .BR = 
 operator, as in 
 .BR Proto=Tcp .
+The variables that can be assigned are exactly the set of NFS specific
+mount options listed in
+.BR nfs (5).
+.PP
 Sections are broken up into three basic categories:
 Global options, Server options and Mount Point options.
 .HP
@@ -54,7 +58,7 @@ are defined in the configuration file.
     Proto=Tcp
 .RS
 .HP
-The TCP protocol will be used on every NFS mount.
+The TCP/IPv4 protocol will be used on every NFS mount.
 .HP
 .RE
 [ Server \(lqnfsserver.foo.com\(rq ]
@@ -62,10 +66,13 @@ The TCP protocol will be used on every NFS mount.
     rsize=32k
 .br
     wsize=32k
+.br
+    proto=udp6
 .HP
 .RS
-A 33k (32768 bytes) block size will be used as the read and write
-size on all mounts to the 'nfsserver.foo.com' server.
+A 32k (32768 bytes) block size will be used as the read and write
+size on all mounts to the 'nfsserver.foo.com' server.  UDP/IPv6
+is the protocol to be used.
 .HP
 .RE
 .BR 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]