<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-cel-nfsv4-mv0-trunking-update-00" updates="7530" submissionType="IETF" xml:lang="en" obsoletes="">
  <front>
    <title abbrev="NFSv4.0 Trunking Update">NFS version 4.0 Trunking Update </title>
    <author initials="C.L." surname="Lever" fullname="Charles Lever" role="editor">
      <organization abbrev="Oracle">Oracle Corporation </organization>
      <address>
        <postal>
          <street>1015 Granger Avenue</street>
          <city>Ann Arbor</city>
          <region>MI</region>
          <code>48104</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 248 816 6463</phone>
        <email>chuck.lever@oracle.com</email>
      </address>
    </author>
    <author initials="D.N." surname="Noveck" fullname="David Noveck">
      <organization>NetApp </organization>
      <address>
        <postal>
          <street>1601 Trapelo Road</street>
          <city>Waltham</city>
          <region>MA</region>
          <code>02451</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 781 572 8038</phone>
        <email>davenoveck@gmail.com</email>
      </address>
    </author>
    <date/>
    <area>Transport</area>
    <workgroup>Network File System Version 4</workgroup>
    <abstract>
      <t>Location-related attributes in NFS version 4.0 are used to support the migration and replication of server file systems.  In this document, we describe an additional use for these attributes as a mechanism to enable client discovery of an NFS version 4.0 server's trunking capabilities.  The interaction of trunking with migration and replication is also clarified.  This document updates RFC 7530.  </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
      <t>The NFS version 4.0 specification <xref target="RFC7530" pageno="false" format="default"/> defines a migration feature which enables the transfer of a file system from one server to another without disruption of client activity.  There were a number of issues with the original definition of this feature, which are described in <xref target="I-D.ietf-nfsv4-migration-issues" pageno="false" format="default"/>, and are resolved with the publication of <xref target="RFC7931" pageno="false" format="default"/>.  </t>
      <t>The latter document introduces into NFS version 4.0 a means of trunking detection as a means to determine whether two network addresses are connected to the same NFS version 4.0 server instance.  Even though migration recovery is closely related to handling trunking, the NFS version 4.0 specification remains without a complete discussion of trunking.  </t>
      <t>File system migration, replication, and trunking discovery are distinct protocol features.  However, it is not appropriate to treat each of these features in isolation.  For example, client migration recovery processing needs to deal with the possibility of multiple server addresses in fs_location attributes.  In addition, fs_location attributes, which both provide trunking-related and replication information, may change over repeated retrievals, requiring an integrated description of how clients are to deal with such changes.  </t>
      <t>In addition, the NFS version 4.0 specification needs clarification as to how the client is to respond to changes in trunking arrangements when migration occurs, as well as in some other important cases.  All of the issues discussed in the current document relate to the interpretation of the fs_locations attribute and to the proper client and server handling of changes in fs_location attribute values.  </t>
    </section>
    <section title="Requirements Language" toc="default">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" pageno="false" format="default"/> <xref target="RFC8174" pageno="false" format="default"/> when, and only when, they appear in all capitals, as shown here.  </t>
    </section>
    <section title="Preliminaries" anchor="sec:preliminaries" toc="default">
      <section title="Terminology" anchor="sec:terminology" toc="default">
        <t>Most of the terms related to handling location attributes are appropriately defined in <xref target="sec:eight-one" pageno="false" format="default"/> below.  However, there are a few terms used outside that context that require further elucidation.  Particularly important is the distinction between trunking detection and trunking discovery.  The definitions we present are applicable to all minor versions of NFSv4, but we put particular emphasis on how these terms apply to NFS version 4.0.  <list style="symbols"><t>Trunking detection refers to ways of determining whether two unique network addresses are associated with the same NFSv4 server instance.  The means available to make this determination depends on the protocol version and, in some cases, on the client implementation.  <vspace blankLines="1"/> In the case of NFS version 4.0, the means to be used are described in <xref target="RFC7931" pageno="false" format="default"/> and require use of the Uniform Client String approach to be effective.  This is in contrast to later minor versions for which the means of trunking detection is described by <xref target="RFC5661" pageno="false" format="default"/> and is available to every client.  </t><t>Trunking discovery is a process by which a client, accessing one server network address, can obtain other addresses that are associated with the same server instance.  Typically it builds on a trunking detection facility by providing one or more methods by which candidate addresses are made available to the client, who then uses trunking detection to appropriately filter them.  <vspace blankLines="1"/> Trunking discovery is not described in <xref target="RFC7530" pageno="false" format="default"/> and no description of it is provided in <xref target="RFC7931" pageno="false" format="default"/>.  </t></list> </t>
      </section>
      <section title="Document Organization" anchor="sec:document-organization" toc="default">
        <t>The sections of the current document are divided into four types based on how they relate to the eventual updating of the NFS verion 4.0 specification.  Once this update is published, NFS version 4.0 will be specified by multiple documents that need to be read together, until such time as a consolidated replacement specification is produced.  <list style="symbols"><t>The base specification <xref target="RFC7530" pageno="false" format="default"/>.  </t><t>The migration-related update <xref target="RFC7931" pageno="false" format="default"/>.  </t><t>An eventual RFC based on the current document.  </t></list> </t>
        <t>The section types are as follows.  See <xref target="sec:section-classification" pageno="false" format="default"/> for a classification of each section of the current document.  <list style="symbols"><t>An explanatory section does not contain any material that is meant to update the specification of NFS version 4.0.  Such sections may contain explanation about why and how changes are to be done, but do not include any text that is to update <xref target="RFC7530" pageno="false" format="default"/> or appear in an eventual consolidated document.  </t><t>A replacement section contains text that is to replace and thus supersede text within <xref target="RFC7530" pageno="false" format="default"/> and then appear in an eventual consolidated document.  </t><t>An additional section contains text which, although not replacing anything in <xref target="RFC7530" pageno="false" format="default"/>, will be part of the specification of NFS version 4.0 and will be expected to be part of an eventual consolidated document.  </t><t>An editing section contains some text that replaces text within <xref target="RFC7530" pageno="false" format="default"/>, although the entire section will not consist of such text and will include other text as well.  Such sections make relatively minor adjustments in the existing NFS version 4.0 specification which are expected to be reflected in an eventual consolidated document.  Generally such replacement text appears as a quotation, possibly taking the form of an indented set of paragraphs.  </t></list> </t>
      </section>
      <section title="Document Goals" anchor="sec:document-goals" toc="default">
        <t>The goals of this document are as follows: <list style="symbols"><t>To provide NFS version 4.0 with a means of trunking discovery, compatible with the means of trunking detection introduced by <xref target="RFC7931" pageno="false" format="default"/>.  </t><t>To describe how NFS version 4.0 clients are to handle the presence of multiple network addresses associated to the same server, when recovering from a replication and migration event.  </t><t>To describe how NFS version 4.0 clients are to handle changes in the location attributes returned, including those that indicate changes in the responding NFS version 4.0 server's trunking configuration.  </t></list> </t>
        <t>The current document pursues these goals by presenting a set of updates to <xref target="RFC7530" pageno="false" format="default"/> as summarized in <xref target="sec:overview-of-7530-sec8-changes" pageno="false" format="default"/> below.  </t>
      </section>
    </section>
    <section title="Overview of changes in RFC7530 Section 8" anchor="sec:overview-of-7530-sec8-changes" toc="default">
      <t>With a few small exceptions (see below), all of the updates to <xref target="RFC7530" pageno="false" format="default"/> to provide support for trunking using the fs_locations attribute apply to Section 8 of that document, entitled "Multi-Server Namespace".  <list style="symbols"><t><xref target="sec:eight-one" pageno="false" format="default"/> replaces Section 8.1 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "Location Attributes".  This section has been reorganized and extended to explicitly allow the use of fs_locations to provide trunking-related information that appropriately interacts with the migration, replication and referral features of fs_location.  Terminology used to describe the interactions is added.  </t><t><xref target="sec:eight-four" pageno="false" format="default"/> updates Section 8.4 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "Uses of Location Information".  This section comprises the bulk of the updates.  Each paragraph of Section 8.4 and its sub-sections has been reviewed to clarify the provision of trunking-related information using the fs_locations attribute.  <list style="symbols"><t><xref target="sec:location-intro" pageno="false" format="default"/> replaces the introductory material within Section 8.4 of <xref target="RFC7530" pageno="false" format="default"/>.  </t><t><xref target="sec:trunking-discovery" pageno="false" format="default"/> is to be added after the introductory material within Section 8.4 of <xref target="RFC7530" pageno="false" format="default"/>.  </t><t><xref target="sec:replication" pageno="false" format="default"/> replaces Section 8.4.1 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "File System Replication".  </t><t><xref target="sec:migration" pageno="false" format="default"/> replaces Section 8.4.2 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "File System Migration".  </t><t><xref target="sec:trunking-and-migration" pageno="false" format="default"/> is to be added after the updated Section 8.4.2 of <xref target="RFC7530" pageno="false" format="default"/>.  </t></list> </t><t><xref target="sec:eight-five" pageno="false" format="default"/> replaces Section 8.5 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "Location Entries and Server Identity".  The last paragraph of the existing section has been removed.  </t><t>A small set of updates outside Section 8 of <xref target="RFC7530" pageno="false" format="default"/> are presented in <xref target="sec:other-updates" pageno="false" format="default"/>.  </t><t><xref target="sec:security-considerations" pageno="false" format="default"/> introduces additional security considerations that are to be added to those within Section 19 of <xref target="RFC7530" pageno="false" format="default"/>, entitled "Security Considerations".  </t></list> </t>
    </section>
    <section title="Location Attributes (as Updated)" anchor="sec:eight-one" toc="default">
      <t>The fs_locations RECOMMENDED attribute allows specification of file system locations where the data corresponding to a given file system may be accessed.  This attribute represents such file system instances as a server address target (as either a DNS name representing one or more IP addresses, or a literal IP address) together with the path of that file system within the associated single-server namespace.  Individual fs_location entries can express trunkable addresses, locations of file system replicas on other servers, migration targets, or pure referrals.  </t>
      <t>We introduce the following terminology: <list style="symbols"><t>Two network addresses connected to the same server are said to be server-trunkable.  </t><t>Trunking detection refers to ways of deciding whether two specific network addresses are connected to the same NFSv4 server.  </t><t>Trunking discovery is a process by which a client using one network address can obtain other addresses that are server-trunkable with it.  </t></list> </t>
      <t>Regarding terminology relating to attributes used in trunking discovery and other multi-server namespace features: <list style="symbols"><t>Location entries (fs_location4, defined in <xref target="RFC7530" pageno="false" format="default"/> Section 2.2.6) are the individual file system locations in the fs_locations attribute (defined in <xref target="RFC7530" pageno="false" format="default"/> Section 2.2.7).  </t><t>Location elements are derived from location entries.  If a location entry specifies an IP address there is only a single corresponding location element.  Location entries that contain a host name are resolved by the client, and may result in one or more location elements.  </t><t>All location elements consist of a location address, which is the IP address of an interface to a server, and an fs name, which is the location of the file system within the server's pseudo-fs.  </t><t>The fs name is empty if the server has no pseudo-fs and only a single exported file system at the root filehandle.  </t></list> </t>
    </section>
    <section title="Updates to RFC7530 Section 8.4 (Uses of Location Information)" anchor="sec:eight-four" toc="default">
      <t>The subsections below provide replacement sections for existing sections within Section 8.4 of <xref target="RFC7530" pageno="false" format="default"/> or new sub-sections to be added to that section.  </t>
      <section title="Introduction to uses of Location Information (as updated)" anchor="sec:location-intro" toc="default">
        <t>The location-bearing attribute fs_locations provides, together with the possibility of absent file systems, a number of important facilities in providing reliable, manageable, and scalable data access.  </t>
        <t>When a file system is present, these attributes can provide alternative locations, to be used to access the same data, in the event of server failures, communications problems, or other difficulties that make continued access to the current file system impossible or otherwise impractical. Provision of such alternative locations is referred to as "replication".  </t>
        <t>One type of replication is trunking, where the location entries do not in fact reside on different servers, but are instead different network paths to the same server.  A client may use location elements simultaneously to provide higher-performance access to the target file system.  The client utilizes trunking detection and/or discovery (see <xref target="sec:trunking-discovery" pageno="false" format="default"/>) to determine if two location elements are server-trunkable.  </t>
        <t>When a file system is present and subsequently becomes absent, clients can be given the opportunity to have continued access to their data, at an alternative location.  Transfer of the file system contents to the new location is referred to as "migration".  See <xref target="sec:migration" pageno="false" format="default"/> and <xref target="sec:trunking-and-migration" pageno="false" format="default"/> (of the current document) for details.  </t>
        <t>Alternative locations may be physical replicas of the file system data or, in the case of various forms of server clustering, another server providing access to the same physical file system.  The client's responsibilities in dealing with this transition depend on the specific nature of the new access path as well as how and whether data was in fact migrated.  These issues will be discussed in detail below.  </t>
        <t>Where a file system was not previously present, specification of file system location provides a means by which file systems located on one server can be associated with a namespace defined by another server, thus enabling the creation of a multi-server namespace.  A designation of such a location, in place of an absent file system, is called a "referral".  A particularly important case is that of a "pure referral", in which the absent file system has never been present on the source server.  </t>
        <t>Because client support for location-related attributes is OPTIONAL, a server may (but is not required to) take action to hide migration and referral events from such clients, by acting as a proxy, for example.  </t>
      </section>
      <section title="Trunking Discovery and Detection (to be added)" anchor="sec:trunking-discovery" toc="default">
        <t>Trunking detection refers to a way for an NFSv4 client to determine whether two independently acquired network addresses are connected to the same NFSv4 server.  Section 5.8 of <xref target="RFC7931" pageno="false" format="default"/> describes an OPTIONAL means by which it can be determined if two server network addresses correspond to the same server instance.  Without trunking detection, a client has no way to determine that two network addresses are server-trunkable.  </t>
        <t>In the context of NFS version 4.0, trunking detection requires that the client support the Uniform Client ID String approach (UCS), described in Section 5.6 of <xref target="RFC7931" pageno="false" format="default"/>.  Any NFS version 4.0 client that supports migration or trunking detection needs to present a Uniform Client ID String to all servers.  If it does not do so, it will be unable to perform trunking detection.  </t>
        <t>Trunking discovery is the process by which an NFSv4 client using one server network address can obtain other server addresses that are trunkable with it; i.e., the set of addresses connected to the same server instance.  Location entries that specify a server host name that resolves via DNS into multiple addresses provide a list of server-trunkable addresses.  </t>
        <t>An NFS version 4.0 client can discover a set of server-trunkable network addresses in a number of ways: <list style="numbers"><t>If the client is accessing a server using its host name, that host name can be resolved to one or more IP addresses using DNS.  If multiple addresses are present in the DNS query result, these addresses are server-trunkable and can be used together to access the server.  </t><t>A client connected to a server without knowledge of its host name can obtain the value of a location attribute (i.e., fs_locations).  Where a location entry within that attribute specifies a server host name, DNS can be used to obtain one or more network addresses corresponding to that host name.  In cases in which one of those addresses is the address being used, the other addresses corresponding to that host name are server-trunkable and can be used to access the server.  </t><t>A client can obtain the value of an fs_location attribute and use location entries that specify network addresses.  When there is a means of trunking detection available all of addresses that are determined to correspond to the same server can be used to access that server.  </t></list> </t>
      </section>
      <section title="File System Replication and Trunking (as updated)" anchor="sec:replication" toc="default">
        <t>On first access to a file system, the client should obtain the value of the set of alternative locations by interrogating the fs_locations attribute.  Trunking discovery and/or detection can then be applied to the location entries to separate the potential server-trunkable addresses from the replica addresses that provide alternative locations of the file system.  Server-trunkable addresses may be used simultaneously to provide higher performance through the exploitation of multiple paths between client and target file system.  </t>
        <t>In the event that server failures, communications problems, or other difficulties make continued access to the current file system impossible or otherwise impractical, the client can use the alternative locations as a way to get continued access to its data.  See <xref target="sec:trunking-and-migration" pageno="false" format="default"/> (of the current document) for more detail.  </t>
      </section>
      <section title="File System Migration (as updated)" anchor="sec:migration" toc="default">
        <t>When a file system is present and becomes absent, clients can be given the opportunity to have continued access to their data, at an alternative location, as specified by the fs_locations attribute.  Typically, a client will be accessing the file system in question, get an NFS4ERR_MOVED error, and then use the fs_locations attribute to determine the new location of the data.  See <xref target="sec:trunking-and-migration" pageno="false" format="default"/> (of the current document) for more detail.  </t>
        <t>Such migration can be helpful in providing load balancing or general resource reallocation.  The protocol does not specify how the file system will be moved between servers.  It is anticipated that a number of different server-to-server transfer mechanisms might be used, with the choice left to the server implementer.  The NFSv4 protocol specifies the method used to communicate the migration event between client and server.  </t>
        <t>When an alternative location is designated as the target for migration, it must designate the same data.  Where file systems are writable, a change made on the original file system must be visible on all migration targets.  Where a file system is not writable but represents a read-only copy (possibly periodically updated) of a writable file system, similar requirements apply to the propagation of updates.  Any change visible in the original file system must already be effected on all migration targets, to avoid any possibility that a client, in effecting a transition to the migration target, will see any reversion in file system state.  </t>
      </section>
      <section title="Interaction of Trunking, Migration, and Replication (to be added)" anchor="sec:trunking-and-migration" toc="default">
        <!--NOTE: this section is (almost) verbatim from Section 3.2.2 of draft-ietf-nfsv4-migration-issues-13 -->
        <t>When the set of network addresses designated by a location attribute changes, NFS4ERR_MOVED might or might not result.  In some of the cases in which NFS4ERR_MOVED is returned migration has occurred, while in others there is a shift in the network addresses used to access a particular file system (no migration occurred).  <list style="numbers"><t>When the list of network addresses is a superset of that previously in effect, there is no need for migration or any other sort of client adjustment.  Nevertheless, the client is free to use an additional address in the replacement list if that address provides another path to the same server.  Or, the client may use an additional address in the replacement list if server addresses it is currently using become unavailable without warning.  </t><t>When the list of networks addresses is a subset of that previously in effect, immediate action is not needed if an address missing in the replacement list is not currently in use by the client.  The client should avoid using it in the future, whether the address is for a replica or a potential additional path to the server being used.  </t><t>When an address being removed is one of a number of paths to the current server, the client may continue to use it until NFS4ERR_MOVED is received.  This is not considered a migration event unless the last available path to the server has become unusable.  </t></list> </t>
        <t>When migration does occur, multiple addresses may be in use on the server previous to migration and multiple addresses may be available for use on the destination server.  </t>
        <t>With regard to the server in use, it may be that return of NFS4ERR_MOVED indicates that a particular network address is no longer to be used, without implying that migration of the file system to a different server is needed. In light of this possibility, clients are best off not concluding that migration has occurred until concluding that all the network addresses known to be associated with the server are not usable.  </t>
        <t>It should be noted that the need to defer this determination is not absolute.  If a client is not aware of all network addresses for any reason, it may conclude that migration has occurred when it has not and treat a switch to a different server address as if it were a migration event.  This is generally harmless since the use of the same server via a new address will appear as a successful Transparent State Migration.  </t>
        <t>While significant harm will not arise from this misapprehension, it can give rise to disconcerting situations.  For example, if a lock has been revoked during the address shift, it will appear to the client as if the lock has been lost during migration, normally calling for it to be recoverable via an fs-specific grace period associated with the migration event.  </t>
        <t>With regard to the destination server, it is desirable for the client to be aware of all the valid network addresses that can be used to access the destination server.  However, there is no need for this to be done immediately.  Implementations can process the additional location elements in parallel with normal use of the first valid location entry found to access the destination.  </t>
      </section>
    </section>
    <section title="Location Entries and Server Identity Update (as updated)" anchor="sec:eight-five" toc="default">
      <t>As mentioned above, a single location entry may have a server address target in the form of a DNS name that may represent multiple IP addresses, while multiple location entries may have their own server address targets that reference the same server.  </t>
      <t>When server-trunkable addresses for a server exist, the client may assume that for each file system in the namespace of a given server network address, there exist file systems at corresponding namespace locations for each of the other server network addresses.  It may do this even in the absence of explicit listing in fs_locations.  Such corresponding file system locations can be used as alternative locations, just as those explicitly specified via the fs_locations attribute.  </t>
    </section>
    <section title="Updates to RFC7530 Outside Section Eight" anchor="sec:other-updates" toc="default">
      <t>Since the existing description of NFS4ERR_MOVED (in Section 13.1.2.4 of <xref target="RFC7530" pageno="false" format="default"/>) does not take proper account of trunking, it needs to be modified by replacing the first two sentences of the description with the following material: <list style="none"><t>The file system that contains the current filehandle object cannot be accessed using the current network address.  It may be accessible using other network addresses connected to the same server, it may have been relocated to another server, or it may never have been present.  </t></list> </t>
    </section>
    <section title="Security Considerations" anchor="sec:security-considerations" toc="default">
      <t>The Security Considerations section of <xref target="RFC7530" pageno="false" format="default"/> needs the additions below to properly address some aspects of trunking discovery, referral, migration and replication.  <list style="none"><t>The possibility that requests to determine the set of network addresses corresponding to a given server might be interfered with or have their responses corrupted needs to be taken into account.  <list style="format o  "><t>When DNS is used to convert NFS server host names to network addresses and DNSSEC <xref target="RFC4033" pageno="false" format="default"/> is not available, the validity of the network addresses returned cannot be relied upon.  However, when the client uses RPCSEC_GSS <xref target="RFC7861" pageno="false" format="default"/> to access NFS servers, it is possible for mutual authentication to detect invalid server addresses.  Other forms of transport layer security (e.g., <xref target="RFC5246" pageno="false" format="default"/>) can also offer strong authentication of NFS servers.  </t><t>Fetching location information SHOULD be performed using RPCSEC_GSS with integrity protection, as previously explained in the Security Considerations section of <xref target="RFC7530" pageno="false" format="default"/>.  Making a request of this sort without using strong integrity protection permits corruption during transit of returned location information.  The client implementer needs to recognize that using such information to access an NFS server without use of RPCSEC_GSS (e.g., by using AUTH_SYS) can result in the client interacting with an unverified network address that is posing as an NFS server.  </t><t>Despite the fact that it is a REQUIREMENT of <xref target="RFC7530" pageno="false" format="default"/> that "implementations" provide "support" for use of RPCSEC_GSS, it cannot be assumed that use of RPCSEC_GSS is always available between any particular client-server pair.  </t><t>Returning only network addresses to a client with no trusted DNS resolution service can hamper its ability to use RPCSEC_GSS.  </t></list> </t><t>Therefore an NFS server SHOULD present location entries that correspond to file systems on other servers using only host names.  This enables the client to interrogate the fs_locations on the destination server to obtain trunking information (as well as replica information) using RPCSEC_GSS with integrity, validating the name provided while assuring that the response has not been corrupted.  </t><t>When RPCSEC_GSS is not available on an NFS server, returned location information is subject to corruption during transit and cannot be relied upon.  In the case of a client being directed to another server after NFS4ERR_MOVED, this could vitiate the authentication provided by the use of RPCSEC_GSS, since the destination server can represent itself as the server to which the client was erroneously directed.  [ cel: this is still confusing. ] </t><t>When a location attribute is fetched upon connecting with an NFS server, it is best for the client to ignore trunking and replica information when RPCSEC_GSS with integrity protection cannot be used.  [ cel: why then fetch location information in this case? ] [ cel: should this be normative advice? ] </t><t>When location information cannot be verified, it can be subjected to additional filtering to prevent the client from being inappropriately directed.  [ cel: why can't filtering be used in the previous paragraph? ] </t><t>To summarize considerations regarding the use of RPCSEC_GSS in fetching location information, consider the following possibilities for requests to interrogate location information, with interrogation approaches on the referring and destination servers arrived at separately: <list style="format o  "><t>The use of RPCSEC_GSS with integrity protection is RECOMMENDED in all cases, since the absence of integrity protection exposes the client to the possibility of the results being modified in transit.  </t><t>The use of RPCSEC_GSS without integrity protection to fetch location information SHOULD NOT be attempted.  In cases of migration or referral, this applies both to the referring and destination servers.  [ cel: how is this normatively different than the first bullet? ] </t><t>The use of requests issued without RPCSEC_GSS (e.g., using AUTH_SYS), while undesirable, might be unavoidable in some cases.  Unprotected returned location information should be subject to filtering to eliminate the possibility that the client would treat an invalid address as if it were a trusted NFSv4 server.  The specifics will vary depending on the degree of network isolation and whether the request is to the referring or destination servers.  </t></list> </t></list> </t>
    </section>
    <section title="IANA Considerations" anchor="sec:iana-considerations" toc="default">
      <t>This document does not require actions by IANA.  </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC7530" target="https://www.rfc-editor.org/info/rfc7530">
        <front>
          <title>Network File System (NFS) Version 4 Protocol</title>
          <author initials="T." surname="Haynes" fullname="T. Haynes" role="editor">
            <organization/>
          </author>
          <author initials="D." surname="Noveck" fullname="D. Noveck" role="editor">
            <organization/>
          </author>
          <date year="2015" month="March"/>
          <abstract>
            <t>The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813).  Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added.  Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.</t>
            <t>This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7530"/>
        <seriesInfo name="DOI" value="10.17487/RFC7530"/>
      </reference>
      <reference anchor="RFC7931" target="https://www.rfc-editor.org/info/rfc7931">
        <front>
          <title>NFSv4.0 Migration: Specification Update</title>
          <author initials="D." surname="Noveck" fullname="D. Noveck" role="editor">
            <organization/>
          </author>
          <author initials="P." surname="Shivam" fullname="P. Shivam">
            <organization/>
          </author>
          <author initials="C." surname="Lever" fullname="C. Lever">
            <organization/>
          </author>
          <author initials="B." surname="Baker" fullname="B. Baker">
            <organization/>
          </author>
          <date year="2016" month="July"/>
          <abstract>
            <t>The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients.  Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7931"/>
        <seriesInfo name="DOI" value="10.17487/RFC7931"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
    <references title="Informative References">
      <reference anchor="I-D.ietf-nfsv4-migration-issues">
        <front>
          <title>NFSv4 Migration and Trunking: Implementation and Specification Issues</title>
          <author initials="D" surname="Noveck" fullname="David Noveck">
            <organization/>
          </author>
          <author initials="P" surname="Shivam" fullname="Piyush Shivam">
            <organization/>
          </author>
          <author initials="C" surname="Lever" fullname="Chuck Lever">
            <organization/>
          </author>
          <author initials="B" surname="Baker" fullname="Bill Baker">
            <organization/>
          </author>
          <date month="May" day="16" year="2017"/>
          <abstract>
            <t>This document discusses a range of implementation and specification issues concerning features related to the use of location-related attributes in NFSv4.  These include migration, which transfers responsibility for a file system from one server to another, and trunking which deals with the discovery and control of the set of network addresses to use to access a file system.  The focus of the discussion, which relates to multiple minor versions, is on providing appropriate clarification and correction of existing specifications.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-nfsv4-migration-issues-13"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-migration-issues-13.txt"/>
      </reference>
      <reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033">
        <front>
          <title>DNS Security Introduction and Requirements</title>
          <author initials="R." surname="Arends" fullname="R. Arends">
            <organization/>
          </author>
          <author initials="R." surname="Austein" fullname="R. Austein">
            <organization/>
          </author>
          <author initials="M." surname="Larson" fullname="M. Larson">
            <organization/>
          </author>
          <author initials="D." surname="Massey" fullname="D. Massey">
            <organization/>
          </author>
          <author initials="S." surname="Rose" fullname="S. Rose">
            <organization/>
          </author>
          <date year="2005" month="March"/>
          <abstract>
            <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4033"/>
        <seriesInfo name="DOI" value="10.17487/RFC4033"/>
      </reference>
      <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author initials="T." surname="Dierks" fullname="T. Dierks">
            <organization/>
          </author>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2008" month="August"/>
          <abstract>
            <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5246"/>
        <seriesInfo name="DOI" value="10.17487/RFC5246"/>
      </reference>
      <reference anchor="RFC5661" target="https://www.rfc-editor.org/info/rfc5661">
        <front>
          <title>Network File System (NFS) Version 4 Minor Version 1 Protocol</title>
          <author initials="S." surname="Shepler" fullname="S. Shepler" role="editor">
            <organization/>
          </author>
          <author initials="M." surname="Eisler" fullname="M. Eisler" role="editor">
            <organization/>
          </author>
          <author initials="D." surname="Noveck" fullname="D. Noveck" role="editor">
            <organization/>
          </author>
          <date year="2010" month="January"/>
          <abstract>
            <t>This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently.  Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS).  NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol.  Thus, this document neither updates nor obsoletes RFC 3530.  NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0.  Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5661"/>
        <seriesInfo name="DOI" value="10.17487/RFC5661"/>
      </reference>
      <reference anchor="RFC7861" target="https://www.rfc-editor.org/info/rfc7861">
        <front>
          <title>Remote Procedure Call (RPC) Security Version 3</title>
          <author initials="A." surname="Adamson" fullname="A. Adamson">
            <organization/>
          </author>
          <author initials="N." surname="Williams" fullname="N. Williams">
            <organization/>
          </author>
          <date year="2016" month="November"/>
          <abstract>
            <t>This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS).  This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings.  This document updates RFC 5403.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7861"/>
        <seriesInfo name="DOI" value="10.17487/RFC7861"/>
      </reference>
    </references>
    <section title="Section Classification" anchor="sec:section-classification" toc="default">
      <t>All sections of this document are considered explanatory with the following exceptions.  <list style="symbols"><t>Sections <xref target="sec:eight-one" format="counter" pageno="false"/> and <xref target="sec:location-intro" format="counter" pageno="false"/> are replacement sections.  </t><t><xref target="sec:trunking-discovery" pageno="false" format="default"/> is an additional section.  </t><t>Sections <xref target="sec:replication" format="counter" pageno="false"/> and <xref target="sec:migration" format="counter" pageno="false"/> are replacement sections.  </t><t><xref target="sec:trunking-and-migration" pageno="false" format="default"/> is an additional section.  </t><t><xref target="sec:eight-five" pageno="false" format="default"/> is a replacement section.  </t><t>Section <xref target="sec:other-updates" format="counter" pageno="false"/> is an editing section.  </t><t>Section <xref target="sec:security-considerations" format="counter" pageno="false"/> is an additional section.  </t></list> </t>
    </section>
    <section title="Acknowledgments" numbered="no" toc="default">
      <t>The authors wish to thank Andy Adamson, who wrote the original version of this document.  All the innovation in this document is the result of Andy's work, while mistakes are best ascribed to the current authors.  </t>
      <t>The editor wishes to thank Greg Marsden of Oracle for his support of this work, and Rob Thurlow of Oracle for review and suggestions.  </t>
      <t>Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chair Spencer Shepler, and NFSV4 Working Group Secretary Thomas Haynes for their support.  </t>
    </section>
  </back>
</rfc>
