rfc3010.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,421 行 · 第 1/5 页

   o  Improved access and good performance on the Internet.

      The protocol is designed to transit firewalls easily, perform well
      where latency is high and bandwidth is low, and scale to very
      large numbers of clients per server.

   o  Strong security with negotiation built into the protocol.

      The protocol builds on the work of the ONCRPC working group in
      supporting the RPCSEC_GSS protocol.  Additionally, the NFS version
      4 protocol provides a mechanism to allow clients and servers the
      ability to negotiate security and require clients and servers to
      support a minimal set of security schemes.

   o  Good cross-platform interoperability.

      The protocol features a file system model that provides a useful,
      common set of features that does not unduly favor one file system
      or operating system over another.

   o  Designed for protocol extensions.

      The protocol is designed to accept standard extensions that do not
      compromise backward compatibility.

1.1.  Overview of NFS Version 4 Features

   To provide a reasonable context for the reader, the major features of
   NFS version 4 protocol will be reviewed in brief.  This will be done
   to provide an appropriate context for both the reader who is familiar
   with the previous versions of the NFS protocol and the reader that is
   new to the NFS protocols.  For the reader new to the NFS protocols,
   there is still a fundamental knowledge that is expected.  The reader
   should be familiar with the XDR and RPC protocols as described in
   [RFC1831] and [RFC1832].  A basic knowledge of file systems and
   distributed file systems is expected as well.

1.1.1.  RPC and Security

   As with previous versions of NFS, the External Data Representation
   (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFS
   version 4 protocol are those defined in [RFC1831] and [RFC1832].  To
   meet end to end security requirements, the RPCSEC_GSS framework
   [RFC2203] will be used to extend the basic RPC security.  With the
   use of RPCSEC_GSS, various mechanisms can be provided to offer
   authentication, integrity, and privacy to the NFS version 4 protocol.
   Kerberos V5 will be used as described in [RFC1964] to provide one
   security framework.  The LIPKEY GSS-API mechanism described in



Shepler, et al.             Standards Track                     [Page 6]

RFC 3010                 NFS version 4 Protocol            December 2000


   [RFC2847] will be used to provide for the use of user password and
   server public key by the NFS version 4 protocol.  With the use of
   RPCSEC_GSS, other mechanisms may also be specified and used for NFS
   version 4 security.

   To enable in-band security negotiation, the NFS version 4 protocol
   has added a new operation which provides the client a method of
   querying the server about its policies regarding which security
   mechanisms must be used for access to the server's file system
   resources.  With this, the client can securely match the security
   mechanism that meets the policies specified at both the client and
   server.

1.1.2.  Procedure and Operation Structure

   A significant departure from the previous versions of the NFS
   protocol is the introduction of the COMPOUND procedure.  For the NFS
   version 4 protocol, there are two RPC procedures, NULL and COMPOUND.
   The COMPOUND procedure is defined in terms of operations and these
   operations correspond more closely to the traditional NFS procedures.
   With the use of the COMPOUND procedure, the client is able to build
   simple or complex requests.  These COMPOUND requests allow for a
   reduction in the number of RPCs needed for logical file system
   operations.  For example, without previous contact with a server a
   client will be able to read data from a file in one request by
   combining LOOKUP, OPEN, and READ operations in a single COMPOUND RPC.
   With previous versions of the NFS protocol, this type of single
   request was not possible.

   The model used for COMPOUND is very simple.  There is no logical OR
   or ANDing of operations.  The operations combined within a COMPOUND
   request are evaluated in order by the server.  Once an operation
   returns a failing result, the evaluation ends and the results of all
   evaluated operations are returned to the client.

   The NFS version 4 protocol continues to have the client refer to a
   file or directory at the server by a "filehandle".  The COMPOUND
   procedure has a method of passing a filehandle from one operation to
   another within the sequence of operations.  There is a concept of a
   "current filehandle" and "saved filehandle".  Most operations use the
   "current filehandle" as the file system object to operate upon.  The
   "saved filehandle" is used as temporary filehandle storage within a
   COMPOUND procedure as well as an additional operand for certain
   operations.







Shepler, et al.             Standards Track                     [Page 7]

RFC 3010                 NFS version 4 Protocol            December 2000


1.1.3.  File System Model

   The general file system model used for the NFS version 4 protocol is
   the same as previous versions.  The server file system is
   hierarchical with the regular files contained within being treated as
   opaque byte streams.  In a slight departure, file and directory names
   are encoded with UTF-8 to deal with the basics of
   internationalization.

   The NFS version 4 protocol does not require a separate protocol to
   provide for the initial mapping between path name and filehandle.
   Instead of using the older MOUNT protocol for this mapping, the
   server provides a ROOT filehandle that represents the logical root or
   top of the file system tree provided by the server.  The server
   provides multiple file systems by gluing them together with pseudo
   file systems.  These pseudo file systems provide for potential gaps
   in the path names between real file systems.

1.1.3.1.  Filehandle Types

   In previous versions of the NFS protocol, the filehandle provided by
   the server was guaranteed to be valid or persistent for the lifetime
   of the file system object to which it referred.  For some server
   implementations, this persistence requirement has been difficult to
   meet.  For the NFS version 4 protocol, this requirement has been
   relaxed by introducing another type of filehandle, volatile.  With
   persistent and volatile filehandle types, the server implementation
   can match the abilities of the file system at the server along with
   the operating environment.  The client will have knowledge of the
   type of filehandle being provided by the server and can be prepared
   to deal with the semantics of each.

1.1.3.2.  Attribute Types

   The NFS version 4 protocol introduces three classes of file system or
   file attributes.  Like the additional filehandle type, the
   classification of file attributes has been done to ease server
   implementations along with extending the overall functionality of the
   NFS protocol.  This attribute model is structured to be extensible
   such that new attributes can be introduced in minor revisions of the
   protocol without requiring significant rework.

   The three classifications are: mandatory, recommended and named
   attributes.  This is a significant departure from the previous
   attribute model used in the NFS protocol.  Previously, the attributes
   for the file system and file objects were a fixed set of mainly Unix
   attributes.  If the server or client did not support a particular
   attribute, it would have to simulate the attribute the best it could.



Shepler, et al.             Standards Track                     [Page 8]

RFC 3010                 NFS version 4 Protocol            December 2000


   Mandatory attributes are the minimal set of file or file system
   attributes that must be provided by the server and must be properly
   represented by the server.  Recommended attributes represent
   different file system types and operating environments.  The
   recommended attributes will allow for better interoperability and the
   inclusion of more operating environments.  The mandatory and
   recommended attribute sets are traditional file or file system
   attributes.  The third type of attribute is the named attribute.  A
   named attribute is an opaque byte stream that is associated with a
   directory or file and referred to by a string name.  Named attributes
   are meant to be used by client applications as a method to associate
   application specific data with a regular file or directory.

   One significant addition to the recommended set of file attributes is
   the Access Control List (ACL) attribute.  This attribute provides for
   directory and file access control beyond the model used in previous
   versions of the NFS protocol.  The ACL definition allows for
   specification of user and group level access control.

1.1.3.3.  File System Replication and Migration

   With the use of a special file attribute, the ability to migrate or
   replicate server file systems is enabled within the protocol.  The
   file system locations attribute provides a method for the client to
   probe the server about the location of a file system.  In the event
   of a migration of a file system, the client will receive an error
   when operating on the file system and it can then query as to the new
   file system location.  Similar steps are used for replication, the
   client is able to query the server for the multiple available
   locations of a particular file system.  From this information, the
   client can use its own policies to access the appropriate file system
   location.

1.1.4.  OPEN and CLOSE

   The NFS version 4 protocol introduces OPEN and CLOSE operations.  The
   OPEN operation provides a single point where file lookup, creation,
   and share semantics can be combined.  The CLOSE operation also
   provides for the release of state accumulated by OPEN.

1.1.5.  File locking

   With the NFS version 4 protocol, the support for byte range file
   locking is part of the NFS protocol.  The file locking support is
   structured so that an RPC callback mechanism is not required.  This
   is a departure from the previous versions of the NFS file locking
   protocol, Network Lock Manager (NLM).  The state associated with file
   locks is maintained at the server under a lease-based model.  The



Shepler, et al.             Standards Track                     [Page 9]

RFC 3010                 NFS version 4 Protocol            December 2000


   server defines a single lease period for all state held by a NFS
   client.  If the client does not renew its lease within the defined
   period, all state associated with the client's lease may be released
   by the server.  The client may renew its lease with use of the RENEW
   operation or implicitly by use of other operations (primarily READ).

1.1.6.  Client Caching and Delegation

   The file, attribute, and directory caching for the NFS version 4
   protocol is similar to previous versions.  Attributes and directory
   information are cached for a duration determined by the client.  At
   the end of a predefined timeout, the client will query the server to
   see if the related file system object has been updated.

   For file data, the client checks its cache validity when the file is
   opened.  A query is sent to the server to determine if the file has
   been changed.  Based on this information, the client determines if
   the data cache for the file should kept or released.  Also, when the
   file is closed, any modified data is written to the server.

   If an application wants to serialize access to file data, file
   locking of the file data ranges in question should be used.

   The major addition to NFS version 4 in the area of caching is the
   ability of the server to delegate certain responsibilities to the
   client.  When the server grants a delegation for a file to a client,
   the client is guaranteed certain semantics with respect to the
   sharing of that file with other clients.  At OPEN, the server may
   provide the client either a read or write delegation for the file.
   If the client is granted a read delegation, it is assured that no
   other client has the ability to write to the file for the duration of
   the delegation.  If the client is granted a write delegation, the
   client is assured that no other client has read or write access to
   the file.

   Delegations can be recalled by the server.  If another client
   requests access to the file in such a way that the access conflicts
   with the granted delegation, the server is able to notify the initial
   client and recall the delegation.  This requires that a callback path
   exist between the server and client.  If this callback path does not
   exist, then delegations can not be granted.  The essence of a
   delegation is that it allows the client to locally service operations
   such as OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate
   interaction with the server.







Shepler, et al.             Standards Track                    [Page 10]

RFC 3010                 NFS version 4 Protocol            December 2000


1.2.  General Definitions

   The following definitions are provided for the purpose of providing
   an appropriate context for the reader.