draft-ietf-nfsv4-rfc3530bis-25.txt   draft-ietf-nfsv4-rfc3530bis-26.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track EMC Intended status: Standards Track EMC
Expires: August 29, 2013 February 25, 2013 Expires: November 9, 2013 May 08, 2013
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-25.txt draft-ietf-nfsv4-rfc3530bis-26.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 August 29, 2013. This Internet-Draft will expire on November 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 9 1.1. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 9
1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 10 1.2. Inconsistencies of this Document with the companion
1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 11 document NFS Version 4 Protocol . . . . . . . . . . . . 10
1.4. Inconsistencies of this Document with the companion 1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 10
document NFS Version 4 Protocol . . . . . . . . . . . . 11 1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 10
1.5. Overview of NFSv4 Features . . . . . . . . . . . . . . . 12 1.3.2. Procedure and Operation Structure . . . . . . . . . 10
1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12 1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 11
1.5.2. Procedure and Operation Structure . . . . . . . . . 12 1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 13
1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13 1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 13
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15 1.3.6. Client Caching and Delegation . . . . . . . . . . . 14
1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15 1.4. General Definitions . . . . . . . . . . . . . . . . . . 14
1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 16
1.6. General Definitions . . . . . . . . . . . . . . . . . . 16 1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . 24 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 25
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 26
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 27
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 27 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 27 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 29
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 28 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 30
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 31
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 31
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31
4.2.1. General Properties of a Filehandle . . . . . . . . . 31 4.2.1. General Properties of a Filehandle . . . . . . . . . 32
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 31 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 33
4.2.4. One Method of Constructing a Volatile Filehandle . . 33 4.2.4. One Method of Constructing a Volatile Filehandle . . 34
4.3. Client Recovery from Filehandle Expiration . . . . . . . 33 4.3. Client Recovery from Filehandle Expiration . . . . . . . 34
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 34 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 35 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 37
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37
5.4. Classification of Attributes . . . . . . . . . . . . . . 38 5.4. Classification of Attributes . . . . . . . . . . . . . . 39
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 38 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39
5.6. REQUIRED Attributes - List and Definition References . . 39 5.6. REQUIRED Attributes - List and Definition References . . 40
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 40 References . . . . . . . . . . . . . . . . . . . . . . . 41
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 42
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 42
5.8.2. Definitions of Uncategorized RECOMMENDED 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 43 Attributes . . . . . . . . . . . . . . . . . . . . . 44
5.9. Interpreting owner and owner_group . . . . . . . . . . . 49 5.9. Interpreting owner and owner_group . . . . . . . . . . . 50
5.10. Character Case Attributes . . . . . . . . . . . . . . . 52 5.10. Character Case Attributes . . . . . . . . . . . . . . . 53
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 52 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 53 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 53 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 72
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 72 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73
7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 74 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 75
7.1. Location Attributes . . . . . . . . . . . . . . . . . . 74 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 75
7.2. File System Presence or Absence . . . . . . . . . . . . 75 7.2. File System Presence or Absence . . . . . . . . . . . . 76
7.3. Getting Attributes for an Absent File System . . . . . . 76 7.3. Getting Attributes for an Absent File System . . . . . . 77
7.3.1. GETATTR Within an Absent File System . . . . . . . . 76 7.3.1. GETATTR Within an Absent File System . . . . . . . . 77
7.3.2. READDIR and Absent File Systems . . . . . . . . . . 77 7.3.2. READDIR and Absent File Systems . . . . . . . . . . 78
7.4. Uses of Location Information . . . . . . . . . . . . . . 77 7.4. Uses of Location Information . . . . . . . . . . . . . . 78
7.4.1. File System Replication . . . . . . . . . . . . . . 78 7.4.1. File System Replication . . . . . . . . . . . . . . 79
7.4.2. File System Migration . . . . . . . . . . . . . . . 79 7.4.2. File System Migration . . . . . . . . . . . . . . . 80
7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 80 7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 81
7.5. Location Entries and Server Identity . . . . . . . . . . 80 7.5. Location Entries and Server Identity . . . . . . . . . . 81
7.6. Additional Client-Side Considerations . . . . . . . . . 81 7.6. Additional Client-Side Considerations . . . . . . . . . 82
7.7. Effecting File System Transitions . . . . . . . . . . . 82 7.7. Effecting File System Transitions . . . . . . . . . . . 83
7.7.1. File System Transitions and Simultaneous Access . . 83 7.7.1. File System Transitions and Simultaneous Access . . 84
7.7.2. Filehandles and File System Transitions . . . . . . 84 7.7.2. Filehandles and File System Transitions . . . . . . 85
7.7.3. Fileids and File System Transitions . . . . . . . . 84 7.7.3. Fileids and File System Transitions . . . . . . . . 85
7.7.4. Fsids and File System Transitions . . . . . . . . . 85 7.7.4. Fsids and File System Transitions . . . . . . . . . 86
7.7.5. The Change Attribute and File System Transitions . . 86 7.7.5. The Change Attribute and File System Transitions . . 87
7.7.6. Lock State and File System Transitions . . . . . . . 86 7.7.6. Lock State and File System Transitions . . . . . . . 87
7.7.7. Write Verifiers and File System Transitions . . . . 88 7.7.7. Write Verifiers and File System Transitions . . . . 89
7.7.8. Readdir Cookies and Verifiers and File System 7.7.8. Readdir Cookies and Verifiers and File System
Transitions . . . . . . . . . . . . . . . . . . . . 88 Transitions . . . . . . . . . . . . . . . . . . . . 89
7.7.9. File System Data and File System Transitions . . . . 89 7.7.9. File System Data and File System Transitions . . . . 90
7.8. Effecting File System Referrals . . . . . . . . . . . . 90 7.8. Effecting File System Referrals . . . . . . . . . . . . 91
7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 90 7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 91
7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 94 7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 95
7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 97 7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 98
7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 98 7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 99
8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 100 8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 101
8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 100 8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 101
8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 100 8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 101
8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 100 8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 101
8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 101 8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 102
8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 101 8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 102
8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 101 8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 102
8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 102 8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 103
8.8. Security Policy and Name Space Presentation . . . . . . 102 8.8. Security Policy and Name Space Presentation . . . . . . 103
9. File Locking and Share Reservations . . . . . . . . . . . . . 103 9. File Locking and Share Reservations . . . . . . . . . . . . . 104
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 104 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 105
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 104 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 105
9.1.2. Server Release of Client ID . . . . . . . . . . . . 107 9.1.2. Server Release of Client ID . . . . . . . . . . . . 108
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 108 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 109
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 114 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 115
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 115 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 116
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 117 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 118
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 118 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 119
9.1.8. Interactions of multiple sequence values . . . . . . 118 9.1.8. Interactions of multiple sequence values . . . . . . 119
9.1.9. Releasing state-owner State . . . . . . . . . . . . 119 9.1.9. Releasing state-owner State . . . . . . . . . . . . 120
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 120 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 121
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 122
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 122
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 123
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 124
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 125
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 125
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 125
9.6.3. Network Partitions and Recovery . . . . . . . . . . 126 9.6.3. Network Partitions and Recovery . . . . . . . . . . 127
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 135
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 134 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 135
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 135 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 136
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 137
9.10.1. Close and Retention of State Information . . . . . . 137 9.10.1. Close and Retention of State Information . . . . . . 138
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 139
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 139 Expiration . . . . . . . . . . . . . . . . . . . . . . . 140
9.14. Migration, Replication and State . . . . . . . . . . . . 139 9.14. Migration, Replication and State . . . . . . . . . . . . 140
9.14.1. Migration and State . . . . . . . . . . . . . . . . 140 9.14.1. Migration and State . . . . . . . . . . . . . . . . 141
9.14.2. Replication and State . . . . . . . . . . . . . . . 141 9.14.2. Replication and State . . . . . . . . . . . . . . . 142
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 142
9.14.4. Migration and the Lease_time Attribute . . . . . . . 142 9.14.4. Migration and the Lease_time Attribute . . . . . . . 143
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 142 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 143
10.1. Performance Challenges for Client-Side Caching . . . . . 143 10.1. Performance Challenges for Client-Side Caching . . . . . 144
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 144 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 145
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 146 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 150 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 151
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 150 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 151
10.3.2. Data Caching and File Locking . . . . . . . . . . . 151 10.3.2. Data Caching and File Locking . . . . . . . . . . . 152
10.3.3. Data Caching and Mandatory File Locking . . . . . . 153 10.3.3. Data Caching and Mandatory File Locking . . . . . . 154
10.3.4. Data Caching and File Identity . . . . . . . . . . . 153 10.3.4. Data Caching and File Identity . . . . . . . . . . . 154
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 154 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 155
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 157 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 158
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 158 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 159
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 158 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 159
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 161 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 162
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 163 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 164
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 164 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 165
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 165 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 166
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 165 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 166
10.5.1. Revocation Recovery for Write Open Delegation . . . 166 10.5.1. Revocation Recovery for Write Open Delegation . . . 167
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 167 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 168
10.7. Data and Metadata Caching and Memory Mapped Files . . . 169 10.7. Data and Metadata Caching and Memory Mapped Files . . . 170
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 171 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 172
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 172 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 173
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 173 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 174
12. Internationalization . . . . . . . . . . . . . . . . . . . . 175 12. Internationalization . . . . . . . . . . . . . . . . . . . . 176
12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 176 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 177
12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 176 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 177
12.1.2. Normalization, Equivalence, and Confusability . . . 177 12.1.2. Normalization, Equivalence, and Confusability . . . 178
12.2. String Type Overview . . . . . . . . . . . . . . . . . . 180 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 181
12.2.1. Overall String Class Divisions . . . . . . . . . . . 180 12.2.1. Overall String Class Divisions . . . . . . . . . . . 181
12.2.2. Divisions by Typedef Parent types . . . . . . . . . 181 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 182
12.2.3. Individual Types and Their Handling . . . . . . . . 182 12.2.3. Individual Types and Their Handling . . . . . . . . 183
12.3. Errors Related to Strings . . . . . . . . . . . . . . . 183 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 184
12.4. Types with Pre-processing to Resolve Mixture Issues . . 184 12.4. Types with Pre-processing to Resolve Mixture Issues . . 185
12.4.1. Processing of Principal Strings . . . . . . . . . . 184 12.4.1. Processing of Principal Strings . . . . . . . . . . 185
12.4.2. Processing of Server Id Strings . . . . . . . . . . 185 12.4.2. Processing of Server Id Strings . . . . . . . . . . 186
12.5. String Types without Internationalization Processing . . 185 12.5. String Types without Internationalization Processing . . 186
12.6. Types with Processing Defined by Other Internet Areas . 186 12.6. Types with Processing Defined by Other Internet Areas . 187
12.7. String Types with NFS-specific Processing . . . . . . . 187 12.7. String Types with NFS-specific Processing . . . . . . . 188
12.7.1. Handling of File Name Components . . . . . . . . . . 187 12.7.1. Handling of File Name Components . . . . . . . . . . 188
12.7.2. Processing of Link Text . . . . . . . . . . . . . . 196 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 197
12.7.3. Processing of Principal Prefixes . . . . . . . . . . 197 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 198
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 198 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 199
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 198 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 199
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 200 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 201
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 201 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 202
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 203 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 204
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 203 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 204
13.1.5. State Management Errors . . . . . . . . . . . . . . 205 13.1.5. State Management Errors . . . . . . . . . . . . . . 206
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 206 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 207
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 207 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 208
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 208 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 209
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 209 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 210
13.1.10. Client Management Errors . . . . . . . . . . . . . . 210 13.1.10. Client Management Errors . . . . . . . . . . . . . . 211
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 210 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 211
13.2. Operations and their valid errors . . . . . . . . . . . 211 13.2. Operations and their valid errors . . . . . . . . . . . 212
13.3. Callback operations and their valid errors . . . . . . . 218 13.3. Callback operations and their valid errors . . . . . . . 219
13.4. Errors and the operations that use them . . . . . . . . 218 13.4. Errors and the operations that use them . . . . . . . . 219
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 223 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 224
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 223 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 224
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 224 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 225
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 225 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 226
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 225 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 226
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 225 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 226
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 225 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 226
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 226 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 227
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 229 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 230
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 232 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 233
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 233 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 234
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 236 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 237
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 238 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 239
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 240 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 241
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 240 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 241
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 242 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 243
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 243 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 244
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 245 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 246
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 249 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 250
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 251 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 252
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 252 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 253
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 254 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 255
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 255 Attributes . . . . . . . . . . . . . . . . . . . . . . . 256
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 256 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 257
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 266 Directory . . . . . . . . . . . . . . . . . . . . . . . 267
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 267 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 268
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 269 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 270
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 270 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 271
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 271 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 272
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 272 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 273
15.25. Operation 25: READ - Read from File . . . . . . . . . . 273 15.25. Operation 25: READ - Read from File . . . . . . . . . . 274
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 275 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 276
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 279 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 280
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 280 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 281
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 282 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 283
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 284 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 285
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 285 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 286
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 286 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 287
15.33. Operation 33: SECINFO - Obtain Available Security . . . 287 15.33. Operation 33: SECINFO - Obtain Available Security . . . 288
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 291 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 292
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 293 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 294
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 297 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 298
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 300 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 301
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 302 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 303
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 306 State . . . . . . . . . . . . . . . . . . . . . . . . . 307
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 307 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 308
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 308 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 309
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 308 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 309
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 308 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 309
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 310 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 311
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 311 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 312
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 312 Operation . . . . . . . . . . . . . . . . . . . . . 313
17. Security Considerations . . . . . . . . . . . . . . . . . . . 313 17. Security Considerations . . . . . . . . . . . . . . . . . . . 314
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 315 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 316
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 315 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 316
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 316 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 317
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 316 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 317
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 316 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 317
19.1. Normative References . . . . . . . . . . . . . . . . . . 316 19.1. Normative References . . . . . . . . . . . . . . . . . . 317
19.2. Informative References . . . . . . . . . . . . . . . . . 317 19.2. Informative References . . . . . . . . . . . . . . . . . 318
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 320 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 321
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 320 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 322
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 322
1. Introduction 1. Introduction
1.1. Changes since RFC 3530 1.1. NFS Version 4 Goals
This document, together with the companion XDR description document
[I-D.ietf-nfsv4-rfc3530bis-dot-x], obsoletes RFC 3530 [RFC3530] as
the authoritative document describing NFSv4. It does not introduce
any over-the-wire protocol changes, in the sense that previously
valid requests requests remain valid. However, some requests
previously defined as invalid, although not generally rejected, are
now explicitly allowed, in that internationalization handling has
been generalized and liberalized. The main changes from RFC 3530
are:
o The XDR definition has been moved to a companion document
[I-D.ietf-nfsv4-rfc3530bis-dot-x]
o Updates for the latest IETF intellectual property statements
o There is a restructured and more complete explanation of multi-
server namespace features. In particular, this explanation
explicitly describes handling of inter-server referrals, even
where neither migration nor replication is involved.
o More liberal handling of internationalization for file names and
user and group names, with the elimination of restrictions imposed
by stringprep, with the recognition that rules for the forms of
these name are the province of the receiving entity.
o Updating handling of domain names to reflect IDNA [RFC5891].
o Restructuring of string types to more appropriately reflect the
reality of required string processing.
o The previously required LIPKEY and SPKM-3 security mechanisms have
been removed.
o Some clarification on a client re-establishing callback
information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network
partitions.
o The definition of stateid was strengthened.
1.2. Changes since RFC 3010
This definition of the NFSv4 protocol replaces or obsoletes the
definition present in [RFC3010]. While portions of the two documents
have remained the same, there have been substantive changes in
others. The changes made between [RFC3010] and this document
represent implementation experience and further review of the
protocol. While some modifications were made for ease of
implementation or clarification, most updates represent errors or
situations where the [RFC3010] definition were untenable.
The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that
is locking a file.
o Clarifications and error conditions were added for the handling of
the owner and group attributes. Since these attributes are string
based (as opposed to the numeric uid/gid of previous versions of
NFS), translations may not be available and hence the changes
made.
o Clarifications for the ACL and mode attributes to address
evaluation and partial support.
o For identifiers that are defined as XDR opaque, limits were set on
their size.
o Added the mounted_on_filed attribute to allow Posix clients to
correctly construct local mounts.
o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal
correctly with confirmation details along with adding the ability
to specify new client callback information. Also added
clarification of the callback information itself.
o Added a new operation RELEASE_LOCKOWNER to enable notifying the
server that a lock_owner4 will no longer be used by the client.
o RENEW operation changes to identify the client correctly and allow
for additional error returns.
o Verify error return possibilities for all operations.
o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect.
o Clarification of the internationalization issues and adoption of
the new stringprep profile framework.
1.3. NFS Version 4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The Network Filesystem version 4 (NFSv4) protocol is a further
already by versions 2 [RFC1094] and 3 [RFC1813]. It retains the revision of the NFS protocol defined already by versions 2 [RFC1094]
essential characteristics of previous versions: design for easy and 3 [RFC1813]. It retains the essential characteristics of
recovery, independent of transport protocols, operating systems and previous versions: design for easy recovery, independent of transport
filesystems, simplicity, and good performance. The NFSv4 revision protocols, operating systems and filesystems, simplicity, and good
has the following goals: performance. The NFSv4 revision has the following goals:
o Improved access and good performance on the Internet. o Improved access and good performance on the Internet.
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
o Strong security with negotiation built into the protocol. o Strong security with negotiation built into the protocol.
The protocol builds on the work of the ONCRPC working group in The protocol builds on the work of the ONCRPC working group in
skipping to change at page 11, line 48 skipping to change at page 9, line 41
The protocol features a filesystem model that provides a useful, The protocol features a filesystem model that provides a useful,
common set of features that does not unduly favor one filesystem common set of features that does not unduly favor one filesystem
or operating system over another. or operating system over another.
o Designed for protocol extensions. o Designed for protocol extensions.
The protocol is designed to accept standard extensions that do not The protocol is designed to accept standard extensions that do not
compromise backward compatibility. compromise backward compatibility.
1.4. Inconsistencies of this Document with the companion document NFS This document, together with the companion XDR description document
[I-D.ietf-nfsv4-rfc3530bis-dot-x], obsoletes RFC 3530 [RFC3530] as
the authoritative document describing NFSv4. It does not introduce
any over-the-wire protocol changes, in the sense that previously
valid requests requests remain valid. However, some requests
previously defined as invalid, although not generally rejected, are
now explicitly allowed, in that internationalization handling has
been generalized and liberalized.
1.2. Inconsistencies of this Document with the companion document NFS
Version 4 Protocol Version 4 Protocol
[I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains [I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains
the definitions in XDR description language of the constructs used by the definitions in XDR description language of the constructs used by
the protocol. Inside this document, several of the constructs are the protocol. Inside this document, several of the constructs are
reproduced for purposes of explanation. The reader is warned of the reproduced for purposes of explanation. The reader is warned of the
possibility of errors in the reproduced constructs outside of possibility of errors in the reproduced constructs outside of
[I-D.ietf-nfsv4-rfc3530bis-dot-x]. For any part of the document that [I-D.ietf-nfsv4-rfc3530bis-dot-x]. For any part of the document that
is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x], is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x],
[I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative. [I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative.
1.5. Overview of NFSv4 Features 1.3. 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 [RFC5531] and familiar with the XDR and RPC protocols as described in [RFC5531] and
[RFC4506]. A basic knowledge of filesystems and distributed [RFC4506]. A basic knowledge of filesystems and distributed
filesystems is expected as well. filesystems is expected as well.
1.5.1. RPC and Security 1.3.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 [RFC5531] and [RFC4506]. To meet end protocol are those defined in [RFC5531] and [RFC4506]. To meet end
to end security requirements, the RPCSEC_GSS framework [RFC2203] will to end security requirements, the RPCSEC_GSS framework [RFC2203] will
be used to extend the basic RPC security. With the use of be used to extend the basic RPC security. With the use of
RPCSEC_GSS, various mechanisms can be provided to offer RPCSEC_GSS, various mechanisms can be provided to offer
authentication, integrity, and privacy to the NFS version 4 protocol. authentication, integrity, and privacy to the NFS version 4 protocol.
Kerberos V5 will be used as described in [RFC4121] to provide one Kerberos V5 will be used as described in [RFC4121] to provide one
security framework. With the use of RPCSEC_GSS, other mechanisms may security framework. With the use of RPCSEC_GSS, other mechanisms may
also be specified and used for NFS version 4 security. also be specified and used for NFS version 4 security.
To enable in-band security negotiation, the NFSv4 protocol has added To enable in-band security negotiation, the NFSv4 protocol has added
a new operation which provides the client a method of querying the a new operation which provides the client a method of querying the
server about its policies regarding which security mechanisms must be server about its policies regarding which security mechanisms must be
used for access to the server's filesystem resources. With this, the used for access to the server's filesystem resources. With this, the
client can securely match the security mechanism that meets the client can securely match the security mechanism that meets the
policies specified at both the client and server. policies specified at both the client and server.
1.5.2. Procedure and Operation Structure 1.3.2. Procedure and Operation Structure
A significant departure from the previous versions of the NFS A significant departure from the previous versions of the NFS
protocol is the introduction of the COMPOUND procedure. For the protocol is the introduction of the COMPOUND procedure. For the
NFSv4 protocol, there are two RPC procedures, NULL and COMPOUND. The NFSv4 protocol, there are two RPC procedures, NULL and COMPOUND. The
COMPOUND procedure is defined in terms of operations and these COMPOUND procedure is defined in terms of operations and these
operations correspond more closely to the traditional NFS procedures. operations correspond more closely to the traditional NFS procedures.
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 filesystem reduction in the number of RPCs needed for logical filesystem
skipping to change at page 13, line 27 skipping to change at page 11, line 32
The NFSv4 protocol continues to have the client refer to a file or The NFSv4 protocol continues to have the client refer to a file or
directory at the server by a "filehandle". The COMPOUND procedure directory at the server by a "filehandle". The COMPOUND procedure
has a method of passing a filehandle from one operation to another has a method of passing a filehandle from one operation to another
within the sequence of operations. There is a concept of a "current within the sequence of operations. There is a concept of a "current
filehandle" and "saved filehandle". Most operations use the "current filehandle" and "saved filehandle". Most operations use the "current
filehandle" as the filesystem object to operate upon. The "saved filehandle" as the filesystem object to operate upon. The "saved
filehandle" is used as temporary filehandle storage within a COMPOUND filehandle" is used as temporary filehandle storage within a COMPOUND
procedure as well as an additional operand for certain operations. procedure as well as an additional operand for certain operations.
1.5.3. Filesystem Model 1.3.3. Filesystem Model
The general filesystem model used for the NFSv4 protocol is the same The general filesystem model used for the NFSv4 protocol is the same
as previous versions. The server filesystem is hierarchical with the as previous versions. The server filesystem is hierarchical with the
regular files contained within being treated as opaque byte streams. regular files contained within being treated as opaque byte streams.
In a slight departure, file and directory names are encoded with In a slight departure, file and directory names are encoded with
UTF-8 to deal with the basics of internationalization. UTF-8 to deal with the basics of internationalization.
The NFSv4 protocol does not require a separate protocol to provide The NFSv4 protocol does not require a separate protocol to provide
for the initial mapping between path name and filehandle. Instead of for the initial mapping between path name and filehandle. Instead of
using the older MOUNT protocol for this mapping, the server provides using the older MOUNT protocol for this mapping, the server provides
a ROOT filehandle that represents the logical root or top of the a ROOT filehandle that represents the logical root or top of the
filesystem tree provided by the server. The server provides multiple filesystem tree provided by the server. The server provides multiple
filesystems by gluing them together with pseudo filesystems. These filesystems by gluing them together with pseudo filesystems. These
pseudo filesystems provide for potential gaps in the path names pseudo filesystems provide for potential gaps in the path names
between real filesystems. between real filesystems.
1.5.3.1. Filehandle Types 1.3.3.1. Filehandle Types
In previous versions of the NFS protocol, the filehandle provided by In previous versions of the NFS protocol, the filehandle provided by
the server was guaranteed to be valid or persistent for the lifetime the server was guaranteed to be valid or persistent for the lifetime
of the filesystem object to which it referred. For some server of the filesystem object to which it referred. For some server
implementations, this persistence requirement has been difficult to implementations, this persistence requirement has been difficult to
meet. For the NFSv4 protocol, this requirement has been relaxed by meet. For the NFSv4 protocol, this requirement has been relaxed by
introducing another type of filehandle, volatile. With persistent introducing another type of filehandle, volatile. With persistent
and volatile filehandle types, the server implementation can match and volatile filehandle types, the server implementation can match
the abilities of the filesystem at the server along with the the abilities of the filesystem at the server along with the
operating environment. The client will have knowledge of the type of operating environment. The client will have knowledge of the type of
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.3.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 attributes of NFSv3 (see definition of the fattr3 data type in
[RFC1813]). An example of a REQUIRED attribute is the file object's [RFC1813]). An example of a REQUIRED attribute is the file object's
type (Section 5.8.1.2) so that regular files can be distinguished type (Section 5.8.1.2) so that regular files can be distinguished
from directories (also known as folders in some operating from directories (also known as folders in some operating
skipping to change at page 14, line 42 skipping to change at page 13, line 5
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 implementations. Named attributes are discussed in interoperable implementations. Named attributes are discussed in
Section 5.3. Section 5.3.
1.5.3.3. Multi-server Namespace 1.3.3.3. Multi-server Namespace
NFSv4 contains a number of features to allow implementation of NFSv4 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.
These attributes may be used together with the concept of absent file These attributes may be used together with the concept of absent file
systems, which provide specifications for additional locations but no systems, which provide specifications for additional locations but no
skipping to change at page 15, line 22 skipping to change at page 13, line 33
o Location attributes may be provided for present file systems to o Location attributes may be provided for present file systems to
provide the locations of alternate file system instances or provide the locations of alternate file system instances or
replicas to be used in the event that the current file system replicas to be used in the event that the current file system
instance becomes unavailable. instance becomes unavailable.
o Location attributes may be provided when a previously present file o Location attributes may be provided when a previously present file
system becomes absent. This allows non-disruptive migration of system becomes absent. This allows non-disruptive migration of
file systems to alternate servers. file systems to alternate servers.
1.5.4. OPEN and CLOSE 1.3.4. OPEN and CLOSE
The NFSv4 protocol introduces OPEN and CLOSE operations. The OPEN The NFSv4 protocol introduces OPEN and CLOSE operations. The OPEN
operation provides a single point where file lookup, creation, and operation provides a single point where file lookup, creation, and
share semantics can be combined. The CLOSE operation also provides share semantics can be combined. The CLOSE operation also provides
for the release of state accumulated by OPEN. for the release of state accumulated by OPEN.
1.5.5. File Locking 1.3.5. File Locking
With the NFSv4 protocol, the support for byte range file locking is With the NFSv4 protocol, the support for byte range file locking is
part of the NFS protocol. The file locking support is structured so part of the NFS protocol. The file locking support is structured so
that an RPC callback mechanism is not required. This is a departure that an RPC callback mechanism is not required. This is a departure
from the previous versions of the NFS file locking protocol, Network from the previous versions of the NFS file locking protocol, Network
Lock Manager (NLM). The state associated with file locks is Lock Manager (NLM). The state associated with file locks is
maintained at the server under a lease-based model. The server maintained at the server under a lease-based model. The server
defines a single lease period for all state held by a NFS client. If defines a single lease period for all state held by a NFS client. If
the client does not renew its lease within the defined period, all the client does not renew its lease within the defined period, all
state associated with the client's lease may be released by the state associated with the client's lease may be released by the
server. The client may renew its lease with use of the RENEW server. The client may renew its lease with use of the RENEW
operation or implicitly by use of other operations (primarily READ). operation or implicitly by use of other operations (primarily READ).
1.5.6. Client Caching and Delegation 1.3.6. Client Caching and Delegation
The file, attribute, and directory caching for the NFSv4 protocol is The file, attribute, and directory caching for the NFSv4 protocol is
similar to previous versions. Attributes and directory information similar to previous versions. Attributes and directory information
are cached for a duration determined by the client. At the end of a are cached for a duration determined by the client. At the end of a
predefined timeout, the client will query the server to see if the predefined timeout, the client will query the server to see if the
related filesystem object has been updated. related filesystem object has been updated.
For file data, the client checks its cache validity when the file is For file data, the client checks its cache validity when the file is
opened. A query is sent to the server to determine if the file has opened. A query is sent to the server to determine if the file has
been changed. Based on this information, the client determines if been changed. Based on this information, the client determines if
skipping to change at page 16, line 34 skipping to change at page 14, line 44
Delegations can be recalled by the server. If another client Delegations can be recalled by the server. If another client
requests access to the file in such a way that the access conflicts requests access to the file in such a way that the access conflicts
with the granted delegation, the server is able to notify the initial with the granted delegation, the server is able to notify the initial
client and recall the delegation. This requires that a callback path client and recall the delegation. This requires that a callback path
exist between the server and client. If this callback path does not exist between the server and client. If this callback path does not
exist, then delegations cannot be granted. The essence of a exist, then delegations cannot be granted. The essence of a
delegation is that it allows the client to locally service operations delegation is that it allows the client to locally service operations
such as OPEN, CLOSE, LOCK, LOCKU, READ, or WRITE without immediate such as OPEN, CLOSE, LOCK, LOCKU, READ, or WRITE without immediate
interaction with the server. interaction with the server.
1.6. General Definitions 1.4. General Definitions
The following definitions are provided for the purpose of providing The following definitions are provided for the purpose of providing
an appropriate context for the reader. an appropriate context for the reader.
Byte: In this document, a byte is an octet, i.e., a datum exactly 8 Byte: In this document, a byte is an octet, i.e., a datum exactly 8
bits in length. bits in length.
Client: The client is the entity that accesses the NFS server's Client: The client is the entity that accesses the NFS server's
resources. The client may be an application that contains the resources. The client may be an application that contains the
logic to access the NFS server directly. The client may also be logic to access the NFS server directly. The client may also be
skipping to change at page 18, line 20 skipping to change at page 16, line 28
Stateid: A stateid is a 128-bit quantity returned by a server that Stateid: A stateid is a 128-bit quantity returned by a server that
uniquely identifies the open and locking states provided by the uniquely identifies the open and locking states provided by the
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.
1.5. Changes since RFC 3530
The main changes from RFC 3530 [RFC3530] are:
o The XDR definition has been moved to a companion document
[I-D.ietf-nfsv4-rfc3530bis-dot-x]
o Updates for the latest IETF intellectual property statements
o There is a restructured and more complete explanation of multi-
server namespace features. In particular, this explanation
explicitly describes handling of inter-server referrals, even
where neither migration nor replication is involved.
o More liberal handling of internationalization for file names and
user and group names, with the elimination of restrictions imposed
by stringprep, with the recognition that rules for the forms of
these name are the province of the receiving entity.
o Updating handling of domain names to reflect IDNA [RFC5891].
o Restructuring of string types to more appropriately reflect the
reality of required string processing.
o The previously required LIPKEY and SPKM-3 security mechanisms have
been removed.
o Some clarification on a client re-establishing callback
information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network
partitions.
o The definition of stateid was strengthened.
1.6. Changes since RFC 3010
This definition of the NFSv4 protocol replaces or obsoletes the
definition present in [RFC3010]. While portions of the two documents
have remained the same, there have been substantive changes in
others. The changes made between [RFC3010] and this document
represent implementation experience and further review of the
protocol. While some modifications were made for ease of
implementation or clarification, most updates represent errors or
situations where the [RFC3010] definition were untenable.
The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that
is locking a file.
o Clarifications and error conditions were added for the handling of
the owner and group attributes. Since these attributes are string
based (as opposed to the numeric uid/gid of previous versions of
NFS), translations may not be available and hence the changes
made.
o Clarifications for the ACL and mode attributes to address
evaluation and partial support.
o For identifiers that are defined as XDR opaque, limits were set on
their size.
o Added the mounted_on_fileid attribute to allow Posix clients to
correctly construct local mounts.
o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal
correctly with confirmation details along with adding the ability
to specify new client callback information. Also added
clarification of the callback information itself.
o Added a new operation RELEASE_LOCKOWNER to enable notifying the
server that a lock_owner4 will no longer be used by the client.
o RENEW operation changes to identify the client correctly and allow
for additional error returns.
o Verify error return possibilities for all operations.
o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect.
o Clarification of the internationalization issues and adoption of
the new stringprep profile framework.
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 [RFC4506] and RPC [RFC5531] version 4 protocol are defined in the XDR [RFC4506] and RPC [RFC5531]
documents. The next sections build upon the XDR data types to define documents. The next sections build upon the XDR data types to define
types and structures specific to this protocol. types and structures specific to this protocol.
2.1. Basic Data Types 2.1. Basic Data Types
These are the base NFSv4 data types. These are the base NFSv4 data types.
skipping to change at page 19, line 21 skipping to change at page 19, line 26
| | Various defined file types. | | | Various defined file types. |
| nfsstat4 | enum nfsstat4; | | nfsstat4 | enum nfsstat4; |
| | Return value for operations. | | | Return value for operations. |
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, | | | Various offset designations (READ, WRITE, |
| | LOCK, COMMIT). | | | LOCK, COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in | | | Quality of protection designation in |
| | SECINFO. | | | SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 | | | Security Object Identifier. The sec_oid4 |
| | data type is not really opaque. Instead it | | | data type is not really opaque. Instead |
| | contains an ASN.1 OBJECT IDENTIFIER as | | | it contains an ASN.1 OBJECT IDENTIFIER as |
| | used by GSS-API in the mech_type argument | | | used by GSS-API in the mech_type argument |
| | to GSS_Init_sec_context. See [RFC2743] for | | | to GSS_Init_sec_context. See [RFC2743] |
| | details. | | | for details. |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| utf8string | typedef opaque utf8string<>; | | utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8_expected | typedef utf8string utf8_expected; | | utf8_expected | typedef utf8string utf8_expected; |
| | String expected to be UTF-8 but no | | | String expected to be UTF-8 but no |
| | validation | | | validation |
| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |
| | String SHOULD be sent UTF-8 and SHOULD be | | | String SHOULD be sent UTF-8 and SHOULD be |
| | validated | | | validated |
skipping to change at page 26, line 43 skipping to change at page 27, line 7
additional security flavor of RPCSEC_GSS has been introduced which additional security flavor of RPCSEC_GSS has been introduced which
uses the functionality of GSS-API [RFC2743]. This allows for the use uses the functionality of GSS-API [RFC2743]. This allows for the use
of various security mechanisms by the RPC layer without the of various security mechanisms by the RPC layer without the
additional implementation overhead of adding RPC security flavors. additional implementation overhead of adding RPC security flavors.
For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the
mandatory security mechanism. Other flavors, such as, AUTH_NONE, mandatory security mechanism. Other flavors, such as, AUTH_NONE,
AUTH_SYS, and AUTH_DH MAY be implemented as well. AUTH_SYS, and AUTH_DH MAY be implemented as well.
3.2.1. Security mechanisms for NFSv4 3.2.1. Security mechanisms for NFSv4
The use of RPCSEC_GSS requires selection of: mechanism, quality of RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide
protection, and service (authentication, integrity, privacy). The security services. Therefore, NFSv4 clients and servers MUST support
remainder of this document will refer to these three parameters of the Kerberos V5 security mechanism.
the RPCSEC_GSS security as the security triple.
The use of RPCSEC_GSS requires selection of mechanism, quality of
protection (QOP), and service (authentication, integrity, privacy).
For the mandated security mechanisms, NFSv4 specifies that a QOP of
zero is used, leaving it up to the mechanism or the mechanism's
configuration to map QOP zero to an appropriate level of protection.
Each mandated mechanism specifies a minimum set of cryptographic
algorithms for implementing integrity and privacy. NFSv4 clients and
servers MUST be implemented on operating environments that comply
with the REQUIRED cryptographic algorithms of each REQUIRED
mechanism.
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 [RFC4121] MUST be The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be
implemented and provide the following security triples. implemented with the RPCSEC_GSS services as specified in the
following table:
column descriptions:
1 == number of pseudo flavor column descriptions:
2 == name of pseudo flavor 1 == number of pseudo flavor
3 == mechanism's OID 2 == name of pseudo flavor
4 == mechanism's algorithm(s) 3 == mechanism's OID
5 == RPCSEC_GSS service 4 == RPCSEC_GSS service
5 == NFSv4 clients MUST support
6 == NFSv4 servers MUST support
1 2 3 4 5 1 2 3 4 5 6
-------------------------------------------------------------------- ------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none 390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity 390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
for integrity,
and 56 bit DES
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 as
described in [RFC2623].
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please At the time this document was specified, the Advanced Encryption
see [RFC2623]. Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for
Kerberos V5. In contrast, when NFSv4.0 was first specified in
[RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and
were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
specification at the time did not specify stronger algorithms. The
NFSv4 specification does not specify REQUIRED algorithms for Kerberos
V5, and instead, the implementor is expected to track the evolution
of the Kerberos V5 standard if and when stronger algorithms are
specified.
3.2.1.1.1. Security Considerations for Cryptographic Algorithms in
Kerberos V5
When deploying NFSv4, the strength of the security achieved depends
on the existing Kerberos V5 infrastructure. The algorithms of
Kerberos V5 are not directly exposed to or selectable by the client
or server, so there is some due diligence required by the user of
NFSv4 to ensure that security is acceptable where needed. Guidance
is provided in [RFC6649] as to why weak algorithms should be disabled
by default.
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 71, line 36 skipping to change at page 72, line 36
ACE4_READ_DATA. ACE4_READ_DATA.
2. If MODE4_WGRP is not set, entities explicitly listed in the ACL 2. If MODE4_WGRP is not set, entities explicitly listed in the ACL
other than OWNER@ and EVERYONE@ SHOULD NOT be granted other than OWNER@ and EVERYONE@ SHOULD NOT be granted
ACE4_WRITE_DATA or ACE4_APPEND_DATA. ACE4_WRITE_DATA or ACE4_APPEND_DATA.
3. If MODE4_XGRP is not set, entities explicitly listed in the ACL 3. If MODE4_XGRP is not set, entities explicitly listed in the ACL
other than OWNER@ and EVERYONE@ SHOULD NOT be granted other than OWNER@ and EVERYONE@ SHOULD NOT be granted
ACE4_EXECUTE. ACE4_EXECUTE.
Access mask bits other those listed above, appearing in ALLOW ACEs, Access mask bits other than those listed above, appearing in ALLOW
MAY also be disabled. ACEs, MAY also be disabled.
Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect
the permissions of the ACL itself, nor do ACEs of the type AUDIT and the permissions of the ACL itself, nor do ACEs of the type AUDIT and
ALARM. As such, it is desirable to leave these ACEs unmodified when ALARM. As such, it is desirable to leave these ACEs unmodified when
modifying the ACL attributes. modifying the ACL attributes.
Also note that the requirement may be met by discarding the acl in Also note that the requirement may be met by discarding the acl in
favor of an ACL that represents the mode and only the mode. This is favor of an ACL that represents the mode and only the mode. This is
permitted, but it is preferable for a server to preserve as much of permitted, but it is preferable for a server to preserve as much of
the ACL as possible without violating the above requirements. the ACL as possible without violating the above requirements.
skipping to change at page 183, line 27 skipping to change at page 184, line 27
Table 6 Table 6
The last table describes the components of the compound types The last table describes the components of the compound types
described above. described above.
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
| Type | Class | Def | Explanation | | Type | Class | Def | Explanation |
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
| svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or | | svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or |
| | | | IPv6. | | | | | IPv6. |
| svrname4 | UVMUST | INET | Server name as returned by server. Not | | svrname4 | UVMUST | INET | Server name as returned by server. |
| | | | sent by client, except in | | | | | Not sent by client, except in |
| | | | VERIFY/NVERIFY. | | | | | VERIFY/NVERIFY. |
| prinsfx4 | UVMUST | INET | Suffix part of principal, in the form | | prinsfx4 | UVMUST | INET | Suffix part of principal, in the form |
| | | | of a domain name. | | | | | of a domain name. |
| prinpfx4 | UVMUST | NFS | Must match one of a list of valid | | prinpfx4 | UVMUST | NFS | Must match one of a list of valid |
| | | | users or groups for that particular | | | | | users or groups for that particular |
| | | | domain. | | | | | domain. |
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
Table 7 Table 7
skipping to change at page 204, line 14 skipping to change at page 205, line 14
feature. feature.
13.1.4.1. NFS4ERR_BADTYPE (Error Code 10007) 13.1.4.1. NFS4ERR_BADTYPE (Error Code 10007)
An attempt was made to create an object with an inappropriate type An attempt was made to create an object with an inappropriate type
specified to CREATE. This may be because the type is undefined, specified to CREATE. This may be because the type is undefined,
because it is a type not supported by the server, or because it is a because it is a type not supported by the server, or because it is a
type for which create is not intended such as a regular file or named type for which create is not intended such as a regular file or named
attribute, for which OPEN is used to do the file creation. attribute, for which OPEN is used to do the file creation.
13.1.4.2. NFS4ERR_DQUOT (Error Code 19) 13.1.4.2. NFS4ERR_DQUOT (Error Code 69)
Resource (quota) hard limit exceeded. The user's resource limit on Resource (quota) hard limit exceeded. The user's resource limit on
the server has been exceeded. the server has been exceeded.
13.1.4.3. NFS4ERR_EXIST (Error Code 17) 13.1.4.3. NFS4ERR_EXIST (Error Code 17)
A file of the specified target name (when creating, renaming or A file of the specified target name (when creating, renaming or
linking) already exists. linking) already exists.
13.1.4.4. NFS4ERR_FBIG (Error Code 27) 13.1.4.4. NFS4ERR_FBIG (Error Code 27)
skipping to change at page 315, line 14 skipping to change at page 316, line 14
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 [RFC5226]. This section uses terms that are defined in [RFC5226].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA will create a registry called the "NFSv4 Named Attribute IANA had created a registry called the "NFSv4 Named Attribute
Definitions Registry". Definitions Registry" for [RFC3530] and [RFC5661]. This section
introduces no new changes, but it does recap the intent.
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.
An IANA registry will promote interoperability where common interests The IANA registry promotes interoperability where common interests
exist. While application developers are allowed to define and use exist. While application developers are allowed to define and use
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.
skipping to change at page 316, line 5 skipping to change at page 317, line 7
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.
The prefix "PRIV" is allocated for Private Use. A site that wants to The prefix "PRIV" is allocated for Private Use. A site that wants to
make use of unregistered named attributes without risk of conflicting make use of unregistered named attributes without risk of conflicting
with an assignment in IANA's registry should use the prefix "PRIV" in with an assignment in IANA's registry should use the prefix "PRIV" in
all of its named attributes. all of its named attributes.
Because some NFSv4 clients and servers have case insensitive Because some NFSv4 clients and servers have case insensitive
semantics, the fifteen additional lower case and mixed case semantics, the fifteen additional lower case and mixed case
permutations of each of "EXPE", "PRIV", and "STDS", are Reserved ermutations of each of "EXPE", "PRIV", and "STDS", are Reserved (e.g.
(e.g. "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA must not
must not allow two assignments that would conflict if both named allow two assignments that would conflict if both named attributes
attributes were converted to a common case. were converted to a common case.
The registry of named attributes is a list of assignments, each The registry of named attributes is a list of assignments, each
containing three fields for each assignment. containing three fields for each assignment.
1. A US-ASCII string name that is the actual name of the attribute. 1. A US-ASCII string name that is the actual name of the attribute.
This name must be unique. This string name can be 1 to 128 UTF-8 This name must be unique. This string name can be 1 to 128 UTF-8
characters long. characters long.
2. A reference to the specification of the named attribute. The 2. A reference to the specification of the named attribute. The
reference can consume up to 256 bytes (or more if IANA permits). reference can consume up to 256 bytes (or more if IANA permits).
skipping to change at page 316, line 39 skipping to change at page 317, line 41
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
Approval. Approval.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-nfsv4-rfc3530bis-dot-x] [I-D.ietf-nfsv4-rfc3530bis-dot-x]
Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR
Description", draft-ietf-nfsv4-rfc3530bis-dot-x-16 (work Description", draft-ietf-nfsv4-rfc3530bis-dot-x-17 (work
in progress), Feb 2013. in progress), May 2013.
[ISO.10646-1.1993] [ISO.10646-1.1993]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] 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.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, May 2009.
[RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure [RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure
Call (RPC) Network Identifiers and Universal Address Call (RPC) Network Identifiers and Universal Address
Formats", RFC 5665, January 2010. Formats", RFC 5665, January 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6649] Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and
Other Weak Cryptographic Algorithms in Kerberos",
RFC 6649, July 2012.
19.2. Informative References 19.2. Informative References
[Chet] Juszczak, C., "Improving the Performance and Correctness [Chet] Juszczak, C., "Improving the Performance and Correctness
of an NFS Server", USENIX Conference Proceedings , of an NFS Server", USENIX Conference Proceedings ,
June 1990. June 1990.
[Floyd] Floyd, S. and V. Jacobson, "The Synchronization of [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", IEEE/ACM Transactions on Periodic Routing Messages", IEEE/ACM Transactions on
Networking 2(2), pp. 122-136, April 1994. Networking 2(2), pp. 122-136, April 1994.
skipping to change at page 318, line 33 skipping to change at page 319, line 33
[RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security
Negotiation for WebNFS", RFC 2755, January 2000. Negotiation for WebNFS", RFC 2755, January 2000.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3010, December 2000. (NFS) version 4 Protocol", RFC 3010, December 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
skipping to change at page 320, line 44 skipping to change at page 321, line 48
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 [RFC5661]. advocate of stamping out backport issues from [RFC5661].
Marcel Telka was a champion of straightening out the difference Marcel Telka was a champion of straightening out the difference
between a lock-owner and an open-owner. He has also been diligent in between a lock-owner and an open-owner. He has also been diligent in
reviewing the final document. reviewing the final document.
Benjamin Kaduk reminded us that DES is dead and Nico Williams helped
us close the lid on the coffin.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the
RFC number assigned to the XDR document.] RFC number assigned to the XDR document.]
[RFC Editor: Please note that there is also a reference entry that [RFC Editor: Please note that there is also a reference entry that
needs to be modified for the companion document.] needs to be modified for the companion document.]
Authors' Addresses Authors' Addresses
Thomas Haynes (editor) Thomas Haynes (editor)
NetApp NetApp
9110 E 66th St 495 E Java Dr
Tulsa, OK 74133 Sunnyvale, CA 95054
USA USA
Phone: +1 918 307 1415 Phone: +1 408 419 3018
Email: thomas@netapp.com Email: thomas@netapp.com
URI: http://www.tulsalabs.com
David Noveck (editor) David Noveck (editor)
EMC Corporation EMC Corporation
228 South Street 228 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US US
Phone: +1 508 249 5748 Phone: +1 508 249 5748
Email: david.noveck@emc.com Email: david.noveck@emc.com
 End of changes. 52 change blocks. 
416 lines changed or deleted 453 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/