draft-ietf-nfsv4-minorversion1-27.txt   draft-ietf-nfsv4-minorversion1-28.txt 
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: June 6, 2009 Editors Expires: June 7, 2009 Editors
December 03, 2008 December 04, 2008
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-27.txt draft-ietf-nfsv4-minorversion1-28.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 6, 2009. This Internet-Draft will expire on June 7, 2009.
Abstract Abstract
This document describes NFS version 4 minor version one, including This document describes NFS version 4 minor version one, including
features retained from the base protocol (NFS version 4 minor version features retained from the base protocol (NFS version 4 minor version
zero which is specified in RFC3530) and protocol extensions made zero which is specified in RFC3530) and protocol extensions made
subsequently. Major extensions introduced in NFS version 4 minor subsequently. Major extensions introduced in NFS version 4 minor
version one include: Sessions, Directory Delegations, and parallel version one include: Sessions, Directory Delegations, and parallel
NFS (pNFS). NFS version 4 minor version one has no dependencies on NFS (pNFS). NFS version 4 minor version one has no dependencies on
NFS version 4 minor version zero, and is considered a separate NFS version 4 minor version zero, and is considered a separate
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 18 1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 18
1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 19 1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 19
2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 20 2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 20
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20
2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 20 2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 20 2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 20
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 23 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 23
2.4. Client Identifiers and Client Owners . . . . . . . . . . 24 2.4. Client Identifiers and Client Owners . . . . . . . . . . 24
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 28 2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 28
2.4.2. Server Release of Client ID . . . . . . . . . . . . 28 2.4.2. Server Release of Client ID . . . . . . . . . . . . 28
2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 28 2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 29
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 30 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 30
2.6. Security Service Negotiation . . . . . . . . . . . . . . 30 2.6. Security Service Negotiation . . . . . . . . . . . . . . 30
2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 31 2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 31
2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 31 2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 31
2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 31 2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 31
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 36 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 36
2.8. Non-RPC-based Security Services . . . . . . . . . . . . 38 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 38
2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 38 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 38
2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38
2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 39 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 39
skipping to change at page 7, line 35 skipping to change at page 7, line 35
13.9. Metadata and Data Server State Coordination . . . . . . 323 13.9. Metadata and Data Server State Coordination . . . . . . 323
13.9.1. Global Stateid Requirements . . . . . . . . . . . . 323 13.9.1. Global Stateid Requirements . . . . . . . . . . . . 323
13.9.2. Data Server State Propagation . . . . . . . . . . . 324 13.9.2. Data Server State Propagation . . . . . . . . . . . 324
13.10. Data Server Component File Size . . . . . . . . . . . . 326 13.10. Data Server Component File Size . . . . . . . . . . . . 326
13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 327 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 327
13.12. Security Considerations for the File Layout Type . . . . 327 13.12. Security Considerations for the File Layout Type . . . . 327
14. Internationalization . . . . . . . . . . . . . . . . . . . . 328 14. Internationalization . . . . . . . . . . . . . . . . . . . . 328
14.1. Stringprep profile for the utf8str_cs type . . . . . . . 329 14.1. Stringprep profile for the utf8str_cs type . . . . . . . 329
14.2. Stringprep profile for the utf8str_cis type . . . . . . 331 14.2. Stringprep profile for the utf8str_cis type . . . . . . 331
14.3. Stringprep profile for the utf8str_mixed type . . . . . 332 14.3. Stringprep profile for the utf8str_mixed type . . . . . 332
14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 334 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 333
14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 334 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 334
15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 335 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 334
15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 335 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 335
15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 337 15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 337
15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 339 15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 339
15.1.3. Compound Structure Errors . . . . . . . . . . . . . 340 15.1.3. Compound Structure Errors . . . . . . . . . . . . . 340
15.1.4. File System Errors . . . . . . . . . . . . . . . . . 342 15.1.4. File System Errors . . . . . . . . . . . . . . . . . 342
15.1.5. State Management Errors . . . . . . . . . . . . . . 344 15.1.5. State Management Errors . . . . . . . . . . . . . . 344
15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 345 15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 344
15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 345 15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 345
15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 346 15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 346
15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 347 15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 347
15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 348 15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 348
15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 349 15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 349
15.1.12. Session Management Errors . . . . . . . . . . . . . 351 15.1.12. Session Management Errors . . . . . . . . . . . . . 350
15.1.13. Client Management Errors . . . . . . . . . . . . . . 351 15.1.13. Client Management Errors . . . . . . . . . . . . . . 351
15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 352 15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 352
15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 352 15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 352
15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 353 15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 353
15.2. Operations and their valid errors . . . . . . . . . . . 354 15.2. Operations and their valid errors . . . . . . . . . . . 354
15.3. Callback operations and their valid errors . . . . . . . 370 15.3. Callback operations and their valid errors . . . . . . . 370
15.4. Errors and the operations that use them . . . . . . . . 372 15.4. Errors and the operations that use them . . . . . . . . 372
16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 387 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 387
16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 387 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 387
16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 388 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 388
skipping to change at page 10, line 36 skipping to change at page 10, line 36
22.4.2. Updating Registrations . . . . . . . . . . . . . . . 597 22.4.2. Updating Registrations . . . . . . . . . . . . . . . 597
22.4.3. Guidelines for Writing Layout Type Specifications . 597 22.4.3. Guidelines for Writing Layout Type Specifications . 597
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 599 22.5. Path Variable Definitions . . . . . . . . . . . . . . . 599
22.5.1. Path Variables Registry . . . . . . . . . . . . . . 599 22.5.1. Path Variables Registry . . . . . . . . . . . . . . 599
22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 601 22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 601
22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 601 22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 601
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 602 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 602
23.1. Normative References . . . . . . . . . . . . . . . . . . 602 23.1. Normative References . . . . . . . . . . . . . . . . . . 602
23.2. Informative References . . . . . . . . . . . . . . . . . 605 23.2. Informative References . . . . . . . . . . . . . . . . . 605
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 606 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 606
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 608 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 609
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 609 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 609
Intellectual Property and Copyright Statements . . . . . . . . . 610 Intellectual Property and Copyright Statements . . . . . . . . . 611
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 1 Protocol 1.1. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0 is described in [30]. It generally follows the version, NFSv4.0 is described in [29]. It generally follows the
guidelines for minor versioning model listed in Section 10 of RFC guidelines for minor versioning model listed in Section 10 of RFC
3530. However, it diverges from guidelines 11 ("a client and server 3530. However, it diverges from guidelines 11 ("a client and server
that supports minor version X must support minor versions 0 through that supports minor version X must support minor versions 0 through
X-1"), and 12 ("no features may be introduced as mandatory in a minor X-1"), and 12 ("no features may be introduced as mandatory in a minor
version"). These divergences are due to the introduction of the version"). These divergences are due to the introduction of the
sessions model for managing non-idempotent operations and the sessions model for managing non-idempotent operations and the
RECLAIM_COMPLETE operation. These two new features are RECLAIM_COMPLETE operation. These two new features are
infrastructural in nature and simplify implementation of existing and infrastructural in nature and simplify implementation of existing and
other new features. Making them anything but REQUIRED would add other new features. Making them anything but REQUIRED would add
undue complexity to protocol definition and implementation. NFSv4.1 undue complexity to protocol definition and implementation. NFSv4.1
skipping to change at page 11, line 45 skipping to change at page 11, line 45
o describe the NFSv4.0 protocol, except where needed to contrast o describe the NFSv4.0 protocol, except where needed to contrast
with NFSv4.1. with NFSv4.1.
o modify the specification of the NFSv4.0 protocol. o modify the specification of the NFSv4.0 protocol.
o clarify the NFSv4.0 protocol. o clarify the NFSv4.0 protocol.
1.3. NFSv4 Goals 1.3. NFSv4 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 NFSv3 [31]. It retains the essential characteristics of already by NFSv3 [30]. It retains the essential characteristics of
previous versions: easy recovery; independence of transport previous versions: easy recovery; independence of transport
protocols, operating systems and file systems; simplicity; and good protocols, operating systems and file systems; simplicity; and good
performance. NFSv4 has the following goals: performance. NFSv4 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.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
1.6.1. RPC and Security 1.6.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.1 (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4.1
protocol are those defined in [2] and [3]. To meet end-to-end protocol are those defined in [2] and [3]. To meet end-to-end
security requirements, the RPCSEC_GSS framework [4] is used to extend security requirements, the RPCSEC_GSS framework [4] is used to extend
the basic RPC security. With the use of RPCSEC_GSS, various the basic RPC security. With the use of RPCSEC_GSS, various
mechanisms can be provided to offer authentication, integrity, and mechanisms can be provided to offer authentication, integrity, and
privacy to the NFSv4 protocol. Kerberos V5 is used as described in privacy to the NFSv4 protocol. Kerberos V5 is used as described in
[5] to provide one security framework. The LIPKEY and SPKM-3 GSS-API [5] to provide one security framework. With the use of RPCSEC_GSS,
mechanisms described in [6] are used to provide for the use of user other mechanisms may also be specified and used for NFSv4.1 security.
password and client/server public key certificates by the NFSv4
protocol. With the use of RPCSEC_GSS, other mechanisms may also be
specified and used for NFSv4.1 security.
To enable in-band security negotiation, the NFSv4.1 protocol has To enable in-band security negotiation, the NFSv4.1 protocol has
operations which provide the client a method of querying the server operations which provide the client a method of querying the server
about its policies regarding which security mechanisms must be used about its policies regarding which security mechanisms must be used
for access to the server's file system resources. With this, the for access to the server's file system 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.
NFSv4.1 introduces parallel access (see Section 1.6.2.2), which is
called pNFS. The security framework described in this section is
significantly modified by the introduction of pNFS (see
Section 12.9), because data access is sometimes not over RPC. The
level of significance varies with the Storage Protocol (see
Section 12.2.5) and can be as low as zero impact (see Section 13.12).
1.6.2. Protocol Structure 1.6.2. Protocol Structure
1.6.2.1. Core Protocol 1.6.2.1. Core Protocol
Unlike NFSv3, which used a series of ancillary protocols (e.g. NLM, Unlike NFSv3, which used a series of ancillary protocols (e.g. NLM,
NSM, MOUNT), within all minor versions of NFSv4 a single RPC protocol NSM, MOUNT), within all minor versions of NFSv4 a single RPC protocol
is used to make requests to the server. Facilities that had been is used to make requests to the server. Facilities that had been
separate protocols, such as locking, are now integrated within a separate protocols, such as locking, are now integrated within a
single unified protocol. single unified protocol.
skipping to change at page 16, line 28 skipping to change at page 16, line 31
clustered server implementation by enabling a separation of metadata clustered server implementation by enabling a separation of metadata
access and data access, with the latter done to multiple servers in access and data access, with the latter done to multiple servers in
parallel. parallel.
Such parallel data access is controlled by recallable objects known Such parallel data access is controlled by recallable objects known
as "layouts", which are integrated into the protocol locking model. as "layouts", which are integrated into the protocol locking model.
Clients direct requests for data access to a set of data servers Clients direct requests for data access to a set of data servers
specified by the layout via a data storage protocol which may be specified by the layout via a data storage protocol which may be
NFSv4.1 or may be another protocol. NFSv4.1 or may be another protocol.
Because the protocols used for parallel data access are not
necessarily RPC-based, the RPC-based security model (Section 1.6.1)
is obviously impacted (see Section 12.9). The degree of impact
varies with the Storage Protocol (see Section 12.2.5) used for data
access, and can be as low as zero (see Section 13.12).
1.6.3. File System Model 1.6.3. File System Model
The general file system model used for the NFSv4.1 protocol is the The general file system model used for the NFSv4.1 protocol is the
same as previous versions. The server file system is hierarchical same as previous versions. The server file system is hierarchical
with the regular files contained within being treated as opaque byte with the regular files contained within being treated as opaque byte
streams. In a slight departure, file and directory names are encoded streams. In a slight departure, file and directory names are encoded
with UTF-8 to deal with the basics of internationalization. with UTF-8 to deal with the basics of internationalization.
The NFSv4.1 protocol does not require a separate protocol to provide The NFSv4.1 protocol does not require a separate protocol to provide
for the initial mapping between path name and filehandle. All file for the initial mapping between path name and filehandle. All file
skipping to change at page 17, line 17 skipping to change at page 17, line 27
filehandles. filehandles.
1.6.3.2. File Attributes 1.6.3.2. File Attributes
The NFSv4.1 protocol has a rich and extensible file object attribute The NFSv4.1 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 the definition of the fattr3 data type in attributes of NFSv3 (see the definition of the fattr3 data type in
[31]). An example of a REQUIRED attribute is the file object's type [30]). An example of a REQUIRED attribute is the file object's type
(Section 5.8.1.2) so that regular files can be distinguished from (Section 5.8.1.2) so that regular files can be distinguished from
directories (also known as folders in some operating environments) directories (also known as folders in some operating environments)
and other types of objects. REQUIRED attributes are discussed in and other types of objects. REQUIRED attributes are discussed in
Section 5.1. Section 5.1.
An example of three RECOMMENDED attributes are acl, sacl, and dacl. An example of three RECOMMENDED attributes are acl, sacl, and dacl.
These attributes define an Access Control List (ACL) on a file object These attributes define an Access Control List (ACL) on a file object
((Section 6). An ACL provides directory and file access control (Section 6). An ACL provides directory and file access control
beyond the model used in NFSv3. The ACL definition allows for beyond the model used in NFSv3. The ACL definition allows for
specification of specific sets of permissions for individual users specification of specific sets of permissions for individual users
and groups. In addition, ACL inheritance allows propagation of and groups. In addition, ACL inheritance allows propagation of
access permissions and restriction down a directory tree as file access permissions and restriction down a directory tree as file
system objects are created. RECOMMENDED attributes are discussed in system objects are created. RECOMMENDED attributes are discussed in
Section 5.2. Section 5.2.
A named attribute is an opaque byte stream that is associated with a A named attribute is an opaque byte stream that is associated with a
directory or file and referred to by a string name. Named attributes directory or file and referred to by a string name. Named attributes
are meant to be used by client applications as a method to associate are meant to be used by client applications as a method to associate
skipping to change at page 19, line 45 skipping to change at page 20, line 6
* A method to allow a server to indicate it is recalling one or * A method to allow a server to indicate it is recalling one or
more delegations for resource management reasons, and thus a more delegations for resource management reasons, and thus a
method to allow the client to pick which delegations to return method to allow the client to pick which delegations to return
(Section 20.6). (Section 20.6).
o Attributes can be set atomically during exclusive file create via o Attributes can be set atomically during exclusive file create via
the OPEN operation (see the new EXCLUSIVE4_1 creation method in the OPEN operation (see the new EXCLUSIVE4_1 creation method in
Section 18.16). Section 18.16).
o Open files can be preserved if removed and the hard link count o Open files can be preserved if removed and the hard link count
("hard link" is defined in an Open Group [7] standard) goes to ("hard link" is defined in an Open Group [6] standard) goes to
zero thus obviating the need for clients to rename deleted files zero thus obviating the need for clients to rename deleted files
to partially hidden names -- colloquially called "silly rename" to partially hidden names -- colloquially called "silly rename"
(see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in (see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in
Section 18.16). Section 18.16).
o Improved compatibility with Microsoft Windows for Access Control o Improved compatibility with Microsoft Windows for Access Control
Lists (Section 6.2.3, Section 6.2.2, Section 6.4.3.2). Lists (Section 6.2.3, Section 6.2.2, Section 6.4.3.2).
o Data retention (Section 5.13). o Data retention (Section 5.13).
o Identification of the implementation of the NFS client and server o Identification of the implementation of the NFS client and server
(Section 18.35). (Section 18.35).
o Support for notification of the availability of byte-range locks o Support for notification of the availability of byte-range locks
(see the new OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in (see the new OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in
Section 18.16 and see Section 20.11). Section 18.16 and see Section 20.11).
o In NFSv4.1, LIPKEY and SPKM-3 are not required security mechanisms
[31].
2. Core Infrastructure 2. Core Infrastructure
2.1. Introduction 2.1. Introduction
NFSv4.1 relies on core infrastructure common to nearly every NFSv4.1 relies on core infrastructure common to nearly every
operation. This core infrastructure is described in the remainder of operation. This core infrastructure is described in the remainder of
this section. this section.
2.2. RPC and XDR 2.2. RPC and XDR
skipping to change at page 21, line 9 skipping to change at page 21, line 22
Every RPC header conveys information used to identify and Every RPC header conveys information used to identify and
authenticate a client and server. As discussed in Section 2.2.1.1.1, authenticate a client and server. As discussed in Section 2.2.1.1.1,
some security flavors provide additional security services. some security flavors provide additional security services.
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This
requirement to implement is not a requirement to use.) Other requirement to implement is not a requirement to use.) Other
flavors, such as AUTH_NONE, and AUTH_SYS, MAY be implemented as well. flavors, such as AUTH_NONE, and AUTH_SYS, MAY be implemented as well.
2.2.1.1.1. RPCSEC_GSS and Security Services 2.2.1.1.1. RPCSEC_GSS and Security Services
RPCSEC_GSS ([4]) uses the functionality of GSS-API [8]. This allows RPCSEC_GSS ([4]) uses the functionality of GSS-API [7]. This allows
for the use of various security mechanisms by the RPC layer without for the use of various security mechanisms by the RPC layer without
the additional implementation overhead of adding RPC security the additional implementation overhead of adding RPC security
flavors. flavors.
2.2.1.1.1.1. Identification, Authentication, Integrity, Privacy 2.2.1.1.1.1. Identification, Authentication, Integrity, Privacy
Via the GSS-API, RPCSEC_GSS can be used to identify and authenticate Via the GSS-API, RPCSEC_GSS can be used to identify and authenticate
users on clients to servers, and servers to users. It can also users on clients to servers, and servers to users. It can also
perform integrity checking on the entire RPC message, including the perform integrity checking on the entire RPC message, including the
RPC header, and the arguments or results. Finally, privacy, usually RPC header, and the arguments or results. Finally, privacy, usually
skipping to change at page 21, line 44 skipping to change at page 22, line 9
NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and
authentication service. NFSv4.1 servers MUST support RPCSEC_GSS's authentication service. NFSv4.1 servers MUST support RPCSEC_GSS's
privacy service. NFSv4.1 clients SHOULD support RPCSEC_GSS's privacy privacy service. NFSv4.1 clients SHOULD support RPCSEC_GSS's privacy
service. service.
2.2.1.1.1.2. Security mechanisms for NFSv4.1 2.2.1.1.1.2. Security mechanisms for NFSv4.1
RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide
security services. Therefore NFSv4.1 clients and servers MUST security services. Therefore NFSv4.1 clients and servers MUST
support three security mechanisms: Kerberos V5, SPKM-3, and LIPKEY. support the Kerberos V5 security mechanism.
The use of RPCSEC_GSS requires selection of: mechanism, quality of The use of RPCSEC_GSS requires selection of: mechanism, quality of
protection (QOP), and service (authentication, integrity, privacy). protection (QOP), and service (authentication, integrity, privacy).
For the mandated security mechanisms, NFSv4.1 specifies that a QOP of For the mandated security mechanisms, NFSv4.1 specifies that a QOP of
zero (0) is used, leaving it up to the mechanism or the mechanism's zero (0) is used, leaving it up to the mechanism or the mechanism's
configuration to map QOP zero to an appropriate level of protection. configuration to map QOP zero to an appropriate level of protection.
Each mandated mechanism specifies minimum set of cryptographic Each mandated mechanism specifies minimum set of cryptographic
algorithms for implementing integrity and privacy. NFSv4.1 clients algorithms for implementing integrity and privacy. NFSv4.1 clients
and servers MUST be implemented on operating environments that comply and servers MUST be implemented on operating environments that comply
with the REQUIRED cryptographic algorithms of each REQUIRED with the REQUIRED cryptographic algorithms of each REQUIRED
skipping to change at page 22, line 36 skipping to change at page 22, line 49
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes 390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the number and name of the pseudo flavor is presented here Note that the number and name of the pseudo flavor is presented here
as a mapping aid to the implementor. Because the NFSv4.1 protocol as a mapping aid to the implementor. Because the NFSv4.1 protocol
includes a method to negotiate security and it understands the GSS- includes a method to negotiate security and it understands the GSS-
API mechanism, the pseudo flavor is not needed. The pseudo flavor is API mechanism, the pseudo flavor is not needed. The pseudo flavor is
needed for the NFSv3 since the security negotiation is done via the needed for the NFSv3 since the security negotiation is done via the
MOUNT protocol as described in [32]. MOUNT protocol as described in [32].
2.2.1.1.1.2.2. LIPKEY At the time NFSv4.1 was specified, AES with HMAC-SHA1 was a REQUIRED
algorithm set for Kerberos V5. In contrast, when NFSv4.0 was
The LIPKEY V5 GSS-API mechanism as described in [6] MUST be specified, weaker algorithm sets were REQUIRED for Kerberos V5, and
implemented with the RPCSEC_GSS services as specified in the were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
following table: specification at the time did not specify stronger algorithms. The
NFSv4.1 specification does not specify REQUIRED algorithms for
1 2 3 4 5 6 Kerberos V5, and instead, the implementor is expected to track the
------------------------------------------------------------------ evolution of the Kerberos V5 standard if and when stronger algorithms
390006 lipkey 1.3.6.1.5.5.9 rpc_gss_svc_none yes yes are specified.
390007 lipkey-i 1.3.6.1.5.5.9 rpc_gss_svc_integrity yes yes
390008 lipkey-p 1.3.6.1.5.5.9 rpc_gss_svc_privacy no yes
2.2.1.1.1.2.3. SPKM-3 as a security triple
The SPKM-3 GSS-API mechanism as described in [6] MUST be implemented 2.2.1.1.1.2.1.1. Security Considerations for Cryptographic Algorithms
with the RPCSEC_GSS services as specified in the following table: in Kerberos V5
1 2 3 4 5 6 When deploying NFSv4.1, the strength of the security achieved depends
------------------------------------------------------------------ on the existing Kerberos V5 infrastructure. The algorithms of
390009 spkm3 1.3.6.1.5.5.1.3 rpc_gss_svc_none yes yes Kerberos V5 are not directly exposed to or selectable by the client
390010 spkm3i 1.3.6.1.5.5.1.3 rpc_gss_svc_integrity yes yes or server, so there is some due diligence required by the user of
390011 spkm3p 1.3.6.1.5.5.1.3 rpc_gss_svc_privacy no yes NFSv4.1 to ensure that security is acceptable where where needed.
2.2.1.1.1.3. GSS Server Principal 2.2.1.1.1.3. GSS Server Principal
Regardless of what security mechanism under RPCSEC_GSS is being used, Regardless of what security mechanism under RPCSEC_GSS is being used,
the NFS server, MUST identify itself in GSS-API via a the NFS server, MUST identify itself in GSS-API via a
GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE
names are of the form: names are of the form:
service@hostname service@hostname
For NFS, the "service" element is For NFS, the "service" element is
nfs nfs
Implementations of security mechanisms will convert nfs@hostname to Implementations of security mechanisms will convert nfs@hostname to
various different forms. For Kerberos V5, LIPKEY, and SPKM-3, the various different forms. For Kerberos V5 the following form is
following form is RECOMMENDED: RECOMMENDED:
nfs/hostname nfs/hostname
2.3. COMPOUND and CB_COMPOUND 2.3. COMPOUND and CB_COMPOUND
A significant departure from the versions of the NFS protocol before A significant departure from the versions of the NFS protocol before
NFSv4 is the introduction of the COMPOUND procedure. For the NFSv4 NFSv4 is the introduction of the COMPOUND procedure. For the NFSv4
protocol, in all minor versions, there are exactly two RPC protocol, in all minor versions, there are exactly two RPC
procedures, NULL and COMPOUND. The COMPOUND procedure is defined as procedures, NULL and COMPOUND. The COMPOUND procedure is defined as
a series of individual operations and these operations perform the a series of individual operations and these operations perform the
skipping to change at page 26, line 12 skipping to change at page 26, line 17
same string. The implementor is cautioned from an approach that same string. The implementor is cautioned from an approach that
requires the string to be recorded in a local file because this requires the string to be recorded in a local file because this
precludes the use of the implementation in an environment where precludes the use of the implementation in an environment where
there is no local disk and all file access is from an NFSv4.1 there is no local disk and all file access is from an NFSv4.1
server. server.
o The string should be the same for each server network address that o The string should be the same for each server network address that
the client accesses. This way, if a server has multiple the client accesses. This way, if a server has multiple
interfaces, the client can trunk traffic over multiple network interfaces, the client can trunk traffic over multiple network
paths as described in Section 2.10.5. (Note: the precise opposite paths as described in Section 2.10.5. (Note: the precise opposite
was advised in the NFSv4.0 specification [30].) was advised in the NFSv4.0 specification [29].)
o The algorithm for generating the string should not assume that the o The algorithm for generating the string should not assume that the
client's network address will not change, unless the client client's network address will not change, unless the client
implementation knows it is using statically assigned network implementation knows it is using statically assigned network
addresses. This includes changes between client incarnations and addresses. This includes changes between client incarnations and
even changes while the client is still running in its current even changes while the client is still running in its current
incarnation. Thus with dynamic address assignment, if the client incarnation. Thus with dynamic address assignment, if the client
includes just the client's network address in the co_ownerid includes just the client's network address in the co_ownerid
string, there is a real risk that after the client gives up the string, there is a real risk that after the client gives up the
network address, another client, using a similar algorithm for network address, another client, using a similar algorithm for
skipping to change at page 28, line 15 skipping to change at page 28, line 19
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 2.4.1. Upgrade from NFSv4.0 to NFSv4.1
To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a
client_owner4 in an EXCHANGE_ID with an nfs_client_id4 established client_owner4 in an EXCHANGE_ID with an nfs_client_id4 established
using the SETCLIENTID operation of NFSv4.0. A server that does so using the SETCLIENTID operation of NFSv4.0. A server that does so
will allow an upgraded client to avoid waiting until the lease (i.e. will allow an upgraded client to avoid waiting until the lease (i.e.
the lease established by the NFSv4.0 instance client) expires. This the lease established by the NFSv4.0 instance client) expires. This
requires the client_owner4 be constructed the same way as the requires the client_owner4 be constructed the same way as the
nfs_client_id4. If the latter's contents included the server's nfs_client_id4. If the latter's contents included the server's
network address (per the recommendations of the NFSv4.0 specification network address (per the recommendations of the NFSv4.0 specification
[30]), and the NFSv4.1 client does not wish to use a client ID that [29]), and the NFSv4.1 client does not wish to use a client ID that
prevents trunking, it should send two EXCHANGE_ID operations. The prevents trunking, it should send two EXCHANGE_ID operations. The
first EXCHANGE_ID will have a client_owner4 equal to the first EXCHANGE_ID will have a client_owner4 equal to the
nfs_client_id4. This will clear the state created by the NFSv4.0 nfs_client_id4. This will clear the state created by the NFSv4.0
client. The second EXCHANGE_ID will not have the server's network client. The second EXCHANGE_ID will not have the server's network
address. The state created for the second EXCHANGE_ID will not have address. The state created for the second EXCHANGE_ID will not have
to wait for lease expiration, because there will be no state to to wait for lease expiration, because there will be no state to
expire. expire.
2.4.2. Server Release of Client ID 2.4.2. Server Release of Client ID
skipping to change at page 31, line 36 skipping to change at page 31, line 38
read-only vs. read-write) access, security tuples that allow greater read-only vs. read-write) access, security tuples that allow greater
access should be presented first. Where the general level of access access should be presented first. Where the general level of access
is the same and different security flavors limit the range of is the same and different security flavors limit the range of
principals whose privileges are recognized (e.g. allowing or principals whose privileges are recognized (e.g. allowing or
disallowing root access), flavors supporting the greatest range of disallowing root access), flavors supporting the greatest range of
principals should be listed first. principals should be listed first.
2.6.3. Security Error 2.6.3. Security Error
Based on the assumption that each NFSv4.1 client and server must Based on the assumption that each NFSv4.1 client and server must
support a minimum set of security (i.e., LIPKEY, SPKM-3, and support a minimum set of security (i.e., Kerberos V5 under
Kerberos-V5 all under RPCSEC_GSS), the NFS client will initiate file RPCSEC_GSS), the NFS client will initiate file access to the server
access to the server with one of the minimal security tuples. During with one of the minimal security tuples. During communication with
communication with the server, the client may receive an NFS error of the server, the client may receive an NFS error of NFS4ERR_WRONGSEC.
NFS4ERR_WRONGSEC. This error allows the server to notify the client This error allows the server to notify the client that the security
that the security tuple currently being used contravenes the server's tuple currently being used contravenes the server's security policy.
security policy. The client is then responsible for determining (see The client is then responsible for determining (see Section 2.6.3.1)
Section 2.6.3.1) what security tuples are available at the server and what security tuples are available at the server and choosing one
choosing one which is appropriate for the client. which is appropriate for the client.
2.6.3.1. Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME 2.6.3.1. Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME
This section explains of the mechanics of NFSv4.1 security This section explains of the mechanics of NFSv4.1 security
negotiation. negotiation.
2.6.3.1.1. Put Filehandle Operations 2.6.3.1.1. Put Filehandle Operations
The term "put filehandle operation" refers to PUTROOTFH, PUTPUBFH, The term "put filehandle operation" refers to PUTROOTFH, PUTPUBFH,
PUTFH, and RESTOREFH. Each of the subsections herein describes how PUTFH, and RESTOREFH. Each of the subsections herein describes how
skipping to change at page 36, line 14 skipping to change at page 36, line 14
2.7. Minor Versioning 2.7. Minor Versioning
To address the requirement of an NFS protocol that can evolve as the To address the requirement of an NFS protocol that can evolve as the
need arises, the NFSv4.1 protocol contains the rules and framework to need arises, the NFSv4.1 protocol contains the rules and framework to
allow for future minor changes or versioning. allow for future minor changes or versioning.
The base assumption with respect to minor versioning is that any The base assumption with respect to minor versioning is that any
future accepted minor version will be documented in one or more future accepted minor version will be documented in one or more
standards track RFCs. Minor version zero of the NFSv4 protocol is standards track RFCs. Minor version zero of the NFSv4 protocol is
represented by [30], and minor version one is represented by this represented by [29], and minor version one is represented by this
document [[Comment.1: RFC Editor: change "document" to "RFC" when we document [[Comment.1: RFC Editor: change "document" to "RFC" when we
publish]]. The COMPOUND and CB_COMPOUND procedures support the publish]]. The COMPOUND and CB_COMPOUND procedures support the
encoding of the minor version being requested by the client. encoding of the minor version being requested by the client.
The following items represent the basic rules for the development of The following items represent the basic rules for the development of
minor versions. Note that a future minor version may modify or add minor versions. Note that a future minor version may modify or add
to the following rules as part of the minor version definition. to the following rules as part of the minor version definition.
1. Procedures are not added or deleted 1. Procedures are not added or deleted
skipping to change at page 59, line 31 skipping to change at page 59, line 31
requester does not know what sequence ID to use for the slot on its requester does not know what sequence ID to use for the slot on its
next request. For example, suppose a requester sends a request with next request. For example, suppose a requester sends a request with
sequence ID 1, and does not wait for the response. The next time it sequence ID 1, and does not wait for the response. The next time it
uses the slot, it sends the new request with sequence ID 2. If the uses the slot, it sends the new request with sequence ID 2. If the
replier has not seen the request with sequence ID 1, then the replier replier has not seen the request with sequence ID 1, then the replier
is not expecting sequence ID 2, and rejects the requester's new is not expecting sequence ID 2, and rejects the requester's new
request with NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or request with NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or
CB_SEQUENCE). CB_SEQUENCE).
RDMA fabrics do not guarantee that the memory handles (Steering Tags) RDMA fabrics do not guarantee that the memory handles (Steering Tags)
within each RPC/RDMA "chunk" ([9]) are valid on a scope outside that within each RPC/RDMA "chunk" ([8]) are valid on a scope outside that
of a single connection. Therefore, handles used by the direct of a single connection. Therefore, handles used by the direct
operations become invalid after connection loss. The server must operations become invalid after connection loss. The server must
ensure that any RDMA operations which must be replayed from the reply ensure that any RDMA operations which must be replayed from the reply
cache use the newly provided handle(s) from the most recent request. cache use the newly provided handle(s) from the most recent request.
A retry might be sent while the original request is still in progress A retry might be sent while the original request is still in progress
on the replier. The replier SHOULD deal with the issue by returning on the replier. The replier SHOULD deal with the issue by returning
NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but
implementations MAY return NFS4ERR_MISORDERED. Since errors from implementations MAY return NFS4ERR_MISORDERED. Since errors from
SEQUENCE and CB_SEQUENCE are never recorded in the reply cache, this SEQUENCE and CB_SEQUENCE are never recorded in the reply cache, this
skipping to change at page 64, line 27 skipping to change at page 64, line 27
the NFSv4.1 server. the NFSv4.1 server.
While the description of the implementation for atomic execution of While the description of the implementation for atomic execution of
the request and caching of the reply is beyond the scope of this the request and caching of the reply is beyond the scope of this
document, an example implementation for NFSv2 [37] is described in document, an example implementation for NFSv2 [37] is described in
[38]. [38].
2.10.7. RDMA Considerations 2.10.7. RDMA Considerations
A complete discussion of the operation of RPC-based protocols over A complete discussion of the operation of RPC-based protocols over
RDMA transports is in [9]. A discussion of the operation of NFSv4, RDMA transports is in [8]. A discussion of the operation of NFSv4,
including NFSv4.1, over RDMA is in [10]. Where RDMA is considered, including NFSv4.1, over RDMA is in [9]. Where RDMA is considered,
this specification assumes the use of such a layering; it addresses this specification assumes the use of such a layering; it addresses
only the upper layer issues relevant to making best use of RPC/RDMA. only the upper layer issues relevant to making best use of RPC/RDMA.
2.10.7.1. RDMA Connection Resources 2.10.7.1. RDMA Connection Resources
RDMA requires its consumers to register memory and post buffers of a RDMA requires its consumers to register memory and post buffers of a
specific size and number for receive operations. specific size and number for receive operations.
Registration of memory can be a relatively high-overhead operation, Registration of memory can be a relatively high-overhead operation,
since it requires pinning of buffers, assignment of attributes (e.g. since it requires pinning of buffers, assignment of attributes (e.g.
skipping to change at page 65, line 28 skipping to change at page 65, line 28
flow control and will terminate a connection in error when limits are flow control and will terminate a connection in error when limits are
exceeded. Limits such as maximum number of requests outstanding are exceeded. Limits such as maximum number of requests outstanding are
therefore negotiated when a session is created (see the therefore negotiated when a session is created (see the
ca_maxrequests field in Section 18.36). These limits then provide ca_maxrequests field in Section 18.36). These limits then provide
the maxima which each connection associated with the session's the maxima which each connection associated with the session's
channel(s) must remain within. RDMA connections are managed within channel(s) must remain within. RDMA connections are managed within
these limits as described in section 3.3 ("Flow Control"[[Comment.2: these limits as described in section 3.3 ("Flow Control"[[Comment.2:
RFC Editor: please verify section and title of the RPCRDMA document RFC Editor: please verify section and title of the RPCRDMA document
which is currently at which is currently at
http://tools.ietf.org/html/draft-ietf-nfsv4-rpcrdma-08#section-3.3]]) http://tools.ietf.org/html/draft-ietf-nfsv4-rpcrdma-08#section-3.3]])
of [9]; if there are multiple RDMA connections, then the maximum of [8]; if there are multiple RDMA connections, then the maximum
number of requests for a channel will be divided among the RDMA number of requests for a channel will be divided among the RDMA
connections. Put a different way, the onus is on the replier to connections. Put a different way, the onus is on the replier to
ensure that total number of RDMA credits across all connections ensure that total number of RDMA credits across all connections
associated with the replier's channel does exceed the channel's associated with the replier's channel does exceed the channel's
maximum number of outstanding requests. maximum number of outstanding requests.
The limits may also be modified dynamically at the replier's choosing The limits may also be modified dynamically at the replier's choosing
by manipulating certain parameters present in each NFSv4.1 reply. In by manipulating certain parameters present in each NFSv4.1 reply. In
addition, the CB_RECALL_SLOT callback operation (see Section 20.8) addition, the CB_RECALL_SLOT callback operation (see Section 20.8)
can be sent by a server to a client to return RDMA credits to the can be sent by a server to a client to return RDMA credits to the
server, thereby lowering the maximum number of requests a client can server, thereby lowering the maximum number of requests a client can
have outstanding to the server. have outstanding to the server.
2.10.7.3. Padding 2.10.7.3. Padding
Header padding is requested by each peer at session initiation (see Header padding is requested by each peer at session initiation (see
the ca_headerpadsize argument to CREATE_SESSION in Section 18.36), the ca_headerpadsize argument to CREATE_SESSION in Section 18.36),
and subsequently used by the RPC RDMA layer, as described in [9]. and subsequently used by the RPC RDMA layer, as described in [8].
Zero padding is permitted. Zero padding is permitted.
Padding leverages the useful property that RDMA preserve alignment of Padding leverages the useful property that RDMA preserve alignment of
data, even when they are placed into anonymous (untagged) buffers. data, even when they are placed into anonymous (untagged) buffers.
If requested, client inline writes will insert appropriate pad bytes If requested, client inline writes will insert appropriate pad bytes
within the request header to align the data payload on the specified within the request header to align the data payload on the specified
boundary. The client is encouraged to add sufficient padding (up to boundary. The client is encouraged to add sufficient padding (up to
the negotiated size) so that the "data" field of the NFSv4.1 WRITE the negotiated size) so that the "data" field of the NFSv4.1 WRITE
operation is aligned. Most servers can make good use of such operation is aligned. Most servers can make good use of such
padding, which allows them to chain receive buffers in such a way padding, which allows them to chain receive buffers in such a way
skipping to change at page 66, line 49 skipping to change at page 66, line 49
posted receive if unused by the actual received request, or may pass posted receive if unused by the actual received request, or may pass
the now-complete buffers by reference for normal write processing. the now-complete buffers by reference for normal write processing.
For a server which can make use of it, this removes any need for data For a server which can make use of it, this removes any need for data
copies of incoming data, without resorting to complicated end-to-end copies of incoming data, without resorting to complicated end-to-end
buffer advertisement and management. This includes most kernel-based buffer advertisement and management. This includes most kernel-based
and integrated server designs, among many others. The client may and integrated server designs, among many others. The client may
perform similar optimizations, if desired. perform similar optimizations, if desired.
2.10.7.4. Dual RDMA and Non-RDMA Transports 2.10.7.4. Dual RDMA and Non-RDMA Transports
Some RDMA transports (e.g., [11]), permit a "streaming" (non-RDMA) Some RDMA transports (e.g., RFC5040 [10]), permit a "streaming" (non-
phase, where ordinary traffic might flow before "stepping up" to RDMA RDMA) phase, where ordinary traffic might flow before "stepping up"
mode, commencing RDMA traffic. Some RDMA transports start to RDMA mode, commencing RDMA traffic. Some RDMA transports start
connections always in RDMA mode. NFSv4.1 allows, but does not connections always in RDMA mode. NFSv4.1 allows, but does not
assume, a streaming phase before RDMA mode. When a connection is assume, a streaming phase before RDMA mode. When a connection is
associated with a session, the client and server negotiate whether associated with a session, the client and server negotiate whether
the connection is used in RDMA or non-RDMA mode (see Section 18.36 the connection is used in RDMA or non-RDMA mode (see Section 18.36
and Section 18.34). and Section 18.34).
2.10.8. Sessions Security 2.10.8. Sessions Security
2.10.8.1. Session Callback Security 2.10.8.1. Session Callback Security
skipping to change at page 67, line 33 skipping to change at page 67, line 33
2.10.8.2. Backchannel RPC Security 2.10.8.2. Backchannel RPC Security
When the NFSv4.1 client establishes the backchannel, it informs the When the NFSv4.1 client establishes the backchannel, it informs the
server of the security flavors and principals to use when sending server of the security flavors and principals to use when sending
requests. If the security flavor is RPCSEC_GSS, the client expresses requests. If the security flavor is RPCSEC_GSS, the client expresses
the principal in the form of an established RPCSEC_GSS context. The the principal in the form of an established RPCSEC_GSS context. The
server is free to use any of the flavor/principal combinations the server is free to use any of the flavor/principal combinations the
client offers, but it MUST NOT use unoffered combinations. This way, client offers, but it MUST NOT use unoffered combinations. This way,
the client need not provide a target GSS principal for the the client need not provide a target GSS principal for the
backchannel as it did with NFSv4.0, nor the server have to implement backchannel as it did with NFSv4.0, nor the server have to implement
an RPCSEC_GSS initiator as it did with NFSv4.0 [30]. an RPCSEC_GSS initiator as it did with NFSv4.0 [29].
The CREATE_SESSION (Section 18.36) and BACKCHANNEL_CTL The CREATE_SESSION (Section 18.36) and BACKCHANNEL_CTL
(Section 18.33) operations allow the client to specify flavor/ (Section 18.33) operations allow the client to specify flavor/
principal combinations. principal combinations.
Also note that the SP4_SSV state protection mode (see Section 18.35 Also note that the SP4_SSV state protection mode (see Section 18.35
and Section 2.10.8.3) has the side benefit of providing SSV-derived and Section 2.10.8.3) has the side benefit of providing SSV-derived
RPCSEC_GSS contexts (Section 2.10.9). RPCSEC_GSS contexts (Section 2.10.9).
2.10.8.3. Protection from Unauthorized State Changes 2.10.8.3. Protection from Unauthorized State Changes
skipping to change at page 72, line 47 skipping to change at page 72, line 47
iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.ssv_mech iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.ssv_mech
(1.3.6.1.4.1.28882.1.1). While the SSV mechanism does not define any (1.3.6.1.4.1.28882.1.1). While the SSV mechanism does not define any
initial context tokens, the OID can be used to let servers indicate initial context tokens, the OID can be used to let servers indicate
that the SSV mechanism is acceptable whenever the client sends a that the SSV mechanism is acceptable whenever the client sends a
SECINFO or SECINFO_NO_NAME operation (see Section 2.6). SECINFO or SECINFO_NO_NAME operation (see Section 2.6).
The SSV mechanism defines four subkeys derived from the SSV value. The SSV mechanism defines four subkeys derived from the SSV value.
Each time SET_SSV is invoked the subkeys are recalculated by the Each time SET_SSV is invoked the subkeys are recalculated by the
client and server. The calculation of each of the four subkeys client and server. The calculation of each of the four subkeys
depends on each of the four respective ssv_subkey4 enumerated values. depends on each of the four respective ssv_subkey4 enumerated values.
The calculation uses the HMAC [12], algorithm, using the current SSV The calculation uses the HMAC [11], algorithm, using the current SSV
as the key, the one way hash algorithm as negotiated by EXCHANGE_ID, as the key, the one way hash algorithm as negotiated by EXCHANGE_ID,
and the input text as represented by the XDR encoded enumeration and the input text as represented by the XDR encoded enumeration
value for that subkey of data type ssv_subkey4. value for that subkey of data type ssv_subkey4.
/* Input for computing subkeys */ /* Input for computing subkeys */
enum ssv_subkey4 { enum ssv_subkey4 {
SSV4_SUBKEY_MIC_I2T = 1, SSV4_SUBKEY_MIC_I2T = 1,
SSV4_SUBKEY_MIC_T2I = 2, SSV4_SUBKEY_MIC_T2I = 2,
SSV4_SUBKEY_SEAL_I2T = 3, SSV4_SUBKEY_SEAL_I2T = 3,
SSV4_SUBKEY_SEAL_T2I = 4 SSV4_SUBKEY_SEAL_T2I = 4
skipping to change at page 73, line 43 skipping to change at page 73, line 43
uint32_t smt_ssv_seq; uint32_t smt_ssv_seq;
opaque smt_hmac<>; opaque smt_hmac<>;
}; };
The field smt_hmac is an HMAC calculated by using the subkey derived The field smt_hmac is an HMAC calculated by using the subkey derived
from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I as the key, the one from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I as the key, the one
way hash algorithm as negotiated by EXCHANGE_ID, and the input text way hash algorithm as negotiated by EXCHANGE_ID, and the input text
as represented by data of type ssv_mic_plain_tkn4. The field as represented by data of type ssv_mic_plain_tkn4. The field
smpt_ssv_seq is the same as smt_ssv_seq. The field smpt_orig_plain smpt_ssv_seq is the same as smt_ssv_seq. The field smpt_orig_plain
is the "message" input passed to GSS_GetMIC() (see Section 2.3.1 of is the "message" input passed to GSS_GetMIC() (see Section 2.3.1 of
[8]). The caller of GSS_GetMIC() provides a pointer to a buffer [7]). The caller of GSS_GetMIC() provides a pointer to a buffer
containing the plain text. The SSV mechanism's entry point for containing the plain text. The SSV mechanism's entry point for
GSS_GetMIC() encodes this into an opaque array, and the encoding will GSS_GetMIC() encodes this into an opaque array, and the encoding will
include an initial four byte length, plus any necessary padding. include an initial four byte length, plus any necessary padding.
Prepended to this will be the XDR encoded value of smpt_ssv_seq thus Prepended to this will be the XDR encoded value of smpt_ssv_seq thus
making up an XDR encoding of a value of data type ssv_mic_plain_tkn4, making up an XDR encoding of a value of data type ssv_mic_plain_tkn4,
which in turn is the input into the HMAC. which in turn is the input into the HMAC.
The token emitted by GSS_GetMIC() is XDR encoded and of XDR data type The token emitted by GSS_GetMIC() is XDR encoded and of XDR data type
ssv_mic_tkn4. The field smt_ssv_seq comes from the SSV sequence ssv_mic_tkn4. The field smt_ssv_seq comes from the SSV sequence
skipping to change at page 75, line 26 skipping to change at page 75, line 26
key is the subkey derived from SSV4_SUBKEY_MIC_I2T or key is the subkey derived from SSV4_SUBKEY_MIC_I2T or
SSV4_SUBKEY_MIC_T2I, and the one way hash algorithm is that SSV4_SUBKEY_MIC_T2I, and the one way hash algorithm is that
negotiated by EXCHANGE_ID. negotiated by EXCHANGE_ID.
The sspt_confounder field is a random value. The sspt_confounder field is a random value.
The sspt_ssv_seq field is the same as ssvt_ssv_seq. The sspt_ssv_seq field is the same as ssvt_ssv_seq.
The field sspt_orig_plain field is the original plaintext and is the The field sspt_orig_plain field is the original plaintext and is the
"input_message" input passed to GSS_Wrap() (see Section 2.3.3 of "input_message" input passed to GSS_Wrap() (see Section 2.3.3 of
[8]). As with the handling of the plaintext by the SSV mechanism's [7]). As with the handling of the plaintext by the SSV mechanism's
GSS_GetMIC() entry point, the entry point for GSS_Wrap() expects a GSS_GetMIC() entry point, the entry point for GSS_Wrap() expects a
pointer to the plaintext, and will XDR encode an opaque array into pointer to the plaintext, and will XDR encode an opaque array into
sspt_orig_plain representing the plain text, along with the other sspt_orig_plain representing the plain text, along with the other
fields of an instance of data type ssv_seal_plain_tkn4. fields of an instance of data type ssv_seal_plain_tkn4.
The sspt_pad field is present to support encryption algorithms that The sspt_pad field is present to support encryption algorithms that
require inputs to be in fixed sized blocks. The content of sspt_pad require inputs to be in fixed sized blocks. The content of sspt_pad
is zero filled except for the length. Beware that the XDR encoding is zero filled except for the length. Beware that the XDR encoding
of ssv_seal_plain_tkn4 contains three variable length arrays, and so of ssv_seal_plain_tkn4 contains three variable length arrays, and so
each array consumes four bytes for an array length, and each array each array consumes four bytes for an array length, and each array
skipping to change at page 84, line 12 skipping to change at page 84, line 12
created under the client ID, and to allow the server to indicate how created under the client ID, and to allow the server to indicate how
it will allow the sessions to be used. See Section 13.1 for pNFS it will allow the sessions to be used. See Section 13.1 for pNFS
sessions considerations. sessions considerations.
3. Protocol Constants and Data Types 3. Protocol Constants and Data Types
The syntax and semantics to describe the data types of the NFSv4.1 The syntax and semantics to describe the data types of the NFSv4.1
protocol are defined in the XDR RFC4506 [2] and RPC RFC1831 [3] protocol are defined in the XDR RFC4506 [2] and RPC RFC1831 [3]
documents. The next sections build upon the XDR data types to define documents. The next sections build upon the XDR data types to define
constants, types and structures specific to this protocol. The full constants, types and structures specific to this protocol. The full
list of XDR data types is in [13]. list of XDR data types is in [12].
3.1. Basic Constants 3.1. Basic Constants
const NFS4_FHSIZE = 128; const NFS4_FHSIZE = 128;
const NFS4_VERIFIER_SIZE = 8; const NFS4_VERIFIER_SIZE = 8;
const NFS4_OPAQUE_LIMIT = 1024; const NFS4_OPAQUE_LIMIT = 1024;
const NFS4_SESSIONID_SIZE = 16; const NFS4_SESSIONID_SIZE = 16;
const NFS4_INT64_MAX = 0x7fffffffffffffff; const NFS4_INT64_MAX = 0x7fffffffffffffff;
const NFS4_UINT64_MAX = 0xffffffffffffffff; const NFS4_UINT64_MAX = 0xffffffffffffffff;
skipping to change at page 85, line 52 skipping to change at page 85, line 52
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, LOCK, | | | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). | | | COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in SECINFO. | | | Quality of protection designation in SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 data | | | Security Object Identifier. The sec_oid4 data |
| | type is not really opaque. Instead it contains an | | | type is not really opaque. Instead it contains an |
| | ASN.1 OBJECT IDENTIFIER as used by GSS-API in the | | | ASN.1 OBJECT IDENTIFIER as used by GSS-API in the |
| | mech_type argument to GSS_Init_sec_context. See | | | mech_type argument to GSS_Init_sec_context. See |
| | [8] for details. | | | [7] for details. |
| sequenceid4 | typedef uint32_t sequenceid4; | | sequenceid4 | typedef uint32_t sequenceid4; |
| | Sequence number used for various session | | | Sequence number used for various session |
| | operations (EXCHANGE_ID, CREATE_SESSION, | | | operations (EXCHANGE_ID, CREATE_SESSION, |
| | SEQUENCE, CB_SEQUENCE). | | | SEQUENCE, CB_SEQUENCE). |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; | | sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; |
| | Session identifier. | | | Session identifier. |
| slotid4 | typedef uint32_t slotid4; | | slotid4 | typedef uint32_t slotid4; |
| | Sequencing artifact for various session | | | Sequencing artifact for various session |
skipping to change at page 86, line 28 skipping to change at page 86, line 28
| | Case-insensitive UTF-8 string. | | | Case-insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; | | utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. | | | Case-sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; | | utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case sensitive prefix and a | | | UTF-8 strings with a case sensitive prefix and a |
| | case insensitive suffix. | | | case insensitive suffix. |
| component4 | typedef utf8str_cs component4; | | component4 | typedef utf8str_cs component4; |
| | Represents path name components. | | | Represents path name components. |
| linktext4 | typedef utf8str_cs linktext4; | | linktext4 | typedef utf8str_cs linktext4; |
| | Symbolic link contents ("symbolic link" is | | | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [14] standard). | | | defined in an Open Group [13] standard). |
| pathname4 | typedef component4 pathname4<>; | | pathname4 | typedef component4 pathname4<>; |
| | Represents path name for fs_locations. | | | Represents path name for fs_locations. |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
| | Verifier used for various operations (COMMIT, | | | Verifier used for various operations (COMMIT, |
| | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) | | | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) |
| | NFS4_VERIFIER_SIZE is defined as 8. | | | NFS4_VERIFIER_SIZE is defined as 8. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
End of Base Data Types End of Base Data Types
skipping to change at page 89, line 28 skipping to change at page 89, line 28
3.3.9. netaddr4 3.3.9. netaddr4
struct netaddr4 { struct netaddr4 {
/* see struct rpcb in RFC 1833 */ /* see struct rpcb in RFC 1833 */
string na_r_netid<>; /* network id */ string na_r_netid<>; /* network id */
string na_r_addr<>; /* universal address */ string na_r_addr<>; /* universal address */
}; };
The netaddr4 data type is used to identify network transport The netaddr4 data type is used to identify network transport
endpoints. The r_netid and r_addr fields respectively contain a endpoints. The r_netid and r_addr fields respectively contain a
netid and uaddr. The netid and uaddr concepts are defined in [15]. netid and uaddr. The netid and uaddr concepts are defined in [14].
The netid and uaddr formats for TCP over IPv4 and TCP over IPv6 are The netid and uaddr formats for TCP over IPv4 and TCP over IPv6 are
defined in [15], specifically Tables 2 and 3 and Sections 3.2.3.3 and defined in [14], specifically Tables 2 and 3 and Sections 4.2.3.3 and
3.2.3.4. 4.2.3.4.
3.3.10. state_owner4 3.3.10. state_owner4
struct state_owner4 { struct state_owner4 {
clientid4 clientid; clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>; opaque owner<NFS4_OPAQUE_LIMIT>;
}; };
typedef state_owner4 open_owner4; typedef state_owner4 open_owner4;
typedef state_owner4 lock_owner4; typedef state_owner4 lock_owner4;
skipping to change at page 95, line 29 skipping to change at page 95, line 29
for a file system object. The contents of the filehandle are opaque for a file system 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 file system the filehandle to an internal representation of the file system
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 NFSv3 protocol initiate communication with the server. With the NFSv3 protocol
RFC1813 [31], there exists an ancillary protocol to obtain this first (RFC1813 [30]), there exists an ancillary protocol to obtain this
filehandle. The MOUNT protocol, RPC program number 100005, provides first filehandle. The MOUNT protocol, RPC program number 100005,
the mechanism of translating a string based file system path name to provides the mechanism of translating a string based file system path
a filehandle which can then be used by the NFS protocols. name to a filehandle which can then be used by 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 RFC2054 [41] and RFC2055 [42]. With the filehandle was introduced in RFC2054 [41] and RFC2055 [42]. With the
use of the public filehandle in combination with the LOOKUP operation use of the public filehandle in combination with the LOOKUP operation
in the NFSv3 protocol, it has been demonstrated that the MOUNT in the NFSv3 protocol, it has been demonstrated that the MOUNT
protocol is unnecessary for viable interaction between NFS client and protocol is unnecessary for viable interaction between NFS client and
server. server.
Therefore, the NFSv4.1 protocol will not use an ancillary protocol Therefore, the NFSv4.1 protocol will not use an ancillary protocol
skipping to change at page 97, line 27 skipping to change at page 97, line 27
behavior. All clients need to be prepared for situations in which it behavior. All clients need to be prepared for situations in which it
cannot be determined whether two filehandles denote the same object cannot be determined whether two filehandles denote the same object
and in such cases, avoid making invalid assumptions which might cause and in such cases, avoid making invalid assumptions which might cause
incorrect behavior. Further discussion of filehandle and attribute incorrect behavior. Further discussion of filehandle and attribute
comparison in the context of data caching is presented in the comparison in the context of data caching is presented in the
Section 10.3.4. Section 10.3.4.
As an example, in the case that two different path names when As an example, in the case that two different path names when
traversed at the server terminate at the same file system object, the traversed at the server terminate at the same file system object, the
server SHOULD return the same filehandle for each path. This can server SHOULD return the same filehandle for each path. This can
occur if a hard link (see [7]) is used to create two file names which occur if a hard link (see [6]) is used to create two file names which
refer to the same underlying file object and associated data. For refer to the same underlying file object and associated data. For
example, if paths /a/b/c and /a/d/c refer to the same file, the example, if paths /a/b/c and /a/d/c refer to the same file, the
server SHOULD return the same filehandle for both path names server SHOULD return the same filehandle for both path names
traversals. traversals.
4.2.2. Persistent Filehandle 4.2.2. Persistent Filehandle
A persistent filehandle is defined as having a fixed value for the A persistent filehandle is defined as having a fixed value for the
lifetime of the file system object to which it refers. Once the lifetime of the file system object to which it refers. Once the
server creates the filehandle for a file system object, the server server creates the filehandle for a file system object, the server
skipping to change at page 105, line 27 skipping to change at page 105, line 27
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 [13], the latter is conflicts between the assigned number and [12], the latter is
authoritative. likely authoritative, but should be resolved with Errata to this
document and/or [12]. See [43] 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 116, line 4 skipping to change at page 116, line 4
to the Windows operating environment. to the Windows operating environment.
5.8.2.37. Attribute 47: time_access 5.8.2.37. 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 that was satisfied by the server. The notion of object by a read that was satisfied by the server. The notion of
what is an "access" depends on server's operating environment and/or what is an "access" depends on server's operating environment and/or
the server's file system semantics. For example, for servers obeying the server's file system semantics. For example, for servers obeying
POSIX semantics, time_access would be updated only by the READ and POSIX semantics, time_access would be updated only by the READ and
READDIR operations and not any of the operations that modify the READDIR operations and not any of the operations that modify the
content of the object [16], [17], [18]. Of course, setting the content of the object [15], [16], [17]. Of course, setting the
corresponding time_access_set attribute is another way to modify the corresponding time_access_set attribute is another way to modify the
time_access 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 best efforts to record time_access into stable server should make 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
skipping to change at page 117, line 5 skipping to change at page 117, line 5
5.8.2.44. Attribute 54: time_modify_set 5.8.2.44. Attribute 54: time_modify_set
Set the time of last modification to the object. SETATTR use only. Set 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 RFC2624 [43] UTF-8 string has been chosen. Note that section 6.1 of RFC2624 [44]
provides additional rationale. It is expected that the client and provides additional rationale. It is expected that the client and
server will have their own local representation of owner and server will have their own local representation of owner and
owner_group that is used for local storage or presentation to the end owner_group that is used for local storage or presentation to the end
user. Therefore, it is expected that when these attributes are user. Therefore, it is expected that when these attributes are
transferred between the client and server that the local transferred between the client and server that the local
representation is translated to a syntax of the form "user@ representation is translated to a syntax of the form "user@
dns_domain". This will allow for a client and server that do not use dns_domain". This will allow for a client and server that do not use
the same local representation the ability to translate to a common the same local representation the ability to translate to a common
syntax that can be interpreted by both. syntax that can be interpreted by both.
skipping to change at page 118, line 50 skipping to change at page 118, line 50
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.
Users and implementations of NFSv4.1 SHOULD NOT use "nobody" to Users and implementations of NFSv4.1 SHOULD NOT use "nobody" to
designate a real user whose access is not anonymous. designate a real user whose access is not anonymous.
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) can be mapped according to each UCS-4 character (which UTF-8 encodes) can be mapped according to
Appendix B.2 of RFC3454 [19]. For general character handling and Appendix B.2 of RFC3454 [18]. For general character handling and
internationalization issues, see Section 14. internationalization issues, see Section 14.
5.11. Directory Notification Attributes 5.11. Directory Notification Attributes
As described in Section 18.39, the client can request a minimum delay As described in Section 18.39, the client can request a minimum delay
for notifications of changes to attributes, but the server is free to for notifications of changes to attributes, but the server is free to
ignore what the client requests. The client can determine in advance ignore what the client requests. The client can determine in advance
what notification delays the server will accept by issuing a GETATTR what notification delays the server will accept by issuing a GETATTR
for either or both of two directory notification attributes. When for either or both of two directory notification attributes. When
the client calls the GET_DIR_DELEGATION operation and asks for the client calls the GET_DIR_DELEGATION operation and asks for
skipping to change at page 136, line 40 skipping to change at page 136, line 40
set unless the NFSv4.1 server has the means to set the set unless the NFSv4.1 server has the means to set the
ACE4_SYNCHRONIZE bit. The second copy will not have the ACE4_SYNCHRONIZE bit. The second copy will not have the
permission set unless the NFSv4.1 server has the means to permission set unless the NFSv4.1 server has the means to
retrieve the ACE4_SYNCHRONIZE bit. retrieve the ACE4_SYNCHRONIZE bit.
Server implementations need not provide the granularity of control Server implementations need not provide the granularity of control
that is implied by this list of masks. For example, POSIX-based that is implied by this list of masks. For example, POSIX-based
systems might not distinguish ACE4_APPEND_DATA (the ability to append systems might not distinguish ACE4_APPEND_DATA (the ability to append
to a file) from ACE4_WRITE_DATA (the ability to modify existing to a file) from ACE4_WRITE_DATA (the ability to modify existing
contents); both masks would be tied to a single "write" permission contents); both masks would be tied to a single "write" permission
[20]. When such a server returns attributes to the client, it would [19]. When such a server returns attributes to the client, it would
show both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the show both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the
write permission is enabled. write permission is enabled.
If a server receives a SETATTR request that it cannot accurately If a server receives a SETATTR request that it cannot accurately
implement, it should err in the direction of more restricted access, implement, it should err in the direction of more restricted access,
except in the previously discussed cases of execute and read. For except in the previously discussed cases of execute and read. For
example, suppose a server cannot distinguish overwriting data from example, suppose a server cannot distinguish overwriting data from
appending new data, as described in the previous paragraph. If a appending new data, as described in the previous paragraph. If a
client submits an ALLOW ACE where ACE4_APPEND_DATA is set but client submits an ALLOW ACE where ACE4_APPEND_DATA is set but
ACE4_WRITE_DATA is not (or vice versa), the server should either turn ACE4_WRITE_DATA is not (or vice versa), the server should either turn
skipping to change at page 155, line 7 skipping to change at page 155, line 7
clients should use strong security mechanisms to access the pseudo clients should use strong security mechanisms to access the pseudo
file system in order to prevent man-in-the-middle attacks. file system in order to prevent man-in-the-middle attacks.
8. State Management 8. State Management
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 such features as share reservations, stateful. With the inclusion of such features as share reservations,
file and directory delegations, recallable layouts, and support for file and directory delegations, recallable layouts, and support for
mandatory byte-range locking, the protocol becomes substantially more mandatory byte-range locking, the protocol becomes substantially more
dependent on proper management of state than the traditional dependent on proper management of state than the traditional
combination of NFS and NLM [44]. These features include expanded combination of NFS and NLM [45]. These features include expanded
locking facilities, which provide some measure of interclient locking facilities, which provide some measure of interclient
exclusion, but the state also offers features not readily providable exclusion, but the state also offers features not readily providable
using a stateless model. There are three components to making this using a stateless model. There are three components to making this
state manageable: 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
skipping to change at page 171, line 34 skipping to change at page 171, line 34
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
[45]. The client must account for the server that can perform I/O [46]. The client must account for the server that can perform I/O
and non-reclaim locking requests within the grace period as well as and non-reclaim locking requests within the grace period as well as
those that cannot do so. 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 restart. I/O request has been granted since 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
skipping to change at page 215, line 14 skipping to change at page 215, line 14
attributes obtained via GETATTR. attributes obtained via GETATTR.
A client may validate its cached version of attributes for a file by A client may validate its cached version of attributes for a file by
fetching just both the change and time_access attributes and assuming fetching just both the change and time_access attributes and assuming
that if the change attribute has the same value as it did when the that if the change attribute has the same value as it did when the
attributes were cached, then no attributes other than time_access attributes were cached, then no attributes other than time_access
have changed. The reason why time_access is also fetched is because have changed. The reason why time_access is also fetched is because
many servers operate in environments where the operation that updates many servers operate in environments where the operation that updates
change does not update time_access. For example, POSIX file change does not update time_access. For example, POSIX file
semantics do not update access time when a file is modified by the semantics do not update access time when a file is modified by the
write system call [18]. Therefore, the client that wants a current write system call [17]. Therefore, the client that wants a current
time_access value should fetch it with change during the attribute time_access value should fetch it with change during the attribute
cache validation processing and update its cached time_access. cache validation processing and update its cached time_access.
The client may maintain a cache of modified attributes for those The client may maintain a cache of modified attributes for those
attributes intimately connected with data of modified regular files attributes intimately connected with data of modified regular files
(size, time_modify, and change). Other than those three attributes, (size, time_modify, and change). Other than those three attributes,
the client MUST NOT maintain a cache of modified attributes. the client MUST NOT maintain a cache of modified attributes.
Instead, attribute changes are immediately sent to the server. Instead, attribute changes are immediately sent to the server.
In some operating environments, the equivalent to time_access is In some operating environments, the equivalent to time_access is
skipping to change at page 254, line 14 skipping to change at page 254, line 14
}; };
The fs_location4 data type is used to represent the location of a The fs_location4 data type is used to represent the location of a
file system by providing a server name and the path to the root of file system by providing a server name and the path to the root of
the file system within that server's namespace. When a set of the file system within that server's namespace. When a set of
servers have corresponding file systems at the same path within their servers have corresponding file systems at the same path within their
namespaces, an array of server names may be provided. An entry in namespaces, an array of server names may be provided. An entry in
the server array is a UTF-8 string and represents one of a the server array is a UTF-8 string and represents one of a
traditional DNS host name, IPv4 address, or IPv6 address, or a zero- traditional DNS host name, IPv4 address, or IPv6 address, or a zero-
length string. An IPv4 or IPv6 address is represented as a universal length string. An IPv4 or IPv6 address is represented as a universal
address (see Section 3.3.9 and [15]), minus the netid, and either address (see Section 3.3.9 and [14]), minus the netid, and either
with or without the trailing ".p1.p2" suffix that represents the port with or without the trailing ".p1.p2" suffix that represents the port
number. If the suffix is omitted, then the default port, 2049, number. If the suffix is omitted, then the default port, 2049,
SHOULD be assumed. A zero-length string SHOULD be used to indicate SHOULD be assumed. A zero-length string SHOULD be used to indicate
the current address being used for the RPC call. It is not a the current address being used for the RPC call. It is not a
requirement that all servers that share the same rootpath be listed requirement that all servers that share the same rootpath be listed
in one fs_location4 instance. The array of server names is provided in one fs_location4 instance. The array of server names is provided
for convenience. Servers that share the same rootpath may also be for convenience. Servers that share the same rootpath may also be
listed in separate fs_location4 entries in the fs_locations listed in separate fs_location4 entries in the fs_locations
attribute. attribute.
skipping to change at page 275, line 16 skipping to change at page 275, line 16
As noted in the Figure 1, the storage protocol is the method used by As noted in the Figure 1, the storage protocol is the method used by
the client to store and retrieve data directly from the storage the client to store and retrieve data directly from the storage
devices. devices.
The NFSv4.1 pNFS feature has been structured to allow for a variety The NFSv4.1 pNFS feature has been structured to allow for a variety
of storage protocols to be defined and used. One example storage of storage protocols to be defined and used. One example storage
protocol is NFSv4.1 itself (as documented in Section 13). Other protocol is NFSv4.1 itself (as documented in Section 13). Other
options for the storage protocol are described elsewhere and include: options for the storage protocol are described elsewhere and include:
o Block/volume protocols such as iSCSI ([46]), and FCP ([47]). The o Block/volume protocols such as iSCSI ([47]), and FCP ([48]). The
block/volume protocol support can be independent of the addressing block/volume protocol support can be independent of the addressing
structure of the block/volume protocol used, allowing more than structure of the block/volume protocol used, allowing more than
one protocol to access the same file data and enabling one protocol to access the same file data and enabling
extensibility to other block/volume protocols. See [40] for a extensibility to other block/volume protocols. See [40] for a
layout specification that allows pNFS to use block/volume storage layout specification that allows pNFS to use block/volume storage
protocols. protocols.
o Object protocols such as OSD over iSCSI or Fibre Channel [48]. o Object protocols such as OSD over iSCSI or Fibre Channel [49].
See [39] for a layout specifications that allows pNFS to use See [39] for a layout specification that allows pNFS to use object
object storage protocols. storage protocols.
It is possible that various storage protocols are available to both It is possible that various storage protocols are available to both
client and server and it may be possible that a client and server do client and server and it may be possible that a client and server do
not have a matching storage protocol available to them. Because of not have a matching storage protocol available to them. Because of
this, the pNFS server MUST support normal NFSv4.1 access to any file this, the pNFS server MUST support normal NFSv4.1 access to any file
accessible by the pNFS feature; this will allow for continued accessible by the pNFS feature; this will allow for continued
interoperability between an NFSv4.1 client and server. interoperability between an NFSv4.1 client and server.
12.2.6. Control Protocol 12.2.6. Control Protocol
The control protocol is used by the exported file system between the As noted in the Figure 1, the control protocol is used by the
metadata server and storage devices. Specification of such protocols exported file system between the metadata server and storage devices.
is outside the scope of the NFSv4.1 protocol. Such control protocols Specification of such protocols is outside the scope of the NFSv4.1
would be used to control activities such as the allocation and protocol. Such control protocols would be used to control activities
deallocation of storage, the management of state required by the such as the allocation and deallocation of storage, the management of
storage devices to perform client access control, and, depending on state required by the storage devices to perform client access
the storage protocol, the enforcement of authentication and control, and, depending on the storage protocol, the enforcement of
authorization so that restrictions that would be enforced by the authentication and authorization so that restrictions that would be
metadata server are also enforced by the storage device. enforced by the metadata server are also enforced by the storage
device.
A particular control protocol is not REQUIRED by NFSv4.1 but A particular control protocol is not REQUIRED by NFSv4.1 but
requirements are placed on the control protocol for maintaining requirements are placed on the control protocol for maintaining
attributes like modify time, the change attribute, and the end-of- attributes like modify time, the change attribute, and the end-of-
file (EOF) position. Note that if pNFS is layered over a clustered, file (EOF) position. Note that if pNFS is layered over a clustered,
parallel file system (e.g. PVFS [49]), the mechanisms that enable parallel file system (e.g. PVFS [50]), the mechanisms that enable
clustering and parallelism in that file system can be considered the clustering and parallelism in that file system can be considered the
control protocol. control protocol.
12.2.7. Layout Types 12.2.7. Layout Types
A layout describes the mapping of a file's data to the storage A layout describes the mapping of a file's data to the storage
devices that hold the data. A layout is said to belong to a specific devices that hold the data. A layout is said to belong to a specific
layout type (data type layouttype4, see Section 3.3.13). The layout layout type (data type layouttype4, see Section 3.3.13). The layout
type allows for variants to handle different storage protocols, such type allows for variants to handle different storage protocols, such
as those associated with block/volume [40], object [39], and file as those associated with block/volume [40], object [39], and file
skipping to change at page 280, line 46 skipping to change at page 280, line 46
which a layout is held, does not necessarily conflict with the which a layout is held, does not necessarily conflict with the
holding of the layout that describes the file being modified. holding of the layout that describes the file being modified.
Therefore, it is the requirement of the storage protocol or layout Therefore, it is the requirement of the storage protocol or layout
type that determines the necessary behavior. For example, block/ type that determines the necessary behavior. For example, block/
volume layout types require that the layout's iomode agree with the volume layout types require that the layout's iomode agree with the
type of I/O being performed. type of I/O being performed.
Depending upon the layout type and storage protocol in use, storage Depending upon the layout type and storage protocol in use, storage
device access permissions may be granted by LAYOUTGET and may be device access permissions may be granted by LAYOUTGET and may be
encoded within the type-specific layout. For an example of storage encoded within the type-specific layout. For an example of storage
device access permissions see an object based protocol such as [48]. device access permissions, see an object based protocol such as [49].
If access permissions are encoded within the layout, the metadata If access permissions are encoded within the layout, the metadata
server SHOULD recall the layout when those permissions become invalid server SHOULD recall the layout when those permissions become invalid
for any reason; for example when a file becomes unwritable or for any reason; for example when a file becomes unwritable or
inaccessible to a client. Note, clients are still required to inaccessible to a client. Note, clients are still required to
perform the appropriate access operations with open, lock and access perform the appropriate access operations with open, lock and access
as described above. The degree to which it is possible for the as described above. The degree to which it is possible for the
client to circumvent these access operations and the consequences of client to circumvent these access operations and the consequences of
doing so must be clearly specified by the individual layout type doing so must be clearly specified by the individual layout type
specifications. In addition, these specifications must be clear specifications. In addition, these specifications must be clear
about the requirements and non-requirements for the checking about the requirements and non-requirements for the checking
skipping to change at page 289, line 24 skipping to change at page 289, line 24
outstanding I/O requests to the storage device. outstanding I/O requests to the storage device.
Even with this requirement for the client, it is possible that I/O Even with this requirement for the client, it is possible that I/O
requests may be presented to a storage device no longer allowed to requests may be presented to a storage device no longer allowed to
perform them. Since the server has no strict control as to when the perform them. Since the server has no strict control as to when the
client will return the layout, the server may later decide to client will return the layout, the server may later decide to
unilaterally revoke the client's access to the storage devices as unilaterally revoke the client's access to the storage devices as
provided by the layout. In choosing to revoke access, the server provided by the layout. In choosing to revoke access, the server
must deal with the possibility of lingering I/O request; those must deal with the possibility of lingering I/O request; those
outstanding I/O requests are still in flight to storage devices outstanding I/O requests are still in flight to storage devices
identified by the revoked layout. All layout specifications MUST identified by the revoked layout. All layout type specifications
define whether unilateral layout revocation by the metadata server is MUST define whether unilateral layout revocation by the metadata
supported; if it is, the specification must also describe how server is supported; if it is, the specification must also describe
lingering writes are processed. For example, storage devices how lingering writes are processed. For example, storage devices
identified by the revoked layout could be fenced off from the client identified by the revoked layout could be fenced off from the client
that held the layout. that held the layout.
In order to ensure client/server convergence with regard to layout In order to ensure client/server convergence with regard to layout
state, the final LAYOUTRETURN operation in a sequence of LAYOUTRETURN state, the final LAYOUTRETURN operation in a sequence of LAYOUTRETURN
operations for a particular recall, MUST specify the entire range operations for a particular recall, MUST specify the entire range
being recalled, echoing the recalled layout type, iomode, recall/ being recalled, echoing the recalled layout type, iomode, recall/
return type (FILE, FSID, or ALL), and byte range; even if layouts return type (FILE, FSID, or ALL), and byte range; even if layouts
pertaining to partial ranges were previously returned. In addition, pertaining to partial ranges were previously returned. In addition,
if the client holds no layouts that overlaps the range being if the client holds no layouts that overlaps the range being
skipping to change at page 328, line 15 skipping to change at page 328, line 15
attribute, open mode, open deny mode, mandatory lock state, or any attribute, open mode, open deny mode, mandatory lock state, or any
other attributes and state, the data server MUST also deny the READ other attributes and state, the data server MUST also deny the READ
or WRITE operation. This impacts the control protocol and the or WRITE operation. This impacts the control protocol and the
propagation of state from the metadata server to the data servers; propagation of state from the metadata server to the data servers;
see Section 13.9.2 for more details. see Section 13.9.2 for more details.
The methods for authentication, integrity, and privacy for file The methods for authentication, integrity, and privacy for file
layout-based data servers are the same as those used by metadata layout-based data servers are the same as those used by metadata
servers. Metadata and data servers use ONC RPC security flavors to servers. Metadata and data servers use ONC RPC security flavors to
authenticate, and SECINFO and SECINFO_NO_NAME to negotiate the authenticate, and SECINFO and SECINFO_NO_NAME to negotiate the
security mechanism and services to be used. security mechanism and services to be used. Thus when using the
LAYOUT4_NFSV4_1_FILES layout type, the impact on the RPC-based
security model due to pNFS (as alluded to in Section 1.6.1 and
Section 1.6.2.2) is zero.
For a given file object, a metadata server MAY require different For a given file object, a metadata server MAY require different
security parameters (secinfo4 value) than the data server. For a security parameters (secinfo4 value) than the data server. For a
given file object with multiple data servers, the secinfo4 value given file object with multiple data servers, the secinfo4 value
SHOULD be the same across all data servers. If the secinfo4 values SHOULD be the same across all data servers. If the secinfo4 values
across a metadata server and its data servers differ for a specific across a metadata server and its data servers differ for a specific
file, the mapping of the principal to the server's internal user file, the mapping of the principal to the server's internal user
identifier MUST be the same in order for the access control checks identifier MUST be the same in order for the access control checks
based on ACL, mode, open and deny mode, and mandatory locking to be based on ACL, mode, open and deny mode, and mandatory locking to be
consistent across on the pNFS server. consistent across on the pNFS server.
skipping to change at page 328, line 38 skipping to change at page 328, line 41
layouts, then the implementation MUST support the SECINFO_NO_NAME layouts, then the implementation MUST support the SECINFO_NO_NAME
operation, on both the metadata and data servers. operation, on both the metadata and data servers.
14. Internationalization 14. Internationalization
The primary issue in which NFSv4.1 needs to deal with The primary issue in which NFSv4.1 needs to deal with
internationalization, or I18N, is with respect to file names and internationalization, or I18N, is with respect to file names and
other strings as used within the protocol. The choice of string other strings as used within the protocol. The choice of string
representation must allow reasonable name/string access to clients representation must allow reasonable name/string access to clients
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 ISO10646 [21] allows for this type of access and follows defined by ISO10646 [20] allows for this type of access and follows
the policy described in "IETF Policy on Character Sets and the policy described in "IETF Policy on Character Sets and
Languages", RFC2277 [22]. Languages", RFC2277 [21].
RFC3454 [19], otherwise know as "stringprep", documents a framework RFC3454 [18], otherwise know as "stringprep", documents a framework
for using Unicode/UTF-8 in networking protocols, so as "to increase for using Unicode/UTF-8 in networking protocols, so as "to increase
the likelihood that string input and string comparison work in ways the likelihood that string input and string comparison work in ways
that make sense for typical users throughout the world." A protocol that make sense for typical users throughout the world." A protocol
must define a profile of stringprep "in order to fully specify the must define a profile of stringprep "in order to fully specify the
processing options." The remainder of this Internationalization processing options." The remainder of this Internationalization
section defines the NFSv4.1 stringprep profiles. Much of terminology section defines the NFSv4.1 stringprep profiles. Much of terminology
used for the remainder of this section comes from stringprep. used for the remainder of this section comes from stringprep.
There are three UTF-8 string types defined for NFSv4.1: utf8str_cs, There are three UTF-8 string types defined for NFSv4.1: utf8str_cs,
utf8str_cis, and utf8str_mixed. Separate profiles are defined for utf8str_cis, and utf8str_mixed. Separate profiles are defined for
each. Each profile defines the following, as required by stringprep: each. Each profile defines the following, as required by stringprep:
o The intended applicability of the profile o The intended applicability of the profile
o The character repertoire that is the input and output to o The character repertoire that is the input and output to
stringprep (which is Unicode 3.2 for referenced version of stringprep (which is Unicode 3.2 for referenced version of
stringprep) stringprep). However, NFSv4.1 implementations are not limited to
3.2.
o The mapping tables from stringprep used (as described in section 3 o The mapping tables from stringprep used (as described in section 3
of stringprep) of stringprep)
o Any additional mapping tables specific to the profile o Any additional mapping tables specific to the profile
o The Unicode normalization used, if any (as described in section 4 o The Unicode normalization used, if any (as described in section 4
of stringprep) of stringprep)
o The tables from stringprep listing of characters that are o The tables from stringprep listing of characters that are
skipping to change at page 329, line 37 skipping to change at page 329, line 40
section 6 of stringprep) section 6 of stringprep)
o Any additional characters that are prohibited as output specific o Any additional characters that are prohibited as output specific
to the profile to the profile
Stringprep discusses Unicode characters, whereas NFSv4.1 renders Stringprep discusses Unicode characters, whereas NFSv4.1 renders
UTF-8 characters. Since there is a one-to-one mapping from UTF-8 to UTF-8 characters. Since there is a one-to-one mapping from UTF-8 to
Unicode, when the remainder of this document refers to Unicode, the Unicode, when the remainder of this document refers to Unicode, the
reader should assume UTF-8. reader should assume UTF-8.
Much of the text for the profiles comes from RFC3491 [23]. Much of the text for the profiles comes from RFC3491 [22].
14.1. Stringprep profile for the utf8str_cs type 14.1. Stringprep profile for the utf8str_cs type
Every use of the utf8str_cs type definition in the NFSv4 protocol Every use of the utf8str_cs type definition in the NFSv4 protocol
specification follows the profile named nfs4_cs_prep. specification follows the profile named nfs4_cs_prep.
14.1.1. Intended applicability of the nfs4_cs_prep profile 14.1.1. Intended applicability of the nfs4_cs_prep profile
The utf8str_cs type is a case sensitive string of UTF-8 characters. The utf8str_cs type is a case sensitive string of UTF-8 characters.
Its primary use in NFSv4.1 is for naming components and pathnames. Its primary use in NFSv4.1 is for naming components and pathnames.
skipping to change at page 330, line 15 skipping to change at page 330, line 18
o disallow the creation of a second name if its post processed form o disallow the creation of a second name if its post processed form
collides with that of an existing name, or collides with that of an existing name, or
o allow the creation of the second name, but arrange so that after o allow the creation of the second name, but arrange so that after
post processing, the second name is different than the post post processing, the second name is different than the post
processed form of the first name. processed form of the first name.
14.1.2. Character repertoire of nfs4_cs_prep 14.1.2. Character repertoire of nfs4_cs_prep
The nfs4_cs_prep profile uses Unicode 3.2, as defined in stringprep's The nfs4_cs_prep profile uses Unicode 3.2, as defined in stringprep's
Appendix A.1 Appendix A.1. However, NFSv4.1 implementations are not limited to
3.2.
14.1.3. Mapping used by nfs4_cs_prep 14.1.3. Mapping used by nfs4_cs_prep
The nfs4_cs_prep profile specifies mapping using the following tables The nfs4_cs_prep profile specifies mapping using the following tables
from stringprep: from stringprep:
Table B.1 Table B.1
Table B.2 is normally not part of the nfs4_cs_prep profile as it is Table B.2 is normally not part of the nfs4_cs_prep profile as it is
primarily for dealing with case-insensitive comparisons. However, if primarily for dealing with case-insensitive comparisons. However, if
skipping to change at page 330, line 50 skipping to change at page 331, line 7
later revision of this specification may specify a particular later revision of this specification may specify a particular
normalization form. Therefore, the server and client can expect that normalization form. Therefore, the server and client can expect that
they may receive unnormalized characters within protocol requests and they may receive unnormalized characters within protocol requests and
responses. If the operating environment requires normalization, then responses. If the operating environment requires normalization, then
the implementation must normalize utf8str_cs strings within the the implementation must normalize utf8str_cs strings within the
protocol before presenting the information to an application (at the protocol before presenting the information to an application (at the
client) or local file system (at the server). client) or local file system (at the server).
14.1.5. Prohibited output for nfs4_cs_prep 14.1.5. Prohibited output for nfs4_cs_prep
The nfs4_cs_prep profile specifies prohibiting using the following The nfs4_cs_prep profile RECOMMENDS prohibiting the use of the
tables from stringprep: following tables from stringprep:
Table C.3
Table C.4
Table C.5 Table C.5
Table C.6 Table C.6
Table C.7
Table C.8
Table C.9
14.1.6. Bidirectional output for nfs4_cs_prep 14.1.6. Bidirectional output for nfs4_cs_prep
The nfs4_cs_prep profile does not specify any checking of The nfs4_cs_prep profile does not specify any checking of
bidirectional strings. bidirectional strings.
14.2. Stringprep profile for the utf8str_cis type 14.2. Stringprep profile for the utf8str_cis type
Every use of the utf8str_cis type definition in the NFSv4.1 protocol Every use of the utf8str_cis type definition in the NFSv4.1 protocol
specification follows the profile named nfs4_cis_prep. specification follows the profile named nfs4_cis_prep.
14.2.1. Intended applicability of the nfs4_cis_prep profile 14.2.1. Intended applicability of the nfs4_cis_prep profile
The utf8str_cis type is a case insensitive string of UTF-8 The utf8str_cis type is a case insensitive string of UTF-8
characters. Its primary use in NFSv4.1 is for naming NFS servers. characters. Its primary use in NFSv4.1 is for naming NFS servers.
14.2.2. Character repertoire of nfs4_cis_prep 14.2.2. Character repertoire of nfs4_cis_prep
The nfs4_cis_prep profile uses Unicode 3.2, as defined in The nfs4_cis_prep profile uses Unicode 3.2, as defined in
stringprep's Appendix A.1 stringprep's Appendix A.1. However, NFSv4.1 implementations are not
limited to 3.2.
14.2.3. Mapping used by nfs4_cis_prep 14.2.3. Mapping used by nfs4_cis_prep
The nfs4_cis_prep profile specifies mapping using the following The nfs4_cis_prep profile specifies mapping using the following
tables from stringprep: tables from stringprep:
Table B.1 Table B.1
Table B.2 Table B.2
skipping to change at page 332, line 48 skipping to change at page 332, line 43
14.3.1. Intended applicability of the nfs4_mixed_prep profile 14.3.1. Intended applicability of the nfs4_mixed_prep profile
The utf8str_mixed type is a string of UTF-8 characters, with a prefix The utf8str_mixed type is a string of UTF-8 characters, with a prefix
that is case sensitive, a separator equal to '@', and a suffix that that is case sensitive, a separator equal to '@', and a suffix that
is fully qualified domain name. Its primary use in NFSv4.1 is for is fully qualified domain name. Its primary use in NFSv4.1 is for
naming principals identified in an Access Control Entry. naming principals identified in an Access Control Entry.
14.3.2. Character repertoire of nfs4_mixed_prep 14.3.2. Character repertoire of nfs4_mixed_prep
The nfs4_mixed_prep profile uses Unicode 3.2, as defined in The nfs4_mixed_prep profile uses Unicode 3.2, as defined in
stringprep's Appendix A.1 stringprep's Appendix A.1. However, NFSv4.1 implementations are not
limited to 3.2.
14.3.3. Mapping used by nfs4_cis_prep 14.3.3. Mapping used by nfs4_cis_prep
For the prefix and the separator of a utf8str_mixed string, the For the prefix and the separator of a utf8str_mixed string, the
nfs4_mixed_prep profile specifies mapping using the following table nfs4_mixed_prep profile specifies mapping using the following table
from stringprep: from stringprep:
Table B.1 Table B.1
For the suffix of a utf8str_mixed string, the nfs4_mixed_prep profile For the suffix of a utf8str_mixed string, the nfs4_mixed_prep profile
skipping to change at page 334, line 37 skipping to change at page 334, line 29
14.5. UTF-8 Related Errors 14.5. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server should Where the client sends an invalid UTF-8 string, the server should
return NFS4ERR_INVAL (see Table 5). This includes cases in which return NFS4ERR_INVAL (see Table 5). This includes cases in which
inappropriate prefixes are detected and where the count includes inappropriate prefixes are detected and where the count includes
trailing bytes that do not constitute a full UCS character. trailing bytes that do not constitute a full UCS character.
Where the client supplied string is valid UTF-8 but contains Where the client supplied string is valid UTF-8 but contains
characters that are not supported by the server as a value for that characters that are not supported by the server as a value for that
string (e.g. names containing characters that have more than two string (e.g. names containing characters outside of Unicode plane 0
bytes on a file system that supports Unicode characters only), the on filesystems that fail to support such characters despite their
server should return NFS4ERR_BADCHAR. presence in the Unicode standard), the server should return
NFS4ERR_BADCHAR.
Where a UTF-8 string is used as a file name, and the file system, Where a UTF-8 string is used as a file name, and the file system,
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the server should return the allow that particular name to be used, the server should return the
error NFS4ERR_BADNAME (Table 5). This includes situations in which error NFS4ERR_BADNAME (Table 5). This includes situations in which
the server file system imposes a normalization constraint on name the server file system imposes a normalization constraint on name
strings, but will also include such situations as file system strings, but will also include such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and other such constraints. and other such constraints.
skipping to change at page 347, line 23 skipping to change at page 347, line 20
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.
15.1.8.7. NFS4ERR_LOCK_RANGE (Error Code 10028) 15.1.8.7. 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 [24]. of request, and thus does not implement POSIX locking semantics [23].
See Section 18.10.4, Section 18.11.4, and Section 18.12.4 for a See Section 18.10.4, Section 18.11.4, and Section 18.12.4 for a
discussion of how this applies to LOCK, LOCKT, and LOCKU discussion of how this applies to LOCK, LOCKT, and LOCKU
respectively. respectively.
15.1.8.8. NFS4ERR_OPENMODE (Error Code 10038) 15.1.8.8. 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).
skipping to change at page 405, line 5 skipping to change at page 405, line 5
o When a client executes a regular file, it has to read the file o When a client executes a regular file, it has to read the file
from the server. Strictly speaking, the server should not allow from the server. Strictly speaking, the server should not allow
the client to read a file being executed unless the user has read the client to read a file being executed unless the user has read
permissions on the file. Requiring users and administers to set permissions on the file. Requiring users and administers to set
read permissions on executable files in order to access them over read permissions on executable files in order to access them over
NFS is not going to be acceptable to some people. Historically, NFS is not going to be acceptable to some people. Historically,
NFS servers have allowed a user to READ a file if the user has NFS servers have allowed a user to READ a file if the user has
execute access to the file. execute access to the file.
As a practical example, the UNIX specification [50] states that an As a practical example, the UNIX specification [51] states that an
implementation claiming conformance to UNIX may indicate in the implementation claiming conformance to UNIX may indicate in the
access() programming interface's result that a privileged user has access() programming interface's result that a privileged user has
execute rights, even if no execute permission bits are set on the execute rights, even if no execute permission bits are set on the
regular file's attributes. It is possible to claim conformance to regular file's attributes. It is possible to claim conformance to
the UNIX specification and instead not indicate execute rights in the UNIX specification and instead not indicate execute rights in
that situation, which is true for some operating environments. that situation, which is true for some operating environments.
Suppose the operating environments of the client and server are Suppose the operating environments of the client and server are
implementing the access() semantics for privileged users differently, implementing the access() semantics for privileged users differently,
and the ACCESS operation implementations of the client and server and the ACCESS operation implementations of the client and server
follow their respective access() semantics. This can cause undesired follow their respective access() semantics. This can cause undesired
skipping to change at page 410, line 47 skipping to change at page 410, line 47
event or instantiation that may lead to a loss of uncommitted data. event or instantiation that may lead to a loss of uncommitted data.
Most commonly this occurs when the server is restarted; however, Most commonly this occurs when the server is restarted; however,
other events at the server may result in uncommitted data loss as other events at the server may result in uncommitted data loss as
well. well.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.3.4. IMPLEMENTATION 18.3.4. 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() [25] system interface that synchronizes a file's state POSIX fsync() [24] system interface that synchronizes a file's state
with 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(2), it may disk or stable storage for the specified file. Like fsync(2), 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(2) in that it is possible for the client to COMMIT differs from fsync(2) in that it is possible for the client to
skipping to change at page 414, line 25 skipping to change at page 414, line 25
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 file system semantics may the server's operating environment or file system 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 file system both supports and requires the notion of a group server's file system 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 [26] that has a group identifier POSIX systems have a user database [25] that has a group identifier
for every user identifier), inherited from directory the object is for every user identifier), inherited from directory the object is
created in, or whatever else the server's operating environment or created in, or whatever else the server's operating environment or
file system semantics dictate. This applies to the OPEN operation file system semantics dictate. This applies to the OPEN operation
too. 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, group attribute, or ACL that the principal indicated owner attribute, group attribute, or ACL that the principal indicated
the RPC call's credentials does not have permissions to create files the RPC call's credentials does not have permissions to create files
for. The error to be returned in this instance is NFS4ERR_PERM. for. The error to be returned in this instance is NFS4ERR_PERM.
This applies to the OPEN operation too. This applies to the OPEN operation too.
skipping to change at page 428, line 51 skipping to change at page 428, line 51
Section 18.35) to send LOCKU. Section 18.35) to send LOCKU.
18.12.4. IMPLEMENTATION 18.12.4. 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 [24] semantics, a client these cases, allowed by POSIX locking [23] 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 a write delegation, it may choose (See When a client holds a write delegation, it may choose (See
Section 18.10.4) to handle LOCK requests locally. In such a case, Section 18.10.4) to handle LOCK requests locally. In such a case,
LOCKU requests will similarly be handled locally. LOCKU requests will similarly be handled locally.
18.13. Operation 15: LOOKUP - Lookup Filename 18.13. Operation 15: LOOKUP - Lookup Filename
skipping to change at page 444, line 26 skipping to change at page 444, line 26
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.
o OPEN4_RESULT_CONFIRM is deprecated and MUST NOT be returned by an o OPEN4_RESULT_CONFIRM is deprecated and MUST NOT be returned by an
NFSv4.1 server. NFSv4.1 server.
o OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking o OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of POSIX locking techniques behavior supports the complete set of POSIX locking techniques
[24]. From this the client can choose to manage file locking [23]. From this the client can choose to manage file locking
state in a way to handle a mis-match of file locking management. state in a way to handle a mis-match of file locking management.
o OPEN4_RESULT_PRESERVE_UNLINKED indicates the server will preserve o OPEN4_RESULT_PRESERVE_UNLINKED indicates the server will preserve
the open file if the client (or any other client) removes the file the open file if the client (or any other client) removes the file
as long as it is open. Furthermore, the server promises to as long as it is open. Furthermore, the server promises to
preserve the file through the grace period after server restart, preserve the file through the grace period after server restart,
thereby giving the client the opportunity to reclaim its open. thereby giving the client the opportunity to reclaim its open.
o OPEN4_RESULT_MAY_NOTIFY_LOCK indicates that the server may attempt o OPEN4_RESULT_MAY_NOTIFY_LOCK indicates that the server may attempt
CB_NOTIFY_LOCK callbacks for locks on this file. This flag is a CB_NOTIFY_LOCK callbacks for locks on this file. This flag is a
skipping to change at page 456, line 25 skipping to change at page 456, line 25
18.20.3. DESCRIPTION 18.20.3. 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.
PUTPUBFH also clears the current stateid. PUTPUBFH also clears the current stateid.
The public filehandle represents the concepts embodied in RFC2054 The public filehandle represents the concepts embodied in RFC2054
[41], RFC2055 [42], RFC2224 [51]. The intent for NFSv4.1 is that the [41], RFC2055 [42], and RFC2224 [52]. The intent for NFSv4.1 is that
public filehandle (represented by the PUTPUBFH operation) be used as the public filehandle (represented by the PUTPUBFH operation) be used
a method of providing WebNFS server compatibility with NFSv3. as a method of providing WebNFS server compatibility with 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 directory corresponding to
descendant of the root filehandle. the public filehandle MUST be a descendant of the directory
corresponding to the root filehandle.
See Section 16.2.3.1.1 for more details on the current filehandle. See Section 16.2.3.1.1 for more details on the current filehandle.
See Section 16.2.3.1.2 for more details on the current stateid. See Section 16.2.3.1.2 for more details on the current stateid.
18.20.4. IMPLEMENTATION 18.20.4. IMPLEMENTATION
Used as the second operator (after SEQUENCE) in an NFS request to set Used as the second operator (after SEQUENCE) in an NFS request to set
the context for file accessing operations that follow in the same the context for file accessing operations that follow in the same
COMPOUND request. COMPOUND request.
With the NFSv3 public filehandle, the client is able to specify With the NFSv3 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. RFC2224 [51] contains further discussion of the public filehandle. RFC2224 [52] contains further discussion of
the functionality. With NFSv4.1, that type of specification is not the functionality. With NFSv4.1, 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 RFC2224 [51] with respect Note that there are warnings mentioned in RFC2224 [52] with respect
to the use of absolute evaluation and the restrictions the server may to the use of absolute evaluation and the restrictions the server may
place on that evaluation with respect to how much of its namespace place on that evaluation with respect to how much of its namespace
has been made available. These same warnings apply to NFSv4.1. It has been made available. These same warnings apply to NFSv4.1. It
is likely, therefore that because of server implementation details, is likely, therefore that because of server implementation details,
an NFSv3 absolute public filehandle lookup may behave differently an NFSv3 absolute public filehandle lookup may behave differently
than an NFSv4.1 absolute resolution. than an NFSv4.1 absolute resolution.
There is a form of security negotiation as described in RFC2755 [52] There is a form of security negotiation as described in RFC2755 [53]
that uses the public filehandle and an overloading of the pathname. that uses the public filehandle and an overloading of the pathname.
This method is not available with NFSv4.1 as filehandles are not This method is not available with NFSv4.1 as filehandles are not
overloaded with special meaning and therefore do not provide the same overloaded with special meaning and therefore do not provide the same
framework as NFSv3. Clients should therefore use the security framework as NFSv3. Clients should therefore use the security
negotiation mechanisms described in Section 2.6. negotiation mechanisms described in Section 2.6.
18.21. Operation 24: PUTROOTFH - Set Root Filehandle 18.21. Operation 24: PUTROOTFH - Set Root Filehandle
18.21.1. ARGUMENTS 18.21.1. ARGUMENTS
skipping to change at page 466, line 5 skipping to change at page 466, line 5
the UTF-8 definition (and the server is enforcing UTF-8 encoding, see the UTF-8 definition (and the server is enforcing UTF-8 encoding, see
Section 14.4), the error NFS4ERR_INVAL will be returned. Section 14.4), the error NFS4ERR_INVAL will be returned.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.25.4. IMPLEMENTATION 18.25.4. 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() [27] in POSIX) to remove a directory, as system call (e.g. unlink() [26] in POSIX) to remove a directory, as
well as the converse (e.g. a rmdir() on a non-directory) because they well as the converse (e.g. a rmdir() on a non-directory) because they
knew the server would check the file type. NFSv4.1 REMOVE can be knew the server would check the file type. NFSv4.1 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.1 client's entry points from the unlink() and implementor of an NFSv4.1 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.
skipping to change at page 475, line 16 skipping to change at page 475, line 16
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 RFC1831 [3]), or RPCSEC_GSS (as defined in AUTH_SYS (as defined in RFC1831 [3]), or RPCSEC_GSS (as defined in
RFC2203 [4]). The field flavor can also be any other security flavor RFC2203 [4]). The field flavor can also be any other security flavor
registered with IANA. registered with IANA.
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. The same is true of many (if not most) information is returned. The same is true of many (if not most)
other security flavors, including AUTH_DH. For a return value of other security flavors, including AUTH_DH. For a return value of
RPCSEC_GSS, a security triple is returned that contains the mechanism RPCSEC_GSS, a security triple is returned that contains the mechanism
object identifier (OID, as defined in RFC2743 [8]), the quality of object identifier (OID, as defined in RFC2743 [7]), the quality of
protection (as defined in RFC2743 [8]) and the service type (as protection (as defined in RFC2743 [7]) and the service type (as
defined in RFC2203 [4]). It is possible for SECINFO to return defined in RFC2203 [4]). It is possible for SECINFO to return
multiple entries with flavor equal to RPCSEC_GSS with different multiple entries with flavor equal to RPCSEC_GSS with different
security triple values. security triple values.
On success, the current filehandle is consumed (see On success, the current filehandle is consumed (see
Section 2.6.3.1.1.8), and if the next operation after SECINFO tries Section 2.6.3.1.1.8), and if the next operation after SECINFO tries
to use the current filehandle, that operation will fail with the to use the current filehandle, that operation will fail with the
status NFS4ERR_NOFILEHANDLE. status NFS4ERR_NOFILEHANDLE.
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
skipping to change at page 499, line 33 skipping to change at page 499, line 33
spo_must_allow and the server agrees. spo_must_allow and the server agrees.
The SP4_SSV protection parameters also have: The SP4_SSV protection parameters also have:
ssp_hash_algs: ssp_hash_algs:
This is the set of algorithms the client supports for the purpose This is the set of algorithms the client supports for the purpose
of computing the digests needed for the internal SSV GSS mechanism of computing the digests needed for the internal SSV GSS mechanism
and for the SET_SSV operation. Each algorithm is specified as an and for the SET_SSV operation. Each algorithm is specified as an
object identifier (OID). The REQUIRED algorithms for a server are object identifier (OID). The REQUIRED algorithms for a server are
id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512 [28]. The id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512 [27]. The
algorithm the server selects among the set is indicated in algorithm the server selects among the set is indicated in
spi_hash_alg, a field of spr_ssv_prot_info. The field spi_hash_alg, a field of spr_ssv_prot_info. The field
spi_hash_alg is an index into the array ssp_hash_algs. If the spi_hash_alg is an index into the array ssp_hash_algs. If the
server does not support any of the offered algorithms, it returns server does not support any of the offered algorithms, it returns
NFS4ERR_HASH_ALG_UNSUPP. If ssp_hash_algs is empty, the server NFS4ERR_HASH_ALG_UNSUPP. If ssp_hash_algs is empty, the server
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
ssp_encr_algs: ssp_encr_algs:
This is the set of algorithms the client supports for the purpose This is the set of algorithms the client supports for the purpose
of providing privacy protection for the internal SSV GSS of providing privacy protection for the internal SSV GSS
mechanism. Each algorithm is specified as an OID. The REQUIRED mechanism. Each algorithm is specified as an OID. The REQUIRED
algorithm for a server is id-aes256-CBC. The RECOMMENDED algorithm for a server is id-aes256-CBC. The RECOMMENDED
algorithms are id-aes192-CBC and id-aes128-CBC [29]. The selected algorithms are id-aes192-CBC and id-aes128-CBC [28]. The selected
algorithm is returned in spi_encr_alg, an index into algorithm is returned in spi_encr_alg, an index into
ssp_encr_algs. If the server does not support any of the offered ssp_encr_algs. If the server does not support any of the offered
algorithms, it returns NFS4ERR_ENCR_ALG_UNSUPP. If ssp_encr_algs algorithms, it returns NFS4ERR_ENCR_ALG_UNSUPP. If ssp_encr_algs
is empty, the server MUST return NFS4ERR_INVAL. is empty, the server MUST return NFS4ERR_INVAL.
ssp_window: ssp_window:
This is the number of SSV versions the client wants the server to This is the number of SSV versions the client wants the server to
maintain (i.e. each successful call to SET_SSV produces a new maintain (i.e. each successful call to SET_SSV produces a new
version of the SSV). If ssp_window is zero, the server MUST version of the SSV). If ssp_window is zero, the server MUST
skipping to change at page 510, line 19 skipping to change at page 510, line 19
If CREATE_SESSION4_FLAG_CONN_RDMA is set in csa_flags, and if If CREATE_SESSION4_FLAG_CONN_RDMA is set in csa_flags, and if
the connection CREATE_SESSION is called over is currently in the connection CREATE_SESSION is called over is currently in
non-RDMA mode, but has the capability to operate in RDMA mode, non-RDMA mode, but has the capability to operate in RDMA mode,
then client is requesting the server agree to "step up" to RDMA then client is requesting the server agree to "step up" to RDMA
mode on the connection. The server sets mode on the connection. The server sets
CREATE_SESSION4_FLAG_CONN_RDMA in the result field csr_flags if CREATE_SESSION4_FLAG_CONN_RDMA in the result field csr_flags if
it agrees. If CREATE_SESSION4_FLAG_CONN_RDMA is not set in it agrees. If CREATE_SESSION4_FLAG_CONN_RDMA is not set in
csa_flags, then CREATE_SESSION4_FLAG_CONN_RDMA MUST NOT be set csa_flags, then CREATE_SESSION4_FLAG_CONN_RDMA MUST NOT be set
in csr_flags. Note that once the server agrees to step up, it in csr_flags. Note that once the server agrees to step up, it
and the client MUST exchange all future traffic on the and the client MUST exchange all future traffic on the
connection with RPC RDMA framing and not Record Marking ([9]). connection with RPC RDMA framing and not Record Marking ([8]).
csa_fore_chan_attrs, csa_fore_chan_attrs: csa_fore_chan_attrs, csa_fore_chan_attrs:
The csa_fore_chan_attrs and csa_back_chan_attrs fields apply to The csa_fore_chan_attrs and csa_back_chan_attrs fields apply to
attributes of the fore channel (which conveys requests originating attributes of the fore channel (which conveys requests originating
from the client to the server), and the backchannel (the channel from the client to the server), and the backchannel (the channel
that conveys callback requests originating from the server to the that conveys callback requests originating from the server to the
client), respectively. The results are in corresponding client), respectively. The results are in corresponding
structures called csr_fore_chan_attrs and csr_back_chan_attrs. structures called csr_fore_chan_attrs and csr_back_chan_attrs.
The results establish attributes for each channel, and on all The results establish attributes for each channel, and on all
skipping to change at page 552, line 34 skipping to change at page 552, line 34
This operation is used to update the SSV for a client ID. Before This operation is used to update the SSV for a client ID. Before
SET_SSV is called the first time on a client ID, the SSV is zero (0). SET_SSV is called the first time on a client ID, the SSV is zero (0).
The SSV is the key used for the SSV GSS mechanism (Section 2.10.9) The SSV is the key used for the SSV GSS mechanism (Section 2.10.9)
SET_SSV MUST be preceded by a SEQUENCE operation in the same SET_SSV MUST be preceded by a SEQUENCE operation in the same
COMPOUND. It MUST NOT be used if the client did not opt for SP4_SSV COMPOUND. It MUST NOT be used if the client did not opt for SP4_SSV
state protection when the client ID was created (see Section 18.35); state protection when the client ID was created (see Section 18.35);
the server returns NFS4ERR_INVAL in that case. the server returns NFS4ERR_INVAL in that case.
The field ssa_digest is computed as the output of the HMAC RFC2104 The field ssa_digest is computed as the output of the HMAC RFC2104
[12] using the subkey derived from the SSV4_SUBKEY_MIC_I2T and [11] using the subkey derived from the SSV4_SUBKEY_MIC_I2T and
current SSV as the key (See Section 2.10.9 for a description of current SSV as the key (See Section 2.10.9 for a description of
subkeys), and an XDR encoded value of data type ssa_digest_input4. subkeys), and an XDR encoded value of data type ssa_digest_input4.
The field sdi_seqargs is equal to the arguments of the SEQUENCE The field sdi_seqargs is equal to the arguments of the SEQUENCE
operation for the COMPOUND procedure that SET_SSV is within. operation for the COMPOUND procedure that SET_SSV is within.
The argument ssa_ssv is XORed with the current SSV to produce the new The argument ssa_ssv is XORed with the current SSV to produce the new
SSV. The argument ssa_ssv SHOULD be generated randomly. SSV. The argument ssa_ssv SHOULD be generated randomly.
In the response, ssr_digest is the output of the HMAC using the In the response, ssr_digest is the output of the HMAC using the
subkey derived from SSV4_SUBKEY_MIC_T2I and new SSV as the key, and subkey derived from SSV4_SUBKEY_MIC_T2I and new SSV as the key, and
skipping to change at page 591, line 10 skipping to change at page 591, line 10
responses came from the same network address and port number that the responses came from the same network address and port number that the
request was sent to. While such a model is easy to implement and request was sent to. While such a model is easy to implement and
simple to deploy and use, it is unsafe. Thus, NFSv4.1 simple to deploy and use, it is unsafe. Thus, NFSv4.1
implementations are REQUIRED to support a security model that uses implementations are REQUIRED to support a security model that uses
end to end authentication, where an end-user on a client mutually end to end authentication, where an end-user on a client mutually
authenticates (via cryptographic schemes that do not expose passwords authenticates (via cryptographic schemes that do not expose passwords
or keys in the clear on the network) to a principal on an NFS server. or keys in the clear on the network) to a principal on an NFS server.
Consideration is also be given to the integrity and privacy of NFS Consideration is also be given to the integrity and privacy of NFS
requests and responses. The issues of end to end mutual requests and responses. The issues of end to end mutual
authentication, integrity, and privacy are discussed authentication, integrity, and privacy are discussed
Section 2.2.1.1.1. Section 2.2.1.1.1. There are specific considerations when using
Kerberos V5 as described in Section 2.2.1.1.1.2.1.1.
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.1 clients and servers. However, AUTH_SYS can be used by NFSv4.1 clients and servers. However,
AUTH_SYS is merely an OPTIONAL security flavor in NFSv4.1, and so AUTH_SYS is merely an OPTIONAL security flavor in NFSv4.1, 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.1 implementations and/or reduction of CPU utilization, users of NFSv4.1 implementations
may opt to not use security mechanisms that enable integrity may opt 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 592, line 7 skipping to change at page 592, line 7
attacker modifies the results to cause the client migrate its attacker modifies the results to cause the client migrate its
traffic to a server controlled by the attacker. traffic to a server controlled by the attacker.
Relative to previous NFS versions, NFSv4.1 has additional security Relative to previous NFS versions, NFSv4.1 has additional security
considerations for pNFS (see Section 12.9 and Section 13.12), locking considerations for pNFS (see Section 12.9 and Section 13.12), locking
and session state (see Section 2.10.8.3), and state recovery during and session state (see Section 2.10.8.3), and state recovery during
grace period (see Section 8.4.2.1.1). grace period (see Section 8.4.2.1.1).
22. IANA Considerations 22. IANA Considerations
This section uses terms that are defined in [53]. This section uses terms that are defined in [54].
22.1. Named Attribute Definitions 22.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.1 protocol supports the association of a file with zero or The NFSv4.1 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 592, line 30 skipping to change at page 592, line 30
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 [53]. The policy for each assignment is basis, per section 4.1 of [54]. The policy for each assignment is
Specification Required, per section 4.1 of [53]. Specification Required, per section 4.1 of [54].
Under the NFSv4.1 specification, the name of a named attribute can in Under the NFSv4.1 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4.1 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4.1
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 593, line 42 skipping to change at page 593, line 42
The potential exists for new notification types to be added to the The potential exists for new notification types to be added to the
CB_NOTIFY_DEVICEID operation Section 20.12. This can be done via CB_NOTIFY_DEVICEID operation Section 20.12. This can be done via
changes to the operations that register notifications, or by adding changes to the operations that register notifications, or by adding
new operations to NFSv4. This requires a new minor version of NFSv4, new operations to NFSv4. This requires a new minor version of NFSv4,
and requires a standards track document from IETF. Another way to and requires a standards track document from IETF. Another way to
add a notification is to specify a new layout type (see add a notification is to specify a new layout type (see
Section 22.4). Section 22.4).
Hence all assignments to the registry are made on a Standards Action Hence all assignments to the registry are made on a Standards Action
basis per section 4.1 of [53], with Expert Review required. basis per section 4.1 of [54], with Expert Review required.
The registry is a list of assignments, each containing five fields The registry is a list of assignments, each containing five fields
per assignment. per assignment.
1. The name of the notification type. This name must have the 1. The name of the notification type. This name must have the
prefix: "NOTIFY_DEVICEID4_". This name must be unique. prefix: "NOTIFY_DEVICEID4_". This name must be unique.
2. The value of the notification. IANA will assign this number, and 2. The value of the notification. IANA will assign this number, and
the request from the registrant will use TBD1 instead of an the request from the registrant will use TBD1 instead of an
actual value. IANA MUST use a whole number which can be no actual value. IANA MUST use a whole number which can be no
higher than 2^32-1, and should be the next available value. The higher than 2^32-1, and should be the next available value. The
value assigned must be unique. A Designated Expert must be used value assigned must be unique. A Designated Expert must be used
to ensure that when the name of the notification type and its to ensure that when the name of the notification type and its
value are added to the NFSv4.1 notify_deviceid_type4 enumerated value are added to the NFSv4.1 notify_deviceid_type4 enumerated
data type in the NFSv4.1 XDR description ([13]), the result data type in the NFSv4.1 XDR description ([12]), the result
continues to be a valid XDR description. continues to be a valid XDR description.
3. The Standards Track RFC(s) that describe the notification. If 3. The Standards Track RFC(s) that describe the notification. If
the RFC(s) have not yet been published, the registrant will use the RFC(s) have not yet been published, the registrant will use
RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
4. How the RFC introduces the notification. This is indicated by a 4. How the RFC introduces the notification. This is indicated by a
single US-ASCII value. If the value is N, it means a minor single US-ASCII value. If the value is N, it means a minor
revision to the NFSv4 protocol. If the value is L, it means a revision to the NFSv4 protocol. If the value is L, it means a
new pNFS layout type. Other values can be used with IESG new pNFS layout type. Other values can be used with IESG
skipping to change at page 595, line 14 skipping to change at page 595, line 14
The potential exists for new object types to be added to the The potential exists for new object types to be added to the
CB_RECALL_ANY operation (see Section 20.6). This can be done via CB_RECALL_ANY operation (see Section 20.6). This can be done via
changes to the operations that add recallable types, or by adding new changes to the operations that add recallable types, or by adding new
operations to NFSv4. This requires a new minor version of NFSv4, and operations to NFSv4. This requires a new minor version of NFSv4, and
requires a standards track document from IETF. Another way to add a requires a standards track document from IETF. Another way to add a
new recallable object is to specify a new layout type (see new recallable object is to specify a new layout type (see
Section 22.4). Section 22.4).
All assignments to the registry are made on a Standards Action basis All assignments to the registry are made on a Standards Action basis
per section 4.1 of [53], with Expert Review required. per section 4.1 of [54], with Expert Review required.
Recallable object types are 32 bit unsigned numbers. There are no Recallable object types are 32 bit unsigned numbers. There are no
Reserved values. Values in the range 12 through 15, inclusive, are Reserved values. Values in the range 12 through 15, inclusive, are
for Private Use. for Private Use.
The registry is a list of assignments, each containing five fields The registry is a list of assignments, each containing five fields
per assignment. per assignment.
1. The name of the recallable object type. This name must have the 1. The name of the recallable object type. This name must have the
prefix: "RCA4_TYPE_MASK_". The name must be unique. prefix: "RCA4_TYPE_MASK_". The name must be unique.
2. The value of the recallable object type. IANA will assign this 2. The value of the recallable object type. IANA will assign this
number, and the request from the registrant will use TBD1 instead number, and the request from the registrant will use TBD1 instead
of an actual value. IANA MUST use a whole number which can be no of an actual value. IANA MUST use a whole number which can be no
higher than 2^32-1, and should be the next available value. The higher than 2^32-1, and should be the next available value. The
value must be unique. A Designated Expert must be used to ensure value must be unique. A Designated Expert must be used to ensure
that when the name of the recallable type and its value are added that when the name of the recallable type and its value are added
to the NFSv4 XDR description [13], the result continues to be a to the NFSv4 XDR description [12], the result continues to be a
valid XDR description. valid XDR description.
3. The Standards Track RFC(s) that describe the recallable object 3. The Standards Track RFC(s) that describe the recallable object
type. If the RFC(s) have not yet been published, the registrant type. If the RFC(s) have not yet been published, the registrant
will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
4. How the RFC introduces the recallable object type. This is 4. How the RFC introduces the recallable object type. This is
indicated by a single US-ASCII value. If the value is N, it indicated by a single US-ASCII value. If the value is N, it
means a minor revision to the NFSv4 protocol. If the value is L, means a minor revision to the NFSv4 protocol. If the value is L,
it means a new pNFS layout type. Other values can be used with it means a new pNFS layout type. Other values can be used with
skipping to change at page 596, line 52 skipping to change at page 596, line 52
The registry is a list of assignments, each containing five fields. The registry is a list of assignments, each containing five fields.
1. The name of the layout type. This name must have the prefix: 1. The name of the layout type. This name must have the prefix:
"LAYOUT4_". The name must be unique. "LAYOUT4_". The name must be unique.
2. The value of the layout type. IANA will assign this number, and 2. The value of the layout type. IANA will assign this number, and
the request from the registrant will use TBD1 instead of an the request from the registrant will use TBD1 instead of an
actual value. The value assigned must be unique. A Designated actual value. The value assigned must be unique. A Designated
Expert must be used to ensure that when the name of the layout Expert must be used to ensure that when the name of the layout
type and its value are added to the NFSv4.1 layouttype4 type and its value are added to the NFSv4.1 layouttype4
enumerated data type in the NFSv4.1 XDR description ([13]), the enumerated data type in the NFSv4.1 XDR description ([12]), the
result continues to be a valid XDR description. result continues to be a valid XDR description.
3. The Standards Track RFC(s) that describe the notification. If 3. The Standards Track RFC(s) that describe the notification. If
the RFC(s) have not yet been published, the registrant will use the RFC(s) have not yet been published, the registrant will use
RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
Collectively, the RFC(s) must adhere to the guidelines listed in Collectively, the RFC(s) must adhere to the guidelines listed in
Section 22.4.3. Section 22.4.3.
4. How the RFC introduces the layout type. This is indicated by a 4. How the RFC introduces the layout type. This is indicated by a
single US-ASCII value. If the value is N, it means a minor single US-ASCII value. If the value is N, it means a minor
skipping to change at page 602, line 48 skipping to change at page 602, line 48
[3] Srinivasan, R., "RPC: Remote Procedure Call Protocol [3] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995. Specification Version 2", RFC 1831, August 1995.
[4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version [5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version
5 Generic Security Service Application Program Interface (GSS- 5 Generic Security Service Application Program Interface (GSS-
API) Mechanism Version 2", RFC 4121, July 2005. API) Mechanism Version 2", RFC 4121, July 2005.
[6] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism [6] The Open Group, "Section 3.191 of Chapter 3 of Base Definitions
Using SPKM", RFC 2847, June 2000.
[7] The Open Group, "Section 3.191 of Chapter 3 of Base Definitions
of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, of The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[8] Linn, J., "Generic Security Service Application Program [7] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[9] Talpey, T. and B. Callaghan, "Remote Direct Memory Access [8] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
Transport for Remote Procedure Call", Transport for Remote Procedure Call",
draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008. draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008.
[10] Talpey, T., Callaghan, B., and I. Property, "NFS Direct Data [9] Talpey, T., Callaghan, B., and I. Property, "NFS Direct Data
Placement", draft-ietf-nfsv4-nfsdirect-08 (work in progress), Placement", draft-ietf-nfsv4-nfsdirect-08 (work in progress),
April 2008. April 2008.
[11] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia, [10] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia,
"A Remote Direct Memory Access Protocol Specification", "A Remote Direct Memory Access Protocol Specification",
RFC 5040, October 2007. RFC 5040, October 2007.
[12] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[13] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1 [12] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1
XDR Description", draft-ietf-nfsv4-minorversion1-dot-x-10 (work XDR Description", draft-ietf-nfsv4-minorversion1-dot-x-11 (work
in progress), Dec 2008. in progress), Dec 2008.
[14] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions [13] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions
of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, of The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[15] Eisler, M., "IANA Considerations for RPC Net Identifiers and [14] Eisler, M., "IANA Considerations for RPC Net Identifiers and
Universal Address Formats", draft-ietf-nfsv4-rpc-netid-04 (work Universal Address Formats", draft-ietf-nfsv4-rpc-netid-04 (work
in progress), December 2008. in progress), December 2008.
[16] The Open Group, "Section 'read()' of System Interfaces of The [15] The Open Group, "Section 'read()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[17] The Open Group, "Section 'readdir()' of System Interfaces of [16] The Open Group, "Section 'readdir()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1, The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[18] The Open Group, "Section 'write()' of System Interfaces of The [17] The Open Group, "Section 'write()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[19] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [18] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
[20] The Open Group, "Section 'chmod()' of System Interfaces of The [19] The Open Group, "Section 'chmod()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[21] International Organization for Standardization, "Information [20] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS) Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", - Part 1: Architecture and Basic Multilingual Plane",
ISO Standard 10646-1, May 1993. ISO Standard 10646-1, May 1993.
[22] Alvestrand, H., "IETF Policy on Character Sets and Languages", [21] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[23] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile [22] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", RFC 3491, for Internationalized Domain Names (IDN)", RFC 3491,
March 2003. March 2003.
[24] The Open Group, "Section 'fcntl()' of System Interfaces of The [23] The Open Group, "Section 'fcntl()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[25] The Open Group, "Section 'fsync()' of System Interfaces of The [24] The Open Group, "Section 'fsync()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[26] The Open Group, "Section 'getpwnam()' of System Interfaces of [25] The Open Group, "Section 'getpwnam()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1, The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[27] The Open Group, "Section 'unlink()' of System Interfaces of The [26] The Open Group, "Section 'unlink()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[28] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms [27] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005. Revocation List (CRL) Profile", RFC 4055, June 2005.
[29] National Institute of Standards and Technology, "Cryptographic [28] National Institute of Standards and Technology, "Cryptographic
Algorithm Object Registration", URL http://csrc.nist.gov/ Algorithm Object Registration", URL http://csrc.nist.gov/
groups/ST/crypto_apps_infra/csor/algorithms.html, groups/ST/crypto_apps_infra/csor/algorithms.html,
November 2007. November 2007.
23.2. Informative References 23.2. Informative References
[30] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [29] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS) C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003. version 4 Protocol", RFC 3530, April 2003.
[31] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 [30] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995. Protocol Specification", RFC 1813, June 1995.
[31] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM", RFC 2847, June 2000.
[32] Eisler, M., "NFS Version 2 and Version 3 Security Issues and [32] Eisler, M., "NFS Version 2 and Version 3 Security Issues and
the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999. RFC 2623, June 1999.
[33] Juszczak, C., "Improving the Performance and Correctness of an [33] Juszczak, C., "Improving the Performance and Correctness of an
NFS Server", USENIX Conference Proceedings , June 1990. NFS Server", USENIX Conference Proceedings , June 1990.
[34] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [34] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
skipping to change at page 606, line 5 skipping to change at page 606, line 5
[40] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume [40] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume
Layout", draft-ietf-nfsv4-pnfs-block-10 (work in progress), Layout", draft-ietf-nfsv4-pnfs-block-10 (work in progress),
November 2008. November 2008.
[41] Callaghan, B., "WebNFS Client Specification", RFC 2054, [41] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[42] Callaghan, B., "WebNFS Server Specification", RFC 2055, [42] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[43] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [43] IESG, "IESG Processing of RFC Errata for the IETF Stream", URL
http://www.ietf.org/IESG/STATEMENTS/
iesg-statement-07-30-2008.txt, July 2008.
[44] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999. June 1999.
[44] The Open Group, "Protocols for Interworking: XNFS, Version 3W, [45] The Open Group, "Protocols for Interworking: XNFS, Version 3W,
ISBN 1-85912-184-5", February 1998. ISBN 1-85912-184-5", February 1998.
[45] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [46] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking 2(2), Routing Messages", IEEE/ACM Transactions on Networking 2(2),
pp. 122-136, April 1994. pp. 122-136, April 1994.
[46] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. [47] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.
Zeidner, "Internet Small Computer Systems Interface (iSCSI)", Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
RFC 3720, April 2004. RFC 3720, April 2004.
[47] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version [48] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version
(FCP-2)", ANSI/INCITS 350-2003, Oct 2003. (FCP-2)", ANSI/INCITS 350-2003, Oct 2003.
[48] Weber, R., "Object-Based Storage Device Commands (OSD)", ANSI/ [49] Weber, R., "Object-Based Storage Device Commands (OSD)", ANSI/
INCITS 400-2004, July 2004, INCITS 400-2004, July 2004,
<http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>. <http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>.
[49] Carns, P., Ligon III, W., Ross, R., and R. Thakur, "PVFS: A [50] Carns, P., Ligon III, W., Ross, R., and R. Thakur, "PVFS: A
Parallel File System for Linux Clusters.", Proceedings of the Parallel File System for Linux Clusters.", Proceedings of the
4th Annual Linux Showcase and Conference , 2000. 4th Annual Linux Showcase and Conference , 2000.
[50] The Open Group, "The Open Group Base Specifications Issue 6, [51] The Open Group, "The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition", 2004. IEEE Std 1003.1, 2004 Edition", 2004.
[51] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [52] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[52] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation [53] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation
for WebNFS", RFC 2755, January 2000. for WebNFS", RFC 2755, January 2000.
[53] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [54] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The initial drafts for the SECINFO extensions were edited by Mike The initial drafts for the SECINFO extensions were edited by Mike
Eisler with contributions from Peng Dai, Sergey Klyushin, and Carl Eisler with contributions from Peng Dai, Sergey Klyushin, and Carl
Burnett. Burnett.
The initial drafts for the SESSIONS extensions were edited by Tom The initial drafts for the SESSIONS extensions were edited by Tom
Talpey, Spencer Shepler, Jon Bauman with contributions from Charles Talpey, Spencer Shepler, Jon Bauman with contributions from Charles
skipping to change at page 608, line 40 skipping to change at page 608, line 45
Iyer, Suchit Kaura, Trond Myklebust, Anatoly Pinchuk, Spencer Iyer, Suchit Kaura, Trond Myklebust, Anatoly Pinchuk, Spencer
Shepler, Renu Tewari, Lisa Week, and Brent Welch. Shepler, Renu Tewari, Lisa Week, and Brent Welch.
A review team worked together to generate the tables of assignments A review team worked together to generate the tables of assignments
of error sets to operations and make sure that each such assignment of error sets to operations and make sure that each such assignment
had two or more people validating it. Participating in the process had two or more people validating it. Participating in the process
were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert
Gordon, Trond Myklebust, Dave Noveck, Spencer Shepler, Tom Talpey, Gordon, Trond Myklebust, Dave Noveck, Spencer Shepler, Tom Talpey,
Amy Weaver, and Lisa Week. Amy Weaver, and Lisa Week.
David Black, Scott Bradner, Lisa Dusseault, and Lars Eggert provided Jari Arkko, David Black, Scott Bradner, Lisa Dusseault, Lars Eggert,
valuable review and guidance. Chris Newman, and Tim Polk provided valuable review and guidance.
Others who provided comments include: Jason Goldschmidt, Vijay K. Others who provided comments include: Jason Goldschmidt, Vijay K.
Gurbani, James Lentini, Anshul Madan, Archana Ramani, Jim Rees, Gurbani, James Lentini, Anshul Madan, Archana Ramani, Jim Rees,
Mahesh Siddheshwar, and Sunil Bhargo. Mahesh Siddheshwar, and Sunil Bhargo.
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]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD20 with RFCyyyy where yyyy is the replace all occurrences of RFCTBD20 with RFCyyyy where yyyy is the
RFC number of the document referenced in [40]] RFC number of the document referenced in [40]]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD30 with RFCzzzz where zzzz is the replace all occurrences of RFCTBD30 with RFCzzzz where zzzz is the
skipping to change at page 609, line 16 skipping to change at page 609, line 22
RFC number of this document] RFC number of this document]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD20 with RFCyyyy where yyyy is the replace all occurrences of RFCTBD20 with RFCyyyy where yyyy is the
RFC number of the document referenced in [40]] RFC number of the document referenced in [40]]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD30 with RFCzzzz where zzzz is the replace all occurrences of RFCTBD30 with RFCzzzz where zzzz is the
RFC number of the document referenced in [39]] RFC number of the document referenced in [39]]
[RFC Editor: prior to publishing this document as an RFC, please
ensure all section references to [14], including the reference from
Section 3.3.9 are accurate if document referenced by [14] has been
finalized for RFC publication. If not finalized for publication,
please remove section number references to [14].
Authors' Addresses Authors' Addresses
Spencer Shepler Spencer Shepler
Storspeed, Inc. Storspeed, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
Austin, TX 78750 Austin, TX 78750
USA USA
Phone: +1-512-402-5811 ext 8530 Phone: +1-512-402-5811 ext 8530
Email: shepler@storspeed.com Email: shepler@storspeed.com
 End of changes. 139 change blocks. 
206 lines changed or deleted 229 lines changed or added

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