Network File System (NFS) Version 4 Minor Version 1 Protocol
Extracted elements (31)
SECINFO and SECINFO_NO_NAME consume the current filehandle in NFSv4.1, a deliberate change from NFSv4.0. This resolves security enforcement ambiguity for operations following SECINFO within a COMPOUND: without a current filehandle, subsequent data operations return NFS4ERR_NOFILEHANDLE rather than silently applying the wrong security context.
Sessions and RECLAIM_COMPLETE were made REQUIRED in NFSv4.1, intentionally diverging from minor versioning guidelines that prohibit mandatory new features. Both are infrastructural changes that broadly simplify implementation; making them optional would add undue complexity to protocol definition and all dependent features.
Unlike NFSv4.0 (which recommended embedding the server's network address in the client owner string), NFSv4.1 recommends using the same co_ownerid string across all server addresses. This enables session trunking, where a single client ID is shared across multiple network paths to the same server.
NFSv4.1 is a separate protocol from NFSv4.0 with no dependencies on it; this document neither updates nor obsoletes RFC 3530. Both minor versions can be used simultaneously on the same network between the same client and server.
A server that determines a client holds no associated state (sessions, opens, locks, delegations, layouts, wants) MAY unilaterally release the client ID. If it does, it MUST ensure the client receives the appropriate error so it uses EXCHANGE_ID/CREATE_SESSION to establish a new client ID.
An NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle operation immediately followed by LOOKUP, OPEN by component name, LOOKUPP, SECINFO, or SECINFO_NO_NAME. The server MUST NOT return NFS4ERR_WRONGSEC from SECINFO or SECINFO_NO_NAME itself.
Minor versions must not add or delete RPC procedures, must not modify existing operation argument/result structures, must not delete operations or attributes. A client MUST NOT use a stateid, filehandle, or similar object from a COMPOUND with minor version X in a COMPOUND with minor version Y where X ≠ Y.
NFSv4.1 clients and servers MUST implement RPCSEC_GSS, though this is not a requirement to use it. Other flavors such as AUTH_NONE and AUTH_SYS MAY be implemented as well.
NFSv4.1 clients and servers MUST support RPCSEC_GSS integrity and authentication services. Servers MUST support RPCSEC_GSS's privacy service; clients SHOULD support it.
NFSv4.1 clients and servers MUST support the Kerberos V5 security mechanism via RPCSEC_GSS/GSS-API. A QOP of zero is used, deferring algorithm selection to the mechanism's configuration; implementors are expected to track evolution of Kerberos V5 algorithm requirements.
Regardless of GSS mechanism in use, the NFS server MUST identify itself via a GSS_C_NT_HOSTBASED_SERVICE name of the form 'nfs@hostname'; for Kerberos V5 the form 'nfs/hostname' is RECOMMENDED.
Security negotiation between client and server SHOULD be performed over a secure channel to prevent a third party from intercepting the negotiation and forcing a downgrade to a weaker security level.
The client SHOULD use DESTROY_CLIENTID to gracefully release a client ID it no longer needs. The server MUST NOT release a client ID while there are sessions, opens, locks, delegations, layouts, or wants associated with it.
To establish a client ID, the client MUST perform an EXCHANGE_ID operation followed by CREATE_SESSION using the returned eir_clientid. This sequence also immediately releases locking state from any previous incarnation of the same client.
When the security policies of the current and saved filehandles have no mutually acceptable security tuple, the server MUST NOT return NFS4ERR_WRONGSEC from LINK or RENAME; instead it MUST return NFS4ERR_XDEV or allow the current filehandle's security policy to override.
A stateid is a 128-bit quantity returned by the server that uniquely identifies open and locking state for a specific open-owner or lock-owner/open-owner pair for a specific file and lock type.
Parallel NFS (pNFS) separates metadata access from data access by introducing layouts — recallable objects that authorize clients to perform I/O directly to one or more data servers using a storage protocol that may or may not be NFSv4.1.
Sessions provide a per-request client context and robust reply protection for non-idempotent requests. Almost all NFSv4.1 server and callback requests are performed within a session; sessions are associated with a client ID at creation and all requests on a session renew the client's lease.
The client_owner4 structure identifies a client using a 64-bit incarnation verifier (co_verifier) and a unique opaque string (co_ownerid). The server cancels leased state if co_verifier changes for a known co_ownerid.
The COMPOUND procedure (and callback counterpart CB_COMPOUND) is the sole RPC procedure used for all NFSv4.1 operations; there are exactly two procedures, NULL and COMPOUND. Operations in a COMPOUND are evaluated in order without atomicity guarantees; evaluation stops on the first failing result.
The Secret State Verifier (SSV) is a unique secret key shared between client and server, used as the key for an internal GSS mechanism (SSV GSS mechanism) to compute MIC and Wrap tokens, enabling per-connection integrity protection of session traffic.
The server_owner4 structure identifies a server with an opaque major identifier (so_major_id) and a 64-bit minor identifier (so_minor_id). Matching so_major_id values indicate the same server; matching both values indicates sessions may be shared across connections, enabling trunking.
IANA registry for NFSv4.1 Named Attribute Definitions, recording names and meanings of named attributes associated with file or directory objects. This document creates the registry and defines procedures for adding entries.
IANA registry for pNFS Device ID Notification types used by the CB_NOTIFY_DEVICEID callback operation, defining the enumerated values that indicate how a data server device entry has changed.
IANA registry for pNFS Layout Types (layouttype4 enumeration), identifying the storage protocols usable for parallel data access. The file layout type LAYOUT4_NFSV4_1_FILES is defined in this document; additional types require IETF review.
IANA registry for pNFS Object Recall Types used by CB_RECALL_ANY, defining the enumerated values that indicate which class of recallable object (delegation, layout, etc.) a server is requesting the client to return.
pNFS significantly modifies the RPC-based security framework because data access may not traverse RPC. The security impact varies with the storage protocol; the NFSv4.1 file layout type can have zero additional security impact, but other layout types may require independent security mechanisms for data-path protection.
The strength of NFSv4.1 security depends on the underlying Kerberos V5 infrastructure. Because Kerberos V5 algorithms are not directly selectable by NFSv4.1 clients or servers, deployers bear due diligence responsibility for ensuring the Kerberos infrastructure meets their security requirements.
Client ID lifecycle: EXCHANGE_ID (returns eir_clientid) → CREATE_SESSION (client ID confirmed, session active) → steady state (all session requests renew the lease) → DESTROY_CLIENTID (graceful teardown) or NFS4ERR_STALE_CLIENTID/NFS4ERR_BADSESSION (server restart, triggers new EXCHANGE_ID + CREATE_SESSION).
The client_owner4 structure encodes a 64-bit verifier (co_verifier, type verifier4) followed by a variable-length opaque string (co_ownerid<NFS4_OPAQUE_LIMIT>) that uniquely identifies the client across incarnations.
The server_owner4 structure encodes a 64-bit unsigned integer minor identifier (so_minor_id, type uint64_t) followed by a variable-length opaque major identifier (so_major_id<NFS4_OPAQUE_LIMIT>).