idnits 2.17.1 draft-ietf-nfsv4-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9353 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2025' on line 472 looks like a reference -- Missing reference section? 'RFC1094' on line 442 looks like a reference -- Missing reference section? 'RFC1813' on line 448 looks like a reference -- Missing reference section? 'RFC1831' on line 454 looks like a reference -- Missing reference section? 'RFC1832' on line 460 looks like a reference -- Missing reference section? 'RFC1833' on line 466 looks like a reference -- Missing reference section? 'RFC2078' on line 478 looks like a reference -- Missing reference section? 'RFC2203' on line 486 looks like a reference -- Missing reference section? 'Sandberg' on line 492 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Spencer Shepler 3 Internet Draft September 1998 4 Document: draft-ietf-nfsv4-requirements-00.txt 6 NFS Version 4 Requirements 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 With the creation of the NFS version 4 working group, a set of 29 requirements for the next version of NFS must be codified to create a 30 reasonable context for the new protocol discussions and aide in the 31 upcoming decisions. This Internet Draft has the purpose of 32 presenting the requirements for NFS version 4 and will be used as the 33 leading document for NFSv4 working group. 35 NFSv4 Requirements September 1998 37 Table of Contents 39 1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3 40 2. Ease of implementation or complexity of protocol . . . . . . 3 41 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3 42 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3 43 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4 44 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4 45 4.1. Throughput and Latency on the Network . . . . . . . . . . 4 46 4.2. Server Work Load or Scalability . . . . . . . . . . . . . 4 47 4.3. Client Caching . . . . . . . . . . . . . . . . . . . . . . 5 48 4.4. Disconnected Client Operation . . . . . . . . . . . . . . 5 49 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 50 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 6 51 5.2. Extended Attributes . . . . . . . . . . . . . . . . . . . 6 52 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . . 6 53 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . . 7 54 6.1. Remote Procedure Call Mechanism . . . . . . . . . . . . . 7 55 6.2. User identification . . . . . . . . . . . . . . . . . . . 7 56 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 57 6.4. Security Negotiation . . . . . . . . . . . . . . . . . . . 8 58 7. Internet Accessibility . . . . . . . . . . . . . . . . . . . 9 59 7.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 9 61 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 9 62 8. File locking / recovery . . . . . . . . . . . . . . . . . 10 63 9. Internationalization . . . . . . . . . . . . . . . . . . . 11 64 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 12 65 11. Author's Address . . . . . . . . . . . . . . . . . . . . 14 67 NFSv4 Requirements September 1998 69 1. NFS Version 4 Requirements 71 As stated in the charter the first deliverable for the NFS version 4 72 working group is this requirements document. This document is to 73 cover the "limitations and deficiencies of NFS version 3". Therefore 74 the intent of the following sections is to identify the various 75 feature points of NFS as a distributed file system and discuss its 76 current functionality and compare to other distributed file systems 77 and offer reasonable requirements for each of these areas. 79 2. Ease of implementation or complexity of protocol 81 One of the strengths of NFS has been the ability to implement a 82 client or server with comparative ease. The eventual size of a basic 83 implementation is relatively small. One reason that keeping NFS as 84 simple as possible is that a simple protocol design can be described 85 in a simple specification that promotes straightforward, 86 interoperable implementations. All protocols can run into problems 87 when deployed on real networks, but simple protocols yield problems 88 that are easier to diagnose and correct. 90 2.1. Extensibility / layering 92 With NFS' relative simplicity, the addition or layering of 93 functionality has been easy to accomplish. The addition of features 94 like the client automount or autofs, client side disk caching and 95 high availability servers are some examples. This type of 96 extensibility is desirable in an environment where problem solutions 97 do not require protocol revision. This extensibility can also be 98 helpful in the future where unforeseen problems or opportunities can 99 be solved by layering functionality on an existing set of tools or 100 protocol. 102 2.2. Managed Extensions or Minor Versioning 104 For those cases where a the protocol is deficient or where a minor 105 modification is the best solution for a problem, a minor version or a 106 managed extension of the NFS protocol would be helpful. With NFS 107 version 2, there were many minor extensions in the protocol to solve 108 problems which were unforeseen. However they were done in a way that 109 was not well documented or detection of support was not possible. A 110 new NFS protocol should allow for the rare instance where protocol 111 extension is the most prudent course and an entire revision would be 112 unnecessary or impractical. 114 NFSv4 Requirements September 1998 116 3. Reliable and Available 118 Current NFS protocol design has lead to quick recovery from server 119 and client failure. This approach to the design has lended itself 120 well to layered technologies like high availability and clustered 121 servers. Providing a protocol design approach that lends itself to 122 these types of reliability and availability features is very 123 desirable. 125 4. Scalable Performance 127 In designing and developing an NFS protocol from a performance 128 viewpoint there are several different points to consider. Each can 129 play a significant role in perceived and real performance from the 130 user's perspective. The three main areas of interest are: throughput 131 and latency on the network, server work load or scalability and 132 client side caching. 134 4.1. Throughput and Latency on the Network 136 NFS currently has characteristics that provide good throughput for 137 read and write of file data. However, the number of RPCs required to 138 accomplish some tasks combined with high latency network environments 139 leads to sluggish response. The protocol should continue to provide 140 good raw read and write throughput. It should also address the issue 141 of network latencies. This issue is discussed further in the section 142 on Internet Accessibility. 144 4.2. Server Work Load or Scalability 146 Current NFS operations are relatively lightweight in that the 147 processing work for most of the operations is not CPU intensive. 148 This allows for potential support of a large number of clients. This 149 attribute can also be helpful in building efficient and scalable SMP 150 or cluster based servers. While this type of protocol design 151 (lightweight operations) is desirable, it needs to be balanced 152 against the previous issue of having the client generate a large 153 number of RPCs to accomplish a straight forward task. 155 NFSv4 Requirements September 1998 157 4.3. Client Caching 159 In an attempt to speed response time and to reduce network and server 160 load, NFS clients have always cached directory and file data. 161 However, this has usually been done as memory cache and in relatively 162 recent history, local disk caching has been added. 164 Having the client cache directory and file data is very desirable. 165 Other distributed file systems have shown that aggressive client side 166 caching can be very visible to the end user in response time gains. 167 Client caching is increasingly important for Internet environments 168 where throughput can be limited and response time can grow 169 significantly. 171 The NFS protocol should allow for aggressive caching while balancing 172 the needs for simplicity and Internet accessibility (i.e. firewalls). 173 If possible, the caching ability should be layered on the protocol 174 instead of embedding specific client caching functions in the 175 protocol itself. 177 4.4. Disconnected Client Operation 179 An extension of client caching is the idea or functionality of 180 disconnected operation at the client. With the ability to cache 181 directory and file data aggressively, a client could then provide 182 service to the end user while disconnected from the server or 183 network. 185 While very desirable, disconnected operation has the opportunity to 186 inflict itself on the NFS protocol more so than regular client 187 caching. If this area is pursued, the tradeoffs will need to be 188 weighed carefully in the areas of the semantics of disconnected 189 operation along with user data synchronization or resolution at the 190 point of reconnection. 192 Editors Note: This section needs to be discussed and 193 expanded or clarified if it is found to be a stronger 194 requirement than what is stated in the above text. 196 5. Interoperability 198 The NFS protocols are available for many different operating 199 environments. Even though this shows the protocol's ability to 201 NFSv4 Requirements September 1998 203 provide distributed file system service in for more than a single 204 operating system, the design of NFS is certainly Unix centric. 205 Distributed file systems are usually tied in some way to the original 206 operating environment for which they were developed. A desired 207 feature of the next NFS protocol is to reduce platform centric 208 features while retaining reasonable functionality and performance in 209 the protocol. 211 5.1. Platform Specific Behavior 213 Because of its Unix centric design, some of the protocol requirements 214 have been difficult to implement in some environments. For example, 215 persistent file handles (unique identifiers of file system objects), 216 Unix uid/gid mappings, directory modification time, accurate file 217 sizes. 219 Editors Note: This list could be expanded or more detail 220 of the associated problems could be added. 222 5.2. Extended Attributes 224 NFS does not provide for file or directory attributes beyond those 225 that are found in the traditional Unix environment; for example the 226 user identifier of the owner of the file, a permission or access 227 bitmap, time stamps for modification time of the file or directory 228 and file size to name a few. While the current set of attributes has 229 usually been sufficient, the file system's ability to manage 230 additional information associated with a file or directory can be 231 useful. 233 Editors Note: Need to add examples of the use or potential 234 extended attributes. 236 Editors Note: Discussion of extended attribute support in 237 other file systems needs to be added. 239 5.3. Access Control Lists 241 One specific type of extended attribute can be the Access Control 242 List (ACL). This attribute is a designation of user access to a file 243 or directory. Many vendors have created ancillary protocols to NFS 245 NFSv4 Requirements September 1998 247 to extend the server's ACL mechanism across the network. Even though 248 the server still interprets the ACL and has final control over access 249 to a file system object, the client is able to manipulate the ACL via 250 these additional protocols. 252 DFS provides the ability to manipulate the ACLs of their file 253 servers. CIFS provides this capability as well. 255 Editors Note: Is the CIFS statement true in this case? 256 What are the mechanisms? 258 6. RPC Mechanism and Security 260 NFS relies on the underlying security mechanisms provided by the 261 ONCRPC protocol. Until the introduction of the ONCRPC RPCSEC_GSS 262 security flavor, NFS security was generally limited to none 263 (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not 264 successful in providing readily available security for NFS because of 265 a lack of implementation and deployment. Also the 192 bit public 266 keys modulos used for the AUTH_DH security flavor quickly became too 267 small for reasonable security. 269 6.1. Remote Procedure Call Mechanism 271 The ONCRPC protocol provides the basic NFS foundation for the 272 following reasons: 274 o Open protocol definition managed by IETF 276 o Transport independent (UDP and TCP supported -- and others????) 278 o Simple data representation and procedure encoding models 280 o Various security mechanisms available through use of RPCSEC_GSS 282 6.2. User identification 284 NFS has been limited to the use of the Unix centric user 285 identification mechanism of numeric user id based on the available 286 file system attributes and the use of the ONCRPC. However, for NFS 288 NFSv4 Requirements September 1998 290 to move beyond the limits of large work groups, user identification 291 should be string based and the definition of the user identifier 292 should allow for integration into an external naming service or 293 services. 295 Internet scaling should also be considered for this as well. The 296 identification mechanism should take into account multiple naming 297 domains and other extremes that can be presented by use outside of 298 the work group. 300 Editors Note: Should identify what other distributed file 301 systems do for naming and if these approaches can help 302 solve the issues above or are themselves limited. 304 6.3. Authentication 306 As a result of a lack of implementation and deployment and relatively 307 weak protection, authentication has been a major issue for ONCRPC and 308 hence NFS. With the introduction of the RPCSEC_GSS security flavor, 309 ONCRPC can provide for reasonable authentication along with integrity 310 and privacy, if desired. The RPCSEC_GSS framework will allow the use 311 of both public and private key mechanisms. Therefore, NFS as a user 312 of ONCRPC should state its specific requirements for each of these 313 areas. 315 Strong authentication is a requirement for NFS and the logical 316 solution for this is in the use of ONCRPC and RPCSEC_GSS. 318 Editors Note: Beyond authentication, should NFS make use 319 of the integrity and privacy features of RPCSEC_GSS? This 320 could prove useful in the broader Internet environment. 322 Editors Note: What security mechanisms should be specified 323 or required by NFS? For private key, Kerberos V5 can be 324 used. Are there other obvious suggestions? For public 325 key, SPKM [RFC2025] can be used. Are there other 326 suggestions for public key? 328 6.4. Security Negotiation 330 Along with the authentication requirements, a method for client and 331 server to automatically negotiate an agreeable security mechanism 332 needs to be in place. This will ease administration overhead and 334 NFSv4 Requirements September 1998 336 interoperability difficulties. 338 7. Internet Accessibility 340 Being a product of an IETF working group, the NFS protocol should not 341 only be built upon IETF technologies where possible but should also 342 work well within the broader Internet environment. 344 7.1. Transports 346 ONCRPC is available for both UDP and TCP transports. NFS as a user 347 of ONCRPC has not placed any requirements on the use of either UDP or 348 TCP. Today's NFS implementations generally support both transports. 350 At a minimum, NFS should require the support of both UDP and TCP at 351 the client and server. An alternative would be to require TCP only 352 for both client and server. 354 However, it can be argued that some new NFS protocol features could 355 rely on the use of TCP and its connection state. If this type of 356 transport dependency were built into NFS, UDP would be lost for some 357 environments as the low overhead and potentially better performing 358 alternative. 360 7.2. Firewalls and Proxy Servers 362 NFS's protocol design should allow its use via Internet firewalls. 363 The protocol should also allow for the use of file system proxy 364 servers if possible (especially for caching). 366 Editors Note: What potential issues exist with the 367 combination of aggressive client caching and proxy caching? 369 Editors Note: Also what are the security implications of 370 proxy NFS servers? 372 7.3. Multiple RPCs and Latency 374 As an application at the NFS client performs simple file system 376 NFSv4 Requirements September 1998 378 operations, multiple NFS operations or RPCs may be executed to 379 accomplish the work for the application. While the NFS version 3 380 protocol addressed some of this by returning file and directory 381 attributes for most procedures hence reducing follow up GETATTR 382 requests, there is still room for improvement. Reducing the number 383 of RPCs can lead to a reduction of processing overhead on the server 384 (transport and security processing) along with reducing the time 385 spent at the client waiting for the server's individual responses. 386 This issue is more prominent environments with higher degrees of 387 latency. 389 One approach to resolving this issue is by allowing multiple 390 individual operations to be combined together in a single RPC. This 391 would reduce the transport and security processing overhead while 392 allowing for the use of simple protocol operations to accomplish more 393 complete tasks. 395 Note that CIFS provides a similar mechanism with its chaining. 397 8. File locking / recovery 399 NFS has provided Unix file locking and DOS SHARE capability with the 400 use of an ancillary protocol (Network Lock Manager / NLM). The NLM 401 protocol provides for file locking and recovery of those locks in the 402 event of client or server failure. NLM requires that the server make 403 call backs to the client for certain scenarios and therefore is not 404 necessarily well suited for Internet firewall traversal. 406 Desirable features of file locking support are: 408 o Integration with the NFS protocol 410 o Interoperability between operating environments 412 o Scalable solutions - thousands of clients 414 o Internet capable (firewall traversal, latency sensitive) 416 o Timely recovery in the event of client/server failure 418 Editors Note: Do these items need further definition? 420 DFS offers file locking but does not provide DOS SHARE capability. 421 DFS' relies on the server calling back to the client for the file 423 NFSv4 Requirements September 1998 425 locking functionality. 427 CIFS supports file locking and DOS SHARE support. 429 9. Internationalization 431 The current NFS protocols are limited in their support of anything 432 more than 7-bit ASCII strings. It is imperative that NFS support a 433 range of character sets. This can be provided by requiring support 434 for Unicode with a UTF-8 wire encoding. Therefore, all strings 435 defined as part of the NFS protocol will need to be defined as UTF-8 436 and the appropriate XDR encoding used. 438 NFSv4 Requirements September 1998 440 10. Bibliography 442 [RFC1094] 443 Sun Microsystems, Inc., "NFS: Network File System Protocol 444 Specification", RFC1094, March 1989. 446 ftp://ftp.isi.edu/in-notes/rfc1094.txt 448 [RFC1813] 449 Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol 450 Specification", RFC1813, Sun Microsystems, Inc., June 1995. 452 ftp://ftp.isi.edu/in-notes/rfc1813.txt 454 [RFC1831] 455 Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification 456 Version 2", RFC1831, Sun Microsystems, Inc., August 1995. 458 ftp://ftp.isi.edu/in-notes/rfc1831.txt 460 [RFC1832] 461 Srinivasan, R., "XDR: External Data Representation Standard", 462 RFC1832, Sun Microsystems, Inc., August 1995. 464 ftp://ftp.isi.edu/in-notes/rfc1832.txt 466 [RFC1833] 467 Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, 468 Sun Microsystems, Inc., August 1995. 470 ftp://ftp.isi.edu/in-notes/rfc1833.txt 472 [RFC2025] 473 Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, 474 Bell-Northern Research, October 1996. 476 ftp://ftp.isi.edu/in-notes/rfc2025.txt 478 [RFC2078] 479 Linn, J., "Generic Security Service Application Program Interface, 480 Version 2", RFC2078, OpenVision Technologies, January 1997. 482 NFSv4 Requirements September 1998 484 ftp://ftp.isi.edu/in-notes/rfc2078.txt 486 [RFC2203] 487 Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification" 488 RFC2203, Sun Microsystems, Inc., August 1995. 490 ftp://ftp.isi.edu/in-notes/rfc2203.txt 492 [Sandberg] 493 Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design 494 and Implementation of the Sun Network Filesystem," USENIX Conference 495 Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The 496 basic paper describing the SunOS implementation of the NFS version 2 497 protocol, and discusses the goals, protocol specification and trade- 498 offs. 500 [X/OpenNFS] 501 X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open 502 Internetworking: XNFS, X/Open Company, Ltd., Apex Plaza, Forbury 503 Road, Reading Berkshire, RG1 1AX, United Kingdom, 1991. This is an 504 indispensable reference for NFS version 2 protocol and accompanying 505 protocols, including the Lock Manager and the Portmapper. 507 [X/OpenPCNFS] 508 X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open 509 Internetworking: (PC)NFS, Developer's Specification, X/Open Company, 510 Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United 511 Kingdom, 1991. This is an indispensable reference for NFS version 2 512 protocol and accompanying protocols, including the Lock Manager and 513 the Portmapper. 515 NFSv4 Requirements September 1998 517 11. Author's Address 519 Address comments related to this memorandum to: 521 spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com 523 Spencer Shepler 524 Sun Microsystems, Inc. 525 7808 Moonflower Drive 526 Austin, Texas 78750 528 Phone: (512) 349-9376 529 E-mail: spencer.shepler@eng.sun.com