NFSV4 Editor

This site originally created by Spencer Sheple in 2006, was used by the editor for the NFSv4 minor version 1 internet draft as method of distributing content and issue tracking. The content below is from the site's 2006-2008 archived pages.

The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. 

The Internet Engineering Task Force (IETF) develops and promotes voluntary Internet standards, in particular the standards that comprise the Internet protocol suite (TCP/IP). It is an open standards organization, with no formal membership or membership requirements. All participants and managers are volunteers, though their work is usually funded by their employers or sponsors.

The IETF started out as an activity supported by the U.S. federal government, but since 1993 it has operated as a standards development function under the auspices of the Internet Society, an international membership-based non-profit organization.

For network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture this website would be reasonably easy to comprehend, unlike people like myself. Quite honestly I don't even know if my webmaster for my site, would understand the information on this site. The firm that handles my site's search engine optimization probably have some coders who could look at the the code below and read it like an interesting puzzle. I find it fascinating how a page's code which is incomprehensible to me actually renders into a great looking web page. Most people just don't even think about how something is created on the web. But the men and women who are part of the Internet Engineering Task Force (IETF) which is a large open international community, create similar code everyday. Kudos to them who keep our Internet running smoothly.


NFSv4.1 Editor

How many versions of the I-D will there be before it is done?

The editor for the NFSv4 minor version 1 internet draft uses this site as a method of distributing content and issue tracking. The latest version of the NFSv4.1 I-D is always found on the IETF site. The NFSv4 WG page will have pointers to all of this and includes a pointer to the email archive as well.

Current (2008) NFSv4.1 internet draft

  • draft-ietf-nfsv4-minorversion1-19.txt
  • draft-ietf-nfsv4-minorversion1-19-ln.txt
  • draft-ietf-nfsv4-minorversion1-19.html
  • Diff of draft-18 and draft-19
  • nfsv41.x
  • nfsv41.x diff from draft-18 to draft-19
  • Document Source

Older NFSv4.1 internet drafts

  • NFSv4.1 Draft-18
  • NFSv4.1 Draft-17
  • NFSv4.1 Draft-16
  • NFSv4.1 Draft-15
  • NFSv4.1 Draft-14
  • NFSv4.1 Draft-13
  • NFSv4.1 Draft-12
  • NFSv4.1 Draft-11
  • NFSv4.1 Draft-10
  • NFSv4.1 Draft-09
  • NFSv4.1 Draft-08
  • NFSv4.1 Draft-07
  • NFSv4.1 Draft-06
  • NFSv4.1 Draft-05
  • NFSv4.1 Draft-04
  • NFSv4.1 Draft-03


Session Changes for Trunking Proposal to address Issue 30


• Where we started (RFC3530)
• Changes due to sessions (as of draft-06) • Need for further changes
• Proposed changes
• Follow-up

RFC3530: No trunking

• Each server IP treated as separate server – No way for client to find otherwise
– Not allowed to act on knowledge anyway

• Each client IP treated as separate client

– We have client_id4 to name clients

– But client must put IP in clent_id4
• To make sure server thinks there are two clients

• Summary: Trunking is to be avoided

But wait ...

• We don’t want to avoid trunking

• Trunking useful for:
– Bandwidth aggregation
– multi-pathing for reliability

• Sessions allow trunking
– Multiple connections in a single session – Multiple sessions for a single clientid

• Great! Problem solved.

Issues (as of draft-06)

• How client knows if 2 IP’s are same server – He’s OK if he knows
– Could use DNS in some cases
– No standard reliable way to find out

• How server know if 2 IP’s are same client – Could use client_id4 and compare
– But spec still requires IP in client_id4

Addressing Issues

• Address second one first

  • –  Just take that requirement out

  • –  Requires first problem to be solved

  • –  Otherwise you can have server know there is one client, while client thinks there are 2 servers

  • –  Confusion reigns

  • –  That’s why requirement is in RFC3530

    • Need to solve both problems

Server Identification

• Needs to be reliable
– Avoid false positives and negatives

• Present server id

– Same uniqueness story as client_id4 • Minus your own IP!

– Avoids false negatives

• Can verify using SSV – Avoids false positives

Proposed Solution

• Do EXCHANGE_ID op on new connection – Subsumes CREATE_CLIENTDID

• Client provides client_id4 – Without your own IP

• Server provides clientid (new or existing)

• Server provides server identification – Server id as above
– Session set value (uint32 or uint64)

What client does with id’s

• See if you have a matching server id

– If don’t, new server
• Use the clientid to create a new session

• Existing server: check session

– If it doesn’t match,
• Create second session bound to same client

– If it does match,
• Bind new connection to existing section


• client_id4 change

– Will have to wait lease time for lock to go away when switching to v4.1

• Matches some stuff in locations_info
– Should probably drop that stuff
– More appropriate at server level than fs level

• Could easily address issue 6 this way – Could handle by adding a server-set id



2006 Session Changes for Trunking
Proposal to address Issue 30



Editors: S. Shepler | D.Noveck | M. Eisler
Intended status: Standards Track   
Expires: June 20, 2006

December 22, 2006



NFSv4 Minor Version 1


Status of this Memo

   By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 22, 2006.

Copyright Notice: Copyright (C) The Internet Society (2006).


   This Internet-Draft describes the NFSv4 minor version 1 protocol extensions.  These most significant of these extensions are commonly called: Sessions, Directory Delegations, and parallel NFS or pNFS

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

Shepler   Expires December 22, 2006               [Page 1]

Internet-Draft  NFSv4 Minor Version 1                June 2006


Shepler                 Expires December 22, 2006               [Page 8]

Internet-Draft            NFSv4 Minor Version 1                June 2006


1.  Protocol Data Types

   The syntax and semantics to describe the data types of the NFS
   version 4 protocol are defined in the XDR RFC1832 [2] and RPC RFC1831
   [3] documents.  The next sections build upon the XDR data types to
   define types and structures specific to this protocol.

1.1.  Basic Data Types

                   These are the base NFSv4 data types.

   | Data Type     | Definition                                        |
   | int32_t       | typedef int int32_t;                              |
   | uint32_t      | typedef unsigned int uint32_t;                    |
   | int64_t       | typedef hyper int64_t;                            |
   | uint64_t      | typedef unsigned hyper uint64_t;                  |
   | attrlist4     | typedef opaque attrlist4<>;                       |
   |               | Used for file/directory attributes                |
   | bitmap4       | typedef uint32_t bitmap4<>;                       |
   |               | Used in attribute array encoding.                 |
   | changeid4     | typedef uint64_t changeid4;                       |
   |               | Used in definition of change_info                 |
   | clientid4     | typedef uint64_t clientid4;                       |
   |               | Shorthand reference to client identification      |
   | component4    | typedef utf8str_cs component4;                    |
   |               | Represents path name components                   |
   | count4        | typedef uint32_t count4;                          |
   |               | Various count parameters (READ, WRITE, COMMIT)    |
   | length4       | typedef uint64_t length4;                         |
   |               | Describes LOCK lengths                            |
   | linktext4     | typedef utf8str_cs linktext4;                     |
   |               | Symbolic link contents                            |
   | mode4         | typedef uint32_t mode4;                           |
   |               | Mode attribute data type                          |
   | nfs_cookie4   | typedef uint64_t nfs_cookie4;                     |
   |               | Opaque cookie value for READDIR                   |
   | nfs_fh4       | typedef opaque nfs_fh4               |
   |               | Filehandle definition; NFS4_FHSIZE is defined as  |
   |               | 128                                               |
   | nfs_ftype4    | enum nfs_ftype4;                                  |
   |               | Various defined file types                        |
   | nfsstat4      | enum nfsstat4;                                    |
   |               | Return value for operations                       |
   | offset4       | typedef uint64_t offset4;                         |
   |               | Various offset designations (READ, WRITE, LOCK,   |
   |               | COMMIT)                                           |


Shepler                 Expires December 22, 2006               [Page 9]

Internet-Draft            NFSv4 Minor Version 1                June 2006


   | pathname4     | typedef component4 pathname4<>;                   |
   |               | Represents path name for fs_locations             |
   | qop4          | typedef uint32_t qop4;                            |
   |               | Quality of protection designation in SECINFO      |
   | sec_oid4      | typedef opaque sec_oid4<>;                        |
   |               | Security Object Identifier The sec_oid4 data type |
   |               | is not really opaque. Instead contains an ASN.1   |
   |               | OBJECT IDENTIFIER as used by GSS-API in the       |
   |               | mech_type argument to GSS_Init_sec_context. See   |
   |               | RFC2743 [4] for details.                          |
   | seqid4        | typedef uint32_t seqid4;                          |
   |               | Sequence identifier used for file locking         |
   | utf8string    | typedef opaque utf8string<>;                      |
   |               | UTF-8 encoding for strings                        |
   | utf8str_cis   | typedef opaque utf8str_cis;                       |
   |               | Case-insensitive UTF-8 string                     |
   | utf8str_cs    | typedef opaque utf8str_cs;                        |
   |               | Case-sensitive UTF-8 string                       |
   | utf8str_mixed | typedef opaque utf8str_mixed;                     |
   |               | UTF-8 strings with a case sensitive prefix and a  |
   |               | case insensitive suffix.                          |
   | verifier4     | typedef opaque verifier4[NFS4_VERIFIER_SIZE];     |
   |               | Verifier used for various operations (COMMIT,     |
   |               | CREATE, OPEN, READDIR, SETCLIENTID,               |
   |               | defined as 8.                                     |

                          End of Base Data Types

                                  Table 1

1.2.  Structured Data Types

1.2.1.  nfstime4

   struct nfstime4 {
       int64_t seconds;
       uint32_t nseconds;

   The nfstime4 structure gives the number of seconds and nanoseconds since midnight or 0 hour January 1, 1970 Coordinated Universal Time(UTC).  Values greater than zero for the seconds field denote dates after the 0 hour January 1, 1970.  Values less than zero for the seconds field denote dates before the 0 hour January 1, 1970.  In both cases, the nseconds field is to be added to the seconds field for the final time representation.  For example, if the time to be


Expires December 22, 2006
[Page 10]

Internet-Draft represented is one-half second before 0 hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds fields would have a value of one-half second (500000000).
Values greater than 999,999,999 for nseconds are considered invalid.

his data type is used to pass time and date information.  A server converts to and from its local representation of time when processing time values, preserving as much accuracy as possible.  If the precision of timestamps stored for a filesystem object is less than defined, loss of precision can occur.  An adjunct time maintenance protocol is recommended to reduce client and server time skew.

1.2.2.  time_how4

   enum time_how4 {
       SET_TO_SERVER_TIME4 = 0,
       SET_TO_CLIENT_TIME4 = 1

1.2.3.  settime4

   union settime4 switch (time_how4 set_it) {
       case SET_TO_CLIENT_TIME4:
           nfstime4       time;

   The above definitions are used as the attribute definitions to set
   time values.  If set_it is SET_TO_SERVER_TIME4, then the server uses
   its local representation of time for the time value.

1.2.4.  specdata4

   struct specdata4 {
       uint32_t specdata1; /* major device number */
       uint32_t specdata2; /* minor device number */

   This data type represents additional information for the device file
   types NF4CHR and NF4BLK.

1.2.5.  fsid4

   struct fsid4 {
       uint64_t        major;
       uint64_t        minor;


Shepler                 Expires December 22, 2006              [Page 11]

Internet-Draft            NFSv4 Minor Version 1                June 2006


1.2.6.  fs_location4

   struct fs_location4 {
       utf8str_cis    server<>;
       pathname4     rootpath;

1.2.7.  fs_locations4

   struct fs_locations4 {
       pathname4     fs_root;
       fs_location4  locations<>;

   The fs_location4 and fs_locations4 data types are used for the
   fs_locations recommended attribute which is used for migration and
   replication support.

1.2.8.  fattr4

   struct fattr4 {
       bitmap4       attrmask;
       attrlist4     attr_vals;

   The fattr4 structure is used to represent file and directory

   The bitmap is a counted array of 32 bit integers used to contain bit
   values.  The position of the integer in the array that contains bit n
   can be computed from the expression (n / 32) and its bit within that
   integer is (n mod 32).


   0            1
   |  count    | 31  ..  0 | 63  .. 32 |

1.2.9.  change_info4

   struct change_info4 {
       bool          atomic;
       changeid4     before;
       changeid4     after;

   This structure is used with the CREATE, LINK, REMOVE, RENAME


Shepler                 Expires December 22, 2006              [Page 12]

Internet-Draft            NFSv4 Minor Version 1                June 2006


   operations to let the client know the value of the change attribute
   for the directory in which the target filesystem object resides.

1.2.10.  clientaddr4

   struct clientaddr4 {
       /* see struct rpcb in RFC1833 */
       string r_netid<>;    /* network id */
       string r_addr<>;     /* universal address */

   The clientaddr4 structure is used as part of the SETCLIENTID
   operation to either specify the address of the client that is using a
   clientid or as part of the callback registration.  The r_netid and
   r_addr fields are specified in RFC1833 [9], but they are
   underspecified in RFC1833 [9] as far as what they should look like
   for specific protocols.

   For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the
   US-ASCII string:


   The prefix, "h1.h2.h3.h4", is the standard textual form for
   representing an IPv4 address, which is always four octets long.
   Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
   the first through fourth octets each converted to ASCII-decimal.
   Assuming big-endian ordering, p1 and p2 are, respectively, the first
   and second octets each converted to ASCII-decimal.  For example, if a
   host, in big-endian order, has an address of 0x0A010307 and there is
   a service listening on, in big endian order, port 0x020F (decimal
   527), then complete universal address is "".

   For TCP over IPv4 the value of r_netid is the string "tcp".  For UDP
   over IPv4 the value of r_netid is the string "udp".

   For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the
   US-ASCII string:


   The suffix "p1.p2" is the service port, and is computed the same way
   as with universal addresses for TCP and UDP over IPv4.  The prefix,
   "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for
   representing an IPv6 address as defined in Section 2.2 of RFC1884
   [5].  Additionally, the two alternative forms specified in Section
   2.2 of RFC1884 [5] are also acceptable.


Shepler                 Expires December 22, 2006              [Page 13]

Internet-Draft            NFSv4 Minor Version 1                June 2006


   For TCP over IPv6 the value of r_netid is the string "tcp6".  For UDP
   over IPv6 the value of r_netid is the string "udp6".

1.2.11.  cb_client4

   struct cb_client4 {
       unsigned int  cb_program;
       clientaddr4   cb_location;

   This structure is used by the client to inform the server of its call
   back address; includes the program number and client address.

1.2.12.  nfs_client_id4

   struct nfs_client_id4 {
       verifier4     verifier;
       opaque        id

   This structure is part of the arguments to the SETCLIENTID operation.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.13.  open_owner4

   struct open_owner4 {
       clientid4     clientid;
       opaque        owner

   This structure is used to identify the owner of open state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.14.  lock_owner4

   struct lock_owner4 {
       clientid4     clientid;
       opaque        owner

   This structure is used to identify the owner of file locking state.
   NFS4_OPAQUE_LIMIT is defined as 1024.