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

From: [email-masked]
Date: Mon, 18 Oct 2010 10:45:20 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : NFS operation over IPv4 and IPv6
	Author(s)       : A. RN, et al.
	Filename        : draft-ietf-nfsv4-ipv4v6-00.txt
	Pages           : 14
	Date            : 2010-10-18

This Internet-Draft provides the description of problem set faced by
NFS and its various side band protocols when implemented over IPv4
and IPv6 networks in various deployment scenarios.  Solution to the
various problems are also given in the draft and are sought for
approval in the respective NFS and side band protocol versions.

Foreword

This "forward" section is an unnumbered section that is not included
in the table of contents.  It is primarily used for the IESG to make
comments about the document.  It can also be used for comments about
the status of the document and sometimes is used for the RFC2119
requirements language statement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ipv4v6-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 18 Oct 2010 14:28:05 -0500

Minor nits:

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.

----

Page 10:

   instead of the client IP address, for the indexing, as explained here
   -

   As mentioned in Client Identification (Section 6) -

   The client SHOULD always send the same client string, irrespective of
I can't tell if this is bad formatting or if two paragraphs are missing.

----

   There are scenarios where NFS implementations need to store IP
   addresses in persistent storage, like -

   NSM monitor/notify database.

   persistent reply cache.

I believe you want this lettered.

-------

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?

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.

---------

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.

---

From: sfaibish <[email-masked]>
Date: Mon, 18 Oct 2010 15:41:26 -0400

Tom and Spencer,

I propose to have a discussion on this topic at the IETF meeting. 10  
minutes
should be enough. I have a problem with pushing this to 4.2 when we may  
need
to address the issue sooner.

/Sorin

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 18 Oct 2010 15:53:13 -0400

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

> than the 192.168.2.15 on the client's e1.

This is why relying on advertising of private nets via RPCBIND is bad.

Cheers
  Trond

---

From: "Spencer Shepler" <[email-masked]>
Date: Mon, 18 Oct 2010 12:59:17 -0700

Sorin,

Is the information or position you plan to present unsuitable for
the initial discussion via the WG alias?  My preference is that
we start here and finish at the WG meeting to trim a few weeks
from closing on these items.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> sfaibish
> Sent: Monday, October 18, 2010 12:41 PM
> To: Thomas Haynes
> Cc: [email-masked]
> Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
> 
> Tom and Spencer,
> 
> 
> minutes should be enough. I have a problem with pushing this to 4.2 when
> we may need to address the issue sooner.
> 
> /Sorin
> 
> >    The client SHOULD always send the same client string, irrespective
> > of I can't tell if this is bad formatting or if two paragraphs are
> missing.
> >
> >
> > ----
> >
> > 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?
> >
> > 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.
> >
> > ---------
> >
> > 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.
> >
> 
> 
> 
> --
> Best Regards
> 
> Sorin Faibish
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: sfaibish <[email-masked]>
Date: Mon, 18 Oct 2010 16:11:43 -0400

I had the intention to start a discussion and there it is a WG draft
before I had the chance to post the discussion we had at BAT.
I want to be sure that we all understand and address the same issue.
Thanks

/Sorin

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Oct 2010 15:19:56 -0500

> Minor nits:

Add this to the nist list: "Foreword" is mispelled (as "forward") in the
Foreword.

> I find the (a) a) to be confusing.

+1 regarding (a) a).

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

> might be a different private subnet than the 192.168.2.15 on the

See below.

> single stack mode topologies as well. I.e., all current multi-homed

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 {1.2.3.4, 10.20.30.40} and
   {1.2.3.5, 10.20.30.40} respectively, then they are necessarily
   different servers, even if they should both happen to claim the same
   UUID.  The servers might use 10.20.30.40 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.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 18 Oct 2010 16:28:09 -0400

> remaining non-port-2049 protocols and resulting firewall complexity.

This was already done in NFSv4.1.

> avoid creating same-client conflicts by referring to the same server via

As I said earlier, this too is a problem that was supposed to be
resolved by the introduction of EXCHANGE_ID in NFSv4.1. So what is the
hole in the current spec that causes the multi-homed server issue to be
broken?

Trond

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 18 Oct 2010 22:40:46 -0500

Sorin,

Just to be clear, the discussions we had at the BAT were under NDA. They
were in no part IETF discussions. If you want to post anything from the BAT,
you will need permission from everyone present. If you didn't take roll for
a specific talk, then you will have to get a release from everyone who could
have been present.

BTW - this is why the talks at ConnectAThon are held in a different room
than the testing and are clearly labeled as public.

Thanks,
Tom

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 18 Oct 2010 22:45:56 -0500

> hole in the current spec that causes the multi-homed server issue to be

Trond,

Sorry, I was just reacting to the presentation in the draft. But that raises
another question, why doesn't the draft address NFSv4.1 and EXCHANGE_ID?

Tom

---

From: dhawal bhagwat <[email-masked]>
Date: Tue, 19 Oct 2010 15:00:22 +0530 (IST)

>} Date: Mon, 18 Oct 2010 14:28:05 -0500
>} From: Thomas Haynes <[email-masked]>
>} Cc: [email-masked]
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
>} 
>} Minor nits:
>} 
>} 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.
>} 

Noted; will correct that in the next version.  ... 

>} ----
>} 
>} Page 10:
>} 
>}    instead of the client IP address, for the indexing, as explained here
>}    -
>} 
>}    As mentioned in Client Identification (Section 6) -
>} 
>}    The client SHOULD always send the same client string, irrespective of
>} I can't tell if this is bad formatting or if two paragraphs are missing.

No missing text/paragraphs there.  I suppose it would have been better 
formatted this way -- 

As mentioned in Client Identification (Section 6) - The client SHOULD 
always send the same client string, irrespective of

Will try to sort that out in the next version.  ... 

>} 
>} 
>} ----
>} 
>}    There are scenarios where NFS implementations need to store IP
>}    addresses in persistent storage, like -
>} 
>}    NSM monitor/notify database.
>} 
>}    persistent reply cache.
>} 
>} I believe you want this lettered.

Noted; will correct that in the next version.  ... 

The remaining points below; I'll respond to the subsequent posts.

thanks,

-dhawal.

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

---

From: dhawal bhagwat <[email-masked]>
Date: Tue, 19 Oct 2010 16:57:16 +0530 (IST)

>} Date: Mon, 18 Oct 2010 22:45:56 -0500
>} To: Trond Myklebust <[email-masked]>
>} Cc: [email-masked], Nicolas Williams <[email-masked]>
>} On Oct 18, 2010, at 3:28 PM, Trond Myklebust wrote:
>} 
>} > On Mon, 2010-10-18 at 15:19 -0500, Nicolas Williams wrote:
>} >> On Mon, Oct 18, 2010 at 02:28:05PM -0500, Thomas Haynes wrote:
>} >>> Minor nits:
>} >> 
>} >>> 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 {1.2.3.4, 10.20.30.40} and
>} >>   {1.2.3.5, 10.20.30.40} respectively, then they are necessarily
>} >>   different servers, even if they should both happen to claim the same
>} >>   UUID.  The servers might use 10.20.30.40 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.
>} > 
>} > As I said earlier, this too is a problem that was supposed to be
>} > resolved by the introduction of EXCHANGE_ID in NFSv4.1. So what is the
>} > hole in the current spec that causes the multi-homed server issue to be
>} > broken?
>} > 
>} > Trond
>} > 
>} 
>} Trond,
>} 
>} Sorry, I was just reacting to the presentation in the draft. But that raises
>} another question, why doesn't the draft address NFSv4.1 and EXCHANGE_ID?

Our focus in the draft was problems we faced when doing our implementation 
- which covered NFSv3 and v4.  And how to solve those problems for v3 and 
v4.  If any of the problems have been solved in v4.1, those can be noted 
as such, but solutions for v3 and v4 would still be useful, we think.

thanks,

-{db}.

>} 
>} Tom
>} 
>} _______________________________________________
>} nfsv4 mailing list
>} [email-masked]
>} https://www.ietf.org/mailman/listinfo/nfsv4
>} 
>}

---

From: "Spencer Shepler" <[email-masked]>
Date: Tue, 19 Oct 2010 21:00:48 -0700

I believe that Sorin and I sorted this out off-list.
There are separate issues/items and I believe I have the
WG agenda updated to reflect this fact.  If not, please
let me know.

Spencer

> From: sfaibish [mailto:[email-masked]]
> Sent: Monday, October 18, 2010 1:12 PM
> To: Spencer Shepler; 'Thomas Haynes'
> Cc: [email-masked]

---

From: dhawal bhagwat <[email-masked]>
Date: Thu, 28 Oct 2010 03:28:35 +0530 (IST)

>} Date: Mon, 18 Oct 2010 15:53:13 -0400
>} From: Trond Myklebust <[email-masked]>
>} To: Thomas Haynes <[email-masked]>
>} Cc: [email-masked]
>} 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?

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

thanks,

-{db}.

>} Cheers
>}   Trond

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 27 Oct 2010 18:19:55 -0400

> 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?

> (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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 27 Oct 2010 18:48:08 -0400

> 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

---

From: dhawal bhagwat <[email-masked]>
Date: Thu, 28 Oct 2010 13:57:31 +0530 (IST)

>} Date: Wed, 27 Oct 2010 18:19:55 -0400
>} To: dhawal bhagwat <[email-masked]>
>} Cc: Thomas Haynes <[email-masked]>, [email-masked]
>} On Thu, 2010-10-28 at 03:28 +0530, dhawal bhagwat wrote:
>} > >} Date: Mon, 18 Oct 2010 15:53:13 -0400
>} > >} From: Trond Myklebust <[email-masked]>
>} > >} To: Thomas Haynes <[email-masked]>
>} > >} Cc: [email-masked]
>} > >} 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}.

---

From: dhawal bhagwat <[email-masked]>
Date: Thu, 28 Oct 2010 14:10:36 +0530 (IST)

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

>} Date: Wed, 27 Oct 2010 18:48:08 -0400
>} From: Trond Myklebust <[email-masked]>
>} 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 <[email-masked]>
>} > > >} To: Thomas Haynes <[email-masked]>
>} > > >} Cc: [email-masked]
>} > > >} 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}.