Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring... Diff: draft-ietf-nfsv4-minorversion1-24.txt - draft-ietf-nfsv4-minorversion1-25.txt
 draft-ietf-nfsv4-minorversion1-24.txt   draft-ietf-nfsv4-minorversion1-25.txt 
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: February 7, 2009 Editors Expires: February 23, 2009 Editors
Aug 06, 2008 August 22, 2008
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-24.txt draft-ietf-nfsv4-minorversion1-25.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 7, 2009. This Internet-Draft will expire on February 23, 2009.
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version one, This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS extensions made subsequently. Major extensions introduced in NFS
version 4 minor version one include: Sessions, Directory Delegations, version 4 minor version one include: Sessions, Directory Delegations,
and parallel NFS (pNFS). and parallel NFS (pNFS).
Requirements Language Requirements Language
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 11 1.1. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 11
1.2. Scope of this Document . . . . . . . . . . . . . . . . . 11 1.2. Scope of this Document . . . . . . . . . . . . . . . . . 11
1.3. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . 11 1.3. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . 11
1.4. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . 12 1.4. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . 12
1.5. General Definitions . . . . . . . . . . . . . . . . . . 12 1.5. General Definitions . . . . . . . . . . . . . . . . . . 12
1.6. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 15 1.6. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 15
1.6.1. RPC and Security . . . . . . . . . . . . . . . . . . 15 1.6.1. RPC and Security . . . . . . . . . . . . . . . . . . 15
1.6.2. Protocol Structure . . . . . . . . . . . . . . . . . 15 1.6.2. Protocol Structure . . . . . . . . . . . . . . . . . 15
1.6.3. File System Model . . . . . . . . . . . . . . . . . 16 1.6.3. File System Model . . . . . . . . . . . . . . . . . 16
1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 18 1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 18
1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 18 1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 19
2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 19 2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 20
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20
2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 20 2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 20 2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 20
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 23 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 23
2.4. Client Identifiers and Client Owners . . . . . . . . . . 24 2.4. Client Identifiers and Client Owners . . . . . . . . . . 24
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 27 2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 27
2.4.2. Server Release of Client ID . . . . . . . . . . . . 28 2.4.2. Server Release of Client ID . . . . . . . . . . . . 28
2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 28 2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 28
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 29 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 29
2.6. Security Service Negotiation . . . . . . . . . . . . . . 30 2.6. Security Service Negotiation . . . . . . . . . . . . . . 30
2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 30 2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 30
2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 30 2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 31
2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 31 2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 31
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 35 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 35
2.8. Non-RPC-based Security Services . . . . . . . . . . . . 38 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 38
2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 38 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 38
2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38
2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 38 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 38
2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 38 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 39
2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 38 2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 39
2.9.2. Client and Server Transport Behavior . . . . . . . . 39 2.9.2. Client and Server Transport Behavior . . . . . . . . 39
2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 41 2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 41
2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 41 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10.1. Motivation and Overview . . . . . . . . . . . . . . 41 2.10.1. Motivation and Overview . . . . . . . . . . . . . . 41
2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 42 2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 42
2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 44 2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 44
2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 45 2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 45
2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 48 2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 48
2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 61 2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 61
2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 63 2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 64
2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 69 2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 69
2.10.9. Session Mechanics - Steady State . . . . . . . . . . 73 2.10.9. Session Mechanics - Steady State . . . . . . . . . . 73
2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 75 2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 75
2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 75 2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 75
2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 78 2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 79
3. Protocol Constants and Data Types . . . . . . . . . . . . . . 78 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 79
3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 79 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 79
3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 79 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 80
3.3. Structured Data Types . . . . . . . . . . . . . . . . . 81 3.3. Structured Data Types . . . . . . . . . . . . . . . . . 82
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 90 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 90 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 90
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 91 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 91
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 91 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 91
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 91 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 91
4.2.1. General Properties of a Filehandle . . . . . . . . . 92 4.2.1. General Properties of a Filehandle . . . . . . . . . 92
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 93 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 93
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 93 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 93
4.3. One Method of Constructing a Volatile Filehandle . . . . 94 4.3. One Method of Constructing a Volatile Filehandle . . . . 94
4.4. Client Recovery from Filehandle Expiration . . . . . . . 95 4.4. Client Recovery from Filehandle Expiration . . . . . . . 95
skipping to change at page 4, line 43 skipping to change at page 4, line 43
9. File Locking and Share Reservations . . . . . . . . . . . . . 174 9. File Locking and Share Reservations . . . . . . . . . . . . . 174
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 174 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 174
9.1.1. State-owner Definition . . . . . . . . . . . . . . . 174 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 174
9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 175 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 175
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 178 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 178
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 178 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 178
9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 179 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 179
9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 179 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 179
9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 180 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 180
9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 181 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 181
9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 181 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 182
9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 182 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 182
9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 183 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 183
9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 184 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 184
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 184 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 184
10.1. Performance Challenges for Client-Side Caching . . . . . 185 10.1. Performance Challenges for Client-Side Caching . . . . . 185
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 186 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 186
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 188 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 188
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 190 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 190
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 190 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 190
10.3.2. Data Caching and File Locking . . . . . . . . . . . 191 10.3.2. Data Caching and File Locking . . . . . . . . . . . 191
skipping to change at page 10, line 6 skipping to change at page 10, line 6
Delegation Wants . . . . . . . . . . . . . . . . . . . . 576 Delegation Wants . . . . . . . . . . . . . . . . . . . . 576
20.11. Operation 13: CB_NOTIFY_LOCK - Notify of possible 20.11. Operation 13: CB_NOTIFY_LOCK - Notify of possible
lock availability . . . . . . . . . . . . . . . . . . . 577 lock availability . . . . . . . . . . . . . . . . . . . 577
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify device ID 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify device ID
changes . . . . . . . . . . . . . . . . . . . . . . . . 579 changes . . . . . . . . . . . . . . . . . . . . . . . . 579
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . . . 581 Operation . . . . . . . . . . . . . . . . . . . . . . . 581
21. Security Considerations . . . . . . . . . . . . . . . . . . . 581 21. Security Considerations . . . . . . . . . . . . . . . . . . . 581
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 583 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 583
22.1. Named Attribute Definitions . . . . . . . . . . . . . . 583 22.1. Named Attribute Definitions . . . . . . . . . . . . . . 583
22.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 583 22.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 584
22.3. Defining New Notifications . . . . . . . . . . . . . . . 584 22.1.2. Updating Registrations . . . . . . . . . . . . . . . 584
22.4. Defining New Layout Types . . . . . . . . . . . . . . . 584 22.2. Device ID Notifications . . . . . . . . . . . . . . . . 584
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 586 22.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 585
22.5.1. Path Variable Values . . . . . . . . . . . . . . . . 586 22.2.2. Updating Registrations . . . . . . . . . . . . . . . 585
22.5.2. Path Variable Names . . . . . . . . . . . . . . . . 586 22.3. Object Recall Types . . . . . . . . . . . . . . . . . . 585
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 586 22.3.1. Initial Registry . . . . . . . . . . . . . . . . . . 587
23.1. Normative References . . . . . . . . . . . . . . . . . . 586 22.3.2. Updating Registrations . . . . . . . . . . . . . . . 587
23.2. Informative References . . . . . . . . . . . . . . . . . 588 22.4. Layout Types . . . . . . . . . . . . . . . . . . . . . . 587
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 590 22.4.1. Initial Registry . . . . . . . . . . . . . . . . . . 588
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 592 22.4.2. Updating Registrations . . . . . . . . . . . . . . . 588
Intellectual Property and Copyright Statements . . . . . . . . . 593 22.4.3. Guidelines for Writing Layout Type Specifications . 588
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 590
22.5.1. Path Variables Registry . . . . . . . . . . . . . . 590
22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 592
22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 592
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 593
23.1. Normative References . . . . . . . . . . . . . . . . . . 593
23.2. Informative References . . . . . . . . . . . . . . . . . 595
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 596
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 598
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 599
Intellectual Property and Copyright Statements . . . . . . . . . 600
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 1 Protocol 1.1. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0 is described in [21]. It generally follows the version, NFSv4.0 is described in [20]. It generally follows the
guidelines for minor versioning model listed in Section 10 of RFC guidelines for minor versioning model listed in Section 10 of RFC
3530. However, it diverges from guidelines 11 ("a client and server 3530. However, it diverges from guidelines 11 ("a client and server
that supports minor version X must support minor versions 0 through that supports minor version X must support minor versions 0 through
X-1"), and 12 ("no features may be introduced as mandatory in a minor X-1"), and 12 ("no features may be introduced as mandatory in a minor
version"). These divergences are due to the introduction of the version"). These divergences are due to the introduction of the
sessions model for managing non-idempotent operations and the sessions model for managing non-idempotent operations and the
RECLAIM_COMPLETE operation. These two new features are RECLAIM_COMPLETE operation. These two new features are
infrastructural in nature and simplify implementation of existing and infrastructural in nature and simplify implementation of existing and
other new features. Making them anything but REQUIRED would add other new features. Making them anything but REQUIRED would add
undue complexity to protocol definition and implementation. NFSv4.1 undue complexity to protocol definition and implementation. NFSv4.1
skipping to change at page 11, line 45 skipping to change at page 11, line 45
o describe the NFSv4.0 protocol, except where needed to contrast o describe the NFSv4.0 protocol, except where needed to contrast
with NFSv4.1. with NFSv4.1.
o modify the specification of the NFSv4.0 protocol. o modify the specification of the NFSv4.0 protocol.
o clarify the NFSv4.0 protocol. o clarify the NFSv4.0 protocol.
1.3. NFSv4 Goals 1.3. NFSv4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The NFSv4 protocol is a further revision of the NFS protocol defined
already by NFSv3 [22]. It retains the essential characteristics of already by NFSv3 [21]. It retains the essential characteristics of
previous versions: easy recovery; independence of transport previous versions: easy recovery; independence of transport
protocols, operating systems and file systems; simplicity; and good protocols, operating systems and file systems; simplicity; and good
performance. NFSv4 has the following goals: performance. NFSv4 has the following goals:
o Improved access and good performance on the Internet. o Improved access and good performance on the Internet.
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
skipping to change at page 13, line 33 skipping to change at page 13, line 33
node. node.
Client ID A 64-bit quantity used as a unique, short-hand reference Client ID A 64-bit quantity used as a unique, short-hand reference
to a client supplied Verifier and client owner. The server is to a client supplied Verifier and client owner. The server is
responsible for supplying the client ID. responsible for supplying the client ID.
Client Owner The client owner is a unique string, opaque to the Client Owner The client owner is a unique string, opaque to the
server, which identifies a client. Multiple network connections server, which identifies a client. Multiple network connections
and source network addresses originating from those connections and source network addresses originating from those connections
may share a client owner. The server is expected to treat may share a client owner. The server is expected to treat
requests from connnections with the same client owner as coming requests from connections with the same client owner as coming
from the same client. from the same client.
File System The collection of objects on a server (as identified by File System The collection of objects on a server (as identified by
the major identifier of a Server Owner, which is defined later in the major identifier of a Server Owner, which is defined later in
this section), that share the same fsid attribute (see this section), that share the same fsid attribute (see
Section 5.8.1.9). Section 5.8.1.9).
Lease An interval of time defined by the server for which the client Lease An interval of time defined by the server for which the client
is irrevocably granted a lock. At the end of a lease period the is irrevocably granted a lock. At the end of a lease period the
lock may be revoked if the lease has not been extended. The lock lock may be revoked if the lease has not been extended. The lock
skipping to change at page 14, line 20 skipping to change at page 14, line 20
client access to a set of file systems and is identified by a client access to a set of file systems and is identified by a
Server owner. A server can span multiple network addresses. Server owner. A server can span multiple network addresses.
Server Owner The "Server Owner" identifies the server to the client. Server Owner The "Server Owner" identifies the server to the client.
The server owner consists of a major and minor identifier. When The server owner consists of a major and minor identifier. When
the client has two connections each to a peer with the same major the client has two connections each to a peer with the same major
identifier, the client assumes both peers are the same server (the identifier, the client assumes both peers are the same server (the
server namespace is the same via each connection), and assumes and server namespace is the same via each connection), and assumes and
lock state is sharable across both connections. When each peer lock state is sharable across both connections. When each peer
has both the same major and minor identifier, the client assumes has both the same major and minor identifier, the client assumes
each connection might be associatable with the same session. each connection might be associable with the same session.
Stable Storage NFSv4.1 servers must be able to recover without data Stable Storage NFSv4.1 servers must be able to recover without data
loss from multiple power failures (including cascading power loss from multiple power failures (including cascading power
failures, that is, several power failures in quick succession), failures, that is, several power failures in quick succession),
operating system failures, and hardware failure of components operating system failures, and hardware failure of components
other than the storage medium itself (for example, disk, other than the storage medium itself (for example, disk,
nonvolatile RAM). nonvolatile RAM).
Some examples of stable storage that are allowable for an NFS Some examples of stable storage that are allowable for an NFS
server include: server include:
skipping to change at page 17, line 9 skipping to change at page 17, line 9
which are then used to identify objects in subsequent operations. which are then used to identify objects in subsequent operations.
The NFSv4.1 protocol provides support for persistent filehandles, The NFSv4.1 protocol provides support for persistent filehandles,
guaranteed to be valid for the lifetime of the file system object guaranteed to be valid for the lifetime of the file system object
designated. In addition it provides support to servers to provide designated. In addition it provides support to servers to provide
filehandles with more limited validity guarantees, called volatile filehandles with more limited validity guarantees, called volatile
filehandles. filehandles.
1.6.3.2. File Attributes 1.6.3.2. File Attributes
The NFSv4.1 protocol has a rich and extensible attribute structure, The NFSv4.1 protocol has a rich and extensible file object attribute
which is divided into REQUIRED, RECOMMENDED, and named attributes. structure, which is divided into REQUIRED, RECOMMENDED, and named
attributes (see Section 5).
The acl, sacl, and dacl attributes compose a set of RECOMMENDED file Several (but not all) of the REQUIRED attributes are derived from the
attributes that make up the Access Control List (ACL) of a file attributes of NFSv3 (see definition of the fattr3 data type in [21]).
(Section 6). These attributes provide for directory and file access An example of a REQUIRED attribute is the file object's type
control beyond the model used in NFSv3. The ACL definition allows (Section 5.8.1.2) so that regular files can be distinguished from
for specification of specific sets of permissions for individual directories (also known as folders in some operating environments)
users and groups. In addition, ACL inheritance allows propagation of and other types of objects. REQUIRED attributes are discussed in
Section 5.1.
An example of three RECOMMENDED attributes are acl, sacl, and dacl.
These attributes define an Access Control List (ACL) on a file object
((Section 6). An ACL provides directory and file access control
beyond the model used in NFSv3. The ACL definition allows for
specification of specific sets of permissions for individual users
and groups. In addition, ACL inheritance allows propagation of
access permissions and restriction down a directory tree as file access permissions and restriction down a directory tree as file
system objects are created. system objects are created. RECOMMENDED attributes are discussed in
Section 5.2.
A named attribute is an opaque byte stream that is associated with a A named attribute is an opaque byte stream that is associated with a
directory or file and referred to by a string name. Named attributes directory or file and referred to by a string name. Named attributes
are meant to be used by client applications as a method to associate are meant to be used by client applications as a method to associate
application-specific data with a regular file or directory. NFSv4.1 application-specific data with a regular file or directory. NFSv4.1
modifies named attributes relative to NFSv4.0 by tightening the modifies named attributes relative to NFSv4.0 by tightening the
allowed operations in order to prevent the development of non- allowed operations in order to prevent the development of non-
interoperable implementation. See Section 5.3 for details. interoperable implementations. Named attributes are discussed in
Section 5.3.
1.6.3.3. Multi-server Namespace 1.6.3.3. Multi-server Namespace
NFSv4.1 contains a number of features to allow implementation of NFSv4.1 contains a number of features to allow implementation of
namespaces that cross server boundaries and that allow and facilitate namespaces that cross server boundaries and that allow and facilitate
a non-disruptive transfer of support for individual file systems a non-disruptive transfer of support for individual file systems
between servers. They are all based upon attributes that allow one between servers. They are all based upon attributes that allow one
file system to specify alternate or new locations for that file file system to specify alternate or new locations for that file
system. system.
skipping to change at page 21, line 28 skipping to change at page 21, line 35
Although GSS-API has an authentication service distinct from its Although GSS-API has an authentication service distinct from its
privacy and integrity services, GSS-API's authentication service is privacy and integrity services, GSS-API's authentication service is
not used for RPCSEC_GSS's authentication service. Instead, each RPC not used for RPCSEC_GSS's authentication service. Instead, each RPC
request and response header is integrity protected with the GSS-API request and response header is integrity protected with the GSS-API
integrity service, and this allows RPCSEC_GSS to offer per-RPC integrity service, and this allows RPCSEC_GSS to offer per-RPC
authentication and identity. See [4] for more information. authentication and identity. See [4] for more information.
NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and
authentication service. NFSv4.1 servers MUST support RPCSEC_GSS's authentication service. NFSv4.1 servers MUST support RPCSEC_GSS's
privacy service. privacy service. NFSv4.1 clients SHOULD support RPCSEC_GSS's privacy
service.
2.2.1.1.1.2. Security mechanisms for NFSv4.1 2.2.1.1.1.2. Security mechanisms for NFSv4.1
RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide
security services. Therefore NFSv4.1 clients and servers MUST security services. Therefore NFSv4.1 clients and servers MUST
support three security mechanisms: Kerberos V5, SPKM-3, and LIPKEY. support three security mechanisms: Kerberos V5, SPKM-3, and LIPKEY.
The use of RPCSEC_GSS requires selection of: mechanism, quality of The use of RPCSEC_GSS requires selection of: mechanism, quality of
protection (QOP), and service (authentication, integrity, privacy). protection (QOP), and service (authentication, integrity, privacy).
For the mandated security mechanisms, NFSv4.1 specifies that a QOP of For the mandated security mechanisms, NFSv4.1 specifies that a QOP of
skipping to change at page 22, line 24 skipping to change at page 22, line 31
------------------------------------------------------------------ ------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes 390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes 390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the number and name of the pseudo flavor is presented here Note that the number and name of the pseudo flavor is presented here
as a mapping aid to the implementor. Because the NFSv4.1 protocol as a mapping aid to the implementor. Because the NFSv4.1 protocol
includes a method to negotiate security and it understands the GSS- includes a method to negotiate security and it understands the GSS-
API mechanism, the pseudo flavor is not needed. The pseudo flavor is API mechanism, the pseudo flavor is not needed. The pseudo flavor is
needed for the NFSv3 since the security negotiation is done via the needed for the NFSv3 since the security negotiation is done via the
MOUNT protocol as described in [23]. MOUNT protocol as described in [22].
2.2.1.1.1.2.2. LIPKEY 2.2.1.1.1.2.2. LIPKEY
The LIPKEY V5 GSS-API mechanism as described in [6] MUST be The LIPKEY V5 GSS-API mechanism as described in [6] MUST be
implemented with the RPCSEC_GSS services as specified in the implemented with the RPCSEC_GSS services as specified in the
following table: following table:
1 2 3 4 5 6 1 2 3 4 5 6
------------------------------------------------------------------ ------------------------------------------------------------------
390006 lipkey 1.3.6.1.5.5.9 rpc_gss_svc_none yes yes 390006 lipkey 1.3.6.1.5.5.9 rpc_gss_svc_none yes yes
skipping to change at page 23, line 49 skipping to change at page 24, line 6
With the use of the COMPOUND procedure, the client is able to build With the use of the COMPOUND procedure, the client is able to build
simple or complex requests. These COMPOUND requests allow for a simple or complex requests. These COMPOUND requests allow for a
reduction in the number of RPCs needed for logical file system reduction in the number of RPCs needed for logical file system
operations. For example, multi-component lookup requests can be operations. For example, multi-component lookup requests can be
constructed by combining multiple LOOKUP operations. Those can be constructed by combining multiple LOOKUP operations. Those can be
further combined with operations such as GETATTR, READDIR, or OPEN further combined with operations such as GETATTR, READDIR, or OPEN
plus READ to do more complicated sets of operation without incurring plus READ to do more complicated sets of operation without incurring
additional latency. additional latency.
NFSv4.1 also contains a considerable set of callback operations in NFSv4.1 also contains a considerable set of callback operations in
which the server makes an RPC directed at the client. Callback RPC's which the server makes an RPC directed at the client. Callback RPCs
have a similar structure to that of the normal server requests. In have a similar structure to that of the normal server requests. In
all minor versions of the NFSv4 protocol there are two callback RPC all minor versions of the NFSv4 protocol there are two callback RPC
procedures, CB_NULL and CB_COMPOUND. The CB_COMPOUND procedure is procedures, CB_NULL and CB_COMPOUND. The CB_COMPOUND procedure is
defined in an analogous fashion to that of COMPOUND with its own set defined in an analogous fashion to that of COMPOUND with its own set
of callback operations. of callback operations.
The addition of new server and callback operations within the The addition of new server and callback operations within the
COMPOUND and CB_COMPOUND request framework provides a means of COMPOUND and CB_COMPOUND request framework provides a means of
extending the protocol in subsequent minor versions. extending the protocol in subsequent minor versions.
skipping to change at page 25, line 47 skipping to change at page 26, line 5
same string. The implementor is cautioned from an approach that same string. The implementor is cautioned from an approach that
requires the string to be recorded in a local file because this requires the string to be recorded in a local file because this
precludes the use of the implementation in an environment where precludes the use of the implementation in an environment where
there is no local disk and all file access is from an NFSv4.1 there is no local disk and all file access is from an NFSv4.1
server. server.
o The string should be the same for each server network address that o The string should be the same for each server network address that
the client accesses. This way, if a server has multiple the client accesses. This way, if a server has multiple
interfaces, the client can trunk traffic over multiple network interfaces, the client can trunk traffic over multiple network
paths as described in Section 2.10.4. (Note: the precise opposite paths as described in Section 2.10.4. (Note: the precise opposite
was advised in the NFSv4.0 specification [21].) was advised in the NFSv4.0 specification [20].)
o The algorithm for generating the string should not assume that the o The algorithm for generating the string should not assume that the
client's network address will not change, unless the client client's network address will not change, unless the client
implementation knows it is using statically assigned network implementation knows it is using statically assigned network
addresses. This includes changes between client incarnations and addresses. This includes changes between client incarnations and
even changes while the client is still running in its current even changes while the client is still running in its current
incarnation. Thus with dynamic address assignment, if the client incarnation. Thus with dynamic address assignment, if the client
includes just the client's network address in the co_ownerid includes just the client's network address in the co_ownerid
string, there is a real risk that after the client gives up the string, there is a real risk that after the client gives up the
network address, another client, using a similar algorithm for network address, another client, using a similar algorithm for
skipping to change at page 27, line 47 skipping to change at page 28, line 4
See the descriptions of EXCHANGE_ID (Section 18.35) and See the descriptions of EXCHANGE_ID (Section 18.35) and
CREATE_SESSION (Section 18.36) for a complete specification of these CREATE_SESSION (Section 18.36) for a complete specification of these
operations. operations.
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 2.4.1. Upgrade from NFSv4.0 to NFSv4.1
To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a
client_owner4 in an EXCHANGE_ID with an nfs_client_id4 established client_owner4 in an EXCHANGE_ID with an nfs_client_id4 established
using the SETCLIENTID operation of NFSv4.0. A server that does so using the SETCLIENTID operation of NFSv4.0. A server that does so
will allow an upgraded client to avoid waiting until the lease (i.e. will allow an upgraded client to avoid waiting until the lease (i.e.
the lease established by the NFSv4.0 instance client) expires. This the lease established by the NFSv4.0 instance client) expires. This
requires the client_owner4 be constructed the same way as the requires the client_owner4 be constructed the same way as the
nfs_client_id4. If the latter's contents included the server's nfs_client_id4. If the latter's contents included the server's
network address (per the recommendations of the NFSv4.0 specification network address (per the recommendations of the NFSv4.0 specification
[21]), and the NFSv4.1 client does not wish to use a client ID that [20]), and the NFSv4.1 client does not wish to use a client ID that
prevents trunking, it should send two EXCHANGE_ID operations. The prevents trunking, it should send two EXCHANGE_ID operations. The
first EXCHANGE_ID will have a client_owner4 equal to the first EXCHANGE_ID will have a client_owner4 equal to the
nfs_client_id4. This will clear the state created by the NFSv4.0 nfs_client_id4. This will clear the state created by the NFSv4.0
client. The second EXCHANGE_ID will not have the server's network client. The second EXCHANGE_ID will not have the server's network
address. The state created for the second EXCHANGE_ID will not have address. The state created for the second EXCHANGE_ID will not have
to wait for lease expiration, because there will be no state to to wait for lease expiration, because there will be no state to
expire. expire.
2.4.2. Server Release of Client ID 2.4.2. Server Release of Client ID
skipping to change at page 35, line 24 skipping to change at page 35, line 34
operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME
request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH,
RENAME "c" "d", using credentials acceptable to aFH's security RENAME "c" "d", using credentials acceptable to aFH's security
policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on
the RENAME operation. the RENAME operation.
To prevent a client from an endless sequence of a request containing To prevent a client from an endless sequence of a request containing
LINK or RENAME, followed by a request containing SECINFO_NO_NAME, the LINK or RENAME, followed by a request containing SECINFO_NO_NAME, the
server MUST detect when the security policies of the current and server MUST detect when the security policies of the current and
saved filehandles have no mutually acceptable security tuple, and saved filehandles have no mutually acceptable security tuple, and
MUST NOT NFS4ERR_WRONGSEC in that situation. Instead the server MUST MUST NOT return NFS4ERR_WRONGSEC in that situation. Instead the
return NFS4ERR_XDEV. server MUST return NFS4ERR_XDEV.
Thus while a server MAY return NFS4ERR_WRONGSEC from LINK and RENAME, Thus while a server MAY return NFS4ERR_WRONGSEC from LINK and RENAME,
the server implementor may reasonably decide the consequences are not the server implementor may reasonably decide the consequences are not
worth the security benefits, and so allow the security policy of the worth the security benefits, and so allow the security policy of the
current filehandle to override that of the saved filehandle. current filehandle to override that of the saved filehandle.
2.7. Minor Versioning 2.7. Minor Versioning
To address the requirement of an NFS protocol that can evolve as the To address the requirement of an NFS protocol that can evolve as the
need arises, the NFSv4.1 protocol contains the rules and framework to need arises, the NFSv4.1 protocol contains the rules and framework to
allow for future minor changes or versioning. allow for future minor changes or versioning.
The base assumption with respect to minor versioning is that any The base assumption with respect to minor versioning is that any
future accepted minor version must follow the IETF process and be future accepted minor version must follow the IETF process and be
documented in a standards track RFC. Therefore, each minor version documented in a standards track RFC. Therefore, each minor version
number will correspond to an RFC. Minor version zero of the NFSv4 number will correspond to one or more new RFCs. Minor version zero
protocol is represented by [21], and minor version one is represented of the NFSv4 protocol is represented by [20], and minor version one
by this document [[Comment.1: RFC Editor: change "document" to "RFC" is represented by this document [[Comment.1: RFC Editor: change
when we publish]]. The COMPOUND and CB_COMPOUND procedures support "document" to "RFC" when we publish]]. The COMPOUND and CB_COMPOUND
the encoding of the minor version being requested by the client. procedures support the encoding of the minor version being requested
by the client.
The following items represent the basic rules for the development of The following items represent the basic rules for the development of
minor versions. Note that a future minor version may decide to minor versions. Note that a future minor version may decide to
modify or add to the following rules as part of the minor version modify or add to the following rules as part of the minor version
definition. definition.
1. Procedures are not added or deleted 1. Procedures are not added or deleted
To maintain the general RPC model, NFSv4 minor versions will not To maintain the general RPC model, NFSv4 minor versions will not
add to or delete procedures from the NFS program. add to or delete procedures from the NFS program.
skipping to change at page 38, line 48 skipping to change at page 39, line 12
NFSv4.1 provides alarm control on a per file object basis, via the NFSv4.1 provides alarm control on a per file object basis, via the
acl and sacl attributes as described in Section 6. Alarms may serve acl and sacl attributes as described in Section 6. Alarms may serve
as the basis for intrusion detection. It is outside the scope of as the basis for intrusion detection. It is outside the scope of
this specification to specify heuristics for detecting intrusion via this specification to specify heuristics for detecting intrusion via
alarms. alarms.
2.9. Transport Layers 2.9. Transport Layers
2.9.1. REQUIRED and RECOMMENDED Properties of Transports 2.9.1. REQUIRED and RECOMMENDED Properties of Transports
NFSv4.1 works over RDMA and non-RDMA_based transports with the NFSv4.1 works over RDMA and non-RDMA-based transports with the
following attributes: following attributes:
o The transport supports reliable delivery of data, which NFSv4.1 o The transport supports reliable delivery of data, which NFSv4.1
requires but neither NFSv4.1 nor RPC has facilities for ensuring. requires but neither NFSv4.1 nor RPC has facilities for ensuring.
[23]
[24]
o The transport delivers data in the order it was sent. Ordered o The transport delivers data in the order it was sent. Ordered
delivery simplifies detection of transmit errors, and simplifies delivery simplifies detection of transmit errors, and simplifies
the sending of arbitrary sized requests and responses, via the the sending of arbitrary sized requests and responses, via the
record marking protocol [3]. record marking protocol [3].
Where an NFSv4.1 implementation supports operation over the IP Where an NFSv4.1 implementation supports operation over the IP
network protocol, any transport used between NFS and IP MUST be among network protocol, any transport used between NFS and IP MUST be among
the IETF-approved congestion control transport protocols. At the the IETF-approved congestion control transport protocols. At the
time this document was written, the only two transports that had the time this document was written, the only two transports that had the
above attributes were TCP and SCTP. To enhance the possibilities for above attributes were TCP and SCTP. To enhance the possibilities for
interoperability, an NFSv4.1 implementation MUST support operation interoperability, an NFSv4.1 implementation MUST support operation
over the TCP transport protocol. over the TCP transport protocol.