NFS version 4 Protocol
obsoleted by
- rfc-3530 — Network File System (NFS) version 4 Protocol
Extracted elements (34)
All server leases are given a single fixed interval (rather than variable lengths) to reduce the expense of maintaining state about variable-length leases across server failures.
NFS version 4 eliminates the separate MOUNT protocol for initial path-to-filehandle mapping, instead providing ROOT and PUBLIC special filehandles, because the MOUNT protocol had deficiencies in security and firewall traversal.
The COMPOUND procedure was introduced to reduce the number of RPCs needed for logical file system operations; for example, a client with no prior server contact can read file data in a single RPC by combining LOOKUP, OPEN, and READ operations, which was impossible with NFSv2/v3.
Volatile filehandles were introduced because some server environments cannot provide file system level invariants needed for persistent filehandles (e.g., hierarchical storage management or file system reorganization). The increased client implementation burden is deemed acceptable for the overall protocol gains.
File and directory names are encoded with UTF-8 (component4 typedef utf8string) to address internationalization requirements. This is a departure from previous NFS versions which used local character set encodings.
Minor versioning allows new mandatory or recommended attributes to be added to NFS between major revisions by publishing a standards-track RFC that allocates a new attribute number and defines encoding, without breaking backward compatibility.
If possible, the client SHOULD recover from receipt of an NFS4ERR_FHEXPIRED error by storing component names leading to the file system object so it can re-traverse the namespace to obtain a fresh filehandle.
If TCP is used as the transport, the client and server SHOULD use persistent connections to prevent weakening of TCP's congestion control via short-lived connections and to improve WAN performance.
Mandatory attributes MUST be supported by every NFS version 4 client and server to ensure a minimum level of interoperability; the server must store and return them and the client must be able to function with only these attributes.
Once a server creates a persistent filehandle for a file system object, the server MUST accept that same filehandle for the lifetime of the object, including across server restarts and file system migration.
The callback RPC must mutually authenticate the NFS server to the principal that acquired the clientid using the same security flavor the original SETCLIENTID operation used; the server MUST identify itself via a GSS_C_NT_HOSTBASED_SERVICE name of the form nfs@hostname.
The client MUST NOT interpret the contents of filehandles beyond byte-by-byte equality comparison. If two filehandles from the same server are equal, they MUST refer to the same file.
The Kerberos V5 GSS-API mechanism MUST be implemented and provide three security triples: krb5 (rpc_gss_svc_none), krb5i (rpc_gss_svc_integrity), and krb5p (rpc_gss_svc_privacy), all using OID 1.2.840.113554.1.2.2 with DES MAC MD5.
The LIPKEY GSS-API mechanism MUST be implemented and provide security triples for none, integrity, and privacy services using OID 1.3.6.1.5.5.9 with negotiated algorithms layered over SPKM-3.
The RPCSEC_GSS security flavor as defined in RFC 2203 MUST be used as the mechanism to deliver stronger security for the NFS version 4 protocol. Other flavors such as AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well.
The SPKM-3 GSS-API mechanism MUST be implemented and provide security triples for none, integrity, and privacy services using OID 1.3.6.1.5.5.1.3. SPKM-3 is mandatory to handle anonymous initiators or initiators with their own certificates.
The transport used by RPC for NFS version 4 MUST provide congestion control comparable to TCP as defined in RFC 2581. If TCP is available, NFS version 4 SHOULD be supported over TCP.
When the server is presented with a persistent filehandle that refers to a deleted object, it MUST return an error of NFS4ERR_STALE.
File attributes are classified into three groups: mandatory (must be supported by all clients and servers), recommended (well-defined but optional), and named (opaque byte streams accessed by string name via OPENATTR, used for application-specific metadata).
File locking uses a lease-based model: the server defines a single lease period for all state held by an NFS client, and if the client does not renew its lease within the period via RENEW or other operations, all lock state associated with the client may be released.
NFS version 4 introduces two filehandle types: persistent (valid for the lifetime of the file system object, equivalent to NFSv2/v3 behavior) and volatile (may expire at various points indicated by the fh_expire_type attribute bitmask with values FH4_PERSISTENT, FH4_NOEXPIRE_WITH_OPEN, FH4_VOLATILE_ANY, FH4_VOL_MIGRATION, FH4_VOL_RENAME).
The client identity (Clientid) is a 64-bit shorthand reference established via the SETCLIENTID and SETCLIENTID_CONFIRM operations; it incorporates a client-supplied verifier4 (8-byte opaque) used by the server to detect client restarts and loss of lock state.
The COMPOUND procedure is the primary RPC operation in NFS version 4, allowing multiple operations to be combined in a single RPC call evaluated sequentially. The protocol has only two RPC procedures: NULL and COMPOUND.
The delegation mechanism allows the server to grant a client either a read delegation (no other client can write for the duration) or write delegation (no other client has read or write access), enabling local servicing of OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate server interaction. Delegations can be recalled via a callback path.
The SECINFO operation allows the client to determine on a per-filehandle basis what security triple is required for server access. The server signals a security mismatch via NFS4ERR_WRONGSEC, prompting the client to query available security mechanisms.
Section 17 establishes IANA consideration for Named Attribute definitions. Names of named attributes are not controlled by IETF standards-track documents; the IANA registry governs their allocation.
NFS version 4 servers must be able to recover without data loss from multiple power failures, OS failures, and hardware failures other than storage medium failure. Stable storage options include media commit, battery-backed drives, and UPS with recovery software.
Security negotiation between client and server must be done over a secure channel to eliminate the possibility of a third party intercepting the negotiation and forcing selection of a weaker security mechanism than required.
Client ID negotiation: client sends SETCLIENTID with nfs_client_id4 (verifier + opaque id) and callback address, server responds with clientid4 and confirm verifier; client must then send SETCLIENTID_CONFIRM to activate the clientid. A new verifier from a previously known client causes the server to release prior lock state.
Delegation lifecycle: server grants read or write delegation at OPEN; server may recall delegation via CB_RECALL callback when a conflicting access is requested; client must return delegation via DELEGRETURN; if callback path does not exist, delegations cannot be granted.
fattr4 encodes attributes as a bitmap4 (variable-length array of uint32 bit vectors) plus attrlist4 (opaque byte array of attribute values). Bit position n is in integer at index (n/32) at bit (n mod 32).
nfs_fh4 is defined as opaque data with a maximum size of NFS4_FHSIZE (128 bytes). The filehandle is opaque to the client and contains all information the server needs to identify a file system object.
nfstime4 encodes time as a struct with int64 seconds (since January 1, 1970 UTC) and uint32 nseconds; nseconds values greater than 999,999,999 are invalid. Negative seconds represent dates before the epoch.
verifier4 is an opaque fixed-length 8-byte (NFS4_VERIFIER_SIZE) field used in COMMIT, CREATE, OPEN, READDIR, SETCLIENTID, and WRITE operations. stateid4 and clientid4 are both uint64 values.