draft-ietf-nfsv4-designconsider-00.txt   draft-ietf-nfsv4-designconsider-01.txt 
Network Working Group Spencer Shepler Network Working Group Spencer Shepler
Document: draft-ietf-nfsv4-designconsider-00.txt Document: draft-ietf-nfsv4-designconsider-01.txt
NFS Version 4 Design Considerations NFS Version 4 Design Considerations
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
extensions. NFS version 4 will owe its general design to the extensions. NFS version 4 will owe its general design to the
previous versions of NFS. It is expected, however, that many previous versions of NFS. It is expected, however, that many
features will be quite different in NFS version 4 than previous features will be quite different in NFS version 4 than previous
versions to facilitate the goals of the working group and to address versions to facilitate the goals of the working group and to address
areas that NFS version 2 and 3 have not. areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail This design considerations document is meant to present more detail
than the working group charter. Specifically, it presents the areas than the working group charter. Specifically, it presents the areas
that the working group will investigate and consider while developing that the working group will investigate and consider while developing
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
a protocol specification for NFS version 4. Based on this a protocol specification for NFS version 4. Based on this
investigation the working group will decide the features of the new investigation the working group will decide the features of the new
protocol based on the cost and benefits within the specific feature protocol based on the cost and benefits within the specific feature
areas. areas.
Copyright Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Key Words Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
Table of Contents Table of Contents
1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 4 1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 4
2. Ease of Implementation or Complexity of Protocol . . . . . . 4 2. Ease of Implementation or Complexity of Protocol . . . . . . 4
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 4 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 4
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 4 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 4
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 6 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 6
4.1. Throughput and Latency via the Network . . . . . . . . . . 7 4.1. Throughput and Latency via the Network . . . . . . . . . . 7
skipping to change at page 4, line 5 skipping to change at page 4, line 5
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 15 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 15
8. File locking / recovery . . . . . . . . . . . . . . . . . . 16 8. File locking / recovery . . . . . . . . . . . . . . . . . . 16
9. Internationalization . . . . . . . . . . . . . . . . . . . 17 9. Internationalization . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . 18
10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 19 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 19
11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 20 11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 25 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 25
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 26 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 26
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
1. NFS Version 4 Design Considerations 1. NFS Version 4 Design Considerations
As stated in the charter, the first deliverable for the NFS version 4 As stated in the charter, the first deliverable for the NFS version 4
working group is this design considerations document. This document working group is this design considerations document. This document
is to cover the "limitations and deficiencies of NFS version 3". is to cover the "limitations and deficiencies of NFS version 3".
This document will also be used as a mechanism to focus discussion This document will also be used as a mechanism to focus discussion
and avenues of investigation as the definition of NFS version 4 and avenues of investigation as the definition of NFS version 4
progresses. Therefore, the contents of this document cover the progresses. Therefore, the contents of this document cover the
general functional/feature areas that are anticipated for NFS version general functional/feature areas that are anticipated for NFS version
skipping to change at page 5, line 5 skipping to change at page 5, line 5
2.2. Managed Extensions or Minor Versioning 2.2. Managed Extensions or Minor Versioning
For those cases where the NFS protocol is deficient or where a minor 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 modification is the best solution for a problem, a minor version or a
managed extension could be helpful. There have been instances with managed extension could be helpful. There have been instances with
NFS version 2 and 3 where small straightforward functional additions NFS version 2 and 3 where small straightforward functional additions
would have increased the overall value of the protocol immensely. would have increased the overall value of the protocol immensely.
For instance, the PATHCONF procedure that was added to version 2 of For instance, the PATHCONF procedure that was added to version 2 of
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
the MOUNT protocol would have been more appropriate for the NFS the MOUNT protocol would have been more appropriate for the NFS
protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP
procedure for NFS versions 2 and 3 would have been more cleanly procedure for NFS versions 2 and 3 would have been more cleanly
implemented in a new LOOKUP procedure. implemented in a new LOOKUP procedure.
However, the perceived size and burden of using a change of RPC However, the perceived size and burden of using a change of RPC
version number for the introduction of new functionality led to no or 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 slow change. It is possible that a new NFS protocol could allow for
the rare instance where protocol extension within the RPC version the rare instance where protocol extension within the RPC version
skipping to change at page 6, line 5 skipping to change at page 6, line 5
protocol. Except for the addition of this new procedure, the protocol. Except for the addition of this new procedure, the
protocol was unchanged. Many thought this protocol revision was protocol was unchanged. Many thought this protocol revision was
unnecessary, since the RPC protocol already allows certain procedures unnecessary, since the RPC protocol already allows certain procedures
not be implemented and defines a PROC_UNAVAIL error. not be implemented and defines a PROC_UNAVAIL error.
Another historical data-point from NFS version 2 and 3 is the support Another historical data-point from NFS version 2 and 3 is the support
(or lack) of symbolic links. Servers that cannot support this (or lack) of symbolic links. Servers that cannot support this
feature will simply reject calls to the SYMLINK and READLINK feature will simply reject calls to the SYMLINK and READLINK
procedures. Additionally, NFS version 4 may describe many file procedures. Additionally, NFS version 4 may describe many file
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
attributes which cannot be supported by the server or file systems on attributes which cannot be supported by the server or file systems on
the server. Therefore, the protocol must support a discovery the server. Therefore, the protocol must support a discovery
mechanism that allows clients to determine which features of the mechanism that allows clients to determine which features of the
protocol are supported by a server. protocol are supported by a server.
3. Reliable and Available 3. Reliable and Available
Current NFS protocol design, while placing an emphasis on simple Current NFS protocol design, while placing an emphasis on simple
server design, has led to timely recovery from server and client server design, has led to timely recovery from server and client
skipping to change at page 7, line 5 skipping to change at page 7, line 5
4. Scalable Performance 4. Scalable Performance
In designing and developing an NFS protocol from a performance In designing and developing an NFS protocol from a performance
viewpoint there are several different points to consider. Each can viewpoint there are several different points to consider. Each can
play a significant role in perceived and real performance from the play a significant role in perceived and real performance from the
user's perspective. The three main areas of interest are: throughput user's perspective. The three main areas of interest are: throughput
and latency via the network, server work load or scalability and and latency via the network, server work load or scalability and
client side caching. client side caching.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
4.1. Throughput and Latency via the Network 4.1. Throughput and Latency via the Network
NFS currently has characteristics that provide good throughput for NFS currently has characteristics that provide good throughput for
reading and writing file data. This is commonly achieved by the reading and writing file data. This is commonly achieved by the
client's use of pipelining or windowing multiple RPC READ/WRITE client's use of pipelining or windowing multiple RPC READ/WRITE
requests to the server. The flexibility of the NFS and ONCRPC requests to the server. The flexibility of the NFS and ONCRPC
protocols allow for implementations to use this type of adaptation to protocols allow for implementations to use this type of adaptation to
provide efficient use of the network connection. provide efficient use of the network connection.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
is possible for a client to obtain an opportunistic lock for a file is possible for a client to obtain an opportunistic lock for a file
and subsequently process file lock requests completely at the client. and subsequently process file lock requests completely at the client.
If there are no conflicts with other clients for file data access, If there are no conflicts with other clients for file data access,
the server is never contacted for the file locking traffic generated the server is never contacted for the file locking traffic generated
by the user application. This behavior is not a protocol requirement by the user application. This behavior is not a protocol requirement
but is allowed by the protocol as an implementation option to improve but is allowed by the protocol as an implementation option to improve
performance. performance.
NFS versions 2 and 3 make no caching requirements. Implementations NFS versions 2 and 3 make no caching requirements. Implementations
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
typically implement close-to-open cache consistency which requires typically implement close-to-open cache consistency which requires
clients flush all changes to the server on each file close, and check 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 for file changes on the server on each file open. The consistency
check required on each file open can generate a large amount of check required on each file open can generate a large amount of
GETATTR traffic. With this approach, there are windows when the GETATTR traffic. With this approach, there are windows when the
client can still be acting with stale data between the open and close client can still be acting with stale data between the open and close
of a file. of a file.
Client caching is increasingly important for Internet environments Client caching is increasingly important for Internet environments
skipping to change at page 9, line 5 skipping to change at page 9, line 5
experiences with Coda, disconnected AFS and others should be helpful experiences with Coda, disconnected AFS and others should be helpful
in this area. (see references) in this area. (see references)
5. Interoperability 5. Interoperability
The NFS protocols are available for many different operating The NFS protocols are available for many different operating
environments. Even though this shows the protocol's ability to environments. Even though this shows the protocol's ability to
provide distributed file system service for more than a single provide distributed file system service for more than a single
operating system, the design of NFS is certainly Unix-centric. The operating system, the design of NFS is certainly Unix-centric. The
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
next NFS protocol needs to be more inclusive of platform or file next NFS protocol needs to be more inclusive of platform or file
system features beyond those of traditional Unix. system features beyond those of traditional Unix.
5.1. Platform Specific Behavior 5.1. Platform Specific Behavior
Because of Unix-centric origins, NFS version 2 and 3 protocol Because of Unix-centric origins, NFS version 2 and 3 protocol
requirements have been difficult to implement in some environments. requirements have been difficult to implement in some environments.
For example, persistent file handles (unique identifiers of file For example, persistent file handles (unique identifiers of file
system objects), Unix uid/gid mappings, directory modification time, system objects), Unix uid/gid mappings, directory modification time,
skipping to change at page 10, line 5 skipping to change at page 10, line 5
to support a generalized named attribute mechanism. This mechanism to support a generalized named attribute mechanism. This mechanism
would allow a client to name, store and retrieve arbitrary data and would allow a client to name, store and retrieve arbitrary data and
have it associated as an attribute of a file or directory. have it associated as an attribute of a file or directory.
One difficulty in providing named attributes is determining if the One difficulty in providing named attributes is determining if the
protocol should specify the names for the attributes, their type or protocol should specify the names for the attributes, their type or
structure. How will the protocol determine or allow for attributes structure. How will the protocol determine or allow for attributes
that can be read but not written is another issue. Yet another could 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 be the side effects that these attributes have on the core set of
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
file properties such as setting a size attribute to 0 and having file properties such as setting a size attribute to 0 and having
associated file data deleted. associated file data deleted.
As these brief examples show, this type of extended attribute As these brief examples show, this type of extended attribute
mechanism brings with it a large set of issues that will need to be mechanism brings with it a large set of issues that will need to be
addressed in the protocol specification while keeping the overall addressed in the protocol specification while keeping the overall
goal of simplicity in mind. goal of simplicity in mind.
There are operating environments that provide named or extended There are operating environments that provide named or extended
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Windows NT ACLs have a similar structure in an array of Access Windows NT ACLs have a similar structure in an array of Access
Control Entries consisting of a type field, identity, and permission Control Entries consisting of a type field, identity, and permission
bits, the similarity ends there. Each model defines its own variants bits, the similarity ends there. Each model defines its own variants
of entry types, identifies users and groups differently, provides of entry types, identifies users and groups differently, provides
different kinds of permission bits, and describes different different kinds of permission bits, and describes different
procedures for ACL creation, defaults, and evaluation. procedures for ACL creation, defaults, and evaluation.
In the least it will be problematic to create a workable ACL In the least it will be problematic to create a workable ACL
mechanism that will encompass a reasonable set of functionality for mechanism that will encompass a reasonable set of functionality for
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
all operating environments. Even with the complicated nature of ACL all operating environments. Even with the complicated nature of ACL
support it is still worthwhile to work towards a solution that can at support it is still worthwhile to work towards a solution that can at
least provide basic functionality for the user. least provide basic functionality for the user.
6. RPC Mechanism and Security 6. RPC Mechanism and Security
NFS relies on the security mechanisms provided by the ONCRPC NFS relies on the security mechanisms provided by the ONCRPC
[RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS [RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS
security flavor [RFC2203], NFS security was generally limited to none security flavor [RFC2203], NFS security was generally limited to none
skipping to change at page 12, line 5 skipping to change at page 12, line 5
identifier) which matches internal implementation needs. identifier) which matches internal implementation needs.
As an example, DFS uses a string based naming scheme but translates 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 the name to a UUID (16 byte identifier) that is used for internal
protocol representations. The DCE/DFS string name is a combination of protocol representations. The DCE/DFS string name is a combination of
cell (administrative domain) and user name. As mentioned, NFS cell (administrative domain) and user name. As mentioned, NFS
clients and servers map a Unix user name to a 32 bit user identifier 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 that is then used for ONCRPC and NFS protocol fields requiring the
user identifier. user identifier.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
6.2. Security 6.2. Security
Because of the aforementioned problems, user authentication has been Because of the aforementioned problems, user authentication has been
a major issue for ONCRPC and hence NFS. To satisfy requirements of a major issue for ONCRPC and hence NFS. To satisfy requirements of
the IETF and to address concerns and requirements from users, NFS the IETF and to address concerns and requirements from users, NFS
version 4 must provide for the use of acceptable security mechanisms. version 4 must provide for the use of acceptable security mechanisms.
The various mechanisms currently available should be explored for The various mechanisms currently available should be explored for
their appropriate use with NFS version 4 and ONCRPC. Some of these their appropriate use with NFS version 4 and ONCRPC. Some of these
mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510], mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510],
skipping to change at page 13, line 5 skipping to change at page 13, line 5
version 2 and 3 implementations to multiplex various users' requests version 2 and 3 implementations to multiplex various users' requests
over a single or few connections to the NFS server. This allows for over a single or few connections to the NFS server. This allows for
scalability in the number of clients systems. Security mechanisms or scalability in the number of clients systems. Security mechanisms or
frameworks should allow for this multiplexing of requests to sustain frameworks should allow for this multiplexing of requests to sustain
the implementation model that is available today. the implementation model that is available today.
6.2.3. Data Integrity 6.2.3. Data Integrity
Until the introduction of RPCSEC_GSS, the ability to provide data Until the introduction of RPCSEC_GSS, the ability to provide data
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
integrity over ONCRPC and to NFS was not available. Since file and integrity over ONCRPC and to NFS was not available. Since file and
directory data is the essence of a distributed file service, the NFS directory data is the essence of a distributed file service, the NFS
protocol should provide to the users of the file service a reasonable protocol should provide to the users of the file service a reasonable
level of data integrity. The security mechanisms chosen must provide level of data integrity. The security mechanisms chosen must provide
for NFS data protection with a cryptographically strong checksum. As for NFS data protection with a cryptographically strong checksum. As
with other aspects within NFS version 4, the user or administrator with other aspects within NFS version 4, the user or administrator
should be able to choose whether data integrity is employed. This should be able to choose whether data integrity is employed. This
will provide needed flexibility for a variety of NFS version 4 will provide needed flexibility for a variety of NFS version 4
solutions. solutions.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
by an NFS server. These types of choices and policies require that by an NFS server. These types of choices and policies require that
NFS version 4 deal with negotiating the appropriate security NFS version 4 deal with negotiating the appropriate security
mechanism based on mechanism availability and policy deployment at mechanism based on mechanism availability and policy deployment at
client and server. This negotiation will need to take into account client and server. This negotiation will need to take into account
the possibility of a change in policy as an NFS client crosses the possibility of a change in policy as an NFS client crosses
certain file system boundaries at the server. The security certain file system boundaries at the server. The security
mechanisms required may change at these boundaries and therefore the mechanisms required may change at these boundaries and therefore the
negotiation must be included within the NFS protocol itself to be negotiation must be included within the NFS protocol itself to be
done properly (i.e. securely). done properly (i.e. securely).
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
6.3. Summary 6.3. Summary
Other distributed file system solutions such as AFS and DFS provide Other distributed file system solutions such as AFS and DFS provide
strong authentication mechanisms. CIFS does provide authentication strong authentication mechanisms. CIFS does provide authentication
at initial server contact and a message signing option for subsequent at initial server contact and a message signing option for subsequent
interaction. Recent NFS version 2 and 3 implementations, with the interaction. Recent NFS version 2 and 3 implementations, with the
use of RPCSEC_GSS, provide strong authentication, integrity, and use of RPCSEC_GSS, provide strong authentication, integrity, and
privacy. privacy.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Being a product of an IETF working group, the NFS protocol should not Being a product of an IETF working group, the NFS protocol should not
only be built upon IETF technologies where possible but should also only be built upon IETF technologies where possible but should also
work well within the broader Internet environment. work well within the broader Internet environment.
7.1. Congestion Control and Transport Selection 7.1. Congestion Control and Transport Selection
As with any network protocol, congestion control is a major issue and As with any network protocol, congestion control is a major issue and
the transport mechanisms that are chosen for NFS should take this the transport mechanisms that are chosen for NFS should take this
into account. Traditionally, implementations of NFS have been into account. Traditionally, implementations of NFS have been
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
deployed using both UDP and TCP. With the use of UDP, most deployed using both UDP and TCP. With the use of UDP, most
implementations provide a rudimentary attempt control congestion with implementations provide a rudimentary attempt control congestion with
simple back-off algorithms and round trip timers. While this may be simple back-off algorithms and round trip timers. While this may be
sufficient in today's NFS deployments, as an Internet protocol NFS sufficient in today's NFS deployments, as an Internet protocol NFS
will need to ensure sufficient congestion control or management. will need to ensure sufficient congestion control or management.
With congestion control in mind, NFS must use TCP as a transport (via With congestion control in mind, NFS must use TCP as a transport (via
ONCRPC). The UDP transport provides its own advantages in certain ONCRPC). The UDP transport provides its own advantages in certain
circumstances. In today's NFS implementations, UDP has been shown to circumstances. In today's NFS implementations, UDP has been shown to
skipping to change at page 15, line 30 skipping to change at page 15, line 30
transport mechanism, then the congestion controls issues will need transport mechanism, then the congestion controls issues will need
resolution to make its use suitable. resolution to make its use suitable.
7.2. Firewalls and Proxy Servers 7.2. Firewalls and Proxy Servers
NFS's protocol design should allow its use via Internet firewalls. NFS's protocol design should allow its use via Internet firewalls.
The protocol should also allow for the use of file system proxy/cache The protocol should also allow for the use of file system proxy/cache
servers. Proxy servers can be very useful for scalability and other servers. Proxy servers can be very useful for scalability and other
reasons. The NFS protocol needs to address the need of proxy servers 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, in a way that will deal with the issues of security, access control,
and content control. It is possible that these issues can be content control, and cache content validation. It is possible that
addressed by documenting the related issues of proxy server usage. these issues can be addressed by documenting the related issues of
However, it is likely that the NFS protocol will need to support proxy server usage. However, it is likely that the NFS protocol will
proxy servers directly through 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 that 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 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, be forwarded, or from which a response might be cached. In any case,
the NFS proxy server should be considered during protocol the NFS proxy server should be considered during protocol
development. development.
The problems encountered in making the NFS protocol work through The problems encountered in making the NFS protocol work through
firewalls are described in detail in [RFC2054] and [RFC2055]. firewalls are described in detail in [RFC2054] and [RFC2055].
7.3. Multiple RPCs and Latency 7.3. Multiple RPCs and Latency
As an application at the NFS client performs simple file system As an application at the NFS client performs simple file system
operations, multiple NFS operations or RPCs may be executed to operations, multiple NFS operations or RPCs may be executed to
accomplish the work for the application. While the NFS version 3 accomplish the work for the application. While the NFS version 3
protocol addressed some of this by returning file and directory protocol addressed some of this by returning file and directory
attributes for most procedures, hence reducing follow up GETATTR attributes for most procedures, hence reducing follow up GETATTR
requests, there is still room for improvement. Reducing the number requests, there is still room for improvement. Reducing the number
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
of RPCs will lead to a reduction of processing overhead on the server of RPCs will lead to a reduction of processing overhead on the server
(transport and security processing) along with reducing the time (transport and security processing) along with reducing the time
spent at the client waiting for the server's individual responses. spent at the client waiting for the server's individual responses.
This issue is more prominent in environments with larger degrees of This issue is more prominent in environments with larger degrees of
latency. latency.
The CIFS file access protocol supports 'batched requests' that allow The CIFS file access protocol supports 'batched requests' that allow
multiple requests to be batched, therefore reducing the number of multiple requests to be batched, therefore reducing the number of
round trip messages between client and server. round trip messages between client and server.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
difficulties. Even in later implementations where reliability and difficulties. Even in later implementations where reliability and
performance had been increased to acceptable levels for NLM, users performance had been increased to acceptable levels for NLM, users
still chose to avoid the use of the protocol and its support. The 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 last issue with NLM is the presence of minor protocol design flaws
that relate to high network load and recovery. that relate to high network load and recovery.
Based on the experiences with NLM, locking support for NFS version 4 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 should strive to meet or at least consider the following (in order of
importance): importance):
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
o Integration with the NFS protocol and ease of implementation. o Integration with the NFS protocol and ease of implementation.
o Interoperability between operating environments. The protocol o Interoperability between operating environments. The protocol
should make a reasonable effort to support the locking semantics should make a reasonable effort to support the locking semantics
of both PC and Unix clients and servers. This will allow for of both PC and Unix clients and servers. This will allow for
greater integration of all environments. greater integration of all environments.
o Scalable solutions - thousands of clients. The server should o Scalable solutions - thousands of clients. The server should
not be required to maintain significant client file locking not be required to maintain significant client file locking
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because
Unicode is a 16 bit encoding, it may be more efficient for the NFS 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 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 useful for a majority of usage. One possible encoding is the UCS
transformation format (UTF). UTF-8 is an encoding method for UCS-4 transformation format (UTF). UTF-8 is an encoding method for UCS-4
characters which allows for the direct encoding of US-ASCII characters which allows for the direct encoding of US-ASCII
characters but expands for the correct encoding of the full UCS-4 31 characters but expands for the correct encoding of the full UCS-4 31
bit definitions. Currently, the UCS-4 and Unicode standards do not bit definitions. Currently, the UCS-4 and Unicode standards do not
diverge. diverge.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
This Unicode/UTF-8 encoding can be used for places in the protocol This Unicode/UTF-8 encoding can be used for places in the protocol
that a traditional string representation is needed. This includes that a traditional string representation is needed. This includes
file and directory names along with symlink contents. This should file and directory names along with symlink contents. This should
also include other file and directory attributes that are eventually also include other file and directory attributes that are eventually
defined as strings. defined as strings.
The Unicode standard is applicable to the well defined strings within The Unicode standard is applicable to the well defined strings within
the protocol. Dealing with file content is much more difficult. NFS the protocol. Dealing with file content is much more difficult. NFS
has traditionally dealt with file data as an opaque byte stream. No has traditionally dealt with file data as an opaque byte stream. No
skipping to change at page 19, line 5 skipping to change at page 19, line 5
10. Security Considerations 10. Security Considerations
Two previous sections within this document deal with security issues. Two previous sections within this document deal with security issues.
The section covering 'Access Control Lists' covers the mechanisms The section covering 'Access Control Lists' covers the mechanisms
that need to be investigated for file system level control. The that need to be investigated for file system level control. The
section that covers RPC security deals with individual user section that covers RPC security deals with individual user
authentication along with data integrity and privacy issues. This authentication along with data integrity and privacy issues. This
section also covers negotiation of security mechanisms. These section also covers negotiation of security mechanisms. These
sections should be consulted for additional discussion and detail. sections should be consulted for additional discussion and detail.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
10.1. Denial of Service 10.1. Denial of Service
As with all services, the denial of service by either incorrect As with all services, the denial of service by either incorrect
implementations or malicious agents is always a concern. With the implementations or malicious agents is always a concern. With the
target of providing NFS version 4 for Internet use, it is all 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 more important that all aspects of the NFS version 4 protocol be
reviewed for potential denial of service scenarios. When found these reviewed for potential denial of service scenarios. When found these
potential problems should be mitigated as much as possible. potential problems should be mitigated as much as possible.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
11. Bibliography 11. Bibliography
[RFC1094] [RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC1094, March 1989. Specification", RFC1094, March 1989.
http://www.ietf.org/rfc/rfc1094.txt http://www.ietf.org/rfc/rfc1094.txt
[RFC1510] [RFC1510]
skipping to change at page 21, line 5 skipping to change at page 21, line 5
[RFC1833] [RFC1833]
Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833,
Sun Microsystems, Inc., August 1995. Sun Microsystems, Inc., August 1995.
http://www.ietf.org/rfc/rfc1833.txt http://www.ietf.org/rfc/rfc1833.txt
[RFC2025] [RFC2025]
Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025,
Bell-Northern Research, October 1996. Bell-Northern Research, October 1996.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
http://www.ietf.org/rfc/rfc2025.txt http://www.ietf.org/rfc/rfc2025.txt
[RFC2054] [RFC2054]
Callaghan, B., "WebNFS Client Specification", RFC2054, Sun Callaghan, B., "WebNFS Client Specification", RFC2054, Sun
Microsystems, Inc., October 1996 Microsystems, Inc., October 1996
http://www.ietf.org/rfc/rfc2054.txt http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] [RFC2055]
skipping to change at page 22, line 5 skipping to change at page 22, line 5
[RFC2222] [RFC2222]
Myers, J., "Simple Authentication and Security Layer (SASL)", Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC2222, Netscape Communications, October 1997. RFC2222, Netscape Communications, October 1997.
http://www.ietf.org/rfc/rfc2222.txt http://www.ietf.org/rfc/rfc2222.txt
[RFC2279] [RFC2279]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC2279, Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC2279,
Alis Technologies, January 1998. Alis Technologies, January 1998.
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
http://www.ietf.org/rfc/rfc2279.txt http://www.ietf.org/rfc/rfc2279.txt
[RFC2246] [RFC2246]
Dierks, T., Allen, C. "The TLS Protocols Version 1.0", RFC 2246, Dierks, T., Allen, C. "The TLS Protocols Version 1.0", RFC 2246,
Certicom, January 1999. Certicom, January 1999.
http://www.ietf.org/rfc/rfc2246.txt http://www.ietf.org/rfc/rfc2246.txt
[RFC2401] [RFC2401]
skipping to change at page 23, line 5 skipping to change at page 23, line 5
1, pp. 3-25, Feb. 1992. 1, pp. 3-25, Feb. 1992.
[Mummert] [Mummert]
Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak
Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on
Operating Systems Principles Dec. 1995. Operating Systems Principles Dec. 1995.
[Nagar] [Nagar]
Nagar, R., "Windows NT File System Internals," ISBN 1565922492, Nagar, R., "Windows NT File System Internals," ISBN 1565922492,
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
O`Reilly & Associates, Inc. O`Reilly & Associates, Inc.
[Sandberg] [Sandberg]
Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design
and Implementation of the Sun Network Filesystem," USENIX Conference and Implementation of the Sun Network Filesystem," USENIX Conference
Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The
basic paper describing the SunOS implementation of the NFS version 2 basic paper describing the SunOS implementation of the NFS version 2
protocol, and discusses the goals, protocol specification and trade- protocol, and discusses the goals, protocol specification and trade-
offs. offs.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[XDSM] [XDSM]
The Open Group, Open Group Technical Standard, "Systems Management: The Open Group, Open Group Technical Standard, "Systems Management:
Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January
1997. 1997.
[XNFS] [XNFS]
The Open Group, Protocols for Interworking: XNFS, Version 3W, The The Open Group, Protocols for Interworking: XNFS, Version 3W, The
Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
1-85912-184-5, February 1998. 1-85912-184-5, February 1998.
HTML version available: http://www.opengroup.org HTML version available: http://www.opengroup.org
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
12. Acknowledgments 12. Acknowledgments
o Brent Callaghan for content contributions. o Brent Callaghan for content contributions.
13. Author's Address 13. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
Spencer Shepler Spencer Shepler
Sun Microsystems, Inc. Sun Microsystems, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
Austin, Texas 78750 Austin, Texas 78750
Phone: (512) 349-9376 Phone: (512) 349-9376
E-mail: spencer.shepler@eng.sun.com E-mail: spencer.shepler@eng.sun.com
NFSv4 NFSv4 Design Considerations March 1999 NFSv4 NFSv4 Design Considerations April 1999
14. Full Copyright Statement 14. Full Copyright Statement
"Copyright (C) The Internet Society (1999). All Rights Reserved. "Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/