2.7.11 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00

Chair(s):

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2623

PS

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

RFC2624

 

NFS Version 4 Design Considerations

Current Meeting Report

NFSv4 Working Group Meeting @ IETF 47, Adelaide
-----------------------------------------------

Reported by Brent Callaghan

The NFSv4 working group met in two sessions. The first on Monday evening for 2 1/2 hours and the second on Tuesday night for 1 hour. The meetings were attended by 20 people. WG co-chair,
Brent Callaghan, welcomed the attendees and introduced the first speaker, document editor, Spencer Shepler.

Spencer gave a quick summary of the changes that went into draft 06. He added some new compound operations: OPEN_CONFIRM, SETCLIENTID_CONFIRM, and OPEN_DOWNGRADE, and clarified the text of the RENEW operation. The document is currently pending IESG review and more minor updates are expected following this review. Spencer then went on to describe some of the contents of an Implementation Choices RFC. The intent of this RFC is to describe implementation detail specific to operating systems such as UNIX. This level of detail would be innapropriate in the protocol spec. Spencer suggested the following items be included:

- Suggestions for persistent and volatile filehandle content.
- How to support Internationalized text strings on filesystems that support single-byte encodings.
- Discussions of client and server state management.
- Options for converting between owner/group identities and protocol string representation.
- Issues with allowing local access to an exported filesystem on a server (having NFS detect access to delegated files).
- Managing missing attributes, solutions for file migration and replication.
- Translating Access Control Lists from one representation to another.
- Mapping locking and lease semantics across heterogeneous servers.

Brent summarized the results of the NFS v4 testing at Connectathon. As with the previous bakeoff in October, there were six servers and 4 clients from 5 vendors. The Solaris snoop sniffer with extensions to handle NFSv4 decodes was used as well as a new Tcl-based testing client. In addition to testing some of the simpler ops (putrootfh, getfh, lookup, getattr) there was some testing of more complex v4 ops (open, create, rpcsec_gss security).

Bev Crair of Sun announced the availability of TI-RPC source from Sun under the new Sun Industry Standards Source License (SISSL) - downloadable from http://soldc.sun.com . This source contains an implementation of the GSS-API (rfc2078) and RPCSEC_GSS (rfc2203) along with updated RPC and XDR source code. Sun also makes binaries of its NFS v4 prototypes available under an evaluation license (contact dana.barsan@eng.sun.com). The NFSv4 Tcl testing client, nfsv4shell, will be made available in source form mid-April. Sun also continues to license its ONC+ source to ONC+ licensees. The ONC+ license may provide early access to NFS v4 product source.

Co-chair, Brian Pawlowski lead an interactive discussion through the remainder of the session and the 1 hour session on Tuesday night. Costas Sapuntzakis asked whether there was still interest in adding protocol support for hardware decode of NFSv4 requests. In a previous post to the list he suggested the addition of byte counts fields that would allow ops containing large chunks of data to be located quickly with a minimum of protocol parsing. The consensus seemed to favor leaving the protocol alone - with a contention that smart enough hardware could parse without the additional fields. Neil Brown asked how key exchange would be handled by LIPKEY in the reverse direction when the server makes a callback (section 3.4 in the spec). Mike Eisler suggested that the server might return a public key to the client (Mike subsequently followed up with an additional proposal on the list). There was some discussion on the properties of the changeid attribute: whether it should increase or decrease. Consensus seemed to be that the value should increase (acknowledging wraparound for overflow).

Brian wound up the discussion by soliciting proposals for further work that the WG could undertake:

- Proxying support
- The protocol is not currently proxyable.
- Implementation Choices document
- As described in Spencer's presentation.
- Migration/replication protocols
- The NFSv4 protocol does not describe protocols for back-end migration of file data or replica management.
- Global naming
- There is no global namespace described for NFSv4. Possibilities include automounter-style naming (/net/server), NFS URLs, or AFS-style global namespaces.
- Hardware acceleration
- Opportunities for accelerating protocol processing with hardware.
- Minor versioning
- Development of a minor version of the protocol that includes some of the above features.

------------------------

The slides from the meeting can be viewed at:

http://playground.sun.com/pub/nfsv4/presentations/ietf47

------------------------

Slides

Agenda
NFSv4 @ Connectathon 2000
NFSv4 I-D Status
Code from Sun Microsystems