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