doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6641.txt b/doc/rfc/rfc6641.txt
new file mode 100644
index 0000000..289d9b1
--- /dev/null
+++ b/doc/rfc/rfc6641.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Everhart
+Request for Comments: 6641                                    W. Adamson
+Category: Standards Track                                         NetApp
+ISSN: 2070-1721                                                 J. Zhang
+                                                                  Google
+                                                               June 2012
+
+
+  Using DNS SRV to Specify a Global File Namespace with NFS Version 4
+
+Abstract
+
+   The NFS version 4 (NFSv4) protocol provides a mechanism for a
+   collection of NFS file servers to collaborate in providing an
+   organization-wide file namespace.  The DNS SRV Resource Record (RR)
+   allows a simple way for an organization to publish the root of its
+   file system namespace, even to clients that might not be intimately
+   associated with such an organization.  The DNS SRV RR can be used to
+   join these organization-wide file namespaces together to allow
+   construction of a global, uniform NFS file namespace.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6641.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 1]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Background ......................................................3
+   2. Requirements Notation ...........................................3
+   3. Use of the SRV Resource Record in DNS ...........................3
+   4. Integration with Use of NFS Version 4 ...........................5
+      4.1. Globally Useful Names: Conventional Mount Point ............5
+      4.2. Mount Options ..............................................6
+      4.3. File System Integration Issues .............................6
+      4.4. Multicast DNS ..............................................7
+   5. Where Is This Integration Carried Out? ..........................7
+   6. Security Considerations .........................................7
+   7. IANA Considerations .............................................9
+   8. References ......................................................9
+      8.1. Normative References .......................................9
+      8.2. Informative References ....................................10
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 2]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+1.  Background
+
+   Version 4 of the NFS protocol [RFC3530] introduced the fs_locations
+   attribute.  Use of this attribute was elaborated further in the NFSv4
+   minor version 1 protocol [RFC5661], which also defined an extended
+   version of the attribute as fs_locations_info.  With the advent of
+   these attributes, NFS servers can cooperate to build a file namespace
+   that crosses server boundaries.  The fs_locations and
+   fs_locations_info attributes are used as referrals, so that a file
+   server may indicate to its client that the file name tree beneath a
+   given name in the server is not present on itself but is represented
+   by a file system in some other set of servers.  The mechanism is
+   general, allowing servers to describe any file system as being
+   reachable by requests to any of a set of servers.  Thus, starting
+   with a single NFSv4 server, using these referrals, an NFSv4 client
+   could see a large namespace associated with a collection of
+   interrelated NFSv4 file servers.  An organization could use this
+   capability to construct a uniform file namespace for itself.
+
+   An organization might wish to publish the starting point for this
+   namespace to its clients.  In many cases, the organization will want
+   to publish this starting point to a broader set of possible clients.
+   At the same time, it is useful to require that clients know only the
+   smallest amount of information in order to locate the appropriate
+   namespace.  Also, that required information should be constant
+   through the life of an organization if the clients are not to require
+   reconfiguration as administrative events change, for instance, a
+   server's name or address.
+
+2.  Requirements Notation
+
+   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 [RFC2119].
+
+3.  Use of the SRV Resource Record in DNS
+
+   Providing an organization's published file system namespace is a
+   service, and the DNS [RFC1034][RFC1035] provides methods for
+   discovery of that service.  This standard defines a mapping from a
+   DNS name to the NFS file system(s) providing the root of the file
+   system namespace associated with that DNS name; such file systems are
+   called "domain root" file systems.  From such file systems, like
+   other NFS file systems, an NFS client can use the standard NFS
+   mechanisms to navigate the rest of the NFS file servers that make up
+   the file system namespace for the given domain.
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 3]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+   Such domain root file systems are mounted at a conventional point in
+   the NFS client namespace.  The mechanism results in a uniform cross-
+   organizational file namespace, similar to that seen in both AFS
+   [AFS][RFC5864] and Distributed Computing Environment / Distributed
+   File System (DCE/DFS) [DFS].  An NFS client need know only the domain
+   name for an organization in order to locate the file namespace
+   published by that organization.
+
+   The DNS SRV RR type [RFC2782] is used to locate domain root file
+   servers.  The format of the DNS SRV record is as follows:
+
+      _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+
+   The Service name used is "_nfs-domainroot", in conformance with RFC
+   6335 [RFC6335].  The Protocol name used is "_tcp", for NFS service
+   over TCP.  Future NFS services using other protocols MUST use another
+   protocol name.  The "_udp" label MUST NOT be used to imply use of UDP
+   with NFSv4, as neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661]
+   defines NFSv4 over UDP.  The Target fields give the domain names of
+   the NFS servers that export file systems for the domain's root.  An
+   NFS client may then interpret any of the exported root file systems
+   as the root of the file system published by the organization with the
+   given domain name.
+
+   The domain root service is not useful for NFS versions prior to
+   version 4, as the fs_locations attribute was introduced only in NFSv4
+   (as described in Section 1).
+
+   In order to allow the NFSv4 servers as given to export a variety of
+   file systems, those file servers MUST export the given domain's root
+   file systems at "/.domainroot/{Name}" within their pseudo-file
+   systems, where the "{Name}" is the name of the organization as used
+   in the SRV RR.
+
+   As an example, suppose a client wished to locate the root of the file
+   system published by organization example.net.  The DNS servers for
+   the domain would publish records like
+
+      $ORIGIN example.net.
+      _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
+      _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net.
+
+
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 4]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+   The resulting domain names nfs1tr.example.net and nfs2ex.example.net
+   indicate NFSv4 file servers that export the root of the published
+   namespace for the example.net domain.  In accordance with RFC 2782
+   [RFC2782], these records are to be interpreted using the Priority and
+   Weight field values, selecting an appropriate file server with which
+   to begin a network conversation.  The two file servers would export
+   file systems that would be found at "/.domainroot/example.net" in
+   their pseudo-file systems, which clients would mount.  Clients then
+   carry out subsequent accesses in accordance with the ordinary NFSv4
+   protocol.  The first record uses the port number 2049 assigned to
+   NFS, and another port is specified for the second record; the NFS
+   servers would provide NFS service at their indicated port numbers,
+   and NFS clients would connect to the service via the corresponding
+   port numbers on those indicated servers.
+
+   Other file system protocols could make use of the same domain root
+   abstraction, but it is necessary to use different Service names not
+   specified here.
+
+4.  Integration with Use of NFS Version 4
+
+   NFSv4 clients adhering to this specification implement a special
+   directory, analogous to an Automounter [AMD1][AMD2] directory, the
+   entries in which are domain names that have recently been traversed.
+   When an application attempts to traverse a new name in that special
+   directory, the NFSv4 client consults DNS to obtain the SRV data for
+   the given name, and if successful, it mounts the indicated file
+   system(s) in that name in the special directory.  The goal is that
+   NFSv4 applications will be able to look up an organization's domain
+   name in the special directory, and the NFSv4 client will be able to
+   discover the file system that the organization publishes.  Entries in
+   the special directory will be domain names, and they will each appear
+   to the application as a directory name pointing to the root directory
+   of the file system published by the organization responsible for that
+   domain name.
+
+   As noted in Section 3, the domain root service is not useful for NFS
+   versions prior to version 4.
+
+4.1.  Globally Useful Names: Conventional Mount Point
+
+   In order for the inter-organizational namespace to function as a
+   global file namespace, the client-side mount point for that namespace
+   must be the same on different clients.  Conventionally, on Portable
+   Operating System Interface (POSIX) machines, the name "/nfs4/" is
+   used so that names on one machine will be directly usable on any
+   machine.  Thus, the example.net published file system would be
+   accessible as
+
+
+
+Everhart, et al.             Standards Track                    [Page 5]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+           /nfs4/example.net/
+
+   on any POSIX client.  Using this convention, "/nfs4/" is the name of
+   the special directory that is populated with domain names, leading to
+   file servers and file systems that capture the results of SRV record
+   lookups.
+
+4.2.  Mount Options
+
+   SRV records are necessarily less complete than the information in the
+   existing NFSv4 attributes fs_locations [RFC3530] or fs_locations_info
+   [RFC5661].  For the rootpath field of fs_location, or the fli_fs_root
+   field of fs_locations_info, NFS servers MUST use the "/.domainroot/
+   {Name}" string.  Thus, the servers listed as targets for the SRV RRs
+   MUST export the root of the organization's published file system as
+   the directory "/.domainroot/{Name}" (for the given organization Name)
+   in their exported NFS namespaces.  For example, for organization
+   example.net, the directory "/.domainroot/example.net" would be used.
+
+   Section 11 of the NFSv4.1 document [RFC5661] describes the approach
+   that an NFS client should take to navigate fs_locations_info
+   information.
+
+   The process of mounting an organization's namespace should permit the
+   use of what is likely to impose the lowest cost on the server.  Thus,
+   the NFS client SHOULD NOT insist on using a writable copy of the file
+   system if read-only copies exist, or a zero-age copy rather than a
+   copy that may be a little older.  The organization's file system
+   representatives can be navigated to provide access to higher-cost
+   properties such as writability or freshness as necessary, but the
+   default use when navigating to the base information for an
+   organization ought to be as low-overhead as possible.
+
+4.3.  File System Integration Issues
+
+   The result of the DNS search SHOULD appear as a (pseudo-)directory in
+   the client namespace.  A further refinement is RECOMMENDED: that only
+   fully qualified domain names appear as directories.  That is, in many
+   environments, DNS names may be abbreviated from their fully qualified
+   form.  In such circumstances, multiple names might be given to NFS
+   clients that all resolve to the same DNS SRV RRs.  The abbreviated
+   form SHOULD be represented in the client's namespace cache as a
+   symbolic link, pointing to the fully qualified name.  This will allow
+   pathnames obtained with, say, getcwd() to include the DNS name that
+   is most likely to be usable outside the scope of any particular DNS
+   abbreviation convention.
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 6]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+4.4.  Multicast DNS
+
+   Location of the NFS domain root by this SRV record is intended to be
+   performed with unicast by using the ordinary DNS [RFC1034][RFC1035]
+   protocol.
+
+   This document does not define the use of this DNS SRV record format
+   in conjunction with Multicast DNS (mDNS).  While mDNS could be used
+   to locate a local domain root via these SRV records, no other
+   domain's root could be discovered.  This means that mDNS has too
+   little value to use in locating NFSv4 domain roots.
+
+5.  Where Is This Integration Carried Out?
+
+   The NFS client is responsible for interpreting SRV records.  Using
+   something like Automounter [AMD1] [AMD2] technology, the client
+   interprets names under a particular directory, by first discovering
+   the appropriate file system to mount and then mounting it in the
+   specified place in the client namespace before returning control to
+   the application doing a lookup.  The result of the DNS lookup should
+   be cached (obeying Time to Live (TTL)) so that the result could be
+   returned more quickly the next time.
+
+6.  Security Considerations
+
+   This functionality introduces a new reliance of NFSv4 on the
+   integrity of DNS.  Forged SRV records in DNS could cause the NFSv4
+   client to connect to the file servers of an attacker, rather than the
+   legitimate file servers of an organization.  This is similar to
+   attacks that can be made on the base NFSv4 protocol, if server names
+   are given in fs_location attributes: the client can be made to
+   connect to the file servers of an attacker, not the file servers
+   intended to be the target for the fs_location attributes.
+
+   If DNS Security Extensions (DNSSEC) [RFC4033] is available, it SHOULD
+   be used to avoid both such attacks.  Domain-based service principal
+   names are an additional mechanism that also apply in this case, and
+   it would be prudent to use them.  They provide a mapping from the
+   domain name that the user specified to names of security principals
+   used on the NFSv4 servers that are indicated as the targets in the
+   SRV records (as providing file service for the root file systems).
+
+   With domain-based service principal names, the idea is that one wants
+   to authenticate {nfs, domainname, host.fqdn}, not simply {nfs,
+   host.fqdn}, when the server is a domain's root file server obtained
+   through a DNS SRV RR lookup that may or may not have been secure.
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 7]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+   The domain administrator can thus ensure that only domain root NFSv4
+   servers have credentials for such domain-based service principal
+   names.
+
+   Domain-based service principal names are defined in RFCs 5178
+   [RFC5178] and 5179 [RFC5179].  To make use of RFC 5178's domain-based
+   names, the syntax for "domain-based-name" MUST be used with a service
+   of "nfs", a domain matching the name of the organization whose root
+   file system is being sought, and a hostname given in the target of
+   the DNS SRV RR.  Thus, in the example above, two file servers
+   (nfs1tr.example.net and nfs2ex.example.net) are located as hosting
+   the root file system for the organization example.net.  To
+   communicate with, for instance, the second of the given file servers,
+   Generic Security Service Application Program Interface (GSS-API) is
+   used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE defined in
+   RFC 5178 and with a symbolic name of
+
+           nfs@example.net@nfs2ex.example.net
+
+   in order to verify that the named server (nfs2ex.example.net) is
+   authorized to provide the root file system for the example.net
+   organization.
+
+   NFSv4 itself contains a facility for the negotiation of security
+   mechanisms to be used between NFS clients and NFS servers.  Section
+   3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both
+   describe how security mechanisms are to be negotiated.  As such,
+   there is no need for this document to describe how that negotiation
+   is to be carried out when the NFS client contacts the NFS server for
+   the specified domain root file system(s).
+
+   Using SRV records to advertise the locations of NFS servers may
+   expose those NFS servers to attacks.  Organizations should carefully
+   consider whether they wish their DNS servers to respond
+   differentially to different DNS clients, perhaps exposing their SRV
+   records to only those DNS requests that originate within a given
+   perimeter, in order to reduce this exposure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 8]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+7.  IANA Considerations
+
+   IANA has assigned a new Service name without an associated port
+   number (as defined in RFC 6335 [RFC6335]) for TCP.  For this new
+   Service, the Reference is this document.
+
+   Service name: nfs-domainroot
+   Transport Protocol(s) TCP
+   Assignee (REQUIRED)  IESG (iesg@ietf.org)
+   Contact (REQUIRED)   IETF Chair (chair@ietf.org)
+   Description (REQUIRED) NFS service for the domain root, the root of
+                       an organization's published file namespace.
+   Reference (REQUIRED)  This document
+   Port Number (OPTIONAL)
+   Service Code (REQUIRED for DCCP only)
+   Known Unauthorized Uses (OPTIONAL)
+   Assignment Notes (OPTIONAL)
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [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.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC5178]  Williams, N. and A. Melnikov, "Generic Security Service
+              Application Program Interface (GSS-API)
+              Internationalization and Domain-Based Service Names and
+              Name Type", RFC 5178, May 2008.
+
+
+
+
+Everhart, et al.             Standards Track                    [Page 9]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+   [RFC5179]  Williams, N., "Generic Security Service Application
+              Program Interface (GSS-API) Domain-Based Service Names
+              Mapping for the Kerberos V GSS Mechanism", RFC 5179,
+              May 2008.
+
+   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
+              "Network File System (NFS) Version 4 Minor Version 1
+              Protocol", RFC 5661, January 2010.
+
+   [RFC5864]  Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864,
+              April 2010.
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165,
+              RFC 6335, August 2011.
+
+8.2.  Informative References
+
+   [AFS]      Howard, J., "An Overview of the Andrew File System", Proc.
+              USENIX Winter Tech. Conf. Dallas, February 1988.
+
+   [AMD1]     Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter
+              Reference Manual", March 1991,
+              <http://docs.freebsd.org/info/amdref/amdref.pdf>.
+
+   [AMD2]     Crosby, M., "AMD--AutoMount Daemon", Linux Journal,
+              35es Article 4, March 1997.
+
+   [DFS]      Kazar, M., Leverett, B., Anderson, O., Apostolides, V.,
+              Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S.,
+              and E. Zayas, "DEcorum File System Architectural
+              Overview", Proc. USENIX Summer Conf. Anaheim, Calif.,
+              June 1990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                   [Page 10]
+
+RFC 6641           NFSv4 Global Namespace with DNS SRV         June 2012
+
+
+Authors' Addresses
+
+   Craig Everhart
+   NetApp
+   800 Cranberry Woods Drive, Ste. 300
+   Cranberry Township, PA  16066
+   USA
+
+   Phone: +1 724 741 5101
+   EMail: everhart@netapp.com
+
+
+   W.A. (Andy) Adamson
+   NetApp
+   495 East Java Drive
+   Sunnyvale, CA  94089
+   USA
+
+   Phone: +1 734 665 1204
+   EMail: andros@netapp.com
+
+
+   Jiaying Zhang
+   Google
+   604 Arizona Avenue
+   Santa Monica, CA  90401
+   USA
+
+   Phone: +1 310 309 6884
+   EMail: jiayingz@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, et al.             Standards Track                   [Page 11]
+