RFC 8587

NFS Version 4.0 Trunking Update

📅 published May 2019, from ietf

NFS Version 4.0 Trunking Update 🎀

RFC 8587 is a Standards Track doc from May 2019, so it's officially an Internet Standard 💅

  • Authors: C. Lever, Ed. (Oracle) and D. Noveck (NetApp) 💖
  • Category: Standards Track 🌈
  • ISSN: 2070-1721
  • Updates: RFC 7530 ✨

Abstract 🌸

okay so in NFS version 4.0, the fs_locations attribute tells clients about alternate locations of file systems 🗺️ A NFS version 4.0 client can use that info to handle migration and replication of server file systems. This doc describes how a NFS version 4.0 client can also use that same info to discover a NFS version 4.0 server's trunking capabilities 🦋 This document updates RFC 7530.

Status of This Memo 📋

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8587 🔗

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 💜

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Document Organization . . . . . . . . . . . . . . . . . . . .   6
5.  Changes within Section 8 of RFC 7530  . . . . . . . . . . . .   7
  5.1.  Updated Section "Location Attributes"
        (Currently Section 8.1) . . . . . . . . . . . . . . . . .   8
  5.2.  Updates to "Uses of Location Information"
        (Currently Section 8.4) . . . . . . . . . . . . . . . . .   9
    5.2.1.  Updates to the Introductory Text of the Current
            Section 8.4 . . . . . . . . . . . . . . . . . . . . .   9
    5.2.2.  New Subsection Titled "Trunking Discovery and
            Detection" (Becomes Section 8.4.1)  . . . . . . . . .  11
    5.2.3.  New Subsection Titled "Location Attributes and
            Selection of Connection Type" (Becomes Section 8.4.2)  12
    5.2.4.  Updated Section "File System Replication" (Becomes
            Section 8.4.3 Retitled "File System Replication and
            Trunking" . . . . . . . . . . . . . . . . . . . . . .  12
    5.2.5.  Updated Section "File System Migration" (Becomes
            Section 8.4.4)  . . . . . . . . . . . . . . . . . . .  13
    5.2.6.  New Subsection Titled "Interaction of Trunking,
            Migration, and Replication" (Becomes Section 8.4.5) .  14
  5.3.  Updated Section "Location Entries and Server Identity"
        (Section 8.5) . . . . . . . . . . . . . . . . . . . . . .  16
6.  Updates to RFC 7530 outside Section 8 . . . . . . . . . . . .  16
7.  Updates to the Security Considerations Section of RFC 7530  .  16
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
9.  Updates to the References Section in RFC 7530 . . . . . . . .  19
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
  10.2.  Informative References . . . . . . . . . . . . . . . . .  21
Appendix A.  Section Classification . . . . . . . . . . . . . . .  22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1. Introduction 🌸

The NFS version 4.0 specification [RFC7530] defines a migration feature that enables the transfer of a file system from one server to another without disruption of client activity. There were a number of issues with the original definition of this feature, now resolved with the publication of [RFC7931]. ✨

After a migration event, a client must determine whether state recovery is necessary. To do this, it needs to determine whether 1) the source and destination server addresses represent the same server instance, 2) if the client has already established a lease on the destination server for other file systems, and 3) if the destination server instance has lock state for the migrated file system. 🧐

As part of addressing this need, [RFC7931] introduces trunking into NFS version 4.0 along with a trunking detection mechanism. A trunking detection mechanism enables a client to determine whether two distinct network addresses are connected to the same NFS version 4.0 server instance. Without this knowledge, a client unaware of a trunking relationship between paths it is using simultaneously is likely to become confused in ways described in [RFC7530]. 😵‍💫

NFSv4.1 was defined with an integral means of trunking detection, which is described in [RFC5661]. NFSv4.0 initially did not have trunking detection; it was added by [RFC7931]. Nevertheless, the use of the concept of server-trunkability is the same in both protocol versions. 🤝

File system migration, replication, and referrals are distinct protocol features. However, it is not appropriate to treat each of these features in isolation. For example, recovery processing of client migration needs to deal with the possibility of multiple server addresses in a returned fs_locations attribute. In addition, the content of the fs_locations attribute, which provides both trunking-related and replication information, may change over repeated retrievals, requiring an integrated description of how clients are to deal with such changes. The issues discussed in the current document relate to the interpretation of the fs_locations attribute and to the proper client and server handling of changes in fs_locations attribute values. 🧩

Therefore, the goals of the current document are as follows:

  • To provide NFS version 4.0 with a means of finding addresses that are trunkable with a given address, i.e., trunking discovery, compatible with the means of trunking detection introduced by [RFC7931]. For an explanation of trunking detection and discovery, see Section 3. 🔍
  • To describe how NFS version 4.0 clients are to handle the presence of multiple network addresses associated with the same server when recovering from a replication and migration event. 🔁
  • To describe how NFS version 4.0 clients are to handle changes in the contents of returned fs_locations attributes, including those that indicate changes in the responding NFS version 4.0 server's trunking configuration. 🦋

The current document pursues these goals by presenting a set of updates to [RFC7530], as summarized in Sections 5 and 6. 💅

2. Requirements Language 💖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

These words only count as the official key words when they're written in ALL CAPS. Lowercase versions are just regular words 🙈

3. Terminology 🦋

Most of the terms related to handling the fs_locations attribute are appropriately defined in Section 5.1. However, there are a few terminological issues regarding the use of terms outside the context of text updating [RFC7530] that are explained in this section. Note that the definitions of trunking-related terms in Section 5.1 apply throughout this document, including in explanatory sections that will not replace any text in [RFC7530]. 📚

Regarding network addresses and the handling of trunking, we use the following terminology:

  • Each NFSv4 server is assumed to have a set of IP addresses to which NFSv4 requests may be sent by clients. These are referred to as the server's "network addresses". Access to a specific server network address might involve the use of multiple network ports, since the ports to be used for particular types of connections might be required to be different. 🌐
  • Clients may establish connections to NFSv4 servers via one of several connection types, supporting the NFSv4 protocol layered on top of an RPC stream transport, as described in [RFC5531], or on top of RPC-over-RDMA, as described in [RFC8166]. The combination of a server network address and a particular connection type is referred to as a "server endpoint". 🔌
  • Each network address, when combined with a pathname providing the location of a file system root directory relative to the associated server root filehandle, defines a file system network access path. 🛣️
  • Two network addresses connected to the same server are said to be server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 recognizes only a single type of trunking relationship between addresses. 👑

Discussion of the term "replica" is complicated for a number of reasons. Even though the term is used in explaining the issues in [RFC7530] that need to be addressed in the current document, a full explanation of this term requires explanation of related terms connected to the fs_locations attribute, which is provided in Section 5.1 of the current document. 🫠

The term is also used in previous documents about NFSv4.0 (i.e., [RFC7530] and [RFC7931]) with a meaning different from that in the current document. In these documents, each replica is identified by a single network access path. However, in the current document, a set of network access paths that have server-trunkable network addresses and the same root-relative file system pathname is considered to be a single replica with multiple network access paths. Although [RFC7931] enables an NFSv4.0 client to determine whether two network addresses are server-trunkable, it never describes the addresses as connected to a single replica, in effect leaving the approach established in [RFC7530]. 🤔

Note that this document, except when explaining problems in [RFC7530], always uses the new definition, including in text intended to replace existing sections of [RFC7530]. 💜

4. Document Organization 🗂️✨

Okay bestie, so this doc sorts its sections into four types based on how they connect to the eventual update of the NFS version 4.0 spec 💅. Once this update is published, NFS version 4.0 is going to be spread across multiple documents that you have to read together, until somebody writes a consolidated replacement spec. It's a whole group project 🫶

Here are the section types. See Appendix A for a classification of each section of the current document 🦋

  • An explanatory section doesn't contain any material meant to update the NFS version 4.0 spec. These sections can explain why and how changes are being made, but they don't include any text that updates [RFC7530] or shows up in an eventual consolidated document. Think of them as the tea, not the recipe 🍵
  • A replacement section contains text that replaces, and therefore supersedes, text within [RFC7530], and then shows up in an eventual consolidated document. The titles of replacement sections tell you which section of [RFC7530] they're replacing 🔁
  • An additional section contains text that doesn't replace anything in [RFC7530], but it will still be part of the NFS version 4.0 spec and is expected to be part of an eventual consolidated document. The titles give you a hint about where the new section would land once it's merged with [RFC7530] 🌱
  • An editing section contains some text that replaces text within [RFC7530], but the whole section isn't just replacement text. It has other stuff in it too. These sections make relatively minor tweaks to the NFS version 4.0 spec, and those tweaks are expected to be reflected in an eventual consolidated document. Usually the replacement text shows up as a quotation, sometimes as an indented set of paragraphs 💜

Heads up: additional and replacement sections sometimes refer to the "current document," which means RFC 8587. When those sections get pulled into a consolidated document, those references will need to be updated so they point to the right sections in that new doc 📌

5. Changes within Section 8 of RFC 7530 🌸

Most of the updates to [RFC7530] that add support for trunking using the fs_locations attribute apply to Section 8 ("Multi-Server Namespace") of that document. In the list below, the replacing section refers to its numbering in this document 🧚

  • Section 5.1 replaces Section 8.1 ("Location Attributes") of [RFC7530]. The text from the original section has been reorganized and extended so that fs_locations can explicitly provide trunking-related information that interacts properly with the migration, replication, and referral features of fs_locations. Terminology for those interactions is added too ✨
  • Section 5.2 updates Section 8.4 ("Uses of Location Information") of [RFC7530]. This section is where most of the updates live. Every paragraph of Section 8.4 and its subsections has been reviewed to clarify how trunking-related information is provided using the fs_locations attribute 🔍
    • Section 5.2.1 replaces the introductory material within Section 8.4 of [RFC7530], meaning the material within Section 8.4 excluding its subsections.
    • Section 5.2.2 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.1.
    • Section 5.2.3 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.2.
    • Section 5.2.4 replaces Section 8.4.1 ("File System Replication") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.3.
    • Section 5.2.5 replaces Section 8.4.2 ("File System Migration") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.4.
    • Section 5.2.6 is to be added as a new subsection of Section 8.4 before Section 8.4.3 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.5, while the existing Section 8.3 would appear as Section 8.4.6.
  • Section 5.3 replaces Section 8.5 ("Location Entries and Server Identity") of [RFC7530]. The last paragraph of the existing section has been removed 🗑️

5.1. Updated Section "Location Attributes" (Currently Section 8.1) 📍

The fs_locations attribute lets you specify file system locations where the data for a given file system can be accessed. It represents these file system instances as a server address target, which can be either a DNS hostname (representing one or more network addresses) or a single literal network address. That's paired with the path of the file system within the associated single-server namespace. Individual fs_locations entries can express trunkable addresses, locations of file system replicas on other servers, migration targets, or pure referrals 🦋

We introduce the following terminology, bestie 📝

  • "Trunking" is a situation in which multiple network addresses are connected to the same NFS server. Network addresses connected to the same NFS server instance are said to be "server-trunkable" 🧩
  • "Trunking detection" refers to ways of confirming that two distinct network addresses are connected to the same NFSv4 server instance 🕵️
  • Trunking discovery is a process by which a client using one network address can obtain other candidate addresses that are server-trunkable with it 🔎

Here's the terminology for GETATTR attributes used in trunking discovery and other multi-server namespace features 💜

  • Location attributes include only the fs_locations GETATTR attribute.
  • Location entries (fs_location4, defined in [RFC7530], Section 2.2.6) are the individual file system locations in the fs_locations attribute (defined in [RFC7530], Section 2.2.7). A file system location entry designates a set of network addresses that clients may use to establish connections. The entry can designate multiple addresses, because the server hostname may map to multiple network addresses and because multiple connection types may be used to talk to each specified network address. Those addresses give you multiple ways of connecting to a single server 🌈

Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to confirm that such addresses are connected to the same server. A client can ignore non-confirmed trunking relationships and treat the corresponding addresses as connected to different servers 🙈

  • File system location elements are derived from file system location entries. If a file system location entry specifies a network address, there is only a single corresponding location element. When a file system location entry contains a hostname, the client resolves the hostname, producing one file system location element for each of the resulting network addresses. Issues regarding the trustworthiness of hostname resolutions are further discussed in Section 7 of the current document 🔐
  • All file system location elements consist of a file system location address, which is the network address of an interface to a server, and an fs_name, which is the location of the file system within the server's pseudo-fs 🏠
  • If the server has no pseudo-fs and only has a single exported file system at the root filehandle, the fs_name may be empty 🫧

5.2. Updates to "Uses of Location Information" (Currently Section 8.4) 🎀

The subsections below provide replacement sections for existing sections within Section 8.4 of [RFC7530], or new subsections to be added to that section 💖

5.2.1. Updates to the Introductory Text of the Current Section 8.4 ✨

Along with the possibility of absent file systems, the fs_locations attribute carries file system locations and a bunch of important facilities that enable reliable, manageable, and scalable data access. It's giving infrastructure 🏗️

When a file system is present on the queried server, this attribute can provide a set of alternate locations that clients may use to access the file system when necessary. Providing these alternate file system locations is called "replication," and it's described further in Section 5.2.4 of the current document 🔁

When alternative file system locations are provided, they may represent distinct physical copies of the same file system data, or separate NFS server instances that give access to the same physical file system. Another possible use of multiple file system location entries is trunking, where the entries don't actually represent different servers, but rather distinct network paths to the same server 🛤️

A client can use file system location elements simultaneously to get higher-performance access to the target file system. This can be done using trunking, although using multiple replicas at the same time is also possible. To enable simultaneous access, the client uses trunking detection and/or discovery, which is further described in Section 5.2.2 of the current document, to figure out a set of network paths that are server-trunkable with the path currently being used to access the file system. Once that's determined, requests may be routed across multiple paths using the existing state management mechanism 🚀

Multiple replicas may also be used simultaneously, typically when accessing read-only datasets. In this case, each replica requires its own state management. The client performs multiple file opens to read the same file content from multiple replicas 📚

When a file system is present and then becomes absent, clients can be given the chance to keep accessing their data at an alternative file system location. Transferring the file system contents to the new file system location is called "migration." The client's responsibilities in dealing with this transition depend on the specific nature of the new access path, as well as how and whether data was actually migrated. See Sections 5.2.5 and 5.2.6 of the current document for details 🦋

The fs_locations attribute can designate one or more remote file system locations in place of an absent file system. This is known as a "referral." A particularly important case is a "pure referral," in which the absent file system has never been present on the NFS server. A referral like this is how a file system on one server can redirect clients to file systems on other servers, which is what makes a multi-server namespace possible 🌍

Because client support for the fs_locations attribute is OPTIONAL, a server may (but is not required to) take action to hide migration and referral events from such clients, for example by acting as a proxy 🫶

5.2.2. New Subsection Titled "Trunking Discovery and Detection" (Becomes Section 8.4.1) 🦋

Okay bestie, "trunking" is when multiple different network addresses all lead to the same NFS server instance 💖 For convenience, we say two addresses connected to the same server are server-trunkable. Section 5.4 of [RFC7931] explains why NFSv4 clients need to know the server's identity to manage lease and lock states properly when there are multiple connections to the same server. It's a whole thing 😭

"Trunking detection" is how an NFSv4 client can check that two addresses it found separately actually belong to the same NFSv4 server 🕵️‍♀️ Section 5.8 of [RFC7931] describes an OPTIONAL way to figure out whether two network addresses match the same NFSv4.0 server instance. Without trunking detection, an NFSv4.0 client has no other way to confirm that two addresses are server-trunkable. No backup plan, periodt 💅

For NFS version 4.0 specifically, trunking detection requires the client to support the uniform client ID string (UCS) approach, described in Section 5.6 of [RFC7931]. Any NFSv4.0 client that supports migration or trunking detection needs to present a uniform client ID string to all NFSv4.0 servers. If it doesn't, it won't be able to do trunking detection, and that's a vibe killer 💀

"Trunking discovery" is the process where an NFSv4 client starts with either a hostname or one of an NFSv4 server's network addresses, and then finds other candidate addresses that are trunkable with that server address. In other words, it gathers a set of addresses that might all be connected to the same NFSv4 server instance ✨ An NFSv4.0 client can discover server-trunkable addresses in a few ways:

  • An NFS server's hostname is provided either at mount time or in a returned file system location entry. A DNS query of this hostname can return more than one network address. Those returned addresses are candidates for trunking 🌐
  • Location entries returned in an fs_locations attribute can specify network addresses. Those addresses are candidates for trunking too 🧚

When there's a way to do trunking detection, an NFSv4.0 client can confirm that a set of network addresses belongs to the same NFSv4.0 server instance. That means any of them can be used to access that server. Iconic, honestly 👑

5.2.3. New Subsection Titled "Location Attributes and Selection of Connection Type" (Becomes Section 8.4.2) 🌸

NFS version 4.0 can be implemented using several different types of connections:

Stream connections may be used to provide RPC service, as described in [RFC5531].
RDMA-capable connections may be used to provide RPC service, as described in [RFC8166].

Since there are multiple connection types, clients have to figure out which one to use when they set up a connection to a server network address 🤔 The fs_locations attribute gives no info to help pick the connection type, so clients that support multiple types have to just try them out. Trial and error, bestie, no shortcuts 🙈 That's how the client works out which connection types the server supports.

If a client strongly prefers one connection type, it can try them one at a time, starting with the most preferred and going down the list. Once an attempt succeeds, the connection that was established can be used. Heads up though: with this approach, network partitions can lead to a long string of waits before a connection finally works 😩

To avoid waiting around when there's at least one viable network path, a client can attempt several connection types at the same time. Once a viable connection is established, the client throws out the less-preferred connections 🗑️ Efficient and iconic.

5.2.4. Updated Section "File System Replication" (Becomes Section 8.4.3 Retitled "File System Replication and Trunking" 🍓

On first access to a file system, the client should get the set of alternative file system locations by checking the fs_locations attribute 🔍 Then trunking discovery and/or detection can be applied to the file system location entries. This separates the candidate server-trunkable addresses from the replica addresses that offer alternative locations for the file system. Server-trunkable addresses can be used at the same time for higher performance, by taking advantage of multiple paths between the client and the target file system. Multitasking queen behavior 👸

If server failure, communication problems, or other difficulties make continued access to the current file system impossible or just impractical, the client can use the alternative file system locations to keep access going. See Section 5.2.6 of the current document for more detail 💜

5.2.5. Updated Section "File System Migration" (Becomes Section 8.4.4) 🚚

When a file system is present and then becomes absent, clients can be given the chance to keep accessing their data at an alternative file system location specified by the fs_locations attribute ✨ Usually, a client is accessing the file system, gets an NFS4ERR_MOVED error, and then uses the fs_locations attribute to find out where the data moved to. See Section 5.2.6 of the current document for more detail.

Migration can help with load balancing or general resource reallocation ⚖️ The protocol doesn't say how the file system gets moved between servers. A bunch of different server-to-server transfer mechanisms might be used, and the server implementer gets to choose. What the NFSv4 protocol does specify is how the migration event gets communicated between the client and the server.

When the client gets word of a migration event through an NFS4ERR_MOVED error, the data must already have been propagated to the destination server. Once the client goes to the alternate file system location, it must see the same data 🫶 For writable file systems, a change made on the original file system must be visible on all migration targets. If a file system isn't writable but is a read-only copy (maybe updated periodically) of a writable file system, similar requirements apply to propagating updates. Any change visible in the original file system must already be applied on all migration targets. That way, when a client moves over to a migration target, it won't see the file system state go backwards 😱

5.2.6. New Subsection Titled "Interaction of Trunking, Migration, and Replication" (Becomes Section 8.4.5) 🧩

When the set of network addresses on a server changes in a way that would affect a file system location attribute, clients who are currently accessing that file system could end up in a few different situations. NFS4ERR_MOVED is only returned when the server can't satisfy a client's request. That could be because the file system was migrated to a different server, or because it's only accessible at a different trunked address on the same server, or because of some other reason. In cases 1 and 2 below, NFS4ERR_MOVED is not returned.

  1. When the list of network addresses is a superset of what was previously in effect, there's no need for migration or any other kind of client adjustment. The client is still free to use an extra address in the new list if that address gives another path to the same server. Or, the client can treat that address like a replica, only used if the current server addresses become unavailable 🌈
  2. When the list of network addresses is a subset of what was previously in effect, no immediate action is needed if an address missing from the new list isn't currently being used by the client. The client should avoid using that address to access the file system in the future, whether the address is for a replica or an additional path to the server being used 🙅‍♀️
  3. When an address being removed is one of several paths to the current server, the client may keep using it until NFS4ERR_MOVED is received. This isn't considered a migration event unless the last available path to the server has become unusable 🛤️

When migration does happen, multiple addresses may be in use on the server before migration, and multiple addresses may be available on the destination server.

For the server currently in use, an NFS4ERR_MOVED return may mean that one particular network address shouldn't be used anymore, without meaning the file system needs to migrate to a different server. Clients shouldn't conclude that migration has happened until they've confirmed that all network addresses known to belong to that server are unusable 🔎

Now, the need to hold off on that determination isn't absolute. If a client doesn't know about all the network addresses for some reason, it might conclude that migration happened when it didn't, and treat a switch to a different server address like a migration event. That's harmless, because using the same server through a new address will just look like a successful instance of transparent state migration 🦋

Even though no real harm comes from this misunderstanding, it can cause some disconcerting situations. For example, if a lock was revoked during the address shift, it'll look to the client like the lock got lost during migration 😵 When a lock like that is lost, the destination server is responsible for recovering it through a file-system-specific grace period.

As for the destination server, it's a good idea for the client to know about all valid network addresses that can be used to reach it. There's no need to do that right away, though. Implementations can process the additional file system location elements in parallel with normal use of the first valid file system location entry found to access the destination 🏃‍♀️

A file system location attribute can include entries for the current server, the migration destination, and possible replicas. So scanning for available network addresses that might be trunkable with addresses the client has already seen could take a super long time 😩 To keep this as short as possible, servers that provide information about trunkable network paths are REQUIRED to put file system location entries for addresses usable with the current server or a migration target before the ones for replicas. This ordering is what lets a client stop scanning for trunkable file system location entries once it hits an entry whose fs_name differs from the current fs_name, or whose address isn't server-trunkable with the address it's currently using. ✂️

Okay, one caveat: a client might stop scanning too early if it gets a location attribute from an older server that doesn't follow that ordering rule. But the harm should be limited, since those older servers aren't expected to give information about trunkable server access paths anyway 💖

5.3. Updated Section "Location Entries and Server Identity" (Section 8.5) 🎀

okay so bestie, remember how a single file system location entry can have a server address target that's a DNS hostname resolving to multiple network addresses? 💅 And it's also possible for multiple file system location entries to have their own server address targets that point at the same server? That's the whole vibe here. 🦋

When server-trunkable addresses exist for a server, the client is allowed to assume that for each file system in the namespace of a given server network address, there are file systems at corresponding namespace locations for each of the other server-trunkable network addresses. ✨ It can do this even if fs_locations doesn't explicitly list them 👀 Those corresponding file system locations can be used as alternative locations, just like the ones explicitly specified via the fs_locations attribute. 💖

Now, if a single file system location entry designates multiple server IP addresses, the client SHOULD choose a single one to use. 🌸 When two server addresses are designated by one entry and they correspond to different servers, that normally signals some sort of misconfiguration 🙈 So the client SHOULD avoid using those entries when alternatives are available. 💀 And when they're not available, the client SHOULD pick one of the IP addresses and use it, without using the others that aren't directed to the same server. 🫶

6. Updates to RFC 7530 outside Section 8 🍓

Okay, so the existing description of NFS4ERR_MOVED in Section 13.1.2.4 of [RFC7530] doesn't take proper account of trunking 😭 That means it needs to be modified: the first two sentences of the description get replaced with the following material:

   The file system that contains the current filehandle object cannot
   be accessed using the current network address.  It may be
   accessible using other network addresses connected to the same
   server, it may have been relocated to another server, or it may
   never have been present.

7. Updates to the Security Considerations Section of RFC 7530 🔥

Serious moment, bestie. 🧚 The Security Considerations section of [RFC7530] needs the additions below to properly address some aspects of trunking discovery, referral, migration, and replication. It's giving high-stakes energy 💀

The possibility that requests to determine the set of network addresses corresponding to a given server might be interfered with, or have their responses corrupted, needs to be taken into account. 😱

o When DNS is used to convert NFS server hostnames to network addresses and DNSSEC [RFC4033] is not available, the validity of the network addresses returned cannot be relied upon. However, when the client uses RPCSEC_GSS [RFC7861] to access NFS servers, it is possible for mutual authentication to detect invalid server addresses. Other forms of transport layer security (e.g., [RFC8446]) can also offer strong authentication of NFS servers. 🦋

  • Fetching file system location information SHOULD be performed using RPCSEC_GSS with integrity protection, as previously explained in the Security Considerations section of [RFC7530]. 🔐 Making a request of this sort without strong integrity protection permits corruption during transit of returned file system location information. The client implementer needs to recognize that using such information to access an NFS server without RPCSEC_GSS (e.g., by using AUTH_SYS as defined in [RFC5531]) can result in the client interacting with an unverified network address that is posing as an NFSv4 server. 👻
  • Despite the fact that [RFC7530] REQUIRES "implementations" to provide "support" for the use of RPCSEC_GSS, it cannot be assumed that use of RPCSEC_GSS is always possible between any particular client-server pair. 🙃
  • Returning only network addresses to a client that has no trusted DNS resolution service can hamper its ability to use RPCSEC_GSS. 🥺

Therefore, an NFSv4 server SHOULD present file system location entries that correspond to file systems on other servers using only hostnames. ✨ This enables the client to interrogate the fs_locations on the destination server to obtain trunking information (as well as replica information) using RPCSEC_GSS with integrity, validating the hostname provided while ensuring that the response has not been corrupted. 🫶

When RPCSEC_GSS is not available on an NFS server, returned file system location information is subject to corruption during transit and cannot be relied upon. 😭 In the case of a client being directed to another server after NFS4ERR_MOVED, this could vitiate the authentication provided by the use of RPCSEC_GSS on the destination. Even when RPCSEC_GSS authentication is available on the destination, this server might validly represent itself as the server to which the client was erroneously directed. Without a way to decide whether the server is a valid one, the client can only determine, using RPCSEC_GSS, that the server corresponds to the hostname provided, with no basis for trusting that server. The client SHOULD NOT use such unverified file system location entries as a basis for migration, even though RPCSEC_GSS might be available on the destination server. 🚫

When a file system location attribute is fetched upon connecting with an NFSv4 server, it SHOULD, as stated above, be done using RPCSEC_GSS with integrity protection. 💜

When file system location information cannot be protected in transit, the client can subject it to additional filtering to prevent the client from being inappropriately directed. 🧐 For example, if a range of network addresses can be determined that ensures the servers and clients using AUTH_SYS are subject to appropriate constraints (such as physical network isolation and the use of administrative controls within the operating systems), then network addresses in this range can be used, with others discarded or restricted in their use of AUTH_SYS. 🌈

When neither integrity protection nor filtering is possible, it is best for the client to ignore trunking and replica information or simply not fetch the file system location information for these purposes. 🙈

To summarize considerations regarding the use of RPCSEC_GSS in fetching file system location information, consider the following recommendations for requests to interrogate location information, with interrogation approaches on the referring and destination servers arrived at separately: 📝

  • The use of RPCSEC_GSS with integrity protection is RECOMMENDED in all cases, since the absence of integrity protection exposes the client to the possibility of the results being modified in transit. 👑
  • The use of requests issued without RPCSEC_GSS (e.g., using AUTH_SYS), while undesirable, might be unavoidable in some cases. Where the use of returned file system location information cannot be avoided, it should be subject to filtering to eliminate untrusted network addresses. The specifics will vary depending on the degree of network isolation and whether the request is to the referring or destination servers. 🦋

Privacy considerations relating to uniform client strings (UCS) versus non-uniform client strings (non-UCS), discussed in Section 5.6 of [RFC7931], are also applicable to their usage for trunking detection in NFS version 4.0. 🔒

8. IANA Considerations 🌸

This document has no IANA actions. ✨

9. Updates to the References Section in RFC 7530 📚

The following references should be added to the Normative References section of [RFC7530]:

[RFC7931]  Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
           "NFSv4.0 Migration: Specification Update", RFC 7931,
           DOI 10.17487/RFC7931, July 2016,
           <https://www.rfc-editor.org/info/rfc7931>.

[RFC8166]  Lever, C., Ed., Simpson, W., and T. Talpey, "Remote
           Direct Memory Access Transport for Remote Procedure
           Call Version 1", RFC 8166, DOI 10.17487/RFC8166,
           June 2017, <https://www.rfc-editor.org/info/rfc8166>.

The following references should be added to the Informative References section of [RFC7530]:

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D.,
           and S. Rose, "DNS Security Introduction and
           Requirements", RFC 4033, DOI 10.17487/RFC4033,
           March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC7861]  Adamson, A. and N. Williams, "Remote Procedure Call
           (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
           November 2016, <https://www.rfc-editor.org/info/rfc7861>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

10. References 🎀

10.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
           Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
           May 2009, <https://www.rfc-editor.org/info/rfc5531>.

[RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File System
           (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
           March 2015, <https://www.rfc-editor.org/info/rfc7530>.

[RFC7931]  Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
           "NFSv4.0 Migration: Specification Update", RFC 7931,
           DOI 10.17487/RFC7931, July 2016,
           <https://www.rfc-editor.org/info/rfc7931>.

[RFC8166]  Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
           Memory Access Transport for Remote Procedure Call Version
           1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
           <https://www.rfc-editor.org/info/rfc8166>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References 🦋

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, DOI 10.17487/RFC4033, March 2005,
           <https://www.rfc-editor.org/info/rfc4033>.

[RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
           "Network File System (NFS) Version 4 Minor Version 1
           Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
           <https://www.rfc-editor.org/info/rfc5661>.

[RFC7861]  Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
           Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
           November 2016, <https://www.rfc-editor.org/info/rfc7861>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

# Appendix A. Section Classification ✨

okay so this bit is the sorting hat for the whole doc 🎀 all the sections are considered **explanatory** unless they're on this list:

- Sections 5.1, 5.2.4, 5.2.5, and 5.3 are **replacement sections** 🔁
- Sections 5.2.2, 5.2.3, and 5.2.6 are **additional sections** ➕
- Sections 5.2.1, 6, 7, and Section 9 are **editing sections** ✏️

the replacement ones swap out old text, the additional ones add new stuff, and the editing ones are where the changes get made. everything else is just explaining things 💅

---

# Acknowledgments

bestie, the authors gave a shoutout to **Andy Adamson**, who wrote the original version of this doc 🫶 all the innovation in here is basically his work, and if there are any mistakes, those are on the current authors 🙈

the editor thanked **Greg Marsden** for supporting this work and **Robert Thurlow** for reviewing it and dropping suggestions 💜

then there's the special thanks squad 👑 **Transport Area Director Spencer Dawkins**, **NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski**, and **NFSV4 Working Group Secretary Thomas Haynes** for their ongoing support 🌈 and the authors are also grateful to **Benjamin Kaduk** and **Ben Campbell** for doing a super thorough review of the document ✨

---

# Authors' Addresses

Charles Lever (editor) 🖊️
Oracle Corporation
United States of America

Email: `chuck.lever@oracle.com`

David Noveck 🦋
NetApp
United States of America

Email: `davenoveck@gmail.com`
📦 where this page comes from