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

[Trond Myklebust <[e-mail]>]

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.

Trond