2.6.10 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@east.isi.edu>

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:



Issue strawman Internet-Draft for v4



Submit Initial Internet-Draft of requirements document



Submit Final Internet-Draft of requirements document



AD reassesses WG charter



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 Meetings @ 48th IETF Pittsburgh

Reported by Brent Callaghan

Monday Session (2 hours)

Document editor, Spencer Shepler, began by describing some of the features of the NFSv4 implementation RFC that he is working on. The purpose of this Informational RFC is to make information available to help implementors of the protocol. This information isn't strictly necessary to describe the protocol, and would add unnecessary bulk to the NFS version 4 protocol specification. As an example of content, Spencer mentioned:

Brent Callaghan gave a brief report on the recent NFSv4 bakeoff event held in Santa Clara, CA. July 11-13. This is the third event that tested NFSv4 interoperability. The first bakeoff was held October last year, and further v4 testing was seen at Connectathon in March. This bakeoff saw 7 implementations from 5 organizations. New this time was an OpenBSD implementation from the University of Michigan CITI group. Much use was made of a v4-enhanced version of the snoop packet analyzer, and a Tcl-based client called "nfsv4shell" that allowed testers to test NFSv4 operations interactively.

Brian Pawlowski presented possibilities for future work if the working group is re-chartered. These include:

He listed some requirements and issues for migration and replication:

Brian concluded with an interactive discussion on future work topics. He suggested that the working group could be re-chartered to cover a migration/replication project and suggested this as a simpler option to the alternative of winding up the group and forming a new one. A risk with pursuing this additional work is that it might drain resources from the on-going standards-track work to take NFSv4 implementations to draft. However, given the time it takes to take a new protocol to the point at which it can be implemented, there is likely little overlap in effort. Other projects that could be included in a re-charter include an SNMP MIB to promote interoperable server management and a name space project that could yield an implementation document for naming. There may be some interest in a disconnected operation project, though this may be just an implementation issue, and may not need the direct attention of a working group.

Tuesday Session (1 hour)

Brian Pawlowski lead an interactive discussion on the requirements of a file migration and replication protocol. There are some sticky issues with file migration: it is difficult to migrate or replicate files with a consistent fileid attribute. Other file attributes could be difficult to migrate or replicate, particularly across heterogeneous filesystems. Atomicity guarantees may require filesystem support of snapshots.

He provided an example of file migration in DFS. First, a filesystem operation creates a read-only clone of the fileset to be migrated. While this cloned fileset is moved, the read-write primary continues to be updated. In a second phase, the primary is locked briefly to all update traffic while the updates since the clone operation are moved. When the updates have been moved, the clients are switched atomically to the fileset at the new location. Clients never see a partially migrated fileset, the final atomic switch is not done if there are any errors. Although this method of migrating filesystems is very efficient and convenient, it does require a lot of support from the server's filesystem, e.g. the ability to create copy-on-write clones, and to identify and move updates to the clone.

The rsync protocol (see www.samba.org) provides an efficient file-level protocol for synchronization of file updates between two filesystems over a TCP connection. It handles recovery from failed synchronization and can detect and resolve file byte-range insertions and deletions. It provides no support for atomicity.

Brian built a list of requirements for file migration/replication:

Further discussion on the topic will be left to the mailing list.

Simon Cooper of SGI raised some concerns on NFSv4 security in the final minutes of the meeting. He said that the RPCSEC_GSS RFC leaves security negotiation up to the higher-level protocol, yet NFSv4 doesn't describe security negotiation outside of GETSECINFO. He suggested that it is inadequate since it does not require a secured connection between client and server. Given the time constraint, further discussion will be moved to the NFSv4 mailing list.


The slides from the meeting can be viewed at:



Bakeoff @ Techmart
NFSv4 Workgroup Directions (Day1)
NFSv4 Workgroup Directions (Day2)
NFSv4 I-D Status