Network File System (NFS) Version 4 Minor Version 1 Protocol
obsoletes
- rfc-5661 — Network File System (NFS) Version 4 Minor Version 1 Protocol
Extracted elements (27)
NFSv4.1 diverges from minor versioning guidelines 11 and 12 by making sessions and RECLAIM_COMPLETE REQUIRED rather than RECOMMENDED or OPTIONAL. These are infrastructural features with broad effects; allowing them to be optional would add undue complexity to protocol definition and implementation.
The co_ownerid string SHOULD be the same for every server network address the client accesses — the opposite of NFSv4.0 guidance — so that trunking over multiple network paths is possible. Including a dynamic IP address risks co_ownerid collisions after address reassignment.
To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a client_owner4 in EXCHANGE_ID with an nfs_client_id4 established via SETCLIENTID, allowing an upgraded client to avoid waiting for lease expiration. If the NFSv4.0 co_ownerid included the server address, the client should send two EXCHANGE_ID operations to avoid a trunking-hostile client ID.
A client MUST NOT attempt to use a stateid, filehandle, or similar object returned from a COMPOUND with minor version X for a COMPOUND with minor version Y where X != Y.
A client SHOULD use DESTROY_CLIENTID to destroy a client ID it no longer needs. As long as sessions, opens, locks, delegations, layouts, or wants remain, the server MUST NOT release the client ID.
A requester MUST NOT retry a request unless the connection was lost before the reply was received. A replier MUST NOT silently drop a request even if it is a retry; it SHOULD return an appropriate error or MAY disconnect.
An NFSv4.1 implementation MUST support operation over the TCP transport protocol. UDP by itself MUST NOT be used as an NFSv4.1 transport.
An NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle operation that is immediately followed by LOOKUP, OPEN by component name, LOOKUPP, SECINFO, or SECINFO_NO_NAME.
Minor versions MUST NOT modify the structure of existing operations' arguments or results, MUST NOT delete operations or attributes, and MUST NOT modify existing attribute structures. New operations must be added rather than modifying existing structures.
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. Other security 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. Servers MUST support RPCSEC_GSS privacy; clients SHOULD support it.
NFSv4.1 clients and servers MUST support the Kerberos V5 security mechanism via RPCSEC_GSS/GSS-API. Implementations MUST run on environments that comply with the REQUIRED cryptographic algorithms of each REQUIRED mechanism.
Security negotiation between client and server SHOULD be done with a secure channel to prevent a third party from intercepting the negotiation and forcing a lower level of security.
The NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name of the form 'nfs@hostname'. For Kerberos V5, the form 'nfs/hostname' is RECOMMENDED.
Where NFSv4.1 operates over IP, any transport used MUST be among the IETF-approved congestion control transport protocols. Even over non-IP networks, congestion control is RECOMMENDED.
A client is identified by a 64-bit client ID assigned by the server, established via EXCHANGE_ID followed by CREATE_SESSION. Establishing a new incarnation's client ID immediately releases all locking state (byte-range locks, share reservations, layouts, delegations) from any prior incarnation.
A lease is a server-defined time interval during which a client is irrevocably granted locks. Locks may be revoked if the lease is not renewed within the interval, and must be revoked if a conflicting lock was granted after the lease expired. A server grants each client a single lease covering all state.
NFSv4.1 defines five lock types: share reservations (OPEN), byte-range locks, file delegations, directory delegations, and layouts. All locks for a client are tied to a single client-wide lease renewed by any activity on any session associated with that client.
NFSv4.1 has exactly two RPC procedures: NULL and COMPOUND. The COMPOUND procedure encodes a series of individual operations evaluated in order without atomicity guarantees; a failing operation stops evaluation and all prior results are returned.
pNFS (parallel NFS) separates metadata access from data access, enabling data I/O to multiple storage servers in parallel. Access is governed by recallable objects called layouts, which integrate with the locking model and may use NFSv4.1 or other storage protocols.
SECINFO and SECINFO_NO_NAME operations allow the client to determine, on a per-filehandle basis, the security tuple (flavor, GSS-API mechanism OID, QOP, RPCSEC_GSS service) required for access. SECINFO_NO_NAME additionally supports upward traversal via SECINFO_STYLE4_PARENT.
The sessions model is the principal infrastructural addition in NFSv4.1. Sessions provide a client context for every request and supply robust replay protection for non-idempotent operations. All requests except session-creation operations are performed within a session.
IANA maintains NFSv4.1-specific registries for Named Attribute Definitions (Section 22.2), Device ID Notifications (Section 22.3), Object Recall Types (Section 22.4), Layout Types (Section 22.5), and Path Variable Definitions (Section 22.6).
The security strength of NFSv4.1 deployments depends on the underlying Kerberos V5 infrastructure. The cryptographic algorithms of Kerberos V5 are not directly selectable by client or server, requiring deployers to perform due diligence to ensure acceptable security for their environment.
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.
The client_owner4 structure has two fields: co_verifier (verifier4, a 64-bit incarnation verifier) and co_ownerid (opaque variable-length string up to NFS4_OPAQUE_LIMIT), used to identify and distinguish client incarnations.
The server_owner4 structure has so_minor_id (uint64_t) and so_major_id (opaque variable-length string). Equal so_major_id indicates the same server; equal so_major_id and so_minor_id additionally indicates that sessions may be shared across connections.