rfc2624.txt

中、英文RFC文档大全打包下载完全版 .

   However, this has usually been done as memory cache and in relatively
   recent history, local disk caching has been added.

   It is very desirable to have the NFS client cache directory and file
   data.  Other distributed file systems have shown that aggressive
   client side caching can be very visible to the end user in the form
   of decreasing overall response time.  For AFS and DCE/DFS, caching is
   accomplished by the utilization of server call backs to notify the
   client of potential cache invalidation.  CIFS and its opportunistic
   locks provide a similar call back mechanism.  Clients in both of
   these environments are able to cache data while avoiding interaction
   with the network and server.

   With these protocols it is also possible to cache or delay certain
   protocol requests at the client which further reduces the protocol
   traffic flowing between client and server.  In the case of CIFS, it
   is possible for a client to obtain an opportunistic lock for a file
   and subsequently process file lock requests completely at the client.
   If there are no conflicts with other clients for file data access,
   the server is never contacted for the file locking traffic generated
   by the user application. This behavior is not a protocol requirement
   but is allowed by the protocol as an implementation option to improve
   performance.





Shepler                      Informational                      [Page 6]

RFC 2624              NFSv4 Design Considerations              June 1999


   NFS versions 2 and 3 make no caching requirements.  Implementations
   typically implement close-to-open cache consistency which requires
   clients flush all changes to the server on each file close, and check
   for file changes on the server on each file open.  The consistency
   check required on each file open can generate a large amount of
   GETATTR traffic.  With this approach, there are windows when the
   client can still be acting with stale data between the open and close
   of a file.

   Client caching is increasingly important for Internet environments
   where throughput can be limited and response time can grow
   significantly. Therefore the NFS version 4 caching design will need
   to take into account the full spectrum of caching designs as
   exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS,
   etc. in determining an appropriate design.  This will need to be done
   while weighing the complexity of each possible approach with the need
   of the eventual users and operating environments into which NFS
   version 4 may be deployed.  Some of these considerations are:
   Internet accessibility, firewall traversal (call back availability),
   proxy caching, low-overhead or simple clients.

4.3.  Disconnected Client Operation

   An extension of client caching is the provision for disconnected
   operation at the client.  With the ability to cache directory and
   file data aggressively, a client could then provide service to the
   end user while disconnected from the server or network.

   While very desirable, disconnected operation has the potential to
   inflict itself upon the NFS protocol in an undesirable way as
   compared to traditional client caching.  Given the complexities of
   disconnected client operation and subsequent resolution of client
   data modification through various playback or data selection
   mechanisms, disconnected operation should not be a requirement for
   the NFS effort.  Even so, the NFS protocol should consider the
   potential layering of disconnected operation solutions on top of the
   NFS protocol (as with other server and client solutions).  The
   experiences with Coda, disconnected AFS and others should be helpful
   in this area. (see references)

5.  Interoperability

   The NFS protocols are available for many different operating
   environments.  Even though this shows the protocol's ability to
   provide distributed file system service for more than a single
   operating system, the design of NFS is certainly Unix-centric.  The
   next NFS protocol needs to be more inclusive of platform or file
   system features beyond those of traditional Unix.



Shepler                      Informational                      [Page 7]

RFC 2624              NFSv4 Design Considerations              June 1999


5.1.  Platform Specific Behavior

   Because of Unix-centric origins, NFS version 2 and 3 protocol
   requirements have been difficult to implement in some environments.
   For example, persistent file handles (unique identifiers of file
   system objects), Unix uid/gid mappings, directory modification time,
   accurate file sizes, file/directory locking semantics (SHAREs, PC-
   style locking). In the design of NFS version 4, these areas and
   others not mentioned will need to be considered and, if possible,
   cross-platform solutions developed.

5.2.  Additional or Extended Attributes

   NFS versions 2 and 3 do not provide for file or directory attributes
   beyond those that are found in the traditional Unix environment. For
   example the user identifier/owner of the file, a permission or access
   bitmap, time stamps for modification of the file or directory and
   file size to name a few.  While the current set of attributes has
   usually been sufficient, the file system's ability to manage
   additional information associated with a file or directory can be
   useful.

   There are many possibilities for additional attributes in the next
   version of NFS.  Some of these include: object creation timestamp,
   user identifier of file's creator, timestamp of last backup or
   archival bit, version number, file content type (MIME type),
   existence of data management involvement (i.e. DMAPI [XDSM]).

   This list is representative of the possibilities and is meant to show
   the need for an additional attribute set.  Enumerating the 'correct'
   set of attributes, however, is difficult.  This is one of the reasons
   for looking towards a minor versioning mechanism as a way to provide
   needed extensibility.  Another way to provide some extensibility is
   to support a generalized named attribute mechanism.  This mechanism
   would allow a client to name, store and retrieve arbitrary data and
   have it associated as an attribute of a file or directory.

   One difficulty in providing named attributes is determining if the
   protocol should specify the names for the attributes, their type or
   structure.  How will the protocol determine or allow for attributes
   that can be read but not written is another issue.  Yet another could
   be the side effects that these attributes have on the core set of
   file properties such as setting a size attribute to 0 and having
   associated file data deleted.

   As these brief examples show, this type of extended attribute
   mechanism brings with it a large set of issues that will need to be
   addressed in the protocol specification while keeping the overall



Shepler                      Informational                      [Page 8]

RFC 2624              NFSv4 Design Considerations              June 1999


   goal of simplicity in mind.

   There are operating environments that provide named or extended
   attribute mechanisms.  Digital Unix provides for the storage of
   extended attributes with some generalized format.  HPFS [HPFS] and
   NTFS [Nagar] also provide for named data associated with traditional
   files.  SGI's local file system, XFS, also provides for this type of
   name/value extended attributes. However, there does not seem to be a
   clear direction that can be taken from these or other environments.

5.3.  Access Control Lists

   Access Control Lists (ACL) can be viewed as one specific type of
   extended attribute.  This attribute is a designation of user access
   to a file or directory.  Many vendors have created ancillary
   protocols to NFS to extend the server's ACL mechanism across the
   network.  Generally this has been done for homogeneous operating
   environments. Even though the server still interprets the ACL and has
   final control over access to a file system object, the client is able
   to manipulate the ACL via these additional protocols.  Other
   distributed file systems have also provided ACL support (DFS, AFS and
   CIFS).

   The basic factor driving the requirement for ACL support in all of
   these file systems has been the user's desire to grant and restrict
   access to file system data on a per user basis.  Based on the desire
   of the user and current distributed file system support, it seems to
   be a requirement that NFS provide this capability as well.

   Because many local and distributed file system ACL implementations
   have been done without a common architecture, the major issue is one
   of compatibility.  Although the POSIX draft, DCE/DFS [DCEACL] and
   Windows NT ACLs have a similar structure in an array of Access
   Control Entries consisting of a type field, identity, and permission
   bits, the similarity ends there.  Each model defines its own variants
   of entry types, identifies users and groups differently, provides
   different kinds of permission bits, and describes different
   procedures for ACL creation, defaults, and evaluation.

   In the least it will be problematic to create a workable ACL
   mechanism that will encompass a reasonable set of functionality for
   all operating environments.  Even with the complicated nature of ACL
   support it is still worthwhile to work towards a solution that can at
   least provide basic functionality for the user.







Shepler                      Informational                      [Page 9]

RFC 2624              NFSv4 Design Considerations              June 1999


6.  RPC Mechanism and Security

   NFS relies on the security mechanisms provided by the ONCRPC
   [RFC1831] protocol.  Until the introduction of the ONCRPC RPCSEC_GSS
   security flavor [RFC2203], NFS security was generally limited to none
   (AUTH_SYS) or DES (AUTH_DH).  The AUTH_DH security flavor was not
   successful in providing readily available security for NFS because of
   a lack of widespread implementation which precluded widespread
   deployment.  Also the Diffie-Hellman 192 bit public key modulus used
   for the AUTH_DH security flavor quickly became too small for
   reasonable security.

6.1.  User identification

   NFS has been limited to the use of the Unix-centric user
   identification mechanism of numeric user id based on the available
   file system attributes and the use of the ONCRPC.  However, for NFS
   to move beyond the limits of large work groups, user identification
   should be string based and the definition of the user identifier
   should allow for integration into an external naming service or
   services.

   Internet scaling should also be considered for this as well.  The
   identification mechanism should take into account multiple naming
   domains and multiple naming mechanisms.  Flexibility is the key to a
   solution that can grow with the needs of the user and administrator.

   If NFS is to move among various naming and security services, it may
   be necessary to stay with a string based identification.  This would
   allow for servers and clients to translate between the external
   string representation to a local or internal numeric (or other
   identifier) which matches internal implementation needs.

   As an example, DFS uses a string based naming scheme but translates
   the name to a UUID (16 byte identifier) that is used for internal
   protocol representations. The DCE/DFS string name is a combination of
   cell (administrative domain) and user name.  As mentioned, NFS
   clients and servers map a Unix user name to a 32 bit user identifier
   that is then used for ONCRPC and NFS protocol fields requiring the
   user identifier.

6.2.  Security

   Because of the aforementioned problems, user authentication has been
   a major issue for ONCRPC and hence NFS.  To satisfy requirements of
   the IETF and to address concerns and requirements from users, NFS
   version 4 must provide for the use of acceptable security mechanisms.
   The various mechanisms currently available should be explored for



Shepler                      Informational                     [Page 10]

RFC 2624              NFSv4 Design Considerations              June 1999


   their appropriate use with NFS version 4 and ONCRPC.  Some of these
   mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510],
   IPSEC [RFC2401].  Since ONCRPC is the basis for NFS client and server
   interaction, the RPCSEC_GSS [RFC2203] framework should be strongly
   considered since it provides a method to employ mechanisms like SPKM
   and KerberosV5.  Before a security mechanism can be evaluated, the
   NFS environment and requirements must be discussed.

6.2.1.  Transport Independence

   As mentioned later in this document in the section "Internet
   Accessibility", transport independence is an asset for NFS and ONCRPC
   and is a general requirement.  This allows for transport choice based
   on the target environment and specific application of NFS.  The most
   common transports in use with NFS are UDP and TCP.  This ability to
   choose transport should be maintained in combination with the user's
   choice of a security mechanism.  This implies that "mandatory to
   implement" security mechanisms for NFS should allow for both
   connection-less and connection-oriented transports.

6.2.2.  Authentication

   As should be expected, strong authentication is a requirement for NFS
   version 4.  Each operation generated via ONCRPC contains user
   identification and authentication information.  It is common in NFS
   version 2 and 3 implementations to multiplex various users' requests
   over a single or few connections to the NFS server.  This allows for
   scalability in the number of clients systems.  Security mechanisms or
   frameworks should allow for this multiplexing of requests to sustain
   the implementation model that is available today.

6.2.3.  Data Integrity

   Until the introduction of RPCSEC_GSS, the ability to provide data
   integrity over ONCRPC and to NFS was not available.  Since file and
   directory data is the essence of a distributed file service, the NFS
   protocol should provide to the users of the file service a reasonable
   level of data integrity.  The security mechanisms chosen must provide
   for NFS data protection with a cryptographically strong checksum.  As
   with other aspects within NFS version 4, the user or administrator
   should be able to choose whether data integrity is employed.  This
   will provide needed flexibility for a variety of NFS version 4
   solutions.








Shepler                      Informational                     [Page 11]