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

[dhawal bhagwat <[e-mail]>]

>} Date: Mon, 18 Oct 2010 15:45:07 -0400
>} From: Trond Myklebust <[e-mail]>
>} To: [e-mail]
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-00.txt
>} 
>} On Mon, 2010-10-18 at 10:45 -0700, [e-mail] wrote:
>} > 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 IPv6
>} > 	Author(s)       : A. RN, et al.
>} > 	Filename        : draft-ietf-nfsv4-ipv6-00.txt
>} > 	Pages           : 8
>} > 	Date            : 2010-10-18
>} > 
>} > This Internet-Draft provides the description of problems faced by NFS
>} > and its various side band protocols, when implemented over IPv6 in
>} > various deployment scenarios.  Solutions to the various problems are
>} > also given in the draft and are sought for approval.
>} > 
>} > 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-ipv6-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.
>} 
>} The RPCBIND requirement (MUST) is definitely unwelcome. The whole point
>} of giving NFSv4 a fixed port was in order to get rid of the reliance on
>} portmapping.

Noted.  Our intent was to say that if a portmap call is being made, then 
in case of NFS/IPv6, it MUST be via RPCBIND.  ... 


>} 
>} There is nothing in the document that justifies the prohibition on using
>} IPv4 embedded IPv6 addresses.

---
   The netid and address formats in the RPCBINDv3/4 procedures, MUST be
   as per those defined for netid and universal addresses, in netid_ID
   draft [netid_ID].  The implementation MUST NOT use IPv4 embedded IPv6
   addresses defined in Section 2.5.5 [RFC4291], for the RPCBINDv3/4
   procedures.
---

In the first part, we are saying the address format MUST be as per that 
defnied in [netid_ID] (RFC5665).

As there is no way in RPCBIND for one side to convey to the other what 
address format is being used, that then implies that any other address 
formats (like the IPv4 embedded IPv6 address), are ruled out.  ... 


>} 
>} I don't understand the utility of the paragraph:
>}                 While making a callback to an address received in a NLM
>}                 LOCK call or a NFSv4 SETCLIENTID call, a server MUST
>}                 specify the local interface via which the call needs to
>}                 be made (or let the default zone be selected, if
>}                 supported).
>} In NFSv4, if the server is calling the client back, then it is the one
>} initiating the TCP connection. There is no need for (nor is there even a
>} mechanism for) specifying on which interface the client must reply to
>} the RPC call.

The text needs to be made more clear; it refers to implementation within 
the server.  Note that this paragraph is under the "Handling of link-local 
addresses in multi-homed hosts" section.  We are talking of

' ... making a callback to a (link-local) address received in a NLM LOCK 
call or a NFSv4 SETCLIENTID call'.

What we are saying there is that the server must convey to the lower 
layers (network and below), the local interface (at the server end) using 
which the callback needs to be initiated to the client.

thanks,

-{db}.


>} 
>} Cheers
>}   Trond
>} 
>} _______________________________________________
>} nfsv4 mailing list
>} [e-mail]
>} https://www.ietf.org/mailman/listinfo/nfsv4
>} 
>}