Network Working Group S. Shepler Internet Draft May 1998 Document: draft-shepler-nfsv4-00.txt Current Status of NFS version 4 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract In preparation for the formation of the NFS version 4 IETF working group, this draft has been created as a summary of the discussions and e-mail (nfsv4-wg@sunroof.eng.sun.com) held since the 1996 San Jose NFS version 4 BOF. This summary is meant as a review for those who have been involved in the past exchanges and as an introduction for those newcomers who would like a quick summary of this past activity. The other intent of this summary is to point out topics which lack significant progress or topics which have not been covered and need consideration. A familiarity with the NFS version 2 and NFS version 3 protocols is assumed. Expires: November 1998 [Page 1]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 Table of Contents 1. Working Group Goals and Problem Space . . . . . . . . . . . . 3 1.1. Draft Charter for Working Group . . . . . . . . . . . . . . 3 1.2. Specific Problems for NFS version 4 . . . . . . . . . . . . 3 2. Discussion Summary . . . . . . . . . . . . . . . . . . . . . 4 2.1. Internationalization . . . . . . . . . . . . . . . . . . . 4 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. File/Directory Attributes . . . . . . . . . . . . . . . . . 5 2.4. File Name Lookup Methodology . . . . . . . . . . . . . . . 5 2.5. File Locking . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Cache Coherency . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Compound Operations . . . . . . . . . . . . . . . . . . . . 6 2.8. Minor Versioning . . . . . . . . . . . . . . . . . . . . . 7 2.9. File Handle Volatility . . . . . . . . . . . . . . . . . . 7 2.10. Structured Files . . . . . . . . . . . . . . . . . . . . . 8 2.11. Client Advice for File Access . . . . . . . . . . . . . . 8 2.12. Time Stamps and Synchronization . . . . . . . . . . . . . 8 2.13. Determining Server File Systems . . . . . . . . . . . . . 9 3. Items to be Discussed . . . . . . . . . . . . . . . . . . . . 9 3.1. Internet Issues . . . . . . . . . . . . . . . . . . . . . . 9 3.2. User Identification (UID/GID mapping) . . . . . . . . . . 10 3.3. Proxy Methodology . . . . . . . . . . . . . . . . . . . . 10 3.4. Fileset or File Migration . . . . . . . . . . . . . . . . 10 3.5. Client Caching or Disconnected Caching Issues . . . . . . 10 3.6. ACL definitions . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Expires: November 1998 [Page 2]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 1. Working Group Goals and Problem Space 1.1. Draft Charter for Working Group The objective of this working group is to advance the state of NFS technology by producing a specification for NFS version 4 which will also be submitted as an Internet standard. NFS version 4 will emphasize the following core features: o Improved access and good performance on the Internet. The protocol will be 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 will build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. Additionally NFS version 4 will provide a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes. o Better cross-platform interoperability. The protocol will feature a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another. o Designed for protocol extensions. The protocol will be designed to accept standard extensions that do not compromise backward compatibility. The NFS version 4 protocol will emphasize, but not be limited to these core features. Additional improvements will be considered if they are considered reasonable, useful, and do not conflict with the core features. 1.2. Specific Problems for NFS version 4 The stated goals of the working group cover known problems or deficiencies within the current NFS protocols with respect to the target operating environment of the Internet. The following list represents some of the issues within NFS version 2 and NFS version 3 which NFS version 4 should address. Expires: November 1998 [Page 3]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 o Unable to handle non-ASCII filenames. o Assumption of low latency leads to poor performance where latency is high. o Cannot browse server's namespace without the Mount protocol. Mount protocol stops at the firewall. o No file locking. Companion lock manager protocol will not scale to Internet use and stops at the firewall. o Supports only POSIX file attributes. No provision for other attribute types. o Unable to negotiate the security flavor. o Unable to utilize proxy server. 2. Discussion Summary The following sections represent topics or protocol areas which have been discussed previously. Each section is a summary and is not meant to be comprehensive coverage. 2.1. Internationalization For all character set encodings which are used in the protocol, the use of the UTF-8 encoding of the Unicode standard (ISO/IEC 10646) will be used. The UTF-8 encoding would be used for all pathnames, hostnames, usernames, URLs or other protocol members which are passed over the wire as character strings. This proposal resulted in little or no comment and therefore it is not clear if this proposal has consensus. 2.2. Security As stated in the goals of the NFS version 4 working group, the ONCRPC [RFC1831] protocol will be used with the addition of the RPCSEC_GSS [RFC2203] security flavor. The security topic needs expansion in the areas of available and proposed mechanisms for various operating environments. These NFS environments include traditional administrative domains, two individuals wanting to securely share data, and any Internet user in between. Expires: November 1998 [Page 4]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 2.3. File/Directory Attributes There has been substantial discussion of file attributes from many different aspects. There was the general classification of the attributes into basic and extended categories. Continuing with observations of current NFS server behavior, it was noted that because of the lack of support in certain operating environments the server, out of necessity, was led to fabricate attributes values. Because of this lack of support for all attribute values, classification of attributes into mandatory and optional attributes was suggested. Mandatory attributes would be the smallest set needed by an NFS client to provide reasonable file system service at the client. Suggestions were made for which attributes would be classified as mandatory; however, final agreement was not reached. Access Control Lists (ACLs) for file system objects (files or directories) were classified as an extended attribute. Based on current operating environment support, most people involved seemed to agree that ACLs were worth including in the protocol. See section 4.6 for further topic requirements. Because of the various operating environments and their requirements for attribute values, it was generally agreed upon that the client would receive only those attributes values for which it generated requests. The belief is that this behavior can lead to a reduction in the amount of data exchanged and reduce processing overhead for both client and server. 2.4. File Name Lookup Methodology Two major issues arose which deal with the NFS server's ability to match or look up names within the file system name space. The first was case sensitivity and the second was file name globbing. Both of the issues are complicated by the inclusion or use of the Unicode standard. One example for case sensitivity is with the client's operating environment. Given a server with case sensitive file name lookups and a client operating environment which is case insensitive, the client may need to generate multiple procedure calls to the server to ensure the correct behavior. The client can either generate multiple lookup requests or read the directory in full and match locally based on its semantics. The protocol could specify the server's support for case sensitive/insensitive lookups and the client would then specify its requirements based on its environment. As previously mentioned, the use of Unicode complicates the server's behavior because of varying character set usage at client and server. Expires: November 1998 [Page 5]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 File name globbing is the other area where the use of Unicode complicates the specification and implementation. File name globbing has the added complexity of a non-uniform behavior with respect to regular expressions. Not all client environments treat regular expressions or file name construction in the same manner. One suggestion is to push the specific behavior back to the client implementation. The client knows its operating environment as it applies to character sets, regular expressions and file name construction. Some of the multiple RPC issues of case insensitivity could be addressed with the use of compound operations (see section 3.7). In any case, not enough discourse was completed in this area to reach consensus. 2.5. File Locking The issues of file locking and cache coherency have been intertwined in previous discussions. For file locking, there seems to be agreement that file locking functionality should be included in the NFS version 4 protocol definition; currently, file locking is managed by an adjunct protocol. However, specifics of what the locking protocol will look like and what problems it will solve have been missing. Further definition of existing file locking protocols and how NFS version 4 will support a reasonable strategy for an Internet file system need to be put forth. 2.6. Cache Coherency One of the first summaries proposed that NFS version 4 not deal with the issue of strict cache coherency. Even with this suggestion, there was considerable discussion about the locking mechanisms in various file systems and what they provided to the client implementation for both The CIFS oplock mechanisms were discussed as well as the Spritely NFS work. 2.7. Compound Operations A method of combining individual operations into a single request has been proposed as a compound operation. As proposed, a small set of procedures will be defined for NFS version 4. One of these procedures will be primitive and glue operations defined. These operations can be used by the client to generate the desired behavior based on the client's needs. For full details of the proposal see: http://playground.Sun.COM/pub/nfsv4/nfsv4-wg-archive/0065.html. As the proposal states, the intent behind compound operations is to address the following issues: network latency, traffic reduction, bandwidth efficiency, protocol complexity reduction and flexibility Expires: November 1998 [Page 6]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 for client implementations. This proposal seems to be one end of the compound operation spectrum. Discussion was limited on the contents of the proposal. To further understand the implications of this type of approach issues such as performance, serviceability and implementation difficulty, etc. need to be addressed. 2.8. Minor Versioning As stated in the goals of the working group, the inclusion of a methodology to make the protocol expandable or easily upgradeable is a desirable feature. Even with the existence of this goal, minor versioning for the protocol has been a contentious topic. As an example, had minor versioning existed in NFS Version 2, an standard extension to provide asynchronous writes would likely have been implemented. Again, as stated in the working group goals, the expandability needs to be done in a way as to preserve the current protocol functionality and semantics to meet backward compatibility requirements. It has been proposed that expansion would be provided through additional procedure calls in the NFS version 4 program. Expansion can also come in the form of defining previously reserved bit fields in existing procedure calls that will lead to additional or modified procedure semantics. One of the main arguments for this type of capability in the protocol is to provide updated/corrected functionality in a timely manner and with the minimum of impact to the end user and administrator. 2.9. File Handle Volatility The current NFS protocols require the server to return file handles to the client which are persistent. This persistence must survive server outages. For some platforms, this requirement has been difficult or impossible to meet because of the lack of support in the underlying file system. The existence of persistent file handles in the NFS protocol eases the implementation issues of the NFS client. However, NFS client implementations do exist that have removed the absolute requirement for persistent file handles. These NFS clients track the association of file handle and file or directory name. The existence of file name allows the NFS client the ability to recover from server failures. Removing the persistent file handle requirement provides the capability for easing and correcting server implementations of NFS version 4 while maintaining the clients capability of surviving server outages or reboots. It has been suggested the protocol Expires: November 1998 [Page 7]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 provide a mechanism for the server to provide notification to the client of the existence of volatile file handles. 2.10. Structured Files A lengthy discussion has occurred around the issues of providing structured file support. This discussion actually presented or combined two disparate pieces of functionality. The first semantic dealt with the traditional definition of structured file support (i.e. indexed files) as opposed to the traditional Unix file definition (i.e. byte stream). The second semantic introduced was the definition of an extended file attribute which could be used to identify the file type or associated application for the file. The most relevant example would be the use of MIME typing. The support of the traditional structured file was not seen as a requirement of the new protocol. The scope of the problem and the lack of a clear definition of what the structure should be did not present itself as a desirable issue to resolve. The idea of an extended attribute for file type definition was not as quickly dismissed and discussion on this topic should continue in the context of support for extended attributes. 2.11. Client Advice for File Access The client's knowledge of current or future application file access patterns could be provided to the server. Heuristically the client operating environment may be able to recognize a sequential file access pattern of an application. If the client informs the server of this, the server could take actions to provide improved service to the client and application. This knowledge extension could also be more explicit at the client; for example, a multimedia application with very specific access patterns and bandwidth requirements. This information could be transfered to the server through the use of client specific APIs then to the NFS implementation at the client and then to the server via the NFS protocol. Another example involves the client's knowledge of its network connection (i.e. modem); the client could provide the server with this knowledge and allow it to avoid over allocation or appropriate allocation of server resource. Definition of specific requirements along with overall implications of this type of support need to be brought forth. For example, whether this information is advisory or mandatory should be determined along with the associated implications. 2.12. Time Stamps and Synchronization Two issues involving time have been raised. First was the size Expires: November 1998 [Page 8]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 increase of the time fields within the protocol definition and the second was the potential need of client/server time synchronization for correctness of any lease-based mechanisms employed by the protocol. With a signed 32 bit quantity representing time in seconds from an epoch of January 1, 1970, the time quantity will expire in the year 2038. The suggestion has been made that this limitation should be addressed by introducing a larger time field. The most straightforward suggestion was to increase the time fields in the protocol to a full 64 bits. Pushing the epoch of a 64 bit time quantity before the 1/1/1970 date was suggested as well. Lease-based locking mechanisms have been suggested and it was observed that the Spritely NFS lease-based mechanism seemed to require synchronized clocks between client and server. Upon closer inspection it was suggested that other underlying mechanisms could be employed to avoid this requirement. The idea of synchronized clocks in an Internet-based file system was daunting. If a lease-based mechanism is considered further, the specifics of time synchronization requirements and replacement technologies need to be fully understood. 2.13. Determining Server File Systems A mechanism to replace the traditional adjunct mount protocol has been suggested in the form of a new procedure (SHAREINFO). SHAREINFO would provide a list of available file systems to the caller. This procedure would be similar in nature to a READDIR request except it would need to provide additional information about appropriate security mechanisms required for access to the server's file systems. 3. Items to be Discussed Even though productive dialog has occurred, the results of the discussions have not addressed all needed areas of investigation for a successful building of an NFS version 4. In the following sections some of these additional issues or areas of investigation have been enumerated. 3.1. Internet Issues The goals of the working group specifically state the desire to provide an Internet-capable protocol. However, there has been little specific discussion or proposals surrounding these issues. This area needs to be expanded upon at least in identification of proposed features and how these features can serve an Internet environment. Expires: November 1998 [Page 9]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 3.2. User Identification (UID/GID mapping) User identification issues have been raised. Suggested solutions to the problem of mapping different user naming schemes beyond an administrative domain have relied on the underlying security mechanism and its method of user identification. This area needs further development with respect to specific solutions and how users without the environment for security support will access available data. 3.3. Proxy Methodology File service proxying seems like a logical extension for the support of Internet functionality. The environment of operation and implications for performance, security and scalability have not been addressed. This is an area where other proxying techniques may lend themselves as useful input to the choice to incorporate specific features into the protocol for NFS proxy functionality. 3.4. Fileset or File Migration Scalable, manageable NFS servers seem to be a logical inclusion for a new protocol. Management of the server's file systems has not been addressed. Applicable protocol features that can help facilitate file system management of an NFS version 4 server have not been investigated. 3.5. Client Caching or Disconnected Caching Issues NFS clients have always cached file data in some form. In recent implementations the caching of data has been more aggressive with the use of client disk caches dedicated to NFS directory and file data. Providing for disconnected operation in the protocol may lead to ease of use in an Internet environment where connection cost or reliability are issues. Dealing with disconnected issues within the protocol may be useful for the target environments. 3.6. ACL definitions Although access control lists have been mentioned in the context of extended attributes, a definition of an NFS version 4 ACL has not been brought forth for discussion. The major issue revolves around the ability for the protocol's ACLs to incorporate the semantics of various existing ACL definitions and operating environments. Expires: November 1998 [Page 10]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 References [NFSV4HYP]"NFS version 4 Hypermail archive for nfsv4- wg@sunroof.eng.sun.com" http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive [RFC1094] Sun Microsystems, Inc. (1989). "NFS: Network File System Protocol specification," RFC 1094. http://info.internet.isi.edu/in-notes/rfc/files/rfc1094.txt [RFC1813] Callaghan, B., Pawlowski, B., Staubach, P. (1995). "NFS Version 3 Protocol Specification," RFC 1813. http://info.internet.isi.edu/in-notes/rfc/files/rfc1813.txt [RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol Specification Version 2," RFC 1831. http://info.internet.isi.edu/in-notes/rfc/files/rfc1831.txt [RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation Standard," RFC 1832. http://info.internet.isi.edu/in-notes/rfc/files/rfc1832.txt [Pawlowski] Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., Lebel, D., Hitz, D. (1994). "NFS Version 3 Design and Implementations," Proceedings of the 1994 USENIX Technical Conference. [RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol Specification," RFC 2203. http://info.internet.isi.edu/in-notes/rfc/files/rfc2203.txt [RFC2078] Linn, J. (1997). "Generic Security Service Application Program Interface, Version 2," RFC 2078. http://info.internet.isi.edu/in-notes/rfc/files/rfc2078.txt [RFC1057] Sun Microsystems, Inc. "RPC: Remote Procedure Call Protocol Specification Version 2," RFC 1057. http://info.internet.isi.edu/in-notes/rfc/files/rfc1057.txt [Callaghan] Callaghan, B., Singh, S. (1993). "The Autofs Automounter," Proceedings of the 1993 Summer USENIX Technical Conference. [RFC2054] Callaghan, B. (1996). "WebNFS Client Specification," RFC 2054. http://info.internet.isi.edu/in-notes/rfc/files/rfc2054.txt Expires: November 1998 [Page 11]
INTERNET-DRAFT Current Status of NFS version 4 May 1998 [RFC2055] Callaghan, B. (1996). "WebNFS Server Specification," RFC 2054. http://info.internet.isi.edu/in-notes/rfc/files/rfc2055.txt [RFC2224] Callaghan, B. (1996). "NFS URL Scheme," RFC 2054. http://info.internet.isi.edu/in-notes/rfc/files/rfc2224.txt Author's Address Address comments related to this memorandum to: nfsv4-wg@sunroof.eng.sun.com Spencer Shepler Sun Microsystems, Inc. 7808 Moonflower Drive Austin, Texas 78750 Phone: 1-512-349-9376 E-mail: shepler@eng.sun.com Expires: November 1998 [Page 12]
