2.7.11 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-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



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 @ 49th IETF, San Diego

Reported by Brent Callaghan

After welcoming the participants and presenting the meeting agenda, Brent Callaghan gave a short presentation on the closing of the ONCRPC working group. This working group was originally formed to move the Informational RFCs that described the "Sun" RPC protocols (XDR RFC 1014 and RPC protocol version 2 RFC 1057) onto the Standards Track. The process involved clarifications and updates to the documents to bring them up to standards track quality, without any changes to the protocols themselves. These eventually became RFC 1832 (XDR), RFC 1831 (RPC) and RFC 1833 (Binding protocol) was added to include the previously undocumented Portmap/Rpcbind protocol. Also added was the RPCSEC_GSS standard in RFC 2203. Since NFSv4 depends on and references RFCs 1831, 1832, and 2203, it cannot advance along the standards track without these protocols. Hence, the IESG will transfer responsibility for these documents to the NFSv4 working group. Currently, all are at Proposed Standard except for RFC 1832 (XDR) which is at Draft.

Document editor, Spencer Shepler, then took the mike and gave an update on the NFSv4 specification and the NFS Implementation RFC. Little progress has been made on the Implementation RFC since the last meeting, but Spencer is taking input for the first draft which is expected around March 1st. At the last NFSv4 bakeoff event in October, some problems were found in the current specification that will need some changes to the document. He took several slides to briefly enumerate some of the issues that were brought up. Some of the changes will be clarifications in the text, though 2 or 3 others will require a change to the protocol. Spencer expects to have an amended spec ready for submission March 1st. This new draft will be assigned a new RFC number that obsoletes the current one (RFC 3010).

Co-chair, Brian Pawlowski, asked Allison Mankin to explain the procedure for updating the current Proposed Standard. Allison mentioned that IESG might measure the 6 month minimum time to submit a Draft standard relative to the publication of the first Proposed draft if the changes in a subsequent draft are minor.

Brian gave a presentation on the Replication and Migration work now before the working group. This work item was first discussed at length at the Pittsburgh meeting. Brian presented some material that consolidated some of the thoughts at that meeting. He gave a definition of the work and an overview of some previous replication work in filesystems like AFS and DCE/DFS as well as replica maintenance protocols like rsync and rdist. He listed several requirements. Client failover between replicas must be transparent to applications. Resolution of replica differences must be conservative of bandwidth, restartable and minimize lack of access to clients. The protocol must open no new security holes and be scalable from small filesystems to huge ones. Since replicas may be hosted on servers and filesystems with different capabilities, there must be provision for negotiating support of filesystem features and attributes between replicas. In response to a question about existing methods of replication via block-level mirrors, Brian added a requirement that that replication be supported independently of filesystem type and block layout. Since replication and migration is outside the working group charter, Brian agreed that a revised charter needs to be submitted and approved by the IESG.

The final segment of the meeting was opened up to general NFS version 4 issues. Brian kicked off the discussion with several: Compatibility with NFS versions 2 and 3 must be assured with lease handling compatible with those clients. Interactions of client transfer sizes and workloads should be studied so that implementations can be optimally tuned. Some utilities may need to be defined for state management, for instance, a utility that provides locking statistics or that provides a way to terminate a "stuck" client that is tying up file locks. A standard SNMP MIB that supports vendor independent management of NFS servers should be investigated. Finally, the SPEC SFS benchmark must eventually be extended to measure NFS version 4 performance.


NFSv4 RFC(Draft) Status
Open Issues
Replication and Migration