idnits 2.17.1 draft-ietf-nfsv4-mv0-trunking-update-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2019) is 1909 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-TBD' is mentioned on line 254, but not defined -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever, Ed. 3 Internet-Draft Oracle 4 Updates: 7530 (if approved) D. Noveck 5 Intended status: Standards Track NetApp 6 Expires: August 5, 2019 February 1, 2019 8 NFS version 4.0 Trunking Update 9 draft-ietf-nfsv4-mv0-trunking-update-04 11 Abstract 13 The file system location-related attribute in NFS version 4.0, 14 fs_locations, informs clients about alternate locations of file 15 systems. An NFS version 4.0 client can use this information to 16 handle migration and replication of server filesystems. This 17 document describes how an NFS version 4.0 client can additionally use 18 this information to discover an NFS version 4.0 server's trunking 19 capabilities. This document updates RFC 7530. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 5, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Document Organization . . . . . . . . . . . . . . . . . . . . 6 59 5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 7 60 5.1. Updated Section 8.1 of [RFC7530], entitled 61 "Location Attributes" . . . . . . . . . . . . . . . . . . 8 62 5.2. Updates to Section 8.4 of [RFC7530], entitled 63 "Uses of Location Information" . . . . . . . . . . . . . 9 64 5.2.1. Updated Introduction to Section 8.4 of [RFC7530], 65 entitled "Uses of Location Information" . . . . . . . 9 66 5.2.2. New Sub-section of Section 8.4 of [RFC7530], 67 to be entitled "Trunking Discovery and Detection" . . 10 68 5.2.3. New Sub-section of Section 8.4 of [RFC7530], 69 to be entitled "Location Attributes and Connection 70 Type Selection" . . . . . . . . . . . . . . . . . . . 11 71 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled 72 "File System Replication and Trunking" . . . . . . . 12 73 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled 74 "File System Migration" . . . . . . . . . . . . . . . 12 75 5.2.6. New Sub-section of Section 8.4 of [RFC7530], 76 to be entitled "Interaction of Trunking, Migration, 77 and Replication" . . . . . . . . . . . . . . . . . . 13 78 5.3. Updated Section 8.5 of [RFC7530], entitled 79 "Location Entries and Server Identity Update" . . . . . . 15 80 6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 9.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Appendix A. Section Classification . . . . . . . . . . . . . . . 19 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The NFS version 4.0 specification [RFC7530] defines a migration 93 feature that enables the transfer of a file system from one server to 94 another without disruption of client activity. There were a number 95 of issues with the original definition of this feature, now resolved 96 with the publication of [RFC7931]. 98 After a migration event, a client must determine whether state 99 recovery is necessary. To do this, it needs to determine whether the 100 source and destination server addresses represent the same server 101 instance, if the client has already established a lease on the 102 destination server for other file systems, and if the destination 103 server instance has lock state for the migrated file system. 105 As part of addressing this need, [RFC7931] introduces trunking into 106 NFS version 4.0 along with a trunking detection mechanism. A 107 trunking detection mechanism enables a client to determine whether 108 two distinct network addresses are connected to the same NFS version 109 4.0 server instance. Without this knowledge, a client unaware of a 110 trunking relationship between paths it is using simultaneously is 111 likely to become confused in ways described in [RFC7530]. 113 NFSv4.1 was defined with an integral means of trunking detection, 114 described in [RFC5661]. NFSv4.0 initially did not have one, with it 115 being added by [RFC7931]. Nevertheless, the use of the concept of 116 server-trunkability is the same in both protocol versions. 118 File system migration, replication, and referrals are distinct 119 protocol features. However, it is not appropriate to treat each of 120 these features in isolation. For example, client migration recovery 121 processing needs to deal with the possibility of multiple server 122 addresses in a returned fs_locations attribute. In addition, the 123 contents of the fs_locations attribute, which provides both trunking- 124 related and replication information, may change over repeated 125 retrievals, requiring an integrated description of how clients are to 126 deal with such changes. The issues discussed in the current document 127 relate to the interpretation of the fs_locations attribute and to the 128 proper client and server handling of changes in fs_locations 129 attribute values. 131 Therefore the goals of the current document are: 133 o To provide NFS version 4.0 with a means of finding addresses 134 trunkable with a given address; i.e., trunking discovery, 135 compatible with the means of trunking detection introduced by 136 [RFC7931]. For an explanation of trunking detection and 137 discovery, see Section 3. 139 o To describe how NFS version 4.0 clients are to handle the presence 140 of multiple network addresses associated to the same server, when 141 recovering from a replication and migration event. 143 o To describe how NFS version 4.0 clients are to handle changes in 144 the contents of returned fs_locations attributes, including those 145 that indicate changes in the responding NFS version 4.0 server's 146 trunking configuration. 148 The current document pursues these goals by presenting a set of 149 updates to [RFC7530] as summarized in Sections 5 and 6 below. 151 2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Terminology 161 Most of the terms related to handling the fs_locations attribute are 162 appropriately defined in Section 5.1 below. However, there are a few 163 terms used outside that context that are explained in this section. 165 Trunking refers to a situation in which a client uses multiple 166 network addresses communicate with the same server. Trunking was 167 first introduced to NFSv4.0 by [RFC7931]. Regarding network 168 addresses and the handling of trunking we use the following 169 terminology: 171 o Each NFSv4 server is assumed to have a set of IP addresses to 172 which NFSv4 requests may be sent by clients. These are referred 173 to as the server's network addresses. Access to a specific server 174 network address might involve the use of multiple network ports, 175 since the ports to be used for particular types of connections 176 might be required to be different. 178 o Clients may establish connections to NFSv4 servers via one of 179 several connection types, supporting the NFSv4 protocol layered on 180 top of an RPC stream transport, as described in [RFC5531], or on 181 top of RPC-over-RDMA, as described in [RFC8166]. The combination 182 of a server network address and a particular connection type is 183 referred to as a "server endpoint". 185 o Each network address, when combined with a pathname providing the 186 location of a file system root directory relative to the 187 associated server root file handle, defines a file system network 188 access path. 190 o Two network addresses connected to the same server are said to be 191 server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 192 recognizes only a single type of trunking relationship between 193 addresses. 195 Particularly important is the distinction between trunking detection 196 and trunking discovery. The definitions we present are applicable to 197 all minor versions of NFSv4, but we put particular emphasis on how 198 these terms apply to NFS version 4.0. 200 o Trunking detection refers to ways of confirming that two unique 201 network addresses are associated with the same NFSv4 server 202 instance. The means available to make this determination depends 203 on the protocol version and, in some cases, on the client 204 implementation. 206 In the case of NFS version 4.0, the means to be used are described 207 in [RFC7931] and require use of the Uniform Client String approach 208 to be effective. This is in contrast to later minor versions for 209 which the means of trunking detection are described by [RFC5661]. 211 o Trunking discovery is a process by which an NFSv4 client, 212 accessing one server network address, can obtain other addresses 213 that might be associated with the same server instance. Typically 214 a client builds on a trunking detection facility by providing one 215 or more methods by which candidate addresses are made available to 216 the client, who then uses trunking detection to appropriately 217 filter them. 219 Trunking discovery is not discussed in [RFC7530] and no 220 description of it is provided in [RFC7931]. 222 Discussion of the term "replica" is complicated for a number of 223 reasons. Even though the term is used in explaining the issues in 224 [RFC7530] that need to be addressed in the current document, a full 225 explanation of this term requires explanation of related terms 226 connected to the fs_locations attribute, which is provided in 227 Section 5.1 of the current document. 229 The term is also used in previous documents about NFSv4.0 (i.e., 230 [RFC7530] and [RFC7931]) with a meaning different from that in the 231 current document. In these documents each replica is identified by a 232 single network access path. However, in the current document a set 233 of network access paths which have server-trunkable network addresses 234 and the same root-relative file system pathname are considered to be 235 a single replica with multiple network access paths. Although 236 [RFC7931] enables an NFSv4.0 client to determine whether two network 237 addresses were server-trunkable, it never described these as 238 connected to a single replica, leaving in effect the approach 239 established in [RFC7530]. 241 4. Document Organization 243 The sections of the current document are divided into four types 244 based on how they relate to the eventual updating of the NFS verion 245 4.0 specification. Once this update is published, NFS version 4.0 246 will be specified by multiple documents that need to be read 247 together, until such time as a consolidated replacement specification 248 is produced. 250 o The base specification [RFC7530]. 252 o The migration-related update [RFC7931]. 254 o This document [RFC-TBD]. 256 The section types are as follows. See Appendix A for a 257 classification of each section of the current document. 259 o An explanatory section does not contain any material that is meant 260 to update the specification of NFS version 4.0. Such sections may 261 contain explanation about why and how changes are to be done, but 262 do not include any text that is to update [RFC7530] or appear in 263 an eventual consolidated document. 265 o A replacement section contains text that is to replace and thus 266 supersede text within [RFC7530] and then appear in an eventual 267 consolidated document. The titles of replacement sections 268 indicate what section of [RFC7530] is to be replaced. 270 o An additional section contains text which, although not replacing 271 anything in [RFC7530], will be part of the specification of NFS 272 version 4.0 and will be expected to be part of an eventual 273 consolidated document. The titles of additional sections provide 274 an indication of where in an updated [RFC7530], the new section 275 would appear. 277 o An editing section contains some text that replaces text within 278 [RFC7530], although the entire section will not consist of such 279 text and will include other text as well. Such sections make 280 relatively minor adjustments in the existing NFS version 4.0 281 specification which are expected to be reflected in an eventual 282 consolidated document. Generally such replacement text appears as 283 a quotation, possibly taking the form of an indented set of 284 paragraphs. 286 5. Changes Within Section 8 of [RFC7530] 288 Most of the updates to [RFC7530] to provide support for trunking 289 using the fs_locations attribute apply to Section 8 of that document, 290 entitled "Multi-Server Namespace". 292 o Section 5.1 replaces Section 8.1 of [RFC7530], entitled "Location 293 Attributes". This section has been reorganized and extended to 294 explicitly allow the use of fs_locations to provide trunking- 295 related information that appropriately interacts with the 296 migration, replication and referral features of fs_locations. 297 Terminology used to describe the interactions is added. 299 o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of 300 Location Information". This section comprises the bulk of the 301 updates. Each paragraph of Section 8.4 and its sub-sections has 302 been reviewed to clarify the provision of trunking-related 303 information using the fs_locations attribute. 305 * Section 5.2.1 replaces the introductory material within 306 Section 8.4 of [RFC7530]; i.e., the material within Section 8.4 307 exclusive of subsections. 309 * Section 5.2.2 is to be added as a new sub-section of 310 Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In 311 a consolidated document, it would appear as Section 8.4.1. 313 * Section 5.2.3 is to be added as a new sub-section of 314 Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In 315 a consolidated document, it would appear as Section 8.4.2. 317 * Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled 318 "File System Replication". In a consolidated document, it 319 would appear as Section 8.4.3. 321 * Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled 322 "File System Migration". In a consolidated document, it would 323 appear as Section 8.4.4. 325 * Section 5.2.6 is to be added as a new sub-section of 326 Section 8.4 before Section 8.4.3 of [RFC7530]. In a 327 consolidated document, it would appear as Section 8.4.5, while 328 the existing Section 8.3 would appear as Section 8.4.6. 330 o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location 331 Entries and Server Identity". The last paragraph of the existing 332 section has been removed. 334 5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes" 336 The fs_locations attribute allows specification of file system 337 locations where the data corresponding to a given file system may be 338 accessed. This attribute represents such file system instances as a 339 server address target (as either a DNS host name representing one or 340 more network addresses, or a single literal network address) together 341 with the path of that file system within the associated single-server 342 namespace. Individual fs_locations entries can express trunkable 343 addresses, locations of file system replicas on other servers, 344 migration targets, or pure referrals. 346 We introduce the following terminology: 348 o Trunking is a situation in which multiple network addresses are 349 connected to the same NFS server. Network addresses connected to 350 the same NFS server instance are said to be server-trunkable. 352 o Trunking detection refers to ways of confirming that two distinct 353 network addresses are connected to the same NFSv4 server instance. 355 o Trunking discovery is a process by which a client using one 356 network address can obtain other candidate addresses that are 357 server-trunkable with it. 359 Regarding terminology relating to GETATTR attributes used in trunking 360 discovery and other multi-server namespace features: 362 o Location attributes include only the fs_locations GETATTR 363 attribute. 365 o Location entries (fs_location4, defined in [RFC7530] 366 Section 2.2.6) are the individual file system locations in the 367 fs_locations attribute (defined in [RFC7530] Section 2.2.7). A 368 file system location entry designates a set of network addresses 369 to which clients may establish connections. The entry may 370 designate multiple such addresses because the server host name may 371 map to multiple network addresses, and because multiple connection 372 types may be used to communicate with each specified network 373 address. Such addresses provide multiple ways of connecting to a 374 single server. 376 Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to 377 confirm that such addresses are connected to the same server. The 378 client can ignore non-confirmed trunking relationships and treat 379 the corresponding addresses as connected to different servers. 381 o File system location elements are derived from file system 382 location entries. If a file system location entry specifies a 383 network address, there is only a single corresponding location 384 element. When a file system location entry contains a host name, 385 the client resolves the hostname, producing one file system 386 location element for each of the resulting network addresses. 387 Issues regarding the trustworthiness of hostname resolutions are 388 further discussed in Section 7 of the current document. 390 o All file system location elements consist of a file system 391 location address, which is the network address of an interface to 392 a server, and an fs_name, which is the location of the file system 393 within the server's pseudo-fs. 395 o If the server has no pseudo-fs and only a single exported file 396 system at the root filehandle, the fs_name may be empty. 398 5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location 399 Information" 401 The subsections below provide replacement sections for existing 402 sections within Section 8.4 of [RFC7530] or new sub-sections to be 403 added to that section. 405 5.2.1. Updated Introduction to Section 8.4 of [RFC7530], entitled "Uses 406 of Location Information" 408 Together with the possibility of absent file systems, the file system 409 location-bearing attribute fs_locations provides a number of 410 important facilities that enable reliable, manageable, and scalable 411 data access. 413 When a file system is present on the queried server, this attribute 414 can provide a set of locations that clients may use to access the 415 file system. In the event that server failure, communications 416 problems, or other difficulties make continued access to the file 417 system impossible or otherwise impractical, the returned information 418 provides alternate locations that enable continued access to the file 419 system. Provision of such alternative file system locations is 420 referred to as "replication". 422 When alternative file system locations are provided, they may 423 represent distinct physical copies of the same file system data or 424 separate NFS server instances that provide access to the same 425 physical file system. Another possible use of the provision of 426 multiple file system location entries is trunking, wherein the file 427 system location entries do not in fact represent different servers 428 but rather are distinct network paths to the same server. 430 A client may use file system location elements simultaneously to 431 provide higher-performance access to the target file system. This 432 can be done using trunking, although the use of multiple replicas 433 simultaneously is possible. To enable simultaneous access, the 434 client utilizes trunking detection and/or discovery, further 435 described in Section 5.2.2 of the current document, to determine a 436 set of network paths that are server-trunkable with the one currently 437 being used to access the file system. Once this determination is 438 made, requests may be routed across multiple paths, using the 439 existing state management mechanism. 441 Multiple replicas may also be used simultaneously, typically used 442 when accessing read-only datasets. In this case, each replica 443 requires its own state management. The client performs multiple file 444 opens to read the same file content from multiple replicas. 446 When a file system is present and subsequently becomes absent, 447 clients can be given the opportunity to have continued access to 448 their data at an alternative file system location. Transfer of the 449 file system contents to the new file system location is referred to 450 as "migration". The client's responsibilities in dealing with this 451 transition depend on the specific nature of the new access path as 452 well as how and whether data was in fact migrated. See Sections 453 5.2.5 and 5.2.6 of the current document for details. 455 The fs_locations attribute can designate one or more remote file 456 system locations in place of an absent file system. This is known as 457 a "referral". A particularly important case is that of a "pure 458 referral", in which the absent file system has never been present on 459 the NFS server. Such a referral is a means by which a file system 460 located on one server can redirect clients to file systems located on 461 other servers, thus enabling the creation of a multi-server 462 namespace. 464 Because client support for the fs_locations attribute is OPTIONAL, a 465 server may (but is not required to) take action to hide migration and 466 referral events from such clients by acting as a proxy, for example. 468 5.2.2. New Sub-section of Section 8.4 of [RFC7530], to be entitled 469 "Trunking Discovery and Detection" 471 Trunking is a situation in which multiple distinct network addresses 472 are associated with the same NFS server instance. As a matter of 473 convenience, we say that two network addresses connected to the same 474 NFS server instance are server-trunkable. Section 5.4 of [RFC7931] 475 explains why NFSv4 clients need to be aware of NFS server identity to 476 manage lease and lock state effectively when multiple connections to 477 the same server exist. 479 Trunking detection refers to a way for an NFSv4 client to confirm 480 that two independently acquired network addresses are connected to 481 the same NFSv4 server. Section 5.8 of [RFC7931] describes an 482 OPTIONAL means by which it can be determined if two network addresses 483 correspond to the same NFSv4.0 server instance. Without trunking 484 detection, an NFSv4.0 client has no other way to confirm that two 485 network addresses are server-trunkable. 487 In the particular context of NFS version 4.0, trunking detection 488 requires that the client support the Uniform Client ID String 489 approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0 490 client that supports migration or trunking detection needs to present 491 a Uniform Client ID String to all NFSv4.0 servers. If it does not do 492 so, it will be unable to perform trunking detection. 494 Trunking discovery is the process by which an NFSv4 client using a 495 host name or one of an NFSv4 server's network addresses can obtain 496 other candidate network addresses that are trunkable with it; i.e., a 497 set of addresses that might be connected to the same NFSv4 server 498 instance. An NFSv4.0 client can discover server-trunkable network 499 addresses in a number of ways: 501 o An NFS server's host name is provided either at mount time or in a 502 returned file system location entry. A DNS query of this host 503 name can return more than one network address. The returned 504 network addresses are candidates for trunking. 506 o Location entries returned in an fs_locations attribute can specify 507 network addresses. These network addresses are candidates for 508 trunking. 510 When there is a means of trunking detection available, an NFSv4.0 511 client can confirm that a set of network addresses correspond to the 512 same NFSv4.0 server instance and thus any of them can be used to 513 access that server. 515 5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled 516 "Location Attributes and Connection Type Selection" 518 NFS version 4.0 may be implemented using a number of different types 519 of connections: 521 Stream connections may be used to provide RPC service, as 522 described in [RFC5531]. 524 RDMA-capable connections may be used to provide RPC service, as 525 described in [RFC8166]. 527 Because of the need to support multiple connections, clients face the 528 issue of determining the proper connection type to use when 529 establishing a connection to a server network address. The 530 fs_locations attribute provides no information to support connection 531 type selection. As a result, clients supporting multiple connection 532 types need to attempt to establish a connection on various connection 533 types allowing it to determine, via a trial-and-error approach, which 534 connection types are supported. 536 If a client strongly prefers one connection type, it can perform 537 these attempts serially in order of declining preference. Once there 538 is a successful attempt, the established connection can be used. 539 Note that with this approach, network partitions can result in a 540 sequence of long waits for a successful connection. 542 To avoid waiting when there is at least one viable network path 543 available, simultaneous attempts to establish multiple connection 544 types are possible. Once a viable connection is established, the 545 client discards less-preferred connections. 547 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System 548 Replication and Trunking" 550 On first access to a file system, the client should obtain the value 551 of the set of alternative file system locations by interrogating the 552 fs_locations attribute. Trunking discovery and/or detection can then 553 be applied to the file system location entries to separate the 554 candidate server-trunkable addresses from the replica addresses that 555 provide alternative locations of the file system. Server-trunkable 556 addresses may be used simultaneously to provide higher performance 557 through the exploitation of multiple paths between client and target 558 file system. 560 In the event that server failures, communications problems, or other 561 difficulties make continued access to the current file system 562 impossible or otherwise impractical, the client can use the 563 alternative file system locations as a way to maintain continued 564 access to the file system. See Section 5.2.6 of the current document 565 for more detail. 567 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled "File System 568 Migration" 570 When a file system is present and becomes absent, clients can be 571 given the opportunity to have continued access to their data at an 572 alternative file system location specified by the fs_locations 573 attribute. Typically, a client will be accessing the file system in 574 question, get an NFS4ERR_MOVED error, and then use the fs_locations 575 attribute to determine the new location of the data. See 576 Section 5.2.6 of the current document for more detail. 578 Such migration can help provide load balancing or general resource 579 reallocation. The protocol does not specify how the file system will 580 be moved between servers. It is anticipated that a number of 581 different server-to-server transfer mechanisms might be used, with 582 the choice left to the server implementer. The NFSv4 protocol 583 specifies the method used to communicate the migration event between 584 client and server. 586 When the client receives indication of a migration event via an 587 NFS4ERR_MOVED error, data propagation to the destination server must 588 have already occurred. Once the client proceeds to access the 589 alternate file system location, it must see the same data. Where 590 file systems are writable, a change made on the original file system 591 must be visible on all migration targets. Where a file system is not 592 writable but represents a read-only copy (possibly periodically 593 updated) of a writable file system, similar requirements apply to the 594 propagation of updates. Any change visible in the original file 595 system must already be effected on all migration targets, to avoid 596 any possibility that a client, in effecting a transition to the 597 migration target, will see any reversion in file system state. 599 5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled 600 "Interaction of Trunking, Migration, and Replication" 602 When the set of network addresses on a server change in a way that 603 would affect a file system location attribute, there are several 604 possible outcomes for clients currently accessing that file system. 605 NFS4ERR_MOVED is returned only when the server cannot satisfy a 606 request from the client, whether because the file system has been 607 migrated to a different server, is only accessible at a different 608 trunked address on the same server, or some other reason. In the 609 cases 1 and 2 below, NFS4ERR_MOVED is not returned. 611 1. When the list of network addresses is a superset of that 612 previously in effect, there is no need for migration or any other 613 sort of client adjustment. Nevertheless, the client is free to 614 use an additional address in the replacement list if that address 615 provides another path to the same server. Or, the client may 616 treat that address as it does a replica, to be used if current 617 server addresses become unavailable. 619 2. When the list of network addresses is a subset of that previously 620 in effect, immediate action is not needed if an address missing 621 in the replacement list is not currently in use by the client. 622 The client should avoid using that address to access that file 623 system in the future, whether the address is for a replica or an 624 additional path to the server being used. 626 3. When an address being removed is one of a number of paths to the 627 current server, the client may continue to use it until 628 NFS4ERR_MOVED is received. This is not considered a migration 629 event unless the last available path to the server has become 630 unusable. 632 When migration does occur, multiple addresses may be in use on the 633 server previous to migration and multiple addresses may be available 634 for use on the destination server. 636 With regard to the server in use, it may be that return of 637 NFS4ERR_MOVED indicates that a particular network address is no 638 longer to be used, without implying that migration of the file system 639 to a different server is needed. Clients should not conclude that 640 migration has occurred until confirming that all network addresses 641 known to be associated with that server are not usable. 643 It should be noted that the need to defer this determination is not 644 absolute. If a client is not aware of all network addresses for any 645 reason, it may conclude that migration has occurred when it has not 646 and treat a switch to a different server address as if it were a 647 migration event. This is harmless since the use of the same server 648 via a new address will appear as a successful instance of Transparent 649 State Migration. 651 Although significant harm cannot arise from this misapprehension, it 652 can give rise to disconcerting situations. For example, if a lock 653 has been revoked during the address shift, it will appear to the 654 client as if the lock has been lost during migration. When such a 655 lock is lost, it is the responsibility of the destination server to 656 provide for its recovery via the use of an fs-specific grace period. 658 With regard to the destination server, it is desirable for the client 659 to be aware of all valid network addresses that can be used to access 660 the destination server. However, there is no need for this to be 661 done immediately. Implementations can process the additional file 662 system location elements in parallel with normal use of the first 663 valid file system location entry found to access the destination. 665 Because a file system location attribute may include entries relating 666 to the current server, the migration destination, and possible 667 replicas to use, scanning for available network addresses that might 668 be trunkable with addresses the client has already seen could 669 potentially be a long process. To keep this process as short as 670 possible, servers that provide information about trunkable network 671 paths are REQUIRED to place file system location entries that 672 represent addresses usable with the current server or a migration 673 target before those associated with replicas. 675 This ordering allows a client to cease scanning for trunkable file 676 system location entries once it encounters a file system location 677 element whose fs_name differs from the current fs_name, or whose 678 address is not server-trunkable with the one it is currently using. 679 Although the possibility exists that a client might prematurely cease 680 scanning for trunkable addresses when receiving a location attribute 681 from an older server that does not follow the ordering constraint 682 above, the harm is expected to be limited since such servers would 683 not be expected to present information about trunkable server access 684 paths. 686 5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and 687 Server Identity Update" 689 As mentioned above, a single file system location entry may have a 690 server address target in the form of a DNS host name that resolves to 691 multiple network addresses; it is also possible for multiple file 692 system location entries to have their own server address targets that 693 reference the same server. 695 When server-trunkable addresses for a server exist, the client may 696 assume that for each file system in the namespace of a given server 697 network address, there exist file systems at corresponding namespace 698 locations for each of the other server-trunkable network addresses. 699 It may do this even in the absence of explicit listing in 700 fs_locations. Such corresponding file system locations can be used 701 as alternative locations, just as those explicitly specified via the 702 fs_locations attribute. 704 If a single file system location entry designates multiple server IP 705 addresses, the client should choose a single one to use. When two 706 server addresses are designated by a single file system location 707 entry and they correspond to different servers, this normally 708 indicates some sort of misconfiguration. The client should avoid 709 using such file system location entries when alternatives are 710 available. When they are not, the client should pick one of the IP 711 addresses and use it, without using others that are not directed to 712 the same server. 714 6. Updates to [RFC7530] Outside Section Eight 716 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 717 of [RFC7530] does not take proper account of trunking, it needs to be 718 modified by replacing the first two sentences of the description with 719 the following material: 721 The file system that contains the current filehandle object cannot 722 be accessed using the current network address. It may be 723 accessible using other network addresses connected to the same 724 server, it may have been relocated to another server, or it may 725 never have been present. 727 7. Security Considerations 729 The Security Considerations section of [RFC7530] needs the additions 730 below to properly address some aspects of trunking discovery, 731 referral, migration, and replication. 733 The possibility that requests to determine the set of network 734 addresses corresponding to a given server might be interfered with 735 or have their responses corrupted needs to be taken into account. 737 o When DNS is used to convert NFS server host names to network 738 addresses and DNSSEC [RFC4033] is not available, the validity 739 of the network addresses returned cannot be relied upon. 740 However, when the client uses RPCSEC_GSS [RFC7861] to access 741 NFS servers, it is possible for mutual authentication to detect 742 invalid server addresses. Other forms of transport layer 743 security (e.g., [RFC8446]) can also offer strong authentication 744 of NFS servers. 746 o Fetching file system location information SHOULD be performed 747 using RPCSEC_GSS with integrity protection, as previously 748 explained in the Security Considerations section of [RFC7530]. 749 Making a request of this sort without using strong integrity 750 protection permits corruption during transit of returned file 751 system location information. The client implementer needs to 752 recognize that using such information to access an NFS server 753 without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined 754 in [RFC5531]) can result in the client interacting with an 755 unverified network address that is posing as an NFSv4 server. 757 o Despite the fact that it is a REQUIREMENT of [RFC7530] that 758 "implementations" provide "support" for the use of RPCSEC_GSS, 759 it cannot be assumed that use of RPCSEC_GSS is always possible 760 between any particular client-server pair. 762 o Returning only network addresses to a client that has no 763 trusted DNS resolution service can hamper its ability to use 764 RPCSEC_GSS. 766 Therefore an NFSv4 server SHOULD present file system location 767 entries that correspond to file systems on other servers using 768 only host names. This enables the client to interrogate the 769 fs_locations on the destination server to obtain trunking 770 information (as well as replica information) using RPCSEC_GSS with 771 integrity, validating the host name provided while assuring that 772 the response has not been corrupted. 774 When RPCSEC_GSS is not available on an NFS server, returned file 775 system location information is subject to corruption during 776 transit and cannot be relied upon. In the case of a client being 777 directed to another server after NFS4ERR_MOVED, this could vitiate 778 the authentication provided by the use of RPCSEC_GSS on the 779 destination. Even when RPCSEC_GSS authentication is available on 780 the destination, this server might validly represent itself as the 781 server to which the client was erroneously directed. Without a 782 way to decide wether the server is a valid one, the client can 783 only determine, using RPCSEC_GSS, that the server corresponds to 784 the host name provided, with no basis for trusting that server. 785 The client should not use such unverified file system location 786 entries as a basis for migration, even though RPCSEC_GSS might be 787 available on the destination server. 789 When a file system location attribute is fetched upon connecting 790 with an NFSv4 server, it SHOULD, as stated above, be done using 791 RPCSEC_GSS with integrity protection. 793 When file system location information cannot be protected in 794 transit, the client can subject it to additional filtering to 795 prevent the client from being inappropriately directed. For 796 example, if a range of network addresses can be determined that 797 assure that the servers and clients using AUTH_SYS are subject to 798 appropriate constraints (such as physical network isolation and 799 the use of administrative controls within the operating systems), 800 then network adresses in this range can be used, with others 801 discarded or restricted in their use of AUTH_SYS. 803 When neither integrity protection nor filtering is possible, it is 804 best for the client to ignore trunking and replica information or 805 simply not fetch the file system location information for these 806 purposes. 808 To summarize considerations regarding the use of RPCSEC_GSS in 809 fetching file system location information, consider the following 810 recommendations for requests to interrogate location information, 811 with interrogation approaches on the referring and destination 812 servers arrived at separately: 814 o The use of RPCSEC_GSS with integrity protection is RECOMMENDED 815 in all cases, since the absence of integrity protection exposes 816 the client to the possibility of the results being modified in 817 transit. 819 o The use of requests issued without RPCSEC_GSS (e.g., using 820 AUTH_SYS), while undesirable, might be unavoidable in some 821 cases. Where the use of returned file system location 822 information cannot be avoided, it should be subject to 823 filtering to eliminate untrusted network addresses. The 824 specifics will vary depending on the degree of network 825 isolation and whether the request is to the referring or 826 destination servers. 828 Privacy considerations relating to uniform client strings (UCS) 829 vs. non-uniform client strings (non-UCS), discussed in 830 Section 5.6 of [RFC7931], are also applicable to their usage for 831 trunking detection in NFS version 4.0. 833 8. IANA Considerations 835 This document does not require actions by IANA. 837 9. References 839 9.1. Normative References 841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, 843 DOI 10.17487/RFC2119, March 1997, 844 . 846 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 847 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 848 May 2009, . 850 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 851 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 852 March 2015, . 854 [RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, 855 "NFSv4.0 Migration: Specification Update", RFC 7931, 856 DOI 10.17487/RFC7931, July 2016, 857 . 859 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 860 Memory Access Transport for Remote Procedure Call Version 861 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 862 . 864 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 865 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 866 May 2017, . 868 9.2. Informative References 870 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 871 Rose, "DNS Security Introduction and Requirements", 872 RFC 4033, DOI 10.17487/RFC4033, March 2005, 873 . 875 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 876 "Network File System (NFS) Version 4 Minor Version 1 877 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 878 . 880 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 881 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 882 November 2016, . 884 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 885 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 886 . 888 Appendix A. Section Classification 890 All sections of the current document are considered explanatory with 891 the following exceptions. 893 o Sections 5.1 and 5.2.1 are replacement sections. 895 o Section 5.2.2 is an additional section. 897 o Sections 5.2.4 and 5.2.5 are replacement sections. 899 o Section 5.2.6 is an additional section. 901 o Section 5.3 is a replacement section. 903 o Section 6 is an editing section. 905 o Section 7 is an additional section. 907 Acknowledgments 909 The authors wish to thank Andy Adamson, who wrote the original 910 version of this document. All the innovation in this document is the 911 result of Andy's work, while mistakes are best ascribed to the 912 current authors. 914 The editor wishes to thank Greg Marsden for his support of this work, 915 and Robert Thurlow for his review and suggestions. 917 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 918 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 919 Working Group Secretary Thomas Haynes for their ongoing support. We 920 are also grateful for the thorough review of this document by 921 Benjamin Kaduk and Ben Campbell. 923 Authors' Addresses 925 Charles Lever (editor) 926 Oracle Corporation 927 United States of America 929 Email: chuck.lever@oracle.com 931 David Noveck 932 NetApp 933 United States of America 935 Email: davenoveck@gmail.com