Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-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 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.

---

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

> implementation to automatically retrieve the ASCII version of the

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.

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

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.

Cheers
  Trond

---

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

>} Date: Mon, 18 Oct 2010 15:45:07 -0400
>} From: Trond Myklebust <[email-masked]>
>} To: [email-masked]
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-00.txt
>} 
>} On Mon, 2010-10-18 at 10:45 -0700, [email-masked] 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
>} [email-masked]
>} https://www.ietf.org/mailman/listinfo/nfsv4
>} 
>}

---

From: Chuck Lever <[email-masked]>
Date: Tue, 19 Oct 2010 11:02:38 -0400

> in case of NFS/IPv6, it MUST be via RPCBIND.  ... 

Curious, is it really necessary to stipulate that?  Have you encountered IPv6 implementations that attempt to resolve ports with PORTMAP over IPv6 ?

I suppose this is relevant for implementations that are not based on a full TI-RPC implementation, but have purpose-built portmap clients and RPC layers.

-- 
chuck[dot]lever[at]oracle[dot]com

---

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

(Sorry for the delay in responding.)  ... 

>} Date: Tue, 19 Oct 2010 11:02:38 -0400
>} From: Chuck Lever <[email-masked]>
>} To: dhawal bhagwat <[email-masked]>
>} Cc: Trond Myklebust <[email-masked]>, [email-masked]
>} On Oct 19, 2010, at 8:25 AM, dhawal bhagwat wrote:
>} 
>} > 
>} >> } Date: Mon, 18 Oct 2010 15:45:07 -0400
>} >> } From: Trond Myklebust <[email-masked]>
>} >> } To: [email-masked]
>} >> } Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-00.txt
>} >> } 
>} >> } On Mon, 2010-10-18 at 10:45 -0700, [email-masked] 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.  ... 
>} 
>} Curious, is it really necessary to stipulate that?  Have you 
>} encountered IPv6 implementations that attempt to resolve ports with 
>} PORTMAP over IPv6 ?
>} 
>} I suppose this is relevant for implementations that are not based on a 
>} full TI-RPC implementation, but have purpose-built portmap clients and 
>} RPC layers.

We have not seen implementations making PORTMAP calls over IPv6.

We felt that rather than have some implementation pop up using 
PORTMAP/IPv6 (#), expecting other implementations to support it, it would 
be better not to leave that open ended, and instead, clearly require the 
use of RPCBIND in case of IPv6.

(# - for some reason like the one you already mentioned.)

thanks,

-{db}.

>} 
>} -- 
>} chuck[dot]lever[at]oracle[dot]com
>}