draft-ietf-nfsv4-rfc3530bis-15.txt   draft-ietf-nfsv4-rfc3530bis-16.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track D. Noveck, Ed. Intended status: Standards Track D. Noveck, Ed.
Expires: March 10, 2012 EMC Expires: May 2, 2012 EMC
September 07, 2011 October 30, 2011
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-15.txt draft-ietf-nfsv4-rfc3530bis-16.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed filesystem The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4 version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course, caching, and internationalization have been added. Of course,
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 10, 2012. This Internet-Draft will expire on May 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12 1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12
1.5.2. Procedure and Operation Structure . . . . . . . . . 12 1.5.2. Procedure and Operation Structure . . . . . . . . . 12
1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13 1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15 1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15
1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15 1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15
1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 1.5.6. Client Caching and Delegation . . . . . . . . . . . 15
1.6. General Definitions . . . . . . . . . . . . . . . . . . 16 1.6. General Definitions . . . . . . . . . . . . . . . . . . 16
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 25 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 25 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 26 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 27 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 27 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 27
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 28
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 30 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30
4.2.1. General Properties of a Filehandle . . . . . . . . . 31 4.2.1. General Properties of a Filehandle . . . . . . . . . 31
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 31
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32
4.2.4. One Method of Constructing a Volatile Filehandle . . 34 4.2.4. One Method of Constructing a Volatile Filehandle . . 33
4.3. Client Recovery from Filehandle Expiration . . . . . . . 34 4.3. Client Recovery from Filehandle Expiration . . . . . . . 33
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 35 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 35
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36
5.4. Classification of Attributes . . . . . . . . . . . . . . 38 5.4. Classification of Attributes . . . . . . . . . . . . . . 38
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 38
5.6. REQUIRED Attributes - List and Definition References . . 39 5.6. REQUIRED Attributes - List and Definition References . . 39
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 40 References . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41
5.8.2. Definitions of Uncategorized RECOMMENDED 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 43 Attributes . . . . . . . . . . . . . . . . . . . . . 43
5.9. Interpreting owner and owner_group . . . . . . . . . . . 49 5.9. Interpreting owner and owner_group . . . . . . . . . . . 49
5.10. Character Case Attributes . . . . . . . . . . . . . . . 52 5.10. Character Case Attributes . . . . . . . . . . . . . . . 52
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 52 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 52
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 53 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 53
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 53 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 53
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 68
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 72 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 72
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72
7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 74 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 74
7.1. Location Attributes . . . . . . . . . . . . . . . . . . 74 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 74
7.2. File System Presence or Absence . . . . . . . . . . . . 75 7.2. File System Presence or Absence . . . . . . . . . . . . 75
skipping to change at page 7, line 50 skipping to change at page 7, line 50
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 270 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 270
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 274 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 274
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 275 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 275
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 277 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 277
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 279 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 279
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 280 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 280
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 281 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 281
15.33. Operation 33: SECINFO - Obtain Available Security . . . 282 15.33. Operation 33: SECINFO - Obtain Available Security . . . 282
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 285 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 285
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 288 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 288
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 291 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 292
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 295 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 295
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 296 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 297
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 300 State . . . . . . . . . . . . . . . . . . . . . . . . . 301
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 301 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 302
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 302 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 303
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 302 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 303
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 303 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 303
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 305 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 305
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 306 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 306
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 307 Operation . . . . . . . . . . . . . . . . . . . . . 307
17. Security Considerations . . . . . . . . . . . . . . . . . . . 307 17. Security Considerations . . . . . . . . . . . . . . . . . . . 308
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 309 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 310
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 309 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 310
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 310 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 311
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 310 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 311
18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 310 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 311
18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 311 19.1. Normative References . . . . . . . . . . . . . . . . . . 311
18.2.2. Updating Registrations . . . . . . . . . . . . . . . 311
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 312
19.1. Normative References . . . . . . . . . . . . . . . . . . 312
19.2. Informative References . . . . . . . . . . . . . . . . . 312 19.2. Informative References . . . . . . . . . . . . . . . . . 312
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 315 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 314
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 315 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 315
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 316 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 315
1. Introduction 1. Introduction
1.1. Changes since RFC 3530 1.1. Changes since RFC 3530
This document, together with the companion XDR description document This document, together with the companion XDR description document
[2], obsoletes RFC 3530 [10] as the authoritative document describing [2], obsoletes RFC 3530 [11] as the authoritative document describing
NFSv4. It does not introduce any over-the-wire protocol changes, in NFSv4. It does not introduce any over-the-wire protocol changes, in
the sense that previously valid requests requests remain valid. the sense that previously valid requests requests remain valid.
However, some requests previously defined as invalid, although not However, some requests previously defined as invalid, although not
generally rejected, are now explicitly allowed, in that generally rejected, are now explicitly allowed, in that
internationalization handling has been generalized and liberalized. internationalization handling has been generalized and liberalized.
The main changes from RFC 3530 are: The main changes from RFC 3530 are:
o The XDR definition has been moved to a companion document [2] o The XDR definition has been moved to a companion document [2]
o Updates for the latest IETF intellectual property statements o Updates for the latest IETF intellectual property statements
skipping to change at page 9, line 51 skipping to change at page 9, line 51
information to the new server if state has been migrated. information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network o A third edge case was added for Courtesy locks and network
partitions. partitions.
o The definition of stateid was strengthened. o The definition of stateid was strengthened.
1.2. Changes since RFC 3010 1.2. Changes since RFC 3010
This definition of the NFSv4 protocol replaces or obsoletes the This definition of the NFSv4 protocol replaces or obsoletes the
definition present in [11]. While portions of the two documents have definition present in [12]. While portions of the two documents have
remained the same, there have been substantive changes in others. remained the same, there have been substantive changes in others.
The changes made between [11] and this document represent The changes made between [12] and this document represent
implementation experience and further review of the protocol. While implementation experience and further review of the protocol. While
some modifications were made for ease of implementation or some modifications were made for ease of implementation or
clarification, most updates represent errors or situations where the clarification, most updates represent errors or situations where the
[11] definition were untenable. [12] definition were untenable.
The following list is not all inclusive of all changes but presents The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made: some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that and the lock_owner4 identifier would correspond to a process that
is locking a file. is locking a file.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
o Remove use of the pathname4 data type from LOOKUP and OPEN in o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect. operations to achieve the same effect.
o Clarification of the internationalization issues and adoption of o Clarification of the internationalization issues and adoption of
the new stringprep profile framework. the new stringprep profile framework.
1.3. NFS Version 4 Goals 1.3. NFS Version 4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The NFSv4 protocol is a further revision of the NFS protocol defined
already by versions 2 [12] and 3 [13]. It retains the essential already by versions 2 [13] and 3 [14]. It retains the essential
characteristics of previous versions: design for easy recovery, characteristics of previous versions: design for easy recovery,
independent of transport protocols, operating systems and independent of transport protocols, operating systems and
filesystems, simplicity, and good performance. The NFSv4 revision filesystems, simplicity, and good performance. The NFSv4 revision
has the following goals: has the following goals:
o Improved access and good performance on the Internet. o Improved access and good performance on the Internet.
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
authoritative. authoritative.
1.5. Overview of NFSv4 Features 1.5. Overview of NFSv4 Features
To provide a reasonable context for the reader, the major features of To provide a reasonable context for the reader, the major features of
NFSv4 protocol will be reviewed in brief. This will be done to NFSv4 protocol will be reviewed in brief. This will be done to
provide an appropriate context for both the reader who is familiar provide an appropriate context for both the reader who is familiar
with the previous versions of the NFS protocol and the reader that is with the previous versions of the NFS protocol and the reader that is
new to the NFS protocols. For the reader new to the NFS protocols, new to the NFS protocols. For the reader new to the NFS protocols,
some fundamental knowledge is still expected. The reader should be some fundamental knowledge is still expected. The reader should be
familiar with the XDR and RPC protocols as described in [4] and [14]. familiar with the XDR and RPC protocols as described in [4] and [15].
A basic knowledge of filesystems and distributed filesystems is A basic knowledge of filesystems and distributed filesystems is
expected as well. expected as well.
1.5.1. RPC and Security 1.5.1. RPC and Security
As with previous versions of NFS, the External Data Representation As with previous versions of NFS, the External Data Representation
(XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4
protocol are those defined in [4] and [14]. To meet end to end protocol are those defined in [4] and [15]. To meet end to end
security requirements, the RPCSEC_GSS framework [5] will be used to security requirements, the RPCSEC_GSS framework [5] will be used to
extend the basic RPC security. With the use of RPCSEC_GSS, various extend 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 NFS version 4 protocol. Kerberos V5 will be used as privacy to the NFS version 4 protocol. Kerberos V5 will be used as
described in [15] to provide one security framework. With the use of described in [16] to provide one security framework. With the use of
RPCSEC_GSS, other mechanisms may also be specified and used for NFS RPCSEC_GSS, other mechanisms may also be specified and used for NFS
version 4 security. version 4 security.
To enable in-band security negotiation, the NFSv4 protocol has added To enable in-band security negotiation, the NFSv4 protocol has added
a new operation which provides the client a method of querying the a new operation which provides the client a method of querying the
server about its policies regarding which security mechanisms must be server about its policies regarding which security mechanisms must be
used for access to the server's filesystem resources. With this, the used for access to the server's filesystem resources. With this, the
client can securely match the security mechanism that meets the client can securely match the security mechanism that meets the
policies specified at both the client and server. policies specified at both the client and server.
skipping to change at page 14, line 12 skipping to change at page 14, line 12
filehandle being provided by the server and can be prepared to deal filehandle being provided by the server and can be prepared to deal
with the semantics of each. with the semantics of each.
1.5.3.2. Attribute Types 1.5.3.2. Attribute Types
The NFSv4 protocol has a rich and extensible file object attribute The NFSv4 protocol has a rich and extensible file object attribute
structure, which is divided into REQUIRED, RECOMMENDED, and named structure, which is divided into REQUIRED, RECOMMENDED, and named
attributes (see Section 5). attributes (see Section 5).
Several (but not all) of the REQUIRED attributes are derived from the Several (but not all) of the REQUIRED attributes are derived from the
attributes of NFSv3 (see definition of the fattr3 data type in [13]). attributes of NFSv3 (see definition of the fattr3 data type in [14]).
An example of a REQUIRED attribute is the file object's type 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 the RECOMMENDED attributes is an acl. This attribute An example of the RECOMMENDED attributes is an acl. This attribute
defines an Access Control List (ACL) on a file object ((Section 6). defines an Access Control List (ACL) on a file object ((Section 6).
An ACL provides file access control beyond the model used in NFSv3. An ACL provides file access control beyond the model used in NFSv3.
The ACL definition allows for specification of specific sets of The ACL definition allows for specification of specific sets of
skipping to change at page 18, line 20 skipping to change at page 18, line 20
server for a specific open-owner or lock-owner/open-owner pair for server for a specific open-owner or lock-owner/open-owner pair for
a specific file and type of lock. a specific file and type of lock.
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
2. Protocol Data Types 2. Protocol Data Types
The syntax and semantics to describe the data types of the NFS The syntax and semantics to describe the data types of the NFS
version 4 protocol are defined in the XDR [14] and RPC [4] documents. version 4 protocol are defined in the XDR [15] and RPC [4] documents.
The next sections build upon the XDR data types to define types and The next sections build upon the XDR data types to define types and
structures specific to this protocol. structures specific to this protocol.
2.1. Basic Data Types 2.1. Basic Data Types
These are the base NFSv4 data types. These are the base NFSv4 data types.
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| Data Type | Definition | | Data Type | Definition |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
skipping to change at page 22, line 50 skipping to change at page 22, line 50
struct clientaddr4 { struct clientaddr4 {
/* see struct rpcb in RFC 1833 */ /* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */ string r_netid<>; /* network id */
string r_addr<>; /* universal address */ string r_addr<>; /* universal address */
}; };
The clientaddr4 structure is used as part of the SETCLIENTID The clientaddr4 structure is used as part of the SETCLIENTID
operation to either specify the address of the client that is using a operation to either specify the address of the client that is using a
client ID or as part of the callback registration. The r_netid and client ID or as part of the callback registration. The r_netid and
r_addr fields are specified in [16], but they are underspecified in r_addr fields respectively contain a netid and uaddr. The netid and
uaddr concepts are defined in [7]. The netid and uaddr formats for
[16] as far as what they should look like for specific protocols. TCP over IPv4 and TCP over IPv6 are defined in [7], specifically
Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4.
For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the
US-ASCII string:
h1.h2.h3.h4.p1.p2
The prefix, "h1.h2.h3.h4", is the standard textual form for
representing an IPv4 address, which is always four octets long.
Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
the first through fourth octets each converted to ASCII-decimal.
Assuming big-endian ordering, p1 and p2 are, respectively, the first
and second octets each converted to ASCII-decimal. For example, if a
host, in big-endian order, has an address of 0x0A010307 and there is
a service listening on, in big endian order, port 0x020F (decimal
527), then the complete universal address is "10.1.3.7.2.15".
For TCP over IPv4 the value of r_netid is the string "tcp". For UDP
over IPv4 the value of r_netid is the string "udp".
For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the
US-ASCII string:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way
as with universal addresses for TCP and UDP over IPv4. The prefix,
"x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for
representing an IPv6 address as defined in Section 2.2 of [17].
Additionally, the two alternative forms specified in Section 2.2 of
[17] are also acceptable.
For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP
over IPv6 the value of r_netid is the string "udp6".
2.2.11. cb_client4 2.2.11. cb_client4
struct cb_client4 { struct cb_client4 {
unsigned int cb_program; unsigned int cb_program;
clientaddr4 cb_location; clientaddr4 cb_location;
}; };
This structure is used by the client to inform the server of its call This structure is used by the client to inform the server of its call
back address; includes the program number and client address. back address; includes the program number and client address.
skipping to change at page 25, line 23 skipping to change at page 24, line 39
between the client and server. For the client, this data structure between the client and server. For the client, this data structure
is read-only. The server is required to increment the seqid field is read-only. The server is required to increment the seqid field
monotonically at each transition of the stateid. This is important monotonically at each transition of the stateid. This is important
since the client will inspect the seqid in OPEN stateids to determine since the client will inspect the seqid in OPEN stateids to determine
the order of OPEN processing done by the server. the order of OPEN processing done by the server.
3. RPC and Security Flavor 3. RPC and Security Flavor
The NFSv4 protocol is a Remote Procedure Call (RPC) application that The NFSv4 protocol is a Remote Procedure Call (RPC) application that
uses RPC version 2 and the corresponding eXternal Data Representation uses RPC version 2 and the corresponding eXternal Data Representation
(XDR) as defined in [4] and [14]. The RPCSEC_GSS security flavor as (XDR) as defined in [4] and [15]. The RPCSEC_GSS security flavor as
defined in [5] MUST be implemented as the mechanism to deliver defined in [5] MUST be implemented as the mechanism to deliver
stronger security for the NFSv4 protocol. However, deployment of stronger security for the NFSv4 protocol. However, deployment of
RPCSEC_GSS is optional. RPCSEC_GSS is optional.
3.1. Ports and Transports 3.1. Ports and Transports
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The Historically, NFSv2 and NFSv3 servers have resided on port 2049. The
registered port 2049 [18] for the NFS protocol SHOULD be the default registered port 2049 [17] for the NFS protocol SHOULD be the default
configuration. Using the registered port for NFS services means the configuration. Using the registered port for NFS services means the
NFS client will not need to use the RPC binding protocols as NFS client will not need to use the RPC binding protocols as
described in [16]; this will allow NFS to transit firewalls. described in [18]; this will allow NFS to transit firewalls.
Where an NFSv4 implementation supports operation over the IP network Where an NFSv4 implementation supports operation over the IP network
protocol, the supported transports between NFS and IP MUST be among protocol, the supported transports between NFS and IP MUST be among
the IETF-approved congestion control transport protocols, which the IETF-approved congestion control transport protocols, which
include TCP and SCTP. To enhance the possibilities for include TCP and SCTP. To enhance the possibilities for
interoperability, an NFSv4 implementation MUST support operation over interoperability, an NFSv4 implementation MUST support operation over
the TCP transport protocol, at least until such time as a standards the TCP transport protocol, at least until such time as a standards
track RFC revises this requirement to use a different IETF-approved track RFC revises this requirement to use a different IETF-approved
congestion control transport protocol. congestion control transport protocol.
If TCP is used as the transport, the client and server SHOULD use If TCP is used as the transport, the client and server SHOULD use
persistent connections. This will prevent the weakening of TCP's persistent connections. This will prevent the weakening of TCP's
congestion control via short lived connections and will improve congestion control via short lived connections and will improve
performance for the WAN environment by eliminating the need for SYN performance for the WAN environment by eliminating the need for SYN
handshakes. handshakes.
To date, all NFSv4 implementations are TCP based, i.e., there are
none for SCTP nor UDP. UDP by itself is not sufficient as a
transport for NFSv4, neither is UDP in combination with some other
mechanism (e.g., DCCP [19], NORM [20]).
As noted in Section 17, the authentication model for NFSv4 has moved As noted in Section 17, the authentication model for NFSv4 has moved
from machine-based to principal-based. However, this modification of from machine-based to principal-based. However, this modification of
the authentication model does not imply a technical requirement to the authentication model does not imply a technical requirement to
move the TCP connection management model from whole machine-based to move the TCP connection management model from whole machine-based to
one based on a per user model. In particular, NFS over TCP client one based on a per user model. In particular, NFS over TCP client
implementations have traditionally multiplexed traffic for multiple implementations have traditionally multiplexed traffic for multiple
users over a common TCP connection between an NFS client and server. users over a common TCP connection between an NFS client and server.
This has been true, regardless whether the NFS client is using This has been true, regardless whether the NFS client is using
AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS
over TCP server implementations have assumed such a model and thus over TCP server implementations have assumed such a model and thus
scale the implementation of TCP connection management in proportion scale the implementation of TCP connection management in proportion
to the number of expected client machines. It is intended that NFSv4 to the number of expected client machines. It is intended that NFSv4
will not modify this connection management model. NFSv4 clients that will not modify this connection management model. NFSv4 clients that
violate this assumption can expect scaling issues on the server and violate this assumption can expect scaling issues on the server and
hence reduced service. hence reduced service.
Note that for various timers, the client and server should avoid Note that for various timers, the client and server should avoid
inadvertent synchronization of those timers. For further discussion inadvertent synchronization of those timers. For further discussion
of the general issue refer to [19]. of the general issue refer to [21].
3.1.1. Client Retransmission Behavior 3.1.1. Client Retransmission Behavior
When processing a request received over a reliable transport such as When processing a request received over a reliable transport such as
TCP, the NFSv4 server MUST NOT silently drop the request, except if TCP, the NFSv4 server MUST NOT silently drop the request, except if
the transport connection has been broken. Given such a contract the transport connection has been broken. Given such a contract
between NFSv4 clients and servers, clients MUST NOT retry a request between NFSv4 clients and servers, clients MUST NOT retry a request
unless one or both of the following are true: unless one or both of the following are true:
o The transport connection has been broken o The transport connection has been broken
skipping to change at page 27, line 28 skipping to change at page 26, line 50
3.2.1. Security mechanisms for NFSv4 3.2.1. Security mechanisms for NFSv4
The use of RPCSEC_GSS requires selection of: mechanism, quality of The use of RPCSEC_GSS requires selection of: mechanism, quality of
protection, and service (authentication, integrity, privacy). The protection, and service (authentication, integrity, privacy). The
remainder of this document will refer to these three parameters of remainder of this document will refer to these three parameters of
the RPCSEC_GSS security as the security triple. the RPCSEC_GSS security as the security triple.
3.2.1.1. Kerberos V5 as a security triple 3.2.1.1. Kerberos V5 as a security triple
The Kerberos V5 GSS-API mechanism as described in [15] MUST be The Kerberos V5 GSS-API mechanism as described in [16] MUST be
implemented and provide the following security triples. implemented and provide the following security triples.
column descriptions: column descriptions:
1 == number of pseudo flavor 1 == number of pseudo flavor
2 == name of pseudo flavor 2 == name of pseudo flavor
3 == mechanism's OID 3 == mechanism's OID
4 == mechanism's algorithm(s) 4 == mechanism's algorithm(s)
5 == RPCSEC_GSS service 5 == RPCSEC_GSS service
skipping to change at page 28, line 8 skipping to change at page 27, line 29
and 56 bit DES and 56 bit DES
for privacy. for privacy.
Note that the pseudo flavor is presented here as a mapping aid to the Note that the pseudo flavor is presented here as a mapping aid to the
implementor. Because this NFS protocol includes a method to implementor. Because this NFS protocol includes a method to
negotiate security and it understands the GSS-API mechanism, the negotiate security and it understands the GSS-API mechanism, the
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 pseudo flavor is not needed. The pseudo flavor is needed for NFSv3
since the security negotiation is done via the MOUNT protocol. since the security negotiation is done via the MOUNT protocol.
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please
see [20]. see [22].
3.3. Security Negotiation 3.3. Security Negotiation
With the NFSv4 server potentially offering multiple security With the NFSv4 server potentially offering multiple security
mechanisms, the client needs a method to determine or negotiate which mechanisms, the client needs a method to determine or negotiate which
mechanism is to be used for its communication with the server. The mechanism is to be used for its communication with the server. The
NFS server may have multiple points within its filesystem name space NFS server may have multiple points within its filesystem name space
that are available for use by NFS clients. In turn the NFS server that are available for use by NFS clients. In turn the NFS server
may be configured such that each of these entry points may have may be configured such that each of these entry points may have
different or multiple security mechanisms in use. different or multiple security mechanisms in use.
skipping to change at page 30, line 17 skipping to change at page 29, line 34
The filehandle in the NFS protocol is a per server unique identifier The filehandle in the NFS protocol is a per server unique identifier
for a filesystem object. The contents of the filehandle are opaque for a filesystem object. The contents of the filehandle are opaque
to the client. Therefore, the server is responsible for translating to the client. Therefore, the server is responsible for translating
the filehandle to an internal representation of the filesystem the filehandle to an internal representation of the filesystem
object. object.
4.1. Obtaining the First Filehandle 4.1. Obtaining the First Filehandle
The operations of the NFS protocol are defined in terms of one or The operations of the NFS protocol are defined in terms of one or
more filehandles. Therefore, the client needs a filehandle to more filehandles. Therefore, the client needs a filehandle to
initiate communication with the server. With the NFSv2 protocol [12] initiate communication with the server. With the NFSv2 protocol [13]
and the NFSv3 protocol [13], there exists an ancillary protocol to and the NFSv3 protocol [14], there exists an ancillary protocol to
obtain this first filehandle. The MOUNT protocol, RPC program number obtain this first filehandle. The MOUNT protocol, RPC program number
100005, provides the mechanism of translating a string based 100005, provides the mechanism of translating a string based
filesystem path name to a filehandle which can then be used by the filesystem path name to a filehandle which can then be used by the
NFS protocols. 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 [21] and [22]. With the use of the filehandle was introduced in [23] and [24]. With the use of the
public filehandle in combination with the LOOKUP operation in the public filehandle in combination with the LOOKUP operation in the
NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT NFSv2 and NFSv3 protocols, 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 protocol will not use an ancillary protocol for Therefore, the NFSv4 protocol will not use an ancillary protocol for
translation from string based path names to a filehandle. Two translation from string based path names to a filehandle. Two
special filehandles will be used as starting points for the NFS special filehandles will be used as starting points for the NFS
client. client.
skipping to change at page 39, line 49 skipping to change at page 39, line 16
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the columns of the table are:
o Name: The name of attribute o Name: The name of attribute
o Id: The number assigned to the attribute. In the event of o Id: The number assigned to the attribute. In the event of
conflicts between the assigned number and [2], the latter is conflicts between the assigned number and [2], the latter is
likely authoritative, but should be resolved with Errata to this likely authoritative, but should be resolved with Errata to this
document and/or [2]. See [23] for the Errata process. document and/or [2]. See [25] 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 48, line 48 skipping to change at page 48, line 32
5.8.2.33. Attribute 47: time_access 5.8.2.33. Attribute 47: time_access
The time_access attribute represents the time of last access to the The time_access attribute represents the time of last access to the
object by a READ operation sent to the server. The notion of what is object by a READ operation sent to the server. The notion of what is
an "access" depends on the server's operating environment and/or the an "access" depends on the server's operating environment and/or the
server's file system semantics. For example, for servers obeying server's file system semantics. For example, for servers obeying
Portable Operating System Interface (POSIX) semantics, time_access Portable Operating System Interface (POSIX) semantics, time_access
would be updated only by the READ and READDIR operations and not any would be updated only by the READ and READDIR operations and not any
of the operations that modify the content of the object [16], [17], of the operations that modify the content of the object [16], [17],
[24], [25], [26]. Of course, setting the corresponding [26], [27], [28]. Of course, setting the corresponding
time_access_set attribute is another way to modify the time_access time_access_set attribute is another way to modify the time_access
attribute. attribute.
Whenever the file object resides on a writable file system, the Whenever the file object resides on a writable file system, the
server should make its best efforts to record time_access into stable server should make its best efforts to record time_access into stable
storage. However, to mitigate the performance effects of doing so, storage. However, to mitigate the performance effects of doing so,
and most especially whenever the server is satisfying the read of the and most especially whenever the server is satisfying the read of the
object's content from its cache, the server MAY cache access time object's content from its cache, the server MAY cache access time
updates and lazily write them to stable storage. It is also updates and lazily write them to stable storage. It is also
acceptable to give administrators of the server the option to disable acceptable to give administrators of the server the option to disable
skipping to change at page 49, line 50 skipping to change at page 49, line 33
5.8.2.40. Attribute 54: time_modify_set 5.8.2.40. Attribute 54: time_modify_set
Sets the time of last modification to the object. SETATTR use only. Sets the time of last modification to the object. SETATTR use only.
5.9. Interpreting owner and owner_group 5.9. Interpreting owner and owner_group
The RECOMMENDED attributes "owner" and "owner_group" (and also users The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups within the "acl" attribute) are represented in terms of a and groups within the "acl" attribute) are represented in terms of a
UTF-8 string. To avoid a representation that is tied to a particular UTF-8 string. To avoid a representation that is tied to a particular
underlying implementation at the client or server, the use of the underlying implementation at the client or server, the use of the
UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [27] UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [29]
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, the local representation transferred between the client and server, the local representation
is translated to a syntax of the form "user@dns_domain". This will is translated to a syntax of the form "user@dns_domain". This will
allow for a client and server that do not use the same local allow for a client and server that do not use the same local
representation the ability to translate to a common syntax that can representation the ability to translate to a common syntax that can
be interpreted by both. be interpreted by both.
skipping to change at page 52, line 32 skipping to change at page 52, line 15
dns_domain". dns_domain".
The owner string "nobody" may be used to designate an anonymous user, The owner string "nobody" may be used to designate an anonymous user,
which will be associated with a file created by a security principal which will be associated with a file created by a security principal
that cannot be mapped through normal means to the owner attribute. that cannot be mapped through normal means to the owner attribute.
5.10. Character Case Attributes 5.10. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes, With respect to the case_insensitive and case_preserving attributes,
each UCS-4 character (which UTF-8 encodes) has a "long descriptive each UCS-4 character (which UTF-8 encodes) has a "long descriptive
name" RFC1345 [28] which may or may not include the word "CAPITAL" or name" RFC1345 [30] which may or may not include the word "CAPITAL" or
"SMALL". The presence of SMALL or CAPITAL allows an NFS server to "SMALL". The presence of SMALL or CAPITAL allows an NFS server to
implement unambiguous and efficient table driven mappings for case implement unambiguous and efficient table driven mappings for case
insensitive comparisons, and non-case-preserving storage, although insensitive comparisons, and non-case-preserving storage, although
there are variations that occur additional characters with a name there are variations that occur additional characters with a name
including "SMALL" or "CAPITAL" are added in a subsequent version of including "SMALL" or "CAPITAL" are added in a subsequent version of
Unicode. Unicode.
For general character handling and internationalization issues, see For general character handling and internationalization issues, see
Section 12. For details regarding case mapping, see the section Section 12. For details regarding case mapping, see the section
Case-based Mapping Used for Component4 Strings. Case-based Mapping Used for Component4 Strings.
skipping to change at page 82, line 50 skipping to change at page 82, line 50
limit the changes seen by the client, to those that are less limit the changes seen by the client, to those that are less
aggressive, use more standard methods of replicating data, and impose aggressive, use more standard methods of replicating data, and impose
a greater burden on the client to adapt to the transition. a greater burden on the client to adapt to the transition.
The NFSv4 protocol does not impose choices on clients and servers The NFSv4 protocol does not impose choices on clients and servers
with regard to that spectrum of transition methods. In fact, there with regard to that spectrum of transition methods. In fact, there
are many valid choices, depending on client and application are many valid choices, depending on client and application
requirements and their interaction with server implementation requirements and their interaction with server implementation
choices. The NFSv4.0 protocol does not provide the servers a means choices. The NFSv4.0 protocol does not provide the servers a means
of communicating the transition methods. In the NFSv4.1 protocol of communicating the transition methods. In the NFSv4.1 protocol
[29], an additional attribute "fs_locations_info" is presented, which [31], an additional attribute "fs_locations_info" is presented, which
will define the specific choices that can be made, how these choices will define the specific choices that can be made, how these choices
are communicated to the client, and how the client is to deal with are communicated to the client, and how the client is to deal with
any discontinuities. any discontinuities.
In the sections below, references will be made to various possible In the sections below, references will be made to various possible
server implementation choices as a way of illustrating the transition server implementation choices as a way of illustrating the transition
scenarios that clients may deal with. The intent here is not to scenarios that clients may deal with. The intent here is not to
define or limit server implementations but rather to illustrate the define or limit server implementations but rather to illustrate the
range of issues that clients may face. Again, as the NFSv4.0 range of issues that clients may face. Again, as the NFSv4.0
protocol does not have an explicit means of communicating these protocol does not have an explicit means of communicating these
skipping to change at page 103, line 27 skipping to change at page 103, line 27
For the case of the use of multiple, disjoint security mechanisms in For the case of the use of multiple, disjoint security mechanisms in
the server's resources, the security for a particular object in the the server's resources, the security for a particular object in the
server's namespace should be the union of all security mechanisms of server's namespace should be the union of all security mechanisms of
all direct descendants. all direct descendants.
9. File Locking and Share Reservations 9. File Locking and Share Reservations
Integrating locking into the NFS protocol necessarily causes it to be Integrating locking into the NFS protocol necessarily causes it to be
stateful. With the inclusion of share reservations the protocol stateful. With the inclusion of share reservations the protocol
becomes substantially more dependent on state than the traditional becomes substantially more dependent on state than the traditional
combination of NFS and NLM (Network Lock Manager) [30]. There are combination of NFS and NLM (Network Lock Manager) [32]. There are
three components to making this state manageable: three components to making this state manageable:
o clear division between client and server o clear division between client and server
o ability to reliably detect inconsistency in state between client o ability to reliably detect inconsistency in state between client
and server and server
o simple and robust recovery mechanisms o simple and robust recovery mechanisms
In this model, the server owns the state information. The client In this model, the server owns the state information. The client
skipping to change at page 117, line 49 skipping to change at page 117, line 49
received before the last request (L) was sent. If a duplicate of received before the last request (L) was sent. If a duplicate of
last request (r == L) is received, the stored response is returned. last request (r == L) is received, the stored response is returned.
If a request beyond the next sequence (r == L + 2) is received, it is If a request beyond the next sequence (r == L + 2) is received, it is
rejected with the return of error NFS4ERR_BAD_SEQID. Sequence rejected with the return of error NFS4ERR_BAD_SEQID. Sequence
history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
sequence changes the client verifier. sequence changes the client verifier.
Since the sequence number is represented with an unsigned 32-bit Since the sequence number is represented with an unsigned 32-bit
integer, the arithmetic involved with the sequence number is mod integer, the arithmetic involved with the sequence number is mod
2^32. For an example of modulo arithmetic involving sequence numbers 2^32. For an example of modulo arithmetic involving sequence numbers
see [31]. see [33].
It is critical the server maintain the last response sent to the It is critical the server maintain the last response sent to the
client to provide a more reliable cache of duplicate non-idempotent client to provide a more reliable cache of duplicate non-idempotent
requests than that of the traditional cache described in [32]. The requests than that of the traditional cache described in [34]. The
traditional duplicate request cache uses a least recently used traditional duplicate request cache uses a least recently used
algorithm for removing unneeded requests. However, the last lock algorithm for removing unneeded requests. However, the last lock
request and response on a given state-owner must be cached as long as request and response on a given state-owner must be cached as long as
the lock state exists on the server. the lock state exists on the server.
The client MUST monotonically increment the sequence number for the The client MUST monotonically increment the sequence number for the
CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
operations. This is true even in the event that the previous operations. This is true even in the event that the previous
operation that used the sequence number received an error. The only operation that used the sequence number received an error. The only
exception to this rule is if the previous operation received one of exception to this rule is if the previous operation received one of
skipping to change at page 126, line 13 skipping to change at page 126, line 13
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
[19]. The client must account for the server that is able to perform [21]. The client must account for the server that is able to perform
I/O and non-reclaim locking requests within the grace period as well I/O and non-reclaim locking requests within the grace period as well
as those that cannot do so. as those that cannot do so.
A reclaim-type locking request outside the server's grace period can A reclaim-type locking request outside the server's grace period can
only succeed if the server can guarantee that no conflicting lock or only succeed if the server can guarantee that no conflicting lock or
I/O request has been granted since reboot or restart. I/O request has been granted since reboot or restart.
A server may, upon restart, establish a new value for the lease A server may, upon restart, establish a new value for the lease
period. Therefore, clients should, once a new client ID is period. Therefore, clients should, once a new client ID is
established, refetch the lease_time attribute and use it as the basis established, refetch the lease_time attribute and use it as the basis
skipping to change at page 172, line 18 skipping to change at page 172, line 18
protocol, and how they address issues related to protocol, and how they address issues related to
internationalization, including issues related to UTF-8, internationalization, including issues related to UTF-8,
normalization, string preparation, case folding, and handling of normalization, string preparation, case folding, and handling of
internationalization issues related to domains. internationalization issues related to domains.
The NFSv4 protocol needs to deal with internationalization, or I18N, The NFSv4 protocol needs to deal with internationalization, or I18N,
with respect to file names and other strings as used within the with respect to file names and other strings as used within the
protocol. The choice of string representation must allow for protocol. The choice of string representation must allow for
reasonable name/string access to clients, applications, and users reasonable name/string access to clients, applications, and users
which use various languages. The UTF-8 encoding of the UCS as which use various languages. The UTF-8 encoding of the UCS as
defined by [7] allows for this type of access and follows the policy defined by [8] allows for this type of access and follows the policy
described in "IETF Policy on Character Sets and Languages", [8]. described in "IETF Policy on Character Sets and Languages", [9].
In implementing such policies, it is important to understand and In implementing such policies, it is important to understand and
respect the nature of NFSv4 as a means by which client respect the nature of NFSv4 as a means by which client
implementations may invoke operations on remote file systems. Server implementations may invoke operations on remote file systems. Server
implementations act as a conduit to a range of file system implementations act as a conduit to a range of file system
implementations that the NFSv4 server typically invokes through a implementations that the NFSv4 server typically invokes through a
virtual-file-system interface. virtual-file-system interface.
Keeping this context in mind, one needs to understand that the file Keeping this context in mind, one needs to understand that the file
systems with which clients will be interacting will generally not be systems with which clients will be interacting will generally not be
skipping to change at page 173, line 14 skipping to change at page 173, line 14
12.1. Use of UTF-8 12.1. Use of UTF-8
As mentioned above, UTF-8 is used as a convenient way to encode As mentioned above, UTF-8 is used as a convenient way to encode
Unicode which allows clients that have no internationalization Unicode which allows clients that have no internationalization
requirements to avoid these issues since the mapping of ASCII names requirements to avoid these issues since the mapping of ASCII names
to UTF-8 is the identity. to UTF-8 is the identity.
12.1.1. Relation to Stringprep 12.1.1. Relation to Stringprep
RFC 3454 [9], otherwise known as "stringprep", documents a framework RFC 3454 [10], otherwise known as "stringprep", documents a framework
for using Unicode/UTF-8 in networking protocols, intended "to for using Unicode/UTF-8 in networking protocols, intended "to
increase the likelihood that string input and string comparison work increase the likelihood that string input and string comparison work
in ways that make sense for typical users throughout the world." A in ways that make sense for typical users throughout the world." A
protocol conforming to this framework must define a profile of protocol conforming to this framework must define a profile of
stringprep "in order to fully specify the processing options." stringprep "in order to fully specify the processing options."
NFSv4, while it does make normative references to stringprep and uses NFSv4, while it does make normative references to stringprep and uses
elements of that framework, it does not, for reasons that are elements of that framework, it does not, for reasons that are
explained below, conform to that framework, for all of the strings explained below, conform to that framework, for all of the strings
that are used within it. that are used within it.
skipping to change at page 175, line 41 skipping to change at page 175, line 41
o For other strings, particular those passed by the server to file o For other strings, particular those passed by the server to file
system implementations, normalization requirements are the system implementations, normalization requirements are the
province of the file system and the job of this specification is province of the file system and the job of this specification is
not to specify a particular form but to make sure that not to specify a particular form but to make sure that
interoperability is maximized, even when clients and server-based interoperability is maximized, even when clients and server-based
file systems have different preferences. file systems have different preferences.
A related but distinct issue concerns string confusability. This can A related but distinct issue concerns string confusability. This can
occur when two strings (including single-character strings) having a occur when two strings (including single-character strings) having a
similar appearance. There have been attempts to define uniform similar appearance. There have been attempts to define uniform
processing in an attempt to avoid such confusion (see stringprep [9]) processing in an attempt to avoid such confusion (see stringprep
but the results have often added confusion. [10]) but the results have often added confusion.
Some examples of possible confusions and proposed processing intended Some examples of possible confusions and proposed processing intended
to reduce/avoid confusions: to reduce/avoid confusions:
o Deletion of characters believed to be invisible and appropriately o Deletion of characters believed to be invisible and appropriately
ignored, justifying their deletion, including, WORD JOINER ignored, justifying their deletion, including, WORD JOINER
(U+2060), and the ZERO WIDTH SPACE (U+200B). (U+2060), and the ZERO WIDTH SPACE (U+200B).
o Deletion of characters supposed to not bear semantics and only o Deletion of characters supposed to not bear semantics and only
affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C) affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C)
skipping to change at page 205, line 23 skipping to change at page 205, line 23
A locking request was attempted which would require the upgrade or A locking request was attempted which would require the upgrade or
downgrade of a lock range already held by the owner when the server downgrade of a lock range already held by the owner when the server
does not support atomic upgrade or downgrade of locks. does not support atomic upgrade or downgrade of locks.
13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) 13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028)
A lock request is operating on a range that overlaps in part a A lock request is operating on a range that overlaps in part a
currently held lock for the current lock owner and does not precisely currently held lock for the current lock owner and does not precisely
match a single such lock where the server does not support this type match a single such lock where the server does not support this type
of request, and thus does not implement POSIX locking semantics [33]. of request, and thus does not implement POSIX locking semantics [35].
See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a
discussion of how this applies to LOCK, LOCKT, and LOCKU discussion of how this applies to LOCK, LOCKT, and LOCKU
respectively. respectively.
13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) 13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038)
The client attempted a READ, WRITE, LOCK or other operation not The client attempted a READ, WRITE, LOCK or other operation not
sanctioned by the stateid passed (e.g., writing to a file opened only sanctioned by the stateid passed (e.g., writing to a file opened only
for read). for read).
skipping to change at page 230, line 47 skipping to change at page 230, line 47
verifier at each server event or instantiation that may lead to a verifier at each server event or instantiation that may lead to a
loss of uncommitted data. Most commonly this occurs when the server loss of uncommitted data. Most commonly this occurs when the server
is rebooted; however, other events at the server may result in is rebooted; however, other events at the server may result in
uncommitted data loss as well. uncommitted data loss as well.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.5.5. IMPLEMENTATION 15.5.5. IMPLEMENTATION
The COMMIT operation is similar in operation and semantics to the The COMMIT operation is similar in operation and semantics to the
POSIX fsync() [34] system call that synchronizes a file's state with POSIX fsync() [36] system call that synchronizes a file's state with
the disk (file data and metadata is flushed to disk or stable the disk (file data and metadata is flushed to disk or stable
storage). COMMIT performs the same operation for a client, flushing storage). COMMIT performs the same operation for a client, flushing
any unsynchronized data and metadata on the server to the server's any unsynchronized data and metadata on the server to the server's
disk or stable storage for the specified file. Like fsync(), it may disk or stable storage for the specified file. Like fsync(), it may
be that there is some modified data or no modified data to be that there is some modified data or no modified data to
synchronize. The data may have been synchronized by the server's synchronize. The data may have been synchronized by the server's
normal periodic buffer synchronization activity. COMMIT should normal periodic buffer synchronization activity. COMMIT should
return NFS4_OK, unless there has been an unexpected error. return NFS4_OK, unless there has been an unexpected error.
COMMIT differs from fsync() in that it is possible for the client to COMMIT differs from fsync() in that it is possible for the client to
skipping to change at page 234, line 19 skipping to change at page 234, line 19
from the principal indicated in the RPC credentials of the call, but from the principal indicated in the RPC credentials of the call, but
the server's operating environment or filesystem semantics may the server's operating environment or filesystem semantics may
dictate other methods of derivation. Similarly, if createattrs dictate other methods of derivation. Similarly, if createattrs
includes neither the group attribute nor a group ACE, and if the includes neither the group attribute nor a group ACE, and if the
server's filesystem both supports and requires the notion of a group server's filesystem both supports and requires the notion of a group
attribute (or group ACE), the server MUST derive the group attribute attribute (or group ACE), the server MUST derive the group attribute
(or the corresponding owner ACE) for the file. This could be from (or the corresponding owner ACE) for the file. This could be from
the RPC call's credentials, such as the group principal if the the RPC call's credentials, such as the group principal if the
credentials include it (such as with AUTH_SYS), from the group credentials include it (such as with AUTH_SYS), from the group
identifier associated with the principal in the credentials (e.g., identifier associated with the principal in the credentials (e.g.,
POSIX systems have a user database [35] that has the group identifier POSIX systems have a user database [37] that has the 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
filesystem semantics dictate. This applies to the OPEN operation filesystem 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 or group attribute or ACL that the principal owner attribute or group attribute or ACL that the principal
indicated the RPC call's credentials does not have permissions to indicated the RPC call's credentials does not have permissions to
create files for. The error to be returned in this instance is create files for. The error to be returned in this instance is
NFS4ERR_PERM. This applies to the OPEN operation too. NFS4ERR_PERM. This applies to the OPEN operation too.
skipping to change at page 247, line 27 skipping to change at page 247, line 27
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.14.5. IMPLEMENTATION 15.14.5. IMPLEMENTATION
If the area to be unlocked does not correspond exactly to a lock If the area to be unlocked does not correspond exactly to a lock
actually held by the lock-owner the server may return the error actually held by the lock-owner the server may return the error
NFS4ERR_LOCK_RANGE. This includes the case in which the area is not NFS4ERR_LOCK_RANGE. This includes the case in which the area is not
locked, where the area is a sub-range of the area locked, where it locked, where the area is a sub-range of the area locked, where it
overlaps the area locked without matching exactly or the area overlaps the area locked without matching exactly or the area
specified includes multiple locks held by the lock-owner. In all of specified includes multiple locks held by the lock-owner. In all of
these cases, allowed by POSIX locking [33] semantics, a client these cases, allowed by POSIX locking [35] semantics, a client
receiving this error, should if it desires support for such receiving this error, should if it desires support for such
operations, simulate the operation using LOCKU on ranges operations, simulate the operation using LOCKU on ranges
corresponding to locks it actually holds, possibly followed by LOCK corresponding to locks it actually holds, possibly followed by LOCK
requests for the sub-ranges not being unlocked. requests for the sub-ranges not being unlocked.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKU requests will similarly be handled locally. case, LOCKU requests will similarly be handled locally.
15.15. Operation 15: LOOKUP - Lookup Filename 15.15. Operation 15: LOOKUP - Lookup Filename
skipping to change at page 257, line 51 skipping to change at page 257, line 51
reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed.
In this case, delegation will always be granted, although the server In this case, delegation will always be granted, although the server
may specify an immediate recall in the delegation structure. may specify an immediate recall in the delegation structure.
The rflags returned by a successful OPEN allow the server to return The rflags returned by a successful OPEN allow the server to return
information governing how the open file is to be handled. information governing how the open file is to be handled.
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
OPEN_CONFIRM operation before using the open file. OPEN_CONFIRM operation before using the open file.
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of Posix locking techniques [33]. behavior supports the complete set of Posix locking techniques [35].
From this the client can choose to manage file locking state in a way From this the client can choose to manage file locking state in a way
to handle a mis-match of file locking management. to handle a mis-match of file locking management.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.3 for further discussion. and name checks. See Section 12.3 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
skipping to change at page 258, line 45 skipping to change at page 258, line 45
does not have authorization to create files for, then the server may does not have authorization to create files for, then the server may
return NFS4ERR_PERM. return NFS4ERR_PERM.
In the case of a OPEN which specifies a size of zero (e.g., In the case of a OPEN which specifies a size of zero (e.g.,
truncation) and the file has named attributes, the named attributes truncation) and the file has named attributes, the named attributes
are left as is. They are not removed. are left as is. They are not removed.
15.18.6. IMPLEMENTATION 15.18.6. IMPLEMENTATION
The OPEN operation contains support for EXCLUSIVE4 create. The The OPEN operation contains support for EXCLUSIVE4 create. The
mechanism is similar to the support in NFSv3 [13]. As in NFSv3, this mechanism is similar to the support in NFSv3 [14]. As in NFSv3, this
mechanism provides reliable exclusive creation. Exclusive create is mechanism provides reliable exclusive creation. Exclusive create is
invoked when the how parameter is EXCLUSIVE4. In this case, the invoked when the how parameter is EXCLUSIVE4. In this case, the
client provides a verifier that can reasonably be expected to be client provides a verifier that can reasonably be expected to be
unique. A combination of a client identifier, perhaps the client unique. A combination of a client identifier, perhaps the client
network address, and a unique number generated by the client, perhaps network address, and a unique number generated by the client, perhaps
the RPC transaction identifier, may be appropriate. the RPC transaction identifier, may be appropriate.
If the object does not exist, the server creates the object and If the object does not exist, the server creates the object and
stores the verifier in stable storage. For filesystems that do not stores the verifier in stable storage. For filesystems that do not
provide a mechanism for the storage of arbitrary file attributes, the provide a mechanism for the storage of arbitrary file attributes, the
skipping to change at page 267, line 12 skipping to change at page 267, line 12
nfsstat4 status; nfsstat4 status;
}; };
15.23.4. DESCRIPTION 15.23.4. DESCRIPTION
Replaces the current filehandle with the filehandle that represents Replaces the current filehandle with the filehandle that represents
the public filehandle of the server's name space. This filehandle the public filehandle of the server's name space. This filehandle
may be different from the "root" filehandle which may be associated may be different from the "root" filehandle which may be associated
with some other directory on the server. with some other directory on the server.
The public filehandle represents the concepts embodied in [21], [22], The public filehandle represents the concepts embodied in [23], [24],
[36]. The intent for NFSv4 is that the public filehandle [38]. The intent for NFSv4 is that the public filehandle
(represented by the PUTPUBFH operation) be used as a method of (represented by the PUTPUBFH operation) be used as a method of
providing WebNFS server compatibility with NFSv2 and NFSv3. providing WebNFS server compatibility with NFSv2 and NFSv3.
The public filehandle and the root filehandle (represented by the The public filehandle and the root filehandle (represented by the
PUTROOTFH operation) should be equivalent. If the public and root PUTROOTFH operation) should be equivalent. If the public and root
filehandles are not equivalent, then the public filehandle MUST be a filehandles are not equivalent, then the public filehandle MUST be a
descendant of the root filehandle. descendant of the root filehandle.
15.23.5. IMPLEMENTATION 15.23.5. IMPLEMENTATION
Used as the first operator in an NFS request to set the context for Used as the first operator in an NFS request to set the context for
following operations. following operations.
With the NFSv2 and 3 public filehandle, the client is able to specify With the NFSv2 and 3 public filehandle, the client is able to specify
whether the path name provided in the LOOKUP should be evaluated as whether the path name provided in the LOOKUP should be evaluated as
either an absolute path relative to the server's root or relative to either an absolute path relative to the server's root or relative to
the public filehandle. [36] contains further discussion of the the public filehandle. [38] contains further discussion of the
functionality. With NFSv4, that type of specification is not functionality. With NFSv4, that type of specification is not
directly available in the LOOKUP operation. The reason for this is directly available in the LOOKUP operation. The reason for this is
because the component separators needed to specify absolute vs. because the component separators needed to specify absolute vs.
relative are not allowed in NFSv4. Therefore, the client is relative are not allowed in NFSv4. Therefore, the client is
responsible for constructing its request such that the use of either responsible for constructing its request such that the use of either
PUTROOTFH or PUTPUBFH are used to signify absolute or relative PUTROOTFH or PUTPUBFH are used to signify absolute or relative
evaluation of an NFS URL respectively. evaluation of an NFS URL respectively.
Note that there are warnings mentioned in [36] with respect to the Note that there are warnings mentioned in [38] with respect to the
use of absolute evaluation and the restrictions the server may place use of absolute evaluation and the restrictions the server may place
on that evaluation with respect to how much of its namespace has been on that evaluation with respect to how much of its namespace has been
made available. These same warnings apply to NFSv4. It is likely, made available. These same warnings apply to NFSv4. It is likely,
therefore that because of server implementation details, an NFSv3 therefore that because of server implementation details, an NFSv3
absolute public filehandle lookup may behave differently than an absolute public filehandle lookup may behave differently than an
NFSv4 absolute resolution. NFSv4 absolute resolution.
There is a form of security negotiation as described in [37] that There is a form of security negotiation as described in [39] that
uses the public filehandle a method of employing SNEGO. This method uses the public filehandle a method of employing SNEGO. This method
is not available with NFSv4 as filehandles are not overloaded with is not available with NFSv4 as filehandles are not overloaded with
special meaning and therefore do not provide the same framework as special meaning and therefore do not provide the same framework as
NFSv2 and NFSv3. Clients should therefore use the security NFSv2 and NFSv3. Clients should therefore use the security
negotiation mechanisms described in this RFC. negotiation mechanisms described in this RFC.
15.24. Operation 24: PUTROOTFH - Set Root Filehandle 15.24. Operation 24: PUTROOTFH - Set Root Filehandle
15.24.1. SYNOPSIS 15.24.1. SYNOPSIS
skipping to change at page 276, line 42 skipping to change at page 276, line 42
target is also subject to the normal UTF-8, character support, and target is also subject to the normal UTF-8, character support, and
name checks. See Section 12.3 for further discussion. name checks. See Section 12.3 for further discussion.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [38] in POSIX) to remove a directory, as system call (e.g., unlink() [40] in POSIX) to remove a directory, as
well as the converse (e.g., a rmdir() on a non-directory) because well as the converse (e.g., a rmdir() on a non-directory) because
they knew the server would check the file type. NFSv4 REMOVE can be they knew the server would check the file type. NFSv4 REMOVE can be
used to delete any directory entry independent of its file type. The used to delete any directory entry independent of its file type. The
implementor of an NFSv4 client's entry points from the unlink() and implementor of an NFSv4 client's entry points from the unlink() and
rmdir() system calls should first check the file type against the rmdir() system calls should first check the file type against the
types the system call is allowed to remove before issuing a REMOVE. types the system call is allowed to remove before issuing a REMOVE.
Alternatively, the implementor can produce a COMPOUND call that Alternatively, the implementor can produce a COMPOUND call that
includes a LOOKUP/VERIFY sequence to verify the file type before a includes a LOOKUP/VERIFY sequence to verify the file type before a
REMOVE operation in the same COMPOUND call. REMOVE operation in the same COMPOUND call.
skipping to change at page 285, line 32 skipping to change at page 285, line 32
and the server supports, since the risks of doing so are on the and the server supports, since the risks of doing so are on the
client. client.
The READDIR operation will not directly return the NFS4ERR_WRONGSEC The READDIR operation will not directly return the NFS4ERR_WRONGSEC
error. However, if the READDIR request included a request for error. However, if the READDIR request included a request for
attributes, it is possible that the READDIR request's security triple attributes, it is possible that the READDIR request's security triple
does not match that of a directory entry. If this is the case and does not match that of a directory entry. If this is the case and
the client has requested the rdattr_error attribute, the server will the client has requested the rdattr_error attribute, the server will
return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.
Note that a server MAY use the AUTH_NONE flavor to signify that the
client is allowed to attempt to use authentication flavors that are
not explicitly listed in the SECINFO results. Instead of using a
listed flavor, the client might then, for instance opt to use an
otherwise unlisted RPCSEC_GSS mechanism instead of AUTH_NONE. It may
wish to do so in order to meet an application requirement for data
integrity or privacy. In choosing to use an unlisted flavor, the
client SHOULD always be prepared to handle a failure by falling back
to using AUTH_NONE or another listed flavor. It MUST NOT assume that
identity mapping is supported, and should be prepared for the fact
that its identity is squashed.
See Section 17 for a discussion on the recommendations for security See Section 17 for a discussion on the recommendations for security
flavor used by SECINFO. flavor used by SECINFO.
15.34. Operation 34: SETATTR - Set Attributes 15.34. Operation 34: SETATTR - Set Attributes
15.34.1. SYNOPSIS 15.34.1. SYNOPSIS
(cfh), stateid, attrmask, attr_vals -> attrsset (cfh), stateid, attrmask, attr_vals -> attrsset
15.34.2. ARGUMENT 15.34.2. ARGUMENT
skipping to change at page 309, line 13 skipping to change at page 310, line 7
server controlled by the attacker. server controlled by the attacker.
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and match the principal used for these operations is checked against and match
the previous use of these operations. See Section 9.1.1 for further the previous use of these operations. See Section 9.1.1 for further
discussion. discussion.
18. IANA Considerations 18. IANA Considerations
This section uses terms that are defined in [39]. This section uses terms that are defined in [41].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA will create a registry called the "NFSv4 Named Attribute IANA will create a registry called the "NFSv4 Named Attribute
Definitions Registry". Definitions Registry".
The NFSv4 protocol supports the association of a file with zero or The NFSv4 protocol supports the association of a file with zero or
more named attributes. The name space identifiers for these more named attributes. The name space identifiers for these
attributes are defined as string names. The protocol does not define attributes are defined as string names. The protocol does not define
the specific assignment of the name space for these file attributes. the specific assignment of the name space for these file attributes.
skipping to change at page 309, line 36 skipping to change at page 310, 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 [39]. The policy for each assignment is basis, per section 4.1 of [41]. The policy for each assignment is
Specification Required, per section 4.1 of [39]. Specification Required, per section 4.1 of [41].
Under the NFSv4 specification, the name of a named attribute can in Under the NFSv4 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
clients and servers will be unable to a handle string that long. clients and servers will be unable to a handle string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up exceeds 128 UTF-8 characters. To give IESG the flexibility to set up
bases of assignment of Experimental Use and Standards Action, the bases of assignment of Experimental Use and Standards Action, the
prefixes of "EXPE" and "STDS" are Reserved. The zero length named prefixes of "EXPE" and "STDS" are Reserved. The zero length named
attribute name is Reserved. attribute name is Reserved.
skipping to change at page 310, line 35 skipping to change at page 311, line 28
18.1.1. Initial Registry 18.1.1. Initial Registry
There is no initial registry. There is no initial registry.
18.1.2. Updating Registrations 18.1.2. Updating Registrations
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
Approval. Approval.
18.2. ONC RPC Network Identifiers (netids)
Section 2.2 discussed the r_netid field and the corresponding r_addr
field of a clientaddr4 structure. The NFSv4 protocol depends on the
syntax and semantics of these fields to effectively communicate
callback information between client and server. Therefore, an IANA
registry has been created to include the values defined in this
document and to allow for future expansion based on transport usage/
availability. Additions to this ONC RPC Network Identifier registry
must be done with the publication of an RFC.
The initial values for this registry are as follows (some of this
text is replicated from section 2.2 for clarity):
The Network Identifier (or r_netid for short) is used to specify a
transport protocol and associated universal address (or r_addr for
short). The syntax of the Network Identifier is a US-ASCII string.
The initial definitions for r_netid are:
"tcp": TCP over IP version 4
"udp": UDP over IP version 4
"tcp6": TCP over IP version 6
"udp6": UDP over IP version 6
Note: the '"' marks are used for delimiting the strings for this
document and are not part of the Network Identifier string.
For the "tcp" and "udp" Network Identifiers the Universal Address or
r_addr (for IPv4) is a US-ASCII string and is of the form:
h1.h2.h3.h4.p1.p2
The prefix, "h1.h2.h3.h4", is the standard textual form for
representing an IPv4 address, which is always four octets long.
Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
the first through fourth octets each converted to ASCII-decimal.
Assuming big-endian ordering, p1 and p2 are, respectively, the first
and second octets each converted to ASCII-decimal. For example, if a
host, in big-endian order, has an address of 0x0A010307 and there is
a service listening on, in big endian order, port 0x020F (decimal
527), then complete universal address is "10.1.3.7.2.15".
For the "tcp6" and "udp6" Network Identifiers the Universal Address
or r_addr (for IPv6) is a US-ASCII string and is of the form:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way
as with universal addresses for "tcp" and "udp". The prefix, "x1:x2:
x3:x4:x5:x6:x7:x8", is the standard textual form for representing an
IPv6 address as defined in Section 2.2 of [17]. Additionally, the
two alternative forms specified in Section 2.2 of [17] are also
acceptable.
18.2.1. Initial Registry
There is no initial registry.
18.2.2. Updating Registrations
The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG
Approval.
19. References 19. References
19.1. Normative References 19.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", [2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description",
draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress),
Feb 2011. Feb 2011.
skipping to change at page 312, line 29 skipping to change at page 312, line 5
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification [4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 5531, May 2009. Version 2", RFC 5531, May 2009.
[5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[6] Linn, J., "Generic Security Service Application Program [6] 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.
[7] International Organization for Standardization, "Information [7] Eisler, M., Ed., "IANA Considerations for Remote Procedure Call
(RPC) Network Identifiers and Universal Address Formats",
RFC 5665, January 2010.
[8] 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.
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", [9] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
19.2. Informative References 19.2. Informative References
[10] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [11] 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.
[11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [12] 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 3010, December 2000. version 4 Protocol", RFC 3010, December 2000.
[12] Nowicki, B., "NFS: Network File System Protocol specification", [13] Nowicki, B., "NFS: Network File System Protocol specification",
RFC 1094, March 1989. RFC 1094, March 1989.
[13] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 [14] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995. Protocol Specification", RFC 1813, June 1995.
[14] Eisler, M., "XDR: External Data Representation Standard", [15] Eisler, M., "XDR: External Data Representation Standard",
RFC 4506, May 2006. RFC 4506, May 2006.
[15] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version [16] 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.
[16] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [17] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002.
[18] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, August 1995.
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing [19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Architecture", RFC 2373, July 1998. Control Protocol (DCCP)", RFC 4340, March 2006.
[18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [20] Adamson, B., Bormann, C., Handley, M., and J. Macker,
line Database", RFC 3232, January 2002. "Negative-acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Protocol", RFC 3940, November 2004.
[19] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [21] 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.
[20] Eisler, M., "NFS Version 2 and Version 3 Security Issues and [22] 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.
[21] Callaghan, B., "WebNFS Client Specification", RFC 2054, [23] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[22] Callaghan, B., "WebNFS Server Specification", RFC 2055, [24] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[23] IESG, "IESG Processing of RFC Errata for the IETF Stream", [25] IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008.
[24] The Open Group, "Section 'read()' of System Interfaces of The [26] 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", 2004. Edition", 2004.
[25] The Open Group, "Section 'readdir()' of System Interfaces of [27] 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", 2004. 2004 Edition", 2004.
[26] The Open Group, "Section 'write()' of System Interfaces of The [28] 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", 2004. Edition", 2004.
[27] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [29] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999. June 1999.
[28] Simonsen, K., "Character Mnemonics and Character Sets", [30] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992. RFC 1345, June 1992.
[29] Shepler, S., Eisler, M., and D. Noveck, "Network File System [31] Shepler, S., Eisler, M., and D. Noveck, "Network File System
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, (NFS) Version 4 Minor Version 1 Protocol", RFC 5661,
January 2010. January 2010.
[30] The Open Group, "Protocols for Interworking: XNFS, Version 3W, [32] The Open Group, "Protocols for Interworking: XNFS, Version 3W,
ISBN 1-85912-184-5", February 1998. ISBN 1-85912-184-5", February 1998.
[31] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [33] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[32] Juszczak, C., "Improving the Performance and Correctness of an [34] Juszczak, C., "Improving the Performance and Correctness of an
NFS Server", USENIX Conference Proceedings , June 1990. NFS Server", USENIX Conference Proceedings , June 1990.
[33] The Open Group, "Section 'fcntl()' of System Interfaces of The [35] 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.
[34] The Open Group, "Section 'fsync()' of System Interfaces of The [36] 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.
[35] The Open Group, "Section 'getpwnam()' of System Interfaces of [37] 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.
[36] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[37] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation [39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation
for WebNFS", RFC 2755, January 2000. for WebNFS", RFC 2755, January 2000.
[38] The Open Group, "Section 'unlink()' of System Interfaces of The [40] 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.
[39] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [41] 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.
[42] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Appendix A. Acknowledgments Appendix A. Acknowledgments
A bis is certainly built on the shoulders of the first attempt. A bis is certainly built on the shoulders of the first attempt.
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
Carl Beame, Mike Eisler, and David Noveck are responsible for a great Carl Beame, Mike Eisler, and David Noveck are responsible for a great
deal of the effort in this work. deal of the effort in this work.
Rob Thurlow clarified how a client should contact a new server if a Rob Thurlow clarified how a client should contact a new server if a
migration has occurred. migration has occurred.
skipping to change at page 315, line 34 skipping to change at page 315, line 20
James Lentini graciously read the rewrite of Section 7 and his James Lentini graciously read the rewrite of Section 7 and his
comments were vital in improving the quality of that effort. comments were vital in improving the quality of that effort.
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond
Myklebust were faithful attendants of the biweekly triage meeting and Myklebust were faithful attendants of the biweekly triage meeting and
accepted many an action item. accepted many an action item.
Bruce Fields was a good sounding board for both the Third Edge Bruce Fields was a good sounding board for both the Third Edge
Condition and Courtesy Locks in general. He was also the leading Condition and Courtesy Locks in general. He was also the leading
advocate of stamping out backport issues from [29]. advocate of stamping out backport issues from [31].
Marcel Telka was a champion of straightening out the difference Marcel Telka was a champion of straightening out the difference
between a lock-owner and an open-owner. He has also been diligent in between a lock-owner and an open-owner. He has also been diligent in
reviewing the final document. reviewing the final document.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
 End of changes. 100 change blocks. 
229 lines changed or deleted 155 lines changed or added

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