Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999
Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999
NFS Version 4 Design Considerations
NFS版本4设计注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on the Internet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
NFS版本4工作组的主要任务是为分布式文件系统创建一个协议定义，该定义侧重于以下项目：改进的访问和Internet上的良好性能、协议内置协商的强大安全性、更好的跨平台互操作性，以及专为协议扩展而设计。NFS版本4的总体设计将归功于以前的NFS版本。但是，人们预计NFS版本4中的许多功能将与以前的版本有很大的不同，以促进工作组的目标，并解决NFS版本2和3没有解决的问题。
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas.
本设计考虑事项文件旨在比工作组章程提供更多细节。具体地说，它介绍了工作组在开发NFS版本4的协议规范时将调查和考虑的领域。根据这项调查，工作组将根据特定功能领域内的成本和效益来决定新协议的功能。
Key Words
关键词
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 RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Table of Contents
目录
1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
2. Ease of Implementation or Complexity of Protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
2.3. Relationship with Older Versions of NFS . . . . . . . . . . 4
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 5
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 5
4.1. Throughput and Latency via the Network . . . . . . . . . . 6
4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 7
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 8
5.2. Additional or Extended Attributes . . . . . . . . . . . . . 8
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 9
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 10
6.1. User identification . . . . . . . . . . . . . . . . . . . 10
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Transport Independence . . . . . . . . . . . . . . . . 11
6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 11
6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 12
6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 12
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 13
7.1. Congestion Control and Transport Selection . . . . . . . 13
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 14
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 14
8. File locking / recovery . . . . . . . . . . . . . . . . . . 15
9. Internationalization . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . 17
10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 17
11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 21
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 22
1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
2. Ease of Implementation or Complexity of Protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
2.3. Relationship with Older Versions of NFS . . . . . . . . . . 4
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 5
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 5
4.1. Throughput and Latency via the Network . . . . . . . . . . 6
4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 7
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 8
5.2. Additional or Extended Attributes . . . . . . . . . . . . . 8
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 9
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 10
6.1. User identification . . . . . . . . . . . . . . . . . . . 10
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Transport Independence . . . . . . . . . . . . . . . . 11
6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 11
6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 12
6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 12
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 13
7.1. Congestion Control and Transport Selection . . . . . . . 13
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 14
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 14
8. File locking / recovery . . . . . . . . . . . . . . . . . . 15
9. Internationalization . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . 17
10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 17
11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 21
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 22
As stated in the charter, the first deliverable for the NFS version 4 working group is this design considerations document. This document is to cover the "limitations and deficiencies of NFS version 3". This document will also be used as a mechanism to focus discussion and avenues of investigation as the definition of NFS version 4 progresses. Therefore, the contents of this document cover the general functional/feature areas that are anticipated for NFS version 4. Where appropriate, discussion of current NFS version 2 and 3
如章程中所述，NFS版本4工作组的第一个可交付成果是本设计注意事项文档。本文档将介绍“NFS版本3的限制和缺陷”。随着NFS版本4定义的进展，本文档还将作为一种机制来集中讨论和调查。因此，本文档的内容涵盖了NFS版本4预期的一般功能/特性领域。在适当的情况下，讨论当前的NFS版本2和3
practice will be presented along with other appropriate references to current distributed file system practice.
实践将与当前分布式文件系统实践的其他适当参考一起介绍。
One of the strengths of NFS has been the ability to implement a client or server with relative ease. The eventual size of a basic implementation is relatively small. The main reason for keeping NFS as simple as possible is that a simple protocol design can be described in a simple specification that promotes straightforward, interoperable implementations. All protocols can run into problems when deployed on real networks, but simple protocols yield problems that are easier to diagnose and correct.
NFS的优势之一是能够相对轻松地实现客户机或服务器。基本实现的最终规模相对较小。保持NFS尽可能简单的主要原因是，可以用一个简单的规范来描述一个简单的协议设计，该规范促进了简单、可互操作的实现。所有协议在实际网络上部署时都会遇到问题，但简单的协议会产生更容易诊断和纠正的问题。
With NFS' relative simplicity, the addition or layering of functionality has been easy to accomplish. The addition of features like the client automount or autofs, client side disk caching and high availability servers are examples. This type of extensibility is desirable in an environment where problem solutions do not require protocol revision. This extensibility can also be helpful in the future where unforeseen problems or opportunities can be solved by layering functionality on an existing set of tools or protocol.
由于NFS相对简单，功能的添加或分层很容易实现。例如，添加了客户端自动装载或autofs、客户端磁盘缓存和高可用性服务器等功能。在问题解决方案不需要修改协议的环境中，这种类型的扩展是可取的。这种可扩展性在将来也会很有用，因为可以通过在现有工具或协议集上分层功能来解决不可预见的问题或机会。
For those cases where the NFS protocol is deficient or where a minor modification is the best solution for a problem, a minor version or a managed extension could be helpful. There have been instances with NFS version 2 and 3 where small straightforward functional additions would have increased the overall value of the protocol immensely. For instance, the PATHCONF procedure that was added to version 2 of the MOUNT protocol would have been more appropriate for the NFS protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP procedure for NFS versions 2 and 3 would have been more cleanly implemented in a new LOOKUP procedure.
对于NFS协议有缺陷或轻微修改是问题的最佳解决方案的情况，较小版本或托管扩展可能会有所帮助。在NFS版本2和3的实例中，简单的小功能添加将极大地提高协议的总体价值。例如，添加到装载协议版本2的PATHCONF过程更适合NFS协议。WebNFS[RFC2054][RFC2055]在新的查找过程中，可以更干净地实现NFS版本2和3的查找过程的重载。
However, the perceived size and burden of using a change of RPC version number for the introduction of new functionality led to no or slow change. It is possible that a new NFS protocol could allow for the rare instance where protocol extension within the RPC version number is the most prudent course and an RPC revision would be unnecessary or impractical.
然而，使用RPC版本号更改来引入新功能的感知大小和负担导致没有或缓慢更改。一个新的NFS协议可能会允许出现这样一种罕见的情况，即RPC版本号内的协议扩展是最谨慎的做法，并且RPC修订是不必要的或不切实际的。
The areas of an NFS protocol which are most obviously volatile are new orthogonal procedures, new well-defined file or directory attributes and potentially new file types. As an example, potential
NFS协议中最易波动的领域是新的正交过程、新的定义良好的文件或目录属性以及潜在的新文件类型。例如，潜在的
file types of the future could be a type such as "attribute" that represents a named file stream or a "dynamic" file type that generates dynamic data in response to a "query" procedure from the client.
未来的文件类型可以是表示命名文件流的“属性”类型，也可以是响应客户机的“查询”过程而生成动态数据的“动态”文件类型。
It is possible and highly desirable that these types of additions be done without changing the overall design model of NFS without significant effort or delay.
在不改变NFS的总体设计模型的情况下进行这些类型的添加是可能的，也是非常可取的，而且不需要付出很大的努力或延迟。
A strong consideration should be given to a NFS protocol mechanism for the introduction of this type of new functionality. This is obviously in contrast to using the standard RPC version mechanism to provide minor changes. The process of using RPC version numbers to introduce new functionality brings with it a lot of history which may not technically prevent its use. However, the historical issues involved will need to be addressed as part of the NFS version 4 protocol work; this should increase the ability for current and future success of the protocol.
在引入此类新功能时，应充分考虑NFS协议机制。这显然与使用标准RPC版本机制来提供微小更改形成对比。使用RPC版本号引入新功能的过程带来了很多历史，从技术上讲，这些历史可能不会阻止它的使用。但是，所涉及的历史问题需要作为NFS版本4协议工作的一部分加以解决；这将提高该议定书目前和今后取得成功的能力。
As background, the RPC protocol described in [RFC1831] uses a version number to describe the set of procedure calls, replies, and their semantics. Any change in this set must be reflected in a new version number for the program. An example of this was the MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT protocol. Except for the addition of this new procedure, the protocol was unchanged. Many thought this protocol revision was unnecessary, since the RPC protocol already allows certain procedures not be implemented and defines a PROC_UNAVAIL error.
作为背景，[RFC1831]中描述的RPC协议使用版本号来描述过程调用、应答及其语义集。此集合中的任何更改都必须反映在程序的新版本号中。这方面的一个例子是在MOUNT协议的版本2中添加的MOUNTPROC_PATHCONF过程。除了增加这一新的程序外，该方案没有改变。许多人认为这个协议修订是不必要的，因为RPC协议已经允许某些程序不能实现，并且定义了一个PROC_UNAVAIL错误。
Another historical data-point from NFS version 2 and 3 is the support (or lack) of symbolic links. Servers that cannot support this feature will simply reject calls to the SYMLINK and READLINK procedures. Additionally, NFS version 4 may describe many file attributes which cannot be supported by the server or file systems on the server. Therefore, the protocol must support a discovery mechanism that allows clients to determine which features of the protocol are supported by a server.
NFS版本2和3的另一个历史数据点是对符号链接的支持（或缺乏）。不支持此功能的服务器只会拒绝对SYMLINK和READLINK过程的调用。此外，NFS版本4可能描述服务器或服务器上的文件系统不支持的许多文件属性。因此，协议必须支持发现机制，该机制允许客户端确定服务器支持协议的哪些功能。
NFS version 4 will be a self contained protocol in that it will not have any dependencies on the previous versions of NFS. Stated another way, an NFS version 4 server or client will not require a NFSv2 or NFSv3 implementation be present for NFS version 4 to function as designed. It should also be noted that having an NFS version 2 or 3 implementation present at the client or server will not enhance the functionality of an NFS version 4 implementation.
NFS版本4将是一个自包含的协议，因为它不依赖于以前的NFS版本。换句话说，NFS版本4服务器或客户端不需要NFSv2或NFSv3实现，NFS版本4才能按设计运行。还应注意，在客户端或服务器上存在NFS版本2或3实现不会增强NFS版本4实现的功能。
In the case where an NFS client has a choice of using various NFS protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms will allow the client to appropriately choose an available version of the protocol at the NFS server. The ONCRPC protocol contains the semantics and error returns for the case where an RPC server program does not support a particular version. This mechanism is used by the NFS client to receive notification of an unavailable version and in conjunction with the error the client will also receive the range of versions (min to max) that are available. Therefore, the ONCRPC mechanism can be used by implementors of both clients and servers to provide for the transitioning to or installation of NFS version 4 services.
如果NFS客户端可以选择使用各种NFS协议版本（即2、3和4），则底层ONCRPC机制将允许客户端在NFS服务器上适当地选择可用的协议版本。ONCRPC协议包含RPC服务器程序不支持特定版本时的语义和错误返回。NFS客户端使用此机制接收不可用版本的通知，并结合错误，客户端还将接收可用版本的范围（从最小到最大）。因此，客户端和服务器的实现者都可以使用ONCRPC机制来提供到nfsversion4服务的转换或安装。
Current NFS protocol design, while placing an emphasis on simple server design, has led to timely recovery from server and client failure. This and other aspects to the design have provided a basis for layered technologies like high availability and clustered servers. Providing a protocol design approach that lends itself to these types of reliability and availability features is very desirable.
当前的NFS协议设计虽然强调简单的服务器设计，但却能够及时从服务器和客户端故障中恢复。设计的这一方面和其他方面为高可用性和集群服务器等分层技术提供了基础。提供适合这些类型的可靠性和可用性特性的协议设计方法是非常可取的。
For the next version of NFS, consideration should be given to client side availability schemes such as client switching between or fail-over to available server replicas. NFS currently requires that file handles be immutable; this requirement adds unnecessarily to the complexity of building fail-over configurations. If possible, the protocol should allow for or ease the building of such layered solutions.
对于下一版本的NFS，应考虑客户端可用性方案，例如在可用服务器副本之间切换或故障转移到可用服务器副本。NFS当前要求文件句柄是不可变的；这一要求不必要地增加了构建故障转移配置的复杂性。如果可能，协议应允许或简化此类分层解决方案的构建。
For the next version of NFS, consideration should be given to schemes that support client switching between server replicas or highly available NFS servers that provide paths to data through multiple servers. For example: NFS currently requires that filehandles be unchanging for any instance of a file or directory. This requirement makes it more difficult for a client to switch from one server to another, since each server may construct filehandles differently. Protocol support could allow the client to handle a filehandle change.
对于下一个版本的NFS，应考虑支持在服务器副本或高可用NFS服务器之间进行客户端切换的方案，这些服务器通过多个服务器提供数据路径。例如：NFS当前要求文件或目录的任何实例的文件句柄都保持不变。这一要求使得客户机从一台服务器切换到另一台服务器更加困难，因为每台服务器可能构造不同的文件句柄。协议支持允许客户端处理文件句柄更改。
In designing and developing an NFS protocol from a performance viewpoint there are several different points to consider. Each can play a significant role in perceived and real performance from the user's perspective. The three main areas of interest are: throughput and latency via the network, server work load or scalability and
在设计和开发NFS协议从性能的观点，有几个不同的点要考虑。从用户的角度来看，每种方法都可以在感知和实际性能方面发挥重要作用。感兴趣的三个主要方面是：通过网络的吞吐量和延迟、服务器工作负载或可伸缩性以及
client side caching.
客户端缓存。
NFS currently has characteristics that provide good throughput for reading and writing file data. This is commonly achieved by the client's use of pipelining or windowing multiple RPC READ/WRITE requests to the server. The flexibility of the NFS and ONCRPC protocols allow for implementations to use this type of adaptation to provide efficient use of the network connection.
NFS目前具有的特性为读取和写入文件数据提供了良好的吞吐量。这通常是通过客户端使用管道或窗口将多个RPC读/写请求发送到服务器来实现的。NFS和ONCRPC协议的灵活性允许实现使用这种类型的自适应来提供对网络连接的有效利用。
However, the number of RPCs required to accomplish some tasks combined with high latency network environments may lead to sluggish single user or single client response. The protocol should continue to provide good raw read and write throughput while addressing the issue of network latency. This issue is discussed further in the section on Internet Accessibility.
但是，完成某些任务所需的RPC数量与高延迟网络环境相结合，可能会导致单用户或单客户端响应缓慢。协议应继续提供良好的原始读写吞吐量，同时解决网络延迟问题。这一问题将在“互联网无障碍性”一节中进一步讨论。
In an attempt to speed response time and to reduce network and server load, NFS clients have always cached directory and file data.
为了加快响应时间并减少网络和服务器负载，NFS客户端始终缓存目录和文件数据。
However, this has usually been done as memory cache and in relatively recent history, local disk caching has been added.
然而，这通常是作为内存缓存完成的，在相对较新的历史中，添加了本地磁盘缓存。
It is very desirable to have the NFS client cache directory and file data. Other distributed file systems have shown that aggressive client side caching can be very visible to the end user in the form of decreasing overall response time. For AFS and DCE/DFS, caching is accomplished by the utilization of server call backs to notify the client of potential cache invalidation. CIFS and its opportunistic locks provide a similar call back mechanism. Clients in both of these environments are able to cache data while avoiding interaction with the network and server.
非常需要NFS客户端缓存目录和文件数据。其他分布式文件系统已经表明，最终用户可以通过减少总体响应时间的形式非常容易看到积极的客户端缓存。对于AFS和DCE/DFS，缓存是通过利用服务器回调通知客户端缓存可能失效来完成的。CIFS及其机会锁提供了类似的回调机制。这两种环境中的客户端都能够缓存数据，同时避免与网络和服务器的交互。
With these protocols it is also possible to cache or delay certain protocol requests at the client which further reduces the protocol traffic flowing between client and server. In the case of CIFS, it is possible for a client to obtain an opportunistic lock for a file and subsequently process file lock requests completely at the client. If there are no conflicts with other clients for file data access, the server is never contacted for the file locking traffic generated by the user application. This behavior is not a protocol requirement but is allowed by the protocol as an implementation option to improve performance.
使用这些协议，还可以在客户端缓存或延迟某些协议请求，从而进一步减少客户端和服务器之间的协议流量。在CIFS的情况下，客户端可以获得文件的机会锁，然后在客户端完全处理文件锁请求。如果在文件数据访问方面与其他客户端没有冲突，则不会联系服务器以获取用户应用程序生成的文件锁定流量。此行为不是协议要求，但协议允许将其作为提高性能的实现选项。
NFS versions 2 and 3 make no caching requirements. Implementations typically implement close-to-open cache consistency which requires clients flush all changes to the server on each file close, and check for file changes on the server on each file open. The consistency check required on each file open can generate a large amount of GETATTR traffic. With this approach, there are windows when the client can still be acting with stale data between the open and close of a file.
NFS版本2和3没有缓存要求。实现通常实现从关闭到打开的缓存一致性，这要求客户端在每次文件关闭时刷新对服务器的所有更改，并在每次文件打开时检查服务器上的文件更改。每个打开的文件所需的一致性检查可能会产生大量GETATTR流量。通过这种方法，在打开和关闭文件之间，客户端仍然可以处理过时数据的窗口仍然存在。
Client caching is increasingly important for Internet environments where throughput can be limited and response time can grow significantly. Therefore the NFS version 4 caching design will need to take into account the full spectrum of caching designs as exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS, etc. in determining an appropriate design. This will need to be done while weighing the complexity of each possible approach with the need of the eventual users and operating environments into which NFS version 4 may be deployed. Some of these considerations are: Internet accessibility, firewall traversal (call back availability), proxy caching, low-overhead or simple clients.
客户端缓存对于吞吐量可能受到限制且响应时间可能显著增长的Internet环境来说越来越重要。因此，在确定合适的设计时，NFS版本4缓存设计需要考虑各种缓存设计，如NFS、AFS、DCE/DFS、CIFS等当前技术所示。这需要在权衡每种可能方法的复杂性与最终用户的需要以及可能部署NFS版本4的操作环境的同时完成。其中一些考虑因素包括：Internet可访问性、防火墙穿越（回拨可用性）、代理缓存、低开销或简单客户端。
An extension of client caching is the provision for disconnected operation at the client. With the ability to cache directory and file data aggressively, a client could then provide service to the end user while disconnected from the server or network.
客户端缓存的扩展是为客户端断开连接的操作提供的。有了主动缓存目录和文件数据的能力，客户机就可以在与服务器或网络断开连接时向最终用户提供服务。
While very desirable, disconnected operation has the potential to inflict itself upon the NFS protocol in an undesirable way as compared to traditional client caching. Given the complexities of disconnected client operation and subsequent resolution of client data modification through various playback or data selection mechanisms, disconnected operation should not be a requirement for the NFS effort. Even so, the NFS protocol should consider the potential layering of disconnected operation solutions on top of the NFS protocol (as with other server and client solutions). The experiences with Coda, disconnected AFS and others should be helpful in this area. (see references)
虽然非常理想，但与传统的客户端缓存相比，断开连接的操作有可能以不理想的方式对NFS协议造成影响。考虑到断开连接的客户端操作的复杂性以及通过各种回放或数据选择机制对客户端数据修改的后续解决方案，断开连接的操作不应该是NFS工作的要求。即使如此，NFS协议应该考虑在NFS协议（与其他服务器和客户端解决方案一样）之上的断开操作解决方案的潜在分层。在这方面，尾波、断开AFS和其他方面的经验应该有所帮助。（见参考资料）
The NFS protocols are available for many different operating environments. Even though this shows the protocol's ability to provide distributed file system service for more than a single operating system, the design of NFS is certainly Unix-centric. The next NFS protocol needs to be more inclusive of platform or file system features beyond those of traditional Unix.
NFS协议可用于许多不同的操作环境。尽管这表明该协议能够为多个操作系统提供分布式文件系统服务，但NFS的设计肯定是以Unix为中心的。下一个NFS协议需要更多地包含传统Unix以外的平台或文件系统功能。
Because of Unix-centric origins, NFS version 2 and 3 protocol requirements have been difficult to implement in some environments. For example, persistent file handles (unique identifiers of file system objects), Unix uid/gid mappings, directory modification time, accurate file sizes, file/directory locking semantics (SHAREs, PC-style locking). In the design of NFS version 4, these areas and others not mentioned will need to be considered and, if possible, cross-platform solutions developed.
由于以Unix为中心的起源，NFS版本2和3协议要求在某些环境中很难实现。例如，持久性文件句柄（文件系统对象的唯一标识符）、Unix uid/gid映射、目录修改时间、准确的文件大小、文件/目录锁定语义（共享、PC风格的锁定）。在NFS版本4的设计中，需要考虑这些领域和其他未提及的领域，如果可能，还需要开发跨平台的解决方案。
NFS versions 2 and 3 do not provide for file or directory attributes beyond those that are found in the traditional Unix environment. For example the user identifier/owner of the file, a permission or access bitmap, time stamps for modification of the file or directory and file size to name a few. While the current set of attributes has usually been sufficient, the file system's ability to manage additional information associated with a file or directory can be useful.
NFS版本2和3不提供传统Unix环境中的文件或目录属性以外的文件或目录属性。例如，文件的用户标识符/所有者、权限或访问位图、修改文件或目录的时间戳以及文件大小等等。虽然当前的一组属性通常已经足够了，但文件系统管理与文件或目录相关的附加信息的能力可能会很有用。
There are many possibilities for additional attributes in the next version of NFS. Some of these include: object creation timestamp, user identifier of file's creator, timestamp of last backup or archival bit, version number, file content type (MIME type), existence of data management involvement (i.e. DMAPI [XDSM]).
在下一个版本的NFS中，有许多附加属性的可能性。其中包括：对象创建时间戳、文件创建者的用户标识符、上次备份或存档位的时间戳、版本号、文件内容类型（MIME类型）、是否存在数据管理参与（即DMAPI[XDSM]）。
This list is representative of the possibilities and is meant to show the need for an additional attribute set. Enumerating the 'correct' set of attributes, however, is difficult. This is one of the reasons for looking towards a minor versioning mechanism as a way to provide needed extensibility. Another way to provide some extensibility is to support a generalized named attribute mechanism. This mechanism would allow a client to name, store and retrieve arbitrary data and have it associated as an attribute of a file or directory.
此列表代表了各种可能性，旨在显示对附加属性集的需要。然而，枚举“正确”的属性集是困难的。这是寻求一种次要版本控制机制以提供所需扩展性的原因之一。提供某种可扩展性的另一种方法是支持通用的命名属性机制。这种机制允许客户端命名、存储和检索任意数据，并将其作为文件或目录的属性进行关联。
One difficulty in providing named attributes is determining if the protocol should specify the names for the attributes, their type or structure. How will the protocol determine or allow for attributes that can be read but not written is another issue. Yet another could be the side effects that these attributes have on the core set of file properties such as setting a size attribute to 0 and having associated file data deleted.
提供命名属性的一个困难是确定协议是否应该指定属性的名称、类型或结构。协议如何确定或允许可以读取但不能写入的属性是另一个问题。还有一个可能是这些属性对核心文件属性集的副作用，例如将size属性设置为0并删除关联的文件数据。
As these brief examples show, this type of extended attribute mechanism brings with it a large set of issues that will need to be addressed in the protocol specification while keeping the overall
正如这些简短的示例所示，这种类型的扩展属性机制带来了大量的问题，这些问题需要在协议规范中加以解决，同时保持总体性能
goal of simplicity in mind.
在头脑中简单的目标。
There are operating environments that provide named or extended attribute mechanisms. Digital Unix provides for the storage of extended attributes with some generalized format. HPFS [HPFS] and NTFS [Nagar] also provide for named data associated with traditional files. SGI's local file system, XFS, also provides for this type of name/value extended attributes. However, there does not seem to be a clear direction that can be taken from these or other environments.
存在提供命名或扩展属性机制的操作环境。数字Unix提供了一些通用格式的扩展属性存储。HPFS[HPFS]和NTFS[Nagar]还提供与传统文件关联的命名数据。SGI的本地文件系统XFS也提供这种类型的名称/值扩展属性。然而，似乎没有一个明确的方向可以从这些或其他环境中获得。
Access Control Lists (ACL) can be viewed as one specific type of extended attribute. This attribute is a designation of user access to a file or directory. Many vendors have created ancillary protocols to NFS to extend the server's ACL mechanism across the network. Generally this has been done for homogeneous operating environments. Even though the server still interprets the ACL and has final control over access to a file system object, the client is able to manipulate the ACL via these additional protocols. Other distributed file systems have also provided ACL support (DFS, AFS and CIFS).
访问控制列表（ACL）可以看作是一种特定类型的扩展属性。此属性表示用户对文件或目录的访问权限。许多供应商已经创建了NFS的辅助协议，以在网络上扩展服务器的ACL机制。一般来说，这是在同质操作环境下完成的。即使服务器仍然解释ACL并最终控制对文件系统对象的访问，客户机也能够通过这些附加协议操纵ACL。其他分布式文件系统也提供了ACL支持（DFS、AFS和CIFS）。
The basic factor driving the requirement for ACL support in all of these file systems has been the user's desire to grant and restrict access to file system data on a per user basis. Based on the desire of the user and current distributed file system support, it seems to be a requirement that NFS provide this capability as well.
在所有这些文件系统中，驱动ACL支持需求的基本因素是用户希望在每个用户的基础上授予和限制对文件系统数据的访问。基于用户的需求和当前的分布式文件系统支持，NFS似乎也需要提供这种功能。
Because many local and distributed file system ACL implementations have been done without a common architecture, the major issue is one of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and Windows NT ACLs have a similar structure in an array of Access Control Entries consisting of a type field, identity, and permission bits, the similarity ends there. Each model defines its own variants of entry types, identifies users and groups differently, provides different kinds of permission bits, and describes different procedures for ACL creation, defaults, and evaluation.
因为许多本地和分布式文件系统ACL实现都是在没有公共体系结构的情况下实现的，所以主要问题是兼容性。尽管POSIX草稿、DCE/DFS[DCEACL]和Windows NT ACL在由类型字段、标识和权限位组成的访问控制条目数组中具有相似的结构，但相似性到此为止。每个模型定义自己的条目类型变体，以不同的方式标识用户和组，提供不同类型的权限位，并描述ACL创建、默认设置和评估的不同过程。
In the least it will be problematic to create a workable ACL mechanism that will encompass a reasonable set of functionality for all operating environments. Even with the complicated nature of ACL support it is still worthwhile to work towards a solution that can at least provide basic functionality for the user.
至少，创建一个可行的ACL机制是有问题的，该机制将包含一组适用于所有操作环境的合理功能。即使ACL支持的性质很复杂，仍然值得为至少可以为用户提供基本功能的解决方案而努力。
NFS relies on the security mechanisms provided by the ONCRPC [RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS security flavor [RFC2203], NFS security was generally limited to none (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not successful in providing readily available security for NFS because of a lack of widespread implementation which precluded widespread deployment. Also the Diffie-Hellman 192 bit public key modulus used for the AUTH_DH security flavor quickly became too small for reasonable security.
NFS依赖于ONCRPC[RFC1831]协议提供的安全机制。在引入ONCRPC-RPCSEC_-GSS安全风格[RFC2203]之前，NFS安全性通常仅限于none（AUTH_-SYS）或DES（AUTH_-DH）。AUTH_DH security flavor未能成功地为NFS提供现成的安全性，因为缺乏广泛的实现，从而妨碍了广泛的部署。此外，用于AUTH_DH安全特性的Diffie-Hellman 192位公钥模数很快变得太小，无法实现合理的安全性。
NFS has been limited to the use of the Unix-centric user identification mechanism of numeric user id based on the available file system attributes and the use of the ONCRPC. However, for NFS to move beyond the limits of large work groups, user identification should be string based and the definition of the user identifier should allow for integration into an external naming service or services.
NFS仅限于基于可用文件系统属性和ONCRPC的使用，使用以Unix为中心的数字用户标识机制。但是，要使NFS超越大型工作组的限制，用户标识应基于字符串，并且用户标识符的定义应允许集成到外部命名服务中。
Internet scaling should also be considered for this as well. The identification mechanism should take into account multiple naming domains and multiple naming mechanisms. Flexibility is the key to a solution that can grow with the needs of the user and administrator.
为此，还应考虑互联网扩展。标识机制应考虑多个命名域和多个命名机制。灵活性是解决方案的关键，它可以随着用户和管理员的需求而增长。
If NFS is to move among various naming and security services, it may be necessary to stay with a string based identification. This would allow for servers and clients to translate between the external string representation to a local or internal numeric (or other identifier) which matches internal implementation needs.
如果NFS要在各种命名和安全服务之间移动，可能需要使用基于字符串的标识。这将允许服务器和客户机将外部字符串表示转换为符合内部实现需要的本地或内部数字（或其他标识符）。
As an example, DFS uses a string based naming scheme but translates the name to a UUID (16 byte identifier) that is used for internal protocol representations. The DCE/DFS string name is a combination of cell (administrative domain) and user name. As mentioned, NFS clients and servers map a Unix user name to a 32 bit user identifier that is then used for ONCRPC and NFS protocol fields requiring the user identifier.
例如，DFS使用基于字符串的命名方案，但将名称转换为用于内部协议表示的UUID（16字节标识符）。DCE/DFS字符串名称是单元格（管理域）和用户名的组合。如前所述，NFS客户端和服务器将Unix用户名映射到32位用户标识符，然后用于需要用户标识符的ONCRPC和NFS协议字段。
Because of the aforementioned problems, user authentication has been a major issue for ONCRPC and hence NFS. To satisfy requirements of the IETF and to address concerns and requirements from users, NFS version 4 must provide for the use of acceptable security mechanisms. The various mechanisms currently available should be explored for
由于上述问题，用户身份验证一直是ONCRPC和NFS的主要问题。为了满足IETF的要求并解决用户的担忧和要求，NFS版本4必须提供可接受的安全机制。应探讨目前可用的各种机制，以供参考
their appropriate use with NFS version 4 and ONCRPC. Some of these mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510], IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server interaction, the RPCSEC_GSS [RFC2203] framework should be strongly considered since it provides a method to employ mechanisms like SPKM and KerberosV5. Before a security mechanism can be evaluated, the NFS environment and requirements must be discussed.
它们在NFS版本4和ONCRPC中的适当使用。其中一些机制是：TLS[RFC2246]、SPKM[RFC2025]、KerberbosV5[RFC1510]、IPSEC[RFC2401]。由于ONCRPC是NFS客户机和服务器交互的基础，因此应重点考虑RPCSEC_GSS[RFC2203]框架，因为它提供了一种使用SPKM和KerberosV5等机制的方法。在评估安全机制之前，必须讨论NFS环境和需求。
As mentioned later in this document in the section "Internet Accessibility", transport independence is an asset for NFS and ONCRPC and is a general requirement. This allows for transport choice based on the target environment and specific application of NFS. The most common transports in use with NFS are UDP and TCP. This ability to choose transport should be maintained in combination with the user's choice of a security mechanism. This implies that "mandatory to implement" security mechanisms for NFS should allow for both connection-less and connection-oriented transports.
正如本文档后面“Internet可访问性”一节中提到的，传输独立性是NFS和ONCRPC的一项资产，是一项一般要求。这允许根据目标环境和NFS的特定应用程序选择传输。NFS中最常见的传输是UDP和TCP。这种选择传输的能力应该与用户选择的安全机制相结合。这意味着NFS的“强制实现”安全机制应同时允许无连接和面向连接的传输。
As should be expected, strong authentication is a requirement for NFS version 4. Each operation generated via ONCRPC contains user identification and authentication information. It is common in NFS version 2 and 3 implementations to multiplex various users' requests over a single or few connections to the NFS server. This allows for scalability in the number of clients systems. Security mechanisms or frameworks should allow for this multiplexing of requests to sustain the implementation model that is available today.
正如预期的那样，NFS版本4需要强身份验证。通过ONCRPC生成的每个操作都包含用户标识和身份验证信息。在NFS版本2和3的实现中，通过一个或几个到NFS服务器的连接来多路传输不同用户的请求是很常见的。这允许客户机系统数量的可伸缩性。安全机制或框架应允许这种请求的多路复用，以维持目前可用的实现模型。
Until the introduction of RPCSEC_GSS, the ability to provide data integrity over ONCRPC and to NFS was not available. Since file and directory data is the essence of a distributed file service, the NFS protocol should provide to the users of the file service a reasonable level of data integrity. The security mechanisms chosen must provide for NFS data protection with a cryptographically strong checksum. As with other aspects within NFS version 4, the user or administrator should be able to choose whether data integrity is employed. This will provide needed flexibility for a variety of NFS version 4 solutions.
在引入RPCSEC_GSS之前，无法通过ONCRPC和NFS提供数据完整性。由于文件和目录数据是分布式文件服务的本质，NFS协议应该为文件服务的用户提供合理级别的数据完整性。所选择的安全机制必须为NFS数据提供加密强校验和保护。与NFS版本4中的其他方面一样，用户或管理员应该能够选择是否采用数据完整性。这将为各种NFS版本4解决方案提供所需的灵活性。
Data privacy, while desirable, is not as important in all environments as authentication and integrity. For example, in a LAN environment the performance overhead of data privacy may not be required to meet an organization's data protection policies. It may also be the case that the performance of the distributed file system solution is more important than the data privacy of that solution. Even with these considerations, the user or administrator must have the choice of data privacy and therefore it must be included in NFS version 4.
数据隐私虽然可取，但在所有环境中都不如身份验证和完整性重要。例如，在LAN环境中，可能不需要数据隐私的性能开销来满足组织的数据保护策略。也可能是分布式文件系统解决方案的性能比该解决方案的数据隐私更重要。即使考虑到这些因素，用户或管理员也必须选择数据隐私，因此必须将其包含在NFS版本4中。
With the ability to provide security mechanism choices to the user or administrator, NFS version 4 should offer reasonable flexibility for application of local security policies. However, this presents the problem of negotiating the appropriate security mechanism between client and server. It is unreasonable to require the client know the server's chosen mechanism before initial contact. The issue is further complicated by an administrator who may choose more than one security mechanism for the various file system resources being shared by an NFS server. These types of choices and policies require that NFS version 4 deal with negotiating the appropriate security mechanism based on mechanism availability and policy deployment at client and server. This negotiation will need to take into account the possibility of a change in policy as an NFS client crosses certain file system boundaries at the server. The security mechanisms required may change at these boundaries and therefore the negotiation must be included within the NFS protocol itself to be done properly (i.e. securely).
由于能够为用户或管理员提供安全机制选择，NFS版本4应该为本地安全策略的应用提供合理的灵活性。然而，这就带来了在客户端和服务器之间协商适当的安全机制的问题。在初次接触之前要求客户机知道服务器选择的机制是不合理的。管理员可能会为NFS服务器共享的各种文件系统资源选择多个安全机制，这使得问题更加复杂。这些类型的选择和策略要求NFS版本4根据机制可用性和客户端和服务器上的策略部署协商适当的安全机制。此协商将需要考虑策略更改的可能性，因为NFS客户端在服务器上跨越某些文件系统边界。所需的安全机制可能会在这些边界处发生变化，因此协商必须包含在NFS协议本身中才能正确完成（即安全地进行）。
Other distributed file system solutions such as AFS and DFS provide strong authentication mechanisms. CIFS does provide authentication at initial server contact and a message signing option for subsequent interaction. Recent NFS version 2 and 3 implementations, with the use of RPCSEC_GSS, provide strong authentication, integrity, and privacy.
其他分布式文件系统解决方案（如AFS和DFS）提供了强大的身份验证机制。CIFS在初始服务器联系时提供身份验证，并为后续交互提供消息签名选项。使用RPCSEC_GSS的最新NFS版本2和3实现提供了强大的身份验证、完整性和隐私。
NFS version 4 must provide for strong authentication, integrity, and privacy. This must be part of the protocol so that users have the choice to use strong security if their environment or policies warrant such use.
NFS版本4必须提供强身份验证、完整性和隐私。这必须是协议的一部分，以便用户可以选择在其环境或策略允许的情况下使用强安全性。
Based on the requirements presented, the ONCRPC RPCSEC_GSS security flavor seems to provide an appropriate framework for satisfying these requirements. RPCSEC_GSS provides for authentication, integrity, and privacy. The RPCSEC_GSS is also extensible in that it provides for both public and private key security mechanisms along with the ability to plug in various mechanisms in such a way that it does not significantly disrupt ONCRPC or NFS implementations.
基于提出的需求，ONCRPC RPCSEC_GSS安全风格似乎为满足这些需求提供了合适的框架。RPCSEC_GSS提供身份验证、完整性和隐私。RPCSEC_GSS还具有可扩展性，因为它提供了公钥和私钥安全机制，并能够以不会显著中断ONCRPC或NFS实现的方式插入各种机制。
With RPCSEC_GSS' ability to support both public and private key mechanisms, NFS version 4 should consider "mandatory to implement" choices from both. The intent is to provide a security solution that will flexibly scale to match the needs of end users. Providing this range of solutions will allow for appropriate usage based on policy and available resources for deployment. Note that, in the end, the user must have a choice and that choice may be to use all of the available mechanisms in NFS version 4 or none of them.
使用RPCSECGIGSS支持公钥和私钥机制的能力，NFS版本4应该考虑从两个方面强制执行“选择”。其目的是提供一个安全解决方案，该解决方案将灵活扩展以满足最终用户的需求。提供这一系列的解决方案将允许基于策略和可供部署的资源进行适当的使用。请注意，最终，用户必须有一个选择，这个选择可能是使用NFS版本4中的所有可用机制，或者不使用任何机制。
Being a product of an IETF working group, the NFS protocol should not only be built upon IETF technologies where possible but should also work well within the broader Internet environment.
作为IETF工作组的产品，NFS协议不仅应尽可能建立在IETF技术的基础上，而且还应在更广泛的互联网环境中运行良好。
As with any network protocol, congestion control is a major issue and the transport mechanisms that are chosen for NFS should take this into account. Traditionally, implementations of NFS have been deployed using both UDP and TCP. With the use of UDP, most implementations provide a rudimentary attempt control congestion with simple back-off algorithms and round trip timers. While this may be sufficient in today's NFS deployments, as an Internet protocol NFS will need to ensure sufficient congestion control or management.
与任何网络协议一样，拥塞控制是一个主要问题，为NFS选择的传输机制应该考虑到这一点。传统上，NFS的实现都是使用UDP和TCP部署的。通过使用UDP，大多数实现都提供了一种基本的尝试，即使用简单的退避算法和往返计时器来控制拥塞。虽然这在今天的NFS部署中可能已经足够了，但作为一种Internet协议，NFS将需要确保足够的拥塞控制或管理。
With congestion control in mind, NFS must use TCP as a transport (via ONCRPC). The UDP transport provides its own advantages in certain circumstances. In today's NFS implementations, UDP has been shown to produce greater throughput as compared to similarly configured systems that use TCP. This issue will need to be investigated such that a determination can be made as to whether the differences are within implementation details. If UDP is supplied as an NFS transport mechanism, then the congestion controls issues will need resolution to make its use suitable.
考虑到拥塞控制，NFS必须使用TCP作为传输（通过ONCRPC）。UDP传输在某些情况下提供了自己的优势。在今天的NFS实现中，与使用TCP的类似配置系统相比，UDP已被证明能够产生更大的吞吐量。需要对该问题进行调查，以便确定差异是否在实施细节范围内。如果UDP是作为NFS传输机制提供的，则需要解决拥塞控制问题以使其适用。
NFS's protocol design should allow its use via Internet firewalls. The protocol should also allow for the use of file system proxy/cache servers. Proxy servers can be very useful for scalability and other reasons. The NFS protocol needs to address the need of proxy servers in a way that will deal with the issues of security, access control, content control, and cache content validation. It is possible that these issues can be addressed by documenting the related issues of proxy server usage. However, it is likely that the NFS protocol will need to support proxy servers directly through the NFS protocol.
NFS的协议设计应该允许通过Internet防火墙使用它。该协议还应允许使用文件系统代理/缓存服务器。由于可伸缩性和其他原因，代理服务器非常有用。NFS协议需要以处理安全性、访问控制、内容控制和缓存内容验证问题的方式满足代理服务器的需求。这些问题可以通过记录代理服务器使用的相关问题来解决。但是，NFS协议可能需要通过NFS协议直接支持代理服务器。
The protocol could allow a request to be sent to a proxy that contains the name of the target NFS server to which the request might be forwarded, or from which a response might be cached. In any case, the NFS proxy server should be considered during protocol development.
该协议可以允许将请求发送到代理，该代理包含请求可能转发到的目标NFS服务器的名称，或者可能缓存响应的目标NFS服务器的名称。在任何情况下，在协议开发过程中都应该考虑NFS代理服务器。
The problems encountered in making the NFS protocol work through firewalls are described in detail in [RFC2054] and [RFC2055].
[RFC2054]和[RFC2055]详细描述了使NFS协议通过防火墙工作时遇到的问题。
As an application at the NFS client performs simple file system operations, multiple NFS operations or RPCs may be executed to accomplish the work for the application. While the NFS version 3 protocol addressed some of this by returning file and directory attributes for most procedures, hence reducing follow up GETATTR requests, there is still room for improvement. Reducing the number of RPCs will lead to a reduction of processing overhead on the server (transport and security processing) along with reducing the time spent at the client waiting for the server's individual responses. This issue is more prominent in environments with larger degrees of latency.
当NFS客户端的应用程序执行简单的文件系统操作时，可以执行多个NFS操作或RPC来完成应用程序的工作。尽管NFS版本3协议通过为大多数过程返回文件和目录属性解决了一些问题，从而减少了后续GETATTR请求，但仍有改进的余地。减少RPC的数量将减少服务器上的处理开销（传输和安全处理），同时减少客户端等待服务器单独响应的时间。在延迟程度较大的环境中，此问题更为突出。
The CIFS file access protocol supports 'batched requests' that allow multiple requests to be batched, therefore reducing the number of round trip messages between client and server.
CIFS文件访问协议支持允许对多个请求进行批处理的“批处理请求”，因此减少了客户端和服务器之间的往返消息数。
This same approach can be used by NFS to allow the grouping of multiple procedure calls together in a traditional RPC request. Not only would this reduce protocol imposed latency but it would reduce transport and security processing overhead and could allow a client to complete more complex tasks by combining procedures.
NFS也可以使用同样的方法来允许在传统的RPC请求中将多个过程调用分组在一起。这不仅可以减少协议强加的延迟，还可以减少传输和安全处理开销，并允许客户端通过组合过程来完成更复杂的任务。
NFS provided Unix file locking and DOS SHARE capability with the use of an ancillary protocol (Network Lock Manager / NLM). The DOS SHARE mechanism is the DOS equivalent of file locking in that it provides the basis for sharing or exclusive access to file and directory data without risk of data corruption. The NLM protocol provides file locking and recovery of those locks in the event of client or server failure. The NLM protocol requires that the server make call backs to the client for certain scenarios and therefore is not necessarily well suited for Internet firewall traversal.
NFS通过使用辅助协议（网络锁管理器/NLM）提供了Unix文件锁定和DOS共享功能。DOS共享机制相当于DOS文件锁定，因为它提供了共享或独占访问文件和目录数据的基础，而不会有数据损坏的风险。NLM协议在客户端或服务器发生故障时提供文件锁定和这些锁定的恢复。NLM协议要求服务器在某些情况下回调客户端，因此不一定适合Internet防火墙穿越。
Available and correct file locking support for NFS version 2 and 3 clients and servers has historically been problematic. The availability of NLM support has traditionally been a problem and seems to be most related to the fact that NFS and NLM are two separate protocols. It is easy to deliver an NFS client and server implementation and then add NLM support later. This led to a general lack of NLM support early on in NFS' lifetime. One of the reasons that NLM was delivered separately has been its relative complexity which has in turn led to poor implementations and testing difficulties. Even in later implementations where reliability and performance had been increased to acceptable levels for NLM, users still chose to avoid the use of the protocol and its support. The last issue with NLM is the presence of minor protocol design flaws that relate to high network load and recovery.
NFS版本2和版本3客户端和服务器的可用且正确的文件锁定支持历来存在问题。NLM支持的可用性历来是一个问题，并且似乎与NFS和NLM是两个独立协议这一事实最为相关。很容易交付NFS客户端和服务器实现，然后在以后添加NLM支持。这导致在NFS生命周期的早期普遍缺乏NLM支持。NLM单独交付的原因之一是其相对复杂，这反过来又导致了较差的实现和测试困难。即使在后来的实现中，可靠性和性能已经提高到NLM可接受的水平，用户仍然选择避免使用协议及其支持。NLM的最后一个问题是存在与高网络负载和恢复相关的次要协议设计缺陷。
Based on the experiences with NLM, locking support for NFS version 4 should strive to meet or at least consider the following (in order of importance):
基于NLM的经验，NFS版本4的锁定支持应该努力满足或至少考虑以下（按重要性排序）：
o Integration with the NFS protocol and ease of implementation.
o 与NFS协议集成，易于实现。
o Interoperability between operating environments. The protocol should make a reasonable effort to support the locking semantics of both PC and Unix clients and servers. This will allow for greater integration of all environments.
o 操作环境之间的互操作性。协议应尽合理努力支持PC和Unix客户端和服务器的锁定语义。这将允许更好地集成所有环境。
o Scalable solutions - thousands of clients. The server should not be required to maintain significant client file locking state between server instantiations.
o 可扩展的解决方案—数千个客户端。不应要求服务器在服务器实例化之间保持重要的客户端文件锁定状态。
o Internet capable (firewall traversal, latency sensitive). The server should not be required to initiate TCP connections to clients.
o 支持Internet（防火墙穿越，延迟敏感）。不应要求服务器启动到客户端的TCP连接。
o Timely recovery in the event of client/server or network failure. Server recovery should be rapid. The protocol should allow clients to detect the loss of a lock.
o 在客户端/服务器或网络出现故障时及时恢复。服务器恢复应该是快速的。该协议应允许客户端检测锁的丢失。
NFS version 2 and 3 are currently limited in the character encoding of strings. In the NFS protocols, strings are used for file and directory names, and symbolic link contents. Although the XDR definition [RFC1832] limits strings in the NFS protocol to 7-bit US-ASCII, common usage is to encode filenames in 8-bit ISO-Latin-1. However, there is no mechanism available to tag XDR character strings to indicate the character encoding used by the client or server. Obviously this limits NFS' usefulness in an environment with clients that may operate with various character sets.
NFS版本2和3目前在字符串的字符编码方面受到限制。在NFS协议中，字符串用于文件和目录名以及符号链接内容。尽管XDR定义[RFC1832]将NFS协议中的字符串限制为7位US-ASCII，但通常使用8位ISO-Latin-1编码文件名。但是，没有任何机制可用于标记XDR字符串以指示客户端或服务器使用的字符编码。显然，这限制了NFS在客户端可能使用各种字符集的环境中的用途。
One approach to address this deficiency is to use the Unicode Standard [Unicode1] as the means to exchange character strings for the NFS version 4 protocol. The Unicode Standard is a 16 bit encoding that supports full multilingual text. The Unicode Standard is code-for-code identical with International Standard ISO/IEC 10646-1:1993. "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because Unicode is a 16 bit encoding, it may be more efficient for the NFS version 4 protocol to use an encoding for wire transfer that will be useful for a majority of usage. One possible encoding is the UCS transformation format (UTF). UTF-8 is an encoding method for UCS-4 characters which allows for the direct encoding of US-ASCII characters but expands for the correct encoding of the full UCS-4 31 bit definitions. Currently, the UCS-4 and Unicode standards do not diverge.
解决这一缺陷的一种方法是使用Unicode标准[Unicode1]作为为NFS版本4协议交换字符串的手段。Unicode标准是一种16位编码，支持完整的多语言文本。Unicode标准是与国际标准ISO/IEC 10646-1:1993相同的代码对代码。“信息技术——通用多八位编码字符集（UCS）——第1部分：体系结构和基本多语言平面。”由于Unicode是一种16位编码，NFS版本4协议可能更有效地使用对大多数使用有用的有线传输编码。一种可能的编码是UCS转换格式（UTF）。UTF-8是UCS-4字符的一种编码方法，允许直接编码US-ASCII字符，但扩展后可正确编码完整的UCS-4 31位定义。目前，UCS-4和Unicode标准没有分歧。
This Unicode/UTF-8 encoding can be used for places in the protocol that a traditional string representation is needed. This includes file and directory names along with symlink contents. This should also include other file and directory attributes that are eventually defined as strings.
这种Unicode/UTF-8编码可用于协议中需要传统字符串表示的位置。这包括文件和目录名以及符号链接内容。这还应该包括最终定义为字符串的其他文件和目录属性。
The Unicode standard is applicable to the well defined strings within the protocol. Dealing with file content is much more difficult. NFS has traditionally dealt with file data as an opaque byte stream. No other structure or content specification has been levied upon the file content. The main advantage to this approach is its flexibility. This byte stream can contain any data content and may be accessed in any sequential or random fashion. Unfortunately, it is left to the application or user to make the determination of file content and format. It is possible to construct a mechanism in the protocol that specifies file data type while maintaining the byte stream model for
Unicode标准适用于协议中定义良好的字符串。处理文件内容要困难得多。NFS传统上将文件数据作为不透明字节流处理。没有对文件内容施加任何其他结构或内容规范。这种方法的主要优点是灵活性。该字节流可以包含任何数据内容，并且可以以任何顺序或随机方式访问。不幸的是，由应用程序或用户决定文件内容和格式。可以在协议中构造一种机制来指定文件数据类型，同时维护文件的字节流模型
data access. However, this approach may be limiting in ways unclear to the designers of the NFS version 4 protocol. An expandable and adaptable approach is to use the previously discussed extended attributes as the mechanism to specify file content and format. The use of extended attributes allows for future definition and growth as various data types are created and allows for maintaining a simple file data model for the NFS protocol.
数据访问。但是，这种方法可能会以NFS版本4协议的设计者不清楚的方式受到限制。一种可扩展且适应性强的方法是使用前面讨论的扩展属性作为指定文件内容和格式的机制。随着各种数据类型的创建，扩展属性的使用允许将来的定义和增长，并允许为NFS协议维护一个简单的文件数据模型。
It should be noted that as the Unicode standards are currently defined there is the possibility for minor inconsistencies when converting from local character representations to Unicode and then back again. This should not be a problem with single client and server interaction but may become apparent with the interaction of two or more clients with separate conversion implementations. Therefore, as NFS version 4 progresses in its development, these types of Unicode issues need to be tracked and understood for their potential impact on client/server interaction. In any case, Unicode seems to be the best selection for NFS version 4 based on its standards background and apparent future direction.
应该注意的是，由于目前定义了Unicode标准，因此在从本地字符表示转换为Unicode然后再转换回Unicode时，可能会出现轻微的不一致。这对于单个客户机和服务器的交互不应该是一个问题，但是对于两个或多个具有单独转换实现的客户机的交互，这可能会变得很明显。因此，随着NFS版本4的开发，需要跟踪和了解这些类型的Unicode问题对客户机/服务器交互的潜在影响。无论如何，基于标准背景和明显的未来方向，Unicode似乎是NFS版本4的最佳选择。
Two previous sections within this document deal with security issues. The section covering 'Access Control Lists' covers the mechanisms that need to be investigated for file system level control. The section that covers RPC security deals with individual user authentication along with data integrity and privacy issues. This section also covers negotiation of security mechanisms. These sections should be consulted for additional discussion and detail.
本文档中的前两部分涉及安全问题。“访问控制列表”一节介绍了文件系统级控制需要研究的机制。本节介绍RPC安全性，涉及个人用户身份验证以及数据完整性和隐私问题。本节还涉及安全机制的谈判。应参考这些章节进行更多讨论和详细说明。
As with all services, the denial of service by either incorrect implementations or malicious agents is always a concern. With the target of providing NFS version 4 for Internet use, it is all the more important that all aspects of the NFS version 4 protocol be reviewed for potential denial of service scenarios. When found these potential problems should be mitigated as much as possible.
与所有服务一样，错误实现或恶意代理的拒绝服务始终是一个令人担忧的问题。以提供供Internet使用的NFS版本4为目标，更重要的是要审查NFS版本4协议的所有方面，以了解潜在的拒绝服务情况。当发现这些潜在问题时，应尽可能缓解。
[RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.txt
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. http://www.ietf.org/rfc/rfc1510.txt
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。http://www.ietf.org/rfc/rfc1510.txt
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. http://www.ietf.org/rfc/rfc1813.txt
[RFC1813]Callaghan，B.，Pawlowski，B.和P.Staubach，“NFS版本3协议规范”，RFC 1813，1995年6月。http://www.ietf.org/rfc/rfc1813.txt
[RFC1831]
Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.txt
[RFC1831]
Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.txt
[RFC1832]
Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.txt
[RFC1832]
Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.txt
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. http://www.ietf.org/rfc/rfc1833.txt
[RFC1833]Srinivasan，R.，“ONC RPC版本2的绑定协议”，RFC 1833，1995年8月。http://www.ietf.org/rfc/rfc1833.txt
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. http://www.ietf.org/rfc/rfc2025.txt
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。http://www.ietf.org/rfc/rfc2025.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054]Callaghan，B.，“WebNFS客户端规范”，RFC2054，1996年10月。http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996. http://www.ietf.org/rfc/rfc2055.txt
[RFC2055]Callaghan，B.，“WebNFS服务器规范”，RFC20551996年10月。http://www.ietf.org/rfc/rfc2055.txt
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. http://www.ietf.org/rfc/rfc2078.txt
[RFC2078]Linn，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。http://www.ietf.org/rfc/rfc2078.txt
[RFC2152] Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997. http://www.ietf.org/rfc/rfc2152.txt
[RFC2152]Goldsmith，D.，“UTF-7一种Unicode的邮件安全转换格式”，RFC 2152，1997年5月。http://www.ietf.org/rfc/rfc2152.txt
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, August 1995. http://www.ietf.org/rfc/rfc2203.txt
[RFC2203]Eisler，M.，Chiu，A.和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1995年8月。http://www.ietf.org/rfc/rfc2203.txt
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. http://www.ietf.org/rfc/rfc2222.txt
[RFC2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。http://www.ietf.org/rfc/rfc2222.txt
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. http://www.ietf.org/rfc/rfc2279.txt
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。http://www.ietf.org/rfc/rfc2279.txt
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246, Certicom, January 1999. http://www.ietf.org/rfc/rfc2246.txt
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，Certicom，1999年1月。http://www.ietf.org/rfc/rfc2246.txt
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. http://www.ietf.org/rfc/rfc2401.txt
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。http://www.ietf.org/rfc/rfc2401.txt
[DCEACL] The Open Group, Open Group Technical Standard, "DCE 1.1: Authentication and Security Services," Document Number C311, August 1997. Provides a discussion of DEC ACL structure and semantics.
[DCEACL]开放组，开放组技术标准，“DCE 1.1：认证和安全服务”，文件编号C311，1997年8月。提供DEC ACL结构和语义的讨论。
[HPFS] Les Bell and Associates Pty Ltd, "The HPFS FAQ," http://www.lesbell.com.au/hpfsfaq.html
[HPFS]Les Bell and Associates Pty Ltd，“HPFS常见问题解答，”http://www.lesbell.com.au/hpfsfaq.html
[Hutson] Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June 1993. Proc. USENIX Symp. on Mobile and Location-Independent Computing, Cambridge, August 1993.
[Hutson]Huston，L.B.，Honeyman，P.，“AFS的断开操作”，1993年6月。过程。USENIX Symp。关于移动和位置无关计算，剑桥，1993年8月。
[Kistler] Kistler, James J., Satyanarayanan, M., "Disconnected Operations in the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. 1, pp. 3-25, Feb. 1992.
[Kistler]Kistler，James J.，Satyanarayanan，M.，“Coda文件系统中的断开连接操作”，ACM Trans。《计算机系统论》，第10卷，第1期，第3-25页，1992年2月。
[Mummert] Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on Operating Systems Principles Dec. 1995.
[Mummert]Mummert，L.B.，Ebling，M.R.，Satyanarayanan，M.，“利用弱连接进行移动文件访问”，Proc。第15届ACM研讨会。关于操作系统原理，1995年12月。
[Nagar] Nagar, R., "Windows NT File System Internals," ISBN 1565922492, O`Reilly & Associates, Inc.
[Nagar]Nagar，R.，“Windows NT文件系统内部”，ISBN 1565922492，O'Reilly&Associates，Inc。
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design and Implementation of the Sun Network Filesystem," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The basic paper describing the SunOS implementation of the NFS version 2 protocol, and discusses the goals, protocol specification and trade-offs.
[Sandberg]R.，D.Goldberg，S.Kleiman，D.Walsh，B.Lyon，“Sun网络文件系统的设计和实现”，USENIX会议记录，USENIX协会，加利福尼亚州伯克利，1985年夏季。本文描述了NFS版本2协议的SunOS实现，并讨论了目标、协议规范和权衡。
[Satyanarayanan1] Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," Proc. of the ACM Principles of Distributed Computing, 1995.
Satyanarayanan，M.，“移动计算的基本挑战”，Proc。《分布式计算的ACM原理》，1995年。
[Satyanarayanan2] Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R., Kumar, P. , Lu, Q., "Experience with disconnected operation in mobile computing environment," Proc. of the USENIX Symp. on Mobile and Location-Independent Computing, Jun. 1993.
[Satyanarayanan2]Satyanarayanan，M.，Kistler，J.J.，Mummert L.B.，Ebling M.R.，Kumar，P.，Lu，Q.，“移动计算环境中断开连接操作的经验”，Proc。在USENIX研讨会上。关于移动和位置无关计算，1993年6月。
[Unicode1]
"Unicode Technical Report #8 - The Unicode Standard, Version 2.1",
Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose,
CA 95710-0519 USA, September 1998
http://www.unicode.org/unicode/reports/tr8.html
[Unicode1]
"Unicode Technical Report #8 - The Unicode Standard, Version 2.1",
Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose,
CA 95710-0519 USA, September 1998
http://www.unicode.org/unicode/reports/tr8.html
[Unicode2]
"Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O.
Box 700519, San Jose, CA 95710-0519 USA, October 1998
http://www.unicode.org/unicode/standard/unsupported.html
[Unicode2]
"Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O.
Box 700519, San Jose, CA 95710-0519 USA, October 1998
http://www.unicode.org/unicode/standard/unsupported.html
[XDSM] The Open Group, Open Group Technical Standard, "Systems Management: Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January 1997.
[XDSM]开放组，开放组技术标准，“系统管理：数据存储管理（XDSM）API”，ISBN 1-85912-190-X，1997年1月。
[XNFS] The Open Group, Protocols for Interworking: XNFS, Version 3W, The Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 1-85912-184-5, February 1998. HTML version available: http://www.opengroup.org
[XNFS]开放组，互通协议：XNFS，版本3W，开放组，1010 El Camino Real Suite 380，Menlo Park，CA 94025，ISBN 1-85912-184-51998年2月。可提供的HTML版本：http://www.opengroup.org
o Brent Callaghan for content contributions.
o Brent Callaghan的内容贡献。
Address comments related to this memorandum to:
将与本备忘录相关的意见发送至：
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
Spencer Shepler Sun Microsystems, Inc. 7808 Moonflower Drive Austin, Texas 78750
斯宾塞·谢普勒太阳微系统公司，德克萨斯州奥斯汀市月光大道7808号，邮编78750
Phone: (512) 349-9376 EMail: spencer.shepler@eng.sun.com
电话：（512）349-9376电子邮件：斯宾塞。shepler@eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。