| | |
7.6. NFS futures
7.6.1. NFS Version 4
In 1998, Sun Microsystems and the Internet Society completed an
agreement giving the Internet Society control over future versions of
NFS, starting with NFS Version 4. The Internet Society is the
umbrella body for the Internet Engineering Task Force
(IETF). IETF now has a working group chartered to define NFS Version
4. The goals of the working group include:
- Better access and performance on the Internet
- NFS can be used on the Internet,
but it isn't designed to work
through firewalls (although, in Chapter 12, "Network Security"
we'll discuss a way to use NFS through a firewall). Even if a
firewall isn't in the way, certain aspects of NFS, such as
pathname parsing, can be expensive on high-latency links. For
example, if you want to look at /a/b/c/d/e on a
server, your NFS Version 2 or 3 client will need to make five lookup
requests before it can start reading the file. This is hardly
noticeable on an ethernet, but very annoying on a modem link.
- Mandatory security
- Most NFS implementations have
a default form of authentication that
relies on a trust between the client and server. With more people on
the Internet, trust is insufficient. While there are security flavors
for NFS that require strong authentication based on cryptography,
these flavors aren't universally implemented. To claim
conformance to NFS Version 4, implementations will have to offer a
common set of security flavors.
- Better heterogeneity
- NFS has been implemented on a wide array of platforms, including
Unix, PCs, Macintoshes, Java, MVS, and web browsers, but many aspects
of it are very Unix-centric, which prevents it from being the
file-sharing system of choice for non-Unix systems.
For example, the set of attributes that NFS Versions 2 and 3 use is
derived completely from Unix without thought about useful attributes
that Windows 98, for example, might need. The other side of the
problem is that some existing NFS attributes are hard to implement by
some non-Unix systems.
- Internationalization and localization
- This refers to pathname strings and not the
contents of files. Technically, filenames in
NFS Versions 2 and 3 can only be 7-bit ASCII, which is very limiting.
Even if one uses the eighth bit, that still doesn't help the
Asian users.
There are no plans to add explicit internationalization and
localization hooks to file content. The NFS protocol's model
has always been to treat the content of files as an opaque stream of
bytes that the application must interpret, and Version 4 will not
vary from that.
There has been talk of adding an optional attribute that describes
the MIME type of contents of the file.
- Extensibility
- After NFS Version 2 was released, it took
nine years for the first NFS Version 3
implementations to appear on the market. It will take at least seven
years from the time NFS Version 3 was first available for Version 4
implementations to be marketed. The gap between Version 2 and Version
3 was especially painful because of the write performance issue. Had
NFS Version 2 included a method for adding procedures, the pain could
have been reduced.
At the time this book was written, the NFS Version 4 working group
published the initial NFS Version 4 specification in the form of RFC
3010, which you can peruse from IETF's web site at http://www.ietf.org. Several of the
participants in the working group have prototype implementations that
interoperate with each other. Early versions of the Linux
implementation are available from http://www.citi.umich.edu/projects/nfsv4/.
Some of the characteristics of NFS Version 4 that are not in Version
3 include:
- No sideband protocols
- The separate protocols for mounting and locking have been
incorporated into the NFS protocol.
- Statefulness
- NFS Version 4 has an OPEN operation that tells the server the client
has opened the file, and a corresponding CLOSE operation. Recall
earlier in this chapter, in Section 7.2.2, "Statelessness and crash recovery" that the point was made that crash
recovery in NFS Versions 2 and 3 is simple because the server retains
very little state. By adding such state, recovery is more
complicated. When a server crashes, clients have a grace period to
reestablish the OPEN state. When a client crashes, because the OPEN
state is leased (i.e., has a time limit that expires if not renewed),
a dead client will eventually have its leases timed out, allowing the
server to delete any state. Another point in Section 7.2.2, "Statelessness and crash recovery" is that the operations in NFS
Versions 2 and 3 are nonidempotent where possible, and the idempotent
operations results are cached in a duplicate request cache. For the
most part, this is still the case with NFS Version 4. The only
exceptions are the OPEN, CLOSE, and locking operations. Operations
like RENAME continue to rely on the duplicate request cache, a
solution with theoretical holes, but in practice has proven to be
quite sufficient. Thus NFS Version 4 retains much of the character of
NFS Versions 2 and 3.
- Aggressive caching
- Because there is an OPEN operation, the client can be much more lazy
about writing data to the server. Indeed, for temporary files, the
server may never see any data written before the client closes and
removes the file.
7.6.2. Security
Aside from lack of multivendor support, the other problem with NFS
security flavors is that they become obsolete rather quickly. To
mitigate this, IETF specified the RPCSEC_GSS security flavor that NFS
and other RPC-based protocols could use to normalize access to
different security mechanisms. RPCSEC_GSS accomplishes this using
another IETF specification called the Generic Security Services
Application Programming Interface (GSS-API). GSS-API is an abstract
layer for generating messages that are encrypted or signed in a form
that can be sent to a peer on the network for decryption or
verification. GSS-API has been specified to work over Kerberos V5,
the Simple Public Key Mechanism, and the Low Infrastructure Public
Key system (LIPKEY). We will discuss NFS security, RPCSEC_GSS, and
Kerberos V5 in more detail in Chapter 12, "Network Security".
The Secure Socket Layer (SSL) and IPSec were considered as candidates
to provide NFS security. SSL wasn't feasible because it was
confined to connection-oriented protocols like TCP, and NFS and RPC
work over TCP and UDP. IPSec wasn't feasible because, as noted
in the section Section 7.2.7, "NFS over TCP", NFS clients
typically don't have a TCP connection per user; whereas, it is
hard, if not impossible, for an IPSec implementation to authenticate
multiple users over a single TCP/IP connection.
| | | 7.5. File locking | | 8. Diskless Clients |
|
|