draft-ietf-nfsv4-mv0-trunking-update-05.txt   rfc8587.txt 
Network File System Version 4 C. Lever, Ed. Internet Engineering Task Force (IETF) C. Lever, Ed.
Internet-Draft Oracle Request for Comments: 8587 Oracle
Updates: 7530 (if approved) D. Noveck Updates: 7530 D. Noveck
Intended status: Standards Track NetApp Category: Standards Track NetApp
Expires: August 5, 2019 February 1, 2019 ISSN: 2070-1721 May 2019
NFS version 4.0 Trunking Update NFS Version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-05
Abstract Abstract
The file system location-related attribute in NFS version 4.0, In NFS version 4.0, the fs_locations attribute informs clients about
fs_locations, informs clients about alternate locations of file alternate locations of file systems. An NFS version 4.0 client can
systems. An NFS version 4.0 client can use this information to use this information to handle migration and replication of server
handle migration and replication of server filesystems. This file systems. This document describes how an NFS version 4.0 client
document describes how an NFS version 4.0 client can additionally use can also use this information to discover an NFS version 4.0 server's
this information to discover an NFS version 4.0 server's trunking trunking capabilities. This document updates RFC 7530.
capabilities. This document updates RFC 7530.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 5, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8587.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Document Organization . . . . . . . . . . . . . . . . . . . . 6 4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 7 5. Changes within Section 8 of RFC 7530 . . . . . . . . . . . . 7
5.1. Updated Section 8.1 of [RFC7530], entitled 5.1. Updated Section "Location Attributes"
"Location Attributes" . . . . . . . . . . . . . . . . . . 8 (Currently Section 8.1) . . . . . . . . . . . . . . . . . 8
5.2. Updates to Section 8.4 of [RFC7530], entitled 5.2. Updates to "Uses of Location Information"
"Uses of Location Information" . . . . . . . . . . . . . 9 (Currently Section 8.4) . . . . . . . . . . . . . . . . . 9
5.2.1. Updated Introduction to Section 8.4 of [RFC7530], 5.2.1. Updates to the Introductory Text of the Current
entitled "Uses of Location Information" . . . . . . . 9 Section 8.4 . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. New Sub-section of Section 8.4 of [RFC7530], 5.2.2. New Subsection Titled "Trunking Discovery and
to be entitled "Trunking Discovery and Detection" . . 10 Detection" (Becomes Section 8.4.1) . . . . . . . . . 11
5.2.3. New Sub-section of Section 8.4 of [RFC7530], 5.2.3. New Subsection Titled "Location Attributes and
to be entitled "Location Attributes and Connection Selection of Connection Type" (Becomes Section 8.4.2) 12
Type Selection" . . . . . . . . . . . . . . . . . . . 11 5.2.4. Updated Section "File System Replication" (Becomes
5.2.4. Updated Section 8.4.1 of [RFC7530], entitled Section 8.4.3 Retitled "File System Replication and
"File System Replication and Trunking" . . . . . . . 12 Trunking" . . . . . . . . . . . . . . . . . . . . . . 12
5.2.5. Updated Section 8.4.2 of [RFC7530], entitled 5.2.5. Updated Section "File System Migration" (Becomes
"File System Migration" . . . . . . . . . . . . . . . 12 Section 8.4.4) . . . . . . . . . . . . . . . . . . . 13
5.2.6. New Sub-section of Section 8.4 of [RFC7530], 5.2.6. New Subsection Titled "Interaction of Trunking,
to be entitled "Interaction of Trunking, Migration, Migration, and Replication" (Becomes Section 8.4.5) . 14
and Replication" . . . . . . . . . . . . . . . . . . 13 5.3. Updated Section "Location Entries and Server Identity"
5.3. Updated Section 8.5 of [RFC7530], entitled (Section 8.5) . . . . . . . . . . . . . . . . . . . . . . 16
"Location Entries and Server Identity Update" . . . . . . 15 6. Updates to RFC 7530 outside Section 8 . . . . . . . . . . . . 16
6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 15 7. Updates to the Security Considerations Section of RFC 7530 . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Updates to the References Section in RFC 7530 . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Section Classification . . . . . . . . . . . . . . . 19 Appendix A. Section Classification . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The NFS version 4.0 specification [RFC7530] defines a migration The NFS version 4.0 specification [RFC7530] defines a migration
feature that enables the transfer of a file system from one server to feature that enables the transfer of a file system from one server to
another without disruption of client activity. There were a number another without disruption of client activity. There were a number
of issues with the original definition of this feature, now resolved of issues with the original definition of this feature, now resolved
with the publication of [RFC7931]. with the publication of [RFC7931].
After a migration event, a client must determine whether state After a migration event, a client must determine whether state
recovery is necessary. To do this, it needs to determine whether the recovery is necessary. To do this, it needs to determine whether 1)
source and destination server addresses represent the same server the source and destination server addresses represent the same server
instance, if the client has already established a lease on the instance, 2) if the client has already established a lease on the
destination server for other file systems, and if the destination destination server for other file systems, and 3) if the destination
server instance has lock state for the migrated file system. server instance has lock state for the migrated file system.
As part of addressing this need, [RFC7931] introduces trunking into As part of addressing this need, [RFC7931] introduces trunking into
NFS version 4.0 along with a trunking detection mechanism. A NFS version 4.0 along with a trunking detection mechanism. A
trunking detection mechanism enables a client to determine whether trunking detection mechanism enables a client to determine whether
two distinct network addresses are connected to the same NFS version two distinct network addresses are connected to the same NFS version
4.0 server instance. Without this knowledge, a client unaware of a 4.0 server instance. Without this knowledge, a client unaware of a
trunking relationship between paths it is using simultaneously is trunking relationship between paths it is using simultaneously is
likely to become confused in ways described in [RFC7530]. likely to become confused in ways described in [RFC7530].
NFSv4.1 was defined with an integral means of trunking detection, NFSv4.1 was defined with an integral means of trunking detection,
described in [RFC5661]. NFSv4.0 initially did not have one, with it which is described in [RFC5661]. NFSv4.0 initially did not have
being added by [RFC7931]. Nevertheless, the use of the concept of trunking detection; it was added by [RFC7931]. Nevertheless, the use
server-trunkability is the same in both protocol versions. of the concept of server-trunkability is the same in both protocol
versions.
File system migration, replication, and referrals are distinct File system migration, replication, and referrals are distinct
protocol features. However, it is not appropriate to treat each of protocol features. However, it is not appropriate to treat each of
these features in isolation. For example, client migration recovery these features in isolation. For example, recovery processing of
processing needs to deal with the possibility of multiple server client migration needs to deal with the possibility of multiple
addresses in a returned fs_locations attribute. In addition, the server addresses in a returned fs_locations attribute. In addition,
contents of the fs_locations attribute, which provides both trunking- the content of the fs_locations attribute, which provides both
related and replication information, may change over repeated trunking-related and replication information, may change over
retrievals, requiring an integrated description of how clients are to repeated retrievals, requiring an integrated description of how
deal with such changes. The issues discussed in the current document clients are to deal with such changes. The issues discussed in the
relate to the interpretation of the fs_locations attribute and to the current document relate to the interpretation of the fs_locations
proper client and server handling of changes in fs_locations attribute and to the proper client and server handling of changes in
attribute values. fs_locations attribute values.
Therefore the goals of the current document are: Therefore, the goals of the current document are as follows:
o To provide NFS version 4.0 with a means of finding addresses o To provide NFS version 4.0 with a means of finding addresses that
trunkable with a given address; i.e., trunking discovery, are trunkable with a given address, i.e., trunking discovery,
compatible with the means of trunking detection introduced by compatible with the means of trunking detection introduced by
[RFC7931]. For an explanation of trunking detection and [RFC7931]. For an explanation of trunking detection and
discovery, see Section 3. discovery, see Section 3.
o To describe how NFS version 4.0 clients are to handle the presence o To describe how NFS version 4.0 clients are to handle the presence
of multiple network addresses associated to the same server, when of multiple network addresses associated with the same server when
recovering from a replication and migration event. recovering from a replication and migration event.
o To describe how NFS version 4.0 clients are to handle changes in o To describe how NFS version 4.0 clients are to handle changes in
the contents of returned fs_locations attributes, including those the contents of returned fs_locations attributes, including those
that indicate changes in the responding NFS version 4.0 server's that indicate changes in the responding NFS version 4.0 server's
trunking configuration. trunking configuration.
The current document pursues these goals by presenting a set of The current document pursues these goals by presenting a set of
updates to [RFC7530] as summarized in Sections 5 and 6 below. updates to [RFC7530], as summarized in Sections 5 and 6.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
Most of the terms related to handling the fs_locations attribute are Most of the terms related to handling the fs_locations attribute are
appropriately defined in Section 5.1 below. However, there are a few appropriately defined in Section 5.1. However, there are a few
terms used outside that context that are explained in this section. 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].
Trunking refers to a situation in which a client uses multiple Regarding network addresses and the handling of trunking, we use the
network addresses communicate with the same server. Trunking was following terminology:
first introduced to NFSv4.0 by [RFC7931]. Regarding network
addresses and the handling of trunking we use the following
terminology:
o Each NFSv4 server is assumed to have a set of IP addresses to o Each NFSv4 server is assumed to have a set of IP addresses to
which NFSv4 requests may be sent by clients. These are referred which NFSv4 requests may be sent by clients. These are referred
to as the server's network addresses. Access to a specific server to as the server's "network addresses". Access to a specific
network address might involve the use of multiple network ports, server network address might involve the use of multiple network
since the ports to be used for particular types of connections ports, since the ports to be used for particular types of
might be required to be different. connections might be required to be different.
o Clients may establish connections to NFSv4 servers via one of o Clients may establish connections to NFSv4 servers via one of
several connection types, supporting the NFSv4 protocol layered on several connection types, supporting the NFSv4 protocol layered on
top of an RPC stream transport, as described in [RFC5531], or on top of an RPC stream transport, as described in [RFC5531], or on
top of RPC-over-RDMA, as described in [RFC8166]. The combination top of RPC-over-RDMA, as described in [RFC8166]. The combination
of a server network address and a particular connection type is of a server network address and a particular connection type is
referred to as a "server endpoint". referred to as a "server endpoint".
o Each network address, when combined with a pathname providing the o Each network address, when combined with a pathname providing the
location of a file system root directory relative to the location of a file system root directory relative to the
associated server root file handle, defines a file system network associated server root filehandle, defines a file system network
access path. access path.
o Two network addresses connected to the same server are said to be o Two network addresses connected to the same server are said to be
server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0
recognizes only a single type of trunking relationship between recognizes only a single type of trunking relationship between
addresses. addresses.
Particularly important is the distinction between trunking detection
and trunking discovery. The definitions we present are applicable to
all minor versions of NFSv4, but we put particular emphasis on how
these terms apply to NFS version 4.0.
o Trunking detection refers to ways of confirming that two unique
network addresses are associated with the same NFSv4 server
instance. The means available to make this determination depends
on the protocol version and, in some cases, on the client
implementation.
In the case of NFS version 4.0, the means to be used are described
in [RFC7931] and require use of the Uniform Client String approach
to be effective. This is in contrast to later minor versions for
which the means of trunking detection are described by [RFC5661].
o Trunking discovery is a process by which an NFSv4 client,
accessing one server network address, can obtain other addresses
that might be associated with the same server instance. Typically
a client builds on a trunking detection facility by providing one
or more methods by which candidate addresses are made available to
the client, who then uses trunking detection to appropriately
filter them.
Trunking discovery is not discussed in [RFC7530] and no
description of it is provided in [RFC7931].
Discussion of the term "replica" is complicated for a number of Discussion of the term "replica" is complicated for a number of
reasons. Even though the term is used in explaining the issues in reasons. Even though the term is used in explaining the issues in
[RFC7530] that need to be addressed in the current document, a full [RFC7530] that need to be addressed in the current document, a full
explanation of this term requires explanation of related terms explanation of this term requires explanation of related terms
connected to the fs_locations attribute, which is provided in connected to the fs_locations attribute, which is provided in
Section 5.1 of the current document. Section 5.1 of the current document.
The term is also used in previous documents about NFSv4.0 (i.e., The term is also used in previous documents about NFSv4.0 (i.e.,
[RFC7530] and [RFC7931]) with a meaning different from that in the [RFC7530] and [RFC7931]) with a meaning different from that in the
current document. In these documents each replica is identified by a current document. In these documents, each replica is identified by
single network access path. However, in the current document a set a single network access path. However, in the current document, a
of network access paths which have server-trunkable network addresses set of network access paths that have server-trunkable network
and the same root-relative file system pathname are considered to be addresses and the same root-relative file system pathname is
a single replica with multiple network access paths. Although considered to be a single replica with multiple network access paths.
[RFC7931] enables an NFSv4.0 client to determine whether two network Although [RFC7931] enables an NFSv4.0 client to determine whether two
addresses were server-trunkable, it never described these as network addresses are server-trunkable, it never describes the
connected to a single replica, leaving in effect the approach addresses as connected to a single replica, in effect leaving the
established in [RFC7530]. 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 4. Document Organization
The sections of the current document are divided into four types The sections of the current document are divided into four types
based on how they relate to the eventual updating of the NFS verion based on how they relate to the eventual updating of the NFS version
4.0 specification. Once this update is published, NFS version 4.0 4.0 specification. Once this update is published, NFS version 4.0
will be specified by multiple documents that need to be read will be specified by multiple documents that need to be read together
together, until such time as a consolidated replacement specification until such time as a consolidated replacement specification is
is produced. produced.
o The base specification [RFC7530]. o The base specification [RFC7530]
o The migration-related update [RFC7931]. o The migration-related update [RFC7931]
o This document [RFC-TBD]. o This document [RFC8587]
The section types are as follows. See Appendix A for a The section types are as follows. See Appendix A for a
classification of each section of the current document. classification of each section of the current document.
o An explanatory section does not contain any material that is meant o An explanatory section does not contain any material that is meant
to update the specification of NFS version 4.0. Such sections may to update the specification of NFS version 4.0. Such sections may
contain explanation about why and how changes are to be done, but contain an explanation about why and how changes are to be made,
do not include any text that is to update [RFC7530] or appear in but they do not include any text that is to update [RFC7530] or
an eventual consolidated document. appear in an eventual consolidated document.
o A replacement section contains text that is to replace and thus o A replacement section contains text that is to replace and thus
supersede text within [RFC7530] and then appear in an eventual supersede text within [RFC7530] and then appear in an eventual
consolidated document. The titles of replacement sections consolidated document. The titles of the replacement sections
indicate what section of [RFC7530] is to be replaced. indicate what section of [RFC7530] is to be replaced.
o An additional section contains text which, although not replacing o An additional section contains text that, although not replacing
anything in [RFC7530], will be part of the specification of NFS anything in [RFC7530], will be part of the specification of NFS
version 4.0 and will be expected to be part of an eventual version 4.0 and will be expected to be part of an eventual
consolidated document. The titles of additional sections provide consolidated document. The titles of the additional sections
an indication of where in an updated [RFC7530], the new section provide an indication of where the new section would appear when
would appear. consolidated with [RFC7530].
o An editing section contains some text that replaces text within o An editing section contains some text that replaces text within
[RFC7530], although the entire section will not consist of such [RFC7530], although the entire section will not consist of such
text and will include other text as well. Such sections make text and will include other text as well. Such sections make
relatively minor adjustments in the existing NFS version 4.0 relatively minor adjustments in the existing NFS version 4.0
specification which are expected to be reflected in an eventual specification, which are expected to be reflected in an eventual
consolidated document. Generally such replacement text appears as consolidated document. Generally, such replacement text appears
a quotation, possibly taking the form of an indented set of as a quotation, possibly taking the form of an indented set of
paragraphs. paragraphs.
5. Changes Within Section 8 of [RFC7530] Additional and replacement sections sometimes contain references to
the "current document" by which RFC 8587 is meant. When those
sections are incorporated in a consolidated document, those
references will need to be updated to refer to the appropriate
sections in that new document.
Most of the updates to [RFC7530] to provide support for trunking 5. Changes within Section 8 of RFC 7530
using the fs_locations attribute apply to Section 8 of that document,
entitled "Multi-Server Namespace".
o Section 5.1 replaces Section 8.1 of [RFC7530], entitled "Location Most of the updates to [RFC7530] that provide support for trunking
Attributes". This section has been reorganized and extended to using the fs_locations attribute apply to Section 8 ("Multi-Server
explicitly allow the use of fs_locations to provide trunking- Namespace") of that document. In the following list, the replacing
related information that appropriately interacts with the section refers to its numbering in this document.
migration, replication and referral features of fs_locations.
Terminology used to describe the interactions is added.
o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of o Section 5.1 replaces Section 8.1 ("Location Attributes") of
Location Information". This section comprises the bulk of the [RFC7530]. The text in the original section has been reorganized
updates. Each paragraph of Section 8.4 and its sub-sections has and extended to explicitly allow the use of fs_locations to
been reviewed to clarify the provision of trunking-related provide trunking-related information that appropriately interacts
information using the fs_locations attribute. with the migration, replication, and referral features of
fs_locations. Terminology used to describe the interactions is
added.
o Section 5.2 updates Section 8.4 ("Uses of Location Information")
of [RFC7530]. This section comprises the bulk of the updates.
Each paragraph of Section 8.4 and its subsections have been
reviewed to clarify the provision of trunking-related information
using the fs_locations attribute.
* Section 5.2.1 replaces the introductory material within * Section 5.2.1 replaces the introductory material within
Section 8.4 of [RFC7530]; i.e., the material within Section 8.4 Section 8.4 of [RFC7530], i.e., the material within Section 8.4
exclusive of subsections. exclusive of subsections.
* Section 5.2.2 is to be added as a new sub-section of * Section 5.2.2 is to be added as a new subsection of Section 8.4
Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In before the updated Section 8.4.1 of [RFC7530]. In a
a consolidated document, it would appear as Section 8.4.1. consolidated document, it would appear as Section 8.4.1.
* Section 5.2.3 is to be added as a new sub-section of * Section 5.2.3 is to be added as a new subsection of Section 8.4
Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In before the updated Section 8.4.1 of [RFC7530]. In a
a consolidated document, it would appear as Section 8.4.2. consolidated document, it would appear as Section 8.4.2.
* Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled * Section 5.2.4 replaces Section 8.4.1 ("File System
"File System Replication". In a consolidated document, it Replication") of [RFC7530]. In a consolidated document, it
would appear as Section 8.4.3. would appear as Section 8.4.3.
* Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled * Section 5.2.5 replaces Section 8.4.2 ("File System Migration")
"File System Migration". In a consolidated document, it would of [RFC7530]. In a consolidated document, it would appear as
appear as Section 8.4.4. Section 8.4.4.
* Section 5.2.6 is to be added as a new sub-section of * Section 5.2.6 is to be added as a new subsection of Section 8.4
Section 8.4 before Section 8.4.3 of [RFC7530]. In a before Section 8.4.3 of [RFC7530]. In a consolidated document,
consolidated document, it would appear as Section 8.4.5, while it would appear as Section 8.4.5, while the existing
the existing Section 8.3 would appear as Section 8.4.6. Section 8.3 would appear as Section 8.4.6.
o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location o Section 5.3 replaces Section 8.5 ("Location Entries and Server
Entries and Server Identity". The last paragraph of the existing Identity") of [RFC7530]. The last paragraph of the existing
section has been removed. section has been removed.
5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes" 5.1. Updated Section "Location Attributes" (Currently Section 8.1)
The fs_locations attribute allows specification of file system The fs_locations attribute allows specification of file system
locations where the data corresponding to a given file system may be locations where the data corresponding to a given file system may be
accessed. This attribute represents such file system instances as a accessed. This attribute represents such file system instances as a
server address target (as either a DNS host name representing one or server address target (as either a DNS hostname representing one or
more network addresses, or a single literal network address) together more network addresses or as a single literal network address)
with the path of that file system within the associated single-server together with the path of that file system within the associated
namespace. Individual fs_locations entries can express trunkable single-server namespace. Individual fs_locations entries can express
addresses, locations of file system replicas on other servers, trunkable addresses, locations of file system replicas on other
migration targets, or pure referrals. servers, migration targets, or pure referrals.
We introduce the following terminology: We introduce the following terminology:
o Trunking is a situation in which multiple network addresses are o "Trunking" is a situation in which multiple network addresses are
connected to the same NFS server. Network addresses connected to connected to the same NFS server. Network addresses connected to
the same NFS server instance are said to be server-trunkable. the same NFS server instance are said to be "server-trunkable".
o Trunking detection refers to ways of confirming that two distinct o "Trunking detection" refers to ways of confirming that two
network addresses are connected to the same NFSv4 server instance. distinct network addresses are connected to the same NFSv4 server
instance.
o Trunking discovery is a process by which a client using one o Trunking discovery is a process by which a client using one
network address can obtain other candidate addresses that are network address can obtain other candidate addresses that are
server-trunkable with it. server-trunkable with it.
Regarding terminology relating to GETATTR attributes used in trunking Regarding terminology relating to GETATTR attributes used in trunking
discovery and other multi-server namespace features: discovery and other multi-server namespace features:
o Location attributes include only the fs_locations GETATTR o Location attributes include only the fs_locations GETATTR
attribute. attribute.
o Location entries (fs_location4, defined in [RFC7530] o Location entries (fs_location4, defined in [RFC7530],
Section 2.2.6) are the individual file system locations in the Section 2.2.6) are the individual file system locations in the
fs_locations attribute (defined in [RFC7530] Section 2.2.7). A fs_locations attribute (defined in [RFC7530], Section 2.2.7). A
file system location entry designates a set of network addresses file system location entry designates a set of network addresses
to which clients may establish connections. The entry may to which clients may establish connections. The entry may
designate multiple such addresses because the server host name may designate multiple such addresses because the server hostname may
map to multiple network addresses, and because multiple connection map to multiple network addresses and because multiple connection
types may be used to communicate with each specified network types may be used to communicate with each specified network
address. Such addresses provide multiple ways of connecting to a address. Such addresses provide multiple ways of connecting to a
single server. single server.
Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to
confirm that such addresses are connected to the same server. The confirm that such addresses are connected to the same server. The
client can ignore non-confirmed trunking relationships and treat client can ignore non-confirmed trunking relationships and treat
the corresponding addresses as connected to different servers. the corresponding addresses as connected to different servers.
o File system location elements are derived from file system o File system location elements are derived from file system
location entries. If a file system location entry specifies a location entries. If a file system location entry specifies a
network address, there is only a single corresponding location network address, there is only a single corresponding location
element. When a file system location entry contains a host name, element. When a file system location entry contains a hostname,
the client resolves the hostname, producing one file system the client resolves the hostname, producing one file system
location element for each of the resulting network addresses. location element for each of the resulting network addresses.
Issues regarding the trustworthiness of hostname resolutions are Issues regarding the trustworthiness of hostname resolutions are
further discussed in Section 7 of the current document. further discussed in Section 7 of the current document.
o All file system location elements consist of a file system o All file system location elements consist of a file system
location address, which is the network address of an interface to 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 a server, and an fs_name, which is the location of the file system
within the server's pseudo-fs. within the server's pseudo-fs.
o If the server has no pseudo-fs and only a single exported file o 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. system at the root filehandle, the fs_name may be empty.
5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location 5.2. Updates to "Uses of Location Information" (Currently Section 8.4)
Information"
The subsections below provide replacement sections for existing The subsections below provide replacement sections for existing
sections within Section 8.4 of [RFC7530] or new sub-sections to be sections within Section 8.4 of [RFC7530] or new subsections to be
added to that section. added to that section.
5.2.1. Updated Introduction to Section 8.4 of [RFC7530], entitled "Uses 5.2.1. Updates to the Introductory Text of the Current Section 8.4
of Location Information"
Together with the possibility of absent file systems, the file system Together with the possibility of absent file systems, the
location-bearing attribute fs_locations provides a number of fs_locations attribute bears file system locations and a number of
important facilities that enable reliable, manageable, and scalable important facilities that enable reliable, manageable, and scalable
data access. data access.
When a file system is present on the queried server, this attribute When a file system is present on the queried server, this attribute
can provide a set of locations that clients may use to access the can provide a set of alternate locations that clients may use to
file system. In the event that server failure, communications access the file system, when necessary. Provision of such alternate
problems, or other difficulties make continued access to the file file system locations is referred to as "replication" and is further
system impossible or otherwise impractical, the returned information described in Section 5.2.4 of the current document.
provides alternate locations that enable continued access to the file
system. Provision of such alternative file system locations is
referred to as "replication".
When alternative file system locations are provided, they may When alternative file system locations are provided, they may
represent distinct physical copies of the same file system data or represent distinct physical copies of the same file system data or
separate NFS server instances that provide access to the same separate NFS server instances that provide access to the same
physical file system. Another possible use of the provision of physical file system. Another possible use of the provision of
multiple file system location entries is trunking, wherein the file multiple file system location entries is trunking, wherein the file
system location entries do not in fact represent different servers system location entries do not, in fact, represent different servers
but rather are distinct network paths to the same server. but rather are distinct network paths to the same server.
A client may use file system location elements simultaneously to A client may use file system location elements simultaneously to
provide higher-performance access to the target file system. This provide higher-performance access to the target file system. This
can be done using trunking, although the use of multiple replicas can be done using trunking, although the use of multiple replicas
simultaneously is possible. To enable simultaneous access, the simultaneously is possible. To enable simultaneous access, the
client utilizes trunking detection and/or discovery, further client utilizes trunking detection and/or discovery, further
described in Section 5.2.2 of the current document, to determine a described in Section 5.2.2 of the current document, to determine a
set of network paths that are server-trunkable with the one currently set of network paths that are server-trunkable with the path
being used to access the file system. Once this determination is currently being used to access the file system. Once this
made, requests may be routed across multiple paths, using the determination is made, requests may be routed across multiple paths
existing state management mechanism. using the existing state management mechanism.
Multiple replicas may also be used simultaneously, typically used Multiple replicas may also be used simultaneously, typically when
when accessing read-only datasets. In this case, each replica accessing read-only datasets. In this case, each replica requires
requires its own state management. The client performs multiple file its own state management. The client performs multiple file opens to
opens to read the same file content from multiple replicas. read the same file content from multiple replicas.
When a file system is present and subsequently becomes absent, When a file system is present and subsequently becomes absent,
clients can be given the opportunity to have continued access to clients can be given the opportunity to have continued access to
their data at an alternative file system location. Transfer of the their data at an alternative file system location. Transfer of the
file system contents to the new file system location is referred to file system contents to the new file system location is referred to
as "migration". The client's responsibilities in dealing with this as "migration". The client's responsibilities in dealing with this
transition depend on the specific nature of the new access path as transition depend on the specific nature of the new access path as
well as how and whether data was in fact migrated. See Sections well as how and whether data was, in fact, migrated. See Sections
5.2.5 and 5.2.6 of the current document for details. 5.2.5 and 5.2.6 of the current document for details.
The fs_locations attribute can designate one or more remote file The fs_locations attribute can designate one or more remote file
system locations in place of an absent file system. This is known as system locations in place of an absent file system. This is known as
a "referral". A particularly important case is that of a "pure a "referral". A particularly important case is that of a "pure
referral", in which the absent file system has never been present on referral", in which the absent file system has never been present on
the NFS server. Such a referral is a means by which a file system the NFS server. Such a referral is a means by which a file system
located on one server can redirect clients to file systems located on located on one server can redirect clients to file systems located on
other servers, thus enabling the creation of a multi-server other servers, thus enabling the creation of a multi-server
namespace. namespace.
Because client support for the fs_locations attribute is OPTIONAL, a Because client support for the fs_locations attribute is OPTIONAL, a
server may (but is not required to) take action to hide migration and server may (but is not required to) take action to hide migration and
referral events from such clients by acting as a proxy, for example. referral events from such clients by acting as a proxy, for example.
5.2.2. New Sub-section of Section 8.4 of [RFC7530], to be entitled 5.2.2. New Subsection Titled "Trunking Discovery and Detection"
"Trunking Discovery and Detection" (Becomes Section 8.4.1)
Trunking is a situation in which multiple distinct network addresses "Trunking" is a situation in which multiple distinct network
are associated with the same NFS server instance. As a matter of addresses are associated with the same NFS server instance. As a
convenience, we say that two network addresses connected to the same matter of convenience, we say that two network addresses connected to
NFS server instance are server-trunkable. Section 5.4 of [RFC7931] the same NFS server instance are server-trunkable. Section 5.4 of
explains why NFSv4 clients need to be aware of NFS server identity to [RFC7931] explains why NFSv4 clients need to be aware of the NFS
manage lease and lock state effectively when multiple connections to server identity to manage lease and lock states effectively when
the same server exist. multiple connections to the same server exist.
Trunking detection refers to a way for an NFSv4 client to confirm "Trunking detection" refers to a way for an NFSv4 client to confirm
that two independently acquired network addresses are connected to that two independently acquired network addresses are connected to
the same NFSv4 server. Section 5.8 of [RFC7931] describes an the same NFSv4 server. Section 5.8 of [RFC7931] describes an
OPTIONAL means by which it can be determined if two network addresses OPTIONAL means by which it can be determined whether two network
correspond to the same NFSv4.0 server instance. Without trunking addresses correspond to the same NFSv4.0 server instance. Without
detection, an NFSv4.0 client has no other way to confirm that two trunking detection, an NFSv4.0 client has no other way to confirm
network addresses are server-trunkable. that two network addresses are server-trunkable.
In the particular context of NFS version 4.0, trunking detection In the particular context of NFS version 4.0, trunking detection
requires that the client support the Uniform Client ID String requires that the client support the uniform client ID string (UCS)
approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0 approach, described in Section 5.6 of [RFC7931]. Any NFSv4.0 client
client that supports migration or trunking detection needs to present that supports migration or trunking detection needs to present a
a Uniform Client ID String to all NFSv4.0 servers. If it does not do uniform client ID string to all NFSv4.0 servers. If it does not do
so, it will be unable to perform trunking detection. so, it will be unable to perform trunking detection.
Trunking discovery is the process by which an NFSv4 client using a "Trunking discovery" is the process by which an NFSv4 client, using a
host name or one of an NFSv4 server's network addresses can obtain hostname or one of an NFSv4 server's network addresses, can obtain
other candidate network addresses that are trunkable with it; i.e., a other candidate network addresses that are trunkable with the NFSv4
set of addresses that might be connected to the same NFSv4 server server's network address, i.e., a set of addresses that might be
instance. An NFSv4.0 client can discover server-trunkable network connected to the same NFSv4 server instance. An NFSv4.0 client can
addresses in a number of ways: discover server-trunkable network addresses in a number of ways:
o An NFS server's host name is provided either at mount time or in a o An NFS server's hostname is provided either at mount time or in a
returned file system location entry. A DNS query of this host returned file system location entry. A DNS query of this hostname
name can return more than one network address. The returned can return more than one network address. The returned network
network addresses are candidates for trunking. addresses are candidates for trunking.
o Location entries returned in an fs_locations attribute can specify o Location entries returned in an fs_locations attribute can specify
network addresses. These network addresses are candidates for network addresses. These network addresses are candidates for
trunking. trunking.
When there is a means of trunking detection available, an NFSv4.0 When there is a means of trunking detection available, an NFSv4.0
client can confirm that a set of network addresses correspond to the client can confirm that a set of network addresses corresponds to the
same NFSv4.0 server instance and thus any of them can be used to same NFSv4.0 server instance; thus, any of them can be used to access
access that server. that server.
5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled 5.2.3. New Subsection Titled "Location Attributes and Selection of
"Location Attributes and Connection Type Selection" Connection Type" (Becomes Section 8.4.2)
NFS version 4.0 may be implemented using a number of different types NFS version 4.0 may be implemented using a number of different types
of connections: of connections:
Stream connections may be used to provide RPC service, as Stream connections may be used to provide RPC service, as
described in [RFC5531]. described in [RFC5531].
RDMA-capable connections may be used to provide RPC service, as RDMA-capable connections may be used to provide RPC service, as
described in [RFC8166]. described in [RFC8166].
Because of the need to support multiple connection types, clients Because of the need to support multiple connection types, clients
face the issue of determining the proper connection type to use when face the issue of determining the proper connection type to use when
establishing a connection to a server network address. The establishing a connection to a server network address. The
fs_locations attribute provides no information to support connection fs_locations attribute provides no information to support selection
type selection. As a result, clients supporting multiple connection of the connection type. As a result, clients supporting multiple
types need to attempt to establish a connection on various connection connection types need to attempt to establish a connection on various
types allowing it to determine, via a trial-and-error approach, which connection types, allowing it to determine, via a trial-and-error
connection types are supported. approach, which connection types are supported.
If a client strongly prefers one connection type, it can perform If a client strongly prefers one connection type, it can perform
these attempts serially in order of declining preference. Once there these attempts serially in order of declining preference. Once there
is a successful attempt, the established connection can be used. is a successful attempt, the established connection can be used.
Note that with this approach, network partitions can result in a Note that with this approach, network partitions can result in a
sequence of long waits for a successful connection. sequence of long waits for a successful connection.
To avoid waiting when there is at least one viable network path To avoid waiting when there is at least one viable network path
available, simultaneous attempts to establish multiple connection available, simultaneous attempts to establish multiple connection
types are possible. Once a viable connection is established, the types are possible. Once a viable connection is established, the
client discards less-preferred connections. client discards less-preferred connections.
5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System 5.2.4. Updated Section "File System Replication" (Becomes Section 8.4.3
Replication and Trunking" Retitled "File System Replication and Trunking"
On first access to a file system, the client should obtain the value On first access to a file system, the client should obtain the value
of the set of alternative file system locations by interrogating the of the set of alternative file system locations by interrogating the
fs_locations attribute. Trunking discovery and/or detection can then fs_locations attribute. Trunking discovery and/or detection can then
be applied to the file system location entries to separate the be applied to the file system location entries to separate the
candidate server-trunkable addresses from the replica addresses that candidate server-trunkable addresses from the replica addresses that
provide alternative locations of the file system. Server-trunkable provide alternative locations of the file system. Server-trunkable
addresses may be used simultaneously to provide higher performance addresses may be used simultaneously to provide higher performance
through the exploitation of multiple paths between client and target through the exploitation of multiple paths between the client and
file system. target file system.
In the event that server failures, communications problems, or other In the event that server failure, communication problems, or other
difficulties make continued access to the current file system difficulties make continued access to the current file system
impossible or otherwise impractical, the client can use the impossible or otherwise impractical, the client can use the
alternative file system locations as a way to maintain continued alternative file system locations as a way to maintain continued
access to the file system. See Section 5.2.6 of the current document access to the file system. See Section 5.2.6 of the current document
for more detail. for more detail.
5.2.5. Updated Section 8.4.2 of [RFC7530], entitled "File System 5.2.5. Updated Section "File System Migration" (Becomes Section 8.4.4)
Migration"
When a file system is present and becomes absent, clients can be When a file system is present and becomes absent, clients can be
given the opportunity to have continued access to their data at an given the opportunity to have continued access to their data at an
alternative file system location specified by the fs_locations alternative file system location specified by the fs_locations
attribute. Typically, a client will be accessing the file system in attribute. Typically, a client will be accessing the file system in
question, get an NFS4ERR_MOVED error, and then use the fs_locations question, get an NFS4ERR_MOVED error, and then use the fs_locations
attribute to determine the new location of the data. See attribute to determine the new location of the data. See
Section 5.2.6 of the current document for more detail. Section 5.2.6 of the current document for more detail.
Such migration can help provide load balancing or general resource Such migration can help provide load balancing or general resource
reallocation. The protocol does not specify how the file system will reallocation. The protocol does not specify how the file system will
be moved between servers. It is anticipated that a number of be moved between servers. It is anticipated that a number of
different server-to-server transfer mechanisms might be used, with different server-to-server transfer mechanisms might be used, with
the choice left to the server implementer. The NFSv4 protocol the choice left to the server implementer. The NFSv4 protocol
specifies the method used to communicate the migration event between specifies the method used to communicate the migration event between
client and server. the client and server.
When the client receives indication of a migration event via an When the client receives indication of a migration event via an
NFS4ERR_MOVED error, data propagation to the destination server must NFS4ERR_MOVED error, data propagation to the destination server must
have already occurred. Once the client proceeds to access the have already occurred. Once the client proceeds to access the
alternate file system location, it must see the same data. Where alternate file system location, it must see the same data. Where
file systems are writable, a change made on the original file system file systems are writable, a change made on the original file system
must be visible on all migration targets. Where a file system is not must be visible on all migration targets. Where a file system is not
writable but represents a read-only copy (possibly periodically writable but represents a read-only copy (possibly periodically
updated) of a writable file system, similar requirements apply to the updated) of a writable file system, similar requirements apply to the
propagation of updates. Any change visible in the original file propagation of updates. Any change visible in the original file
system must already be effected on all migration targets, to avoid system must already be effected on all migration targets to avoid any
any possibility that a client, in effecting a transition to the possibility that a client, in effecting a transition to the migration
migration target, will see any reversion in file system state. target, will see any reversion in the file system state.
5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled 5.2.6. New Subsection Titled "Interaction of Trunking, Migration, and
"Interaction of Trunking, Migration, and Replication" Replication" (Becomes Section 8.4.5)
When the set of network addresses on a server change in a way that When the set of network addresses on a server changes in a way that
would affect a file system location attribute, there are several would affect a file system location attribute, there are several
possible outcomes for clients currently accessing that file system. possible outcomes for clients currently accessing that file system.
NFS4ERR_MOVED is returned only when the server cannot satisfy a NFS4ERR_MOVED is returned only when the server cannot satisfy a
request from the client, whether because the file system has been request from the client, whether because the file system has been
migrated to a different server, is only accessible at a different migrated to a different server or is only accessible at a different
trunked address on the same server, or some other reason. In the trunked address on the same server, or for some other reason. In
cases 1 and 2 below, NFS4ERR_MOVED is not returned. cases 1 and 2 below, NFS4ERR_MOVED is not returned.
1. When the list of network addresses is a superset of that 1. When the list of network addresses is a superset of that
previously in effect, there is no need for migration or any other previously in effect, there is no need for migration or any other
sort of client adjustment. Nevertheless, the client is free to sort of client adjustment. Nevertheless, the client is free to
use an additional address in the replacement list if that address use an additional address in the replacement list if that address
provides another path to the same server. Or, the client may provides another path to the same server. Alternatively, the
treat that address as it does a replica, to be used if current client may treat that address as it does a replica -- to be used
server addresses become unavailable. if the current server addresses become unavailable.
2. When the list of network addresses is a subset of that previously 2. When the list of network addresses is a subset of that previously
in effect, immediate action is not needed if an address missing in effect, immediate action is not needed if an address missing
in the replacement list is not currently in use by the client. in the replacement list is not currently in use by the client.
The client should avoid using that address to access that file The client should avoid using that address to access that file
system in the future, whether the address is for a replica or an system in the future, whether the address is for a replica or an
additional path to the server being used. additional path to the server being used.
3. When an address being removed is one of a number of paths to the 3. When an address being removed is one of a number of paths to the
current server, the client may continue to use it until current server, the client may continue to use it until
NFS4ERR_MOVED is received. This is not considered a migration NFS4ERR_MOVED is received. This is not considered a migration
event unless the last available path to the server has become event unless the last available path to the server has become
unusable. unusable.
When migration does occur, multiple addresses may be in use on the When migration does occur, multiple addresses may be in use on the
server previous to migration and multiple addresses may be available server prior to migration, and multiple addresses may be available
for use on the destination server. for use on the destination server.
With regard to the server in use, it may be that return of With regard to the server in use, a return of NFS4ERR_MOVED may
NFS4ERR_MOVED indicates that a particular network address is no indicate that a particular network address is no longer to be used,
longer to be used, without implying that migration of the file system without implying that migration of the file system to a different
to a different server is needed. Clients should not conclude that server is needed. Clients should not conclude that migration has
migration has occurred until confirming that all network addresses occurred until confirming that all network addresses known to be
known to be associated with that server are not usable. associated with that server are not usable.
It should be noted that the need to defer this determination is not It should be noted that the need to defer this determination is not
absolute. If a client is not aware of all network addresses for any absolute. If a client is not aware of all network addresses for any
reason, it may conclude that migration has occurred when it has not reason, it may conclude that migration has occurred when it has not
and treat a switch to a different server address as if it were a and treat a switch to a different server address as if it were a
migration event. This is harmless since the use of the same server migration event. This is harmless since the use of the same server
via a new address will appear as a successful instance of Transparent via a new address will appear as a successful instance of transparent
State Migration. state migration.
Although significant harm cannot arise from this misapprehension, it Although significant harm cannot arise from this misapprehension, it
can give rise to disconcerting situations. For example, if a lock can give rise to disconcerting situations. For example, if a lock
has been revoked during the address shift, it will appear to the has been revoked during the address shift, it will appear to the
client as if the lock has been lost during migration. When such a client as if the lock has been lost during migration. When such a
lock is lost, it is the responsibility of the destination server to lock is lost, it is the responsibility of the destination server to
provide for its recovery via the use of an fs-specific grace period. provide for its recovery via the use of an fs-specific grace period.
With regard to the destination server, it is desirable for the client With regard to the destination server, it is desirable for the client
to be aware of all valid network addresses that can be used to access to be aware of all valid network addresses that can be used to access
skipping to change at page 15, line 10 skipping to change at page 15, line 39
replicas to use, scanning for available network addresses that might replicas to use, scanning for available network addresses that might
be trunkable with addresses the client has already seen could be trunkable with addresses the client has already seen could
potentially be a long process. To keep this process as short as potentially be a long process. To keep this process as short as
possible, servers that provide information about trunkable network possible, servers that provide information about trunkable network
paths are REQUIRED to place file system location entries that paths are REQUIRED to place file system location entries that
represent addresses usable with the current server or a migration represent addresses usable with the current server or a migration
target before those associated with replicas. target before those associated with replicas.
This ordering allows a client to cease scanning for trunkable file This ordering allows a client to cease scanning for trunkable file
system location entries once it encounters a file system location system location entries once it encounters a file system location
element whose fs_name differs from the current fs_name, or whose element whose fs_name differs from the current fs_name or whose
address is not server-trunkable with the one it is currently using. address is not server-trunkable with the address it is currently
Although the possibility exists that a client might prematurely cease using. Although the possibility exists that a client might
scanning for trunkable addresses when receiving a location attribute prematurely cease scanning for trunkable addresses when receiving a
from an older server that does not follow the ordering constraint location attribute from an older server that does not follow the
above, the harm is expected to be limited since such servers would ordering constraint above, the harm is expected to be limited since
not be expected to present information about trunkable server access such servers would not be expected to present information about
paths. trunkable server access paths.
5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and 5.3. Updated Section "Location Entries and Server Identity"
Server Identity Update" (Section 8.5)
As mentioned above, a single file system location entry may have a As mentioned above, a single file system location entry may have a
server address target in the form of a DNS host name that resolves to server address target in the form of a DNS hostname that resolves to
multiple network addresses; it is also possible for multiple file multiple network addresses; it is also possible for multiple file
system location entries to have their own server address targets that system location entries to have their own server address targets that
reference the same server. reference the same server.
When server-trunkable addresses for a server exist, the client may When server-trunkable addresses for a server exist, the client may
assume that for each file system in the namespace of a given server assume that for each file system in the namespace of a given server
network address, there exist file systems at corresponding namespace network address, file systems at corresponding namespace locations
locations for each of the other server-trunkable network addresses. exist for each of the other server-trunkable network addresses. It
It may do this even in the absence of explicit listing in may do this even in the absence of explicit listing in fs_locations.
fs_locations. Such corresponding file system locations can be used Such corresponding file system locations can be used as alternative
as alternative locations, just as those explicitly specified via the locations, just as those explicitly specified via the fs_locations
fs_locations attribute. attribute.
If a single file system location entry designates multiple server IP If a single file system location entry designates multiple server IP
addresses, the client should choose a single one to use. When two addresses, the client should choose a single one to use. When two
server addresses are designated by a single file system location server addresses are designated by a single file system location
entry and they correspond to different servers, this normally entry and they correspond to different servers, this normally
indicates some sort of misconfiguration. The client should avoid indicates some sort of misconfiguration. The client should avoid
using such file system location entries when alternatives are using such file system location entries when alternatives are
available. When they are not, the client should pick one of the IP available. When they are not, the client should pick one of the IP
addresses and use it, without using others that are not directed to addresses and use it without using others that are not directed to
the same server. the same server.
6. Updates to [RFC7530] Outside Section Eight 6. Updates to RFC 7530 outside Section 8
Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4
of [RFC7530] does not take proper account of trunking, it needs to be of [RFC7530] does not take proper account of trunking, it needs to be
modified by replacing the first two sentences of the description with modified by replacing the first two sentences of the description with
the following material: the following material:
The file system that contains the current filehandle object cannot The file system that contains the current filehandle object cannot
be accessed using the current network address. It may be be accessed using the current network address. It may be
accessible using other network addresses connected to the same accessible using other network addresses connected to the same
server, it may have been relocated to another server, or it may server, it may have been relocated to another server, or it may
never have been present. never have been present.
7. Security Considerations 7. Updates to the Security Considerations Section of RFC 7530
The Security Considerations section of [RFC7530] needs the additions The Security Considerations section of [RFC7530] needs the additions
below to properly address some aspects of trunking discovery, below to properly address some aspects of trunking discovery,
referral, migration, and replication. referral, migration, and replication.
The possibility that requests to determine the set of network The possibility that requests to determine the set of network
addresses corresponding to a given server might be interfered with addresses corresponding to a given server might be interfered with
or have their responses corrupted needs to be taken into account. or have their responses corrupted needs to be taken into account.
o When DNS is used to convert NFS server host names to network o When DNS is used to convert NFS server hostnames to network
addresses and DNSSEC [RFC4033] is not available, the validity addresses and DNSSEC [RFC4033] is not available, the validity
of the network addresses returned cannot be relied upon. of the network addresses returned cannot be relied upon.
However, when the client uses RPCSEC_GSS [RFC7861] to access However, when the client uses RPCSEC_GSS [RFC7861] to access
NFS servers, it is possible for mutual authentication to detect NFS servers, it is possible for mutual authentication to detect
invalid server addresses. Other forms of transport layer invalid server addresses. Other forms of transport layer
security (e.g., [RFC8446]) can also offer strong authentication security (e.g., [RFC8446]) can also offer strong authentication
of NFS servers. of NFS servers.
o Fetching file system location information SHOULD be performed o Fetching file system location information SHOULD be performed
using RPCSEC_GSS with integrity protection, as previously using RPCSEC_GSS with integrity protection, as previously
explained in the Security Considerations section of [RFC7530]. explained in the Security Considerations section of [RFC7530].
Making a request of this sort without using strong integrity Making a request of this sort without using strong integrity
protection permits corruption during transit of returned file protection permits corruption during the transit of returned
system location information. The client implementer needs to file system location information. The client implementer needs
recognize that using such information to access an NFS server to recognize that using such information to access an NFS
without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined server without use of RPCSEC_GSS (e.g., by using AUTH_SYS as
in [RFC5531]) can result in the client interacting with an defined in [RFC5531]) can result in the client interacting with
unverified network address that is posing as an NFSv4 server. an unverified network address that is posing as an NFSv4
server.
o Despite the fact that it is a REQUIREMENT of [RFC7530] that o Despite the fact that [RFC7530] REQUIRES "implementations" to
"implementations" provide "support" for the use of RPCSEC_GSS, provide "support" for the use of RPCSEC_GSS, it cannot be
it cannot be assumed that use of RPCSEC_GSS is always possible assumed that use of RPCSEC_GSS is always possible between any
between any particular client-server pair. particular client-server pair.
o Returning only network addresses to a client that has no o Returning only network addresses to a client that has no
trusted DNS resolution service can hamper its ability to use trusted DNS resolution service can hamper its ability to use
RPCSEC_GSS. RPCSEC_GSS.
Therefore an NFSv4 server SHOULD present file system location Therefore, an NFSv4 server SHOULD present file system location
entries that correspond to file systems on other servers using entries that correspond to file systems on other servers using
only host names. This enables the client to interrogate the only hostnames. This enables the client to interrogate the
fs_locations on the destination server to obtain trunking fs_locations on the destination server to obtain trunking
information (as well as replica information) using RPCSEC_GSS with information (as well as replica information) using RPCSEC_GSS with
integrity, validating the host name provided while assuring that integrity, validating the hostname provided while ensuring that
the response has not been corrupted. the response has not been corrupted.
When RPCSEC_GSS is not available on an NFS server, returned file When RPCSEC_GSS is not available on an NFS server, returned file
system location information is subject to corruption during system location information is subject to corruption during
transit and cannot be relied upon. In the case of a client being transit and cannot be relied upon. In the case of a client being
directed to another server after NFS4ERR_MOVED, this could vitiate directed to another server after NFS4ERR_MOVED, this could vitiate
the authentication provided by the use of RPCSEC_GSS on the the authentication provided by the use of RPCSEC_GSS on the
destination. Even when RPCSEC_GSS authentication is available on destination. Even when RPCSEC_GSS authentication is available on
the destination, this server might validly represent itself as the the destination, this server might validly represent itself as the
server to which the client was erroneously directed. Without a server to which the client was erroneously directed. Without a
way to decide wether the server is a valid one, the client can way to decide whether the server is a valid one, the client can
only determine, using RPCSEC_GSS, that the server corresponds to only determine, using RPCSEC_GSS, that the server corresponds to
the host name provided, with no basis for trusting that server. the hostname provided, with no basis for trusting that server.
The client should not use such unverified file system location The client should not use such unverified file system location
entries as a basis for migration, even though RPCSEC_GSS might be entries as a basis for migration, even though RPCSEC_GSS might be
available on the destination server. available on the destination server.
When a file system location attribute is fetched upon connecting When a file system location attribute is fetched upon connecting
with an NFSv4 server, it SHOULD, as stated above, be done using with an NFSv4 server, it SHOULD, as stated above, be done using
RPCSEC_GSS with integrity protection. RPCSEC_GSS with integrity protection.
When file system location information cannot be protected in When file system location information cannot be protected in
transit, the client can subject it to additional filtering to transit, the client can subject it to additional filtering to
prevent the client from being inappropriately directed. For prevent the client from being inappropriately directed. For
example, if a range of network addresses can be determined that example, if a range of network addresses can be determined that
assure that the servers and clients using AUTH_SYS are subject to ensure that the servers and clients using AUTH_SYS are subject to
appropriate constraints (such as physical network isolation and appropriate constraints (such as physical network isolation and
the use of administrative controls within the operating systems), the use of administrative controls within the operating systems),
then network adresses in this range can be used, with others then network addresses in this range can be used, with others
discarded or restricted in their use of AUTH_SYS. discarded or restricted in their use of AUTH_SYS.
When neither integrity protection nor filtering is possible, it is When neither integrity protection nor filtering is possible, it is
best for the client to ignore trunking and replica information or best for the client to ignore trunking and replica information or
simply not fetch the file system location information for these simply not fetch the file system location information for these
purposes. purposes.
To summarize considerations regarding the use of RPCSEC_GSS in To summarize considerations regarding the use of RPCSEC_GSS in
fetching file system location information, consider the following fetching file system location information, consider the following
recommendations for requests to interrogate location information, recommendations for requests to interrogate location information,
skipping to change at page 18, line 20 skipping to change at page 19, line 6
o The use of requests issued without RPCSEC_GSS (e.g., using o The use of requests issued without RPCSEC_GSS (e.g., using
AUTH_SYS), while undesirable, might be unavoidable in some AUTH_SYS), while undesirable, might be unavoidable in some
cases. Where the use of returned file system location cases. Where the use of returned file system location
information cannot be avoided, it should be subject to information cannot be avoided, it should be subject to
filtering to eliminate untrusted network addresses. The filtering to eliminate untrusted network addresses. The
specifics will vary depending on the degree of network specifics will vary depending on the degree of network
isolation and whether the request is to the referring or isolation and whether the request is to the referring or
destination servers. destination servers.
Privacy considerations relating to uniform client strings (UCS) Privacy considerations relating to uniform client strings (UCS)
vs. non-uniform client strings (non-UCS), discussed in versus non-uniform client strings (non-UCS), discussed in
Section 5.6 of [RFC7931], are also applicable to their usage for Section 5.6 of [RFC7931], are also applicable to their usage for
trunking detection in NFS version 4.0. trunking detection in NFS version 4.0.
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document has no IANA actions.
9. References 9. Updates to the References Section in RFC 7530
9.1. Normative References 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>. May 2009, <https://www.rfc-editor.org/info/rfc5531>.
skipping to change at page 19, line 14 skipping to change at page 21, line 5
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
Memory Access Transport for Remote Procedure Call Version Memory Access Transport for Remote Procedure Call Version
1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
<https://www.rfc-editor.org/info/rfc8166>. <https://www.rfc-editor.org/info/rfc8166>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 10.2. Informative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>. <https://www.rfc-editor.org/info/rfc5661>.
skipping to change at page 19, line 39 skipping to change at page 22, line 10
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Section Classification Appendix A. Section Classification
All sections of the current document are considered explanatory with All sections of the current document are considered explanatory with
the following exceptions. the following exceptions.
o Sections 5.1 and 5.2.1 are replacement sections. o Sections 5.1, 5.2.4, 5.2.5, and 5.3 are replacement sections.
o Section 5.2.2 is an additional section.
o Sections 5.2.4 and 5.2.5 are replacement sections.
o Section 5.2.6 is an additional section.
o Section 5.3 is a replacement section.
o Section 6 is an editing section. o Sections 5.2.2, 5.2.3, and 5.2.6 are additional sections.
o Section 7 is an additional section. o Sections 5.2.1, 6, 7, and Section 9 are editing sections.
Acknowledgments Acknowledgments
The authors wish to thank Andy Adamson, who wrote the original The authors wish to thank Andy Adamson, who wrote the original
version of this document. All the innovation in this document is the version of this document. All the innovation in this document is the
result of Andy's work, while mistakes are best ascribed to the result of Andy's work, while mistakes are best ascribed to the
current authors. current authors.
The editor wishes to thank Greg Marsden for his support of this work, The editor wishes to thank Greg Marsden for his support of this work
and Robert Thurlow for his review and suggestions. and Robert Thurlow for his review and suggestions.
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Working Group Secretary Thomas Haynes for their ongoing support. We Working Group Secretary Thomas Haynes for their ongoing support. We
are also grateful for the thorough review of this document by are also grateful for the thorough review of this document by
Benjamin Kaduk and Ben Campbell. Benjamin Kaduk and Ben Campbell.
Authors' Addresses Authors' Addresses
 End of changes. 111 change blocks. 
342 lines changed or deleted 343 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/