2.7.10 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Brent Callaghan <brent@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Mailing Lists:

General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: nfsv4-wg-request@sunroof.eng.sun.com
Archive: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive

Description of 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 be submitted as an Internet standards track RFC. The first phase of the working group activity will produce a requirements document describing the limitations and deficiencies of NFS version 3, potential solutions for addressing these, and a cost/benefit analysis of the different solutions. Input for the development of this document will include experiences with other distributed file systems such as DCE/DFS and Coda. Following the publication of this document, the charter of the working group will be reassessed; however, it is anticipated that NFS version 4 will emphasize the following core features:

o Improved access and good performance on the Internet.

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

o Strong security with negotiation built into the protocol.

The protocol may build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. The permission model needs to scale beyond the current flat integer UID space.

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.

Goals and Milestones:

Jul 98


Issue strawman Internet-Draft for v4

Aug 98


Submit Initial Internet-Draft of requirements document

Sep 98


Submit Final Internet-Draft of requirements document

Oct 98


AD reassesses WG charter

Dec 98


Submit v4 Internet-Draft sufficient to begin prototype implementations

Oct 99


Begin Interoperability testing of prototype implementations

Dec 99


Submit NFS version 4 to IESG for consideration as a Proposed Standard.

Jun 00


Conduct final Interoperability tests

Aug 00


Submit NFS version 4 to IESG for consideration as a Draft Standard.


Request For Comments:







NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5



NFS Version 4 Design Considerations

Current Meeting Report

NFSv4 Working Group Meeting @ IETF 46, Washington D.C. 11/10/99

Reported by Brent Callaghan

WG co-chair, Brent Callaghan, welcomed the attendees and introduced the first speaker, document editor, Spencer Shepler. Spencer described the state of the v4 specification and enumerated some of the changes in the latest draft. The most significant additions were the delegation mechanism for file caching and Access Control Lists (ACLs) as a new file attribute. In addition, the definitions of the chown_restricted, rdattr_error, owner, and owner_group attributes were updated. The CREATE operation was fixed to allow the creation of symbolic links and special device nodes, and minor changes were made to the OPEN and READDIR operations. The text presenting the requirements for transport and congestion control requirements was improved. The RPC language protocol description was cleaned up. The next protocol draft will have some improvements to the LINK and RENAME operations, a complete section on minor versioning, and LIPKEY security.

The next speaker, Mike Eisler, described some minor changes to the LINK and RENAME operations that provide more flexibility in the specification of the target directory filehandle. Dave Noveck suggested that the stateid might be made persistent across a compound op like the filehandle, i.e. set the stateid with a PUTSTATEID operation. Mike responded that the proposal might have merit, but not enough to make it worth revising the spec at this stage. Mike went on to describe his proposal for minor versioning that he had posted previously to the mailing list. He suggested that the changes allowed by a minor version should be subject to some constraints if interoperability is to be preserved. For instance, new attributes can be added, but attributes cannot be deleted. In addition, he proposed the addition of a minor version field to the COMPOUND procedure so that the server knows the minor version that the client assumes, as well as an error that the server can return if the client requests a minor version that the server does not support. Ran Atkinson raised an issue as to whether the complexity of the minor version rules and mechanism made it worth adding to the protocol. Mike responded that minor versioning is a less heavyweight mechanism than a full RPC version change. Minor versioning also implies backward compatibility (which is not an RPC version requirement). Uresh Vahalia suggested that a change of some feature from "mandatory" to "recommended" might break the protocol. Mike said that this should not be a problem if the client and server both agree on the version. Ted Ts'o suggested a scenario where a minor version might be used to drop support for an operation considered "onerous." There seemed to be a consensus that the minor versioning rules should not be finalized until a minor revision is attempted. Mike completed his presentation with an update on LIPKEY security. LIPKEY is a public key mechanism based on the SPKM (rfc2025) and compatible with the RPCSEC_GSS security framework. LIPKEY borrows from SSL/TLS security in using the server's public key to establish a secure connection between client and server over which authentication can be negotiated securely. A public key is not required by the client. Since LIPKEY doesn't face the same key management problems of Kerberos v5, it is more suitable for NFSv4 security on an Internet scale.

The next speaker, Dave Noveck, gave a "worry" list of issues that are raised by the spec. The statefulness of v4 means that requests are not independent and some state may be unbounded. It is more important for v4 clients and servers to synchronize their times for lease or delegation expiration. Dave is also concerned that state in the protocol could require unbounded resources. Implementations will need to handle this. Dave concluded by pointing out that giving up on locking requests is not easy - either it must be forbidden or the protocol must specify a cleanup path.

WG co-chair, Brian Pawlowski, showed the results of some work to measure NFS throughput over TCP and UDP. Previous results had shown that TCP performance lagged UDP performance. Brian showed that a simple boost in the TCP window size produced throughput results superior to UDP. He concluded that the use of TCP as a preferred transport for NFSv4 would not be a problem. On the performance track, Brian questioned the performance cost of the new file attribute model and the compound operations. Some performance measurements need to be done to quantify the performance cost of these features. Brian enumerated some of the protocol features that must in the spec before the protocol can be declared "complete". The document editor is working to a December deadline for completion of a final draft of the spec for submission to the IESG as a Proposed Standard. He went on to suggest additional testing opportunities for interoperability. Obviously, Connectathon 2000 in March 2000 is a good opportunity, but another interoperability bakeoff will be needed in June or July.

The remainder of the time was allocated to open discussion. There was some concern about the ability of a v4 server to detect local access to a file that is OPEN or delegated by a v4 client. Brian suggested that a separate Informational RFC would be a useful document for examining some of these implementation issues in depth - rather than in the v4 spec. A final question queried the value of volatile filehandles since their properties are inferior to persistent filehandles. Spencer replied that volatile filehandles are inferior, but in many cases they are the only way that some filesystems or servers can make data available. Brian also pointed out that recent discussion of changes to the persistent file handle attribute on the WG alias appeared to have addressed the issue.

Brian concluded the meeting at 10:50am.


None received.