Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt

[Nicolas Williams <[e-mail]>]

On Mon, Oct 18, 2010 at 02:28:05PM -0500, Thomas Haynes wrote:
> Minor nits:

Add this to the nist list: "Foreword" is mispelled (as "forward") in the
Foreword.

> Page 7:
> 
>         same server identifier.  An example of well generated server
>         identifier can be the one that includes the following:
>    (c)
>         (a)  a) MAC address
>         (b)  b) Machine serial number
> 
> I would expect these items to be part of (b) above (The ':' gives me that expectation).
> 
> I find the (a) a) to be confusing.

+1 regarding (a) a).

> A larger question on the draft as a whole would be whether we could
> add some additional operations to NFSv4.2 to get rid of the guessing.
> I.e., could a client send a server a list of IPv4 and IPv6 addresses
> that it is using and in return the server respond with the equivalence
> addresses that it is using?

We could move the status/lock callbacks into NFS proper.  That way we
need never have communications initiated by the server.  That would be
very useful for firewalling in general, and it'd help get rid of the
remaining non-port-2049 protocols and resulting firewall complexity.

> One issue I can see is that the machines might be on different subnets
> that use the same IP addresses. I.e., 192.168.2.14 on the filer's e0a
> might be a different private subnet than the 192.168.2.15 on the
> client's e1.

See below.

> Finally, it is understated, so I think you should bring more attention
> to it, but the problem you deal with in Section 6 applies to symmetric
> single stack mode topologies as well. I.e., all current multi-homed
> IPv4 deployments.

Yes.  This should be solved in NFSv4.2 if at all possible.  Some
suggestions for how to solve this problem:

 - have an operation by which the server can list its IP addresses to
   the client

 - have a server UUID

 - both of the above, so that clients could ID servers by {server-
   address-list, server-UUID}, which is bound to be unique for all
   servers, even when private addresses overlap.

   If two servers claim to speak NFS on {1.2.3.4, 10.20.30.40} and
   {1.2.3.5, 10.20.30.40} respectively, then they are necessarily
   different servers, even if they should both happen to claim the same
   UUID.  The servers might use 10.20.30.40 on distinct subnets for
   backup purposes.

This would improve server multi-homing support in NFSv4.  Clients could
avoid creating same-client conflicts by referring to the same server via
different addresses.

Nico
--