idnits 2.17.1 draft-ietf-nfsv4-mv0-trunking-update-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 16, 2018) is 2111 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: January 17, 2019 July 16, 2018 8 NFS version 4.0 Trunking Update 9 draft-ietf-nfsv4-mv0-trunking-update-01 11 Abstract 13 The location-related attribute in NFS version 4.0, fs_locations, 14 informs clients about alternate locations of file systems. An NFS 15 version 4.0 client can use this information to handle migration and 16 replication of server filesystems. This document describes how an 17 NFS version 4.0 client can additionally use this information to 18 discover an NFS version 4.0 server's trunking capabilities. This 19 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 January 17, 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 . . . . . . . . . . . . . . . . . . . . 3 57 3. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Document Organization . . . . . . . . . . . . . . . . . . 5 60 3.3. Document Goals . . . . . . . . . . . . . . . . . . . . . 6 61 4. Overview of changes in RFC7530 Section 8 . . . . . . . . . . 6 62 5. Location Attributes (as updated) . . . . . . . . . . . . . . 7 63 6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 8 64 6.1. Introduction to uses of Location Information (as updated) 8 65 6.2. Trunking Discovery and Detection (to be added) . . . . . 10 66 6.3. Location Attributes and Connection Type Selection (to be 67 added) . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.4. File System Replication and Trunking (as updated) . . . . 11 69 6.5. File System Migration (as updated) . . . . . . . . . . . 11 70 6.6. Interaction of Trunking, Migration, and Replication (to 71 be added) . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Location Entries and Server Identity Update (as updated) . . 13 73 8. Updates to RFC7530 Outside Section Eight . . . . . . . . . . 14 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 11.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Appendix A. Section Classification . . . . . . . . . . . . . . . 17 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The NFS version 4.0 specification [RFC7530] defines a migration 86 feature which enables the transfer of a file system from one server 87 to another without disruption of client activity. There were a 88 number of issues with the original definition of this feature, now 89 resolved with the publication of [RFC7931]. 91 After a migration event, a client must determine whether state 92 recovery is necessary. To do this, it needs to determine whether the 93 source and destination server addresses represent the same server 94 instance, if the client has already established a lease on the 95 destination server for other file systems, and if the destination 96 server instance has lock state for the migrated file system. 98 As part of addressing this need, [RFC7931] introduces into NFS 99 version 4.0 a trunking detection mechanism to enable a client to 100 determine whether two distinct network addresses are connected to the 101 same NFS version 4.0 server instance. Despite this addition, the NFS 102 version 4.0 specification remains without a complete discussion of 103 trunking. 105 File system migration, replication, and referrals are distinct 106 protocol features. However, it is not appropriate to treat each of 107 these features in isolation. For example, client migration recovery 108 processing needs to deal with the possibility of multiple server 109 addresses in a returned fs_locations attribute. In addition, the 110 contents of the fs_locations attribute, which provides both trunking- 111 related and replication information, may change over repeated 112 retrievals, requiring an integrated description of how clients are to 113 deal with such changes. The issues discussed in the current document 114 relate to the interpretation of the fs_locations attribute and to the 115 proper client and server handling of changes in fs_locations 116 attribute values. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14 [RFC2119] 123 [RFC8174] when, and only when, they appear in all capitals, as shown 124 here. 126 3. Preliminaries 128 3.1. Terminology 130 Most of the terms related to handling the fs_locations attribute are 131 appropriately defined in Section 5 below. However, there are a few 132 terms used outside that context that are explained in this section. 134 Regarding network addresses and the handling of trunking we use the 135 following terminology: 137 o Each NFSv4 server is assumed to have a set of IP addresses to 138 which NFSv4 requests may be sent by clients. These are referred 139 to as the server's network addresses. Access to a specific server 140 network address might involve the use of multiple network ports, 141 since the ports to be used for particular types of connections 142 might be required to be different. 144 o Clients may establish connections to NFSv4 servers via one of 145 several connection types, supporting the NFSv4 protocol layered on 146 top of an RPC stream transport, as described in [RFC5531], or on 147 top of RPC-over-RDMA, as described in [RFC8166]. 149 o The combination of a server network address and a particular 150 connection type is referred to as a "server endpoint". Using 151 different connection types typically results in the use of 152 different ports. However, the use of different ports by multiple 153 connections to the same network address is not the essence of the 154 distinction between the two endpoints used. 156 o Each network address, when combined with a pathname providing the 157 location of a file system root directory relative to the 158 associated server root file handle, defines a file system network 159 access path. 161 o Two network addresses connected to the same server are said to be 162 server-trunkable. 164 Particularly important is the distinction between trunking detection 165 and trunking discovery. The definitions we present are applicable to 166 all minor versions of NFSv4, but we put particular emphasis on how 167 these terms apply to NFS version 4.0. 169 o Trunking detection refers to ways of confirming that two unique 170 network addresses are associated with the same NFSv4 server 171 instance. The means available to make this determination depends 172 on the protocol version and, in some cases, on the client 173 implementation. 175 In the case of NFS version 4.0, the means to be used are described 176 in [RFC7931] and require use of the Uniform Client String approach 177 to be effective. This is in contrast to later minor versions for 178 which the means of trunking detection are described by [RFC5661]. 180 o Trunking discovery is a process by which an NFSv4 client, 181 accessing one server network address, can obtain other addresses 182 that might be associated with the same server instance. Typically 183 a client builds on a trunking detection facility by providing one 184 or more methods by which candidate addresses are made available to 185 the client, who then uses trunking detection to appropriately 186 filter them. 188 Trunking discovery is not discussed in [RFC7530] and no 189 description of it is provided in [RFC7931]. 191 Discussion of the term "replica" is complicated for a number of 192 reasons. Even though the term is used in explaining the issues in 193 [RFC7530] that need to be addressed in this document, a full 194 explanation of this term requires explanation of related terms 195 connected to the fs_locations attribute, which is provided in 196 Section 5 of the current document. 198 The term is also used in previous documents about NFSv4.0 (i.e., 199 [RFC7530] and [RFC7931]) with a meaning different from that in the 200 current document. In these documents each replica is identified by a 201 single network access path. However, in the current document a set 202 of network access paths which have server-trunkable network addresses 203 and the same root-relative file system pathname are considered to be 204 a single replica with multiple network access paths. Although 205 [RFC7931] enables an NFSv4.0 client to determine whether two network 206 addresses were server-trunkable, it never described these as 207 connected to a single replica, leaving in effect the approach 208 established in [RFC7530]. 210 3.2. Document Organization 212 The sections of the current document are divided into four types 213 based on how they relate to the eventual updating of the NFS verion 214 4.0 specification. Once this update is published, NFS version 4.0 215 will be specified by multiple documents that need to be read 216 together, until such time as a consolidated replacement specification 217 is produced. 219 o The base specification [RFC7530]. 221 o The migration-related update [RFC7931]. 223 o An eventual RFC based on the current document. 225 The section types are as follows. See Appendix A for a 226 classification of each section of the current document. 228 o An explanatory section does not contain any material that is meant 229 to update the specification of NFS version 4.0. Such sections may 230 contain explanation about why and how changes are to be done, but 231 do not include any text that is to update [RFC7530] or appear in 232 an eventual consolidated document. 234 o A replacement section contains text that is to replace and thus 235 supersede text within [RFC7530] and then appear in an eventual 236 consolidated document. 238 o An additional section contains text which, although not replacing 239 anything in [RFC7530], will be part of the specification of NFS 240 version 4.0 and will be expected to be part of an eventual 241 consolidated document. 243 o An editing section contains some text that replaces text within 244 [RFC7530], although the entire section will not consist of such 245 text and will include other text as well. Such sections make 246 relatively minor adjustments in the existing NFS version 4.0 247 specification which are expected to be reflected in an eventual 248 consolidated document. Generally such replacement text appears as 249 a quotation, possibly taking the form of an indented set of 250 paragraphs. 252 3.3. Document Goals 254 The goals of this document are as follows: 256 o To provide NFS version 4.0 with a means of trunking discovery, 257 compatible with the means of trunking detection introduced by 258 [RFC7931]. 260 o To describe how NFS version 4.0 clients are to handle the presence 261 of multiple network addresses associated to the same server, when 262 recovering from a replication and migration event. 264 o To describe how NFS version 4.0 clients are to handle changes in 265 the contents of returned fs_locations attributes, including those 266 that indicate changes in the responding NFS version 4.0 server's 267 trunking configuration. 269 The current document pursues these goals by presenting a set of 270 updates to [RFC7530] as summarized in Sections 4 and 8 below. 272 4. Overview of changes in RFC7530 Section 8 274 With a few small exceptions (see below), all of the updates to 275 [RFC7530] to provide support for trunking using the fs_locations 276 attribute apply to Section 8 of that document, entitled "Multi-Server 277 Namespace". 279 o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location 280 Attributes". This section has been reorganized and extended to 281 explicitly allow the use of fs_locations to provide trunking- 282 related information that appropriately interacts with the 283 migration, replication and referral features of fs_locations. 284 Terminology used to describe the interactions is added. 286 o Section 6 updates Section 8.4 of [RFC7530], entitled "Uses of 287 Location Information". This section comprises the bulk of the 288 updates. Each paragraph of Section 8.4 and its sub-sections has 289 been reviewed to clarify the provision of trunking-related 290 information using the fs_locations attribute. 292 * Section 6.1 replaces the introductory material within 293 Section 8.4 of [RFC7530]. 295 * Section 6.2 is to be added after the introductory material 296 within Section 8.4 of [RFC7530]. 298 * Section 6.4 replaces Section 8.4.1 of [RFC7530], entitled "File 299 System Replication". 301 * Section 6.5 replaces Section 8.4.2 of [RFC7530], entitled "File 302 System Migration". 304 * Section 6.6 is to be added after the updated Section 8.4.2 of 305 [RFC7530]. 307 o Section 7 replaces Section 8.5 of [RFC7530], entitled "Location 308 Entries and Server Identity". The last paragraph of the existing 309 section has been removed. 311 o A small set of updates outside Section 8 of [RFC7530] are 312 presented in Section 8. 314 o Section 9 introduces additional security considerations that are 315 to be added to those within Section 19 of [RFC7530], entitled 316 "Security Considerations". 318 5. Location Attributes (as updated) 320 The fs_locations attribute (described as "RECOMMENDED" in [RFC7530]) 321 allows specification of file system locations where the data 322 corresponding to a given file system may be accessed. This attribute 323 represents such file system instances as a server address target (as 324 either a DNS host name representing one or more network addresses, or 325 a single literal network address) together with the path of that file 326 system within the associated single-server namespace. Individual 327 fs_locations entries can express trunkable addresses, locations of 328 file system replicas on other servers, migration targets, or pure 329 referrals. 331 We introduce the following terminology: 333 o Trunking is a situation in which multiple network addresses are 334 connected to the same NFS server. Network addresses connected to 335 the same NFS server instance are said to be server-trunkable. 337 o Trunking detection refers to ways of confirming that two distinct 338 network addresses are connected to the same NFSv4 server instance. 340 o Trunking discovery is a process by which a client using one 341 network address can obtain other candidate addresses that are 342 server-trunkable with it. 344 Regarding terminology relating to GETATTR attributes used in trunking 345 discovery and other multi-server namespace features: 347 o Location attributes include only the fs_locations GETATTR 348 attribute. 350 o Location entries (fs_location4, defined in [RFC7530] 351 Section 2.2.6) are the individual file system locations in the 352 fs_locations attribute (defined in [RFC7530] Section 2.2.7). A 353 location entry designates a set of network addresses to which 354 clients may establish connections. The entry may designate 355 multiple such addresses because the server host name may map to 356 multiple network addresses, and because multiple connection types 357 may be used to communicate with each specified network address. 358 All such addresses MUST provide a way of connecting to a single 359 server. 361 o Location elements are derived from location entries. If a 362 location entry specifies a network address there is only a single 363 corresponding location element. When a location entry contains a 364 host name, the host name is resolved by the client, producing one 365 location element for each of the resulting network addresses. 367 o All location elements consist of a location address, which is the 368 network address of an interface to a server, and an fs_name, which 369 is the location of the file system within the server's pseudo-fs. 371 o If the server has no pseudo-fs and only a single exported file 372 system at the root filehandle, the fs_name may be empty. 374 6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 376 The subsections below provide replacement sections for existing 377 sections within Section 8.4 of [RFC7530] or new sub-sections to be 378 added to that section. 380 6.1. Introduction to uses of Location Information (as updated) 382 Together with the possibility of absent file systems, the location- 383 bearing attribute fs_locations provides a number of important 384 facilities that enable reliable, manageable, and scalable data 385 access. 387 When a file system is present on the queried server, this attribute 388 can provide a set of locations that clients may use to access the 389 file system. In the event that server failure, communications 390 problems, or other difficulties make continued access to the file 391 system impossible or otherwise impractical, the returned information 392 provides alternate locations that enable continued access to the file 393 system. Provision of such alternative locations is referred to as 394 "replication". 396 When alternative locations are provided, they may represent distinct 397 physical copies of the same file system data or separate NFS server 398 instances that provide access to the same physical file system. 399 Another possible use of the provision of multiple location entries is 400 trunking, wherein the location entries do not in fact represent 401 different servers but rather are distinct network paths to the same 402 server. 404 A client may use location elements simultaneously to provide higher- 405 performance access to the target file system. The client utilizes 406 trunking detection and/or discovery, further described in Section 6.2 407 of the current document, to determine a set of network paths that are 408 server-trunkable with the one currently being used to access the file 409 system. 411 When a file system is present and subsequently becomes absent, 412 clients can be given the opportunity to have continued access to 413 their data at an alternative location. Transfer of the file system 414 contents to the new location is referred to as "migration". The 415 client's responsibilities in dealing with this transition depend on 416 the specific nature of the new access path as well as how and whether 417 data was in fact migrated. See Sections 6.5 and 6.6 of the current 418 document for details. 420 The fs_locations attribute can designate one or more remote locations 421 in place of an absent file system. This is known as a "referral". A 422 particularly important case is that of a "pure referral", in which 423 the absent file system has never been present on the NFS server. 424 Such a referral is a means by which a file system located on one 425 server can redirect clients to file systems located on other servers, 426 thus enabling the creation of a multi-server namespace. 428 Because client support for the fs_locations attribute is OPTIONAL, a 429 server may (but is not required to) take action to hide migration and 430 referral events from such clients by acting as a proxy, for example. 432 6.2. Trunking Discovery and Detection (to be added) 434 Trunking is a situation in which multiple distinct network addresses 435 are associated with the same NFS server instance. As a matter of 436 convenience, we say that two network addresses connected to the same 437 NFS server instance are server-trunkable. Section 5.4 of [RFC7931] 438 explains why NFSv4 clients need to be aware of NFS server identity to 439 manage lease and lock state effectively when multiple connections to 440 the same server exist. 442 Trunking detection refers to a way for an NFSv4 client to confirm 443 that two independently acquired network addresses are connected to 444 the same NFSv4 server. Section 5.8 of [RFC7931] describes an 445 OPTIONAL means by which it can be determined if two network addresses 446 correspond to the same NFSv4.0 server instance. Without trunking 447 detection, an NFSv4.0 client has no other way to confirm that two 448 network addresses are server-trunkable. 450 In the particular context of NFS version 4.0, trunking detection 451 requires that the client support the Uniform Client ID String 452 approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0 453 client that supports migration or trunking detection needs to present 454 a Uniform Client ID String to all NFSv4.0 servers. If it does not do 455 so, it will be unable to perform trunking detection. 457 Trunking discovery is the process by which an NFSv4 client using a 458 host name or one of an NFSv4 server's network addresses can obtain 459 other candidate network addresses that are trunkable with it; i.e., a 460 set of addresses that might be connected to the same NFSv4 server 461 instance. An NFSv4.0 client can discover server-trunkable network 462 addresses in a number of ways: 464 o An NFS server's host name is provided either at mount time or in a 465 returned location entry. A DNS query of this host name can return 466 more than one network address. The returned network addresses are 467 candidates for trunking. 469 o Location entries returned in an fs_locations attribute can specify 470 network addresses. These network addresses are candidates for 471 trunking. 473 When there is a means of trunking detection available, an NFSv4.0 474 client can confirm that a set of network addresses correspond to the 475 same NFSv4.0 server instance and thus any of them can be used to 476 access that server. 478 6.3. Location Attributes and Connection Type Selection (to be added) 480 Because of the need to support multiple connections, clients face the 481 issue of determining the proper connection type to use when 482 establishing a connection to a server network address. The 483 fs_locations attribute provides no information to support connection 484 type selection. As a result, clients supporting multiple connection 485 types need to attempt to establish a connection on various connection 486 types until the one preferred by the client is successfully 487 established. 489 6.4. File System Replication and Trunking (as updated) 491 On first access to a file system, the client should obtain the value 492 of the set of alternative locations by interrogating the fs_locations 493 attribute. Trunking discovery and/or detection can then be applied 494 to the location entries to separate the candidate server-trunkable 495 addresses from the replica addresses that provide alternative 496 locations of the file system. Server-trunkable addresses may be used 497 simultaneously to provide higher performance through the exploitation 498 of multiple paths between client and target file system. 500 In the event that server failures, communications problems, or other 501 difficulties make continued access to the current file system 502 impossible or otherwise impractical, the client can use the 503 alternative locations as a way to maintain continued access to the 504 file system. See Section 6.6 of the current document for more 505 detail. 507 6.5. File System Migration (as updated) 509 When a file system is present and becomes absent, clients can be 510 given the opportunity to have continued access to their data at an 511 alternative location specified by the fs_locations attribute. 512 Typically, a client will be accessing the file system in question, 513 get an NFS4ERR_MOVED error, and then use the fs_locations attribute 514 to determine the new location of the data. See Section 6.6 of the 515 current document for more detail. 517 Such migration can help provide load balancing or general resource 518 reallocation. The protocol does not specify how the file system will 519 be moved between servers. It is anticipated that a number of 520 different server-to-server transfer mechanisms might be used, with 521 the choice left to the server implementer. The NFSv4 protocol 522 specifies the method used to communicate the migration event between 523 client and server. 525 When an alternative location is designated as the target for 526 migration, it must designate the same data. Where file systems are 527 writable, a change made on the original file system must be visible 528 on all migration targets. Where a file system is not writable but 529 represents a read-only copy (possibly periodically updated) of a 530 writable file system, similar requirements apply to the propagation 531 of updates. Any change visible in the original file system must 532 already be effected on all migration targets, to avoid any 533 possibility that a client, in effecting a transition to the migration 534 target, will see any reversion in file system state. 536 6.6. Interaction of Trunking, Migration, and Replication (to be added) 538 When the set of network addresses designated by a location attribute 539 changes, NFS4ERR_MOVED might or might not result. In some of the 540 cases in which NFS4ERR_MOVED is returned migration has occurred, 541 while in others there is a shift in the network addresses used to 542 access a particular file system with no migration. 544 1. When the list of network addresses is a superset of that 545 previously in effect, there is no need for migration or any other 546 sort of client adjustment. Nevertheless, the client is free to 547 use an additional address in the replacement list if that address 548 provides another path to the same server. Or, the client may 549 treat that address as it does a replica, to be used if current 550 server addresses become unavailable. 552 2. When the list of network addresses is a subset of that previously 553 in effect, immediate action is not needed if an address missing 554 in the replacement list is not currently in use by the client. 555 The client should avoid using that address in the future, whether 556 the address is for a replica or an additional path to the server 557 being used. 559 3. When an address being removed is one of a number of paths to the 560 current server, the client may continue to use it until 561 NFS4ERR_MOVED is received. This is not considered a migration 562 event unless the last available path to the server has become 563 unusable. 565 When migration does occur, multiple addresses may be in use on the 566 server previous to migration and multiple addresses may be available 567 for use on the destination server. 569 With regard to the server in use, it may be that return of 570 NFS4ERR_MOVED indicates that a particular network address is no 571 longer to be used, without implying that migration of the file system 572 to a different server is needed. Clients should not conclude that 573 migration has occurred until confirming that all network addresses 574 known to be associated with that server are not usable. 576 It should be noted that the need to defer this determination is not 577 absolute. If a client is not aware of all network addresses for any 578 reason, it may conclude that migration has occurred when it has not 579 and treat a switch to a different server address as if it were a 580 migration event. This is harmless since the use of the same server 581 via a new address will appear as a successful instance of Transparent 582 State Migration. 584 Although significant harm cannot arise from this misapprehension, it 585 can give rise to disconcerting situations. For example, if a lock 586 has been revoked during the address shift, it will appear to the 587 client as if the lock has been lost during migration, normally 588 calling for it to be recoverable via an fs-specific grace period 589 associated with the migration event. 591 With regard to the destination server, it is desirable for the client 592 to be aware of all valid network addresses that can be used to access 593 the destination server. However, there is no need for this to be 594 done immediately. Implementations can process the additional 595 location elements in parallel with normal use of the first valid 596 location entry found to access the destination. 598 Because a location attribute may include entries relating to the 599 current server, the migration destination, and possible replicas to 600 use, scanning for available network addresses could potentially be a 601 long process. To keep this process as short as possible, Servers are 602 REQUIRED to place location entries that represent addresses usable 603 with the current server or a migration target before those associated 604 with replicas. A client can then cease scanning for trunkable 605 location entries once it encounters a location element whose fs_name 606 differs from the current fs_name, or whose address is not server- 607 trunkable with the one it is currently using. 609 7. Location Entries and Server Identity Update (as updated) 611 As mentioned above, a single location entry may have a server address 612 target in the form of a DNS host name that resolves to multiple 613 network addresses, while multiple location entries may have their own 614 server address targets that reference the same server. 616 When server-trunkable addresses for a server exist, the client may 617 assume that for each file system in the namespace of a given server 618 network address, there exist file systems at corresponding namespace 619 locations for each of the other server network addresses. It may do 620 this even in the absence of explicit listing in fs_locations. Such 621 corresponding file system locations can be used as alternative 622 locations, just as those explicitly specified via the fs_locations 623 attribute. 625 8. Updates to RFC7530 Outside Section Eight 627 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 628 of [RFC7530] does not take proper account of trunking, it needs to be 629 modified by replacing the first two sentences of the description with 630 the following material: 632 The file system that contains the current filehandle object cannot 633 be accessed using the current network address. It may be 634 accessible using other network addresses connected to the same 635 server, it may have been relocated to another server, or it may 636 never have been present. 638 9. Security Considerations 640 The Security Considerations section of [RFC7530] needs the additions 641 below to properly address some aspects of trunking discovery, 642 referral, migration, and replication. 644 The possibility that requests to determine the set of network 645 addresses corresponding to a given server might be interfered with 646 or have their responses corrupted needs to be taken into account. 648 o When DNS is used to convert NFS server host names to network 649 addresses and DNSSEC [RFC4033] is not available, the validity 650 of the network addresses returned cannot be relied upon. 651 However, when the client uses RPCSEC_GSS [RFC7861] to access 652 NFS servers, it is possible for mutual authentication to detect 653 invalid server addresses. Other forms of transport layer 654 security (e.g., [RFC5246]) can also offer strong authentication 655 of NFS servers. 657 o Fetching location information SHOULD be performed using 658 RPCSEC_GSS with integrity protection, as previously explained 659 in the Security Considerations section of [RFC7530]. Making a 660 request of this sort without using strong integrity protection 661 permits corruption during transit of returned location 662 information. The client implementer needs to recognize that 663 using such information to access an NFS server without use of 664 RPCSEC_GSS (e.g., by using AUTH_SYS as defined in [RFC5531]) 665 can result in the client interacting with an unverified network 666 address that is posing as an NFSv4 server. 668 o Despite the fact that it is a REQUIREMENT of [RFC7530] that 669 "implementations" provide "support" for the use of RPCSEC_GSS, 670 it cannot be assumed that use of RPCSEC_GSS is always possible 671 between any particular client-server pair. 673 o Returning only network addresses to a client that has no 674 trusted DNS resolution service can hamper its ability to use 675 RPCSEC_GSS. 677 Therefore an NFSv4 server SHOULD present location entries that 678 correspond to file systems on other servers using only host names. 679 This enables the client to interrogate the fs_locations on the 680 destination server to obtain trunking information (as well as 681 replica information) using RPCSEC_GSS with integrity, validating 682 the host name provided while assuring that the response has not 683 been corrupted. 685 When RPCSEC_GSS is not available on an NFS server, returned 686 location information is subject to corruption during transit and 687 cannot be relied upon. In the case of a client being directed to 688 another server after NFS4ERR_MOVED, this could vitiate the 689 authentication provided by the use of RPCSEC_GSS on the 690 destination. Even when RPCSEC_GSS authentication is available on 691 the destination, this server might validly represent itself as the 692 server to which the client was erroneously directed. Without a 693 way to decide wether the server is a valid one, the client can 694 only determine, using RPCSEC_GSS, that the server corresponds to 695 the host name provided, with no basis for trusting that server. 696 The client should not use such unverified location entries as a 697 basis for migration, even though RPCSEC_GSS might be available on 698 the destination server. 700 When a location attribute is fetched upon connecting with an NFSv4 701 server, it SHOULD, as stated above, be done using RPCSEC_GSS with 702 integrity protection. 704 When location information cannot be protected in transit, the 705 client can subject it to additional filtering to prevent the 706 client from being inappropriately directed. For example, if a 707 range of network addresses can be determined that assure that the 708 servers and clients using AUTH_SYS are subject to appropriate 709 constraints (such as physical network isolation and the use of 710 administrative controls within the operating systems), then 711 network adresses in this range can be used with others discarded 712 or restricted in their use of AUTH_SYS. 714 When neither integrity protection nor filtering is possible, it is 715 best for the client to ignore trunking and replica information or 716 simply not fetch the location information for these purposes. 718 To summarize considerations regarding the use of RPCSEC_GSS in 719 fetching location information, consider the following 720 possibilities for requests to interrogate location information, 721 with interrogation approaches on the referring and destination 722 servers arrived at separately: 724 o The use of RPCSEC_GSS with integrity protection is RECOMMENDED 725 in all cases, since the absence of integrity protection exposes 726 the client to the possibility of the results being modified in 727 transit. 729 o The use of requests issued without RPCSEC_GSS (e.g., using 730 AUTH_SYS), while undesirable, might be unavoidable in some 731 cases. Where the use of returned location information cannot 732 be avoided, it should be subject to filtering to eliminate 733 untrusted network addresses. The specifics will vary depending 734 on the degree of network isolation and whether the request is 735 to the referring or destination servers. 737 10. IANA Considerations 739 This document does not require actions by IANA. 741 11. References 743 11.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, 747 DOI 10.17487/RFC2119, March 1997, 748 . 750 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 751 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 752 May 2009, . 754 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 755 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 756 March 2015, . 758 [RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, 759 "NFSv4.0 Migration: Specification Update", RFC 7931, 760 DOI 10.17487/RFC7931, July 2016, 761 . 763 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 764 Memory Access Transport for Remote Procedure Call Version 765 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 766 . 768 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 769 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 770 May 2017, . 772 11.2. Informative References 774 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 775 Rose, "DNS Security Introduction and Requirements", 776 RFC 4033, DOI 10.17487/RFC4033, March 2005, 777 . 779 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 780 (TLS) Protocol Version 1.2", RFC 5246, 781 DOI 10.17487/RFC5246, August 2008, 782 . 784 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 785 "Network File System (NFS) Version 4 Minor Version 1 786 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 787 . 789 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 790 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 791 November 2016, . 793 Appendix A. Section Classification 795 All sections of this document are considered explanatory with the 796 following exceptions. 798 o Sections 5 and 6.1 are replacement sections. 800 o Section 6.2 is an additional section. 802 o Sections 6.4 and 6.5 are replacement sections. 804 o Section 6.6 is an additional section. 806 o Section 7 is a replacement section. 808 o Section 8 is an editing section. 810 o Section 9 is an additional section. 812 Acknowledgments 814 The authors wish to thank Andy Adamson, who wrote the original 815 version of this document. All the innovation in this document is the 816 result of Andy's work, while mistakes are best ascribed to the 817 current authors. 819 The editor wishes to thank Greg Marsden of Oracle for his support of 820 this work, and Rob Thurlow of Oracle for review and suggestions. 822 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 823 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 824 Working Group Secretary Thomas Haynes for their support. 826 Authors' Addresses 828 Charles Lever (editor) 829 Oracle Corporation 830 1015 Granger Avenue 831 Ann Arbor, MI 48104 832 United States of America 834 Phone: +1 248 816 6463 835 Email: chuck.lever@oracle.com 837 David Noveck 838 NetApp 839 1601 Trapelo Road 840 Waltham, MA 02451 841 United States of America 843 Phone: +1 781 572 8038 844 Email: davenoveck@gmail.com