Network File System (NFS) version 4 Protocol
obsoleted by
- rfc-7530 — Network File System (NFS) Version 4 Protocol
obsoletes
- rfc-3010 — NFS version 4 Protocol
Extracted elements (30)
File locking is integrated into the core NFS v4 protocol rather than a separate NLM protocol, using a lease-based model that does not require RPC callbacks for lock acquisition. A fixed lease interval was chosen (rather than variable) to reduce server state recovery overhead after failures.
NFS v4 eliminates the separate MOUNT protocol used in v2/v3 for obtaining the first filehandle. Instead, two special filehandles are provided: ROOT (via PUTROOTFH) and PUBLIC (via PUTPUBFH). The MOUNT protocol was eliminated because it had security deficiencies and did not traverse firewalls well.
The open_owner4 identifier was added to the state model (relative to RFC 3010) specifically to accommodate POSIX-based clients, where a file descriptor may be shared among processes (open_owner4) while individual processes hold locks (lock_owner4). This mapping enables correct POSIX file locking semantics over NFS.
Volatile filehandles were introduced to accommodate server environments where persistent filehandles are infeasible due to the lack of filesystem-level invariants, or where hierarchical storage management or filesystem reorganization makes persistence impractical. The tradeoff is increased client implementation burden to re-traverse the namespace on expiry.
NFS v4 clients and servers must support a minimum security set of LIPKEY, SPKM-3, and Kerberos-V5 under RPCSEC_GSS. When a server returns NFS4ERR_WRONGSEC, the client must invoke SECINFO to discover available security triples for that filehandle and select an appropriate one before retrying.
A persistent filehandle MUST be accepted by the server for the lifetime of the object, including after server restart and after filesystem migration. When presented with a persistent filehandle referring to a deleted object, the server MUST return NFS4ERR_STALE.
The callback RPC MUST mutually authenticate the NFS server to the principal that acquired the clientid using the security flavor the original SETCLIENTID operation used. The NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name of the form 'nfs@hostname'.
The client MUST NOT interpret the contents of filehandles. If two filehandles from the same server are equal, they MUST refer to the same file. Clients MUST use filehandle comparisons only to improve performance, not for correct behavior.
The Kerberos V5 GSS-API mechanism MUST be implemented and provide 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 for integrity and 56-bit DES for privacy.
The LIPKEY GSS-API mechanism MUST be implemented with OID 1.3.6.1.5.5.9 providing lipkey, lipkey-i, and lipkey-p triples. SPKM-3 MUST also be implemented with OID 1.3.6.1.5.5.1.3 providing spkm3, spkm3i, and spkm3p triples.
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 server is required to increment the seqid field of stateid4 monotonically at each transition of the stateid, since the client inspects the seqid in OPEN stateids to determine the order of OPEN processing done by the server.
When processing a request received over a reliable transport such as TCP, the NFS version 4 server MUST NOT silently drop the request except if the transport connection has been broken. Clients MUST NOT retry a request unless the transport connection has been broken or the procedure being retried is the NULL procedure.
Where an NFS version 4 implementation supports operation over the IP network protocol, the supported transports MUST be among the IETF-approved congestion control transport protocols. An NFS version 4 implementation MUST support operation over the TCP transport protocol.
File attributes are classified into three types: mandatory (server must support, e.g., fsid, fh_expire_type), recommended (server should support, e.g., ACL, fs_locations), and named (opaque byte streams accessed via OPENATTR and identified by string names, intended for application-specific metadata). Mandatory and recommended attributes use numbered bit-vector encoding.
NFS v4 defines two filehandle types: persistent (fixed value for the lifetime of the filesystem object) and volatile (may expire at points determined by the server). The mandatory fh_expire_type attribute bitmask communicates expiry semantics via flags: FH4_PERSISTENT, FH4_VOLATILE_ANY, FH4_NOEXPIRE_WITH_OPEN, FH4_VOL_MIGRATION, and FH4_VOL_RENAME.
Open delegation allows the server to grant a client a read or write delegation for a file at OPEN time. A read delegation guarantees no other client can write; a write delegation guarantees exclusive access. Delegations are recalled via server callback (CB_RECALL) when conflicting access is requested and require a working callback path to be granted.
The COMPOUND procedure is the primary RPC mechanism in NFS v4, allowing multiple operations to be sent in a single RPC request evaluated sequentially by the server. A 'current filehandle' and 'saved filehandle' are maintained across operations. Once any operation returns a failure, evaluation stops and all partial results are returned.
The lease-based locking model maintains all client file lock and open state at the server under a single lease period. If the client does not renew its lease within the defined interval, all state associated with the client may be released by the server. The client may renew its lease via the RENEW operation or implicitly through READ and other operations.
The SECINFO operation allows the client to determine on a per-filehandle basis what security triple (mechanism, QoP, service) is required for server access. The client uses it during initial communication or when crossing security policy boundaries, and in response to NFS4ERR_WRONGSEC errors.
IANA maintains a registry for NFS version 4 Named Attributes. New named attributes require a standards-track RFC defining the attribute's name, syntax, semantics, and encoding; the IANA registration is the attribute name string.
IANA maintains the ONC RPC Network Identifiers (netids) registry. NFS v4 specifies the netid strings 'tcp', 'udp', 'tcp6', and 'udp6' for use in the clientaddr4 r_netid field to identify the transport and address family.
56-bit DES used in Kerberos V5 Kerberos security triples is no longer considered state-of-the-art against brute-force attacks. Implementors are urged to incorporate AES once RFC 1964 is revised to add AES support, and users are urged to migrate to AES.
Security negotiation between client and server must occur over a secure channel to prevent a third party from intercepting and forcing a downgrade to a lower security level than required. The NFS v4 authentication model has moved from machine-based to principal-based, though TCP connection management remains per-machine for scalability.
Client identity is established via SETCLIENTID (providing a verifier4 and opaque client ID string) followed by SETCLIENTID_CONFIRM. The server issues a 64-bit clientid4 shorthand reference. If the client presents a new verifier (indicating restart), the server schedules release of prior state. If the same verifier is presented with the same client ID, the prior clientid is returned.
File open state transitions: OPEN returns an open stateid (seqid incremented per transition); the first OPEN by an open_owner4 may require OPEN_CONFIRM to validate. Open access can be downgraded via OPEN_DOWNGRADE. CLOSE releases open state. The first LOCK operation transitions from an open stateid to a lock stateid using the open_to_lock_owner4 structure.
The clientaddr4 r_addr field encodes IPv4 universal addresses as 'h1.h2.h3.h4.p1.p2' (dotted-decimal host plus two-octet port in ASCII-decimal) with r_netid 'tcp' or 'udp'. For IPv6, the format is 'x1:x2:x3:x4:x5:x6:x7:x8.p1.p2' with r_netid 'tcp6' or 'udp6'.
The nfs_fh4 filehandle is a variable-length opaque byte string with a maximum of NFS4_FHSIZE (128) bytes, defined as 'typedef opaque nfs_fh4<NFS4_FHSIZE>'. The stateid4 structure encodes as a uint32_t seqid plus a 12-byte opaque other field (total 16 bytes). Stateids of all-zeros or all-ones are reserved.
The nfstime4 structure encodes time as int64_t seconds since January 1, 1970 UTC plus uint32_t nanoseconds. nseconds values greater than 999,999,999 are invalid. For negative seconds (pre-epoch), the nseconds field is added to the seconds field for the final representation.
The verifier4 type is a fixed 8-byte opaque value (NFS4_VERIFIER_SIZE = 8), used in COMMIT, CREATE, OPEN, READDIR, SETCLIENTID, SETCLIENTID_CONFIRM, and WRITE. The nfs_client_id4 structure contains a verifier4 plus an opaque id field capped at NFS4_OPAQUE_LIMIT (1024) bytes.