Network Working Group S. Shepler

Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999

NFS Version 4 Design Considerations

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.

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.

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.

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.

Shepler Informational [Page 1]

RFC 2624 NFSv4 Design Considerations June 1999

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

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

Shepler Informational [Page 2]

RFC 2624 NFSv4 Design Considerations June 1999

practice will be presented along with other appropriate references to
current distributed file system practice.

2. Ease of Implementation or Complexity of Protocol

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.

2.1. Extensibility / layering

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.

2.2. Managed Extensions or Minor Versioning

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.

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.

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

Shepler Informational [Page 3]

RFC 2624 NFSv4 Design Considerations June 1999

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.

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.

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.

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.

2.3. Relationship with Older Versions of NFS

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.

Shepler Informational [Page 4]

RFC 2624 NFSv4 Design Considerations June 1999

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.

3. Reliable and Available

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.

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.

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.

4. Scalable Performance

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

Shepler Informational [Page 5]

RFC 2624 NFSv4 Design Considerations June 1999

client side caching.

4.1. Throughput and Latency via the Network

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.

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.

4.2. Client Caching

In an attempt to speed response time and to reduce network and server
load, NFS clients have always cached directory and file data.

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.

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.

Shepler Informational [Page 6]

RFC 2624 NFSv4 Design Considerations June 1999

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.

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.

4.3. Disconnected Client Operation

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)

5. Interoperability

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.

Shepler Informational [Page 7]

RFC 2624 NFSv4 Design Considerations June 1999

5.1. Platform Specific Behavior

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.

5.2. Additional or Extended Attributes

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.

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]).

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.

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

Shepler Informational [Page 8]

RFC 2624 NFSv4 Design Considerations June 1999

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.

5.3. Access Control Lists

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).

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.

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.

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.

Shepler Informational [Page 9]

RFC 2624 NFSv4 Design Considerations June 1999

6. RPC Mechanism and Security

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.

6.1. User identification

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.

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.

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.

6.2. Security

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

Shepler Informational [Page 10]

RFC 2624 NFSv4 Design Considerations June 1999

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.

6.2.1. Transport Independence

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.

6.2.2. Authentication

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.

6.2.3. Data Integrity

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.

Shepler Informational [Page 11]

RFC 2624 NFSv4 Design Considerations June 1999

6.2.4. Data Privacy

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.

6.2.5. Security Negotiation

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).

6.3. Summary

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.

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.

Shepler Informational [Page 12]

RFC 2624 NFSv4 Design Considerations June 1999

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.

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.

7. Internet Accessibility

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.

7.1. Congestion Control and Transport Selection

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.

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.

Shepler Informational [Page 13]

RFC 2624 NFSv4 Design Considerations June 1999

7.2. Firewalls and Proxy Servers

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.

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.

The problems encountered in making the NFS protocol work through
firewalls are described in detail in [RFC2054] and [RFC2055].

7.3. Multiple RPCs and Latency

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.

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.

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.

Shepler Informational [Page 14]

RFC 2624 NFSv4 Design Considerations June 1999

8. File locking / recovery

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.

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.

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):

o Integration with the NFS protocol and ease of implementation.

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 Scalable solutions - thousands of clients. The server should
not be required to maintain significant client file locking
state between server instantiations.

o Internet capable (firewall traversal, latency sensitive). The
server should not be required to initiate TCP connections to
clients.

Shepler Informational [Page 15]

RFC 2624 NFSv4 Design Considerations June 1999

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.

9. Internationalization

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.

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.

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.

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

Shepler Informational [Page 16]

RFC 2624 NFSv4 Design Considerations June 1999

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.

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.

10. Security Considerations

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.

10.1. Denial of Service

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.

Shepler Informational [Page 17]

RFC 2624 NFSv4 Design Considerations June 1999

11. Bibliography

[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

[RFC1813]
Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995.
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

[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

[RFC2025]
Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996.
http://www.ietf.org/rfc/rfc2025.txt

[RFC2054]
Callaghan, B., "WebNFS Client Specification", RFC 2054, October
1996.
http://www.ietf.org/rfc/rfc2054.txt

[RFC2055]
Callaghan, B., "WebNFS Server Specification", RFC 2055, October
1996.
http://www.ietf.org/rfc/rfc2055.txt

Shepler Informational [Page 18]

RFC 2624 NFSv4 Design Considerations June 1999

[RFC2078]
Linn, J., "Generic Security Service Application Program Interface,
Version 2", RFC 2078, January 1997.
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

[RFC2203]
Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, August 1995.
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

[RFC2279]
Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
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

[RFC2401]
Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
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.

[HPFS]
Les Bell and Associates Pty Ltd, "The HPFS FAQ,"
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.

Shepler Informational [Page 19]

RFC 2624 NFSv4 Design Considerations June 1999

[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.

[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.

[Nagar]
Nagar, R., "Windows NT File System Internals," 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.

[Satyanarayanan1]
Satyanarayanan, M., "Fundamental Challenges in Mobile Computing,"
Proc. of the ACM Principles of Distributed Computing, 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.

[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

[XDSM]
The Open Group, Open Group Technical Standard, "Systems Management:
Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January
1997.

Shepler Informational [Page 20]

RFC 2624 NFSv4 Design Considerations June 1999

[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

12. Acknowledgments

o Brent Callaghan for content contributions.

13. Author's Address

Address comments related to this memorandum to:

[email protected] -or- [email protected]

Spencer Shepler
Sun Microsystems, Inc.
7808 Moonflower Drive
Austin, Texas 78750

Phone: (512) 349-9376
EMail: [email protected]

Shepler Informational [Page 21]

RFC 2624 NFSv4 Design Considerations June 1999

14. Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

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.

Shepler Informational [Page 22]