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

Nicolas Williams <> Mon, 18 October 2010 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B66F3A6B02 for <>; Mon, 18 Oct 2010 13:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Thc3bW+INJq3 for <>; Mon, 18 Oct 2010 13:19:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 936393A6BF8 for <>; Mon, 18 Oct 2010 13:19:11 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9IKKcqM013923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Oct 2010 20:20:40 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9IKKbZ6006538; Mon, 18 Oct 2010 20:20:37 GMT
Received: from by with ESMTP id 699941231287433201; Mon, 18 Oct 2010 13:20:01 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Oct 2010 13:20:00 -0700
Date: Mon, 18 Oct 2010 15:19:56 -0500
From: Nicolas Williams <>
To: Thomas Haynes <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Oct 2010 20:19:16 -0000

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

> 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., on the filer's e0a
> might be a different private subnet than the 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 {,} and
   {,} respectively, then they are necessarily
   different servers, even if they should both happen to claim the same
   UUID.  The servers might use 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.