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

[dhawal bhagwat <[e-mail]>]

>} Date: Wed, 27 Oct 2010 18:19:55 -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 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?

In such a setup, you would have problems with all communications with any 
host in your office (VPN) network, that has an IP matching something on 
your LAN.  An office RPCBIND returning private addresses seems comparable 
to an office DNS returning private addresses; does relying on private 
addresses returned by DNS raise similar concerns?


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

RPCBIND cannot take care of it for IPv4 private addresses -- for the 
reason you state.  But for IPv6 link local addresses, RPCBIND can look at 
the zone to track which interface say a GETADDRLIST call came in on (#); 
when responding to that call, RPCBIND can try to ensure that it will not 
return link local addresses of links other than the one on which the call 
came in.

# - For that, RPCBIND will need to look at the address info at the 
network layer, not just the address that comes in the GETADDRLIST call.  
That also means the implementation has to maintain / propogate the zone 
information in the system.

thanks,

-{db}.


>} 
>} Trond
>} 
>} 
>}