idnits 2.17.1 draft-ietf-nfsv4-mv0-trunking-update-03.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 (December 27, 2018) is 1940 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 246, 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: June 30, 2019 December 27, 2018 8 NFS version 4.0 Trunking Update 9 draft-ietf-nfsv4-mv0-trunking-update-03 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 June 30, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 5 59 5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 6 60 5.1. Updated Section 8.1 of [RFC7530], entitled 61 "Location Attributes" . . . . . . . . . . . . . . . . . . 7 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" . . . . . . . 11 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" . . . . . . . . . . . . . . . . . . 12 78 5.3. Updated Section 8.5 of [RFC7530], entitled 79 "Location Entries and Server Identity Update" . . . . . . 14 80 6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 14 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 85 9.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Appendix A. Section Classification . . . . . . . . . . . . . . . 18 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 The NFS version 4.0 specification [RFC7530] defines a migration 93 feature which enables the transfer of a file system from one server 94 to another without disruption of client activity. There were a 95 number of issues with the original definition of this feature, now 96 resolved 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. This 107 enables a client to determine whether two distinct network addresses 108 are connected to the same NFS version 4.0 server instance. 109 Nevertheless, the use of the concept of server-trunkability is the 110 same in both protocol versions. 112 File system migration, replication, and referrals are distinct 113 protocol features. However, it is not appropriate to treat each of 114 these features in isolation. For example, client migration recovery 115 processing needs to deal with the possibility of multiple server 116 addresses in a returned fs_locations attribute. In addition, the 117 contents of the fs_locations attribute, which provides both trunking- 118 related and replication information, may change over repeated 119 retrievals, requiring an integrated description of how clients are to 120 deal with such changes. The issues discussed in the current document 121 relate to the interpretation of the fs_locations attribute and to the 122 proper client and server handling of changes in fs_locations 123 attribute values. 125 Therefore the goals of this document are: 127 o To provide NFS version 4.0 with a means of trunking discovery, 128 compatible with the means of trunking detection introduced by 129 [RFC7931]. 131 o To describe how NFS version 4.0 clients are to handle the presence 132 of multiple network addresses associated to the same server, when 133 recovering from a replication and migration event. 135 o To describe how NFS version 4.0 clients are to handle changes in 136 the contents of returned fs_locations attributes, including those 137 that indicate changes in the responding NFS version 4.0 server's 138 trunking configuration. 140 The current document pursues these goals by presenting a set of 141 updates to [RFC7530] as summarized in Sections 5 and 6 below. 143 2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. Terminology 153 Most of the terms related to handling the fs_locations attribute are 154 appropriately defined in Section 5.1 below. However, there are a few 155 terms used outside that context that are explained in this section. 157 Trunking refers to a situation in which a client uses multiple 158 network addresses communicate with the same server. Trunking was 159 first introduced to NFSv4.0 by [RFC7931]. Regarding network 160 addresses and the handling of trunking we use the following 161 terminology: 163 o Each NFSv4 server is assumed to have a set of IP addresses to 164 which NFSv4 requests may be sent by clients. These are referred 165 to as the server's network addresses. Access to a specific server 166 network address might involve the use of multiple network ports, 167 since the ports to be used for particular types of connections 168 might be required to be different. 170 o Clients may establish connections to NFSv4 servers via one of 171 several connection types, supporting the NFSv4 protocol layered on 172 top of an RPC stream transport, as described in [RFC5531], or on 173 top of RPC-over-RDMA, as described in [RFC8166]. The combination 174 of a server network address and a particular connection type is 175 referred to as a "server endpoint". 177 o Each network address, when combined with a pathname providing the 178 location of a file system root directory relative to the 179 associated server root file handle, defines a file system network 180 access path. 182 o Two network addresses connected to the same server are said to be 183 server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 184 recognizes only a single type of trunking relationship between 185 addresses. 187 Particularly important is the distinction between trunking detection 188 and trunking discovery. The definitions we present are applicable to 189 all minor versions of NFSv4, but we put particular emphasis on how 190 these terms apply to NFS version 4.0. 192 o Trunking detection refers to ways of confirming that two unique 193 network addresses are associated with the same NFSv4 server 194 instance. The means available to make this determination depends 195 on the protocol version and, in some cases, on the client 196 implementation. 198 In the case of NFS version 4.0, the means to be used are described 199 in [RFC7931] and require use of the Uniform Client String approach 200 to be effective. This is in contrast to later minor versions for 201 which the means of trunking detection are described by [RFC5661]. 203 o Trunking discovery is a process by which an NFSv4 client, 204 accessing one server network address, can obtain other addresses 205 that might be associated with the same server instance. Typically 206 a client builds on a trunking detection facility by providing one 207 or more methods by which candidate addresses are made available to 208 the client, who then uses trunking detection to appropriately 209 filter them. 211 Trunking discovery is not discussed in [RFC7530] and no 212 description of it is provided in [RFC7931]. 214 Discussion of the term "replica" is complicated for a number of 215 reasons. Even though the term is used in explaining the issues in 216 [RFC7530] that need to be addressed in this document, a full 217 explanation of this term requires explanation of related terms 218 connected to the fs_locations attribute, which is provided in 219 Section 5.1 of the current document. 221 The term is also used in previous documents about NFSv4.0 (i.e., 222 [RFC7530] and [RFC7931]) with a meaning different from that in the 223 current document. In these documents each replica is identified by a 224 single network access path. However, in the current document a set 225 of network access paths which have server-trunkable network addresses 226 and the same root-relative file system pathname are considered to be 227 a single replica with multiple network access paths. Although 228 [RFC7931] enables an NFSv4.0 client to determine whether two network 229 addresses were server-trunkable, it never described these as 230 connected to a single replica, leaving in effect the approach 231 established in [RFC7530]. 233 4. Document Organization 235 The sections of the current document are divided into four types 236 based on how they relate to the eventual updating of the NFS verion 237 4.0 specification. Once this update is published, NFS version 4.0 238 will be specified by multiple documents that need to be read 239 together, until such time as a consolidated replacement specification 240 is produced. 242 o The base specification [RFC7530]. 244 o The migration-related update [RFC7931]. 246 o This document [RFC-TBD]. 248 The section types are as follows. See Appendix A for a 249 classification of each section of the current document. 251 o An explanatory section does not contain any material that is meant 252 to update the specification of NFS version 4.0. Such sections may 253 contain explanation about why and how changes are to be done, but 254 do not include any text that is to update [RFC7530] or appear in 255 an eventual consolidated document. 257 o A replacement section contains text that is to replace and thus 258 supersede text within [RFC7530] and then appear in an eventual 259 consolidated document. The titles of replacement sections 260 indicate what section of [RFC7530] is to be replaced. 262 o An additional section contains text which, although not replacing 263 anything in [RFC7530], will be part of the specification of NFS 264 version 4.0 and will be expected to be part of an eventual 265 consolidated document. The titles of additional sections provide 266 an indication of where in an updated [RFC7530], the new section 267 would appear. 269 o An editing section contains some text that replaces text within 270 [RFC7530], although the entire section will not consist of such 271 text and will include other text as well. Such sections make 272 relatively minor adjustments in the existing NFS version 4.0 273 specification which are expected to be reflected in an eventual 274 consolidated document. Generally such replacement text appears as 275 a quotation, possibly taking the form of an indented set of 276 paragraphs. 278 5. Changes Within Section 8 of [RFC7530] 280 Most of the updates to [RFC7530] to provide support for trunking 281 using the fs_locations attribute apply to Section 8 of that document, 282 entitled "Multi-Server Namespace". 284 o Section 5.1 replaces Section 8.1 of [RFC7530], entitled "Location 285 Attributes". This section has been reorganized and extended to 286 explicitly allow the use of fs_locations to provide trunking- 287 related information that appropriately interacts with the 288 migration, replication and referral features of fs_locations. 289 Terminology used to describe the interactions is added. 291 o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of 292 Location Information". This section comprises the bulk of the 293 updates. Each paragraph of Section 8.4 and its sub-sections has 294 been reviewed to clarify the provision of trunking-related 295 information using the fs_locations attribute. 297 * Section 5.2.1 replaces the introductory material within 298 Section 8.4 of [RFC7530]. 300 * Section 5.2.2 is to be added as a new sub-section of 301 Section 8.4 before the updated Section 8.4.1 of [RFC7530]. 303 * Section 5.2.3 is to be added as a new sub-section of 304 Section 8.4 before the updated Section 8.4.1 of [RFC7530]. 306 * Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled 307 "File System Replication". 309 * Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled 310 "File System Migration". 312 * Section 5.2.6 is to be added as a new sub-section of 313 Section 8.4 before Section 8.4.3 of [RFC7530]. 315 o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location 316 Entries and Server Identity". The last paragraph of the existing 317 section has been removed. 319 5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes" 321 The fs_locations attribute (described as "RECOMMENDED" in [RFC7530]) 322 allows specification of file system locations where the data 323 corresponding to a given file system may be accessed. This attribute 324 represents such file system instances as a server address target (as 325 either a DNS host name representing one or more network addresses, or 326 a single literal network address) together with the path of that file 327 system within the associated single-server namespace. Individual 328 fs_locations entries can express trunkable addresses, locations of 329 file system replicas on other servers, migration targets, or pure 330 referrals. 332 We introduce the following terminology: 334 o Trunking is a situation in which multiple network addresses are 335 connected to the same NFS server. Network addresses connected to 336 the same NFS server instance are said to be server-trunkable. 338 o Trunking detection refers to ways of confirming that two distinct 339 network addresses are connected to the same NFSv4 server instance. 341 o Trunking discovery is a process by which a client using one 342 network address can obtain other candidate addresses that are 343 server-trunkable with it. 345 Regarding terminology relating to GETATTR attributes used in trunking 346 discovery and other multi-server namespace features: 348 o Location attributes include only the fs_locations GETATTR 349 attribute. 351 o Location entries (fs_location4, defined in [RFC7530] 352 Section 2.2.6) are the individual file system locations in the 353 fs_locations attribute (defined in [RFC7530] Section 2.2.7). A 354 file system location entry designates a set of network addresses 355 to which clients may establish connections. The entry may 356 designate multiple such addresses because the server host name may 357 map to multiple network addresses, and because multiple connection 358 types may be used to communicate with each specified network 359 address. Such addresses provide multiple ways of connecting to a 360 single server. 362 Clients use the existing means for NFSv4.0 trunking detection, 363 defined in [RFC7931], to confirm that such addresses are connected 364 to the same server. The client can ignore addresses found not to 365 be so connected. 367 o File system location elements are derived from file system 368 location entries. If a file system location entry specifies a 369 network address, there is only a single corresponding location 370 element. When a file system location entry contains a host name, 371 the client resolves the hostname, producing one file system 372 location element for each of the resulting network addresses. 373 Issues regarding the trustworthiness of hostname resolutions are 374 further discussed in Section 7. 376 o All file system location elements consist of a file system 377 location address, which is the network address of an interface to 378 a server, and an fs_name, which is the location of the file system 379 within the server's pseudo-fs. 381 o If the server has no pseudo-fs and only a single exported file 382 system at the root filehandle, the fs_name may be empty. 384 5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location 385 Information" 387 The subsections below provide replacement sections for existing 388 sections within Section 8.4 of [RFC7530] or new sub-sections to be 389 added to that section. 391 5.2.1. Updated Introduction to Section 8.4 of [RFC7530], entitled "Uses 392 of Location Information" 394 Together with the possibility of absent file systems, the file system 395 location-bearing attribute fs_locations provides a number of 396 important facilities that enable reliable, manageable, and scalable 397 data access. 399 When a file system is present on the queried server, this attribute 400 can provide a set of locations that clients may use to access the 401 file system. In the event that server failure, communications 402 problems, or other difficulties make continued access to the file 403 system impossible or otherwise impractical, the returned information 404 provides alternate locations that enable continued access to the file 405 system. Provision of such alternative file system locations is 406 referred to as "replication". 408 When alternative file system locations are provided, they may 409 represent distinct physical copies of the same file system data or 410 separate NFS server instances that provide access to the same 411 physical file system. Another possible use of the provision of 412 multiple file system location entries is trunking, wherein the file 413 system location entries do not in fact represent different servers 414 but rather are distinct network paths to the same server. 416 A client may use file system location elements simultaneously to 417 provide higher-performance access to the target file system. The 418 client utilizes trunking detection and/or discovery, further 419 described in Section 5.2.2 of the current document, to determine a 420 set of network paths that are server-trunkable with the one currently 421 being used to access the file system. 423 When a file system is present and subsequently becomes absent, 424 clients can be given the opportunity to have continued access to 425 their data at an alternative file system location. Transfer of the 426 file system contents to the new file system location is referred to 427 as "migration". The client's responsibilities in dealing with this 428 transition depend on the specific nature of the new access path as 429 well as how and whether data was in fact migrated. See Sections 430 5.2.5 and 5.2.6 of the current document for details. 432 The fs_locations attribute can designate one or more remote file 433 system locations in place of an absent file system. This is known as 434 a "referral". A particularly important case is that of a "pure 435 referral", in which the absent file system has never been present on 436 the NFS server. Such a referral is a means by which a file system 437 located on one server can redirect clients to file systems located on 438 other servers, thus enabling the creation of a multi-server 439 namespace. 441 Because client support for the fs_locations attribute is OPTIONAL, a 442 server may (but is not required to) take action to hide migration and 443 referral events from such clients by acting as a proxy, for example. 445 5.2.2. New Sub-section of Section 8.4 of [RFC7530], to be entitled 446 "Trunking Discovery and Detection" 448 Trunking is a situation in which multiple distinct network addresses 449 are associated with the same NFS server instance. As a matter of 450 convenience, we say that two network addresses connected to the same 451 NFS server instance are server-trunkable. Section 5.4 of [RFC7931] 452 explains why NFSv4 clients need to be aware of NFS server identity to 453 manage lease and lock state effectively when multiple connections to 454 the same server exist. 456 Trunking detection refers to a way for an NFSv4 client to confirm 457 that two independently acquired network addresses are connected to 458 the same NFSv4 server. Section 5.8 of [RFC7931] describes an 459 OPTIONAL means by which it can be determined if two network addresses 460 correspond to the same NFSv4.0 server instance. Without trunking 461 detection, an NFSv4.0 client has no other way to confirm that two 462 network addresses are server-trunkable. 464 In the particular context of NFS version 4.0, trunking detection 465 requires that the client support the Uniform Client ID String 466 approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0 467 client that supports migration or trunking detection needs to present 468 a Uniform Client ID String to all NFSv4.0 servers. If it does not do 469 so, it will be unable to perform trunking detection. 471 Trunking discovery is the process by which an NFSv4 client using a 472 host name or one of an NFSv4 server's network addresses can obtain 473 other candidate network addresses that are trunkable with it; i.e., a 474 set of addresses that might be connected to the same NFSv4 server 475 instance. An NFSv4.0 client can discover server-trunkable network 476 addresses in a number of ways: 478 o An NFS server's host name is provided either at mount time or in a 479 returned file system location entry. A DNS query of this host 480 name can return more than one network address. The returned 481 network addresses are candidates for trunking. 483 o Location entries returned in an fs_locations attribute can specify 484 network addresses. These network addresses are candidates for 485 trunking. 487 When there is a means of trunking detection available, an NFSv4.0 488 client can confirm that a set of network addresses correspond to the 489 same NFSv4.0 server instance and thus any of them can be used to 490 access that server. 492 5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled 493 "Location Attributes and Connection Type Selection" 495 Because of the need to support multiple connections, clients face the 496 issue of determining the proper connection type to use when 497 establishing a connection to a server network address. The 498 fs_locations attribute provides no information to support connection 499 type selection. As a result, clients supporting multiple connection 500 types need to attempt to establish a connection on various connection 501 types allowing it to determine which connection types are supported. 503 If a client strongly prefers one connection type, it can perform 504 these attempts serially in order of declining preference. Once there 505 is a successful attempt, the established connection can be used. 506 Note that with this approach, network partitions can result in a 507 sequence of long waits for a successful connection. 509 To avoid waiting when there is at least one viable network path 510 available, simultaneous attempts to establish multiple connection 511 types are possible. Once a viable connection is established, the 512 client discards less-preferred connections. 514 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System 515 Replication and Trunking" 517 On first access to a file system, the client should obtain the value 518 of the set of alternative file system locations by interrogating the 519 fs_locations attribute. Trunking discovery and/or detection can then 520 be applied to the file system location entries to separate the 521 candidate server-trunkable addresses from the replica addresses that 522 provide alternative locations of the file system. Server-trunkable 523 addresses may be used simultaneously to provide higher performance 524 through the exploitation of multiple paths between client and target 525 file system. 527 In the event that server failures, communications problems, or other 528 difficulties make continued access to the current file system 529 impossible or otherwise impractical, the client can use the 530 alternative file system locations as a way to maintain continued 531 access to the file system. See Section 5.2.6 of the current document 532 for more detail. 534 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled "File System 535 Migration" 537 When a file system is present and becomes absent, clients can be 538 given the opportunity to have continued access to their data at an 539 alternative file system location specified by the fs_locations 540 attribute. Typically, a client will be accessing the file system in 541 question, get an NFS4ERR_MOVED error, and then use the fs_locations 542 attribute to determine the new location of the data. See 543 Section 5.2.6 of the current document for more detail. 545 Such migration can help provide load balancing or general resource 546 reallocation. The protocol does not specify how the file system will 547 be moved between servers. It is anticipated that a number of 548 different server-to-server transfer mechanisms might be used, with 549 the choice left to the server implementer. The NFSv4 protocol 550 specifies the method used to communicate the migration event between 551 client and server. 553 When the client receives indication of a migration event via an 554 NFS4ERR_MOVED error, data propagation to the destination server must 555 have already occurred. Once the client proceeds to access the 556 alternate file system location, it must see the same data. Where 557 file systems are writable, a change made on the original file system 558 must be visible on all migration targets. Where a file system is not 559 writable but represents a read-only copy (possibly periodically 560 updated) of a writable file system, similar requirements apply to the 561 propagation of updates. Any change visible in the original file 562 system must already be effected on all migration targets, to avoid 563 any possibility that a client, in effecting a transition to the 564 migration target, will see any reversion in file system state. 566 5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled 567 "Interaction of Trunking, Migration, and Replication" 569 When the set of network addresses designated by a file system 570 location attribute changes, NFS4ERR_MOVED might or might not result. 571 In some of the cases in which NFS4ERR_MOVED is returned migration has 572 occurred, while in others there is a shift in the network addresses 573 used to access a particular file system with no migration. 575 1. When the list of network addresses is a superset of that 576 previously in effect, there is no need for migration or any other 577 sort of client adjustment. Nevertheless, the client is free to 578 use an additional address in the replacement list if that address 579 provides another path to the same server. Or, the client may 580 treat that address as it does a replica, to be used if current 581 server addresses become unavailable. 583 2. When the list of network addresses is a subset of that previously 584 in effect, immediate action is not needed if an address missing 585 in the replacement list is not currently in use by the client. 586 The client should avoid using that address in the future, whether 587 the address is for a replica or an additional path to the server 588 being used. 590 3. When an address being removed is one of a number of paths to the 591 current server, the client may continue to use it until 592 NFS4ERR_MOVED is received. This is not considered a migration 593 event unless the last available path to the server has become 594 unusable. 596 When migration does occur, multiple addresses may be in use on the 597 server previous to migration and multiple addresses may be available 598 for use on the destination server. 600 With regard to the server in use, it may be that return of 601 NFS4ERR_MOVED indicates that a particular network address is no 602 longer to be used, without implying that migration of the file system 603 to a different server is needed. Clients should not conclude that 604 migration has occurred until confirming that all network addresses 605 known to be associated with that server are not usable. 607 It should be noted that the need to defer this determination is not 608 absolute. If a client is not aware of all network addresses for any 609 reason, it may conclude that migration has occurred when it has not 610 and treat a switch to a different server address as if it were a 611 migration event. This is harmless since the use of the same server 612 via a new address will appear as a successful instance of Transparent 613 State Migration. 615 Although significant harm cannot arise from this misapprehension, it 616 can give rise to disconcerting situations. For example, if a lock 617 has been revoked during the address shift, it will appear to the 618 client as if the lock has been lost during migration, normally 619 calling for it to be recoverable via an fs-specific grace period 620 associated with the migration event. 622 With regard to the destination server, it is desirable for the client 623 to be aware of all valid network addresses that can be used to access 624 the destination server. However, there is no need for this to be 625 done immediately. Implementations can process the additional file 626 system location elements in parallel with normal use of the first 627 valid file system location entry found to access the destination. 629 Because a file system location attribute may include entries relating 630 to the current server, the migration destination, and possible 631 replicas to use, scanning for available network addresses could 632 potentially be a long process. To keep this process as short as 633 possible, Servers are REQUIRED to place file system location entries 634 that represent addresses usable with the current server or a 635 migration target before those associated with replicas. A client can 636 then cease scanning for trunkable file system location entries once 637 it encounters a file system location element whose fs_name differs 638 from the current fs_name, or whose address is not server-trunkable 639 with the one it is currently using. 641 5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and 642 Server Identity Update" 644 As mentioned above, a single file system location entry may have a 645 server address target in the form of a DNS host name that resolves to 646 multiple network addresses, while multiple file system location 647 entries may have their own server address targets that reference the 648 same server. 650 When server-trunkable addresses for a server exist, the client may 651 assume that for each file system in the namespace of a given server 652 network address, there exist file systems at corresponding namespace 653 locations for each of the other server network addresses. It may do 654 this even in the absence of explicit listing in fs_locations. Such 655 corresponding file system locations can be used as alternative 656 locations, just as those explicitly specified via the fs_locations 657 attribute. 659 6. Updates to [RFC7530] Outside Section Eight 661 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 662 of [RFC7530] does not take proper account of trunking, it needs to be 663 modified by replacing the first two sentences of the description with 664 the following material: 666 The file system that contains the current filehandle object cannot 667 be accessed using the current network address. It may be 668 accessible using other network addresses connected to the same 669 server, it may have been relocated to another server, or it may 670 never have been present. 672 7. Security Considerations 674 The Security Considerations section of [RFC7530] needs the additions 675 below to properly address some aspects of trunking discovery, 676 referral, migration, and replication. 678 The possibility that requests to determine the set of network 679 addresses corresponding to a given server might be interfered with 680 or have their responses corrupted needs to be taken into account. 682 o When DNS is used to convert NFS server host names to network 683 addresses and DNSSEC [RFC4033] is not available, the validity 684 of the network addresses returned cannot be relied upon. 685 However, when the client uses RPCSEC_GSS [RFC7861] to access 686 NFS servers, it is possible for mutual authentication to detect 687 invalid server addresses. Other forms of transport layer 688 security (e.g., [RFC8446]) can also offer strong authentication 689 of NFS servers. 691 o Fetching file system location information SHOULD be performed 692 using RPCSEC_GSS with integrity protection, as previously 693 explained in the Security Considerations section of [RFC7530]. 694 Making a request of this sort without using strong integrity 695 protection permits corruption during transit of returned file 696 system location information. The client implementer needs to 697 recognize that using such information to access an NFS server 698 without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined 699 in [RFC5531]) can result in the client interacting with an 700 unverified network address that is posing as an NFSv4 server. 702 o Despite the fact that it is a REQUIREMENT of [RFC7530] that 703 "implementations" provide "support" for the use of RPCSEC_GSS, 704 it cannot be assumed that use of RPCSEC_GSS is always possible 705 between any particular client-server pair. 707 o Returning only network addresses to a client that has no 708 trusted DNS resolution service can hamper its ability to use 709 RPCSEC_GSS. 711 Therefore an NFSv4 server SHOULD present file system location 712 entries that correspond to file systems on other servers using 713 only host names. This enables the client to interrogate the 714 fs_locations on the destination server to obtain trunking 715 information (as well as replica information) using RPCSEC_GSS with 716 integrity, validating the host name provided while assuring that 717 the response has not been corrupted. 719 When RPCSEC_GSS is not available on an NFS server, returned file 720 system location information is subject to corruption during 721 transit and cannot be relied upon. In the case of a client being 722 directed to another server after NFS4ERR_MOVED, this could vitiate 723 the authentication provided by the use of RPCSEC_GSS on the 724 destination. Even when RPCSEC_GSS authentication is available on 725 the destination, this server might validly represent itself as the 726 server to which the client was erroneously directed. Without a 727 way to decide wether the server is a valid one, the client can 728 only determine, using RPCSEC_GSS, that the server corresponds to 729 the host name provided, with no basis for trusting that server. 730 The client should not use such unverified file system location 731 entries as a basis for migration, even though RPCSEC_GSS might be 732 available on the destination server. 734 When a file system location attribute is fetched upon connecting 735 with an NFSv4 server, it SHOULD, as stated above, be done using 736 RPCSEC_GSS with integrity protection. 738 When file system location information cannot be protected in 739 transit, the client can subject it to additional filtering to 740 prevent the client from being inappropriately directed. For 741 example, if a range of network addresses can be determined that 742 assure that the servers and clients using AUTH_SYS are subject to 743 appropriate constraints (such as physical network isolation and 744 the use of administrative controls within the operating systems), 745 then network adresses in this range can be used with others 746 discarded or restricted in their use of AUTH_SYS. 748 When neither integrity protection nor filtering is possible, it is 749 best for the client to ignore trunking and replica information or 750 simply not fetch the file system location information for these 751 purposes. 753 To summarize considerations regarding the use of RPCSEC_GSS in 754 fetching file system location information, consider the following 755 possibilities for requests to interrogate location information, 756 with interrogation approaches on the referring and destination 757 servers arrived at separately: 759 o The use of RPCSEC_GSS with integrity protection is RECOMMENDED 760 in all cases, since the absence of integrity protection exposes 761 the client to the possibility of the results being modified in 762 transit. 764 o The use of requests issued without RPCSEC_GSS (e.g., using 765 AUTH_SYS), while undesirable, might be unavoidable in some 766 cases. Where the use of returned file system location 767 information cannot be avoided, it should be subject to 768 filtering to eliminate untrusted network addresses. The 769 specifics will vary depending on the degree of network 770 isolation and whether the request is to the referring or 771 destination servers. 773 8. IANA Considerations 775 This document does not require actions by IANA. 777 9. References 779 9.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, 784 . 786 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 787 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 788 May 2009, . 790 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 791 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 792 March 2015, . 794 [RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, 795 "NFSv4.0 Migration: Specification Update", RFC 7931, 796 DOI 10.17487/RFC7931, July 2016, 797 . 799 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 800 Memory Access Transport for Remote Procedure Call Version 801 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 802 . 804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 806 May 2017, . 808 9.2. Informative References 810 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 811 Rose, "DNS Security Introduction and Requirements", 812 RFC 4033, DOI 10.17487/RFC4033, March 2005, 813 . 815 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 816 "Network File System (NFS) Version 4 Minor Version 1 817 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 818 . 820 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 821 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 822 November 2016, . 824 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 825 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 826 . 828 Appendix A. Section Classification 830 All sections of this document are considered explanatory with the 831 following exceptions. 833 o Sections 5.1 and 5.2.1 are replacement sections. 835 o Section 5.2.2 is an additional section. 837 o Sections 5.2.4 and 5.2.5 are replacement sections. 839 o Section 5.2.6 is an additional section. 841 o Section 5.3 is a replacement section. 843 o Section 6 is an editing section. 845 o Section 7 is an additional section. 847 Acknowledgments 849 The authors wish to thank Andy Adamson, who wrote the original 850 version of this document. All the innovation in this document is the 851 result of Andy's work, while mistakes are best ascribed to the 852 current authors. 854 The editor wishes to thank Greg Marsden for his support of this work, 855 and Robert Thurlow for review and suggestions. 857 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 858 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 859 Working Group Secretary Thomas Haynes for their ongoing support. 861 Authors' Addresses 863 Charles Lever (editor) 864 Oracle Corporation 865 United States of America 867 Email: chuck.lever@oracle.com 869 David Noveck 870 NetApp 871 United States of America 873 Email: davenoveck@gmail.com