[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             Alex RN, Ed.
Internet-Draft                                         Bhargo Sunil, Ed.
Intended status: Standards Track                          Dhawal Bhagwat
Expires: April 21, 2011                                     Dipankar Roy
                                                       Rishikesh Barooah
                                                                  NetApp
                                                        October 18, 2010


                    NFS operation over IPv4 and IPv6
                     draft-ietf-nfsv4-ipv4v6-00.txt

Abstract

   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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Alex RN, et al.          Expires April 21, 2011                 [Page 1]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   This Internet-Draft will expire on April 21, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Alex RN, et al.          Expires April 21, 2011                 [Page 2]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Various Deployment Scenarios . . . . . . . . . . . . . . . . .  4
   4.  PORTMAP and RPCBIND  . . . . . . . . . . . . . . . . . . . . .  5
   5.  NLM and NSM  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Client Identification  . . . . . . . . . . . . . . . . . . . .  6
   7.  Dual to single stack mode transition . . . . . . . . . . . . .  8
   8.  NFSv4 Callback Information . . . . . . . . . . . . . . . . . .  9
   9.  Reply cache tuples for NFSv4 . . . . . . . . . . . . . . . . .  9
   10. Other optimizations  . . . . . . . . . . . . . . . . . . . . . 10
     10.1.  Address Persistence . . . . . . . . . . . . . . . . . . . 10
     10.2.  IP addresses as keys  . . . . . . . . . . . . . . . . . . 11
     10.3.  NFSv4 Id Mapping  . . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13





























Alex RN, et al.          Expires April 21, 2011                 [Page 3]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


1.  Terminology

   Host: Used to refer to the client or the server where the specific(s)
   of client or the server does not matter.

   IPv4: Internet Protocol Version 4.

   IPv6: Internet Protocol Version 6.

   NFS: Used to refer to Network File System irrespective of the
   version.

   NFSv2: Network File System Protocol Version 2.

   NFSv3: Network File System Protocol version 3.

   NFSv4: Network File System Protocol version 4.

   NFSv4.1: Network File System Protocol version 4.1.

   NLM: Network Lock Manager Protocol.

   NSM: Network Status Monitor Protocol.

   Operation: Refers to the NFS operation when its mode of request or
   response is inconsequential.


2.  Introduction

   This draft addresses problems associated with operating NFS in an
   environment that has a mix of IPv4 and IPv6.


3.  Various Deployment Scenarios

   The various deployment scenarios involving a mix of IPv4 and IPv6,
   are as follows:

   (a)  Client in IPv4-only network and Server in IPv6-only network.
   (b)  Client in IPv6-only network and Server in IPv4-only network.
   (c)  Client in IPv4 and IPv6 capable network and Server too in IPv4
        and IPv6 capable network.

   The first two scenarios can be called asymmetric single stack mode.
   The third scenario can be called dual stack mode.

   Note: These scenarios -



Alex RN, et al.          Expires April 21, 2011                 [Page 4]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   (a)  Client in IPv4-only network and Server in IPv4-only network.
   (b)  Client in IPv6 only network and Server in IPv6-only network.

   can be referred to as symmetric single stack mode.  They are not
   discussed in this document, as the focus of this document is
   scenarios that have a mix of IPv4 and IPv6.

   The problems discussed below are primarily related to sharing of NFS
   state across different protocol address families.  State come into
   picture in NFS, in case of NLM/NSM, and NFSv4.


4.  PORTMAP and RPCBIND

   Clients SHOULD use PORTMAP (version 2) while querying IPv4 server
   addresses, and RPCBIND (version 3/4) while querying IPv6 server
   addresses.

   Similarly, servers should use PORTMAP (version 2) while querying
   clients for making callbacks to IPv4 client addresses and RPCBIND
   (version 3/4) while querying clients making callbacks to IPv6 client
   addresses.

   Callbacks from server to client are needed in case of port
   information verification (NFSv4), asynchronous lock requests (NLM),
   and delegation recalls (NFSv4).


5.  NLM and NSM

   Clients and servers should use the "caller_name" (in the NLM_LOCK
   call), and the "mon_name" (in the SM_NOTIFY call) as the identity of
   the caller.  This will make the identify of the caller independent of
   the protocol address family, and will help in proper operation in the
   situations described below in this section.

   A dual stack NSM server implementation with persistent recording of
   source IP address, SHOULD record at least one IPv4 and one IPv6
   address for the client (from the caller_name in the NLM_LOCK
   request), so that in case of a reboot, it can send out NOTIFY
   messages to the client via either/both protocol address families.

   This will ensure proper operation in scenarios like these :








Alex RN, et al.          Expires April 21, 2011                 [Page 5]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   (a)  Client1 connects to the server using IPv6 address.
   (b)  Client2 connects to the server using IPv4 address.
   (c)  The server switches from dual stack to single stack mode of
        operation.
   (d)  Server restarts.

   Step 'c' can happen due to a network or interface disruption, or it
   could also happen as part of step 'd' (due to administrative action
   during step 'd').  Either way, it will result in loss of ability of
   the server to communicate with the clients via one of the protocol
   address families.

   To handle such scenarios, the server SHOULD associate one IP address
   for each protocol address family, with the client (caller_name from
   the NLM_LOCK call).  Otherwise, after step 'd', the server will not
   be able to send a SM_NOTIFY to some of the clients.  This will result
   in those clients incorrectly assuming that the server is holding
   their locks, when infact the server is not.

   When clients receive a SM_NOTIFY from a server via one address
   family, they SHOULD try to determine whether they hold locks on that
   server (mon_name in the SM_NOTIFY call) via the other address family,
   and if so, they SHOULD reclaim those locks too from the server.

   Similarly, to handle the scenario where a dual stack client switches
   to a single stack mode, and restarts, a server, when it receives a
   SM_NOTIFY from a client on one address family, should try to
   determine whether it holds any lock for that client (mon_name in the
   SM_NOTIFY call), on another address family, and if so, it should
   clear those locks too.


6.  Client Identification

   In the case of NFSv4.1, the short hand clientid is very similar to
   NFSv4.0 clientid.  Since states are tied to clientid, state sharing
   across and within sessions are immune to individual connection
   failures.  The sessions from individual connections of an address
   family can be failed over to another address family if available.

   For NFSv4 however, RFC3530 [RFC3530] says - that a client MUST send a
   different client string in SETCLIENTID to a different destination
   addresses(s)/family of address(s).  Even if the same server is
   servicing on a different network address/address family the server
   MUST return a different clientid to the client.  This is to prevent
   confusion on the client side as there is no way of determining
   whether the server to which the client is connecting again is the
   same or not.



Alex RN, et al.          Expires April 21, 2011                 [Page 6]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   The client using different client strings for different network
   addresses / address families might result in a case that the multiple
   requests from the same client conflict with each other on a
   multihomed server, and result in revocation of delegation.  This can
   happen in this scenario:

   (a)  Client establishes a connection to server on address X and then
        opens the file Z in write mode.
   (b)  Server grants the client a write delegation.
   (c)  The connection the client had established with server address X
        in step a), breaks for some reason.  Client establishes another
        connection with server address Y, and then tries to open the
        file Z.

   In step c) as client is trying to connect to a different server
   address/address family, it would send the SETCLIENTID with different
   client string than in step a).  Since servers generate clientid based
   on client string, the clientid generated by the server in step c)
   will be different than the clientid generated by the server in step
   a).  The server will then end up revoking the delegation granted in
   step b).

   Step c) can happen if the client side faced a disruption on one of
   its address families and then connected on a different address family
   to the server.  Example would be client connected using IPv6 in step
   a) and then client IPv6 stack or interfaces faced disruption after
   step b).  Client then used IPv4 to connect to the server in step c).

   To handle such scenarios, the implementations should do the following
   -

   (a)  The client SHOULD use the same client string irrespective of
        which server address or address family it is communicating with.
   (b)  For generating the clientid, the server SHOULD use a combination
        of the client string with its own server identifier.  The server
        identifier should be generated in a unique way on similar lines
        as that of the client identifier.  Specifically the server
        identifier should be such that no two servers should use the
        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
   (d)  The client SHOULD always send the SETCLIENTID as the first
        request on the connection; even if the client is retransmitting
        the request.  If the clientid returned by server is the same as
        a clientid that the client has received from some server in the
        past, the client SHOULD conclude that both the connections are



Alex RN, et al.          Expires April 21, 2011                 [Page 7]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


        to the same server.  To prevent the server from expunging the
        client due to non renewal, the client should send a RENEW even
        if it does not have a lease after a SETCLIENTID to the server.

   With the above mechanism, in the preceding example, the client string
   in step c) would have been the same as step a) and therefore the
   server would not revoke the delegation granted in step b).
   Additionally, the clientid returned by the server in setp c) would be
   the same as that in step a), and so the client would know that it is
   communicating to the same server as in step a).


7.  Dual to single stack mode transition

   Dual stack implementations of NFS over IPv4 and IPv6 should ensure
   that the shutdown of one stack implementation does not leave any data
   in indeterminate state.  This means that state like locks that is
   shared between both IPv4 and IPv6 paths, should be handled carefully.
   A shutdown of one path could result in a partial or complete
   unreachability to the client, temporarily or permanently.  To allow
   for possible reconnects after reachability condition are restored,
   the states SHOULD be left intact.  To handle scenarios where
   reachability is not expected to be restored within any reasonable
   period of time, administrative action SHOULD be used for clearing the
   appropriate states (removal, cleanup etc).

   Shutting down of one address family stack, or loss of all interfaces
   of one address family, SHOULD NOT lead to NFSv4 client states being
   removed upon lease period expiry.  This is required so that server
   does not grant conflicting access to other clients via a different
   address family; otherwise, they may find data file to be in some
   inconsistent state, leading to corruption.

   Consider this scenario -

   a) An IPv6 client A is connected to the server and is accessing file
   X, and has some state on the server, for that file.

   b) The partial reachability condition happens for IPv6.

   c) An IPv4 client B connects to the server and tries to access file X
   on which the client A had states.

   If after step b), the server had removed the state, then client B
   might find the file to be in unusable state and so the state for
   client A should be maintained unless the disruption due to step b) is
   permanent, in which case the administrator needs to take some steps
   to check / restore file X to some proper state, and then clear the



Alex RN, et al.          Expires April 21, 2011                 [Page 8]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   state the server had for client A, for file X.

   For NFSv4, one of the ways to implement the above recommendation is
   that the server should mark the client and the states associated with
   it as temporarily unusable but should not remove the state associated
   with the clients in such case.  After the complete reachability is
   restored the server should go into partial restart case for only the
   clients that had their state marked as temporarily unusable and thus
   should allow such clients to regain their state.  The server should
   identify the clientid/states that are marked as temporarily unusable
   and should send those client the NFSERR_STALE_CLIENTID/
   NFSERR_STALE_STATEID errors, which will start the state recovery
   procedure on the client side.  The server can remove the client state
   if the clients have not recovered the state in the grace period after
   the complete reachability condition has been restored.

   For example, if the partial reachability condition affected only the
   clients accessing the server over IPv6, then after the reachability
   is restored, the grace period should be started only for the clients
   coming over IPv6.  Till the time the grace period completes, clients
   coming over IPv4, trying to take locks that conflict with ones being
   held by IPv6 clients, should be denied.

   In such cases, for NLM, the SM_NOTIFYs should be sent only to the
   IPv6 clients (the ones that were affected due to partial reachability
   condition).


8.  NFSv4 Callback Information

   The NFSv4 server implementation SHOULD verify the netid information
   in the callbacks corresponds to respective address families.  The
   netid used for IPv6 address SHOULD be tcp6 and for IPv4 addresses, it
   SHOULD be tcp.  Otherwise, the callback information SHOULD be
   rejected as incorrect.


9.  Reply cache tuples for NFSv4

   Reply cache implementations usually use some combination of elements
   like client address, client port, server address, protocol, RPC XID,
   etc., to index into the reply cache.  Use of the client IP usually
   has a drawback; for example, a client using a different source IP
   address + port while retransmitting a request, might result in a
   reply cache miss on the server.

   In environments where there is a mix of IPv4 and IPv6, there are
   greater chances of a server seeing a different source IP + port for a



Alex RN, et al.          Expires April 21, 2011                 [Page 9]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   client retransmission.  For example, one address family being
   completely disabled on a client, might cause the client to send
   retransmissions from a different address family (and therefore
   different source IP), as compared to the original request.

   Therefore, reply cache indexing mechanisms, that don't rely on client
   IP address, will add considerable value in environments having a mix
   of IPv4 and IPv6.  One alternative could be using the client string
   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
   the server address that it is communicating with.  Also, the NFSv4.0
   client should always send the SETCLIENTID procedure as the first
   request on any connection to the server.  If a request is to be
   retransmitted on a different connection, the first procedure sent out
   should be a SETCLIENTID with no change in the callback address or
   client string or verifier.  This will help the server to associate
   the new connection with the clientid.

   Once a connection is associated with an existing clientid (and
   therefore, an existing client string), any request restransmission on
   the new connection can then successfully be indexed to it's match in
   the reply cache, in a NFSv4 reply cache implementation that uses the
   client string instead of the client IP address, for indexing into the
   reply cache.


10.  Other optimizations

10.1.  Address Persistence

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

   NSM monitor/notify database.

   persistent reply cache.

   In such scenarios, to support dual stack mode, or a switch to/from
   it, implementations should store the protocol address family
   information explicitly, along with the IP address.  This information
   can be used during upgrades and downgrades, across versions which
   have may or may not have turned on support for NFS over IPv6.





Alex RN, et al.          Expires April 21, 2011                [Page 10]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


10.2.  IP addresses as keys

   Functionalities like export checks require information to be indexed
   based on client IP, for efficient insertion / updation, and lookup.

   When using IP addresses as keys in these scenarios, the variability
   of the bits in the IP addresses SHOULD be considered.  In IPv6, for
   the same interface, the different addresses might differ mostly in
   the subnet part (the lower order bits are often generated from the
   MAC address of the interface and are therefore mostly static).  In
   IPv4 however, that may not be the case.  Depending on the
   implementation specifics, different indexing algorithms might be
   needed for IPv4 and IPv6 addresses.

10.3.  NFSv4 Id Mapping

   The "dns_domain" in "user@dns_domain" as referred to in section 5.8
   [RFC3530], used to map owners, groups, users and user groups string
   principals, to internal representations (usually numeric id) at the
   client and server SHOULD be the same for the same client accessing an
   NFSv4 server simultaneously over IPv4 and IPv6.


11.  Acknowledgments

   The authors would like to acknowledge Mike Eisler for reviews of the
   various versions of the draft.


12.  IANA Considerations

   This memo includes no request to IANA.


13.  Security Considerations

   All considerations from RFC 3530 Section 16 [RFC3530]


14.  References

14.1.  Normative References

   [RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
              Version 3 Protocol Specification", RFC 1813, June 1995.

   [RFC1833]  Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
              RFC 1833, August 1995.



Alex RN, et al.          Expires April 21, 2011                [Page 11]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", BCP 14, RFC 2119, March 1997,
              <http://xml.resource.org/public/rfc/html/rfc2119.html>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              March 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4506]  Eisler, M., "XDR: External Data Representation Standard",
              STD 67, RFC 4506, May 2006.

   [RFC5378]  Bradner, S. and J. Contreras, "Rights Contributors Provide
              to the IETF Trust", BCP 78, RFC 5378, November 2008.

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, May 2009.

   [netid_ID]
              Eisler, M., "IANA Considerations for RPC Net Identifiers
              and Universal Address Formats",
              draft-ietf-nfsv4-rpc-netid-04 (work in progress),
              December 2008.

14.2.  Informative References

   [RFC1094]  Nowicki, B., "NFS: Network File System Protocol
              specification", RFC 1094, March 1989.

   [RFC2624]  Shepler, S., "NFS Version 4 Design Considerations",
              RFC 2624, June 1999.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.



Alex RN, et al.          Expires April 21, 2011                [Page 12]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   [RFC3542]  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
              "Advanced Sockets Application Program Interface (API) for
              IPv6", RFC 3542, May 2003.

   [RFC3593]  Tesink, K., "Textual Conventions for MIB Modules Using
              Performance History Based on 15 Minute Intervals",
              RFC 3593, September 2003.

   [RFC4620]  Crawford, M. and B. Haberman, "IPv6 Node Information
              Queries", RFC 4620, August 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.


Authors' Addresses

   Alex RN (editor)
   NetApp
   3rd Floor, Fair Winds Block, EGL Software Park,
   Bangalore, Karnataka  560071
   IN

   Phone: +91-80-41843352
   Email: rnalex@netapp.com


   Bhargo Sunil (editor)
   NetApp
   3rd Floor, Fair Winds Block, EGL Software Park,
   Bangalore, Karnataka  560071
   IN

   Phone: +91-80-41843963
   Email: bhargo@netapp.com


   Dhawal Bhagwat
   NetApp
   3rd Floor, Fair Winds Block, EGL Software Park,
   Bangalore, Karnataka  560071
   IN

   Phone: +91-80-41843134
   Email: dhawal@netapp.com






Alex RN, et al.          Expires April 21, 2011                [Page 13]


Internet-Draft           draft-ietf-nfsv4v6-ipv6            October 2010


   Dipankar Roy
   NetApp
   3rd Floor, Fair Winds Block, EGL Software Park,
   Bangalore, Karnataka  560071
   IN

   Phone: +91-80-41843303
   Email: dipankar@netapp.com


   Rishikesh Barooah
   NetApp
   3rd Floor, Fair Winds Block, EGL Software Park,
   Bangalore, Karnataka  560071
   IN

   Email: rbarooah@netapp.com


































Alex RN, et al.          Expires April 21, 2011                [Page 14]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/