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

[Trond Myklebust <[e-mail]>]

On Wed, 2010-10-27 at 18:19 -0400, Trond Myklebust wrote:
> On Thu, 2010-10-28 at 03:28 +0530, dhawal bhagwat wrote:
> > >} Date: Mon, 18 Oct 2010 15:53:13 -0400
> > >} From: Trond Myklebust <[e-mail]>
> > >} To: Thomas Haynes <[e-mail]>
> > >} Cc: [e-mail]
> > >} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
> > >} 
> > >} On Mon, 2010-10-18 at 14:28 -0500, Thomas Haynes wrote:
> > >} 
> > >} > 
> > >} > 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?
> > >} > 
> > >} 
> > >} Why does the server need this information? The NFSv4.1 protocol does not
> > >} provide for server-initiated callbacks. All communication channels (i.e.
> > >} TCP connections) are initiated by the client in NFSv4.1.
> > >} 
> > >} Furthermore, EXCHANGE_ID already provides a mechanism to allow the
> > >} client to discover that 2 IP addresses point to the same server. This
> > >} mechanism even works independently of the actual transport mechanism
> > >} used, so it will work with RDMA and other possible future transport
> > >} mechanisms too.
> > >} 
> > >} > 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.
> > >} 
> > >} This is why relying on advertising of private nets via RPCBIND is bad.
> > 
> > Is this for RPCBIND to worry about?  Shouldn't setups like the one 
> > described above be separated into different IP spaces?  Within the same IP 
> > space, the above I believe is a incorrect network config -- how would 
> > hosts in one of those subnets, route to those in the other subnet?
> > 
> > If private subnets are properly configured, will there be a problem with 
> > RPCBIND advertising private addresses?
> 
> Consider the (common) case where I'm VPNed in to my office, but have a
> local connection to my home LAN so that I can access my NAS box, my
> printer etc. Is that an 'incorrect network config'?
> 
> If I then try to connect to an office NFS server, and its RPCBIND starts
> telling me to connect via an IP address that matches something on my LAN
> (and I start treating my NAS box as a replica of the office server),
> then who configured what incorrectly?
> 
> > For IPv6 however, there is the issue of RPCBIND advertising IPv6 
> > link local addresses across links -- that is for RPCBIND to explicitly 
> > take care of.  We have talked of this issue in the other draft 
> > (draft-ietf-nfsv4-ipv6-00.txt).
> 
> I can't see how RPCBIND can take care of anything. If it wants to
> advertise something on a private network, then it needs to know about my
> client's ability to route to the correct object on that private network.
> Advertising stuff on a global net doesn't have that problem, because the
> routing tables are globally defined.

To try to move this along: I'd see no problems with advertising
addresses on multiple global subnets.

However if the RPCBIND is going to advertise private subnets, then
AFAICS, the only safe situation is:

      * All the addresses advertised as being equivalent must be on the
        same subnet, or must be global addresses.
      * The private subnet is advertised by RPCBIND only through
        addresses on that same private subnet. If the client accesses
        RPCBIND through a different subnet, then it should not see the
        private subnet advertised.

Cheers
  Trond