draft-ietf-nfsv4-designconsider-01.txt   draft-ietf-nfsv4-designconsider-02.txt 
Network Working Group Spencer Shepler Network Working Group Spencer Shepler
Document: draft-ietf-nfsv4-designconsider-01.txt Document: draft-ietf-nfsv4-designconsider-02.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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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
2.3. Relationship with Older Versions of NFS . . . . . . . . . . 6
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 6 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 7
4.1. Throughput and Latency via the Network . . . . . . . . . . 7 4.1. Throughput and Latency via the Network . . . . . . . . . . 7
4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 8 4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 9
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 8 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 9 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 9
5.2. Additional or Extended Attributes . . . . . . . . . . . . . 9 5.2. Additional or Extended Attributes . . . . . . . . . . . . . 9
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 10 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 10
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 11 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 11
6.1. User identification . . . . . . . . . . . . . . . . . . . 11 6.1. User identification . . . . . . . . . . . . . . . . . . . 12
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Transport Independence . . . . . . . . . . . . . . . . 12 6.2.1. Transport Independence . . . . . . . . . . . . . . . . 13
6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 12 6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 12 6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 13
6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 13 6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 13
6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 13 6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 14
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 14 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 15
7.1. Congestion Control and Transport Selection . . . . . . . 14 7.1. Congestion Control and Transport Selection . . . . . . . 15
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 15 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 16
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 15 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 16
8. File locking / recovery . . . . . . . . . . . . . . . . . . 16 8. File locking / recovery . . . . . . . . . . . . . . . . . . 17
9. Internationalization . . . . . . . . . . . . . . . . . . . 17 9. Internationalization . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . 19
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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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.
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.
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 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
failure. This and other aspects to the design have provided a basis failure. This and other aspects to the design have provided a basis
for layered technologies like high availability and clustered for layered technologies like high availability and clustered
servers. Providing a protocol design approach that lends itself to servers. Providing a protocol design approach that lends itself to
these types of reliability and availability features is very these types of reliability and availability features is very
desirable. desirable.
For the next version of NFS, consideration should be given to client For the next version of NFS, consideration should be given to client
side availability schemes such as client switching between or fail- side availability schemes such as client switching between or fail-
over to available server replicas. NFS currently requires that file over to available server replicas. NFS currently requires that file
handles be immutable; this requirement adds unnecessarily to the handles be immutable; this requirement adds unnecessarily to the
complexity of building fail-over configurations. If possible, the complexity of building fail-over configurations. If possible, the
protocol should allow for or ease the building of such layered protocol should allow for or ease the building of such layered
NFSv4 NFSv4 Design Considerations May 1999
solutions. solutions.
For the next version of NFS, consideration should be given to schemes For the next version of NFS, consideration should be given to schemes
that support client switching between server replicas or highly that support client switching between server replicas or highly
available NFS servers that provide paths to data through multiple available NFS servers that provide paths to data through multiple
servers. For example: NFS currently requires that filehandles be servers. For example: NFS currently requires that filehandles be
unchanging for any instance of a file or directory. This requirement unchanging for any instance of a file or directory. This requirement
makes it more difficult for a client to switch from one server to makes it more difficult for a client to switch from one server to
another, since each server may construct filehandles differently. another, since each server may construct filehandles differently.
Protocol support could allow the client to handle a filehandle Protocol support could allow the client to handle a filehandle
skipping to change at page 7, line 5 skipping to change at page 7, line 28
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 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.
However, the number of RPCs required to accomplish some tasks However, the number of RPCs required to accomplish some tasks
combined with high latency network environments may lead to sluggish combined with high latency network environments may lead to sluggish
single user or single client response. The protocol should continue single user or single client response. The protocol should continue
to provide good raw read and write throughput while addressing the to provide good raw read and write throughput while addressing the
issue of network latency. This issue is discussed further in the issue of network latency. This issue is discussed further in the
section on Internet Accessibility. section on Internet Accessibility.
4.2. Client Caching 4.2. Client Caching
In an attempt to speed response time and to reduce network and server In an attempt to speed response time and to reduce network and server
load, NFS clients have always cached directory and file data. load, NFS clients have always cached directory and file data.
NFSv4 NFSv4 Design Considerations May 1999
However, this has usually been done as memory cache and in relatively However, this has usually been done as memory cache and in relatively
recent history, local disk caching has been added. recent history, local disk caching has been added.
It is very desirable to have the NFS client cache directory and file It is very desirable to have the NFS client cache directory and file
data. Other distributed file systems have shown that aggressive data. Other distributed file systems have shown that aggressive
client side caching can be very visible to the end user in the form 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 of decreasing overall response time. For AFS and DCE/DFS, caching is
accomplished by the utilization of server call backs to notify the accomplished by the utilization of server call backs to notify the
client of potential cache invalidation. CIFS and its opportunistic client of potential cache invalidation. CIFS and its opportunistic
locks provide a similar call back mechanism. Clients in both of locks provide a similar call back mechanism. Clients in both of
skipping to change at page 8, line 4 skipping to change at page 8, line 32
traffic flowing between client and server. In the case of CIFS, it 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 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 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
where throughput can be limited and response time can grow where throughput can be limited and response time can grow
significantly. Therefore the NFS version 4 caching design will need significantly. Therefore the NFS version 4 caching design will need
to take into account the full spectrum of caching designs as to take into account the full spectrum of caching designs as
exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS, exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS,
etc. in determining an appropriate design. This will need to be done etc. in determining an appropriate design. This will need to be done
while weighing the complexity of each possible approach with the need while weighing the complexity of each possible approach with the need
of the eventual users and operating environments into which NFS of the eventual users and operating environments into which NFS
version 4 may be deployed. Some of these considerations are: version 4 may be deployed. Some of these considerations are:
Internet accessibility, firewall traversal (call back availability), Internet accessibility, firewall traversal (call back availability),
proxy caching, low-overhead or simple clients. proxy caching, low-overhead or simple clients.
NFSv4 NFSv4 Design Considerations May 1999
4.3. Disconnected Client Operation 4.3. Disconnected Client Operation
An extension of client caching is the provision for disconnected An extension of client caching is the provision for disconnected
operation at the client. With the ability to cache directory and operation at the client. With the ability to cache directory and
file data aggressively, a client could then provide service to the file data aggressively, a client could then provide service to the
end user while disconnected from the server or network. end user while disconnected from the server or network.
While very desirable, disconnected operation has the potential to While very desirable, disconnected operation has the potential to
inflict itself upon the NFS protocol in an undesirable way as inflict itself upon the NFS protocol in an undesirable way as
compared to traditional client caching. Given the complexities of compared to traditional client caching. Given the complexities of
skipping to change at page 9, line 4 skipping to change at page 9, line 32
NFS protocol (as with other server and client solutions). The NFS protocol (as with other server and client solutions). The
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 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,
accurate file sizes, file/directory locking semantics (SHAREs, PC- accurate file sizes, file/directory locking semantics (SHAREs, PC-
style locking). In the design of NFS version 4, these areas and style locking). In the design of NFS version 4, these areas and
others not mentioned will need to be considered and, if possible, others not mentioned will need to be considered and, if possible,
cross-platform solutions developed. cross-platform solutions developed.
5.2. Additional or Extended Attributes 5.2. Additional or Extended Attributes
NFS versions 2 and 3 do not provide for file or directory 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 beyond those that are found in the traditional Unix environment. For
NFSv4 NFSv4 Design Considerations May 1999
example the user identifier/owner of the file, a permission or access example the user identifier/owner of the file, a permission or access
bitmap, time stamps for modification of the file or directory and bitmap, time stamps for modification of the file or directory and
file size to name a few. While the current set of attributes has file size to name a few. While the current set of attributes has
usually been sufficient, the file system's ability to manage usually been sufficient, the file system's ability to manage
additional information associated with a file or directory can be additional information associated with a file or directory can be
useful. useful.
There are many possibilities for additional attributes in the next There are many possibilities for additional attributes in the next
version of NFS. Some of these include: object creation timestamp, version of NFS. Some of these include: object creation timestamp,
user identifier of file's creator, timestamp of last backup or user identifier of file's creator, timestamp of last backup or
skipping to change at page 10, line 4 skipping to change at page 10, line 34
needed extensibility. Another way to provide some extensibility is needed extensibility. Another way to provide some extensibility is
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 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
attribute mechanisms. Digital Unix provides for the storage of attribute mechanisms. Digital Unix provides for the storage of
extended attributes with some generalized format. HPFS[HPFS] and extended attributes with some generalized format. HPFS[HPFS] and
NTFS [Nagar] also provide for named data associated with traditional NTFS [Nagar] also provide for named data associated with traditional
files. SGI's local file system, XFS, also provides for this type of 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 name/value extended attributes. However, there does not seem to be a
clear direction that can be taken from these or other environments. clear direction that can be taken from these or other environments.
5.3. Access Control Lists 5.3. Access Control Lists
Access Control Lists (ACL) can be viewed as one specific type of Access Control Lists (ACL) can be viewed as one specific type of
extended attribute. This attribute is a designation of user access extended attribute. This attribute is a designation of user access
NFSv4 NFSv4 Design Considerations May 1999
to a file or directory. Many vendors have created ancillary to a file or directory. Many vendors have created ancillary
protocols to NFS to extend the server's ACL mechanism across the protocols to NFS to extend the server's ACL mechanism across the
network. Generally this has been done for homogeneous operating network. Generally this has been done for homogeneous operating
environments. Even though the server still interprets the ACL and has environments. Even though the server still interprets the ACL and has
final control over access to a file system object, the client is able final control over access to a file system object, the client is able
to manipulate the ACL via these additional protocols. Other to manipulate the ACL via these additional protocols. Other
distributed file systems have also provided ACL support (DFS, AFS and distributed file systems have also provided ACL support (DFS, AFS and
CIFS). CIFS).
The basic factor driving the requirement for ACL support in all of The basic factor driving the requirement for ACL support in all of
skipping to change at page 11, line 4 skipping to change at page 11, line 34
of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and
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 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
(AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not
successful in providing readily available security for NFS because of successful in providing readily available security for NFS because of
a lack of widespread implementation which precluded widespread a lack of widespread implementation which precluded widespread
deployment. Also the Diffie-Hellman 192 bit public key modulus used deployment. Also the Diffie-Hellman 192 bit public key modulus used
for the AUTH_DH security flavor quickly became too small for for the AUTH_DH security flavor quickly became too small for
reasonable security. reasonable security.
NFSv4 NFSv4 Design Considerations May 1999
6.1. User identification 6.1. User identification
NFS has been limited to the use of the Unix-centric user NFS has been limited to the use of the Unix-centric user
identification mechanism of numeric user id based on the available identification mechanism of numeric user id based on the available
file system attributes and the use of the ONCRPC. However, for NFS file system attributes and the use of the ONCRPC. However, for NFS
to move beyond the limits of large work groups, user identification to move beyond the limits of large work groups, user identification
should be string based and the definition of the user identifier should be string based and the definition of the user identifier
should allow for integration into an external naming service or should allow for integration into an external naming service or
services. services.
skipping to change at page 12, line 5 skipping to change at page 12, line 36
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 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],
IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server
interaction, the RPCSEC_GSS [RFC2203] framework should be strongly interaction, the RPCSEC_GSS [RFC2203] framework should be strongly
considered since it provides a method to employ mechanisms like SPKM considered since it provides a method to employ mechanisms like SPKM
and KerberosV5. Before a security mechanism can be evaluated, the and KerberosV5. Before a security mechanism can be evaluated, the
NFS environment and requirements must be discussed. NFS environment and requirements must be discussed.
NFSv4 NFSv4 Design Considerations May 1999
6.2.1. Transport Independence 6.2.1. Transport Independence
As mentioned later in this document in the section "Internet As mentioned later in this document in the section "Internet
Accessibility", transport independence is an asset for NFS and ONCRPC Accessibility", transport independence is an asset for NFS and ONCRPC
and is a general requirement. This allows for transport choice based and is a general requirement. This allows for transport choice based
on the target environment and specific application of NFS. The most on the target environment and specific application of NFS. The most
common transports in use with NFS are UDP and TCP. This ability to common transports in use with NFS are UDP and TCP. This ability to
choose transport should be maintained in combination with the user's choose transport should be maintained in combination with the user's
choice of a security mechanism. This implies that "mandatory to choice of a security mechanism. This implies that "mandatory to
implement" security mechanisms for NFS should allow for both implement" security mechanisms for NFS should allow for both
skipping to change at page 13, line 4 skipping to change at page 13, line 33
identification and authentication information. It is common in NFS identification and authentication information. It is common in NFS
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 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.
6.2.4. Data Privacy 6.2.4. Data Privacy
Data privacy, while desirable, is not as important in all Data privacy, while desirable, is not as important in all
environments as authentication and integrity. For example, in a LAN environments as authentication and integrity. For example, in a LAN
environment the performance overhead of data privacy may not be environment the performance overhead of data privacy may not be
NFSv4 NFSv4 Design Considerations May 1999
required to meet an organization's data protection policies. It may required to meet an organization's data protection policies. It may
also be the case that the performance of the distributed file system also be the case that the performance of the distributed file system
solution is more important than the data privacy of that solution. solution is more important than the data privacy of that solution.
Even with these considerations, the user or administrator must have Even with these considerations, the user or administrator must have
the choice of data privacy and therefore it must be included in NFS the choice of data privacy and therefore it must be included in NFS
version 4. version 4.
6.2.5. Security Negotiation 6.2.5. Security Negotiation
With the ability to provide security mechanism choices to the user or With the ability to provide security mechanism choices to the user or
skipping to change at page 14, line 5 skipping to change at page 14, line 34
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 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.
NFS version 4 must provide for strong authentication, integrity, and NFS version 4 must provide for strong authentication, integrity, and
privacy. This must be part of the protocol so that users have the privacy. This must be part of the protocol so that users have the
choice to use strong security if their environment or policies choice to use strong security if their environment or policies
warrant such use. warrant such use.
Based on the requirements presented, the ONCRPC RPCSEC_GSS security Based on the requirements presented, the ONCRPC RPCSEC_GSS security
flavor seems to provide an appropriate framework for satisfying these flavor seems to provide an appropriate framework for satisfying these
requirements. RPCSEC_GSS provides for authentication, integrity, and requirements. RPCSEC_GSS provides for authentication, integrity, and
NFSv4 NFSv4 Design Considerations May 1999
privacy. The RPCSEC_GSS is also extensible in that it provides for privacy. The RPCSEC_GSS is also extensible in that it provides for
both public and private key security mechanisms along with the both public and private key security mechanisms along with the
ability to plug in various mechanisms in such a way that it does not ability to plug in various mechanisms in such a way that it does not
significantly disrupt ONCRPC or NFS implementations. significantly disrupt ONCRPC or NFS implementations.
With RPCSEC_GSS' ability to support both public and private key With RPCSEC_GSS' ability to support both public and private key
mechanisms, NFS version 4 should consider "mandatory to implement" mechanisms, NFS version 4 should consider "mandatory to implement"
choices from both. The intent is to provide a security solution that choices from both. The intent is to provide a security solution that
will flexibly scale to match the needs of end users. Providing this will flexibly scale to match the needs of end users. Providing this
range of solutions will allow for appropriate usage based on policy range of solutions will allow for appropriate usage based on policy
skipping to change at page 15, line 4 skipping to change at page 15, line 32
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 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
produce greater throughput as compared to similarly configured produce greater throughput as compared to similarly configured
systems that use TCP. This issue will need to be investigated such systems that use TCP. This issue will need to be investigated such
that a determination can be made as to whether the differences are that a determination can be made as to whether the differences are
within implementation details. If UDP is supplied as an NFS within implementation details. If UDP is supplied as an NFS
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.
NFSv4 NFSv4 Design Considerations May 1999
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,
content control, and cache content validation. It is possible that and content control. It is possible that these issues can be
these issues can be addressed by documenting the related issues of addressed by documenting the related issues of proxy server usage.
proxy server usage. However, it is likely that the NFS protocol will However, it is likely that the NFS protocol will need to support
need to support proxy servers directly through the NFS protocol. 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 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.
This same approach can be used by NFS to allow the grouping of This same approach can be used by NFS to allow the grouping of
multiple procedure calls together in a traditional RPC request. Not multiple procedure calls together in a traditional RPC request. Not
only would this reduce protocol imposed latency but it would reduce only would this reduce protocol imposed latency but it would reduce
transport and security processing overhead and could allow a client transport and security processing overhead and could allow a client
to complete more complex tasks by combining procedures. to complete more complex tasks by combining procedures.
NFSv4 NFSv4 Design Considerations May 1999
8. File locking / recovery 8. File locking / recovery
NFS provided Unix file locking and DOS SHARE capability with the use NFS provided Unix file locking and DOS SHARE capability with the use
of an ancillary protocol (Network Lock Manager / NLM). The DOS SHARE of an ancillary protocol (Network Lock Manager / NLM). The DOS SHARE
mechanism is the DOS equivalent of file locking in that it provides mechanism is the DOS equivalent of file locking in that it provides
the basis for sharing or exclusive access to file and directory data the basis for sharing or exclusive access to file and directory data
without risk of data corruption. The NLM protocol provides file without risk of data corruption. The NLM protocol provides file
locking and recovery of those locks in the event of client or server locking and recovery of those locks in the event of client or server
failure. The NLM protocol requires that the server make call backs failure. The NLM protocol requires that the server make call backs
to the client for certain scenarios and therefore is not necessarily to the client for certain scenarios and therefore is not necessarily
skipping to change at page 17, line 5 skipping to change at page 17, line 38
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 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
state between server instantiations. state between server instantiations.
o Internet capable (firewall traversal, latency sensitive). The o Internet capable (firewall traversal, latency sensitive). The
server should not be required to initiate TCP connections to server should not be required to initiate TCP connections to
clients. clients.
o Timely recovery in the event of client/server or network o Timely recovery in the event of client/server or network
NFSv4 NFSv4 Design Considerations May 1999
failure. Server recovery should be rapid. The protocol should failure. Server recovery should be rapid. The protocol should
allow clients to detect the loss of a lock. allow clients to detect the loss of a lock.
9. Internationalization 9. Internationalization
NFS version 2 and 3 are currently limited in the character encoding NFS version 2 and 3 are currently limited in the character encoding
of strings. In the NFS protocols, strings are used for file and of strings. In the NFS protocols, strings are used for file and
directory names, and symbolic link contents. Although the XDR directory names, and symbolic link contents. Although the XDR
definition [RFC1832] limits strings in the NFS protocol to 7-bit US- 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. ASCII, common usage is to encode filenames in 8-bit ISO-Latin-1.
skipping to change at page 18, line 5 skipping to change at page 18, line 38
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 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
other structure or content specification has been levied upon the other structure or content specification has been levied upon the
file content. The main advantage to this approach is its flexibility. file content. The main advantage to this approach is its flexibility.
This byte stream can contain any data content and may be accessed in This byte stream can contain any data content and may be accessed in
any sequential or random fashion. Unfortunately, it is left to the any sequential or random fashion. Unfortunately, it is left to the
application or user to make the determination of file content and application or user to make the determination of file content and
format. It is possible to construct a mechanism in the protocol that format. It is possible to construct a mechanism in the protocol that
NFSv4 NFSv4 Design Considerations May 1999
specifies file data type while maintaining the byte stream model for specifies file data type while maintaining the byte stream model for
data access. However, this approach may be limiting in ways unclear data access. However, this approach may be limiting in ways unclear
to the designers of the NFS version 4 protocol. An expandable and to the designers of the NFS version 4 protocol. An expandable and
adaptable approach is to use the previously discussed extended adaptable approach is to use the previously discussed extended
attributes as the mechanism to specify file content and format. The attributes as the mechanism to specify file content and format. The
use of extended attributes allows for future definition and growth as use of extended attributes allows for future definition and growth as
various data types are created and allows for maintaining a simple various data types are created and allows for maintaining a simple
file data model for the NFS protocol. file data model for the NFS protocol.
It should be noted that as the Unicode standards are currently It should be noted that as the Unicode standards are currently
skipping to change at page 19, line 5 skipping to change at page 19, line 38
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 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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 April 1999 NFSv4 NFSv4 Design Considerations May 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/