RFC 2624

NFS Version 4 Design Considerations

📅 published June 1999, from ietf

RFC 2624: NFS Version 4 Design Considerations 🎀

Okay bestie, so this is RFC 2624, and it's called NFS Version 4 Design Considerations 💅 It was written by S. Shepler at Sun Microsystems, Inc. for the Network Working Group. It's in the Informational category and dated June 1999 🌸 The header doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing ✨

Status of This Memo 📜

This memo gives information to the Internet community. It is not a specification for an Internet standard of any kind, so no vibes of "you must do this" here 🫶 Distribution of this memo is unlimited, so share it with everyone 💖

Copyright (C) The Internet Society (1999). All Rights Reserved. 🔒

Abstract 🦋

Okay so the main job of the NFS version 4 working group is to make a protocol definition for a distributed file system. The focus is on a few big things: improved access and good performance on the Internet, strong security with negotiation built into the protocol, better cross-platform interoperability, and being designed for protocol extensions 🔥 NFS version 4 is gonna owe its general design to the earlier versions of NFS, but a lot of features will be totally different. That's because they're trying to hit goals the working group cares about and tackle stuff that NFS versions 2 and 3 never covered 👑

This design considerations document goes deeper than the working group charter ✨ It lays out the areas the working group is going to investigate while building the NFS version 4 protocol spec. After digging into those areas, the group will pick which features to include based on the costs and benefits in each feature area. Main character decision-making 💅

Key Words 🔑

Here's the key words bit, and yes, these ones show up in capitals on purpose 🙈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents 📚

1.  NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
2.  Ease of Implementation or Complexity of Protocol  . . . . . . 3
2.1.  Extensibility / layering  . . . . . . . . . . . . . . . . . 3
2.2.  Managed Extensions or Minor Versioning  . . . . . . . . . . 3
2.3.  Relationship with Older Versions of NFS . . . . . . . . . . 4
3.  Reliable and Available  . . . . . . . . . . . . . . . . . . . 5
4.  Scalable Performance  . . . . . . . . . . . . . . . . . . . . 5
4.1.  Throughput and Latency via the Network  . . . . . . . . . . 6
4.2.  Client Caching  . . . . . . . . . . . . . . . . . . . . . . 6
4.3.  Disconnected Client Operation . . . . . . . . . . . . . . . 7
5.  Interoperability  . . . . . . . . . . . . . . . . . . . . . . 7
5.1.  Platform Specific Behavior  . . . . . . . . . . . . . . . . 8
5.2.  Additional or Extended Attributes . . . . . . . . . . . . . 8
5.3.  Access Control Lists  . . . . . . . . . . . . . . . . . .   9
6.  RPC Mechanism and Security  . . . . . . . . . . . . . . . .  10
6.1.  User identification . . . . . . . . . . . . . . . . . . .  10
6.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  10
6.2.1.  Transport Independence  . . . . . . . . . . . . . . . .  11
6.2.2.  Authentication  . . . . . . . . . . . . . . . . . . . .  11
6.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . . .  11
6.2.4.  Data Privacy  . . . . . . . . . . . . . . . . . . . . .  12
6.2.5.  Security Negotiation  . . . . . . . . . . . . . . . . .  12
6.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  12
7.  Internet Accessibility  . . . . . . . . . . . . . . . . . .  13
7.1.  Congestion Control and Transport Selection  . . . . . . .  13
7.2.  Firewalls and Proxy Servers . . . . . . . . . . . . . . .  14
7.3.  Multiple RPCs and Latency . . . . . . . . . . . . . . . .  14
8.  File locking / recovery . . . . . . . . . . . . . . . . . .  15
9.  Internationalization  . . . . . . . . . . . . . . . . . . .  16
10.  Security Considerations  . . . . . . . . . . . . . . . . .  17
10.1.  Denial of Service  . . . . . . . . . . . . . . . . . . .  17
11.  Bibliography . . . . . . . . . . . . . . . . . . . . . . .  18
12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  21
13.  Author's Address . . . . . . . . . . . . . . . . . . . . .  21
14.  Full Copyright Statement . . . . . . . . . . . . . . . . .  22

1. NFS Version 4 Design Considerations 🌈

As the charter says, the first deliverable for the NFS version 4 working group is this design considerations document ✨ It's meant to cover the "limitations and deficiencies of NFS version 3" 🙈 It's also gonna be used to focus discussion and the paths the group investigates as NFS version 4 takes shape. So the contents cover the general functional and feature areas the group expects for NFS version 4. Where it makes sense, the doc talks about what NFS versions 2 and 3 currently do, along with other useful references to how distributed file systems work today 🧚

2. Ease of Implementation or Complexity of Protocol 🧠

One of NFS's biggest strengths has been how easy it is to implement a client or a server 💖 A basic implementation ends up being pretty small. The main reason to keep NFS as simple as possible is that a simple protocol design can be described in a simple specification, and that makes straightforward, interoperable implementations way more likely 🫶 Every protocol runs into problems once it hits real networks, but simple protocols give you problems that are easier to diagnose and fix. Honestly, that's the kind of drama you want 😭

2.1. Extensibility / layering 🧩

NFS is relatively simple, so adding or layering new functionality has been pretty easy ✨ Things like the client automount or autofs, client side disk caching, and high availability servers are all examples of that. This kind of extensibility is great in environments where solving a problem doesn't require revising the protocol 💅 It can also help down the road, when unforeseen problems or opportunities pop up and can be solved by layering functionality on top of an existing set of tools or protocol 🦋

2.2. Managed Extensions or Minor Versioning 🎀

Sometimes the NFS protocol is deficient, or a minor change is the best fix for a problem. In those cases, a minor version or a managed extension could be super helpful 🔥 NFS versions 2 and 3 have had moments where small, straightforward functional additions would have boosted the overall value of the protocol a ton. For example, the PATHCONF procedure that was added to version 2 of the MOUNT protocol would've fit the NFS protocol better. And the WebNFS [RFC2054][RFC2055] overloading of the LOOKUP procedure for NFS versions 2 and 3 would have been cleaner as a brand new LOOKUP procedure 😭

Here's the tea though: the perceived size and burden of changing the RPC version number to add new functionality led to little or slow change 💀 It's possible that a new NFS protocol could allow for the rare case where extending within the RPC version number is the smartest move, and bumping the RPC revision would be unnecessary or impractical 🌸

The parts of an NFS protocol that are most obviously going to change are new orthogonal procedures, new well-defined file or directory attributes, and potentially new file types 🧚 For example, a future file type could be something like "attribute," which represents a named file stream, or a "dynamic" file type that generates dynamic data in response to a "query" procedure from the client 👑 Adding these kinds of things is possible and highly desirable without changing the overall design model of NFS and without significant effort or delay ⭐

A strong consideration should be given to an NFS protocol mechanism for introducing this kind of new functionality 🫶 That's obviously different from using the standard RPC version mechanism for minor changes. Using RPC version numbers to introduce new functionality comes with a lot of history, which may not technically stop you from using it 💅 Still, those historical issues will need to be addressed as part of the NFS version 4 protocol work. Dealing with them should boost the protocol's current and future success 🌈

As background, the RPC protocol described in [RFC1831] uses a version number to describe the set of procedure calls, replies, and their semantics ✨ Any change in that set must be reflected in a new version number for the program. The MOUNTPROC_PATHCONF procedure, added in version 2 of the MOUNT protocol, is an example of this. Apart from adding that one procedure, the protocol didn't change at all. Lots of people thought this protocol revision was unnecessary, since RPC already lets certain procedures go unimplemented and defines a PROC_UNAVAIL error 🙈

Another historical data point from NFS versions 2 and 3 is whether symbolic links are supported or not 🦋 Servers that can't support this feature will just reject calls to the SYMLINK and READLINK procedures 💖 On top of that, NFS version 4 may describe many file attributes that the server or the file systems on the server can't support. So the protocol must support a discovery mechanism that lets clients figure out which features of the protocol a server supports 🧠

2.3. Relationship with Older Versions of NFS 🕰️

NFS version 4 is going to be a self-contained protocol 💅 It won't have any dependencies on the previous versions of NFS. Put another way, an NFS version 4 server or client won't require an NFSv2 or NFSv3 implementation to be present in order for NFS version 4 to function as designed. It's also worth noting that having an NFS version 2 or 3 implementation present at the client or server won't enhance the functionality of an NFS version 4 implementation 🫶

When an NFS client has a choice of protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms let the client choose an available version of the protocol at the NFS server ✨ The ONCRPC protocol has the semantics and error returns for when an RPC server program doesn't support a particular version. The NFS client uses this mechanism to get notified about an unavailable version, and along with that error, it also gets the range of versions (min to max) that are available 🎀 So the ONCRPC mechanism can be used by implementors of both clients and servers to make the switch to, or install, NFS version 4 services 🌸

3. Reliable and Available ✨

okay so the current NFS design puts a lot of effort into simple server design, and that's paid off big time 💖 it means clients and servers can recover quickly after a failure 😭 That's the foundation that layered stuff like high availability and clustered servers gets built on. So a protocol design that makes those reliability and availability features easier to add is super desirable 🫶

For the next version of NFS, we should think about client side availability schemes, like a client switching between or failing over to available server replicas 🔄 Right now NFS requires that file handles be immutable, and that makes fail-over setups way more complicated than they need to be 🙃 If it's possible, the protocol should allow for or ease building these layered solutions 🧚

For the next version of NFS, we should also look at schemes that let clients switch between server replicas, or highly available NFS servers that give paths to data through multiple servers 🦋 For example, NFS currently requires that filehandles be unchanging for any instance of a file or directory. This makes it harder for a client to hop from one server to another, since each server might construct filehandles differently 💀 Protocol support could let the client handle a filehandle change ✨

4. Scalable Performance 🔥

When you're designing an NFS protocol from a performance angle, there are a bunch of things to think about 🤓 Each one can seriously affect both the perceived and real performance from the user's point of view. The three main areas are: throughput and latency over the network, server workload or scalability, and client side caching 💅

4.1. Throughput and Latency via the Network 🌊

NFS already has characteristics that give good throughput for reading and writing file data 📈 This is usually achieved when the client pipelines or windows multiple RPC READ/WRITE requests to the server. The flexibility of the NFS and ONCRPC protocols lets implementations use this kind of adaptation for efficient use of the network connection 🙌

However, the number of RPCs needed for some tasks, combined with high latency network environments, can make single user or single client response feel sluggish 🐌 The protocol should keep providing good raw read and write throughput while also tackling network latency. This issue is discussed further in the section on Internet Accessibility 👀

4.2. Client Caching 🗂️

To speed up response time and cut down on network and server load, NFS clients have always cached directory and file data 🧠

Historically though, this has mostly been done as memory cache, and only fairly recently has local disk caching been added 💾

It's very desirable for the NFS client to cache directory and file data 💜 Other distributed file systems have shown that aggressive client side caching can be super visible to the end user, in the form of decreasing overall response time ⚡ For AFS and DCE/DFS, caching is done with server call backs that notify the client of potential cache invalidation. CIFS and its opportunistic locks offer a similar call back mechanism 🔔 Clients in both of these environments can cache data while avoiding interaction with the network and server. Iconic 😤

With these protocols, it's also possible to cache or delay certain protocol requests at the client, which cuts down the protocol traffic flowing between client and server even more 🎀 In the case of CIFS, a client can obtain an opportunistic lock for a file and then process file lock requests completely at the client. If there are no conflicts with other clients for file data access, the server is never contacted for the file locking traffic the user application generates 🙈 This behavior is not a protocol requirement, but the protocol allows it as an implementation option to improve performance 🌸

NFS versions 2 and 3 make no caching requirements 🤷‍♀️ Implementations typically use close-to-open cache consistency, which means clients flush all changes to the server on each file close, and check for file changes on the server on each file open. The consistency check on each file open can generate a huge amount of GETATTR traffic 😵 With this approach there are windows where the client can still be acting on stale data between the open and close of a file 😬

Client caching is becoming increasingly important for Internet environments, where throughput can be limited and response time can grow significantly 🌐 So the NFS version 4 caching design will need to take the full spectrum of caching designs into account, as shown by current technologies like NFS, AFS, DCE/DFS, CIFS, etc., when figuring out an appropriate design 🧩 This has to be done while weighing the complexity of each possible approach against the needs of the eventual users and operating environments NFS version 4 might be deployed into ⚖️ Some of these considerations are: Internet accessibility, firewall traversal (call back availability), proxy caching, and low-overhead or simple clients 🫧

4.3. Disconnected Client Operation 🔌

An extension of client caching is providing for disconnected operation at the client 💭 With the ability to cache directory and file data aggressively, a client could keep serving the end user while disconnected from the server or network 🙌

Disconnected operation is very desirable, but it has the potential to mess with the NFS protocol in a way that's not so great compared to traditional client caching 😩 Given the complexities of disconnected client operation, and the later resolution of client data modifications through various playback or data selection mechanisms, disconnected operation should not be a requirement for the NFS effort. Even so, the NFS protocol should consider the potential layering of disconnected operation solutions on top of it, just like other server and client solutions 🍰 The experiences with Coda, disconnected AFS and others should be helpful in this area (see references) 📚

5. Interoperability 🌍

The NFS protocols are available for lots of different operating environments 🎉 Even though that shows the protocol can provide distributed file system service for more than one operating system, the design of NFS is definitely Unix-centric 🐧 The next NFS protocol needs to be more inclusive of platform or file system features beyond the traditional Unix ones 🫶

5.1. Platform Specific Behavior 🧃

Because of its Unix-centric origins, NFS version 2 and 3 protocol requirements have been hard to implement in some environments 😭 For example: persistent file handles (unique identifiers of file system objects), Unix uid/gid mappings, directory modification time, accurate file sizes, and file/directory locking semantics (SHAREs, PC-style locking). In the design of NFS version 4, these areas and others not mentioned here will need to be considered and, if possible, cross-platform solutions developed 🌈

5.2. Additional or Extended Attributes 🏷️

NFS versions 2 and 3 don't provide for file or directory attributes beyond the ones found in the traditional Unix environment 🙃 For example, there's the user identifier/owner of the file, a permission or access bitmap, time stamps for modification of the file or directory, and file size, to name a few. The current set of attributes has usually been enough, but the file system's ability to manage additional information associated with a file or directory can be super useful 💅

There are a lot of possibilities for additional attributes in the next version of NFS 🔮 Some of these include: object creation timestamp, user identifier of file's creator, timestamp of last backup or archival bit, version number, file content type (MIME type), and existence of data management involvement (i.e. DMAPI [XDSM]).

This list is representative of the possibilities and is meant to show the need for an additional attribute set 🧁 Enumerating the 'correct' set of attributes, though, is hard. That's one of the reasons for looking toward a minor versioning mechanism as a way to provide needed extensibility ⭐ Another way to get some extensibility is to support a generalized named attribute mechanism. This mechanism would let a client name, store and retrieve arbitrary data and have it associated as an attribute of a file or directory 🎀

One difficulty with named attributes is deciding whether the protocol should specify the names for the attributes, their type or their structure 🤔 How will the protocol determine or allow for attributes that can be read but not written? That's another issue. Yet another could be the side effects these attributes have on the core set of file properties, like setting a size attribute to 0 and having the associated file data deleted 😱

As these brief examples show, this type of extended attribute mechanism brings a big set of issues that will need to be addressed in the protocol specification, all while keeping the overall goal of simplicity in mind 🧠💖

There are operating environments that already provide named or extended attribute mechanisms 🖥️ Digital Unix provides for the storage of extended attributes with some generalized format. HPFS [HPFS] and NTFS [Nagar] also provide for named data associated with traditional files. SGI's local file system, XFS, also provides this kind of name/value extended attributes 🦋 However, there doesn't seem to be a clear direction that can be taken from these or other environments 🫠

5.3. Access Control Lists ✨

Okay so ACLs (Access Control Lists) can be viewed as one specific type of extended attribute 💅. This attribute is basically a designation of who gets access to a file or directory 🔐. Lots of vendors built ancillary protocols on top of NFS to extend the server's ACL mechanism across the network 🌐. Mostly this was done for homogeneous operating environments, so everyone was using the same stuff 🫶. Even so, the server still interprets the ACL and has final control over access to a file system object. The client can manipulate the ACL through these extra protocols. Other distributed file systems have provided ACL support too: DFS, AFS and CIFS 🦋.

The main reason all of these file systems need ACL support is that users want to grant and restrict access to file system data on a per user basis 👑. Given what users want and what current distributed file systems already do, it seems to be a requirement that NFS provide this capability as well 💖.

Here's the tricky part 😭. Lots of local and distributed file system ACL implementations were built without a common architecture, so the major issue is compatibility. The POSIX draft, DCE/DFS [DCEACL] and Windows NT ACLs all have a similar structure: an array of Access Control Entries made of a type field, identity, and permission bits. But the similarity ends there 💀. Each model defines its own variants of entry types, identifies users and groups differently, provides different kinds of permission bits, and describes different procedures for ACL creation, defaults, and evaluation.

Honestly, it will be problematic to create a workable ACL mechanism that covers a reasonable set of functionality for all operating environments 🙈. Even with how complicated ACL support is, it's still worth working towards a solution that can at least provide basic functionality for the user 🌸.

6. RPC Mechanism and Security ✨

NFS relies on the security mechanisms provided by the ONCRPC [RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS security flavor [RFC2203], NFS security was generally limited to none (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not successful at providing readily available security for NFS, because it lacked widespread implementation, which precluded widespread deployment 😩. Also, the Diffie-Hellman 192 bit public key modulus used for the AUTH_DH security flavor quickly became too small for reasonable security 💀.

6.1. User identification

NFS has been stuck with the Unix-centric user identification mechanism: a numeric user id based on the available file system attributes, used over ONCRPC 🐧. However, for NFS to move beyond the limits of large work groups, user identification should be string based, and the definition of the user identifier should allow for integration into an external naming service or services 🌈.

Internet scaling should also be considered here 🌍. The identification mechanism should take into account multiple naming domains and multiple naming mechanisms. Flexibility is the key to a solution that can grow with the needs of the user and administrator 🦋.

If NFS is going to move among various naming and security services, it may be necessary to stay with string based identification 🧚. This would allow servers and clients to translate between the external string representation and a local or internal numeric (or other identifier) that matches internal implementation needs.

As an example, DFS uses a string based naming scheme but translates the name to a UUID (16 byte identifier) that is used for internal protocol representations 🎀. The DCE/DFS string name is a combination of cell (administrative domain) and user name. As mentioned, NFS clients and servers map a Unix user name to a 32 bit user identifier, which is then used for the ONCRPC and NFS protocol fields that need the user identifier 💜.

6.2. Security

Because of the aforementioned problems, user authentication has been a major issue for ONCRPC and therefore NFS 😤. To satisfy requirements of the IETF and to address concerns and requirements from users, NFS version 4 must provide for the use of acceptable security mechanisms 🔥. The various mechanisms currently available should be explored for their appropriate use with NFS version 4 and ONCRPC. Some of these mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510], IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server interaction, the RPCSEC_GSS [RFC2203] framework should be strongly considered, since it provides a method to employ mechanisms like SPKM and KerberosV5 ✨. Before a security mechanism can be evaluated, the NFS environment and requirements must be discussed 📝.

6.2.1. Transport Independence

As mentioned later in this document in the section "Internet Accessibility", transport independence is an asset for NFS and ONCRPC, and it is a general requirement 🦋. This allows for transport choice based on the target environment and the specific application of NFS. The most common transports in use with NFS are UDP and TCP. This ability to choose a transport should be maintained in combination with the user's choice of a security mechanism. This implies that "mandatory to implement" security mechanisms for NFS should allow for both connection-less and connection-oriented transports 💅.

6.2.2. Authentication

As should be expected, strong authentication is a requirement for NFS version 4 🔐. Each operation generated via ONCRPC contains user identification and authentication information. It is common in NFS version 2 and 3 implementations to multiplex various users' requests over a single connection or a few connections to the NFS server. This allows for scalability in the number of client systems 🌸. Security mechanisms or frameworks should allow for this multiplexing of requests, so the implementation model that works today can keep going 🫶.

6.2.3. Data Integrity

Until the introduction of RPCSEC_GSS, the ability to provide data integrity over ONCRPC and to NFS was just not available 😭. Since file and directory data is the essence of a distributed file service, the NFS protocol should provide the users of the file service a reasonable level of data integrity 🛡️. The security mechanisms chosen must provide for NFS data protection with a cryptographically strong checksum. As with other aspects of NFS version 4, the user or administrator should be able to choose whether data integrity is employed 👑. This will provide the flexibility needed for a variety of NFS version 4 solutions 🌈.

6.2.4. Data Privacy

Data privacy is desirable, but it isn't as important in all environments as authentication and integrity 🙈. For example, in a LAN environment, the performance overhead of data privacy may not be required to meet an organization's data protection policies. It may also be the case that the performance of the distributed file system solution is more important than the data privacy of that solution 🏎️. Even with these considerations, the user or administrator must have the choice of data privacy, and therefore it must be included in NFS version 4 🔒.

6.2.5. Security Negotiation

With the ability to provide security mechanism choices to the user or administrator, NFS version 4 should offer reasonable flexibility for applying local security policies 🎀. However, this presents the problem of negotiating the appropriate security mechanism between client and server. It is unreasonable to require that the client know the server's chosen mechanism before initial contact 😵. The issue is further complicated by an administrator who may choose more than one security mechanism for the various file system resources shared by an NFS server 🍓. These types of choices and policies require that NFS version 4 deal with negotiating the appropriate security mechanism, based on mechanism availability and policy deployment at client and server. This negotiation will need to take into account the possibility of a change in policy as an NFS client crosses certain file system boundaries at the server. The security mechanisms required may change at these boundaries, and therefore the negotiation must be included within the NFS protocol itself to be done properly (i.e. securely) 🔐✨.

6.3. Summary

Other distributed file system solutions, such as AFS and DFS, provide strong authentication mechanisms 💜. CIFS does provide authentication at initial server contact, plus a message signing option for subsequent interaction. Recent NFS version 2 and 3 implementations, with the use of RPCSEC_GSS, provide strong authentication, integrity, and privacy 🌟.

NFS version 4 must provide for strong authentication, integrity, and privacy 💅. This must be part of the protocol so that users have the choice to use strong security if their environment or policies warrant it.

Based on the requirements presented, the ONCRPC RPCSEC_GSS security flavor seems to provide an appropriate framework for satisfying these requirements 🧚. RPCSEC_GSS provides for authentication, integrity, and privacy. It is also extensible, in that it provides for both public and private key security mechanisms, along with the ability to plug in various mechanisms in such a way that it does not significantly disrupt ONCRPC or NFS implementations 🔌.

With RPCSEC_GSS' ability to support both public and private key mechanisms, NFS version 4 should consider "mandatory to implement" choices from both 🦄. The intent is a security solution that will flexibly scale to match the needs of end users. Providing this range of solutions will allow for appropriate usage based on policy and available resources for deployment. Note that, in the end, the user must have a choice, and that choice may be to use all of the available mechanisms in NFS version 4 or none of them 👑💖.

7. Internet Accessibility ✨

Being a product of an IETF working group, the NFS protocol should not only be built upon IETF technologies where possible, but should also work well within the broader Internet environment 🌐💫.

7.1. Congestion Control and Transport Selection

As with any network protocol, congestion control is a major issue, and the transport mechanisms chosen for NFS should take this into account 🚦. Traditionally, implementations of NFS have been deployed using both UDP and TCP. With UDP, most implementations make a rudimentary attempt at congestion control, using simple back-off algorithms and round trip timers 🤷‍♀️. While this may be sufficient in today's NFS deployments, as an Internet protocol NFS will need to ensure sufficient congestion control or management 😤.

With congestion control in mind, NFS must use TCP as a transport (via ONCRPC) 🫶. The UDP transport provides its own advantages in certain circumstances. In today's NFS implementations, UDP has been shown to produce greater throughput compared to similarly configured systems that use TCP 🏎️. This issue will need to be investigated so that a determination can be made as to whether the differences are within implementation details 🔍. If UDP is supplied as an NFS transport mechanism, then the congestion control issues will need resolution to make its use suitable 🎀.

7.2. Firewalls and Proxy Servers ✨

okay so NFS has to be able to work through Internet firewalls 🧱, and the protocol should also leave room for file system proxy and cache servers 🫶. proxies are seriously useful for scalability and a bunch of other reasons 💅. the NFS protocol has to handle proxies in a way that covers security, access control, content control, and cache content validation, no cap 😭. one option is that these issues get solved just by writing up the related problems of proxy server usage 📝. but honestly, it's likely that NFS will need to support proxy servers directly in the protocol itself 🔥.

the protocol could let a request get sent to a proxy that includes the name of the target NFS server, so the request can be forwarded along, or so a response can be cached 🦋. either way, the NFS proxy server should be thought about during protocol development, bestie 🌸.

the problems you run into when making NFS work through firewalls are explained in detail in [RFC2054] and [RFC2055] 📚 iykyk, those two are the go-to reads 🧚.

7.3. Multiple RPCs and Latency 🎀

okay so when an app on the NFS client does simple file system stuff, it might need to run multiple NFS operations or RPCs to get the job done for that app 💖. NFS version 3 already got a head start on this by returning file and directory attributes for most procedures, which cuts down on follow-up GETATTR requests ✨. but there is still room to glow up here 💅. cutting the number of RPCs means less processing overhead on the server (transport and security processing) and less time the client spends just waiting on the server's responses one by one 😭. this matters even more in environments with bigger latency 🌈.

the CIFS file access protocol has 'batched requests', which let multiple requests get batched together, so there are fewer round trip messages between client and server 🫶 literally so smart.

NFS can use this same approach to group several procedure calls together in one traditional RPC request 🔥. not only would that reduce protocol-imposed latency, it would also cut down on transport and security processing overhead, and it could let a client finish more complex tasks by combining procedures 👑.

8. File locking / recovery 🔐

NFS gave us Unix file locking and DOS SHARE capability through an ancillary protocol, the Network Lock Manager (NLM) 🗝️. the DOS SHARE mechanism is basically the DOS version of file locking, since it gives you the basis for sharing or exclusive access to file and directory data without risking data corruption 💅. the NLM protocol handles file locking and recovers those locks if a client or server fails 🛟. the catch is that NLM needs the server to make call backs to the client in certain scenarios, so it's not really a great fit for getting through Internet firewalls 🧱 not me going "why" 💀.

reliable, working file locking for NFS version 2 and 3 clients and servers has historically been kind of a mess 😭. NLM support was often missing, and that seems mostly tied to the fact that NFS and NLM are two separate protocols 🙈. it's really easy to ship an NFS client and server and then add NLM later, so for a long time NLM support was just lacking in NFS' early days 💔. part of the problem was that NLM was delivered separately, and it's pretty complex, which led to poor implementations and testing headaches 🌀. even once reliability and performance got good enough, users still avoided the protocol and its support anyway 💀. the last problem with NLM is some minor protocol design flaws around high network load and recovery 🫠.

so based on what happened with NLM, locking support for NFS version 4 should aim to meet, or at least consider, the following (listed in order of importance) ✨:

  • Integration with the NFS protocol and ease of implementation. 🧩
  • Interoperability between operating environments. The protocol should make a reasonable effort to support the locking semantics of both PC and Unix clients and servers. This will allow for greater integration of all environments. 🌈
  • Scalable solutions - thousands of clients. The server should not be required to maintain significant client file locking state between server instantiations. 👑
  • Internet capable (firewall traversal, latency sensitive). The server should not be required to initiate TCP connections to clients. 🦋
  • Timely recovery in the event of client/server or network failure. Server recovery should be rapid. The protocol should allow clients to detect the loss of a lock. ⏰

9. Internationalization 🌍

NFS version 2 and 3 are kinda stuck when it comes to character encoding for strings 🙈. in the NFS protocols, strings show up in file and directory names and symbolic link contents 📁. the XDR definition [RFC1832] technically limits NFS strings to 7-bit US-ASCII, but in practice people encode filenames in 8-bit ISO-Latin-1 🤷‍♀️. the issue is there's no mechanism to tag XDR character strings so you can tell which character encoding the client or server used 💀. honestly that limits how useful NFS is in environments where clients use different character sets 😭.

one way to fix this is to use the Unicode Standard [Unicode1] as the way to exchange character strings for NFS version 4 💖. the Unicode Standard is a 16 bit encoding that supports full multilingual text ✨. it's code-for-code identical with International Standard ISO/IEC 10646-1:1993. "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." 📖 since Unicode is 16 bit, it could be more efficient for NFS version 4 to use a wire transfer encoding that works for most usage 🦋. one option is the UCS transformation format (UTF) 🔥. UTF-8 is an encoding method for UCS-4 characters that lets US-ASCII characters be encoded directly, but it expands to correctly encode the full 31 bit UCS-4 definitions 🌸. right now, the UCS-4 and Unicode standards don't diverge 🫶.

this Unicode/UTF-8 encoding can be used anywhere the protocol needs a traditional string representation 💅. that covers file and directory names along with symlink contents 📁. it should also cover other file and directory attributes that end up being defined as strings 🎀.

Unicode applies to the well defined strings inside the protocol, but dealing with file content is way harder 😭. NFS has always treated file data as an opaque byte stream 🫧. no other structure or content spec has been put on the file content, and the big win there is flexibility 💜. the byte stream can hold any data and can be accessed in any sequential or random way 🌈. the downside is that it's left to the application or user to figure out what the file content and format are 🙃. it's possible to build a mechanism into the protocol that specifies the file data type while still keeping the byte stream model for data access ✨. but that approach might be limiting in ways that aren't clear to the NFS version 4 designers 🤔. a more expandable, adaptable option is to use the extended attributes we talked about earlier as the mechanism for specifying file content and format 🧚. extended attributes allow for future definition and growth as various data types get created, and they keep a simple file data model for NFS 💖.

it should be noted that, the way the Unicode standards are currently defined, there's a possibility of minor inconsistencies when converting from local character representations to Unicode and back again 🌀. this shouldn't be a problem with a single client and server interaction, but it may become apparent when two or more clients with separate conversion implementations interact 👀. so as NFS version 4 moves along in development, these Unicode issues need to be tracked and understood for their potential impact on client/server interaction 📝. either way, Unicode seems to be the best pick for NFS version 4 based on its standards background and apparent future direction 👑✨.

10. Security Considerations 🔒

two earlier sections of this document deal with security issues 🛡️. the section on 'Access Control Lists' covers the mechanisms that need to be looked into for file system level control 🗂️. the section on RPC security deals with individual user authentication, data integrity, and privacy issues, and it also covers negotiation of security mechanisms 🔐. those sections should be checked out for more discussion and detail 📖💅.

10.1. Denial of Service 💀

as with all services, denial of service is always a concern, whether it comes from incorrect implementations or malicious agents 🚨. since the goal is to bring NFS version 4 to Internet use, it's extra important that every part of the NFS version 4 protocol gets reviewed for potential denial of service scenarios 👀. when problems are found, they should be mitigated as much as possible 🫶🔥.

11. Bibliography 📚

okay bestie, this is the reading list 🧚 every single one of these is a source the spec leans on, so no skipping. i kept every tag, title, date, and link exactly as written 💅

12. Acknowledgments 🫶

big shoutout to the people who helped make this happen 💖

  • Brent Callaghan for content contributions. 🌸

13. Author's Address 📮

if you have comments about this memo, send them to:

spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com

the author is Spencer Shepler, and here's where to find him 🦋

Spencer Shepler
Sun Microsystems, Inc.
7808 Moonflower Drive
Austin, Texas 78750

Phone: (512) 349-9376
EMail: spencer.shepler@eng.sun.com

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀

📦 where this page comes from