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

[Trond Myklebust <[e-mail]>]

On Mon, 2010-10-18 at 15:19 -0500, Nicolas Williams wrote:
> 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.

This was already done in NFSv4.1.

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

As I said earlier, this too is a problem that was supposed to be
resolved by the introduction of EXCHANGE_ID in NFSv4.1. So what is the
hole in the current spec that causes the multi-homed server issue to be
broken?

Trond