Namespace Database (NSDB) Protocol for Federated File Systems
Extracted elements (30)
NsdbName is not stored as an attribute of FSN or FSL records because it is implicit from the NSDB node that a client is accessing and, when TLS is in effect, is authenticated by the TLS connection. Storing it redundantly would create inconsistency risks.
The third sub-protocol (for fileserver administration) uses ONC RPC rather than LDAP because all fileservers support ONC RPC but some do not support an LDAP directory server. This decision preserves interoperability across diverse fileserver implementations.
Version 1 UUIDs were deprecated in favor of version 4 because virtual machines do not depend on unique physical MAC addresses and administrators can modify physical MAC addresses. Since FSN/FSL UUIDs are readable by unauthenticated users, version 1 UUIDs would also expose MAC addresses and timestamps to attackers.
After fileset migration, administrators SHOULD keep redirecting junctions on the source fileserver in place for at least the value of FsnTTL seconds because referring fileservers may have cached stale FSL data during that window. File-access protocols that do not communicate cache expiry make the required duration indeterminate.
Deleting an FSN removes it only from the federation namespace; the fileset data is not deleted. Junctions targeting the deleted FSN become dangling references, detectable when a fileserver attempts to resolve them against the NSDB.
An NFS fileserver MUST NOT combine a set of FSL records into a single fs_location4 or fs_locations_item4 unless each FSL record in the set contains the same rootpath value and extended file system information.
An NFS URI MUST contain both an authority and a path component, and MUST NOT contain a query component or a fragment component. The authority MUST contain the host subcomponent, and the path MUST NOT be empty and MUST be expressed as an absolute path.
Fileservers MUST NOT use cached FSL records after the parent FSN's FsnTTL has expired. An FsnTTL value of zero indicates that fileservers MUST NOT cache the results of resolving that FSN.
For each naming context containing federation entries, there MUST be an LDAP entry (the NSDB Container Entry, NCE) that is superior to all federation entries, and the naming context's root entry MUST include fedfsNsdbContainerInfo as one of its object classes. The fedfsNceDN attribute MUST NOT be empty.
If an NSDB is replicated, it MUST exhibit loose, converging consistency as defined in RFC 3254. The mechanism for achieving this is outside the scope of this document; many LDAP implementations support replication features that MAY be used.
It MUST be possible for an unprivileged (unauthenticated) user to perform LDAP queries accessing NSDB data, since fileservers perform FSN resolution as an unauthenticated user. All implementations MUST use a schema that includes all named objects with all associated attributes.
The component names of an NFSv4 pathname MUST be prepared using the component name rules from RFC 7530 Section 12 prior to encoding into the NFS URI path component. Non-ASCII characters and URI-reserved characters (including '/') MUST be represented by URI percent encoding.
The Delete FSN operation MUST return an error if the FSN entry has child FSL entries, preventing orphaned FSL entries. This requirement is met by compliant LDAP implementations because RFC 4511 Section 4.8 defines the LDAP delete operation to only remove leaf entries.
The protocol used for communication between the admin entity and each NSDB node MUST be LDAPv3 (RFC 4510). Administrators SHOULD authenticate using the DN of a privileged LDAP user when performing write operations.
UUIDs SHOULD be generated using the procedure for version 4 UUIDs as specified in RFC 4122 to minimize collision probability. Version 1 UUIDs are no longer considered sufficient because MAC addresses are no longer reliably unique (e.g., virtual machines).
When generating a referral, the fileserver SHOULD include the maximum possible number of FSL records. However, the fileserver MAY omit some FSL records (e.g., due to protocol format limitations) and MAY convert or reduce FSL record contents to match the referral format, attempting to maintain original meaning where possible.
A Fileset Location (FSL) describes one physical location of a fileset's data and contains FslUuid, FsnUuid, and NsdbName. Additional type-specific attributes describe how to access the fileset; this document defines an NFS FSL subtype encoded as a fedfsNfsFsl LDAP entry.
A Fileset Name (FSN) uniquely identifies a fileset across a federation and consists of three components: NsdbName (the NSDB node's network location), FsnUuid (a UUID per RFC 4122), and FsnTTL (time-to-live in seconds for cached FSL records). The FsnUuid and NsdbName never change during the FSN's lifetime.
An NFS URI extends the NFS URL scheme (RFC 2224) to capture the location of an NFSv4 fileset. It encodes the rootpath as a URI path component and the server hostname as the authority component. NFSv4 pathnames are evaluated relative to the fileserver's pseudoroot, not a public filehandle.
The fedfsNfsFsl LDAP object class (OID 1.3.6.1.4.1.31103.1.1004) is a structural subclass of fedfsFsl and represents an NFS fileset location. Its REQUIRED attributes include fedfsNfsURI, fedfsNfsCurrency, fedfsNfsGenFlagWritable/Going/Split, fedfsNfsTransFlagRdma, six class fields, read/write rank/order fields, fedfsNfsVarSub, and fedfsNfsValidFor.
IANA created a registry for FedFS Object Identifiers (OIDs) under the arc 1.3.6.1.4.1.31103 (Section 7.2), covering LDAP attribute types (1.x) and object classes (1.1xxx). This registry governs the OIDs assigned to all LDAP schema elements defined in this document.
IANA created a registry for the fedfsAnnotation Key Namespace (Section 7.1), which governs the namespace of key strings used in fedfsAnnotation attributes. New key registrations allow higher-level protocols to extend fileset metadata in a standardized way.
IANA registered LDAP descriptors for all attribute types and object classes defined in this document (Section 7.3), including fedfsUuid, fedfsFsnUuid, fedfsFsnTTL, fedfsNceDN, fedfsFslUuid, fedfsAnnotation, fedfsDescr, fedfsNfsURI, and all fedfsNfs* attributes, plus the fedfsNsdbContainerInfo, fedfsFsn, fedfsFsl, and fedfsNfsFsl object classes.
The NSDB is designed to require authentication for write operations while allowing unauthenticated read access. TLS is referenced as the mechanism for authenticating NsdbName in NSDB connections, and administrators performing Section 5.1 operations SHOULD authenticate via a privileged LDAP DN.
Version 1 UUIDs embedded in FSN and FSL records expose the generating host's MAC address and a timestamp in cleartext. Since FSN/FSL records are readable by unauthenticated users, security-sensitive installations should be aware that externally facing NSDBs can reveal host identity information through UUIDs.
The DN of an FSN entry is REQUIRED to take the form 'fedfsFsnUuid=$FSNUUID,$NCE', and the DN of an FSL entry is REQUIRED to take the form 'fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE'. These structures enforce UUID uniqueness within the LDAP directory.
The fedfsAnnotation attribute (OID 1.3.6.1.4.1.31103.1.12) stores key/value pairs formatted per ABNF: ANNOTATION = KEY '=' VALUE, where KEY and VALUE are double-quoted UTF-8 strings. It is multi-valued; a malformed annotation SHOULD be ignored in its entirety but MUST NOT prevent processing of the containing entry.
The fedfsFsnTTL attribute (OID 1.3.6.1.4.1.31103.1.11) MUST be encoded as an Integer syntax value in the range [0, 4294967295]. It is single-valued and specifies the time-to-live in seconds of a cached FSN and its child FSL records.
The fedfsNfsURI attribute (OID 1.3.6.1.4.1.31103.1.120) is a single-valued subtype of labeledURI (RFC 2079) that stores the host and pathname components of an NFS FSL encoded as an NFS URI per Section 2.8.1.
The fedfsUuid attribute (OID 1.3.6.1.4.1.31103.1.1) is a single-valued LDAP attribute using UUID syntax (1.3.6.1.1.16.1, RFC 4530) with uuidMatch equality and uuidOrderingMatch ordering. It is the base type for all UUIDs used in the federated file system protocols.