draft-ietf-nfsv4-rfc3530bis-21.txt   draft-ietf-nfsv4-rfc3530bis-22.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track D. Noveck, Ed. Intended status: Standards Track D. Noveck, Ed.
Expires: May 14, 2013 EMC Expires: August 2, 2013 EMC
November 10, 2012 January 29, 2013
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol - Obsoletes (if approved)
draft-ietf-nfsv4-rfc3530bis-21.txt draft-ietf-nfsv4-rfc3530bis-22.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed filesystem The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4 version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course, caching, and internationalization have been added. Of course,
attention has been applied to making NFS version 4 operate well in an attention has been applied to making NFS version 4 operate well in an
Internet environment. Internet environment.
This document, together with the companion XDR description document, This document, together with the companion XDR description document,
RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
protocol. 4 protocol.
Requirements Language Requirements Language
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 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2013. This Internet-Draft will expire on August 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 9 1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 9
1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 9 1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 10
1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 11 1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 11
1.4. Inconsistencies of this Document with the companion 1.4. Inconsistencies of this Document with the companion
document NFS Version 4 Protocol . . . . . . . . . . . . 11 document NFS Version 4 Protocol . . . . . . . . . . . . 11
1.5. Overview of NFSv4 Features . . . . . . . . . . . . . . . 12 1.5. Overview of NFSv4 Features . . . . . . . . . . . . . . . 12
1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12 1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12
1.5.2. Procedure and Operation Structure . . . . . . . . . 12 1.5.2. Procedure and Operation Structure . . . . . . . . . 12
1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13 1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15 1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15
1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15 1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15
1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 1.5.6. Client Caching and Delegation . . . . . . . . . . . 15
skipping to change at page 7, line 48 skipping to change at page 7, line 48
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 272 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 272
15.25. Operation 25: READ - Read from File . . . . . . . . . . 273 15.25. Operation 25: READ - Read from File . . . . . . . . . . 273
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 275 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 275
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 279 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 279
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 280 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 280
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 282 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 282
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 284 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 284
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 285 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 285
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 286 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 286
15.33. Operation 33: SECINFO - Obtain Available Security . . . 287 15.33. Operation 33: SECINFO - Obtain Available Security . . . 287
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 290 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 291
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 293 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 293
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 297 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 297
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 300 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 300
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 302 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 302
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 306 State . . . . . . . . . . . . . . . . . . . . . . . . . 306
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 307 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 307
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 308 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 308
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 308 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 308
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 308 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 308
skipping to change at page 8, line 23 skipping to change at page 8, line 23
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 312 Operation . . . . . . . . . . . . . . . . . . . . . 312
17. Security Considerations . . . . . . . . . . . . . . . . . . . 313 17. Security Considerations . . . . . . . . . . . . . . . . . . . 313
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 315 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 315
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 315 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 315
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 316 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 316
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 316 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 316
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 316 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 316
19.1. Normative References . . . . . . . . . . . . . . . . . . 316 19.1. Normative References . . . . . . . . . . . . . . . . . . 316
19.2. Informative References . . . . . . . . . . . . . . . . . 317 19.2. Informative References . . . . . . . . . . . . . . . . . 317
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 319 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 320
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 320 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 320
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 320 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321
1. Introduction 1. Introduction
1.1. Changes since RFC 3530 1.1. Changes since RFC 3530
This document, together with the companion XDR description document This document, together with the companion XDR description document
[2], obsoletes RFC 3530 [11] as the authoritative document describing [I-D.ietf-nfsv4-rfc3530bis-dot-x], obsoletes RFC 3530 [RFC3530] as
NFSv4. It does not introduce any over-the-wire protocol changes, in the authoritative document describing NFSv4. It does not introduce
the sense that previously valid requests requests remain valid. any over-the-wire protocol changes, in the sense that previously
However, some requests previously defined as invalid, although not valid requests requests remain valid. However, some requests
generally rejected, are now explicitly allowed, in that previously defined as invalid, although not generally rejected, are
internationalization handling has been generalized and liberalized. now explicitly allowed, in that internationalization handling has
The main changes from RFC 3530 are: been generalized and liberalized. The main changes from RFC 3530
are:
o The XDR definition has been moved to a companion document [2] o The XDR definition has been moved to a companion document
[I-D.ietf-nfsv4-rfc3530bis-dot-x]
o Updates for the latest IETF intellectual property statements o Updates for the latest IETF intellectual property statements
o There is a restructured and more complete explanation of multi- o There is a restructured and more complete explanation of multi-
server namespace features. In particular, this explanation server namespace features. In particular, this explanation
explicitly describes handling of inter-server referrals, even explicitly describes handling of inter-server referrals, even
where neither migration nor replication is involved. where neither migration nor replication is involved.
o More liberal handling of internationalization for file names and o More liberal handling of internationalization for file names and
user and group names, with the elimination of restrictions imposed user and group names, with the elimination of restrictions imposed
by stringprep, with the recognition that rules for the forms of by stringprep, with the recognition that rules for the forms of
these name are the province of the receiving entity. these name are the province of the receiving entity.
o Updating handling of domain names to reflect IDNA [3]. o Updating handling of domain names to reflect IDNA
[I-D.draft-ietf-idna].
o Restructuring of string types to more appropriately reflect the o Restructuring of string types to more appropriately reflect the
reality of required string processing. reality of required string processing.
o The previously required LIPKEY and SPKM-3 security mechanisms have o The previously required LIPKEY and SPKM-3 security mechanisms have
been removed. been removed.
o Some clarification on a client re-establishing callback o Some clarification on a client re-establishing callback
information to the new server if state has been migrated. information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network o A third edge case was added for Courtesy locks and network
partitions. partitions.
o The definition of stateid was strengthened. o The definition of stateid was strengthened.
1.2. Changes since RFC 3010 1.2. Changes since RFC 3010
This definition of the NFSv4 protocol replaces or obsoletes the This definition of the NFSv4 protocol replaces or obsoletes the
definition present in [12]. While portions of the two documents have definition present in [RFC3010]. While portions of the two documents
remained the same, there have been substantive changes in others. have remained the same, there have been substantive changes in
others. The changes made between [RFC3010] and this document
The changes made between [12] and this document represent represent implementation experience and further review of the
implementation experience and further review of the protocol. While protocol. While some modifications were made for ease of
some modifications were made for ease of implementation or implementation or clarification, most updates represent errors or
clarification, most updates represent errors or situations where the situations where the [RFC3010] definition were untenable.
[12] definition were untenable.
The following list is not all inclusive of all changes but presents The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made: some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that and the lock_owner4 identifier would correspond to a process that
is locking a file. is locking a file.
skipping to change at page 11, line 11 skipping to change at page 11, line 17
o Remove use of the pathname4 data type from LOOKUP and OPEN in o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect. operations to achieve the same effect.
o Clarification of the internationalization issues and adoption of o Clarification of the internationalization issues and adoption of
the new stringprep profile framework. the new stringprep profile framework.
1.3. NFS Version 4 Goals 1.3. NFS Version 4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The NFSv4 protocol is a further revision of the NFS protocol defined
already by versions 2 [13] and 3 [14]. It retains the essential already by versions 2 [RFC1094] and 3 [RFC1813]. It retains the
characteristics of previous versions: design for easy recovery, essential characteristics of previous versions: design for easy
independent of transport protocols, operating systems and recovery, independent of transport protocols, operating systems and
filesystems, simplicity, and good performance. The NFSv4 revision filesystems, simplicity, and good performance. The NFSv4 revision
has the following goals: has the following goals:
o Improved access and good performance on the Internet. o Improved access and good performance on the Internet.
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
o Strong security with negotiation built into the protocol. o Strong security with negotiation built into the protocol.
skipping to change at page 11, line 45 skipping to change at page 11, line 51
or operating system over another. or operating system over another.
o Designed for protocol extensions. o Designed for protocol extensions.
The protocol is designed to accept standard extensions that do not The protocol is designed to accept standard extensions that do not
compromise backward compatibility. compromise backward compatibility.
1.4. Inconsistencies of this Document with the companion document NFS 1.4. Inconsistencies of this Document with the companion document NFS
Version 4 Protocol Version 4 Protocol
[2], NFS Version 4 Protocol, contains the definitions in XDR [I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains
description language of the constructs used by the protocol. Inside the definitions in XDR description language of the constructs used by
this document, several of the constructs are reproduced for purposes the protocol. Inside this document, several of the constructs are
of explanation. The reader is warned of the possibility of errors in reproduced for purposes of explanation. The reader is warned of the
the reproduced constructs outside of [2]. For any part of the possibility of errors in the reproduced constructs outside of
document that is inconsistent with [2], [2] is to be considered [I-D.ietf-nfsv4-rfc3530bis-dot-x]. For any part of the document that
authoritative. is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x],
[I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative.
1.5. Overview of NFSv4 Features 1.5. Overview of NFSv4 Features
To provide a reasonable context for the reader, the major features of To provide a reasonable context for the reader, the major features of
NFSv4 protocol will be reviewed in brief. This will be done to NFSv4 protocol will be reviewed in brief. This will be done to
provide an appropriate context for both the reader who is familiar provide an appropriate context for both the reader who is familiar
with the previous versions of the NFS protocol and the reader that is with the previous versions of the NFS protocol and the reader that is
new to the NFS protocols. For the reader new to the NFS protocols, new to the NFS protocols. For the reader new to the NFS protocols,
some fundamental knowledge is still expected. The reader should be some fundamental knowledge is still expected. The reader should be
familiar with the XDR and RPC protocols as described in [4] and [15]. familiar with the XDR and RPC protocols as described in [RFC5531] and
A basic knowledge of filesystems and distributed filesystems is [RFC4506]. A basic knowledge of filesystems and distributed
expected as well. filesystems is expected as well.
1.5.1. RPC and Security 1.5.1. RPC and Security
As with previous versions of NFS, the External Data Representation As with previous versions of NFS, the External Data Representation
(XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4
protocol are those defined in [4] and [15]. To meet end to end protocol are those defined in [RFC5531] and [RFC4506]. To meet end
security requirements, the RPCSEC_GSS framework [5] will be used to to end security requirements, the RPCSEC_GSS framework [RFC2203] will
extend the basic RPC security. With the use of RPCSEC_GSS, various be used to extend the basic RPC security. With the use of
mechanisms can be provided to offer authentication, integrity, and RPCSEC_GSS, various mechanisms can be provided to offer
privacy to the NFS version 4 protocol. Kerberos V5 will be used as authentication, integrity, and privacy to the NFS version 4 protocol.
described in [16] to provide one security framework. With the use of Kerberos V5 will be used as described in [RFC4121] to provide one
RPCSEC_GSS, other mechanisms may also be specified and used for NFS security framework. With the use of RPCSEC_GSS, other mechanisms may
version 4 security. also be specified and used for NFS version 4 security.
To enable in-band security negotiation, the NFSv4 protocol has added To enable in-band security negotiation, the NFSv4 protocol has added
a new operation which provides the client a method of querying the a new operation which provides the client a method of querying the
server about its policies regarding which security mechanisms must be server about its policies regarding which security mechanisms must be
used for access to the server's filesystem resources. With this, the used for access to the server's filesystem resources. With this, the
client can securely match the security mechanism that meets the client can securely match the security mechanism that meets the
policies specified at both the client and server. policies specified at both the client and server.
1.5.2. Procedure and Operation Structure 1.5.2. Procedure and Operation Structure
skipping to change at page 14, line 12 skipping to change at page 14, line 17
filehandle being provided by the server and can be prepared to deal filehandle being provided by the server and can be prepared to deal
with the semantics of each. with the semantics of each.
1.5.3.2. Attribute Types 1.5.3.2. Attribute Types
The NFSv4 protocol has a rich and extensible file object attribute The NFSv4 protocol has a rich and extensible file object attribute
structure, which is divided into REQUIRED, RECOMMENDED, and named structure, which is divided into REQUIRED, RECOMMENDED, and named
attributes (see Section 5). attributes (see Section 5).
Several (but not all) of the REQUIRED attributes are derived from the Several (but not all) of the REQUIRED attributes are derived from the
attributes of NFSv3 (see definition of the fattr3 data type in [14]). attributes of NFSv3 (see definition of the fattr3 data type in
An example of a REQUIRED attribute is the file object's type [RFC1813]). An example of a REQUIRED attribute is the file object's
(Section 5.8.1.2) so that regular files can be distinguished from type (Section 5.8.1.2) so that regular files can be distinguished
directories (also known as folders in some operating environments) from directories (also known as folders in some operating
and other types of objects. REQUIRED attributes are discussed in environments) and other types of objects. REQUIRED attributes are
Section 5.1. discussed in Section 5.1.
An example of the RECOMMENDED attributes is an acl. This attribute An example of the RECOMMENDED attributes is an acl. This attribute
defines an Access Control List (ACL) on a file object ((Section 6). defines an Access Control List (ACL) on a file object ((Section 6).
An ACL provides file access control beyond the model used in NFSv3. An ACL provides file access control beyond the model used in NFSv3.
The ACL definition allows for specification of specific sets of The ACL definition allows for specification of specific sets of
permissions for individual users and groups. In addition, ACL permissions for individual users and groups. In addition, ACL
inheritance allows propagation of access permissions and restriction inheritance allows propagation of access permissions and restriction
down a directory tree as file system objects are created. down a directory tree as file system objects are created.
RECOMMENDED attributes are discussed in Section 5.2. RECOMMENDED attributes are discussed in Section 5.2.
skipping to change at page 18, line 20 skipping to change at page 18, line 23
server for a specific open-owner or lock-owner/open-owner pair for server for a specific open-owner or lock-owner/open-owner pair for
a specific file and type of lock. a specific file and type of lock.
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
2. Protocol Data Types 2. Protocol Data Types
The syntax and semantics to describe the data types of the NFS The syntax and semantics to describe the data types of the NFS
version 4 protocol are defined in the XDR [15] and RPC [4] documents. version 4 protocol are defined in the XDR [RFC4506] and RPC [RFC5531]
The next sections build upon the XDR data types to define types and documents. The next sections build upon the XDR data types to define
structures specific to this protocol. types and structures specific to this protocol.
2.1. Basic Data Types 2.1. Basic Data Types
These are the base NFSv4 data types. These are the base NFSv4 data types.
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| Data Type | Definition | | Data Type | Definition |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| int32_t | typedef int int32_t; | | int32_t | typedef int int32_t; |
| uint32_t | typedef unsigned int uint32_t; | | uint32_t | typedef unsigned int uint32_t; |
skipping to change at page 19, line 18 skipping to change at page 19, line 21
| | Various defined file types. | | | Various defined file types. |
| nfsstat4 | enum nfsstat4; | | nfsstat4 | enum nfsstat4; |
| | Return value for operations. | | | Return value for operations. |
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, | | | Various offset designations (READ, WRITE, |
| | LOCK, COMMIT). | | | LOCK, COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in | | | Quality of protection designation in |
| | SECINFO. | | | SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 | | | Security Object Identifier. The sec_oid4 |
| | data type is not really opaque. Instead | | | data type is not really opaque. Instead it |
| | it contains an ASN.1 OBJECT IDENTIFIER as | | | contains an ASN.1 OBJECT IDENTIFIER as |
| | used by GSS-API in the mech_type argument | | | used by GSS-API in the mech_type argument |
| | to GSS_Init_sec_context. See [6] for | | | to GSS_Init_sec_context. See [RFC2743] for |
| | details. | | | details. |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| utf8string | typedef opaque utf8string<>; | | utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8_expected | typedef utf8string utf8_expected; | | utf8_expected | typedef utf8string utf8_expected; |
| | String expected to be UTF-8 but no | | | String expected to be UTF-8 but no |
| | validation | | | validation |
| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |
| | String SHOULD be sent UTF-8 and SHOULD be | | | String SHOULD be sent UTF-8 and SHOULD be |
skipping to change at page 23, line 4 skipping to change at page 23, line 4
struct clientaddr4 { struct clientaddr4 {
/* see struct rpcb in RFC 1833 */ /* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */ string r_netid<>; /* network id */
string r_addr<>; /* universal address */ string r_addr<>; /* universal address */
}; };
The clientaddr4 structure is used as part of the SETCLIENTID The clientaddr4 structure is used as part of the SETCLIENTID
operation to either specify the address of the client that is using a operation to either specify the address of the client that is using a
client ID or as part of the callback registration. The r_netid and client ID or as part of the callback registration. The r_netid and
r_addr fields respectively contain a netid and uaddr. The netid and r_addr fields respectively contain a netid and uaddr. The netid and
uaddr concepts are defined in [7]. The netid and uaddr formats for uaddr concepts are defined in [RFC5665]. The netid and uaddr formats
TCP over IPv4 and TCP over IPv6 are defined in [7], specifically for TCP over IPv4 and TCP over IPv6 are defined in [RFC5665],
Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4. specifically Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4.
2.2.11. cb_client4 2.2.11. cb_client4
struct cb_client4 { struct cb_client4 {
unsigned int cb_program; unsigned int cb_program;
clientaddr4 cb_location; clientaddr4 cb_location;
}; };
This structure is used by the client to inform the server of its call This structure is used by the client to inform the server of its call
back address; includes the program number and client address. back address; includes the program number and client address.
skipping to change at page 24, line 39 skipping to change at page 24, line 39
between the client and server. For the client, this data structure between the client and server. For the client, this data structure
is read-only. The server is required to increment the seqid field is read-only. The server is required to increment the seqid field
monotonically at each transition of the stateid. This is important monotonically at each transition of the stateid. This is important
since the client will inspect the seqid in OPEN stateids to determine since the client will inspect the seqid in OPEN stateids to determine
the order of OPEN processing done by the server. the order of OPEN processing done by the server.
3. RPC and Security Flavor 3. RPC and Security Flavor
The NFSv4 protocol is a Remote Procedure Call (RPC) application that The NFSv4 protocol is a Remote Procedure Call (RPC) application that
uses RPC version 2 and the corresponding eXternal Data Representation uses RPC version 2 and the corresponding eXternal Data Representation
(XDR) as defined in [4] and [15]. The RPCSEC_GSS security flavor as (XDR) as defined in [RFC5531] and [RFC4506]. The RPCSEC_GSS security
defined in [5] MUST be implemented as the mechanism to deliver flavor as defined in [RFC2203] MUST be implemented as the mechanism
stronger security for the NFSv4 protocol. However, deployment of to deliver stronger security for the NFSv4 protocol. However,
RPCSEC_GSS is optional. deployment of RPCSEC_GSS is optional.
3.1. Ports and Transports 3.1. Ports and Transports
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The Historically, NFSv2 and NFSv3 servers have resided on port 2049. The
registered port 2049 [17] for the NFS protocol SHOULD be the default registered port 2049 [RFC3232] for the NFS protocol SHOULD be the
configuration. Using the registered port for NFS services means the default configuration. Using the registered port for NFS services
NFS client will not need to use the RPC binding protocols as means the NFS client will not need to use the RPC binding protocols
described in [18]; this will allow NFS to transit firewalls. as described in [RFC1833]; this will allow NFS to transit firewalls.
Where an NFSv4 implementation supports operation over the IP network Where an NFSv4 implementation supports operation over the IP network
protocol, the supported transports between NFS and IP MUST be among protocol, the supported transports between NFS and IP MUST be among
the IETF-approved congestion control transport protocols, which the IETF-approved congestion control transport protocols, which
include TCP and SCTP. To enhance the possibilities for include TCP and SCTP. To enhance the possibilities for
interoperability, an NFSv4 implementation MUST support operation over interoperability, an NFSv4 implementation MUST support operation over
the TCP transport protocol, at least until such time as a standards the TCP transport protocol, at least until such time as a standards
track RFC revises this requirement to use a different IETF-approved track RFC revises this requirement to use a different IETF-approved
congestion control transport protocol. congestion control transport protocol.
If TCP is used as the transport, the client and server SHOULD use If TCP is used as the transport, the client and server SHOULD use
persistent connections. This will prevent the weakening of TCP's persistent connections. This will prevent the weakening of TCP's
congestion control via short lived connections and will improve congestion control via short lived connections and will improve
performance for the WAN environment by eliminating the need for SYN performance for the WAN environment by eliminating the need for SYN
handshakes. handshakes.
To date, all NFSv4 implementations are TCP based, i.e., there are To date, all NFSv4 implementations are TCP based, i.e., there are
none for SCTP nor UDP. UDP by itself is not sufficient as a none for SCTP nor UDP. UDP by itself is not sufficient as a
transport for NFSv4, neither is UDP in combination with some other transport for NFSv4, neither is UDP in combination with some other
mechanism (e.g., DCCP [19], NORM [20]). mechanism (e.g., DCCP [RFC4340], NORM [RFC3940]).
As noted in Section 17, the authentication model for NFSv4 has moved As noted in Section 17, the authentication model for NFSv4 has moved
from machine-based to principal-based. However, this modification of from machine-based to principal-based. However, this modification of
the authentication model does not imply a technical requirement to the authentication model does not imply a technical requirement to
move the TCP connection management model from whole machine-based to move the TCP connection management model from whole machine-based to
one based on a per user model. In particular, NFS over TCP client one based on a per user model. In particular, NFS over TCP client
implementations have traditionally multiplexed traffic for multiple implementations have traditionally multiplexed traffic for multiple
users over a common TCP connection between an NFS client and server. users over a common TCP connection between an NFS client and server.
This has been true, regardless whether the NFS client is using This has been true, regardless whether the NFS client is using
AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS
over TCP server implementations have assumed such a model and thus over TCP server implementations have assumed such a model and thus
scale the implementation of TCP connection management in proportion scale the implementation of TCP connection management in proportion
to the number of expected client machines. It is intended that NFSv4 to the number of expected client machines. It is intended that NFSv4
will not modify this connection management model. NFSv4 clients that will not modify this connection management model. NFSv4 clients that
violate this assumption can expect scaling issues on the server and violate this assumption can expect scaling issues on the server and
hence reduced service. hence reduced service.
Note that for various timers, the client and server should avoid Note that for various timers, the client and server should avoid
inadvertent synchronization of those timers. For further discussion inadvertent synchronization of those timers. For further discussion
of the general issue refer to [21]. of the general issue refer to [Floyd].
3.1.1. Client Retransmission Behavior 3.1.1. Client Retransmission Behavior
When processing a request received over a reliable transport such as When processing a request received over a reliable transport such as
TCP, the NFSv4 server MUST NOT silently drop the request, except if TCP, the NFSv4 server MUST NOT silently drop the request, except if
the transport connection has been broken. Given such a contract the transport connection has been broken. Given such a contract
between NFSv4 clients and servers, clients MUST NOT retry a request between NFSv4 clients and servers, clients MUST NOT retry a request
unless one or both of the following are true: unless one or both of the following are true:
o The transport connection has been broken o The transport connection has been broken
skipping to change at page 26, line 32 skipping to change at page 26, line 32
or it can break the transport connection and reconnect before re- or it can break the transport connection and reconnect before re-
sending the original request. sending the original request.
For callbacks from the server to the client, the same rules apply, For callbacks from the server to the client, the same rules apply,
but the server doing the callback becomes the client, and the client but the server doing the callback becomes the client, and the client
receiving the callback becomes the server. receiving the callback becomes the server.
3.2. Security Flavors 3.2. Security Flavors
Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
AUTH_DH, and AUTH_KRB4 as security flavors. With [5] an additional AUTH_DH, and AUTH_KRB4 as security flavors. With [RFC2203] an
security flavor of RPCSEC_GSS has been introduced which uses the additional security flavor of RPCSEC_GSS has been introduced which
functionality of GSS-API [6]. This allows for the use of various uses the functionality of GSS-API [RFC2743]. This allows for the use
security mechanisms by the RPC layer without the additional of various security mechanisms by the RPC layer without the
implementation overhead of adding RPC security flavors. For NFSv4, additional implementation overhead of adding RPC security flavors.
the RPCSEC_GSS security flavor MUST be used to enable the mandatory For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the
security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and mandatory security mechanism. Other flavors, such as, AUTH_NONE,
AUTH_DH MAY be implemented as well. AUTH_SYS, and AUTH_DH MAY be implemented as well.
3.2.1. Security mechanisms for NFSv4 3.2.1. Security mechanisms for NFSv4
The use of RPCSEC_GSS requires selection of: mechanism, quality of The use of RPCSEC_GSS requires selection of: mechanism, quality of
protection, and service (authentication, integrity, privacy). The protection, and service (authentication, integrity, privacy). The
remainder of this document will refer to these three parameters of remainder of this document will refer to these three parameters of
the RPCSEC_GSS security as the security triple. the RPCSEC_GSS security as the security triple.
3.2.1.1. Kerberos V5 as a security triple 3.2.1.1. Kerberos V5 as a security triple
The Kerberos V5 GSS-API mechanism as described in [16] MUST be The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be
implemented and provide the following security triples. implemented and provide the following security triples.
column descriptions: column descriptions:
1 == number of pseudo flavor 1 == number of pseudo flavor
2 == name of pseudo flavor 2 == name of pseudo flavor
3 == mechanism's OID 3 == mechanism's OID
4 == mechanism's algorithm(s) 4 == mechanism's algorithm(s)
5 == RPCSEC_GSS service 5 == RPCSEC_GSS service
skipping to change at page 27, line 29 skipping to change at page 27, line 29
and 56 bit DES and 56 bit DES
for privacy. for privacy.
Note that the pseudo flavor is presented here as a mapping aid to the Note that the pseudo flavor is presented here as a mapping aid to the
implementor. Because this NFS protocol includes a method to implementor. Because this NFS protocol includes a method to
negotiate security and it understands the GSS-API mechanism, the negotiate security and it understands the GSS-API mechanism, the
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 pseudo flavor is not needed. The pseudo flavor is needed for NFSv3
since the security negotiation is done via the MOUNT protocol. since the security negotiation is done via the MOUNT protocol.
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please
see [22]. see [RFC2623].
3.3. Security Negotiation 3.3. Security Negotiation
With the NFSv4 server potentially offering multiple security With the NFSv4 server potentially offering multiple security
mechanisms, the client needs a method to determine or negotiate which mechanisms, the client needs a method to determine or negotiate which
mechanism is to be used for its communication with the server. The mechanism is to be used for its communication with the server. The
NFS server may have multiple points within its filesystem name space NFS server may have multiple points within its filesystem name space
that are available for use by NFS clients. In turn the NFS server that are available for use by NFS clients. In turn the NFS server
may be configured such that each of these entry points may have may be configured such that each of these entry points may have
different or multiple security mechanisms in use. different or multiple security mechanisms in use.
skipping to change at page 29, line 34 skipping to change at page 29, line 34
The filehandle in the NFS protocol is a per server unique identifier The filehandle in the NFS protocol is a per server unique identifier
for a filesystem object. The contents of the filehandle are opaque for a filesystem object. The contents of the filehandle are opaque
to the client. Therefore, the server is responsible for translating to the client. Therefore, the server is responsible for translating
the filehandle to an internal representation of the filesystem the filehandle to an internal representation of the filesystem
object. object.
4.1. Obtaining the First Filehandle 4.1. Obtaining the First Filehandle
The operations of the NFS protocol are defined in terms of one or The operations of the NFS protocol are defined in terms of one or
more filehandles. Therefore, the client needs a filehandle to more filehandles. Therefore, the client needs a filehandle to
initiate communication with the server. With the NFSv2 protocol [13] initiate communication with the server. With the NFSv2 protocol
and the NFSv3 protocol [14], there exists an ancillary protocol to [RFC1094] and the NFSv3 protocol [RFC1813], there exists an ancillary
obtain this first filehandle. The MOUNT protocol, RPC program number protocol to obtain this first filehandle. The MOUNT protocol, RPC
100005, provides the mechanism of translating a string based program number 100005, provides the mechanism of translating a string
filesystem path name to a filehandle which can then be used by the based filesystem path name to a filehandle which can then be used by
NFS protocols. the NFS protocols.
The MOUNT protocol has deficiencies in the area of security and use The MOUNT protocol has deficiencies in the area of security and use
via firewalls. This is one reason that the use of the public via firewalls. This is one reason that the use of the public
filehandle was introduced in [23] and [24]. With the use of the filehandle was introduced in [RFC2054] and [RFC2055]. With the use
public filehandle in combination with the LOOKUP operation in the of the public filehandle in combination with the LOOKUP operation in
NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT the NFSv2 and NFSv3 protocols, it has been demonstrated that the
protocol is unnecessary for viable interaction between NFS client and MOUNT protocol is unnecessary for viable interaction between NFS
server. client and server.
Therefore, the NFSv4 protocol will not use an ancillary protocol for Therefore, the NFSv4 protocol will not use an ancillary protocol for
translation from string based path names to a filehandle. Two translation from string based path names to a filehandle. Two
special filehandles will be used as starting points for the NFS special filehandles will be used as starting points for the NFS
client. client.
4.1.1. Root Filehandle 4.1.1. Root Filehandle
The first of the special filehandles is the ROOT filehandle. The The first of the special filehandles is the ROOT filehandle. The
ROOT filehandle is the "conceptual" root of the filesystem name space ROOT filehandle is the "conceptual" root of the filesystem name space
skipping to change at page 39, line 14 skipping to change at page 39, line 14
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the columns of the table are:
o Name: The name of attribute o Name: The name of attribute
o Id: The number assigned to the attribute. In the event of o Id: The number assigned to the attribute. In the event of
conflicts between the assigned number and [2], the latter is conflicts between the assigned number and
likely authoritative, but should be resolved with Errata to this [I-D.ietf-nfsv4-rfc3530bis-dot-x], the latter is likely
document and/or [2]. See [25] for the Errata process. authoritative, but should be resolved with Errata to this document
and/or [I-D.ietf-nfsv4-rfc3530bis-dot-x]. See [ISEG_errata] for
the Errata process.
o Data Type: The XDR data type of the attribute. o Data Type: The XDR data type of the attribute.
o Acc: Access allowed to the attribute. R means read-only (GETATTR o Acc: Access allowed to the attribute. R means read-only (GETATTR
may retrieve, SETATTR may not set). W means write-only (SETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR
may set, GETATTR may not retrieve). R W means read/write (GETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR
may retrieve, SETATTR may set). may retrieve, SETATTR may set).
o Defined in: The section of this specification that describes the o Defined in: The section of this specification that describes the
attribute. attribute.
skipping to change at page 44, line 28 skipping to change at page 44, line 28
5.8.2.9. Attribute 23: files_total 5.8.2.9. Attribute 23: files_total
Total file slots on the file system containing this object. Total file slots on the file system containing this object.
5.8.2.10. Attribute 24: fs_locations 5.8.2.10. Attribute 24: fs_locations
Locations where this file system may be found. If the server returns Locations where this file system may be found. If the server returns
NFS4ERR_MOVED as an error, this attribute MUST be supported. NFS4ERR_MOVED as an error, this attribute MUST be supported.
The server can specify a root path by setting an array of zero path The server specifies the root path for a given server by returning a
components. Other than this special case, the server MUST not path consisting of zero path components.
present empty path components to the client.
5.8.2.11. Attribute 25: hidden 5.8.2.11. Attribute 25: hidden
TRUE, if the file is considered hidden with respect to the Windows TRUE, if the file is considered hidden with respect to the Windows
API. API.
5.8.2.12. Attribute 26: homogeneous 5.8.2.12. Attribute 26: homogeneous
TRUE, if this object's file system is homogeneous, i.e., all objects TRUE, if this object's file system is homogeneous, i.e., all objects
in the file system (all objects on the server with the same fsid) in the file system (all objects on the server with the same fsid)
skipping to change at page 48, line 32 skipping to change at page 48, line 32
5.8.2.33. Attribute 47: time_access 5.8.2.33. Attribute 47: time_access
The time_access attribute represents the time of last access to the The time_access attribute represents the time of last access to the
object by a READ operation sent to the server. The notion of what is object by a READ operation sent to the server. The notion of what is
an "access" depends on the server's operating environment and/or the an "access" depends on the server's operating environment and/or the
server's file system semantics. For example, for servers obeying server's file system semantics. For example, for servers obeying
Portable Operating System Interface (POSIX) semantics, time_access Portable Operating System Interface (POSIX) semantics, time_access
would be updated only by the READ and READDIR operations and not any would be updated only by the READ and READDIR operations and not any
of the operations that modify the content of the object [16], [17], of the operations that modify the content of the object [16], [17],
[26], [27], [28]. Of course, setting the corresponding [read_api], [readdir_api], [write_api]. Of course, setting the
time_access_set attribute is another way to modify the time_access corresponding time_access_set attribute is another way to modify the
attribute. time_access attribute.
Whenever the file object resides on a writable file system, the Whenever the file object resides on a writable file system, the
server should make its best efforts to record time_access into stable server should make its best efforts to record time_access into stable
storage. However, to mitigate the performance effects of doing so, storage. However, to mitigate the performance effects of doing so,
and most especially whenever the server is satisfying the read of the and most especially whenever the server is satisfying the read of the
object's content from its cache, the server MAY cache access time object's content from its cache, the server MAY cache access time
updates and lazily write them to stable storage. It is also updates and lazily write them to stable storage. It is also
acceptable to give administrators of the server the option to disable acceptable to give administrators of the server the option to disable
time_access updates. time_access updates.
skipping to change at page 49, line 33 skipping to change at page 49, line 33
5.8.2.40. Attribute 54: time_modify_set 5.8.2.40. Attribute 54: time_modify_set
Sets the time of last modification to the object. SETATTR use only. Sets the time of last modification to the object. SETATTR use only.
5.9. Interpreting owner and owner_group 5.9. Interpreting owner and owner_group
The RECOMMENDED attributes "owner" and "owner_group" (and also users The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups within the "acl" attribute) are represented in terms of a and groups within the "acl" attribute) are represented in terms of a
UTF-8 string. To avoid a representation that is tied to a particular UTF-8 string. To avoid a representation that is tied to a particular
underlying implementation at the client or server, the use of the underlying implementation at the client or server, the use of the
UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [29] UTF-8 string has been chosen. Note that section 6.1 of RFC 2624
provides additional rationale. It is expected that the client and [RFC2624] provides additional rationale. It is expected that the
server will have their own local representation of owner and client and server will have their own local representation of owner
owner_group that is used for local storage or presentation to the end and owner_group that is used for local storage or presentation to the
user. Therefore, it is expected that when these attributes are end user. Therefore, it is expected that when these attributes are
transferred between the client and server, the local representation transferred between the client and server, the local representation
is translated to a syntax of the form "user@dns_domain". This will is translated to a syntax of the form "user@dns_domain". This will
allow for a client and server that do not use the same local allow for a client and server that do not use the same local
representation the ability to translate to a common syntax that can representation the ability to translate to a common syntax that can
be interpreted by both. be interpreted by both.
Similarly, security principals may be represented in different ways Similarly, security principals may be represented in different ways
by different security mechanisms. Servers normally translate these by different security mechanisms. Servers normally translate these
representations into a common format, generally that used by local representations into a common format, generally that used by local
storage, to serve as a means of identifying the users corresponding storage, to serve as a means of identifying the users corresponding
skipping to change at page 52, line 15 skipping to change at page 52, line 15
dns_domain". dns_domain".
The owner string "nobody" may be used to designate an anonymous user, The owner string "nobody" may be used to designate an anonymous user,
which will be associated with a file created by a security principal which will be associated with a file created by a security principal
that cannot be mapped through normal means to the owner attribute. that cannot be mapped through normal means to the owner attribute.
5.10. Character Case Attributes 5.10. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes, With respect to the case_insensitive and case_preserving attributes,
each UCS-4 character (which UTF-8 encodes) has a "long descriptive each UCS-4 character (which UTF-8 encodes) has a "long descriptive
name" RFC1345 [30] which may or may not include the word "CAPITAL" or name" RFC1345 [RFC1345] which may or may not include the word
"SMALL". The presence of SMALL or CAPITAL allows an NFS server to "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows an NFS
implement unambiguous and efficient table driven mappings for case server to implement unambiguous and efficient table driven mappings
insensitive comparisons, and non-case-preserving storage, although for case insensitive comparisons, and non-case-preserving storage,
there are variations that occur additional characters with a name although there are variations that occur additional characters with a
including "SMALL" or "CAPITAL" are added in a subsequent version of name including "SMALL" or "CAPITAL" are added in a subsequent version
Unicode. of Unicode.
For general character handling and internationalization issues, see For general character handling and internationalization issues, see
Section 12. For details regarding case mapping, see the section Section 12. For details regarding case mapping, see the section
Case-based Mapping Used for Component4 Strings. Case-based Mapping Used for Component4 Strings.
6. Access Control Attributes 6. Access Control Attributes
Access Control Lists (ACLs) are file attributes that specify fine Access Control Lists (ACLs) are file attributes that specify fine
grained access control. This chapter covers the "acl", "aclsupport", grained access control. This chapter covers the "acl", "aclsupport",
"mode", file attributes, and their interactions. Note that file "mode", file attributes, and their interactions. Note that file
skipping to change at page 82, line 12 skipping to change at page 82, line 12
Another issue concerns refresh of referral locations. When referrals Another issue concerns refresh of referral locations. When referrals
are used extensively, they may change as server configurations are used extensively, they may change as server configurations
change. It is expected that clients will cache information related change. It is expected that clients will cache information related
to traversing referrals so that future client-side requests are to traversing referrals so that future client-side requests are
resolved locally without server communication. This is usually resolved locally without server communication. This is usually
rooted in client-side name look up caching. Clients should rooted in client-side name look up caching. Clients should
periodically purge this data for referral points in order to detect periodically purge this data for referral points in order to detect
changes in location information. changes in location information.
A problem exists if a client allows an open owner to have state on A potential problem exists if a client were to allow an open owner to
multiple filesystems on a server. If one of those filesystems is have state on multiple filesystems on server, in that it is unclear
migrated, what happens to the sequence numbers? A client can avoid how the sequence numbers associated with open owners are to be dealt
such a situation with the stipulation that any client which supports with, in the event of transparent state migration. A client can
migration MUST ensure that any open owner is confined to a single avoid such a situation, if it ensures that any use of an open owner
filesystem. If the server finds itself migrating open owners that is confined to a single filesystem.
span multiple filesystems, then it MUST not migrate the state for the
conflicting open owners on the non-migrated filesystems; instead it A server MAY decline to migrate state associated with open owners
MUST return NFS4ERR_STALE_STATEID if the client tries to use those that span multiple filesystems. In cases in which the server chooses
stateids. not to migrate such state, the server MUST return NFS4ERR_BAD_STATEID
when the client uses those stateids on the new server.
The server MUST return NFS4ERR_STALE_STATEID when the client uses
those stateids on the old server, regardless of whether migration has
occurred or not.
7.7. Effecting File System Transitions 7.7. Effecting File System Transitions
Transitions between file system instances, whether due to switching Transitions between file system instances, whether due to switching
between replicas upon server unavailability or to server-initiated between replicas upon server unavailability or to server-initiated
migration events, are best dealt with together. This is so even migration events, are best dealt with together. This is so even
though, for the server, pragmatic considerations will normally force though, for the server, pragmatic considerations will normally force
different implementation strategies for planned and unplanned different implementation strategies for planned and unplanned
transitions. Even though the prototypical use cases of replication transitions. Even though the prototypical use cases of replication
and migration contain distinctive sets of features, when all and migration contain distinctive sets of features, when all
skipping to change at page 82, line 50 skipping to change at page 83, line 7
limit the changes seen by the client, to those that are less limit the changes seen by the client, to those that are less
aggressive, use more standard methods of replicating data, and impose aggressive, use more standard methods of replicating data, and impose
a greater burden on the client to adapt to the transition. a greater burden on the client to adapt to the transition.
The NFSv4 protocol does not impose choices on clients and servers The NFSv4 protocol does not impose choices on clients and servers
with regard to that spectrum of transition methods. In fact, there with regard to that spectrum of transition methods. In fact, there
are many valid choices, depending on client and application are many valid choices, depending on client and application
requirements and their interaction with server implementation requirements and their interaction with server implementation
choices. The NFSv4.0 protocol does not provide the servers a means choices. The NFSv4.0 protocol does not provide the servers a means
of communicating the transition methods. In the NFSv4.1 protocol of communicating the transition methods. In the NFSv4.1 protocol
[31], an additional attribute "fs_locations_info" is presented, which [RFC5661], an additional attribute "fs_locations_info" is presented,
will define the specific choices that can be made, how these choices which will define the specific choices that can be made, how these
are communicated to the client, and how the client is to deal with choices are communicated to the client, and how the client is to deal
any discontinuities. with any discontinuities.
In the sections below, references will be made to various possible In the sections below, references will be made to various possible
server implementation choices as a way of illustrating the transition server implementation choices as a way of illustrating the transition
scenarios that clients may deal with. The intent here is not to scenarios that clients may deal with. The intent here is not to
define or limit server implementations but rather to illustrate the define or limit server implementations but rather to illustrate the
range of issues that clients may face. Again, as the NFSv4.0 range of issues that clients may face. Again, as the NFSv4.0
protocol does not have an explicit means of communicating these protocol does not have an explicit means of communicating these
issues to the client, the intent is to document the problems that can issues to the client, the intent is to document the problems that can
be faced in a multi-server name space and allow the client to use the be faced in a multi-server name space and allow the client to use the
inferred transitions available via fs_locations and other attributes inferred transitions available via fs_locations and other attributes
skipping to change at page 103, line 27 skipping to change at page 103, line 27
For the case of the use of multiple, disjoint security mechanisms in For the case of the use of multiple, disjoint security mechanisms in
the server's resources, the security for a particular object in the the server's resources, the security for a particular object in the
server's namespace should be the union of all security mechanisms of server's namespace should be the union of all security mechanisms of
all direct descendants. all direct descendants.
9. File Locking and Share Reservations 9. File Locking and Share Reservations
Integrating locking into the NFS protocol necessarily causes it to be Integrating locking into the NFS protocol necessarily causes it to be
stateful. With the inclusion of share reservations the protocol stateful. With the inclusion of share reservations the protocol
becomes substantially more dependent on state than the traditional becomes substantially more dependent on state than the traditional
combination of NFS and NLM (Network Lock Manager) [32]. There are combination of NFS and NLM (Network Lock Manager) [xnfs]. There are
three components to making this state manageable: three components to making this state manageable:
o clear division between client and server o clear division between client and server
o ability to reliably detect inconsistency in state between client o ability to reliably detect inconsistency in state between client
and server and server
o simple and robust recovery mechanisms o simple and robust recovery mechanisms
In this model, the server owns the state information. The client In this model, the server owns the state information. The client
skipping to change at page 117, line 49 skipping to change at page 117, line 49
received before the last request (L) was sent. If a duplicate of received before the last request (L) was sent. If a duplicate of
last request (r == L) is received, the stored response is returned. last request (r == L) is received, the stored response is returned.
If a request beyond the next sequence (r == L + 2) is received, it is If a request beyond the next sequence (r == L + 2) is received, it is
rejected with the return of error NFS4ERR_BAD_SEQID. Sequence rejected with the return of error NFS4ERR_BAD_SEQID. Sequence
history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
sequence changes the client verifier. sequence changes the client verifier.
Since the sequence number is represented with an unsigned 32-bit Since the sequence number is represented with an unsigned 32-bit
integer, the arithmetic involved with the sequence number is mod integer, the arithmetic involved with the sequence number is mod
2^32. For an example of modulo arithmetic involving sequence numbers 2^32. For an example of modulo arithmetic involving sequence numbers
see [33]. see [RFC0793].
It is critical the server maintain the last response sent to the It is critical the server maintain the last response sent to the
client to provide a more reliable cache of duplicate non-idempotent client to provide a more reliable cache of duplicate non-idempotent
requests than that of the traditional cache described in [34]. The requests than that of the traditional cache described in [Chet]. The
traditional duplicate request cache uses a least recently used traditional duplicate request cache uses a least recently used
algorithm for removing unneeded requests. However, the last lock algorithm for removing unneeded requests. However, the last lock
request and response on a given state-owner must be cached as long as request and response on a given state-owner must be cached as long as
the lock state exists on the server. the lock state exists on the server.
The client MUST monotonically increment the sequence number for the The client MUST monotonically increment the sequence number for the
CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
operations. This is true even in the event that the previous operations. This is true even in the event that the previous
operation that used the sequence number received an error. The only operation that used the sequence number received an error. The only
exception to this rule is if the previous operation received one of exception to this rule is if the previous operation received one of
skipping to change at page 126, line 17 skipping to change at page 126, line 17
requests to be processed during the grace period, it MUST determine requests to be processed during the grace period, it MUST determine
that no lock subsequently reclaimed will be rejected and that no lock that no lock subsequently reclaimed will be rejected and that no lock
subsequently reclaimed would have prevented any I/O operation subsequently reclaimed would have prevented any I/O operation
processed during the grace period. processed during the grace period.
Clients should be prepared for the return of NFS4ERR_GRACE errors for Clients should be prepared for the return of NFS4ERR_GRACE errors for
non-reclaim lock and I/O requests. In this case the client should non-reclaim lock and I/O requests. In this case the client should
employ a retry mechanism for the request. A delay (on the order of employ a retry mechanism for the request. A delay (on the order of
several seconds) between retries should be used to avoid overwhelming several seconds) between retries should be used to avoid overwhelming
the server. Further discussion of the general issue is included in the server. Further discussion of the general issue is included in
[21]. The client must account for the server that is able to perform [Floyd]. The client must account for the server that is able to
I/O and non-reclaim locking requests within the grace period as well perform I/O and non-reclaim locking requests within the grace period
as those that cannot do so. as well as those that cannot do so.
A reclaim-type locking request outside the server's grace period can A reclaim-type locking request outside the server's grace period can
only succeed if the server can guarantee that no conflicting lock or only succeed if the server can guarantee that no conflicting lock or
I/O request has been granted since reboot or restart. I/O request has been granted since reboot or restart.
A server may, upon restart, establish a new value for the lease A server may, upon restart, establish a new value for the lease
period. Therefore, clients should, once a new client ID is period. Therefore, clients should, once a new client ID is
established, refetch the lease_time attribute and use it as the basis established, refetch the lease_time attribute and use it as the basis
for lease renewal for the lease associated with that server. for lease renewal for the lease associated with that server.
However, the server must establish, for this restart event, a grace However, the server must establish, for this restart event, a grace
skipping to change at page 146, line 45 skipping to change at page 146, line 45
leases will not be renewed, the server MAY extend the period for leases will not be renewed, the server MAY extend the period for
delegation recovery beyond the typical lease expiration period. For delegation recovery beyond the typical lease expiration period. For
open delegations, such delegations that are not released are open delegations, such delegations that are not released are
reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (See reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (See
Section 10.5 and Section 15.18 for discussion of open delegation and Section 10.5 and Section 15.18 for discussion of open delegation and
the details of OPEN respectively). the details of OPEN respectively).
A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it
does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM and does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM and
instead MUST make them available for client reclaim using instead MUST make them available for client reclaim using
CLAIM_DELEGATE_PREV. The server MAY NOT remove the delegations until CLAIM_DELEGATE_PREV. The server MUST NOT remove the delegations
either the client does a DELEGPURGE, or one lease period has elapsed until either the client does a DELEGPURGE, or one lease period has
from the time the later of the SETCLIENTID_CONFIRM or the last elapsed from the time the later of the SETCLIENTID_CONFIRM or the
successful CLAIM_DELEGATE_PREV reclaim. last successful CLAIM_DELEGATE_PREV reclaim.
Note that the requirement stated above is not meant to imply that Note that the requirement stated above is not meant to imply that
when the client is no longer obliged, as required above, to retain when the client is no longer obliged, as required above, to retain
delegation information, that it should necessarily dispose of it. delegation information, that it should necessarily dispose of it.
Some specific cases are: Some specific cases are:
o When the period is terminated by the occurrence of DELEGPURGE, o When the period is terminated by the occurrence of DELEGPURGE,
deletion of unreclaimed delegations is appropriate and desirable. deletion of unreclaimed delegations is appropriate and desirable.
skipping to change at page 175, line 48 skipping to change at page 175, line 48
protocol, and how they address issues related to protocol, and how they address issues related to
internationalization, including issues related to UTF-8, internationalization, including issues related to UTF-8,
normalization, string preparation, case folding, and handling of normalization, string preparation, case folding, and handling of
internationalization issues related to domains. internationalization issues related to domains.
The NFSv4 protocol needs to deal with internationalization, or I18N, The NFSv4 protocol needs to deal with internationalization, or I18N,
with respect to file names and other strings as used within the with respect to file names and other strings as used within the
protocol. The choice of string representation must allow for protocol. The choice of string representation must allow for
reasonable name/string access to clients, applications, and users reasonable name/string access to clients, applications, and users
which use various languages. The UTF-8 encoding of the UCS as which use various languages. The UTF-8 encoding of the UCS as
defined by [8] allows for this type of access and follows the policy defined by [ISO.10646-1.1993] allows for this type of access and
described in "IETF Policy on Character Sets and Languages", [9]. follows the policy described in "IETF Policy on Character Sets and
Languages", [RFC2277].
In implementing such policies, it is important to understand and In implementing such policies, it is important to understand and
respect the nature of NFSv4 as a means by which client respect the nature of NFSv4 as a means by which client
implementations may invoke operations on remote file systems. Server implementations may invoke operations on remote file systems. Server
implementations act as a conduit to a range of file system implementations act as a conduit to a range of file system
implementations that the NFSv4 server typically invokes through a implementations that the NFSv4 server typically invokes through a
virtual-file-system interface. virtual-file-system interface.
Keeping this context in mind, one needs to understand that the file Keeping this context in mind, one needs to understand that the file
systems with which clients will be interacting will generally not be systems with which clients will be interacting will generally not be
skipping to change at page 176, line 45 skipping to change at page 176, line 47
12.1. Use of UTF-8 12.1. Use of UTF-8
As mentioned above, UTF-8 is used as a convenient way to encode As mentioned above, UTF-8 is used as a convenient way to encode
Unicode which allows clients that have no internationalization Unicode which allows clients that have no internationalization
requirements to avoid these issues since the mapping of ASCII names requirements to avoid these issues since the mapping of ASCII names
to UTF-8 is the identity. to UTF-8 is the identity.
12.1.1. Relation to Stringprep 12.1.1. Relation to Stringprep
RFC 3454 [10], otherwise known as "stringprep", documents a framework RFC 3454 [RFC3454], otherwise known as "stringprep", documents a
for using Unicode/UTF-8 in networking protocols, intended "to framework for using Unicode/UTF-8 in networking protocols, intended
increase the likelihood that string input and string comparison work "to increase the likelihood that string input and string comparison
in ways that make sense for typical users throughout the world." A work in ways that make sense for typical users throughout the world."
protocol conforming to this framework must define a profile of A protocol conforming to this framework must define a profile of
stringprep "in order to fully specify the processing options." stringprep "in order to fully specify the processing options."
NFSv4, while it does make normative references to stringprep and uses NFSv4, while it does make normative references to stringprep and uses
elements of that framework, it does not, for reasons that are elements of that framework, it does not, for reasons that are
explained below, conform to that framework, for all of the strings explained below, conform to that framework, for all of the strings
that are used within it. that are used within it.
In addition to some specific issues which have caused stringprep to In addition to some specific issues which have caused stringprep to
add confusion in handling certain characters for certain languages, add confusion in handling certain characters for certain languages,
there are a number of general reasons why stringprep profiles are not there are a number of general reasons why stringprep profiles are not
suitable for describing NFSv4. suitable for describing NFSv4.
skipping to change at page 179, line 11 skipping to change at page 179, line 11
equivalence classes defined by the chosen equivalence relation. equivalence classes defined by the chosen equivalence relation.
In the NFSv4 protocol, handling of issues related to In the NFSv4 protocol, handling of issues related to
internationalization with regard to normalization follows one of two internationalization with regard to normalization follows one of two
basic patterns: basic patterns:
o For strings whose function is related to other internet standards, o For strings whose function is related to other internet standards,
such as server and domain naming, the normalization form defined such as server and domain naming, the normalization form defined
by the appropriate internet standards is used. For server and by the appropriate internet standards is used. For server and
domain naming, this involves normalization form NFKC as specified domain naming, this involves normalization form NFKC as specified
in [3] in [I-D.draft-ietf-idna]
o For other strings, particular those passed by the server to file o For other strings, particular those passed by the server to file
system implementations, normalization requirements are the system implementations, normalization requirements are the
province of the file system and the job of this specification is province of the file system and the job of this specification is
not to specify a particular form but to make sure that not to specify a particular form but to make sure that
interoperability is maximized, even when clients and server-based interoperability is maximized, even when clients and server-based
file systems have different preferences. file systems have different preferences.
A related but distinct issue concerns string confusability. This can A related but distinct issue concerns string confusability. This can
occur when two strings (including single-character strings) having a occur when two strings (including single-character strings) having a
similar appearance. There have been attempts to define uniform similar appearance. There have been attempts to define uniform
processing in an attempt to avoid such confusion (see stringprep processing in an attempt to avoid such confusion (see stringprep
[10]) but the results have often added confusion. [RFC3454]) but the results have often added confusion.
Some examples of possible confusions and proposed processing intended Some examples of possible confusions and proposed processing intended
to reduce/avoid confusions: to reduce/avoid confusions:
o Deletion of characters believed to be invisible and appropriately o Deletion of characters believed to be invisible and appropriately
ignored, justifying their deletion, including, WORD JOINER ignored, justifying their deletion, including, WORD JOINER
(U+2060), and the ZERO WIDTH SPACE (U+200B). (U+2060), and the ZERO WIDTH SPACE (U+200B).
o Deletion of characters supposed to not bear semantics and only o Deletion of characters supposed to not bear semantics and only
affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C) affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C)
skipping to change at page 180, line 9 skipping to change at page 180, line 9
(U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK (U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK
SMALL LETTER RHO (U+1D56, for good measure). SMALL LETTER RHO (U+1D56, for good measure).
NFSv4, as it does with normalization, takes a two-part approach to NFSv4, as it does with normalization, takes a two-part approach to
this issue: this issue:
o For strings whose function is related to other internet standards, o For strings whose function is related to other internet standards,
such as server and domain naming, any string processing to address such as server and domain naming, any string processing to address
the confusability issue is defined by the appropriate internet the confusability issue is defined by the appropriate internet
standards is used. For server and domain naming, this is the standards is used. For server and domain naming, this is the
responsibility of IDNA as described in [3]. responsibility of IDNA as described in [I-D.draft-ietf-idna].
o For other strings, particularly those passed by the server to file o For other strings, particularly those passed by the server to file
system implementations, any such preparation requirements system implementations, any such preparation requirements
including the choice of how, or whether to address the including the choice of how, or whether to address the
confusability issue, are the responsibility of the file system to confusability issue, are the responsibility of the file system to
define, and for this specification to try to add its own set would define, and for this specification to try to add its own set would
add unacceptably to complexity, and make many files accessible add unacceptably to complexity, and make many files accessible
locally and by other remote file access protocols, inaccessible by locally and by other remote file access protocols, inaccessible by
NFSv4. This specification defines how the protocol maximizes NFSv4. This specification defines how the protocol maximizes
interoperability in the face of different file system interoperability in the face of different file system
skipping to change at page 183, line 27 skipping to change at page 183, line 27
Table 6 Table 6
The last table describes the components of the compound types The last table describes the components of the compound types
described above. described above.
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
| Type | Class | Def | Explanation | | Type | Class | Def | Explanation |
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
| svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or | | svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or |
| | | | IPv6. | | | | | IPv6. |
| svrname4 | UVMUST | INET | Server name as returned by server. | | svrname4 | UVMUST | INET | Server name as returned by server. Not |
| | | | Not sent by client, except in | | | | | sent by client, except in |
| | | | VERIFY/NVERIFY. | | | | | VERIFY/NVERIFY. |
| prinsfx4 | UVMUST | INET | Suffix part of principal, in the form | | prinsfx4 | UVMUST | INET | Suffix part of principal, in the form |
| | | | of a domain name. | | | | | of a domain name. |
| prinpfx4 | UVMUST | NFS | Must match one of a list of valid | | prinpfx4 | UVMUST | NFS | Must match one of a list of valid |
| | | | users or groups for that particular | | | | | users or groups for that particular |
| | | | domain. | | | | | domain. |
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
Table 7 Table 7
skipping to change at page 209, line 16 skipping to change at page 209, line 16
A locking request was attempted which would require the upgrade or A locking request was attempted which would require the upgrade or
downgrade of a lock range already held by the owner when the server downgrade of a lock range already held by the owner when the server
does not support atomic upgrade or downgrade of locks. does not support atomic upgrade or downgrade of locks.
13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) 13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028)
A lock request is operating on a range that overlaps in part a A lock request is operating on a range that overlaps in part a
currently held lock for the current lock owner and does not precisely currently held lock for the current lock owner and does not precisely
match a single such lock where the server does not support this type match a single such lock where the server does not support this type
of request, and thus does not implement POSIX locking semantics [35]. of request, and thus does not implement POSIX locking semantics
See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a [fcntl]. See Section 15.12.5, Section 15.13.5, and Section 15.14.5
discussion of how this applies to LOCK, LOCKT, and LOCKU for a discussion of how this applies to LOCK, LOCKT, and LOCKU
respectively. respectively.
13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) 13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038)
The client attempted a READ, WRITE, LOCK or other operation not The client attempted a READ, WRITE, LOCK or other operation not
sanctioned by the stateid passed (e.g., writing to a file opened only sanctioned by the stateid passed (e.g., writing to a file opened only
for read). for read).
13.1.9. Reclaim Errors 13.1.9. Reclaim Errors
skipping to change at page 234, line 47 skipping to change at page 234, line 47
verifier at each server event or instantiation that may lead to a verifier at each server event or instantiation that may lead to a
loss of uncommitted data. Most commonly this occurs when the server loss of uncommitted data. Most commonly this occurs when the server
is rebooted; however, other events at the server may result in is rebooted; however, other events at the server may result in
uncommitted data loss as well. uncommitted data loss as well.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.5.5. IMPLEMENTATION 15.5.5. IMPLEMENTATION
The COMMIT operation is similar in operation and semantics to the The COMMIT operation is similar in operation and semantics to the
POSIX fsync() [36] system call that synchronizes a file's state with POSIX fsync() [fsync] system call that synchronizes a file's state
the disk (file data and metadata is flushed to disk or stable with the disk (file data and metadata is flushed to disk or stable
storage). COMMIT performs the same operation for a client, flushing storage). COMMIT performs the same operation for a client, flushing
any unsynchronized data and metadata on the server to the server's any unsynchronized data and metadata on the server to the server's
disk or stable storage for the specified file. Like fsync(), it may disk or stable storage for the specified file. Like fsync(), it may
be that there is some modified data or no modified data to be that there is some modified data or no modified data to
synchronize. The data may have been synchronized by the server's synchronize. The data may have been synchronized by the server's
normal periodic buffer synchronization activity. COMMIT should normal periodic buffer synchronization activity. COMMIT should
return NFS4_OK, unless there has been an unexpected error. return NFS4_OK, unless there has been an unexpected error.
COMMIT differs from fsync() in that it is possible for the client to COMMIT differs from fsync() in that it is possible for the client to
flush a range of the file (most likely triggered by a buffer- flush a range of the file (most likely triggered by a buffer-
skipping to change at page 238, line 19 skipping to change at page 238, line 19
from the principal indicated in the RPC credentials of the call, but from the principal indicated in the RPC credentials of the call, but
the server's operating environment or filesystem semantics may the server's operating environment or filesystem semantics may
dictate other methods of derivation. Similarly, if createattrs dictate other methods of derivation. Similarly, if createattrs
includes neither the group attribute nor a group ACE, and if the includes neither the group attribute nor a group ACE, and if the
server's filesystem both supports and requires the notion of a group server's filesystem both supports and requires the notion of a group
attribute (or group ACE), the server MUST derive the group attribute attribute (or group ACE), the server MUST derive the group attribute
(or the corresponding owner ACE) for the file. This could be from (or the corresponding owner ACE) for the file. This could be from
the RPC call's credentials, such as the group principal if the the RPC call's credentials, such as the group principal if the
credentials include it (such as with AUTH_SYS), from the group credentials include it (such as with AUTH_SYS), from the group
identifier associated with the principal in the credentials (e.g., identifier associated with the principal in the credentials (e.g.,
POSIX systems have a user database [37] that has the group identifier POSIX systems have a user database [getpwnam] that has the group
for every user identifier), inherited from directory the object is identifier for every user identifier), inherited from directory the
created in, or whatever else the server's operating environment or object is created in, or whatever else the server's operating
filesystem semantics dictate. This applies to the OPEN operation environment or filesystem semantics dictate. This applies to the
too. OPEN operation too.
Conversely, it is possible the client will specify in createattrs an Conversely, it is possible the client will specify in createattrs an
owner attribute or group attribute or ACL that the principal owner attribute or group attribute or ACL that the principal
indicated the RPC call's credentials does not have permissions to indicated the RPC call's credentials does not have permissions to
create files for. The error to be returned in this instance is create files for. The error to be returned in this instance is
NFS4ERR_PERM. This applies to the OPEN operation too. NFS4ERR_PERM. This applies to the OPEN operation too.
15.6.5. IMPLEMENTATION 15.6.5. IMPLEMENTATION
If the client desires to set attribute values after the create, a If the client desires to set attribute values after the create, a
skipping to change at page 252, line 27 skipping to change at page 252, line 27
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.14.5. IMPLEMENTATION 15.14.5. IMPLEMENTATION
If the area to be unlocked does not correspond exactly to a lock If the area to be unlocked does not correspond exactly to a lock
actually held by the lock-owner the server may return the error actually held by the lock-owner the server may return the error
NFS4ERR_LOCK_RANGE. This includes the case in which the area is not NFS4ERR_LOCK_RANGE. This includes the case in which the area is not
locked, where the area is a sub-range of the area locked, where it locked, where the area is a sub-range of the area locked, where it
overlaps the area locked without matching exactly or the area overlaps the area locked without matching exactly or the area
specified includes multiple locks held by the lock-owner. In all of specified includes multiple locks held by the lock-owner. In all of
these cases, allowed by POSIX locking [35] semantics, a client these cases, allowed by POSIX locking [fcntl] semantics, a client
receiving this error, should if it desires support for such receiving this error, should if it desires support for such
operations, simulate the operation using LOCKU on ranges operations, simulate the operation using LOCKU on ranges
corresponding to locks it actually holds, possibly followed by LOCK corresponding to locks it actually holds, possibly followed by LOCK
requests for the sub-ranges not being unlocked. requests for the sub-ranges not being unlocked.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKU requests will similarly be handled locally. case, LOCKU requests will similarly be handled locally.
15.15. Operation 15: LOOKUP - Lookup Filename 15.15. Operation 15: LOOKUP - Lookup Filename
skipping to change at page 263, line 18 skipping to change at page 263, line 18
reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed.
In this case, delegation will always be granted, although the server In this case, delegation will always be granted, although the server
may specify an immediate recall in the delegation structure. may specify an immediate recall in the delegation structure.
The rflags returned by a successful OPEN allow the server to return The rflags returned by a successful OPEN allow the server to return
information governing how the open file is to be handled. information governing how the open file is to be handled.
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
OPEN_CONFIRM operation before using the open file. OPEN_CONFIRM operation before using the open file.
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of Posix locking techniques [35]. behavior supports the complete set of Posix locking techniques
From this the client can choose to manage file locking state in a way [fcntl]. From this the client can choose to manage file locking
to handle a mis-match of file locking management. state in a way to handle a mis-match of file locking management.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.3 for further discussion. and name checks. See Section 12.3 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
share and deny status together with the existing status. In this share and deny status together with the existing status. In this
case, only a single CLOSE need be done, even though multiple OPENs case, only a single CLOSE need be done, even though multiple OPENs
were completed. When such an OPEN is done, checking of share were completed. When such an OPEN is done, checking of share
skipping to change at page 264, line 12 skipping to change at page 264, line 12
does not have authorization to create files for, then the server may does not have authorization to create files for, then the server may
return NFS4ERR_PERM. return NFS4ERR_PERM.
In the case of a OPEN which specifies a size of zero (e.g., In the case of a OPEN which specifies a size of zero (e.g.,
truncation) and the file has named attributes, the named attributes truncation) and the file has named attributes, the named attributes
are left as is. They are not removed. are left as is. They are not removed.
15.18.6. IMPLEMENTATION 15.18.6. IMPLEMENTATION
The OPEN operation contains support for EXCLUSIVE4 create. The The OPEN operation contains support for EXCLUSIVE4 create. The
mechanism is similar to the support in NFSv3 [14]. As in NFSv3, this mechanism is similar to the support in NFSv3 [RFC1813]. As in NFSv3,
mechanism provides reliable exclusive creation. Exclusive create is this mechanism provides reliable exclusive creation. Exclusive
invoked when the how parameter is EXCLUSIVE4. In this case, the create is invoked when the how parameter is EXCLUSIVE4. In this
client provides a verifier that can reasonably be expected to be case, the client provides a verifier that can reasonably be expected
unique. A combination of a client identifier, perhaps the client to be unique. A combination of a client identifier, perhaps the
network address, and a unique number generated by the client, perhaps client network address, and a unique number generated by the client,
the RPC transaction identifier, may be appropriate. perhaps the RPC transaction identifier, may be appropriate.
If the object does not exist, the server creates the object and If the object does not exist, the server creates the object and
stores the verifier in stable storage. For filesystems that do not stores the verifier in stable storage. For filesystems that do not
provide a mechanism for the storage of arbitrary file attributes, the provide a mechanism for the storage of arbitrary file attributes, the
server may use one or more elements of the object meta-data to store server may use one or more elements of the object meta-data to store
the verifier. The verifier must be stored in stable storage to the verifier. The verifier must be stored in stable storage to
prevent erroneous failure on retransmission of the request. It is prevent erroneous failure on retransmission of the request. It is
assumed that an exclusive create is being performed because exclusive assumed that an exclusive create is being performed because exclusive
semantics are critical to the application. Because of the expected semantics are critical to the application. Because of the expected
usage, exclusive CREATE does not rely solely on the normally volatile usage, exclusive CREATE does not rely solely on the normally volatile
skipping to change at page 266, line 10 skipping to change at page 266, line 10
and for special files of other types; NFS4ERR_INVAL would be and for special files of other types; NFS4ERR_INVAL would be
inappropriate, since the arguments provided by the client were inappropriate, since the arguments provided by the client were
correct, and the client cannot necessarily know at the time it sent correct, and the client cannot necessarily know at the time it sent
the OPEN that the component would resolve to a non-regular file. the OPEN that the component would resolve to a non-regular file.
If the current filehandle is not a directory, the error If the current filehandle is not a directory, the error
NFS4ERR_NOTDIR will be returned. NFS4ERR_NOTDIR will be returned.
If a COMPOUND contains an OPEN which establishes a If a COMPOUND contains an OPEN which establishes a
OPEN_DELEGATE_WRITE delegation, then a subsequent GETATTR inside that OPEN_DELEGATE_WRITE delegation, then a subsequent GETATTR inside that
COMPOUND SHOULD not result in a CB_GETATTR to the client. The server COMPOUND SHOULD NOT result in a CB_GETATTR to the client. The server
SHOULD understand the GETATTR to be for the same client ID and avoid SHOULD understand the GETATTR to be for the same client ID and avoid
querying the client, which will not be able to respond. This querying the client, which will not be able to respond. This
sequence of OPEN, GETATTR SHOULD be understood as an atomic retrieval sequence of OPEN, GETATTR SHOULD be understood as an atomic retrieval
of the initial size and change attribute. Further, the client SHOULD of the initial size and change attribute. Further, the client SHOULD
NOT construct a COMPOUND which mixes operations for different client NOT construct a COMPOUND which mixes operations for different client
IDs. IDs.
15.19. Operation 19: OPENATTR - Open Named Attribute Directory 15.19. Operation 19: OPENATTR - Open Named Attribute Directory
15.19.1. SYNOPSIS 15.19.1. SYNOPSIS
skipping to change at page 271, line 45 skipping to change at page 271, line 45
nfsstat4 status; nfsstat4 status;
}; };
15.23.4. DESCRIPTION 15.23.4. DESCRIPTION
Replaces the current filehandle with the filehandle that represents Replaces the current filehandle with the filehandle that represents
the public filehandle of the server's name space. This filehandle the public filehandle of the server's name space. This filehandle
may be different from the "root" filehandle which may be associated may be different from the "root" filehandle which may be associated
with some other directory on the server. with some other directory on the server.
The public filehandle represents the concepts embodied in [23], [24], The public filehandle represents the concepts embodied in [RFC2054],
[38]. The intent for NFSv4 is that the public filehandle [RFC2055], [RFC2224]. The intent for NFSv4 is that the public
(represented by the PUTPUBFH operation) be used as a method of filehandle (represented by the PUTPUBFH operation) be used as a
providing WebNFS server compatibility with NFSv2 and NFSv3. method of providing WebNFS server compatibility with NFSv2 and NFSv3.
The public filehandle and the root filehandle (represented by the The public filehandle and the root filehandle (represented by the
PUTROOTFH operation) should be equivalent. If the public and root PUTROOTFH operation) should be equivalent. If the public and root
filehandles are not equivalent, then the public filehandle MUST be a filehandles are not equivalent, then the public filehandle MUST be a
descendant of the root filehandle. descendant of the root filehandle.
15.23.5. IMPLEMENTATION 15.23.5. IMPLEMENTATION
Used as the first operator in an NFS request to set the context for Used as the first operator in an NFS request to set the context for
following operations. following operations.
With the NFSv2 and 3 public filehandle, the client is able to specify With the NFSv2 and 3 public filehandle, the client is able to specify
whether the path name provided in the LOOKUP should be evaluated as whether the path name provided in the LOOKUP should be evaluated as
either an absolute path relative to the server's root or relative to either an absolute path relative to the server's root or relative to
the public filehandle. [38] contains further discussion of the the public filehandle. [RFC2224] contains further discussion of the
functionality. With NFSv4, that type of specification is not functionality. With NFSv4, that type of specification is not
directly available in the LOOKUP operation. The reason for this is directly available in the LOOKUP operation. The reason for this is
because the component separators needed to specify absolute vs. because the component separators needed to specify absolute vs.
relative are not allowed in NFSv4. Therefore, the client is relative are not allowed in NFSv4. Therefore, the client is
responsible for constructing its request such that the use of either responsible for constructing its request such that the use of either
PUTROOTFH or PUTPUBFH are used to signify absolute or relative PUTROOTFH or PUTPUBFH are used to signify absolute or relative
evaluation of an NFS URL respectively. evaluation of an NFS URL respectively.
Note that there are warnings mentioned in [38] with respect to the Note that there are warnings mentioned in [RFC2224] with respect to
use of absolute evaluation and the restrictions the server may place the use of absolute evaluation and the restrictions the server may
on that evaluation with respect to how much of its namespace has been place on that evaluation with respect to how much of its namespace
made available. These same warnings apply to NFSv4. It is likely, has been made available. These same warnings apply to NFSv4. It is
therefore that because of server implementation details, an NFSv3 likely, therefore that because of server implementation details, an
absolute public filehandle lookup may behave differently than an NFSv3 absolute public filehandle lookup may behave differently than
NFSv4 absolute resolution. an NFSv4 absolute resolution.
There is a form of security negotiation as described in [39] that There is a form of security negotiation as described in [RFC2755]
uses the public filehandle a method of employing SNEGO. This method that uses the public filehandle a method of employing SNEGO. This
is not available with NFSv4 as filehandles are not overloaded with method is not available with NFSv4 as filehandles are not overloaded
special meaning and therefore do not provide the same framework as with special meaning and therefore do not provide the same framework
NFSv2 and NFSv3. Clients should therefore use the security as NFSv2 and NFSv3. Clients should therefore use the security
negotiation mechanisms described in this RFC. negotiation mechanisms described in this RFC.
15.24. Operation 24: PUTROOTFH - Set Root Filehandle 15.24. Operation 24: PUTROOTFH - Set Root Filehandle
15.24.1. SYNOPSIS 15.24.1. SYNOPSIS
- -> (cfh) - -> (cfh)
15.24.2. ARGUMENT 15.24.2. ARGUMENT
skipping to change at page 281, line 42 skipping to change at page 281, line 42
target is also subject to the normal UTF-8, character support, and target is also subject to the normal UTF-8, character support, and
name checks. See Section 12.3 for further discussion. name checks. See Section 12.3 for further discussion.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [40] in POSIX) to remove a directory, as system call (e.g., unlink() [unlink] in POSIX) to remove a directory,
well as the converse (e.g., a rmdir() on a non-directory) because as well as the converse (e.g., a rmdir() on a non-directory) because
they knew the server would check the file type. NFSv4 REMOVE can be they knew the server would check the file type. NFSv4 REMOVE can be
used to delete any directory entry independent of its file type. The used to delete any directory entry independent of its file type. The
implementor of an NFSv4 client's entry points from the unlink() and implementor of an NFSv4 client's entry points from the unlink() and
rmdir() system calls should first check the file type against the rmdir() system calls should first check the file type against the
types the system call is allowed to remove before issuing a REMOVE. types the system call is allowed to remove before issuing a REMOVE.
Alternatively, the implementor can produce a COMPOUND call that Alternatively, the implementor can produce a COMPOUND call that
includes a LOOKUP/VERIFY sequence to verify the file type before a includes a LOOKUP/VERIFY sequence to verify the file type before a
REMOVE operation in the same COMPOUND call. REMOVE operation in the same COMPOUND call.
The concept of last reference is server specific. However, if the The concept of last reference is server specific. However, if the
skipping to change at page 289, line 7 skipping to change at page 289, line 7
not have the appropriate access to LOOKUP the name then SECINFO must not have the appropriate access to LOOKUP the name then SECINFO must
behave the same way and return NFS4ERR_ACCESS. behave the same way and return NFS4ERR_ACCESS.
The result will contain an array which represents the security The result will contain an array which represents the security
mechanisms available, with an order corresponding to server's mechanisms available, with an order corresponding to server's
preferences, the most preferred being first in the array. The client preferences, the most preferred being first in the array. The client
is free to pick whatever security mechanism it both desires and is free to pick whatever security mechanism it both desires and
supports, or to pick in the server's preference order the first one supports, or to pick in the server's preference order the first one
it supports. The array entries are represented by the secinfo4 it supports. The array entries are represented by the secinfo4
structure. The field 'flavor' will contain a value of AUTH_NONE, structure. The field 'flavor' will contain a value of AUTH_NONE,
AUTH_SYS (as defined in [4]), or RPCSEC_GSS (as defined in [5]). AUTH_SYS (as defined in [RFC5531]), or RPCSEC_GSS (as defined in
[RFC2203]).
For the flavors AUTH_NONE and AUTH_SYS, no additional security For the flavors AUTH_NONE and AUTH_SYS, no additional security
information is returned. For a return value of RPCSEC_GSS, a information is returned. For a return value of RPCSEC_GSS, a
security triple is returned that contains the mechanism object id (as security triple is returned that contains the mechanism object id (as
defined in [6]), the quality of protection (as defined in [6]) and defined in [RFC2743]), the quality of protection (as defined in
the service type (as defined in [5]). It is possible for SECINFO to [RFC2743]) and the service type (as defined in [RFC2203]). It is
return multiple entries with flavor equal to RPCSEC_GSS with possible for SECINFO to return multiple entries with flavor equal to
different security triple values. RPCSEC_GSS with different security triple values.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
If the name has a length of 0 (zero), or if name does not obey the If the name has a length of 0 (zero), or if name does not obey the
UTF-8 definition, the error NFS4ERR_INVAL will be returned. UTF-8 definition, the error NFS4ERR_INVAL will be returned.
15.33.5. IMPLEMENTATION 15.33.5. IMPLEMENTATION
The SECINFO operation is expected to be used by the NFS client when The SECINFO operation is expected to be used by the NFS client when
the error value of NFS4ERR_WRONGSEC is returned from another NFS the error value of NFS4ERR_WRONGSEC is returned from another NFS
skipping to change at page 314, line 11 skipping to change at page 314, line 11
on an NFS server. Consideration should also be given to the on an NFS server. Consideration should also be given to the
integrity and privacy of NFS requests and responses. The issues of integrity and privacy of NFS requests and responses. The issues of
end to end mutual authentication, integrity, and privacy are end to end mutual authentication, integrity, and privacy are
discussed as part of Section 3. discussed as part of Section 3.
When an NFSv4 mandated security model is used and a security When an NFSv4 mandated security model is used and a security
principal or an NFSv4 name in user@dns_domain form needs to be principal or an NFSv4 name in user@dns_domain form needs to be
translated to or from a local representation as described in translated to or from a local representation as described in
Section 5.9, the translation SHOULD be done in a secure manner that Section 5.9, the translation SHOULD be done in a secure manner that
preserves the integrity of the translation. For communication with a preserves the integrity of the translation. For communication with a
name service such as LDAP ([41]), this means employing a security name service such as LDAP ([RFC4511]), this means employing a
service that uses authentication and data integrity. Kerberos and security service that uses authentication and data integrity.
TLS ([42]) are examples of such a security service. Kerberos and TLS ([RFC5246]) are examples of such a security service.
Note that being REQUIRED to implement does not mean REQUIRED to use; Note that being REQUIRED to implement does not mean REQUIRED to use;
AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS
is merely an OPTIONAL security flavor in NFSv4, and so is merely an OPTIONAL security flavor in NFSv4, and so
interoperability via AUTH_SYS is not assured. interoperability via AUTH_SYS is not assured.
For reasons of reduced administration overhead, better performance For reasons of reduced administration overhead, better performance
and/or reduction of CPU utilization, users of NFSv4 implementations and/or reduction of CPU utilization, users of NFSv4 implementations
may choose to not use security mechanisms that enable integrity may choose to not use security mechanisms that enable integrity
protection on each remote procedure call and response. The use of protection on each remote procedure call and response. The use of
skipping to change at page 315, line 10 skipping to change at page 315, line 10
server controlled by the attacker. server controlled by the attacker.
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and match the principal used for these operations is checked against and match
the previous use of these operations. See Section 9.1.1 for further the previous use of these operations. See Section 9.1.1 for further
discussion. discussion.
18. IANA Considerations 18. IANA Considerations
This section uses terms that are defined in [43]. This section uses terms that are defined in [RFC5226].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA will create a registry called the "NFSv4 Named Attribute IANA will create a registry called the "NFSv4 Named Attribute
Definitions Registry". Definitions Registry".
The NFSv4 protocol supports the association of a file with zero or The NFSv4 protocol supports the association of a file with zero or
more named attributes. The name space identifiers for these more named attributes. The name space identifiers for these
attributes are defined as string names. The protocol does not define attributes are defined as string names. The protocol does not define
the specific assignment of the name space for these file attributes. the specific assignment of the name space for these file attributes.
skipping to change at page 315, line 33 skipping to change at page 315, line 33
attributes as needed, they are encouraged to register the attributes attributes as needed, they are encouraged to register the attributes
with IANA. with IANA.
Such registered named attributes are presumed to apply to all minor Such registered named attributes are presumed to apply to all minor
versions of NFSv4, including those defined subsequently to the versions of NFSv4, including those defined subsequently to the
registration. Where the named attribute is intended to be limited registration. Where the named attribute is intended to be limited
with regard to the minor versions for which they are not be used, the with regard to the minor versions for which they are not be used, the
assignment in registry will clearly state the applicable limits. assignment in registry will clearly state the applicable limits.
All assignments to the registry are made on a First Come First Served All assignments to the registry are made on a First Come First Served
basis, per section 4.1 of [43]. The policy for each assignment is basis, per section 4.1 of [RFC5226]. The policy for each assignment
Specification Required, per section 4.1 of [43]. is Specification Required, per section 4.1 of [RFC5226].
Under the NFSv4 specification, the name of a named attribute can in Under the NFSv4 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
clients and servers will be unable to a handle string that long. clients and servers will be unable to a handle string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up exceeds 128 UTF-8 characters. To give IESG the flexibility to set up
bases of assignment of Experimental Use and Standards Action, the bases of assignment of Experimental Use and Standards Action, the
prefixes of "EXPE" and "STDS" are Reserved. The zero length named prefixes of "EXPE" and "STDS" are Reserved. The zero length named
attribute name is Reserved. attribute name is Reserved.
skipping to change at page 316, line 37 skipping to change at page 316, line 37
18.1.2. Updating Registrations 18.1.2. Updating Registrations
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
Approval. Approval.
19. References 19. References
19.1. Normative References 19.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [I-D.draft-ietf-idna]
Levels", March 1997. Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol",
draft-ietf-idnabis-protocol-18 (work in progress),
January 2010.
[2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", [I-D.ietf-nfsv4-rfc3530bis-dot-x]
draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR
Feb 2011. Description", draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work
in progress), Feb 2011.
[3] Klensin, J., "Internationalized Domain Names in Applications [ISO.10646-1.1993]
(IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in International Organization for Standardization,
progress), January 2010. "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993.
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Version 2", RFC 5531, May 2009. Requirement Levels", March 1997.
[5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[6] Linn, J., "Generic Security Service Application Program [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Interface Version 2, Update 1", RFC 2743, January 2000. Languages", BCP 18, RFC 2277, January 1998.
[7] Eisler, M., Ed., "IANA Considerations for Remote Procedure Call [RFC2743] Linn, J., "Generic Security Service Application Program
(RPC) Network Identifiers and Universal Address Formats", Interface Version 2, Update 1", RFC 2743, January 2000.
RFC 5665, January 2010.
[8] International Organization for Standardization, "Information [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Technology - Universal Multiple-octet coded Character Set (UCS) Internationalized Strings ("stringprep")", RFC 3454,
- Part 1: Architecture and Basic Multilingual Plane", December 2002.
ISO Standard 10646-1, May 1993.
[9] Alvestrand, H., "IETF Policy on Character Sets and Languages", [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
BCP 18, RFC 2277, January 1998. Specification Version 2", RFC 5531, May 2009.
[10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure
Strings ("stringprep")", RFC 3454, December 2002. Call (RPC) Network Identifiers and Universal Address
Formats", RFC 5665, January 2010.
19.2. Informative References 19.2. Informative References
[11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [Chet] Juszczak, C., "Improving the Performance and Correctness
C., Eisler, M., and D. Noveck, "Network File System (NFS) of an NFS Server", USENIX Conference Proceedings ,
version 4 Protocol", RFC 3530, April 2003. June 1990.
[12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of
C., Eisler, M., and D. Noveck, "Network File System (NFS) Periodic Routing Messages", IEEE/ACM Transactions on
version 4 Protocol", RFC 3010, December 2000. Networking 2(2), pp. 122-136, April 1994.
[13] Nowicki, B., "NFS: Network File System Protocol specification", [ISEG_errata]
RFC 1094, March 1989. IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008.
[14] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Protocol Specification", RFC 1813, June 1995. RFC 793, September 1981.
[15] Eisler, M., "XDR: External Data Representation Standard", [RFC1094] Nowicki, B., "NFS: Network File System Protocol
RFC 4506, May 2006. specification", RFC 1094, March 1989.
[16] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
5 Generic Security Service Application Program Interface (GSS- RFC 1345, June 1992.
API) Mechanism: Version 2", RFC 4121, July 2005.
[17] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
line Database", RFC 3232, January 2002. Version 3 Protocol Specification", RFC 1813, June 1995.
[18] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, August 1995.
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054,
Control Protocol (DCCP)", RFC 4340, March 2006. October 1996.
[20] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
"Negative-acknowledgment (NACK)-Oriented Reliable Multicast October 1996.
(NORM) Protocol", RFC 3940, November 2004.
[21] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
Routing Messages", IEEE/ACM Transactions on Networking 2(2),
pp. 122-136, April 1994.
[22] Eisler, M., "NFS Version 2 and Version 3 Security Issues and [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999. RFC 2623, June 1999.
[23] Callaghan, B., "WebNFS Client Specification", RFC 2054, [RFC2624] Shepler, S., "NFS Version 4 Design Considerations",
October 1996. RFC 2624, June 1999.
[24] Callaghan, B., "WebNFS Server Specification", RFC 2055, [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security
October 1996. Negotiation for WebNFS", RFC 2755, January 2000.
[25] IESG, "IESG Processing of RFC Errata for the IETF Stream", [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
July 2008. Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3010, December 2000.
[26] The Open Group, "Section 'read()' of System Interfaces of The [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 an On-line Database", RFC 3232, January 2002.
Edition", 2004.
[27] The Open Group, "Section 'readdir()' of System Interfaces of [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
The Open Group Base Specifications Issue 6, IEEE Std 1003.1, Beame, C., Eisler, M., and D. Noveck, "Network File System
2004 Edition", 2004. (NFS) version 4 Protocol", RFC 3530, April 2003.
[28] The Open Group, "Section 'write()' of System Interfaces of The [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker,
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 "Negative-acknowledgment (NACK)-Oriented Reliable
Edition", 2004. Multicast (NORM) Protocol", RFC 3940, November 2004.
[29] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
June 1999. Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[30] Simonsen, K., "Character Mnemonics and Character Sets", [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
RFC 1345, June 1992. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[31] Shepler, S., Eisler, M., and D. Noveck, "Network File System [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, RFC 4506, May 2006.
January 2010.
[32] The Open Group, "Protocols for Interworking: XNFS, Version 3W, [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
ISBN 1-85912-184-5", February 1998. (LDAP): The Protocol", RFC 4511, June 2006.
[33] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
September 1981. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[34] Juszczak, C., "Improving the Performance and Correctness of an [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
NFS Server", USENIX Conference Proceedings , June 1990. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[35] The Open Group, "Section 'fcntl()' of System Interfaces of The [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 System (NFS) Version 4 Minor Version 1 Protocol",
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", RFC 5661, January 2010.
2004.
[36] The Open Group, "Section 'fsync()' of System Interfaces of The [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 The Open Group Base Specifications Issue 6 IEEE Std
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 1003.1, 2004 Edition, HTML Version (www.opengroup.org),
2004. ISBN 1931624232", 2004.
[37] The Open Group, "Section 'getpwnam()' of System Interfaces of [fsync] The Open Group, "Section 'fsync()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1, The Open Group Base Specifications Issue 6 IEEE Std
2004 Edition, HTML Version (www.opengroup.org), ISBN 1003.1, 2004 Edition, HTML Version (www.opengroup.org),
1931624232", 2004. ISBN 1931624232", 2004.
[38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [getpwnam]
The Open Group, "Section 'getpwnam()' of System Interfaces
of The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org),
ISBN 1931624232", 2004.
[39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation [read_api]
for WebNFS", RFC 2755, January 2000. The Open Group, "Section 'read()' of System Interfaces of
The Open Group Base Specifications Issue 6, IEEE Std
1003.1, 2004 Edition", 2004.
[40] The Open Group, "Section 'unlink()' of System Interfaces of The [readdir_api]
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 The Open Group, "Section 'readdir()' of System Interfaces
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", of The Open Group Base Specifications Issue 6, IEEE Std
2004. 1003.1, 2004 Edition", 2004.
[41] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): [unlink] The Open Group, "Section 'unlink()' of System Interfaces
The Protocol", RFC 4511, June 2006. of The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org),
ISBN 1931624232", 2004.
[42] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [write_api]
Protocol Version 1.2", RFC 5246, August 2008. The Open Group, "Section 'write()' of System Interfaces of
The Open Group Base Specifications Issue 6, IEEE Std
1003.1, 2004 Edition", 2004.
[43] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [xnfs] The Open Group, "Protocols for Interworking: XNFS, Version
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3W, ISBN 1-85912-184-5", February 1998.
Appendix A. Acknowledgments Appendix A. Acknowledgments
A bis is certainly built on the shoulders of the first attempt. A bis is certainly built on the shoulders of the first attempt.
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
Carl Beame, Mike Eisler, and David Noveck are responsible for a great Carl Beame, Mike Eisler, and David Noveck are responsible for a great
deal of the effort in this work. deal of the effort in this work.
Rob Thurlow clarified how a client should contact a new server if a Rob Thurlow clarified how a client should contact a new server if a
migration has occurred. migration has occurred.
skipping to change at page 320, line 29 skipping to change at page 320, line 40
James Lentini graciously read the rewrite of Section 7 and his James Lentini graciously read the rewrite of Section 7 and his
comments were vital in improving the quality of that effort. comments were vital in improving the quality of that effort.
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond
Myklebust were faithful attendants of the biweekly triage meeting and Myklebust were faithful attendants of the biweekly triage meeting and
accepted many an action item. accepted many an action item.
Bruce Fields was a good sounding board for both the Third Edge Bruce Fields was a good sounding board for both the Third Edge
Condition and Courtesy Locks in general. He was also the leading Condition and Courtesy Locks in general. He was also the leading
advocate of stamping out backport issues from [31]. advocate of stamping out backport issues from [RFC5661].
Marcel Telka was a champion of straightening out the difference Marcel Telka was a champion of straightening out the difference
between a lock-owner and an open-owner. He has also been diligent in between a lock-owner and an open-owner. He has also been diligent in
reviewing the final document. reviewing the final document.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
 End of changes. 111 change blocks. 
316 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/