draft-ietf-nfsv4-rfc3530bis-00.txt   draft-ietf-nfsv4-rfc3530bis-01.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Editor Internet-Draft Editor
Updates: 3530 (if approved) April 02, 2009 Intended status: Standards Track March 05, 2010
Intended status: Standards Track Expires: September 6, 2010
Expires: October 4, 2009
Network File System (NFS) version 4 Protocol NFS Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-00.txt draft-ietf-nfsv4-rfc3530bis-01.txt
Abstract
The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course,
attention has been applied to making NFS version 4 operate well in an
Internet environment. This document replaces RFC 3530 as the
definition of the NFS version 4 protocol.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 2, line 5
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 October 4, 2009. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Network File System (NFS) version 4 is a distributed filesystem described in the BSD License.
protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course,
attention has been applied to making NFS version 4 operate well in an
Internet environment. This document replaces RFC 3530 as the
definition of the NFS version 4 protocol.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [1]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 7 1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 7
1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 7 1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 7
1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 8 1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 8
1.4. Inconsistencies of this Document with Section 18 . . . . 9 1.4. Inconsistencies of this Document with Section 18 . . . . 9
1.5. Overview of NFS version 4 Features . . . . . . . . . . . 9 1.5. Overview of NFS version 4 Features . . . . . . . . . . . 9
1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 9 1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 9
1.5.2. Procedure and Operation Structure . . . . . . . . . . 10 1.5.2. Procedure and Operation Structure . . . . . . . . . . 10
1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10 1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12 1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12
1.5.5. File locking . . . . . . . . . . . . . . . . . . . . 12 1.5.5. File locking . . . . . . . . . . . . . . . . . . . . 12
1.5.6. Client Caching and Delegation . . . . . . . . . . . . 12 1.5.6. Client Caching and Delegation . . . . . . . . . . . . 13
1.6. General Definitions . . . . . . . . . . . . . . . . . . 13 1.6. General Definitions . . . . . . . . . . . . . . . . . . 13
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 15 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 15
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 15 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 15
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 16 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 17
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 21 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 22
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 22 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 22
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 23 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 23
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 23 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Security mechanisms for NFS version 4 . . . . . . . . 24 3.2.1. Security mechanisms for NFS version 4 . . . . . . . . 24
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 26 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 26
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 26 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 27
3.3.3. Callback RPC Authentication . . . . . . . . . . . . . 27 3.3.3. Callback RPC Authentication . . . . . . . . . . . . . 27
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . 29 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . 29
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . 29 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . 30
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30
4.2.1. General Properties of a Filehandle . . . . . . . . . 30 4.2.1. General Properties of a Filehandle . . . . . . . . . 30
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . 31 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . 31
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . 31 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . 31
4.2.4. One Method of Constructing a Volatile Filehandle . . 33 4.2.4. One Method of Constructing a Volatile Filehandle . . 33
4.3. Client Recovery from Filehandle Expiration . . . . . . . 33 4.3. Client Recovery from Filehandle Expiration . . . . . . . 33
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 34 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Mandatory Attributes . . . . . . . . . . . . . . . . . . 35 5.1. Mandatory Attributes . . . . . . . . . . . . . . . . . . 35
5.2. Recommended Attributes . . . . . . . . . . . . . . . . . 35 5.2. Recommended Attributes . . . . . . . . . . . . . . . . . 35
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 4, line 27 skipping to change at page 5, line 10
8.10.1. Close and Retention of State Information . . . . . . 87 8.10.1. Close and Retention of State Information . . . . . . 87
8.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 88 8.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 88
8.12. Short and Long Leases . . . . . . . . . . . . . . . . . 89 8.12. Short and Long Leases . . . . . . . . . . . . . . . . . 89
8.13. Clocks, Propagation Delay, and Calculating Lease 8.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 89 Expiration . . . . . . . . . . . . . . . . . . . . . . . 89
8.14. Migration, Replication and State . . . . . . . . . . . . 90 8.14. Migration, Replication and State . . . . . . . . . . . . 90
8.14.1. Migration and State . . . . . . . . . . . . . . . . . 90 8.14.1. Migration and State . . . . . . . . . . . . . . . . . 90
8.14.2. Replication and State . . . . . . . . . . . . . . . . 91 8.14.2. Replication and State . . . . . . . . . . . . . . . . 91
8.14.3. Notification of Migrated Lease . . . . . . . . . . . 91 8.14.3. Notification of Migrated Lease . . . . . . . . . . . 91
8.14.4. Migration and the Lease_time Attribute . . . . . . . 92 8.14.4. Migration and the Lease_time Attribute . . . . . . . 92
9. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 92 9. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 93
9.1. Performance Challenges for Client-Side Caching . . . . . 93 9.1. Performance Challenges for Client-Side Caching . . . . . 93
9.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 94 9.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 94
9.2.1. Delegation Recovery . . . . . . . . . . . . . . . . . 95 9.2.1. Delegation Recovery . . . . . . . . . . . . . . . . . 95
9.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 97 9.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 97
9.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 98 9.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 98
9.3.2. Data Caching and File Locking . . . . . . . . . . . . 99 9.3.2. Data Caching and File Locking . . . . . . . . . . . . 99
9.3.3. Data Caching and Mandatory File Locking . . . . . . . 100 9.3.3. Data Caching and Mandatory File Locking . . . . . . . 100
9.3.4. Data Caching and File Identity . . . . . . . . . . . 101 9.3.4. Data Caching and File Identity . . . . . . . . . . . 101
9.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 102 9.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 102
9.4.1. Open Delegation and Data Caching . . . . . . . . . . 104 9.4.1. Open Delegation and Data Caching . . . . . . . . . . 104
9.4.2. Open Delegation and File Locks . . . . . . . . . . . 105 9.4.2. Open Delegation and File Locks . . . . . . . . . . . 105
9.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 106 9.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 106
9.4.4. Recall of Open Delegation . . . . . . . . . . . . . . 109 9.4.4. Recall of Open Delegation . . . . . . . . . . . . . . 109
9.4.5. Clients that Fail to Honor Delegation Recalls . . . . 110 9.4.5. Clients that Fail to Honor Delegation Recalls . . . . 111
9.4.6. Delegation Revocation . . . . . . . . . . . . . . . . 111 9.4.6. Delegation Revocation . . . . . . . . . . . . . . . . 111
9.5. Data Caching and Revocation . . . . . . . . . . . . . . 112 9.5. Data Caching and Revocation . . . . . . . . . . . . . . 112
9.5.1. Revocation Recovery for Write Open Delegation . . . . 112 9.5.1. Revocation Recovery for Write Open Delegation . . . . 112
9.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 113 9.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 113
9.7. Data and Metadata Caching and Memory Mapped Files . . . 115 9.7. Data and Metadata Caching and Memory Mapped Files . . . 115
9.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 117 9.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 117
9.9. Directory Caching . . . . . . . . . . . . . . . . . . . 118 9.9. Directory Caching . . . . . . . . . . . . . . . . . . . 118
10. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 119 10. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 119
11. Internationalization . . . . . . . . . . . . . . . . . . . . 121 11. Internationalization . . . . . . . . . . . . . . . . . . . . 122
11.1. Stringprep profile for the utf8str_cs type . . . . . . . 123 11.1. Stringprep profile for the utf8str_cs type . . . . . . . 123
11.1.1. Intended applicability of the nfs4_cs_prep profile . 123 11.1.1. Intended applicability of the nfs4_cs_prep profile . 123
11.1.2. Character repertoire of nfs4_cs_prep . . . . . . . . 123 11.1.2. Character repertoire of nfs4_cs_prep . . . . . . . . 123
11.1.3. Mapping used by nfs4_cs_prep . . . . . . . . . . . . 123 11.1.3. Mapping used by nfs4_cs_prep . . . . . . . . . . . . 123
11.1.4. Normalization used by nfs4_cs_prep . . . . . . . . . 124 11.1.4. Normalization used by nfs4_cs_prep . . . . . . . . . 124
11.1.5. Prohibited output for nfs4_cs_prep . . . . . . . . . 124 11.1.5. Prohibited output for nfs4_cs_prep . . . . . . . . . 124
11.1.6. Bidirectional output for nfs4_cs_prep . . . . . . . . 124 11.1.6. Bidirectional output for nfs4_cs_prep . . . . . . . . 124
11.2. Stringprep profile for the utf8str_cis type . . . . . . 124 11.2. Stringprep profile for the utf8str_cis type . . . . . . 124
11.2.1. Intended applicability of the nfs4_cis_prep profile . 124 11.2.1. Intended applicability of the nfs4_cis_prep profile . 125
11.2.2. Character repertoire of nfs4_cis_prep . . . . . . . . 125 11.2.2. Character repertoire of nfs4_cis_prep . . . . . . . . 125
11.2.3. Mapping used by nfs4_cis_prep . . . . . . . . . . . . 125 11.2.3. Mapping used by nfs4_cis_prep . . . . . . . . . . . . 125
11.2.4. Normalization used by nfs4_cis_prep . . . . . . . . . 125 11.2.4. Normalization used by nfs4_cis_prep . . . . . . . . . 125
11.2.5. Prohibited output for nfs4_cis_prep . . . . . . . . . 125 11.2.5. Prohibited output for nfs4_cis_prep . . . . . . . . . 125
11.2.6. Bidirectional output for nfs4_cis_prep . . . . . . . 125 11.2.6. Bidirectional output for nfs4_cis_prep . . . . . . . 126
11.3. Stringprep profile for the utf8str_mixed type . . . . . 126 11.3. Stringprep profile for the utf8str_mixed type . . . . . 126
11.3.1. Intended applicability of the nfs4_mixed_prep 11.3.1. Intended applicability of the nfs4_mixed_prep
profile . . . . . . . . . . . . . . . . . . . . . . . 126 profile . . . . . . . . . . . . . . . . . . . . . . . 126
11.3.2. Character repertoire of nfs4_mixed_prep . . . . . . . 126 11.3.2. Character repertoire of nfs4_mixed_prep . . . . . . . 126
11.3.3. Mapping used by nfs4_cis_prep . . . . . . . . . . . . 126 11.3.3. Mapping used by nfs4_cis_prep . . . . . . . . . . . . 126
11.3.4. Normalization used by nfs4_mixed_prep . . . . . . . . 126 11.3.4. Normalization used by nfs4_mixed_prep . . . . . . . . 126
11.3.5. Prohibited output for nfs4_mixed_prep . . . . . . . . 126 11.3.5. Prohibited output for nfs4_mixed_prep . . . . . . . . 126
11.3.6. Bidirectional output for nfs4_mixed_prep . . . . . . 127 11.3.6. Bidirectional output for nfs4_mixed_prep . . . . . . 127
11.4. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 127 11.4. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 127
12. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 127 12. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 128
13. NFS version 4 Requests . . . . . . . . . . . . . . . . . . . 132 13. NFS version 4 Requests . . . . . . . . . . . . . . . . . . . 133
13.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 133 13.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 133
13.2. Evaluation of a Compound Request . . . . . . . . . . . . 134 13.2. Evaluation of a Compound Request . . . . . . . . . . . . 134
13.3. Synchronous Modifying Operations . . . . . . . . . . . . 134 13.3. Synchronous Modifying Operations . . . . . . . . . . . . 135
13.4. Operation Values . . . . . . . . . . . . . . . . . . . . 135 13.4. Operation Values . . . . . . . . . . . . . . . . . . . . 135
14. NFS version 4 Procedures . . . . . . . . . . . . . . . . . . 135 14. NFS version 4 Procedures . . . . . . . . . . . . . . . . . . 135
14.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 135 14.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 135
14.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 136 14.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 136
14.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 138 14.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 139
14.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 141 14.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 142
14.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 143 14.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 143
14.6. Operation 6: CREATE - Create a Non-Regular File Object . 146 14.6. Operation 6: CREATE - Create a Non-Regular File Object . 146
14.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 14.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 149 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 149
14.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 150 14.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 150
14.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 151 14.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 151
14.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 153 14.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 153
14.11. Operation 11: LINK - Create Link to a File . . . . . . . 154 14.11. Operation 11: LINK - Create Link to a File . . . . . . . 154
14.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 156 14.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 156
14.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 160 14.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 160
skipping to change at page 7, line 17 skipping to change at page 8, line 17
1.1. Changes since RFC 3530 1.1. Changes since RFC 3530
This document obsoletes RFC 3530 [10] as the authoritative document This document obsoletes RFC 3530 [10] as the authoritative document
describing NFSv4, without introducing any over-the-wire protocol describing NFSv4, without introducing any over-the-wire protocol
changes. The main changes from RFC 3530 are: changes. The main changes from RFC 3530 are:
o The RPC definition has been moved to a companion document [2] o The RPC 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
o LIPKEY SPKM/3 has been moved from being mandatory to optional
o Some clarification on a client re-establishing callback
information to the new server if state has been migrated
1.2. Changes since RFC 3010 1.2. Changes since RFC 3010
This definition of the NFS version 4 protocol replaces or obsoletes This definition of the NFS version 4 protocol replaces or obsoletes
the definition present in [11]. While portions of the two documents the definition present in [11]. While portions of the two documents
have remained the same, there have been substantive changes in have remained the same, there have been substantive changes in
others. The changes made between [11] and this document represent others. The changes made between [11] 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. [11] definition were untenable.
skipping to change at page 8, line 20 skipping to change at page 9, line 26
o Added a new operation LOCKOWNER_RELEASE to enable notifying the o Added a new operation LOCKOWNER_RELEASE to enable notifying the
server that a lock_owner4 will no longer be used by the client. server that a lock_owner4 will no longer be used by the client.
o RENEW operation changes to identify the client correctly and allow o RENEW operation changes to identify the client correctly and allow
for additional error returns. for additional error returns.
o Verify error return possibilities for all operations. o Verify error return possibilities for all operations.
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 achieive 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 NFS version 4 protocol is a further revision of the NFS protocol The NFS version 4 protocol is a further revision of the NFS protocol
defined already by versions 2 [12] and 3 [13]. It retains the defined already by versions 2 [12] and 3 [13]. It retains the
essential characteristics of previous versions: design for easy essential characteristics of previous versions: design for easy
recovery, independent of transport protocols, operating systems and recovery, independent of transport protocols, operating systems and
skipping to change at page 25, line 7 skipping to change at page 26, line 10
Users and implementors are warned that 56 bit DES is no longer Users and implementors are warned that 56 bit DES is no longer
considered state of the art in terms of resistance to brute force considered state of the art in terms of resistance to brute force
attacks. Once a revision to [15] is available that adds support for attacks. Once a revision to [15] is available that adds support for
AES, implementors are urged to incorporate AES into their NFSv4 over AES, implementors are urged to incorporate AES into their NFSv4 over
Kerberos V5 protocol stacks, and users are similarly urged to migrate Kerberos V5 protocol stacks, and users are similarly urged to migrate
to the use of AES. to the use of AES.
3.2.1.2. LIPKEY as a security triple 3.2.1.2. LIPKEY as a security triple
The LIPKEY GSS-API mechanism as described in [5] MUST be implemented The LIPKEY GSS-API mechanism as described in [5] MAY be implemented
and provide the following security triples. The definition of the and provide the following security triples. The definition of the
columns matches the previous subsection "Kerberos V5 as security columns matches the previous subsection "Kerberos V5 as security
triple". triple".
1 2 3 4 5 1 2 3 4 5
-------------------------------------------------------------------- --------------------------------------------------------------------
390006 lipkey 1.3.6.1.5.5.9 negotiated rpc_gss_svc_none 390006 lipkey 1.3.6.1.5.5.9 negotiated rpc_gss_svc_none
390007 lipkey-i 1.3.6.1.5.5.9 negotiated rpc_gss_svc_integrity 390007 lipkey-i 1.3.6.1.5.5.9 negotiated rpc_gss_svc_integrity
390008 lipkey-p 1.3.6.1.5.5.9 negotiated rpc_gss_svc_privacy 390008 lipkey-p 1.3.6.1.5.5.9 negotiated rpc_gss_svc_privacy
skipping to change at page 25, line 41 skipping to change at page 26, line 44
explanation. explanation.
LIPKEY uses SPKM-3 to create a secure channel in which to pass a user LIPKEY uses SPKM-3 to create a secure channel in which to pass a user
name and password from the client to the server. Once the user name name and password from the client to the server. Once the user name
and password have been accepted by the server, calls to the LIPKEY and password have been accepted by the server, calls to the LIPKEY
context are redirected to the SPKM-3 context. See [5] for more context are redirected to the SPKM-3 context. See [5] for more
details. details.
3.2.1.3. SPKM-3 as a security triple 3.2.1.3. SPKM-3 as a security triple
The SPKM-3 GSS-API mechanism as described in [5] MUST be implemented The SPKM-3 GSS-API mechanism as described in [5] MAY be implemented
and provide the following security triples. The definition of the and provide the following security triples. The definition of the
columns matches the previous subsection "Kerberos V5 as security columns matches the previous subsection "Kerberos V5 as security
triple". triple".
1 2 3 4 5 1 2 3 4 5
-------------------------------------------------------------------- --------------------------------------------------------------------
390009 spkm3 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_none 390009 spkm3 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_none
390010 spkm3i 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_integrity 390010 spkm3i 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_integrity
390011 spkm3p 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_privacy 390011 spkm3p 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_privacy
skipping to change at page 91, line 12 skipping to change at page 92, line 12
server will typically have a different expiration time from those for server will typically have a different expiration time from those for
the same client, previously on the old server. To maintain the the same client, previously on the old server. To maintain the
property that all leases on a given server for a given client expire property that all leases on a given server for a given client expire
at the same time, the server should advance the expiration time to at the same time, the server should advance the expiration time to
the later of the leases being transferred or the leases already the later of the leases being transferred or the leases already
present. This allows the client to maintain lease renewal of both present. This allows the client to maintain lease renewal of both
classes without special effort. classes without special effort.
The servers may choose not to transfer the state information upon The servers may choose not to transfer the state information upon
migration. However, this choice is discouraged. In this case, when migration. However, this choice is discouraged. In this case, when
the client presents state information from the original server, the the client presents state information from the original server (e.g.
client must be prepared to receive either NFS4ERR_STALE_CLIENTID or in a RENEW op or a READ op of zero length), the client must be
prepared to receive either NFS4ERR_STALE_CLIENTID or
NFS4ERR_STALE_STATEID from the new server. The client should then NFS4ERR_STALE_STATEID from the new server. The client should then
recover its state information as it normally would in response to a recover its state information as it normally would in response to a
server failure. The new server must take care to allow for the server failure. The new server must take care to allow for the
recovery of state information as it would in the event of server recovery of state information as it would in the event of server
restart. restart.
A client SHOULD re-establish new callback information with the new
server as soon as possible, according to sequences described in
sections Section 14.35 and Section 14.36. This ensures that server
operations are not blocked by the inability to recall delegations.
8.14.2. Replication and State 8.14.2. Replication and State
Since client switch-over in the case of replication is not under Since client switch-over in the case of replication is not under
server control, the handling of state is different. In this case, server control, the handling of state is different. In this case,
leases, stateids and clientids do not have validity across a leases, stateids and clientids do not have validity across a
transition from one server to another. The client must re-establish transition from one server to another. The client must re-establish
its locks on the new server. This can be compared to the re- its locks on the new server. This can be compared to the re-
establishment of locks by means of reclaim-type requests after a establishment of locks by means of reclaim-type requests after a
server reboot. The difference is that the server has no provision to server reboot. The difference is that the server has no provision to
distinguish requests reclaiming locks from those obtaining new locks distinguish requests reclaiming locks from those obtaining new locks
skipping to change at page 238, line 10 skipping to change at page 239, line 10
listed above for the Network Identifier itself and corresponding listed above for the Network Identifier itself and corresponding
Universal Address. Universal Address.
18. References 18. References
18.1. Normative References 18.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., "NFSv4 Version 0 XDR Description", [2] Haynes, T., "NFSv4 Version 0 XDR Description",
draft-ietf-nfsv4-rfc3530bis-dot-x-00 (work in progress), draft-ietf-nfsv4-rfc3530bis-dot-x-01 (work in progress),
Apr 2009. Mar 2010.
[3] Srinivasan, R., "RPC: Remote Procedure Call Protocol [3] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995. Specification Version 2", RFC 1831, August 1995.
[4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism [5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM", RFC 2847, June 2000. Using SPKM", RFC 2847, June 2000.
skipping to change at page 239, line 5 skipping to change at page 240, line 5
[11] 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 3010, December 2000. version 4 Protocol", RFC 3010, December 2000.
[12] Nowicki, B., "NFS: Network File System Protocol specification", [12] 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 [13] 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", [14] Srinivasan, R., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. RFC 1832, August 1995.
[15] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [15] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996. June 1996.
[16] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [16] 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 [17] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 2373, July 1998.
[18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
[19] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [19] 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 [20] 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",
skipping to change at page 240, line 8 skipping to change at page 241, line 8
September 1981. September 1981.
[28] Juszczak, C., "Improving the Performance and Correctness of an [28] Juszczak, C., "Improving the Performance and Correctness of an
NFS Server", USENIX Conference Proceedings , June 1990. NFS Server", USENIX Conference Proceedings , June 1990.
[29] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [29] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[30] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation [30] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation
for WebNFS", RFC 2755, January 2000. for WebNFS", RFC 2755, January 2000.
[31] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[32] Noveck, D. and R. Burnett, "Implementation Guide for Referrals
in NFSv4", draft-ietf-nfsv4-referrals-00 (work in progress),
July 2005.
[33] Shepler, S., Eisler, M., and D. Noveck, "Network File System
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661,
January 2010.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
Rob Thurlow clarified how a client should contact a new server if a
migration has occured.
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
Author's Address Author's Address
Thomas Haynes Thomas Haynes
Sun Microsystems, Inc. Oracle
9110 E 66th St 9110 E 66th St
Tulsa, OK 74133 Tulsa, OK 74133
USA USA
Phone: +1-918-307-1415 Phone: +1-918-307-1415
Email: thomas.haynes@sun.com Email: tom.haynes@oracle.com
URI: http://blogs.sun.com/tdh
 End of changes. 31 change blocks. 
55 lines changed or deleted 95 lines changed or added

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