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

[dhawal bhagwat <[e-mail]>]

Had not seen this when I replied to the previous post.  ... 


>} Date: Wed, 27 Oct 2010 18:48:08 -0400
>} From: Trond Myklebust <[e-mail]>
>} To: dhawal bhagwat <[e-mail]>
>} Cc: Thomas Haynes <[e-mail]>, [e-mail]
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
>} 
>} 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.

Ok, this seems similar to what we are suggesting for IPv6 link local 
addresses (what I mentioned in my reply to your previous post) -- for 
IPv4, RPCBIND can try to look at the address from which it received a 
call, and decide which private addresses to advertise, accordingly.

thanks,

-{db}.


>} 
>} Cheers
>}   Trond
>} 
>} 
>}