Internet Engineering Task Force (IETF) C. Lever, Ed.
Request for Comments: 8587 Oracle
Updates: 7530 D. Noveck
Category: Standards Track NetApp
ISSN: 2070-1721 May 2019
Internet Engineering Task Force (IETF) C. Lever, Ed.
Request for Comments: 8587 Oracle
Updates: 7530 D. Noveck
Category: Standards Track NetApp
ISSN: 2070-1721 May 2019
NFS Version 4.0 Trunking Update
NFS 4.0版中继更新
Abstract
摘要
In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.
在NFS版本4.0中，fs_locations属性通知客户端文件系统的备用位置。NFS 4.0版客户端可以使用此信息处理服务器文件系统的迁移和复制。本文档介绍NFS 4.0版客户端如何也可以使用此信息来发现NFS 4.0版服务器的中继功能。本文件更新了RFC 7530。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8587.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8587.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
5. Changes within Section 8 of RFC 7530 . . . . . . . . . . . . 7
5.1. Updated Section "Location Attributes"
(Currently Section 8.1) . . . . . . . . . . . . . . . . . 8
5.2. Updates to "Uses of Location Information"
(Currently Section 8.4) . . . . . . . . . . . . . . . . . 9
5.2.1. Updates to the Introductory Text of the Current
Section 8.4 . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. New Subsection Titled "Trunking Discovery and
Detection" (Becomes Section 8.4.1) . . . . . . . . . 11
5.2.3. New Subsection Titled "Location Attributes and
Selection of Connection Type" (Becomes Section 8.4.2) 12
5.2.4. Updated Section "File System Replication" (Becomes
Section 8.4.3 Retitled "File System Replication and
Trunking" . . . . . . . . . . . . . . . . . . . . . . 12
5.2.5. Updated Section "File System Migration" (Becomes
Section 8.4.4) . . . . . . . . . . . . . . . . . . . 13
5.2.6. New Subsection Titled "Interaction of Trunking,
Migration, and Replication" (Becomes Section 8.4.5) . 14
5.3. Updated Section "Location Entries and Server Identity"
(Section 8.5) . . . . . . . . . . . . . . . . . . . . . . 16
6. Updates to RFC 7530 outside Section 8 . . . . . . . . . . . . 16
7. Updates to the Security Considerations Section of RFC 7530 . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Updates to the References Section in RFC 7530 . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Section Classification . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
5. Changes within Section 8 of RFC 7530 . . . . . . . . . . . . 7
5.1. Updated Section "Location Attributes"
(Currently Section 8.1) . . . . . . . . . . . . . . . . . 8
5.2. Updates to "Uses of Location Information"
(Currently Section 8.4) . . . . . . . . . . . . . . . . . 9
5.2.1. Updates to the Introductory Text of the Current
Section 8.4 . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. New Subsection Titled "Trunking Discovery and
Detection" (Becomes Section 8.4.1) . . . . . . . . . 11
5.2.3. New Subsection Titled "Location Attributes and
Selection of Connection Type" (Becomes Section 8.4.2) 12
5.2.4. Updated Section "File System Replication" (Becomes
Section 8.4.3 Retitled "File System Replication and
Trunking" . . . . . . . . . . . . . . . . . . . . . . 12
5.2.5. Updated Section "File System Migration" (Becomes
Section 8.4.4) . . . . . . . . . . . . . . . . . . . 13
5.2.6. New Subsection Titled "Interaction of Trunking,
Migration, and Replication" (Becomes Section 8.4.5) . 14
5.3. Updated Section "Location Entries and Server Identity"
(Section 8.5) . . . . . . . . . . . . . . . . . . . . . . 16
6. Updates to RFC 7530 outside Section 8 . . . . . . . . . . . . 16
7. Updates to the Security Considerations Section of RFC 7530 . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Updates to the References Section in RFC 7530 . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Section Classification . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The NFS version 4.0 specification [RFC7530] defines a migration feature that 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, now resolved with the publication of [RFC7931].
NFS版本4.0规范[RFC7530]定义了一种迁移功能，该功能允许在不中断客户端活动的情况下将文件系统从一台服务器传输到另一台服务器。此功能的原始定义存在许多问题，现在通过[RFC7931]的发布解决了这些问题。
After a migration event, a client must determine whether state recovery is necessary. To do this, it needs to determine whether 1) the source and destination server addresses represent the same server instance, 2) if the client has already established a lease on the destination server for other file systems, and 3) if the destination server instance has lock state for the migrated file system.
迁移事件发生后，客户端必须确定是否需要状态恢复。为此，需要确定1）源服务器地址和目标服务器地址是否表示同一服务器实例，2）客户端是否已在目标服务器上为其他文件系统建立租约，以及3）目标服务器实例是否具有已迁移文件系统的锁定状态。
As part of addressing this need, [RFC7931] introduces trunking into NFS version 4.0 along with a trunking detection mechanism. A trunking detection mechanism enables a client to determine whether two distinct network addresses are connected to the same NFS version 4.0 server instance. Without this knowledge, a client unaware of a trunking relationship between paths it is using simultaneously is likely to become confused in ways described in [RFC7530].
作为满足这一需求的一部分，[RFC7931]在NFS 4.0版中引入中继以及中继检测机制。中继检测机制使客户端能够确定两个不同的网络地址是否连接到同一NFS 4.0版服务器实例。如果不知道这一点，不知道它同时使用的路径之间的中继关系的客户机可能会以[RFC7530]中描述的方式变得混乱。
NFSv4.1 was defined with an integral means of trunking detection, which is described in [RFC5661]. NFSv4.0 initially did not have trunking detection; it was added by [RFC7931]. Nevertheless, the use of the concept of server-trunkability is the same in both protocol versions.
NFSv4.1定义为中继检测的整体方式，如[RFC5661]所述。NFSv4.0最初没有中继检测；它是由[RFC7931]添加的。然而，在两个协议版本中，服务器中继能力概念的使用是相同的。
File system migration, replication, and referrals are distinct protocol features. However, it is not appropriate to treat each of these features in isolation. For example, recovery processing of client migration needs to deal with the possibility of multiple server addresses in a returned fs_locations attribute. In addition, the content of the fs_locations attribute, which provides both trunking-related and replication information, may change over repeated retrievals, requiring an integrated description of how clients are to deal with such changes. 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_locations attribute values.
文件系统迁移、复制和引用是不同的协议功能。但是，单独处理这些特征是不合适的。例如，客户端迁移的恢复处理需要处理在返回的fs_locations属性中存在多个服务器地址的可能性。此外，fs_locations属性的内容（提供中继相关信息和复制信息）可能会随着重复检索而更改，这需要对客户端如何处理此类更改进行集成描述。当前文档中讨论的问题与fs_locations属性的解释以及客户端和服务器对fs_locations属性值更改的正确处理有关。
Therefore, the goals of the current document are as follows:
因此，本文件的目标如下：
o To provide NFS version 4.0 with a means of finding addresses that are trunkable with a given address, i.e., trunking discovery, compatible with the means of trunking detection introduced by [RFC7931]. For an explanation of trunking detection and discovery, see Section 3.
o 为NFS版本4.0提供一种查找可与给定地址进行中继的地址的方法，即中继发现，与[RFC7931]引入的中继检测方法兼容。有关中继检测和发现的说明，请参见第3节。
o To describe how NFS version 4.0 clients are to handle the presence of multiple network addresses associated with the same server when recovering from a replication and migration event.
o 描述NFS 4.0版客户端在从复制和迁移事件恢复时如何处理与同一服务器关联的多个网络地址。
o To describe how NFS version 4.0 clients are to handle changes in the contents of returned fs_locations attributes, including those that indicate changes in the responding NFS version 4.0 server's trunking configuration.
o 描述NFS 4.0版客户端如何处理返回的fs_位置属性内容中的更改，包括指示响应NFS 4.0版服务器中继配置更改的属性。
The current document pursues these goals by presenting a set of updates to [RFC7530], as summarized in Sections 5 and 6.
本文件通过对[RFC7530]进行更新来实现这些目标，如第5节和第6节所述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Most of the terms related to handling the fs_locations attribute are appropriately defined in Section 5.1. However, there are a few terminological issues regarding the use of terms outside the context of text updating [RFC7530] that are explained in this section. Note that the definitions of trunking-related terms in Section 5.1 apply throughout this document, including in explanatory sections that will not replace any text in [RFC7530].
与处理fs_位置属性相关的大多数术语在第5.1节中有适当的定义。然而，关于文本更新[RFC7530]上下文之外术语的使用，本节将解释一些术语问题。请注意，第5.1节中中继相关术语的定义适用于本文件，包括不会取代[RFC7530]中任何文本的解释性章节。
Regarding network addresses and the handling of trunking, we use the following terminology:
关于网络地址和中继处理，我们使用以下术语：
o Each NFSv4 server is assumed to have a set of IP addresses to which NFSv4 requests may be sent by clients. These are referred to as the server's "network addresses". Access to a specific server network address might involve the use of multiple network ports, since the ports to be used for particular types of connections might be required to be different.
o 假设每个NFSv4服务器都有一组IP地址，客户端可以向这些地址发送NFSv4请求。这些被称为服务器的“网络地址”。对特定服务器网络地址的访问可能涉及使用多个网络端口，因为用于特定类型连接的端口可能需要不同。
o Clients may establish connections to NFSv4 servers via one of several connection types, supporting the NFSv4 protocol layered on top of an RPC stream transport, as described in [RFC5531], or on top of RPC-over-RDMA, as described in [RFC8166]. The combination of a server network address and a particular connection type is referred to as a "server endpoint".
o 客户机可以通过几种连接类型之一建立到NFSv4服务器的连接，如[RFC5531]所述，支持在RPC流传输之上分层的NFSv4协议，或如[RFC8166]所述，在RPC over RDMA之上分层的NFSv4协议。服务器网络地址和特定连接类型的组合称为“服务器端点”。
o Each network address, when combined with a pathname providing the location of a file system root directory relative to the associated server root filehandle, defines a file system network access path.
o 每个网络地址与提供文件系统根目录相对于关联服务器根文件句柄的位置的路径名组合时，定义文件系统网络访问路径。
o Two network addresses connected to the same server are said to be server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 recognizes only a single type of trunking relationship between addresses.
o 连接到同一台服务器的两个网络地址称为可中继服务器。与后续的NFSv4次要版本不同，NFSv4.0只识别地址之间单一类型的中继关系。
Discussion of the term "replica" is complicated for a number of reasons. Even though the term is used in explaining the issues in [RFC7530] that need to be addressed in the current document, a full explanation of this term requires explanation of related terms connected to the fs_locations attribute, which is provided in Section 5.1 of the current document.
由于许多原因，“复制品”一词的讨论很复杂。尽管该术语用于解释[RFC7530]中需要在当前文档中解决的问题，但对该术语的完整解释需要解释与fs_locations属性相关的术语，该属性在当前文档第5.1节中提供。
The term is also used in previous documents about NFSv4.0 (i.e., [RFC7530] and [RFC7931]) with a meaning different from that in the current document. In these documents, each replica is identified by a single network access path. However, in the current document, a set of network access paths that have server-trunkable network addresses and the same root-relative file system pathname is considered to be a single replica with multiple network access paths. Although [RFC7931] enables an NFSv4.0 client to determine whether two network addresses are server-trunkable, it never describes the addresses as connected to a single replica, in effect leaving the approach established in [RFC7530].
该术语也在先前关于NFSv4.0的文件（即[RFC7530]和[RFC7931]）中使用，其含义与当前文件中的含义不同。在这些文档中，每个副本都由单个网络访问路径标识。但是，在当前文档中，具有服务器可中继网络地址和相同根相对文件系统路径名的一组网络访问路径被视为具有多个网络访问路径的单个副本。尽管[RFC7931]使NFSv4.0客户端能够确定两个网络地址是否可用于服务器中继，但它从未将地址描述为连接到单个副本，实际上保留了[RFC7530]中建立的方法。
Note that this document, except when explaining problems in [RFC7530], always uses the new definition, including in text intended to replace existing sections of [RFC7530].
请注意，除解释[RFC7530]中的问题外，本文件始终使用新定义，包括替换[RFC7530]现有章节的文本。
The sections of the current document are divided into four types based on how they relate to the eventual updating of the NFS version 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.
根据与最终更新NFS 4.0版规范的关系，当前文档的各部分分为四种类型。发布此更新后，需要一起阅读的多个文档将指定NFS版本4.0，直到生成统一的替换规范。
o The base specification [RFC7530]
o 基本规范[RFC7530]
o The migration-related update [RFC7931]
o 与迁移相关的更新[RFC7931]
o This document [RFC8587]
o 本文件[RFC8587]
The section types are as follows. See Appendix A for a classification of each section of the current document.
截面类型如下所示。有关当前文件各部分的分类，请参见附录A。
o An explanatory section does not contain any material that is meant to update the specification of NFS version 4.0. Such sections may contain an explanation about why and how changes are to be made, but they do not include any text that is to update [RFC7530] or appear in an eventual consolidated document.
o 解释部分不包含任何旨在更新NFS 4.0版规范的材料。这些章节可能包含关于变更原因和方式的解释，但不包括任何要更新[RFC7530]或出现在最终合并文档中的文本。
o A replacement section contains text that is to replace and thus supersede text within [RFC7530] and then appear in an eventual consolidated document. The titles of the replacement sections indicate what section of [RFC7530] is to be replaced.
o 替换部分包含要替换的文本，从而取代[RFC7530]中的文本，然后出现在最终的合并文档中。替换章节的标题说明了要替换[RFC7530]的哪个章节。
o An additional section contains text that, although not replacing anything in [RFC7530], will be part of the specification of NFS version 4.0 and will be expected to be part of an eventual consolidated document. The titles of the additional sections provide an indication of where the new section would appear when consolidated with [RFC7530].
o 另一节包含的文本虽然没有取代[RFC7530]中的任何内容，但将成为NFS 4.0版规范的一部分，并有望成为最终合并文档的一部分。附加章节的标题说明了与[RFC7530]合并时新章节将出现的位置。
o An editing section contains some text that replaces text within [RFC7530], 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.
o 编辑部分包含一些替换[RFC7530]中文本的文本，尽管整个部分不包含此类文本，也将包含其他文本。这些章节对现有的NFS版本4.0规范进行了相对较小的调整，预计将在最终的合并文档中反映出来。通常，此类替换文本以引用的形式出现，可能采用缩进段落集的形式。
Additional and replacement sections sometimes contain references to the "current document" by which RFC 8587 is meant. When those sections are incorporated in a consolidated document, those references will need to be updated to refer to the appropriate sections in that new document.
附加和替换部分有时包含对“当前文件”的引用，RFC 8587的含义是“当前文件”。当这些章节纳入合并文件时，需要更新这些参考资料，以参考新文件中的适当章节。
Most of the updates to [RFC7530] that provide support for trunking using the fs_locations attribute apply to Section 8 ("Multi-Server Namespace") of that document. In the following list, the replacing section refers to its numbering in this document.
[RFC7530]的大多数更新都支持使用fs_locations属性进行中继，这些更新适用于该文档的第8节（“多服务器名称空间”）。在以下列表中，替换部分指本文件中的编号。
o Section 5.1 replaces Section 8.1 ("Location Attributes") of [RFC7530]. The text in the original 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_locations. Terminology used to describe the interactions is added.
o 第5.1节取代[RFC7530]第8.1节（“位置属性”）。原始部分中的文本已重新组织和扩展，以明确允许使用fs_位置来提供与中继相关的信息，从而与fs_位置的迁移、复制和引用功能进行适当的交互。添加了用于描述交互的术语。
o Section 5.2 updates Section 8.4 ("Uses of Location Information") of [RFC7530]. This section comprises the bulk of the updates. Each paragraph of Section 8.4 and its subsections have been reviewed to clarify the provision of trunking-related information using the fs_locations attribute.
o 第5.2节更新了[RFC7530]第8.4节（“位置信息的使用”）。本节包含大部分更新。已审查第8.4节及其各小节的每一段，以澄清使用fs_位置属性提供中继相关信息的情况。
* Section 5.2.1 replaces the introductory material within Section 8.4 of [RFC7530], i.e., the material within Section 8.4 exclusive of subsections.
* 第5.2.1节取代了[RFC7530]第8.4节中的介绍性材料，即第8.4节中的材料，不包括小节。
* Section 5.2.2 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.1.
* 在[RFC7530]更新的第8.4.1节之前，将第5.2.2节添加为第8.4节的新小节。在合并文件中，它将显示为第8.4.1节。
* Section 5.2.3 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.2.
* 在[RFC7530]更新的第8.4.1节之前，第5.2.3节将作为第8.4节的新小节添加。在合并文件中，它将显示为第8.4.2节。
* Section 5.2.4 replaces Section 8.4.1 ("File System Replication") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.3.
* 第5.2.4节取代[RFC7530]的第8.4.1节（“文件系统复制”）。在合并文件中，它将显示为第8.4.3节。
* Section 5.2.5 replaces Section 8.4.2 ("File System Migration") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.4.
* 第5.2.5节取代[RFC7530]的第8.4.2节（“文件系统迁移”）。在合并文件中，它将显示为第8.4.4节。
* Section 5.2.6 is to be added as a new subsection of Section 8.4 before Section 8.4.3 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.5, while the existing Section 8.3 would appear as Section 8.4.6.
* 在[RFC7530]第8.4.3节之前，将第5.2.6节添加为第8.4节的新小节。在合并文件中，它将显示为第8.4.5节，而现有的第8.3节将显示为第8.4.6节。
o Section 5.3 replaces Section 8.5 ("Location Entries and Server Identity") of [RFC7530]. The last paragraph of the existing section has been removed.
o 第5.3节取代[RFC7530]第8.5节（“位置条目和服务器标识”）。现有章节的最后一段已删除。
The fs_locations 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 hostname representing one or more network addresses or as a single literal network address) together with the path of that file system within the associated single-server namespace. Individual fs_locations entries can express trunkable addresses, locations of file system replicas on other servers, migration targets, or pure referrals.
fs_locations属性允许指定文件系统位置，其中可以访问与给定文件系统对应的数据。此属性将此类文件系统实例表示为服务器地址目标（表示一个或多个网络地址的DNS主机名或单个文字网络地址）以及相关单个服务器命名空间中该文件系统的路径。单个fs_位置条目可以表示中继地址、其他服务器上文件系统副本的位置、迁移目标或纯引用。
We introduce the following terminology:
我们介绍以下术语：
o "Trunking" is a situation in which multiple network addresses are connected to the same NFS server. Network addresses connected to the same NFS server instance are said to be "server-trunkable".
o “中继”是指多个网络地址连接到同一NFS服务器的情况。连接到同一NFS服务器实例的网络地址称为“服务器可中继”。
o "Trunking detection" refers to ways of confirming that two distinct network addresses are connected to the same NFSv4 server instance.
o “中继检测”是指确认两个不同的网络地址连接到同一个NFSv4服务器实例的方法。
o Trunking discovery is a process by which a client using one network address can obtain other candidate addresses that are server-trunkable with it.
o 中继发现是一个过程，通过该过程，使用一个网络地址的客户机可以获得其他候选地址，这些候选地址可以与它进行服务器中继。
Regarding terminology relating to GETATTR attributes used in trunking discovery and other multi-server namespace features:
关于中继发现和其他多服务器命名空间功能中使用的与GETATTR属性相关的术语：
o Location attributes include only the fs_locations GETATTR attribute.
o 位置属性仅包括fs_位置GETATTR属性。
o Location entries (fs_location4, defined in [RFC7530], Section 2.2.6) are the individual file system locations in the fs_locations attribute (defined in [RFC7530], Section 2.2.7). A file system location entry designates a set of network addresses to which clients may establish connections. The entry may designate multiple such addresses because the server hostname may map to multiple network addresses and because multiple connection
o 位置项（fs_location4，在[RFC7530]第2.2.6节中定义）是fs_locations属性中的单个文件系统位置（在[RFC7530]第2.2.7节中定义）。文件系统位置条目指定一组网络地址，客户端可以与这些地址建立连接。该条目可能指定多个这样的地址，因为服务器主机名可能映射到多个网络地址，并且因为多个连接
types may be used to communicate with each specified network address. Such addresses provide multiple ways of connecting to a single server.
类型可用于与每个指定的网络地址通信。这些地址提供了多种连接到单个服务器的方式。
Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to confirm that such addresses are connected to the same server. The client can ignore non-confirmed trunking relationships and treat the corresponding addresses as connected to different servers.
客户端使用NFSv4.0中继检测机制[RFC7931]来确认这些地址连接到同一服务器。客户端可以忽略未确认的中继关系，并将相应的地址视为连接到不同的服务器。
o File system location elements are derived from file system location entries. If a file system location entry specifies a network address, there is only a single corresponding location element. When a file system location entry contains a hostname, the client resolves the hostname, producing one file system location element for each of the resulting network addresses. Issues regarding the trustworthiness of hostname resolutions are further discussed in Section 7 of the current document.
o 文件系统位置元素是从文件系统位置项派生的。如果文件系统位置条目指定网络地址，则只有一个对应的位置元素。当文件系统位置条目包含主机名时，客户端解析主机名，为每个生成的网络地址生成一个文件系统位置元素。当前文档的第7节进一步讨论了主机名解析的可信度问题。
o All file system location elements consist of a file system location address, which is the network 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.
o 所有文件系统位置元素都由文件系统位置地址（服务器接口的网络地址）和fs_名称（服务器伪fs中文件系统的位置）组成。
o If the server has no pseudo-fs and only has a single exported file system at the root filehandle, the fs_name may be empty.
o 如果服务器没有伪fs，并且在根文件句柄处只有一个导出的文件系统，则fs\u名称可能为空。
The subsections below provide replacement sections for existing sections within Section 8.4 of [RFC7530] or new subsections to be added to that section.
以下小节提供了[RFC7530]第8.4节中现有章节的替换章节或该章节中新增的新章节。
Together with the possibility of absent file systems, the fs_locations attribute bears file system locations and a number of important facilities that enable reliable, manageable, and scalable data access.
除了可能缺少文件系统外，“fs_locations”属性还包含文件系统位置和许多重要功能，这些功能支持可靠、可管理和可扩展的数据访问。
When a file system is present on the queried server, this attribute can provide a set of alternate locations that clients may use to access the file system, when necessary. Provision of such alternate file system locations is referred to as "replication" and is further described in Section 5.2.4 of the current document.
当查询的服务器上存在文件系统时，此属性可以提供一组备用位置，客户机可以在必要时使用这些位置访问文件系统。提供此类备用文件系统位置称为“复制”，本文件第5.2.4节对此作了进一步说明。
When alternative file system locations are provided, they may represent distinct physical copies of the same file system data or separate NFS server instances that provide access to the same
当提供替代文件系统位置时，它们可能表示相同文件系统数据的不同物理拷贝，或者表示提供对相同文件系统数据访问的单独NFS服务器实例
physical file system. Another possible use of the provision of multiple file system location entries is trunking, wherein the file system location entries do not, in fact, represent different servers but rather are distinct network paths to the same server.
物理文件系统。提供多个文件系统位置项的另一个可能用途是中继，其中文件系统位置项实际上并不表示不同的服务器，而是到同一服务器的不同网络路径。
A client may use file system location elements simultaneously to provide higher-performance access to the target file system. This can be done using trunking, although the use of multiple replicas simultaneously is possible. To enable simultaneous access, the client utilizes trunking detection and/or discovery, further described in Section 5.2.2 of the current document, to determine a set of network paths that are server-trunkable with the path currently being used to access the file system. Once this determination is made, requests may be routed across multiple paths using the existing state management mechanism.
客户端可以同时使用文件系统位置元素来提供对目标文件系统的更高性能访问。虽然可以同时使用多个副本，但这可以通过中继实现。为了实现同步访问，客户机利用中继检测和/或发现（在当前文档的第5.2.2节中进一步描述）来确定一组网络路径，这些路径可与当前用于访问文件系统的路径进行服务器中继。一旦做出此确定，可以使用现有的状态管理机制跨多个路径路由请求。
Multiple replicas may also be used simultaneously, typically when accessing read-only datasets. In this case, each replica requires its own state management. The client performs multiple file opens to read the same file content from multiple replicas.
通常在访问只读数据集时，也可以同时使用多个副本。在这种情况下，每个复制副本都需要自己的状态管理。客户端执行多个文件打开以从多个副本读取相同的文件内容。
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 file system location. Transfer of the file system contents to the new file system location is referred to as "migration". 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. See Sections 5.2.5 and 5.2.6 of the current document for details.
当文件系统存在并且随后不存在时，客户机可以有机会在另一个文件系统位置继续访问其数据。将文件系统内容传输到新的文件系统位置称为“迁移”。客户在处理这种转换时的责任取决于新访问路径的具体性质以及数据实际上是如何迁移的以及是否迁移的。详见本文件第5.2.5节和第5.2.6节。
The fs_locations attribute can designate one or more remote file system locations in place of an absent file system. This is known as a "referral". A particularly important case is that of a "pure referral", in which the absent file system has never been present on the NFS server. Such a referral is a means by which a file system located on one server can redirect clients to file systems located on other servers, thus enabling the creation of a multi-server namespace.
fs_locations属性可以指定一个或多个远程文件系统位置来代替缺少的文件系统。这被称为“推荐”。一个特别重要的案例是“纯引用”，其中缺少的文件系统从未出现在NFS服务器上。这种引用是一种方法，通过这种方法，位于一台服务器上的文件系统可以将客户端重定向到位于其他服务器上的文件系统，从而支持创建多服务器名称空间。
Because client support for the fs_locations attribute 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.
由于客户端对fs_locations属性的支持是可选的，因此服务器可以（但不需要）采取操作，例如通过代理来隐藏来自此类客户端的迁移和引用事件。
5.2.2. New Subsection Titled "Trunking Discovery and Detection" (Becomes Section 8.4.1)
5.2.2. 标题为“中继发现和检测”的新小节（成为第8.4.1节）
"Trunking" is a situation in which multiple distinct network addresses are associated with the same NFS server instance. As a matter of convenience, we say that two network addresses connected to the same NFS server instance are server-trunkable. Section 5.4 of [RFC7931] explains why NFSv4 clients need to be aware of the NFS server identity to manage lease and lock states effectively when multiple connections to the same server exist.
“中继”是指多个不同的网络地址与同一NFS服务器实例相关联的情况。为了方便起见，我们说连接到同一NFS服务器实例的两个网络地址是可中继的。[RFC7931]的第5.4节解释了当存在到同一服务器的多个连接时，NFSv4客户端需要知道NFS服务器标识以有效管理租约和锁定状态的原因。
"Trunking detection" refers to a way for an NFSv4 client to confirm that two independently acquired network addresses are connected to the same NFSv4 server. Section 5.8 of [RFC7931] describes an OPTIONAL means by which it can be determined whether two network addresses correspond to the same NFSv4.0 server instance. Without trunking detection, an NFSv4.0 client has no other way to confirm that two network addresses are server-trunkable.
“中继检测”是指NFSv4客户端确认两个独立获取的网络地址连接到同一个NFSv4服务器的一种方法。[RFC7931]第5.8节描述了一种可选方法，通过该方法可以确定两个网络地址是否对应于同一个NFSv4.0服务器实例。如果没有中继检测，NFSv4.0客户端就没有其他方法来确认两个网络地址可用于服务器中继。
In the particular context of NFS version 4.0, trunking detection requires that the client support the uniform client ID string (UCS) approach, described in Section 5.6 of [RFC7931]. Any NFSv4.0 client that supports migration or trunking detection needs to present a uniform client ID string to all NFSv4.0 servers. If it does not do so, it will be unable to perform trunking detection.
在NFS版本4.0的特定上下文中，中继检测要求客户端支持统一客户端ID字符串（UCS）方法，如[RFC7931]第5.6节所述。任何支持迁移或中继检测的NFSv4.0客户端都需要向所有NFSv4.0服务器提供统一的客户端ID字符串。如果不这样做，它将无法执行中继检测。
"Trunking discovery" is the process by which an NFSv4 client, using a hostname or one of an NFSv4 server's network addresses, can obtain other candidate network addresses that are trunkable with the NFSv4 server's network address, i.e., a set of addresses that might be connected to the same NFSv4 server instance. An NFSv4.0 client can discover server-trunkable network addresses in a number of ways:
“中继发现”是NFSv4客户端使用主机名或NFSv4服务器的一个网络地址，可以获得可与NFSv4服务器的网络地址中继的其他候选网络地址的过程，即，可能连接到同一NFSv4服务器实例的一组地址。NFSv4.0客户端可以通过多种方式发现服务器集群网络地址：
o An NFS server's hostname is provided either at mount time or in a returned file system location entry. A DNS query of this hostname can return more than one network address. The returned network addresses are candidates for trunking.
o NFS服务器的主机名可以在装载时提供，也可以在返回的文件系统位置条目中提供。此主机名的DNS查询可以返回多个网络地址。返回的网络地址是中继的候选地址。
o Location entries returned in an fs_locations attribute can specify network addresses. These network addresses are candidates for trunking.
o fs_locations属性中返回的位置项可以指定网络地址。这些网络地址是中继的候选地址。
When there is a means of trunking detection available, an NFSv4.0 client can confirm that a set of network addresses corresponds to the same NFSv4.0 server instance; thus, any of them can be used to access that server.
当有中继检测手段可用时，NFSv4.0客户端可以确认一组网络地址对应于同一NFSv4.0服务器实例；因此，它们中的任何一个都可以用来访问该服务器。
5.2.3. New Subsection Titled "Location Attributes and Selection of Connection Type" (Becomes Section 8.4.2)
5.2.3. 标题为“位置属性和连接类型选择”的新小节（成为第8.4.2节）
NFS version 4.0 may be implemented using a number of different types of connections:
NFS 4.0版可以使用多种不同类型的连接来实现：
Stream connections may be used to provide RPC service, as described in [RFC5531].
流连接可用于提供RPC服务，如[RFC5531]中所述。
RDMA-capable connections may be used to provide RPC service, as described in [RFC8166].
支持RDMA的连接可用于提供RPC服务，如[RFC8166]所述。
Because of the need to support multiple connection types, clients face the issue of determining the proper connection type to use when establishing a connection to a server network address. The fs_locations attribute provides no information to support selection of the connection type. As a result, clients supporting multiple connection types need to attempt to establish a connection on various connection types, allowing it to determine, via a trial-and-error approach, which connection types are supported.
由于需要支持多种连接类型，客户端在建立到服务器网络地址的连接时面临确定要使用的正确连接类型的问题。fs_locations属性不提供支持选择连接类型的信息。因此，支持多种连接类型的客户端需要尝试在各种连接类型上建立连接，以便通过试错方法确定支持哪些连接类型。
If a client strongly prefers one connection type, it can perform these attempts serially in order of declining preference. Once there is a successful attempt, the established connection can be used. Note that with this approach, network partitions can result in a sequence of long waits for a successful connection.
如果客户机强烈偏好一种连接类型，它可以按拒绝偏好的顺序连续执行这些尝试。一旦尝试成功，就可以使用已建立的连接。请注意，使用这种方法，网络分区可能会导致对成功连接的一系列长时间等待。
To avoid waiting when there is at least one viable network path available, simultaneous attempts to establish multiple connection types are possible. Once a viable connection is established, the client discards less-preferred connections.
为了避免在至少有一条可行的网络路径可用时等待，可以同时尝试建立多种连接类型。一旦建立了一个可行的连接，客户端就会丢弃不太首选的连接。
5.2.4. Updated Section "File System Replication" (Becomes Section 8.4.3 Retitled "File System Replication and Trunking"
5.2.4. 更新了“文件系统复制”一节（变为第8.4.3节，重新命名为“文件系统复制和中继”
On first access to a file system, the client should obtain the value of the set of alternative file system locations by interrogating the fs_locations attribute. Trunking discovery and/or detection can then be applied to the file system location entries to separate the candidate 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 the client and target file system.
在首次访问文件系统时，客户机应通过询问fs_locations属性来获取一组备选文件系统位置的值。中继发现和/或检测随后可应用于文件系统位置条目，以将候选服务器中继地址与提供文件系统替代位置的副本地址分开。通过利用客户端和目标文件系统之间的多条路径，可以同时使用服务器中继地址来提供更高的性能。
In the event that server failure, communication problems, or other difficulties make continued access to the current file system impossible or otherwise impractical, the client can use the
如果服务器故障、通信问题或其他困难导致无法继续访问当前文件系统或无法继续访问当前文件系统，客户端可以使用
alternative file system locations as a way to maintain continued access to the file system. See Section 5.2.6 of the current document for more detail.
替代文件系统位置，以保持对文件系统的持续访问。有关更多详细信息，请参见当前文件第5.2.6节。
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 file system location 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 Section 5.2.6 of the current document for more detail.
当文件系统存在并且不存在时，客户机可以有机会在fs_locations属性指定的替代文件系统位置继续访问其数据。通常，客户机将访问有问题的文件系统，获取NFS4ERR_MOVED错误，然后使用fs_locations属性确定数据的新位置。有关更多详细信息，请参见当前文件第5.2.6节。
Such migration can help provide 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 the client and server.
这种迁移可以帮助提供负载平衡或一般资源重新分配。该协议未指定文件系统在服务器之间移动的方式。预计可能会使用许多不同的服务器到服务器传输机制，选择权留给服务器实现者。NFSv4协议指定用于在客户端和服务器之间传递迁移事件的方法。
When the client receives indication of a migration event via an NFS4ERR_MOVED error, data propagation to the destination server must have already occurred. Once the client proceeds to access the alternate file system location, it must see 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 the file system state.
当客户端通过NFS4ERR_MOVED错误接收到迁移事件的指示时，必须已经发生到目标服务器的数据传播。一旦客户端继续访问备用文件系统位置，它必须看到相同的数据。如果文件系统是可写的，则对原始文件系统所做的更改必须在所有迁移目标上可见。如果文件系统不可写，但表示可写文件系统的只读副本（可能定期更新），则类似的要求适用于更新的传播。原始文件系统中的任何可见更改必须已经在所有迁移目标上生效，以避免客户端在向迁移目标进行转换时看到文件系统状态的任何恢复。
5.2.6. New Subsection Titled "Interaction of Trunking, Migration, and Replication" (Becomes Section 8.4.5)
5.2.6. 标题为“中继、迁移和复制的交互”的新小节（成为第8.4.5节）
When the set of network addresses on a server changes in a way that would affect a file system location attribute, there are several possible outcomes for clients currently accessing that file system. NFS4ERR_MOVED is returned only when the server cannot satisfy a request from the client, whether because the file system has been migrated to a different server or is only accessible at a different trunked address on the same server, or for some other reason. In cases 1 and 2 below, NFS4ERR_MOVED is not returned.
当服务器上的一组网络地址发生更改，从而影响文件系统位置属性时，当前访问该文件系统的客户端可能会出现几种结果。只有当服务器无法满足客户端的请求时，才会返回NFS4ERR_MOVED，无论是因为文件系统已迁移到其他服务器，还是由于其他原因，只能在同一服务器上的不同中继地址访问文件系统。在下面的情况1和2中，不会返回NFS4ERR_MOVED。
1. 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. Alternatively, the client may treat that address as it does a replica -- to be used if the current server addresses become unavailable.
1. 当网络地址列表是以前有效的超集时，不需要迁移或任何其他类型的客户端调整。但是，如果替换列表中的其他地址提供了到同一服务器的另一条路径，则客户端可以自由使用该地址。或者，客户机可以将该地址视为复制副本——如果当前服务器地址不可用，则使用该地址。
2. When the list of network 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 that address to access that file system in the future, whether the address is for a replica or an additional path to the server being used.
2. 当网络地址列表是以前有效的地址列表的子集时，如果替换列表中缺少的地址当前未被客户端使用，则不需要立即采取行动。客户端应避免在将来使用该地址访问该文件系统，无论该地址是用于复制副本还是用于所用服务器的其他路径。
3. 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.
3. 当要删除的地址是当前服务器的多条路径之一时，客户端可以继续使用该地址，直到收到NFS4ERR_MOVED。除非到服务器的最后一条可用路径变得不可用，否则这不会被视为迁移事件。
When migration does occur, multiple addresses may be in use on the server prior to migration, and multiple addresses may be available for use on the destination server.
当确实发生迁移时，迁移之前服务器上可能正在使用多个地址，并且目标服务器上可能可以使用多个地址。
With regard to the server in use, a return of NFS4ERR_MOVED may indicate 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. Clients should not conclude that migration has occurred until confirming that all network addresses known to be associated with that server are not usable.
关于正在使用的服务器，返回NFS4ERR_MOVED可能表示不再使用特定的网络地址，而不意味着需要将文件系统迁移到不同的服务器。在确认所有已知与该服务器关联的网络地址都不可用之前，客户端不应断定迁移已发生。
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 harmless since the use of the same server via a new address will appear as a successful instance of transparent state migration.
应当指出，推迟这一决定的必要性并不是绝对的。如果客户机由于任何原因不知道所有网络地址，它可能会得出这样的结论：当它不知道时，迁移已经发生，并将切换到其他服务器地址视为迁移事件。这是无害的，因为通过新地址使用同一服务器将显示为透明状态迁移的成功实例。
Although significant harm cannot 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. When such a lock is lost, it is the responsibility of the destination server to provide for its recovery via the use of an fs-specific grace period.
虽然这种误解不会造成重大伤害，但会导致令人不安的情况。例如，如果一个锁在地址移动期间被撤销，那么客户端会觉得该锁在迁移期间丢失了。当此类锁丢失时，目标服务器负责通过使用特定于fs的宽限期来提供恢复。
With regard to the destination server, it is desirable for the client to be aware of all 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 file system location elements in parallel with normal use of the first valid file system location entry found to access the destination.
关于目的地服务器，希望客户端知道可用于访问目的地服务器的所有有效网络地址。然而，没有必要立即这样做。实现可以并行处理附加的文件系统位置元素，并正常使用找到的第一个有效文件系统位置条目来访问目标。
Because a file system location attribute may include entries relating to the current server, the migration destination, and possible replicas to use, scanning for available network addresses that might be trunkable with addresses the client has already seen could potentially be a long process. To keep this process as short as possible, servers that provide information about trunkable network paths are REQUIRED to place file system location entries that represent addresses usable with the current server or a migration target before those associated with replicas.
由于文件系统位置属性可能包括与当前服务器、迁移目标和可能要使用的副本相关的条目，因此扫描可用的网络地址（这些地址可能与客户端已经看到的地址一致）可能是一个漫长的过程。为了使此过程尽可能短，需要提供可中继网络路径信息的服务器将表示当前服务器或迁移目标可用地址的文件系统位置条目放在与副本关联的地址之前。
This ordering allows a client to cease scanning for trunkable file system location entries once it encounters a file system location element whose fs_name differs from the current fs_name or whose address is not server-trunkable with the address it is currently using. Although the possibility exists that a client might prematurely cease scanning for trunkable addresses when receiving a location attribute from an older server that does not follow the ordering constraint above, the harm is expected to be limited since such servers would not be expected to present information about trunkable server access paths.
此排序允许客户端在遇到文件系统位置元素（其fs_名称与当前fs_名称不同或其地址与当前使用的地址不可用于服务器中继）时停止扫描可中继文件系统位置条目。虽然存在这样的可能性，即当从不遵循上述排序约束的较旧服务器接收位置属性时，客户端可能会提前停止扫描可中继地址，但由于此类服务器不会提供有关可中继服务器访问路径的信息，因此其危害预计是有限的。
5.3. Updated Section "Location Entries and Server Identity" (Section 8.5)
5.3. 更新了“位置条目和服务器标识”一节（第8.5节）
As mentioned above, a single file system location entry may have a server address target in the form of a DNS hostname that resolves to multiple network addresses; it is also possible for multiple file system location entries to have their own server address targets that reference the same server.
如上所述，单个文件系统位置条目可以具有解析为多个网络地址的DNS主机名形式的服务器地址目标；多个文件系统位置项也可能具有引用同一服务器的自己的服务器地址目标。
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, file systems at corresponding namespace locations exist for each of the other server-trunkable 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.
当服务器的可中继服务器地址存在时，客户机可能会假定，对于给定服务器网络地址的命名空间中的每个文件系统，其他每个可中继服务器网络地址都存在相应命名空间位置的文件系统。即使在fs_位置中没有明确的列表，它也可以这样做。这些相应的文件系统位置可以用作替代位置，就像通过fs_locations属性显式指定的位置一样。
If a single file system location entry designates multiple server IP addresses, the client should choose a single one to use. When two server addresses are designated by a single file system location entry and they correspond to different servers, this normally indicates some sort of misconfiguration. The client should avoid using such file system location entries when alternatives are available. When they are not, the client should pick one of the IP addresses and use it without using others that are not directed to the same server.
如果单个文件系统位置条目指定多个服务器IP地址，则客户端应选择一个要使用的IP地址。当两个服务器地址由一个文件系统位置条目指定，并且它们对应于不同的服务器时，这通常表示某种配置错误。当有其他选择时，客户机应避免使用此类文件系统位置条目。如果不是，客户端应该选择一个IP地址并使用它，而不使用其他不指向同一服务器的IP地址。
Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 of [RFC7530] 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:
由于[RFC7530]第13.1.2.4节中对NFS4ERR_的现有描述没有适当考虑中继，因此需要修改，将描述的前两句替换为以下材料：
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.
无法使用当前网络地址访问包含当前filehandle对象的文件系统。可以使用连接到同一服务器的其他网络地址访问它，它可能已重新定位到另一台服务器，或者它可能从未出现过。
The Security Considerations section of [RFC7530] needs the additions below to properly address some aspects of trunking discovery, referral, migration, and replication.
[RFC7530]的安全注意事项部分需要添加以下内容，以正确解决中继发现、引用、迁移和复制的某些方面。
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.
需要考虑确定与给定服务器对应的网络地址集的请求可能受到干扰或其响应被破坏的可能性。
o When DNS is used to convert NFS server hostnames to network addresses and DNSSEC [RFC4033] is not available, the validity of the network addresses returned cannot be relied upon. However, when the client uses RPCSEC_GSS [RFC7861] to access NFS servers, it is possible for mutual authentication to detect invalid server addresses. Other forms of transport layer security (e.g., [RFC8446]) can also offer strong authentication of NFS servers.
o 如果使用DNS将NFS服务器主机名转换为网络地址，并且DNSSEC[RFC4033]不可用，则无法依赖返回的网络地址的有效性。但是，当客户端使用RPCSEC_GSS[RFC7861]访问NFS服务器时，相互身份验证可以检测无效的服务器地址。其他形式的传输层安全性（例如，[RFC8446]）也可以提供NFS服务器的强身份验证。
o Fetching file system location information SHOULD be performed using RPCSEC_GSS with integrity protection, as previously explained in the Security Considerations section of [RFC7530]. Making a request of this sort without using strong integrity protection permits corruption during the transit of returned file system 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 as defined in [RFC5531]) can result in the client interacting with an unverified network address that is posing as an NFSv4 server.
o 获取文件系统位置信息应使用带有完整性保护的RPCSEC_GSS执行，如[RFC7530]的安全注意事项部分所述。在不使用强完整性保护的情况下发出此类请求，会导致在传输返回的文件系统位置信息时发生损坏。客户机实现者需要认识到，在不使用RPCSEC_GSS的情况下使用此类信息访问NFS服务器（例如，使用[RFC5531]中定义的AUTH_SYS）可能会导致客户机与冒充为NFSv4服务器的未经验证的网络地址进行交互。
o Despite the fact that [RFC7530] REQUIRES "implementations" to provide "support" for the use of RPCSEC_GSS, it cannot be assumed that use of RPCSEC_GSS is always possible between any particular client-server pair.
o 尽管[RFC7530]需要“实现”来为RPCSEC_GSS的使用提供“支持”，但不能假定在任何特定的客户机-服务器对之间始终可以使用RPCSEC_GSS。
o Returning only network addresses to a client that has no trusted DNS resolution service can hamper its ability to use RPCSEC_GSS.
o 仅向没有可信DNS解析服务的客户端返回网络地址可能会妨碍其使用RPCSEC_GSS的能力。
Therefore, an NFSv4 server SHOULD present file system location entries that correspond to file systems on other servers using only hostnames. 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 hostname provided while ensuring that the response has not been corrupted.
因此，NFSv4服务器应提供与仅使用主机名的其他服务器上的文件系统相对应的文件系统位置条目。这使客户端能够使用完整的RPCSEC_GSS查询目标服务器上的fs_位置，以获取中继信息（以及副本信息），验证提供的主机名，同时确保响应未损坏。
When RPCSEC_GSS is not available on an NFS server, returned file system 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 on the destination. Even when RPCSEC_GSS authentication is available on
当NFS服务器上没有RPCSEC_GSS时，返回的文件系统位置信息在传输过程中会损坏，因此无法依赖。如果客户端在NFS4ERR_移动后被定向到另一台服务器，则这可能会使通过在目标上使用RPCSEC_GSS提供的身份验证无效。即使RPCSEC_GSS身份验证在
the destination, this server might validly represent itself as the server to which the client was erroneously directed. Without a way to decide whether the server is a valid one, the client can only determine, using RPCSEC_GSS, that the server corresponds to the hostname provided, with no basis for trusting that server. The client should not use such unverified file system location entries as a basis for migration, even though RPCSEC_GSS might be available on the destination server.
在目标服务器上，此服务器可以有效地将其自身表示为客户端被错误定向到的服务器。如果无法确定服务器是否有效，客户端只能使用RPCSEC_GSS确定服务器与提供的主机名相对应，而没有信任该服务器的基础。客户机不应使用此类未经验证的文件系统位置项作为迁移的基础，即使目标服务器上可能有RPCSEC_GSS。
When a file system location attribute is fetched upon connecting with an NFSv4 server, it SHOULD, as stated above, be done using RPCSEC_GSS with integrity protection.
当在连接NFSv4服务器时获取文件系统位置属性时，如上所述，应该使用具有完整性保护的RPCSEC_GSS来完成。
When file system location information cannot be protected in transit, the client can subject it to additional filtering to prevent the client from being inappropriately directed. For example, if a range of network addresses can be determined that ensure that the servers and clients using AUTH_SYS are subject to appropriate constraints (such as physical network isolation and the use of administrative controls within the operating systems), then network addresses in this range can be used, with others discarded or restricted in their use of AUTH_SYS.
当文件系统位置信息在传输过程中无法得到保护时，客户机可以对其进行额外的筛选，以防止客户机受到不适当的指导。例如，如果可以确定一个网络地址范围，以确保使用AUTH_SYS的服务器和客户端受到适当的约束（例如物理网络隔离和操作系统内管理控制的使用），则可以使用该范围内的网络地址，其他人放弃或限制使用AUTH_SYS。
When neither integrity protection nor filtering is possible, it is best for the client to ignore trunking and replica information or simply not fetch the file system location information for these purposes.
当完整性保护和筛选都不可能时，客户机最好忽略中继和副本信息，或者干脆不获取用于这些目的的文件系统位置信息。
To summarize considerations regarding the use of RPCSEC_GSS in fetching file system location information, consider the following recommendations for requests to interrogate location information, with interrogation approaches on the referring and destination servers arrived at separately:
总结RPCSECGIGSS在获取文件系统位置信息方面的考虑，考虑请求查询位置信息的下列建议，查询和到达目的地服务器的查询方法分别为：
o 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.
o 在所有情况下，建议使用带有完整性保护的RPCSEC_GSS，因为缺乏完整性保护会使客户在传输过程中有可能修改结果。
o The use of requests issued without RPCSEC_GSS (e.g., using AUTH_SYS), while undesirable, might be unavoidable in some cases. Where the use of returned file system location information cannot be avoided, it should be subject to filtering to eliminate untrusted network addresses. The specifics will vary depending on the degree of network isolation and whether the request is to the referring or destination servers.
o 使用未经RPCSEC_GSS发出的请求（例如，使用AUTH_SYS）虽然不可取，但在某些情况下可能无法避免。如果无法避免使用返回的文件系统位置信息，则应对其进行过滤，以消除不受信任的网络地址。具体细节将根据网络隔离程度以及请求是发送给引用服务器还是发送给目标服务器而有所不同。
Privacy considerations relating to uniform client strings (UCS) versus non-uniform client strings (non-UCS), discussed in Section 5.6 of [RFC7931], are also applicable to their usage for trunking detection in NFS version 4.0.
[RFC7931]第5.6节中讨论的与统一客户端字符串（UCS）和非统一客户端字符串（非UCS）相关的隐私注意事项也适用于NFS版本4.0中中继检测的使用。
This document has no IANA actions.
本文档没有IANA操作。
The following references should be added to the Normative References section of [RFC7530]:
[RFC7530]的规范性参考文件部分应添加以下参考文件：
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4.0 Migration: Specification Update", RFC 7931, DOI 10.17487/RFC7931, July 2016, <https://www.rfc-editor.org/info/rfc7931>.
[RFC7931]Noveck，D.，Ed.，Shivam，P.，Lever，C.，和B.Baker，“NFSv4.0迁移：规范更新”，RFC 7931，DOI 10.17487/RFC79312016年7月<https://www.rfc-editor.org/info/rfc7931>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166]Lever，C.，Ed.，Simpson，W.，和T.Talpey，“远程过程调用版本1的远程直接内存访问传输”，RFC 8166，DOI 10.17487/RFC8166，2017年6月<https://www.rfc-editor.org/info/rfc8166>.
The following references should be added to the Informative References section of [RFC7530]:
[RFC7530]的参考资料部分应添加以下参考资料：
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<https://www.rfc-editor.org/info/rfc4033>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861]Adamson，A.和N.Williams，“远程过程调用（RPC）安全版本3”，RFC 7861，DOI 10.17487/RFC7861，2016年11月<https://www.rfc-editor.org/info/rfc7861>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC：远程过程调用协议规范版本2”，RFC 5531，DOI 10.17487/RFC5531，2009年5月<https://www.rfc-editor.org/info/rfc5531>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<https://www.rfc-editor.org/info/rfc7530>.
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4.0 Migration: Specification Update", RFC 7931, DOI 10.17487/RFC7931, July 2016, <https://www.rfc-editor.org/info/rfc7931>.
[RFC7931]Noveck，D.，Ed.，Shivam，P.，Lever，C.，和B.Baker，“NFSv4.0迁移：规范更新”，RFC 7931，DOI 10.17487/RFC79312016年7月<https://www.rfc-editor.org/info/rfc7931>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166]Lever，C.，Ed.，Simpson，W.，和T.Talpey，“远程过程调用版本1的远程直接内存访问传输”，RFC 8166，DOI 10.17487/RFC8166，2017年6月<https://www.rfc-editor.org/info/rfc8166>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<https://www.rfc-editor.org/info/rfc4033>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <https://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<https://www.rfc-editor.org/info/rfc5661>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861]Adamson，A.和N.Williams，“远程过程调用（RPC）安全版本3”，RFC 7861，DOI 10.17487/RFC7861，2016年11月<https://www.rfc-editor.org/info/rfc7861>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
All sections of the current document are considered explanatory with the following exceptions.
除以下例外情况外，本文件的所有章节均视为解释性章节。
o Sections 5.1, 5.2.4, 5.2.5, and 5.3 are replacement sections.
o 第5.1节、第5.2.4节、第5.2.5节和第5.3节为替换章节。
o Sections 5.2.2, 5.2.3, and 5.2.6 are additional sections.
o 第5.2.2、5.2.3和5.2.6节为附加章节。
o Sections 5.2.1, 6, 7, and Section 9 are editing sections.
o 第5.2.1节、第6节、第7节和第9节是编辑部分。
Acknowledgments
致谢
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.
作者希望感谢Andy Adamson，他编写了本文件的原始版本。本文档中的所有创新都是Andy工作的结果，而错误最好归咎于当前的作者。
The editor wishes to thank Greg Marsden for his support of this work and Robert Thurlow for his review and suggestions.
编辑希望感谢格雷格·马斯登对这项工作的支持，以及罗伯特·瑟洛的评论和建议。
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their ongoing support. We are also grateful for the thorough review of this document by Benjamin Kaduk and Ben Campbell.
特别感谢运输部门主管斯宾塞·道金斯、NFSV4工作组主席斯宾塞·谢普勒和布赖恩·波洛夫斯基以及NFSV4工作组秘书托马斯·海恩斯的持续支持。我们还感谢本杰明·卡杜克和本·坎贝尔对本文件的全面审查。
Authors' Addresses
作者地址
Charles Lever (editor) Oracle Corporation United States of America
Charles Lever（编辑）美国甲骨文公司
Email: chuck.lever@oracle.com
Email: chuck.lever@oracle.com
David Noveck NetApp United States of America
David Noveck NetApp美利坚合众国
Email: davenoveck@gmail.com
Email: davenoveck@gmail.com