NFS Version 4.0 Trunking Update
updates
- rfc-7530 — Network File System (NFS) Version 4 Protocol
Extracted elements (24)
A client that misidentifies an address switch as a migration event causes no significant harm: using the same server via a new address will appear as a successful transparent state migration. Deferring the migration determination until all known server addresses are confirmed unusable is therefore recommended but not absolute.
A set of network access paths with server-trunkable addresses and the same root-relative file system pathname is treated as a single replica with multiple network access paths in this document, differing from the older RFC 7530 and RFC 7931 approach where each replica was identified by a single network access path.
Because fs_locations provides no connection-type hints, clients supporting multiple connection types must probe serially (declining preference order) or simultaneously. Simultaneous probing avoids long waits from network partitions but requires discarding less-preferred connections once one succeeds.
Although a client may prematurely cease scanning for trunkable addresses when receiving a location attribute from an older server that does not follow the required ordering constraint (trunking entries before replica entries), the harm is expected to be limited since older servers would not present trunking path information.
If a single file system location entry designates multiple server IP addresses that correspond to different servers, this normally indicates misconfiguration. The client should avoid using such entries when alternatives are available; if unavoidable, it should pick one IP address and not use others not directed to the same server.
Any NFSv4.0 client that supports migration or trunking detection needs to present a uniform client ID string to all NFSv4.0 servers; failure to do so will make trunking detection impossible.
Fetching file system location information SHOULD be performed using RPCSEC_GSS with integrity protection. Without integrity protection, returned location data may be corrupted in transit, potentially directing the client to an unverified or hostile server.
On first access to a file system, the client should obtain the value of the set of alternative file system locations by interrogating the fs_locations attribute, then apply trunking discovery/detection to separate trunkable addresses from replica addresses.
Servers that provide information about trunkable network paths are REQUIRED to place file system location entries representing addresses usable with the current server or a migration target before those associated with replicas, enabling clients to cease scanning early.
The use of RPCSEC_GSS with integrity protection is RECOMMENDED in all cases when interrogating location information. When integrity protection cannot be used, returned location information should be subject to filtering to eliminate untrusted network addresses; if neither is possible, the client should ignore trunking and replica information.
Privacy considerations relating to uniform client strings (UCS) versus non-uniform client strings (non-UCS), discussed in RFC 7931 Section 5.6, are applicable to their usage for trunking detection in NFS version 4.0. UCS exposes a stable client identity across servers.
File system location elements are derived from location entries. When an entry specifies a hostname, the client resolves it to produce one location element per resulting network address. Each element consists of a file system location address and an fs_name indicating the file system's location within the server's pseudo-fs.
NFS version 4.0 may use stream connections (RPC per RFC 5531) or RDMA-capable connections (RPC-over-RDMA per RFC 8166). The fs_locations attribute provides no information to support connection type selection, so clients must use trial-and-error to determine which types are supported.
NFS4ERR_MOVED indicates only that a file system cannot be accessed via the current network address; it does not imply migration to a different server. Clients should not conclude migration has occurred until confirming that all network addresses known to be associated with the server are unusable.
The fs_locations attribute allows specification of file system locations where data corresponding to a given file system may be accessed, representing instances as a server address target together with a path within the single-server namespace. Individual entries can express trunkable addresses, replica locations, migration targets, or pure referrals.
Trunking detection refers to confirming that two independently acquired network addresses are connected to the same NFSv4 server instance. In NFSv4.0 this requires the client to support the uniform client ID string (UCS) approach described in RFC 7931 Section 5.6.
Trunking discovery is the process by which an NFSv4 client using one network address can obtain other candidate addresses trunkable with that server. Discovery sources include DNS resolution of server hostnames (which may return multiple addresses) and network addresses specified in fs_locations attribute entries.
Trunking is defined as a situation in which multiple distinct network addresses are connected to the same NFS server instance. Two such addresses are described as 'server-trunkable'. NFSv4.0 recognizes only a single type of trunking relationship between addresses, unlike later minor versions.
When a file system becomes absent, a client receives NFS4ERR_MOVED, then uses the fs_locations attribute to find the new location. The client must see the same data at the new location; any change visible on the original must already be reflected on all migration targets to prevent state reversion.
When server-trunkable addresses exist, the client may assume that for each file system in a given server network address's namespace, corresponding file systems exist at the same namespace locations for each other trunkable address, even without explicit listing in fs_locations.
An NFSv4 server SHOULD present file system location entries for file systems on other servers using only hostnames rather than bare IP addresses. This allows the client to interrogate fs_locations on the destination using RPCSEC_GSS with integrity, validating the hostname and ensuring the response has not been corrupted.
When DNS is used to resolve NFS server hostnames and DNSSEC is unavailable, the validity of returned network addresses cannot be relied upon. RPCSEC_GSS mutual authentication or transport-layer security (e.g., TLS 1.3) can detect invalid server addresses obtained via compromised DNS.
When RPCSEC_GSS is not available, returned file system location information is subject to corruption in transit. A client directed to another server after NFS4ERR_MOVED without integrity-protected location data cannot reliably authenticate the destination; it should not use such unverified entries as a basis for migration.
When the set of server network addresses changes: (1) if the new list is a superset, no client action is required; (2) if it is a subset and the removed address is not in use, no immediate action is needed but the address should be avoided; (3) if an address in use is removed, the client may continue using it until NFS4ERR_MOVED is received, which is not a migration event unless the last path becomes unusable.