2.8.10 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-17

Brian Pawlowski <beepy@netapp.com>
Spencer Shepler <spencer.shepler@sun.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: nfsv4@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4
Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html
Description of Working Group:
The objective of this working group is to advance the state of NFS technology by producing specifications to extend the original NFS Version 4 work (RFC 3010) to provide additional capabilities, as described below.

o NFS version 4

Advance the protocol along the standards track, coordinating the development of test suites to provide a high level of implementation quality. The ONC RPC standards that NFSv4 references must also be advanced. This includes work to make NFSv4 and the underlying ONC RPC protocol compatible with IPv6. Specifically, we will advance RFC 3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working group will help advance related security RFCs, specifically through the definition of a method to advance APIs.

o Replication and Migration

The original working group defined a mechanism for NFS clients and servers to support replication and migration of data transparently to an application. Left undefined in the initial work was the server back end migration and replication mechanism. The working group will produce a draft submission of a replication/migration protocol that supports NFS Version 4 clients - needed to create and maintain replicated filesystems as well as migrating filesystems from one location to another - and servers for consideration as Proposed Standard.

o Management

The working group will produce a draft submission for consideration as Proposed Standard of a management MIBs to provide better management and administration capabilities for NFS and ONC RPC.

o Minor Versions

NFS Version 4 contains within it the capability for minor versioning. Some discussions within the working group suggest addressing additional requirements over the original charter. The WG will work to identify additional requirements for NFSv4 and determine if they are appropriate and worthwhile for a minor version. This work may lead to proposals for additional work items. If it does a specific proposal to add these work items to the charter will be forwarded to the IESG and IAB.

o RDMA/RDDP enabling

The performance benefit of RDMA/RDDP transports in NFS-related applications, by reducing the overhead of data and metadata exchange, has been demonstrated sufficiently such that the working group will pursue in parallel enabling NFS and RPC over the transport defined by the RDDP working group. The WG will restrict its initial activities to defining the problem statement and specifying the requirements for possible extensions to RPC and NFS (in the context of a minor revision).

Goals and Milestones:
Done  Issue strawman Internet-Draft for v4
Done  Submit Initial Internet-Draft of requirements document
Done  Submit Final Internet-Draft of requirements document
Done  AD reassesses WG charter
Done  Submit v4 Internet-Draft sufficient to begin prototype implementations
Done  Begin Interoperability testing of prototype implementations
Done  Submit NFS version 4 to IESG for consideration as a Proposed Standard.
Done  Conduct final Interoperability tests
Done  Conduct full Interoperability tests for all NFSv4 features
Done  Update API advancement draft
Done  Form core design team to work on NFS V4 migration/replication requirements and protocol
Done  Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard
Done  Strawman NFS V4 replication/migration protocol proposal submitted as an ID
Mar 03  ADs to submit API advancement internet draft as informational RFC (needed to advance GSSAPI to Draft Standard to allow advancement of NFS Version 4)
Mar 03  Continued interoperability testing of NFS Version 4
Apr 03  Internet draft on NFS V4 migration/replication requirements
Apr 03  AD review of NFS V4 migration/replication requirements draft
Apr 03  Creation of internet draft on ONC RPC MIB
Apr 03  Revision of internet draft on NFS MIB
Apr 03  Draft problem statement I-D for NFS/RPC/RDDP submitted
May 03  Document full Interoperability tests for all NFSv4 features
Jun 03  Depending on results of AD review of NFS Version 4 migration/replication requirements document, review scope of task
Jun 03  Submit related Proposed Standards required by NFS Version 4 for consideration as Draft Standards to IESG - RFCs 1831, 1833, 2203, 2078, 2744, RFC 1964, & 2847
Jun 03  Draft requirements document I-D for NFS/RPC/RDDP submitted
Jun 03  Submit ONC RPC and NFS MIBs to IESG for consideration as Proposed Standards
Jun 03  Submit an NFS V4 migration/replication protocol to IESG for consideration as a Proposed Standard
Jun 03  Submit report on results of NFS version 4 RFC interoperability testing
Jul 03  AD review of NFS/RPC/RDDP progress and charter
Jul 03  Interoperability tests of NFS V4 migration/replication
Aug 03  Submit revised NFS Version 4 Proposed Standard for consideration as Draft Standard to IESG
  • - draft-ietf-nfsv4-rfc1832bis-04.txt
  • - draft-ietf-nfsv4-ccm-03.txt
  • - draft-ietf-nfsv4-secinfo-02.txt
  • - draft-ietf-nfsv4-rpc-iana-01.txt
  • - draft-ietf-nfsv4-rfc1831bis-03.txt
  • - draft-ietf-nfsv4-acl-mapping-01.txt
  • - draft-ietf-nfsv4-channel-bindings-02.txt
  • - draft-ietf-nfsv4-nfs-rdma-problem-statement-01.txt
  • - draft-ietf-nfsv4-rpcrdma-00.txt
  • - draft-ietf-nfsv4-nfsdirect-00.txt
  • - draft-ietf-nfsv4-directory-delegation-00.txt
  • - draft-ietf-nfsv4-sess-00.txt
  • Request For Comments:
    RFC2623 PS NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
    RFC2624 I NFS Version 4 Design Considerations
    RFC3010 PS NFS version 4
    RFC3530 PS Network File System (NFS) version 4 Protocol

    Current Meeting Report

    Network File System Version 4 (nfsv4)

    Tuesday, August 3, 2004 at 0900-1130


    Brian Pawlowski <beepy@netapp.com>
    Spencer Shepler <spencer.shepler@sun.com>


    Welcome and Introduction (Pawlowski) 5 min
    Agenda bash etc.
    - Status of drafts

    Interim meeting and bakeathon results (Shepler) 10 min

    Transfer of RPC Numbering to IANA (Shepler) 2 min

    On the Use of Channel Bindings to Secure Channels (N. Williams) 10 min

    NFS RDMA Problem Statement (Talpey) 3 min

    RDMA Transport for ONC RPC (Talpey) 3 min

    NFS Direct Data Placement (Talpey) 3 min

    NFSv4 Session Extensions (Talpey) 20 min

    NFSv4.1: Directory Delegations and Notifications (Khan) 15 min

    Migration Issues for NFSv4 (Noveck) 15 min

    Server recovery issues (Noveck) 10 min

    Implementation Best Practices (Pawlowski) 10 min

    NFSv4 minor version planning (Shepler) 25 min

    Open discussion (Pawlowski) 10 min

    Wrapup (Pawlowski) 5 min


    Beepy welcomed and introduced; reviewed "note well" and started the blue sheets for attendance.

    Spencer covered the status of the existing drafts and working group milestones. Noted that the milestones are woefully out of date and that effort to update will start very soon.

    The XDR draft is ready for working group last call and as a reminder this will be for a move to Internet Standard. Rob Thurlow has updated the RPC draft and that too, after one round of minor updates, will be ready for working group last call. Still working the issues of transfer of RPC program number assignment to IANA but that will be dealt with as part of the normal update to the RPC RFC and Sun will be seeding the number allocations based on its record. An I-D explaining the transfer does exist.

    The draft on V4.1 SECINFO minor version item is considered complete - locked down and ready to go. CCM is GSS exploit of underlying transport to eliminate double encryption is also ready. Plan is to divide labor between us and security area.

    Tom Talpey mentioned that the NFS/RDMA problem statement is a working group draft and will be taken forward as an informational RFC. The RDMA transport/DDP is intended for minor versioning.

    Note that the current directory delegations I-D is targeted as a minor versioning items as well.

    Note that the ACL mapping I-D has not been refreshed.

    Spencer reviewed the interim meeting results at the Bakeathon in June.
    - Talpey added additional author and updated the sessions draft.
    - Saadia has updates from discussion to directory delegations draft.
    - ADs have agreed we have good things queued up for minor versioning.
    - Interim meeting interrupted by tornado warning.

    On with the regular presentation section:

    "On Channel Bindings" - Nico Williams. About how you avoid double encryption, exploit a secure channel underneath. Point is to have a lightweight authentication based on Eisler's notions to allow leverage of a secure channel. Intended for use in RDDP and other NFS deployments (leverage HW acceleration). Back and forth with Talpey and Nico on negotiation of channel bindings - who owns, implementation choice? Nico says GSS/RPC layer will own. David Black and Nico chatted about I-Ds and peers and men in the middle and ... "Group pre-shared keys work just fine with IKE," David Black.

    Talpey NFS-RDMA drafts. Three of them describing protocols. RDMA for ONC RPC - enables RDMA also for V2 and V3 - but not spending much time discussing legacy lock manager etc.

    ONC RPC over RDMA - a WG item. Inserts a slightly more complex marker to allow marshalling RDMA data. Leverage copy avoidance. No semantic extensions. Since last Ann Arbor meeting - chunking only impacts data.

    NFS Direct Data Placement - republished in July as a working group item. See slides for more details. NFS is blissfully unaware of most issues with RDMA usage beyond providing a buffer target.

    V4 Sessions draft - Jon Baumann added as co-author given changes he has introduced from his server work. Sessions are not RDMA specific - but there is a chapter on use of sessions with RDMA. See slides. Talpey argued that XIDs are wimpy - tightened up with sequence ID. Chaining removed in Ann Arbor - ordering constraints were its downfall. Sufficiently large COMPOUNDs get around it. Session BIND went away - problem arose in reconnect, which is an RPC level recovery, unable to force an NFS op into the rebind sequence which was serious layer violation.

    Saadia Khan - directory delegations and notifications. To reduce traffic between client and server. Saadia covered the changes introduced in Ann Arbor - see slides. Need attribute notifications with directory notifications. Draft currently defines notifications as asynchronous - but needs further discussion. Currently depends on sessions being in V4.1 - will have to be changed if sessions fails to make it. Spencer said synchronous notifications would enable negative lookup elimination - big win. Saadia to follow up with a the problem statement and nail requirements on the feature on the alias.

    Noveck on migration, replication and referrals. Some issues with RFC 3530. He produced an I-D. Noveck argues that while not explicitly mentioned, referrals exist. But referrals (telling a client attempting to access a recently moved file is somewhere else) seem to work. Evanescent file handles - the Quantum Mechanical view. The file handle for a migrating root file system. Garth Gibson observes this is Windows DFS like functionality. What about a global name space - referrals do not define a server to server communication to join to construct one. See slides... Description needs work in spec moving forward to clarify referrals and have explicit section. Errata? In V4.1? How to deal with clarification.

    Noveck - Lock Recovery Delimitation... section 8.6.3 issues. Need mechanism to determine when a client is done reclaiming locks in face of network partition during lock reclaim. Edge condition. Argh. Fix possibilities. Client can back off on reclaim in face of rebooting server. But server may persistently store locks to remember the sequencing. Spec tries to allow for servers that explicitly store lock state. Trond suggests using setclientid to time shift grace period forward - there may be a workaround here - need to follow up. Noveck observes it does not work with servers that implement persistent locks. Grace period length is issue - Noveck observes long grace period in conflict with non-reclaim OPENs. Wants ti introduce DONE_RECOVERY op. Want closure on this on the list.

    Beepy discussed implementation doc proposal. Practical status of NFSv4: numerous v4 releases are in the pipeline. 4Q04 and 1Q05 will get interesting! I.e. users will begin to see this

    How to turn it off?
    How to turn it on!

    Security negotiation ("strongest security") may be problematic going forward - needs careful doc. We need to manage the v2/v3 legacy interactions through doc.

    Beepy wants to resurrect the "implementation document". Focus on best practices. Not a client implementors doc, but a description of implementations for sysadmins and users. Also document the protocol features (with an eye toward having it as we move to Draft Standard).

    Beepy intends to produce this document by September 30. Informational RFC track.

    Shepler - Minor Versions. I-Ds are piling up. Implementations and deployment experience are pointing to additional fruitful areas to pursue. (Earlier, beepy asked about how minor versions put out - separate addendum doc? whole new doc with 4.0 core/fixes?) Issues? Limit content - set time. One RFC or separate docs? Shepler to talk to ADs how to proceed on docs and proposal to list.

    Ran out of time and things to discuss at the same time. Meeting ended.


    NFSv4 WG Meeting
    On Channel Bindings
    NFS/RDMA Draft Status
    Directory Delegations and Notifications
    Migration, Replication, and Referrals
    Lock Recovery Delimitation
    NFS Version 4 Best Practices
    NFS/RDMA Draft Status