2.7.9 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Vern Paxson <vern@ee.lbl.gov>

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

Mar 99


Begin Interoperability testing of prototype implementations

Apr 99


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

Sep 99


Conduct final Interoperability tests

Oct 99


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


No Request For Comments

Current Meeting Report

NFSv4 Working Group Meetings @ 43rd IETF Orlando

Reported by Brent Callaghan

First Session (Mon Dec 7th 9:00 - 10:00am)

Both sessions were attended by 35 people (according to the blue sheet). WG co-chair, Brent Callaghan, welcomed the participants and outlined the agenda for both sessions.

He then presented an overview of the NFS version 4 server namespace proposal. NFS version 2 and 3 servers export independent pieces of their namespace and do not allow NFS clients to cross mountpoints on the server. Clients that need to browse the server's namespace must currently obtain a static snapshot of the server's namespace using the EXPORT procedure of the mount protocol and attempt to replicate the exported namespace in mirror image on the client. NFS v4 servers can be made browsable by connecting exported sub-trees of the namespace with a pseudo filesystem and allowing clients to cross server mountpoints. Brian Pawlowski mentioned that client crossing of server mountpoints might be something that a server administrator might need to control. Brent agreed, pointing out that this is an implementation detail.

Document editor, Spencer Shepler, followed with an overview of the NFS version 4 Requirements document that he first presented in preliminary draft at the Chicago meeting. The current draft is assumed to be final (last call has expired) and it has been submitted to the IESG for review. Based on this review, a final version of the Requirements document will be issued as an RFC and the Working Group Charter will be amended if necessary. The topics covered in the document are:

- Ease of Implementation
- Reliable and Available
- Scalable Performance
- Interoperability
- RPC and Security
- Internet Accessibility
- File Locking
- Internationalization

The draft submitted to the IESG can be viewed at: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-requirements-03.txt

Rob Thurlow gave the final presentation of the session on the NFS Version 4 Attributes. The proposed attribute model allows clients to retrieve attributes individually and allows servers to support a subset of the standard set of attributes. A topic of concern is whether some attributes should be declared "mandatory" while others are "recommended". Some mandatory attributes may make some client implementations easier - but may cause problems if some servers cannot support some of the mandatory attributes. Rob also described a set of "extended" attributes that could be assigned text names and opened like files. An OPENATTR operation would make these attribute files accessible. There was some discussion of support for an ACL protocol. Brent pointed out that there are several styles of ACL: POSIX draft, DCE, and Microsoft NT. There seems to be consensus that support for an ACL attribute would be welcomed, but building an interoperable model will be a challenge.

At question time, Dan Trufasiu of HCL expressed concern that interoperability would suffer if clients and servers implemented non-overlapping subsets of the attributes. Brent suggested that some stronger language might be necessary in the spec to promote implementation of all attributes.

Second Session (Mon Dec 7th 10:15 - 11:15am)

WG co-chair, Brian Pawlowski, introduced the second session and proceeded with a presentation on client and server failover issues for NFS version 4. He began with a survey of existing examples of distributed filesystem replication and failover: the Andrew Filesystem (AFS) supports failover to replicas that can be lazy-updated from a single writeable volume and Solaris NFS provides client-side failover for read-only replicas. As requirements for NFS v4, Brian suggested that it should provide better support for read-only replication, and support transparent migration of volumes from one server to another. He proposed that clients should be able to elicit alternative replica locations when mounting a filesystem from a server (to be used if the server crashes) and that the server should support some kind of redirect facility for when volumes are moved. At question time, Mike Eisler suggested that Craig Everhart's proposal for a multi-level filesystem-id might work well to identify relocatable filesets.

David Robinson described a new file locking proposal that uses a OPEN/CLOSE operations to support PC clients that need to be able to open or create files and establish file locks atomically. A "state id" returned by the server identifies the client's lock state. The state id is required as an argument to READ and WRITE operations where mandatory locking is enforced. He listed a number of outstanding issues that need to be resolved: the current proposal needs a cleanup, a lease-refresh procedure might be used instead of a zero-length READ, locks to support long-term caching would be useful (like oplocks), and there is concern as to the performance of client polling of blocked locks.

Mike Eisler spoke on NFS version 4 security - the final talk of the session. He described existing practice with NFS versions 2 and 3 and the work to standardize RPCSEC_GSS security within the ONCRPC working group. He indicated the security requirements for NFS v4: a mandatory set of security mechanisms, secure negotiation, and strong authentication, data integrity and privacy. He proposed NFS v4 require RPCSEC_GSS security with Kerberos v5 support as one of the required mechanisms. There was no dissent from the participants. He went on to indicate that an Internet-scale, public key scheme is still not defined. SPKM is one possibility. He raised some security issues that need further discussion: will the IESG accept an optional requirement for data integrity and privacy ? How does SSL fit in ? (It won't work over UDP and cannot be negotiated via RPCSEC_GSS). He recommended the "Globus" model for a public key solution (see http://www.globus.org/security ).

There being no further questions, Brian Pawlowski concluded the session at 11:05am.


Welcome and Agenda
NFS Version 4 Requirements
NFS Server Namespace
NFS Version 4 Attributes
NFS Version 4 Locking
NFS Version 4 Security