RFC relevance of mechanism

As per Relevance of the word mechanism, we have this rfc below:

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

NFS Version 4 Design

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

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

The main task of the NFS version 4 working group is to create
protocol definition for a distributed file system that focuses on
following items: improved access and good performance on
Internet, strong security with negotiation built into the protocol
better cross-platform interoperability, and designed for
extensions. NFS version 4 will owe its general design to
previous versions of NFS. It is expected, however, that
features will be quite different in NFS version 4 than
versions to facilitate the goals of the working group and to
areas that NFS version 2 and 3 have not

This design considerations document is meant to present more
than the working group charter. Specifically, it presents the
that the working group will investigate and consider while
a protocol specification for NFS version 4. Based on
investigation the working group will decide the features of the
protocol based on the cost and benefits within the specific
areas

Key

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.

Shepler Informational [Page 1]

RFC 2624 NFSv4 Design Considerations June 1999

Table of

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

As stated in the charter, the first deliverable for the NFS version 4
working group is this design considerations document. This
is to cover the "limitations and deficiencies of NFS version 3".
This document will also be used as a mechanism to focus
and avenues of investigation as the definition of NFS version 4
progresses. Therefore, the contents of this document cover
general functional/feature areas that are anticipated for NFS
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
current distributed file system practice

2. Ease of Implementation or Complexity of

One of the strengths of NFS has been the ability to implement
client or server with relative ease. The eventual size of a
implementation is relatively small. The main reason for keeping
as simple as possible is that a simple protocol design can
described in a simple specification that promotes straightforward
interoperable implementations. All protocols can run into
when deployed on real networks, but simple protocols yield
that are easier to diagnose and correct

2.1. Extensibility /

With NFS' relative simplicity, the addition or layering
functionality has been easy to accomplish. The addition of
like the client automount or autofs, client side disk caching
high availability servers are examples. This type of
is desirable in an environment where problem solutions do not
protocol revision. This extensibility can also be helpful in
future where unforeseen problems or opportunities can be solved
layering functionality on an existing set of tools or protocol

2.2. Managed Extensions or Minor

For those cases where the NFS protocol is deficient or where a
modification is the best solution for a problem, a minor version or
managed extension could be helpful. There have been instances
NFS version 2 and 3 where small straightforward functional
would have increased the overall value of the protocol immensely
For instance, the PATHCONF procedure that was added to version 2
the MOUNT protocol would have been more appropriate for the
protocol. WebNFS [RFC2054][RFC2055] overloading of the
procedure for NFS versions 2 and 3 would have been more
implemented in a new LOOKUP procedure

However, the perceived size and burden of using a change of
version number for the introduction of new functionality led to no
slow change. It is possible that a new NFS protocol could allow
the rare instance where protocol extension within the RPC
number is the most prudent course and an RPC revision would
unnecessary or impractical

The areas of an NFS protocol which are most obviously volatile
new orthogonal procedures, new well-defined file or
attributes and potentially new file types. As an example,

Shepler Informational [Page 3]

RFC 2624 NFSv4 Design Considerations June 1999

file types of the future could be a type such as "attribute"
represents a named file stream or a "dynamic" file type
generates dynamic data in response to a "query" procedure from
client

It is possible and highly desirable that these types of additions
done without changing the overall design model of NFS
significant effort or delay

A strong consideration should be given to a NFS protocol
for the introduction of this type of new functionality. This
obviously in contrast to using the standard RPC version mechanism
provide minor changes. The process of using RPC version numbers
introduce new functionality brings with it a lot of history which
not technically prevent its use. However, the historical
involved will need to be addressed as part of the NFS version 4
protocol work; this should increase the ability for current
future success of the protocol

As background, the RPC protocol described in [RFC1831] uses a
number to describe the set of procedure calls, replies, and
semantics. Any change in this set must be reflected in a new
number for the program. An example of this was
MOUNTPROC_PATHCONF procedure added in version 2 of the
protocol. Except for the addition of this new procedure,
protocol was unchanged. Many thought this protocol revision
unnecessary, since the RPC protocol already allows certain
not be implemented and defines a PROC_UNAVAIL error

Another historical data-point from NFS version 2 and 3 is the
(or lack) of symbolic links. Servers that cannot support
feature will simply reject calls to the SYMLINK and
procedures. Additionally, NFS version 4 may describe many
attributes which cannot be supported by the server or file systems
the server. Therefore, the protocol must support a
mechanism that allows clients to determine which features of
protocol are supported by a server

2.3. Relationship with Older Versions of

NFS version 4 will be a self contained protocol in that it will
have any dependencies on the previous versions of NFS.
another way, an NFS version 4 server or client will not require
NFSv2 or NFSv3 implementation be present for NFS version 4
function as designed. It should also be noted that having an
version 2 or 3 implementation present at the client or server
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
protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC
will allow the client to appropriately choose an available version
the protocol at the NFS server. The ONCRPC protocol contains
semantics and error returns for the case where an RPC server
does not support a particular version. This mechanism is used by
NFS client to receive notification of an unavailable version and
conjunction with the error the client will also receive the range
versions (min to max) that are available. Therefore, the
mechanism can be used by implementors of both clients and servers
provide for the transitioning to or installation of NFS version 4
services

3. Reliable and

Current NFS protocol design, while placing an emphasis on
server design, has led to timely recovery from server and
failure. This and other aspects to the design have provided a
for layered technologies like high availability and
servers. Providing a protocol design approach that lends itself
these types of reliability and availability features is
desirable

For the next version of NFS, consideration should be given to
side availability schemes such as client switching between or fail
over to available server replicas. NFS currently requires that
handles be immutable; this requirement adds unnecessarily to
complexity of building fail-over configurations. If possible,
protocol should allow for or ease the building of such
solutions

For the next version of NFS, consideration should be given to
that support client switching between server replicas or
available NFS servers that provide paths to data through
servers. For example: NFS currently requires that filehandles
unchanging for any instance of a file or directory. This
makes it more difficult for a client to switch from one server
another, since each server may construct filehandles differently
Protocol support could allow the client to handle a
change

4. Scalable

In designing and developing an NFS protocol from a
viewpoint there are several different points to consider. Each
play a significant role in perceived and real performance from
user's perspective. The three main areas of interest are:
and latency via the network, server work load or scalability

Shepler Informational [Page 5]

RFC 2624 NFSv4 Design Considerations June 1999

client side caching

4.1. Throughput and Latency via the

NFS currently has characteristics that provide good throughput
reading and writing file data. This is commonly achieved by
client's use of pipelining or windowing multiple RPC READ/
requests to the server. The flexibility of the NFS and
protocols allow for implementations to use this type of adaptation
provide efficient use of the network connection

However, the number of RPCs required to accomplish some
combined with high latency network environments may lead to
single user or single client response. The protocol should
to provide good raw read and write throughput while addressing
issue of network latency. This issue is discussed further in
section on Internet Accessibility

4.2. Client

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

However, this has usually been done as memory cache and in
recent history, local disk caching has been added

It is very desirable to have the NFS client cache directory and
data. Other distributed file systems have shown that
client side caching can be very visible to the end user in the
of decreasing overall response time. For AFS and DCE/DFS, caching
accomplished by the utilization of server call backs to notify
client of potential cache invalidation. CIFS and its
locks provide a similar call back mechanism. Clients in both
these environments are able to cache data while avoiding
with the network and server

With these protocols it is also possible to cache or delay
protocol requests at the client which further reduces the
traffic flowing between client and server. In the case of CIFS,
is possible for a client to obtain an opportunistic lock for a
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
by the user application. This behavior is not a protocol
but is allowed by the protocol as an implementation option to
performance

Shepler Informational [Page 6]

RFC 2624 NFSv4 Design Considerations June 1999

NFS versions 2 and 3 make no caching requirements.
typically implement close-to-open cache consistency which
clients flush all changes to the server on each file close, and
for file changes on the server on each file open. The
check required on each file open can generate a large amount
GETATTR traffic. With this approach, there are windows when
client can still be acting with stale data between the open and
of a file

Client caching is increasingly important for Internet
where throughput can be limited and response time can
significantly. Therefore the NFS version 4 caching design will
to take into account the full spectrum of caching designs
exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS
etc. in determining an appropriate design. This will need to be
while weighing the complexity of each possible approach with the
of the eventual users and operating environments into which
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

An extension of client caching is the provision for
operation at the client. With the ability to cache directory
file data aggressively, a client could then provide service to
end user while disconnected from the server or network

While very desirable, disconnected operation has the potential
inflict itself upon the NFS protocol in an undesirable way
compared to traditional client caching. Given the complexities
disconnected client operation and subsequent resolution of
data modification through various playback or data
mechanisms, disconnected operation should not be a requirement
the NFS effort. Even so, the NFS protocol should consider
potential layering of disconnected operation solutions on top of
NFS protocol (as with other server and client solutions).
experiences with Coda, disconnected AFS and others should be
in this area. (see references

5.

The NFS protocols are available for many different
environments. Even though this shows the protocol's ability
provide distributed file system service for more than a
operating system, the design of NFS is certainly Unix-centric.
next NFS protocol needs to be more inclusive of platform or
system features beyond those of traditional Unix

Shepler Informational [Page 7]

RFC 2624 NFSv4 Design Considerations June 1999

5.1. Platform Specific

Because of Unix-centric origins, NFS version 2 and 3
requirements have been difficult to implement in some environments
For example, persistent file handles (unique identifiers of
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
others not mentioned will need to be considered and, if possible
cross-platform solutions developed

5.2. Additional or Extended

NFS versions 2 and 3 do not provide for file or directory
beyond those that are found in the traditional Unix environment.
example the user identifier/owner of the file, a permission or
bitmap, time stamps for modification of the file or directory
file size to name a few. While the current set of attributes
usually been sufficient, the file system's ability to
additional information associated with a file or directory can
useful

There are many possibilities for additional attributes in the
version of NFS. Some of these include: object creation timestamp
user identifier of file's creator, timestamp of last backup
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
the need for an additional attribute set. Enumerating the 'correct
set of attributes, however, is difficult. This is one of the
for looking towards a minor versioning mechanism as a way to
needed extensibility. Another way to provide some extensibility
to support a generalized named attribute mechanism. This
would allow a client to name, store and retrieve arbitrary data
have it associated as an attribute of a file or directory

One difficulty in providing named attributes is determining if
protocol should specify the names for the attributes, their type
structure. How will the protocol determine or allow for
that can be read but not written is another issue. Yet another
be the side effects that these attributes have on the core set
file properties such as setting a size attribute to 0 and
associated file data deleted

As these brief examples show, this type of extended
mechanism brings with it a large set of issues that will need to
addressed in the protocol specification while keeping the

Shepler Informational [Page 8]

RFC 2624 NFSv4 Design Considerations June 1999

goal of simplicity in mind

There are operating environments that provide named or
attribute mechanisms. Digital Unix provides for the storage
extended attributes with some generalized format. HPFS [HPFS]
NTFS [Nagar] also provide for named data associated with
files. SGI's local file system, XFS, also provides for this type
name/value extended attributes. However, there does not seem to be
clear direction that can be taken from these or other environments

5.3. Access Control

Access Control Lists (ACL) can be viewed as one specific type
extended attribute. This attribute is a designation of user
to a file or directory. Many vendors have created
protocols to NFS to extend the server's ACL mechanism across
network. Generally this has been done for homogeneous
environments. Even though the server still interprets the ACL and
final control over access to a file system object, the client is
to manipulate the ACL via these additional protocols.
distributed file systems have also provided ACL support (DFS, AFS
CIFS).

The basic factor driving the requirement for ACL support in all
these file systems has been the user's desire to grant and
access to file system data on a per user basis. Based on the
of the user and current distributed file system support, it seems
be a requirement that NFS provide this capability as well

Because many local and distributed file system ACL
have been done without a common architecture, the major issue is
of compatibility. Although the POSIX draft, DCE/DFS [DCEACL]
Windows NT ACLs have a similar structure in an array of
Control Entries consisting of a type field, identity, and
bits, the similarity ends there. Each model defines its own
of entry types, identifies users and groups differently,
different kinds of permission bits, and describes
procedures for ACL creation, defaults, and evaluation

In the least it will be problematic to create a workable
mechanism that will encompass a reasonable set of functionality
all operating environments. Even with the complicated nature of
support it is still worthwhile to work towards a solution that can
least provide basic functionality for the user

Shepler Informational [Page 9]

RFC 2624 NFSv4 Design Considerations June 1999

6. RPC Mechanism and

NFS relies on the security mechanisms provided by the
[RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_
security flavor [RFC2203], NFS security was generally limited to
(AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was
successful in providing readily available security for NFS because
a lack of widespread implementation which precluded
deployment. Also the Diffie-Hellman 192 bit public key modulus
for the AUTH_DH security flavor quickly became too small
reasonable security

6.1. User

NFS has been limited to the use of the Unix-centric
identification mechanism of numeric user id based on the
file system attributes and the use of the ONCRPC. However, for
to move beyond the limits of large work groups, user
should be string based and the definition of the user
should allow for integration into an external naming service
services

Internet scaling should also be considered for this as well.
identification mechanism should take into account multiple
domains and multiple naming mechanisms. Flexibility is the key to
solution that can grow with the needs of the user and administrator

If NFS is to move among various naming and security services, it
be necessary to stay with a string based identification. This
allow for servers and clients to translate between the
string representation to a local or internal numeric (or
identifier) which matches internal implementation needs

As an example, DFS uses a string based naming scheme but
the name to a UUID (16 byte identifier) that is used for
protocol representations. The DCE/DFS string name is a combination
cell (administrative domain) and user name. As mentioned,
clients and servers map a Unix user name to a 32 bit user
that is then used for ONCRPC and NFS protocol fields requiring
user identifier

6.2.

Because of the aforementioned problems, user authentication has
a major issue for ONCRPC and hence NFS. To satisfy requirements
the IETF and to address concerns and requirements from users,
version 4 must provide for the use of acceptable security mechanisms
The various mechanisms currently available should be explored

Shepler Informational [Page 10]

RFC 2624 NFSv4 Design Considerations June 1999

their appropriate use with NFS version 4 and ONCRPC. Some of
mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510],
IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and
interaction, the RPCSEC_GSS [RFC2203] framework should be
considered since it provides a method to employ mechanisms like
and KerberosV5. Before a security mechanism can be evaluated,
NFS environment and requirements must be discussed

6.2.1. Transport

As mentioned later in this document in the section "
Accessibility", transport independence is an asset for NFS and
and is a general requirement. This allows for transport choice
on the target environment and specific application of NFS. The
common transports in use with NFS are UDP and TCP. This ability
choose transport should be maintained in combination with the user'
choice of a security mechanism. This implies that "mandatory
implement" security mechanisms for NFS should allow for
connection-less and connection-oriented transports

6.2.2.

As should be expected, strong authentication is a requirement for
version 4. Each operation generated via ONCRPC contains
identification and authentication information. It is common in
version 2 and 3 implementations to multiplex various users'
over a single or few connections to the NFS server. This allows
scalability in the number of clients systems. Security mechanisms
frameworks should allow for this multiplexing of requests to
the implementation model that is available today

6.2.3. Data

Until the introduction of RPCSEC_GSS, the ability to provide
integrity over ONCRPC and to NFS was not available. Since file
directory data is the essence of a distributed file service, the
protocol should provide to the users of the file service a
level of data integrity. The security mechanisms chosen must
for NFS data protection with a cryptographically strong checksum.
with other aspects within NFS version 4, the user or
should be able to choose whether data integrity is employed.
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

Data privacy, while desirable, is not as important in
environments as authentication and integrity. For example, in a
environment the performance overhead of data privacy may not
required to meet an organization's data protection policies. It
also be the case that the performance of the distributed file
solution is more important than the data privacy of that solution
Even with these considerations, the user or administrator must
the choice of data privacy and therefore it must be included in
version 4.

6.2.5. Security

With the ability to provide security mechanism choices to the user
administrator, NFS version 4 should offer reasonable flexibility
application of local security policies. However, this presents
problem of negotiating the appropriate security mechanism
client and server. It is unreasonable to require the client know
server's chosen mechanism before initial contact. The issue
further complicated by an administrator who may choose more than
security mechanism for the various file system resources being
by an NFS server. These types of choices and policies require
NFS version 4 deal with negotiating the appropriate
mechanism based on mechanism availability and policy deployment
client and server. This negotiation will need to take into
the possibility of a change in policy as an NFS client
certain file system boundaries at the server. The
mechanisms required may change at these boundaries and therefore
negotiation must be included within the NFS protocol itself to
done properly (i.e. securely).

6.3.

Other distributed file system solutions such as AFS and DFS
strong authentication mechanisms. CIFS does provide
at initial server contact and a message signing option for
interaction. Recent NFS version 2 and 3 implementations, with
use of RPCSEC_GSS, provide strong authentication, integrity,
privacy

NFS version 4 must provide for strong authentication, integrity,
privacy. This must be part of the protocol so that users have
choice to use strong security if their environment or
warrant such use

Shepler Informational [Page 12]

RFC 2624 NFSv4 Design Considerations June 1999

Based on the requirements presented, the ONCRPC RPCSEC_GSS
flavor seems to provide an appropriate framework for satisfying
requirements. RPCSEC_GSS provides for authentication, integrity,
privacy. The RPCSEC_GSS is also extensible in that it provides
both public and private key security mechanisms along with
ability to plug in various mechanisms in such a way that it does
significantly disrupt ONCRPC or NFS implementations

With RPCSEC_GSS' ability to support both public and private
mechanisms, NFS version 4 should consider "mandatory to implement
choices from both. The intent is to provide a security solution
will flexibly scale to match the needs of end users. Providing
range of solutions will allow for appropriate usage based on
and available resources for deployment. Note that, in the end,
user must have a choice and that choice may be to use all of
available mechanisms in NFS version 4 or none of them

7. Internet

Being a product of an IETF working group, the NFS protocol should
only be built upon IETF technologies where possible but should
work well within the broader Internet environment

7.1. Congestion Control and Transport

As with any network protocol, congestion control is a major issue
the transport mechanisms that are chosen for NFS should take
into account. Traditionally, implementations of NFS have
deployed using both UDP and TCP. With the use of UDP,
implementations provide a rudimentary attempt control congestion
simple back-off algorithms and round trip timers. While this may
sufficient in today's NFS deployments, as an Internet protocol
will need to ensure sufficient congestion control or management

With congestion control in mind, NFS must use TCP as a transport (
ONCRPC). The UDP transport provides its own advantages in
circumstances. In today's NFS implementations, UDP has been shown
produce greater throughput as compared to similarly
systems that use TCP. This issue will need to be investigated
that a determination can be made as to whether the differences
within implementation details. If UDP is supplied as an
transport mechanism, then the congestion controls issues will
resolution to make its use suitable

Shepler Informational [Page 13]

RFC 2624 NFSv4 Design Considerations June 1999

7.2. Firewalls and Proxy

NFS's protocol design should allow its use via Internet firewalls
The protocol should also allow for the use of file system proxy/
servers. Proxy servers can be very useful for scalability and
reasons. The NFS protocol needs to address the need of proxy
in a way that will deal with the issues of security, access control
content control, and cache content validation. It is possible
these issues can be addressed by documenting the related issues
proxy server usage. However, it is likely that the NFS protocol
need to support proxy servers directly through the NFS protocol

The protocol could allow a request to be sent to a proxy
contains the name of the target NFS server to which the request
be forwarded, or from which a response might be cached. In any case
the NFS proxy server should be considered during
development

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

7.3. Multiple RPCs and

As an application at the NFS client performs simple file
operations, multiple NFS operations or RPCs may be executed
accomplish the work for the application. While the NFS version 3
protocol addressed some of this by returning file and
attributes for most procedures, hence reducing follow up
requests, there is still room for improvement. Reducing the
of RPCs will lead to a reduction of processing overhead on the
(transport and security processing) along with reducing the
spent at the client waiting for the server's individual responses
This issue is more prominent in environments with larger degrees
latency

The CIFS file access protocol supports 'batched requests' that
multiple requests to be batched, therefore reducing the number
round trip messages between client and server

This same approach can be used by NFS to allow the grouping
multiple procedure calls together in a traditional RPC request.
only would this reduce protocol imposed latency but it would
transport and security processing overhead and could allow a
to complete more complex tasks by combining procedures

Shepler Informational [Page 14]

RFC 2624 NFSv4 Design Considerations June 1999

8. File locking /

NFS provided Unix file locking and DOS SHARE capability with the
of an ancillary protocol (Network Lock Manager / NLM). The DOS
mechanism is the DOS equivalent of file locking in that it
the basis for sharing or exclusive access to file and directory
without risk of data corruption. The NLM protocol provides
locking and recovery of those locks in the event of client or
failure. The NLM protocol requires that the server make call
to the client for certain scenarios and therefore is not
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.
availability of NLM support has traditionally been a problem
seems to be most related to the fact that NFS and NLM are
separate protocols. It is easy to deliver an NFS client and
implementation and then add NLM support later. This led to a
lack of NLM support early on in NFS' lifetime. One of the
that NLM was delivered separately has been its relative
which has in turn led to poor implementations and
difficulties. Even in later implementations where reliability
performance had been increased to acceptable levels for NLM,
still chose to avoid the use of the protocol and its support.
last issue with NLM is the presence of minor protocol design
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
importance):

o Integration with the NFS protocol and ease of implementation

o Interoperability between operating environments. The
should make a reasonable effort to support the locking
of both PC and Unix clients and servers. This will allow
greater integration of all environments

o Scalable solutions - thousands of clients. The server
not be required to maintain significant client file
state between server instantiations

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

Shepler Informational [Page 15]

RFC 2624 NFSv4 Design Considerations June 1999

o Timely recovery in the event of client/server or
failure. Server recovery should be rapid. The protocol
allow clients to detect the loss of a lock

9.

NFS version 2 and 3 are currently limited in the character
of strings. In the NFS protocols, strings are used for file
directory names, and symbolic link contents. Although the
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
to indicate the character encoding used by the client or server
Obviously this limits NFS' usefulness in an environment with
that may operate with various character sets

One approach to address this deficiency is to use the
Standard [Unicode1] as the means to exchange character strings
the NFS version 4 protocol. The Unicode Standard is a 16 bit
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
Set (UCS)-Part 1: Architecture and Basic Multilingual Plane."
Unicode is a 16 bit encoding, it may be more efficient for the
version 4 protocol to use an encoding for wire transfer that will
useful for a majority of usage. One possible encoding is the
transformation format (UTF). UTF-8 is an encoding method for UCS-4
characters which allows for the direct encoding of US-
characters but expands for the correct encoding of the full UCS-4 31
bit definitions. Currently, the UCS-4 and Unicode standards do
diverge

This Unicode/UTF-8 encoding can be used for places in the
that a traditional string representation is needed. This
file and directory names along with symlink contents. This
also include other file and directory attributes that are
defined as strings

The Unicode standard is applicable to the well defined strings
the protocol. Dealing with file content is much more difficult.
has traditionally dealt with file data as an opaque byte stream.
other structure or content specification has been levied upon
file content. The main advantage to this approach is its flexibility
This byte stream can contain any data content and may be accessed
any sequential or random fashion. Unfortunately, it is left to
application or user to make the determination of file content
format. It is possible to construct a mechanism in the protocol
specifies file data type while maintaining the byte stream model

Shepler Informational [Page 16]

RFC 2624 NFSv4 Design Considerations June 1999

data access. However, this approach may be limiting in ways
to the designers of the NFS version 4 protocol. An expandable
adaptable approach is to use the previously discussed
attributes as the mechanism to specify file content and format.
use of extended attributes allows for future definition and growth
various data types are created and allows for maintaining a
file data model for the NFS protocol

It should be noted that as the Unicode standards are
defined there is the possibility for minor inconsistencies
converting from local character representations to Unicode and
back again. This should not be a problem with single client
server interaction but may become apparent with the interaction
two or more clients with separate conversion implementations
Therefore, as NFS version 4 progresses in its development,
types of Unicode issues need to be tracked and understood for
potential impact on client/server interaction. In any case,
seems to be the best selection for NFS version 4 based on
standards background and apparent future direction

10. Security

Two previous sections within this document deal with security issues
The section covering 'Access Control Lists' covers the
that need to be investigated for file system level control.
section that covers RPC security deals with individual
authentication along with data integrity and privacy issues.
section also covers negotiation of security mechanisms.
sections should be consulted for additional discussion and detail

10.1. Denial of

As with all services, the denial of service by either
implementations or malicious agents is always a concern. With
target of providing NFS version 4 for Internet use, it is all
more important that all aspects of the NFS version 4 protocol
reviewed for potential denial of service scenarios. When found
potential problems should be mitigated as much as possible

Shepler Informational [Page 17]

RFC 2624 NFSv4 Design Considerations June 1999

11.

[RFC1094]
Sun Microsystems, Inc., "NFS: Network File System
Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.

[RFC1510]
Kohl, J. and C. Neuman, "The Kerberos Network
Service (V5)", RFC 1510, September 1993.
http://www.ietf.org/rfc/rfc1510.

[RFC1813]
Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995.
http://www.ietf.org/rfc/rfc1813.

[RFC1831]
Srinivasan, R., "RPC: Remote Procedure Call Protocol
Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.

[RFC1832]
Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.

[RFC1833]
Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
1833, August 1995.
http://www.ietf.org/rfc/rfc1833.

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

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

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

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.

[RFC2152]
Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode",
RFC 2152, May 1997.
http://www.ietf.org/rfc/rfc2152.

[RFC2203]
Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS
Specification", RFC 2203, August 1995.
http://www.ietf.org/rfc/rfc2203.

[RFC2222]
Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
http://www.ietf.org/rfc/rfc2222.

[RFC2279]
Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
http://www.ietf.org/rfc/rfc2279.

[RFC2246]
Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246,
Certicom, January 1999.
http://www.ietf.org/rfc/rfc2246.

[RFC2401]
Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", RFC 2401, November 1998.
http://www.ietf.org/rfc/rfc2401.

[DCEACL
The Open Group, Open Group Technical Standard, "DCE 1.1:
Authentication and Security Services," Document Number C311,
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.

[Hutson
Huston, L.B., Honeyman, P., "Disconnected Operation for AFS,"
1993. Proc. USENIX Symp. on Mobile and Location-
Computing, Cambridge, August 1993.

Shepler Informational [Page 19]

RFC 2624 NFSv4 Design Considerations June 1999

[Kistler
Kistler, James J., Satyanarayanan, M., "Disconnected Operations
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
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, "
and Implementation of the Sun Network Filesystem,"
Conference Proceedings, USENIX Association, Berkeley, CA,
1985. The basic paper describing the SunOS implementation of
NFS version 2 protocol, and discusses the goals,
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
mobile computing environment," Proc. of the USENIX Symp. on
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.

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

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

Shepler Informational [Page 20]

RFC 2624 NFSv4 Design Considerations June 1999

[XNFS
The Open Group, Protocols for Interworking: XNFS, Version 3W,
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.

12.

o Brent Callaghan for content contributions

13. Author's

Address comments related to this memorandum to

spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.

Spencer
Sun Microsystems, Inc
7808 Moonflower
Austin, Texas 78750

Phone: (512) 349-9376
EMail: spencer.shepler@eng.sun.

Shepler Informational [Page 21]

RFC 2624 NFSv4 Design Considerations June 1999

14. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Shepler Informational [Page 22]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX