NFSv4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | David Noveck , Chuck Lever | ||
| Last updated | 2018-01-03 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-nfsv4-mv1-msns-update-00
quot; attribute for
the current filehandle. For further discussion, refer to
Section 11 of [RFC5661], as modified by the current document.
12.4. Revised Discussion of Server_owner changes
Because of problems with the treatment of such changes, the confusing
paragraph, which simply says that such changes need to be dealt with,
is to be replaced by the one below.
It is always possible that, as a result of various sorts of
reconfiguration events, eir_server_scope and eir_server_owner
values may be different on subsequent EXCHANGE_ID requests made to
the same network address.
In most cases such reconfiguration events will be disruptive and
indicate that an IP address formerly connected to one server is
now connected to an entirely different one.
Some guidelines on client handling of such situations follow:
* When eir_server_scope changes, the client has no assurance that
any id's it obtained previously (e.g. file handles) can be
validly used on the new server, and, even if the new server
accepts them, there is no assurance that this is not due to
accident. Thus it is best to treat all such state as lost/
stale although a client may assume that the probability of
inadvertent acceptance is low and treat this situation as
within the next case.
* When eir_server_scope remains the same and
eir_server_owner.so_major_id changes, the client can use
Noveck & Lever Expires July 7, 2018 [Page 46]
Internet-Draft nfsv4.1-msns-update January 2018
filehandles it has and attempt reclaims. It may find that
these are now stale but if NFS4ERR_STALE is not received, he
can proceed to reclaim his opens.
* When eir_server_scope and eir_server_owner.so_major_id remain
the same, the client has to use the now-current values of
eir_server_owner.so_minor_id in deciding on appropriate forms
of trunking.
12.5. Revision to Treatment of EXCHANGE_ID
There are a number of issues in the original treatment of EXCHANGE_ID
(in [RFC5661]) that cause problems for Transparent State Migration
and for the transfer of access between different network access paths
to the same file system instance.
These issues arise from the fact that this treatment was written:
o assuming that a client ID can only become known to a server by
having been created by executing an EXCHANGE_ID, with confirmation
of the ID only possible by execution of a CREATE_SESSION.
o Considering the interactions between a client and a server only on
a single network address
As these assumptions have become invalid in the context of
Transparent State Migration and active use of trunking, the treatment
has been modified in several respects.
o It had been assumed that an EXCHANGED_ID executed when the server
is already aware of a given client instance must be either
updating associated parameters (e.g. with respect to callbacks) or
a lingering retransmission to deal with a previously lost reply.
As result, any slot sequence returned would be of no use. The
existing treatment goes so far as to say that it "MUST NOT" be
used, although this usage is not in accord with [RFC2119]. This
created a difficulty when an EXCHANGE_ID is done after Transparent
State Migration since that slot sequence needs to be used in a
subsequent CREATE_SESSION.
In the updated treatment, CREATE_SESSION is a way that client IDs
are confirmed but it is understood that other ways are possible.
The slot sequence can be used as needed and cases in which it
would be of no use are appropriately noted.
o It was assumed that the only functions of EXCHANGE_ID were to
inform the server of the client, create the client ID, and
communicate it to the client. When multiple simultaneous
Noveck & Lever Expires July 7, 2018 [Page 47]
Internet-Draft nfsv4.1-msns-update January 2018
connections are involved, as often happens when trunking, that
treatment was inadequate in that it ignored the role of
EXCHANGE_ID in associating the client ID with the connection on
which it was done, so that it could be used by a subsequent
CREATE_SESSSION, whose parameters do not include an explicit
client ID.
The new treatment explicitly discusses the role of EXCHANGE_ID in
associating the client ID with the connection so it can be used by
CREATE_SESSION and in associating a connection with an existing
session.
The new treatment can be found in Section 13 below. It is intended
to supersede the treatment in Section 18.35 of [RFC5661]. Publishing
a complete replacement for Section 18.35 allows the corrected
definition to be read as a whole once [RFC5661] is updated
13. Operation 42: EXCHANGE_ID - Instantiate Client ID (as updated)
The EXCHANGE_ID exchanges long-hand client and server identifiers
(owners), and provides access to a client ID, creating one if
necessary. This client ID becomes associated with the connection on
which the operation is done, so that it is available when a
CREATE_SESSION is done or when the connection is used to issue a
request on an existing session associated with the current client.
13.1. ARGUMENT
const EXCHGID4_FLAG_SUPP_MOVED_REFER = 0x00000001;
const EXCHGID4_FLAG_SUPP_MOVED_MIGR = 0x00000002;
const EXCHGID4_FLAG_BIND_PRINC_STATEID = 0x00000100;
const EXCHGID4_FLAG_USE_NON_PNFS = 0x00010000;
const EXCHGID4_FLAG_USE_PNFS_MDS = 0x00020000;
const EXCHGID4_FLAG_USE_PNFS_DS = 0x00040000;
const EXCHGID4_FLAG_MASK_PNFS = 0x00070000;
const EXCHGID4_FLAG_UPD_CONFIRMED_REC_A = 0x40000000;
const EXCHGID4_FLAG_CONFIRMED_R = 0x80000000;
struct state_protect_ops4 {
bitmap4 spo_must_enforce;
bitmap4 spo_must_allow;
};
struct ssv_sp_parms4 {
Noveck & Lever Expires July 7, 2018 [Page 48]
Internet-Draft nfsv4.1-msns-update January 2018
state_protect_ops4 ssp_ops;
sec_oid4 ssp_hash_algs<>;
sec_oid4 ssp_encr_algs<>;
uint32_t ssp_window;
uint32_t ssp_num_gss_handles;
};
enum state_protect_how4 {
SP4_NONE = 0,
SP4_MACH_CRED = 1,
SP4_SSV = 2
};
union state_protect4_a switch(state_protect_how4 spa_how) {
case SP4_NONE:
void;
case SP4_MACH_CRED:
state_protect_ops4 spa_mach_ops;
case SP4_SSV:
ssv_sp_parms4 spa_ssv_parms;
};
struct EXCHANGE_ID4args {
client_owner4 eia_clientowner;
uint32_t eia_flags;
state_protect4_a eia_state_protect;
nfs_impl_id4 eia_client_impl_id<1>;
};
13.2. RESULT
Noveck & Lever Expires July 7, 2018 [Page 49]
Internet-Draft nfsv4.1-msns-update January 2018
struct ssv_prot_info4 {
state_protect_ops4 spi_ops;
uint32_t spi_hash_alg;
uint32_t spi_encr_alg;
uint32_t spi_ssv_len;
uint32_t spi_window;
gsshandle4_t spi_handles<>;
};
union state_protect4_r switch(state_protect_how4 spr_how) {
case SP4_NONE:
void;
case SP4_MACH_CRED:
state_protect_ops4 spr_mach_ops;
case SP4_SSV:
ssv_prot_info4 spr_ssv_info;
};
struct EXCHANGE_ID4resok {
clientid4 eir_clientid;
sequenceid4 eir_sequenceid;
uint32_t eir_flags;
state_protect4_r eir_state_protect;
server_owner4 eir_server_owner;
opaque eir_server_scope<NFS4_OPAQUE_LIMIT>;
nfs_impl_id4 eir_server_impl_id<1>;
};
union EXCHANGE_ID4res switch (nfsstat4 eir_status) {
case NFS4_OK:
EXCHANGE_ID4resok eir_resok4;
default:
void;
};
13.3. DESCRIPTION
The client uses the EXCHANGE_ID operation to register a particular
client_owner with the server. However, when the client_owner has
been already been registered by other means (e.g. Transparent State
Migration), the client may still use EXCHANGE_ID to obtain the client
ID assigned previously.
The client ID returned from this operation will be associated with
the connection on which the EXHANGE_ID is received and will serve as
a parent object for sessions created by the client on this connection
or to which the connection is bound. As a result of using those
Noveck & Lever Expires July 7, 2018 [Page 50]
Internet-Draft nfsv4.1-msns-update January 2018
sessions to make requests involving the creation of state, that state
will become associated with the client ID returned.
In situations in which the registration of the client_owner has not
occurred previously, the client ID must first be used, along with the
returned eir_sequenceid, in creating an associated session using
CREATE_SESSION.
If the flag EXCHGID4_FLAG_CONFIRMED_R is set in the result,
eir_flags, then it is an indication that the registration of the
client_owner has already occurred and that a further CREATE_SESSION
is not needed to confirm it. Of course, subsequent CREATE_SESSION
operations may be needed for other reasons.
The value eir_sequenceid is used to establish an initial sequence
value associate with the client ID returned. In cases in which a
CREATE_SESSION has already been done, there is no need for this
value, since sequencing of such request has already been established
and the client has no need for this value and will ignore it
EXCHANGE_ID MAY be sent in a COMPOUND procedure that starts with
SEQUENCE. However, when a client communicates with a server for the
first time, it will not have a session, so using SEQUENCE will not be
possible. If EXCHANGE_ID is sent without a preceding SEQUENCE, then
it MUST be the only operation in the COMPOUND procedure's request.
If it is not, the server MUST return NFS4ERR_NOT_ONLY_OP.
The eia_clientowner field is composed of a co_verifier field and a
co_ownerid string. As noted in section 2.4 of [RFC5661], the
co_ownerid describes the client, and the co_verifier is the
incarnation of the client. An EXCHANGE_ID sent with a new
incarnation of the client will lead to the server removing lock state
of the old incarnation. Whereas an EXCHANGE_ID sent with the current
incarnation and co_ownerid will result in an error or an update of
the client ID's properties, depending on the arguments to
EXCHANGE_ID.
A server MUST NOT use the same client ID for two different
incarnations of an eir_clientowner.
In addition to the client ID and sequence ID, the server returns a
server owner (eir_server_owner) and server scope (eir_server_scope).
The former field is used for network trunking as described in
Section 2.10.54 of [RFC5661]. The latter field is used to allow
clients to determine when client IDs sent by one server may be
recognized by another in the event of file system migration (see
Section 8.9 of the current document).
Noveck & Lever Expires July 7, 2018 [Page 51]
Internet-Draft nfsv4.1-msns-update January 2018
The client ID returned by EXCHANGE_ID is only unique relative to the
combination of eir_server_owner.so_major_id and eir_server_scope.
Thus, if two servers return the same client ID, the onus is on the
client to distinguish the client IDs on the basis of
eir_server_owner.so_major_id and eir_server_scope. In the event two
different servers claim matching server_owner.so_major_id and
eir_server_scope, the client can use the verification techniques
discussed in Section 2.10.5 of [RFC5661] to determine if the servers
are distinct. If they are distinct, then the client will need to
note the destination network addresses of the connections used with
each server, and use the network address as the final discriminator.
The server, as defined by the unique identity expressed in the
so_major_id of the server owner and the server scope, needs to track
several properties of each client ID it hands out. The properties
apply to the client ID and all sessions associated with the client
ID. The properties are derived from the arguments and results of
EXCHANGE_ID. The client ID properties include:
o The capabilities expressed by the following bits, which come from
the results of EXCHANGE_ID:
* EXCHGID4_FLAG_SUPP_MOVED_REFER
* EXCHGID4_FLAG_SUPP_MOVED_MIGR
* EXCHGID4_FLAG_BIND_PRINC_STATEID
* EXCHGID4_FLAG_USE_NON_PNFS
* EXCHGID4_FLAG_USE_PNFS_MDS
* EXCHGID4_FLAG_USE_PNFS_DS
These properties may be updated by subsequent EXCHANGE_ID requests
on confirmed client IDs though the server MAY refuse to change
them.
o The state protection method used, one of SP4_NONE, SP4_MACH_CRED,
or SP4_SSV, as set by the spa_how field of the arguments to
EXCHANGE_ID. Once the client ID is confirmed, this property
cannot be updated by subsequent EXCHANGE_ID requests.
o For SP4_MACH_CRED or SP4_SSV state protection:
* The list of operations (spo_must_enforce) that MUST use the
specified state protection. This list comes from the results
of EXCHANGE_ID.
Noveck & Lever Expires July 7, 2018 [Page 52]
Internet-Draft nfsv4.1-msns-update January 2018
* The list of operations (spo_must_allow) that MAY use the
specified state protection. This list comes from the results
of EXCHANGE_ID.
Once the client ID is confirmed, these properties cannot be
updated by subsequent EXCHANGE_ID requests.
o For SP4_SSV protection:
* The OID of the hash algorithm. This property is represented by
one of the algorithms in the ssp_hash_algs field of the
EXCHANGE_ID arguments. Once the client ID is confirmed, this
property cannot be updated by subsequent EXCHANGE_ID requests.
* The OID of the encryption algorithm. This property is
represented by one of the algorithms in the ssp_encr_algs field
of the EXCHANGE_ID arguments. Once the client ID is confirmed,
this property cannot be updated by subsequent EXCHANGE_ID
requests.
* The length of the SSV. This property is represented by the
spi_ssv_len field in the EXCHANGE_ID results. Once the client
ID is confirmed, this property cannot be updated by subsequent
EXCHANGE_ID requests.
There are REQUIRED and RECOMMENDED relationships among the
length of the key of the encryption algorithm ("key length"),
the length of the output of hash algorithm ("hash length"), and
the length of the SSV ("SSV length").
+ key length MUST be <= hash length. This is because the keys
used for the encryption algorithm are actually subkeys
derived from the SSV, and the derivation is via the hash
algorithm. The selection of an encryption algorithm with a
key length that exceeded the length of the output of the
hash algorithm would require padding, and thus weaken the
use of the encryption algorithm.
+ hash length SHOULD be <= SSV length. This is because the
SSV is a key used to derive subkeys via an HMAC, and it is
recommended that the key used as input to an HMAC be at
least as long as the length of the HMAC's hash algorithm's
output (see Section 3 of [RFC2104]).
+ key length SHOULD be <= SSV length. This is a transitive
result of the above two invariants.
Noveck & Lever Expires July 7, 2018 [Page 53]
Internet-Draft nfsv4.1-msns-update January 2018
+ key length SHOULD be >= hash length / 2. This is because
the subkey derivation is via an HMAC and it is recommended
that if the HMAC has to be truncated, it should not be
truncated to less than half the hash length (see Section 4
of RFC2104 [RFC2104]).
* Number of concurrent versions of the SSV the client and server
will support (see Section 2.10.9 of [RFC5661]). This property
is represented by spi_window in the EXCHANGE_ID results. The
property may be updated by subsequent EXCHANGE_ID requests.
o The client's implementation ID as represented by the
eia_client_impl_id field of the arguments. The property may be
updated by subsequent EXCHANGE_ID requests.
o The server's implementation ID as represented by the
eir_server_impl_id field of the reply. The property may be
updated by replies to subsequent EXCHANGE_ID requests.
The eia_flags passed as part of the arguments and the eir_flags
results allow the client and server to inform each other of their
capabilities as well as indicate how the client ID will be used.
Whether a bit is set or cleared on the arguments' flags does not
force the server to set or clear the same bit on the results' side.
Bits not defined above cannot be set in the eia_flags field. If they
are, the server MUST reject the operation with NFS4ERR_INVAL.
The EXCHGID4_FLAG_UPD_CONFIRMED_REC_A bit can only be set in
eia_flags; it is always off in eir_flags. The
EXCHGID4_FLAG_CONFIRMED_R bit can only be set in eir_flags; it is
always off in eia_flags. If the server recognizes the co_ownerid and
co_verifier as mapping to a confirmed client ID, it sets
EXCHGID4_FLAG_CONFIRMED_R in eir_flags. The
EXCHGID4_FLAG_CONFIRMED_R flag allows a client to tell if the client
ID it is trying to create already exists and is confirmed.
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set in eia_flags, this means
that the client is attempting to update properties of an existing
confirmed client ID (if the client wants to update properties of an
unconfirmed client ID, it MUST NOT set
EXCHGID4_FLAG_UPD_CONFIRMED_REC_A). If so, it is RECOMMENDED that
the client send the update EXCHANGE_ID operation in the same COMPOUND
as a SEQUENCE so that the EXCHANGE_ID is executed exactly once.
Whether the client can update the properties of client ID depends on
the state protection it selected when the client ID was created, and
the principal and security flavor it uses when sending the
EXCHANGE_ID request. The situations described in items 6, 7, 8, or 9
of the second numbered list of Section 13.4 below will apply. Note
Noveck & Lever Expires July 7, 2018 [Page 54]
Internet-Draft nfsv4.1-msns-update January 2018
that if the operation succeeds and returns a client ID that is
already confirmed, the server MUST set the EXCHGID4_FLAG_CONFIRMED_R
bit in eir_flags.
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set in eia_flags, this
means that the client is trying to establish a new client ID; it is
attempting to trunk data communication to the server (See
Section 2.10.5 of [RFC5661]); or it is attempting to update
properties of an unconfirmed client ID. The situations described in
items 1, 2, 3, 4, or 5 of the second numbered list of Section 13.4
below will apply. Note that if the operation succeeds and returns a
client ID that was previously confirmed, the server MUST set the
EXCHGID4_FLAG_CONFIRMED_R bit in eir_flags.
When the EXCHGID4_FLAG_SUPP_MOVED_REFER flag bit is set, the client
indicates that it is capable of dealing with an NFS4ERR_MOVED error
as part of a referral sequence. When this bit is not set, it is
still legal for the server to perform a referral sequence. However,
a server may use the fact that the client is incapable of correctly
responding to a referral, by avoiding it for that particular client.
It may, for instance, act as a proxy for that particular file system,
at some cost in performance, although it is not obligated to do so.
If the server will potentially perform a referral, it MUST set
EXCHGID4_FLAG_SUPP_MOVED_REFER in eir_flags.
When the EXCHGID4_FLAG_SUPP_MOVED_MIGR is set, the client indicates
that it is capable of dealing with an NFS4ERR_MOVED error as part of
a file system migration sequence. When this bit is not set, it is
still legal for the server to indicate that a file system has moved,
when this in fact happens. However, a server may use the fact that
the client is incapable of correctly responding to a migration in its
scheduling of file systems to migrate so as to avoid migration of
file systems being actively used. It may also hide actual migrations
from clients unable to deal with them by acting as a proxy for a
migrated file system for particular clients, at some cost in
performance, although it is not obligated to do so. If the server
will potentially perform a migration, it MUST set
EXCHGID4_FLAG_SUPP_MOVED_MIGR in eir_flags.
When EXCHGID4_FLAG_BIND_PRINC_STATEID is set, the client indicates
that it wants the server to bind the stateid to the principal. This
means that when a principal creates a stateid, it has to be the one
to use the stateid. If the server will perform binding, it will
return EXCHGID4_FLAG_BIND_PRINC_STATEID. The server MAY return
EXCHGID4_FLAG_BIND_PRINC_STATEID even if the client does not request
it. If an update to the client ID changes the value of
EXCHGID4_FLAG_BIND_PRINC_STATEID's client ID property, the effect
applies only to new stateids. Existing stateids (and all stateids
Noveck & Lever Expires July 7, 2018 [Page 55]
Internet-Draft nfsv4.1-msns-update January 2018
with the same "other" field) that were created with stateid to
principal binding in force will continue to have binding in force.
Existing stateids (and all stateids with the same "other" field) that
were created with stateid to principal not in force will continue to
have binding not in force.
The EXCHGID4_FLAG_USE_NON_PNFS, EXCHGID4_FLAG_USE_PNFS_MDS, and
EXCHGID4_FLAG_USE_PNFS_DS bits are described in Section 13.1 of
[RFC5661] and convey roles the client ID is to be used for in a pNFS
environment. The server MUST set one of the acceptable combinations
of these bits (roles) in eir_flags, as specified in that section.
Note that the same client owner/server owner pair can have multiple
roles. Multiple roles can be associated with the same client ID or
with different client IDs. Thus, if a client sends EXCHANGE_ID from
the same client owner to the same server owner multiple times, but
specifies different pNFS roles each time, the server might return
different client IDs. Given that different pNFS roles might have
different client IDs, the client may ask for different properties for
each role/client ID.
The spa_how field of the eia_state_protect field specifies how the
client wants to protect its client, locking, and session states from
unauthorized changes (Section 2.10.8.3 of [RFC5661]):
o SP4_NONE. The client does not request the NFSv4.1 server to
enforce state protection. The NFSv4.1 server MUST NOT enforce
state protection for the returned client ID.
o SP4_MACH_CRED. If spa_how is SP4_MACH_CRED, then the client MUST
send the EXCHANGE_ID request with RPCSEC_GSS as the security
flavor, and with a service of RPC_GSS_SVC_INTEGRITY or
RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the
client wants to use an RPCSEC_GSS-based machine credential to
protect its state. The server MUST note the principal the
EXCHANGE_ID operation was sent with, and the GSS mechanism used.
These notes collectively comprise the machine credential.
After the client ID is confirmed, as long as the lease associated
with the client ID is unexpired, a subsequent EXCHANGE_ID
operation that uses the same eia_clientowner.co_owner as the first
EXCHANGE_ID MUST also use the same machine credential as the first
EXCHANGE_ID. The server returns the same client ID for the
subsequent EXCHANGE_ID as that returned from the first
EXCHANGE_ID.
o SP4_SSV. If spa_how is SP4_SSV, then the client MUST send the
EXCHANGE_ID request with RPCSEC_GSS as the security flavor, and
with a service of RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY.
Noveck & Lever Expires July 7, 2018 [Page 56]
Internet-Draft nfsv4.1-msns-update January 2018
If SP4_SSV is specified, then the client wants to use the SSV to
protect its state. The server records the credential used in the
request as the machine credential (as defined above) for the
eia_clientowner.co_owner. The CREATE_SESSION operation that
confirms the client ID MUST use the same machine credential.
When a client specifies SP4_MACH_CRED or SP4_SSV, it also provides
two lists of operations (each expressed as a bitmap). The first list
is spo_must_enforce and consists of those operations the client MUST
send (subject to the server confirming the list of operations in the
result of EXCHANGE_ID) with the machine credential (if SP4_MACH_CRED
protection is specified) or the SSV-based credential (if SP4_SSV
protection is used). The client MUST send the operations with
RPCSEC_GSS credentials that specify the RPC_GSS_SVC_INTEGRITY or
RPC_GSS_SVC_PRIVACY security service. Typically, the first list of
operations includes EXCHANGE_ID, CREATE_SESSION, DELEGPURGE,
DESTROY_SESSION, BIND_CONN_TO_SESSION, and DESTROY_CLIENTID. The
client SHOULD NOT specify in this list any operations that require a
filehandle because the server's access policies MAY conflict with the
client's choice, and thus the client would then be unable to access a
subset of the server's namespace.
Note that if SP4_SSV protection is specified, and the client
indicates that CREATE_SESSION must be protected with SP4_SSV, because
the SSV cannot exist without a confirmed client ID, the first
CREATE_SESSION MUST instead be sent using the machine credential, and
the server MUST accept the machine credential.
There is a corresponding result, also called spo_must_enforce, of the
operations for which the server will require SP4_MACH_CRED or SP4_SSV
protection. Normally, the server's result equals the client's
argument, but the result MAY be different. If the client requests
one or more operations in the set { EXCHANGE_ID, CREATE_SESSION,
DELEGPURGE, DESTROY_SESSION, BIND_CONN_TO_SESSION, DESTROY_CLIENTID
}, then the result spo_must_enforce MUST include the operations the
client requested from that set.
If spo_must_enforce in the results has BIND_CONN_TO_SESSION set, then
connection binding enforcement is enabled, and the client MUST use
the machine (if SP4_MACH_CRED protection is used) or SSV (if SP4_SSV
protection is used) credential on calls to BIND_CONN_TO_SESSION.
The second list is spo_must_allow and consists of those operations
the client wants to have the option of sending with the machine
credential or the SSV-based credential, even if the object the
operations are performed on is not owned by the machine or SSV
credential.
Noveck & Lever Expires July 7, 2018 [Page 57]
Internet-Draft nfsv4.1-msns-update January 2018
The corresponding result, also called spo_must_allow, consists of the
operations the server will allow the client to use SP4_SSV or
SP4_MACH_CRED credentials with. Normally, the server's result equals
the client's argument, but the result MAY be different.
The purpose of spo_must_allow is to allow clients to solve the
following conundrum. Suppose the client ID is confirmed with
EXCHGID4_FLAG_BIND_PRINC_STATEID, and it calls OPEN with the
RPCSEC_GSS credentials of a normal user. Now suppose the user's
credentials expire, and cannot be renewed (e.g., a Kerberos ticket
granting ticket expires, and the user has logged off and will not be
acquiring a new ticket granting ticket). The client will be unable
to send CLOSE without the user's credentials, which is to say the
client has to either leave the state on the server or re-send
EXCHANGE_ID with a new verifier to clear all state, that is, unless
the client includes CLOSE on the list of operations in spo_must_allow
and the server agrees.
The SP4_SSV protection parameters also have:
ssp_hash_algs:
This is the set of algorithms the client supports for the purpose
of computing the digests needed for the internal SSV GSS mechanism
and for the SET_SSV operation. Each algorithm is specified as an
object identifier (OID). The REQUIRED algorithms for a server are
id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512 [RFC4055].
The algorithm the server selects among the set is indicated in
spi_hash_alg, a field of spr_ssv_prot_info. The field
spi_hash_alg is an index into the array ssp_hash_algs. If the
server does not support any of the offered algorithms, it returns
NFS4ERR_HASH_ALG_UNSUPP. If ssp_hash_algs is empty, the server
MUST return NFS4ERR_INVAL.
ssp_encr_algs:
This is the set of algorithms the client supports for the purpose
of providing privacy protection for the internal SSV GSS
mechanism. Each algorithm is specified as an OID. The REQUIRED
algorithm for a server is id-aes256-CBC. The RECOMMENDED
algorithms are id-aes192-CBC and id-aes128-CBC [CSOR_AES]. The
selected algorithm is returned in spi_encr_alg, an index into
ssp_encr_algs. If the server does not support any of the offered
algorithms, it returns NFS4ERR_ENCR_ALG_UNSUPP. If ssp_encr_algs
is empty, the server MUST return NFS4ERR_INVAL. Note that due to
previously stated requirements and recommendations on the
relationships between key length and hash length, some
combinations of RECOMMENDED and REQUIRED encryption algorithm and
Noveck & Lever Expires July 7, 2018 [Page 58]
Internet-Draft nfsv4.1-msns-update January 2018
hash algorithm either SHOULD NOT or MUST NOT be used. Table 1
summarizes the illegal and discouraged combinations.
ssp_window:
This is the number of SSV versions the client wants the server to
maintain (i.e., each successful call to SET_SSV produces a new
version of the SSV). If ssp_window is zero, the server MUST
return NFS4ERR_INVAL. The server responds with spi_window, which
MUST NOT exceed ssp_window, and MUST be at least one. Any
requests on the backchannel or fore channel that are using a
version of the SSV that is outside the window will fail with an
ONC RPC authentication error, and the requester will have to retry
them with the same slot ID and sequence ID.
ssp_num_gss_handles:
This is the number of RPCSEC_GSS handles the server should create
that are based on the GSS SSV mechanism (see section 2.10.9 of
[RFC5661]). It is not the total number of RPCSEC_GSS handles for
the client ID. Indeed, subsequent calls to EXCHANGE_ID will add
RPCSEC_GSS handles. The server responds with a list of handles in
spi_handles. If the client asks for at least one handle and the
server cannot create it, the server MUST return an error. The
handles in spi_handles are not available for use until the client
ID is confirmed, which could be immediately if EXCHANGE_ID returns
EXCHGID4_FLAG_CONFIRMED_R, or upon successful confirmation from
CREATE_SESSION.
While a client ID can span all the connections that are connected
to a server sharing the same eir_server_owner.so_major_id, the
RPCSEC_GSS handles returned in spi_handles can only be used on
connections connected to a server that returns the same the
eir_server_owner.so_major_id and eir_server_owner.so_minor_id on
each connection. It is permissible for the client to set
ssp_num_gss_handles to zero; the client can create more handles
with another EXCHANGE_ID call.
Because each SSV RPCSEC_GSS handle shares a common SSV GSS
context, there are security considerations specific to this
situation discussed in Section 2.10.10 of [RFC5661].
The seq_window (see Section 5.2.3.1 of [RFC2203]) of each
RPCSEC_GSS handle in spi_handle MUST be the same as the seq_window
of the RPCSEC_GSS handle used for the credential of the RPC
request that the EXCHANGE_ID request was sent with.
Noveck & Lever Expires July 7, 2018 [Page 59]
Internet-Draft nfsv4.1-msns-update January 2018
+-------------------+----------------------+------------------------+
| Encryption | MUST NOT be combined | SHOULD NOT be combined |
| Algorithm | with | with |
+-------------------+----------------------+------------------------+
| id-aes128-CBC | | id-sha384, id-sha512 |
| id-aes192-CBC | id-sha1 | id-sha512 |
| id-aes256-CBC | id-sha1, id-sha224 | |
+-------------------+----------------------+------------------------+
Table 1
The arguments include an array of up to one element in length called
eia_client_impl_id. If eia_client_impl_id is present, it contains
the information identifying the implementation of the client.
Similarly, the results include an array of up to one element in
length called eir_server_impl_id that identifies the implementation
of the server. Servers MUST accept a zero-length eia_client_impl_id
array, and clients MUST accept a zero-length eir_server_impl_id
array.
A possible use for implementation identifiers would be in diagnostic
software that extracts this information in an attempt to identify
interoperability problems, performance workload behaviors, or general
usage statistics. Since the intent of having access to this
information is for planning or general diagnosis only, the client and
server MUST NOT interpret this implementation identity information in
a way that affects how the implementation behaves in interacting with
its peer. The client and server are not allowed to depend on the
peer's manifesting a particular allowed behavior based on an
implementation identifier but are required to interoperate as
specified elsewhere in the protocol specification.
Because it is possible that some implementations might violate the
protocol specification and interpret the identity information,
implementations MUST provide facilities to allow the NFSv4 client and
server be configured to set the contents of the nfs_impl_id
structures sent to any specified value.
13.4. IMPLEMENTATION
A server's client record is a 5-tuple:
1. co_ownerid
The client identifier string, from the eia_clientowner
structure of the EXCHANGE_ID4args structure.
2. co_verifier:
Noveck & Lever Expires July 7, 2018 [Page 60]
Internet-Draft nfsv4.1-msns-update January 2018
A client-specific value used to indicate incarnations (where a
client restart represents a new incarnation), from the
eia_clientowner structure of the EXCHANGE_ID4args structure.
3. principal:
The principal that was defined in the RPC header's credential
and/or verifier at the time the client record was established.
4. client ID:
The shorthand client identifier, generated by the server and
returned via the eir_clientid field in the EXCHANGE_ID4resok
structure.
5. confirmed:
A private field on the server indicating whether or not a
client record has been confirmed. A client record is
confirmed if there has been a successful CREATE_SESSION
operation to confirm it. Otherwise, it is unconfirmed. An
unconfirmed record is established by an EXCHANGE_ID call. Any
unconfirmed record that is not confirmed within a lease period
SHOULD be removed.
The following identifiers represent special values for the fields in
the records.
ownerid_arg:
The value of the eia_clientowner.co_ownerid subfield of the
EXCHANGE_ID4args structure of the current request.
verifier_arg:
The value of the eia_clientowner.co_verifier subfield of the
EXCHANGE_ID4args structure of the current request.
old_verifier_arg:
A value of the eia_clientowner.co_verifier field of a client
record received in a previous request; this is distinct from
verifier_arg.
principal_arg:
The value of the RPCSEC_GSS principal for the current request.
Noveck & Lever Expires July 7, 2018 [Page 61]
Internet-Draft nfsv4.1-msns-update January 2018
old_principal_arg:
A value of the principal of a client record as defined by the RPC
header's credential or verifier of a previous request. This is
distinct from principal_arg.
clientid_ret:
The value of the eir_clientid field the server will return in the
EXCHANGE_ID4resok structure for the current request.
old_clientid_ret:
The value of the eir_clientid field the server returned in the
EXCHANGE_ID4resok structure for a previous request. This is
distinct from clientid_ret.
confirmed:
The client ID has been confirmed.
unconfirmed:
The client ID has not been confirmed.
Since EXCHANGE_ID is a non-idempotent operation, we must consider the
possibility that retries occur as a result of a client restart,
network partition, malfunctioning router, etc. Retries are
identified by the value of the eia_clientowner field of
EXCHANGE_ID4args, and the method for dealing with them is outlined in
the scenarios below.
The scenarios are described in terms of the client record(s) a server
has for a given co_ownerid. Note that if the client ID was created
specifying SP4_SSV state protection and EXCHANGE_ID as the one of the
operations in spo_must_allow, then the server MUST authorize
EXCHANGE_IDs with the SSV principal in addition to the principal that
created the client ID.
1. New Owner ID
If the server has no client records with
eia_clientowner.co_ownerid matching ownerid_arg, and
EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set in the
EXCHANGE_ID, then a new shorthand client ID (let us call it
clientid_ret) is generated, and the following unconfirmed
record is added to the server's state.
Noveck & Lever Expires July 7, 2018 [Page 62]
Internet-Draft nfsv4.1-msns-update January 2018
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed }
Subsequently, the server returns clientid_ret.
2. Non-Update on Existing Client ID
If the server has the following confirmed record, and the
request does not have EXCHGID4_FLAG_UPD_CONFIRMED_REC_A set,
then the request is the result of a retried request due to a
faulty router or lost connection, or the client is trying to
determine if it can perform trunking.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
confirmed }
Since the record has been confirmed, the client must have
received the server's reply from the initial EXCHANGE_ID
request. Since the server has a confirmed record, and since
EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, with the
possible exception of eir_server_owner.so_minor_id, the server
returns the same result it did when the client ID's properties
were last updated (or if never updated, the result when the
client ID was created). The confirmed record is unchanged.
3. Client Collision
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the
server has the following confirmed record, then this request
is likely the result of a chance collision between the values
of the eia_clientowner.co_ownerid subfield of EXCHANGE_ID4args
for two different clients.
{ ownerid_arg, *, old_principal_arg, old_clientid_ret,
confirmed }
If there is currently no state associated with
old_clientid_ret, or if there is state but the lease has
expired, then this case is effectively equivalent to the New
Owner ID case of Paragraph 1. The confirmed record is
deleted, the old_clientid_ret and its lock state are deleted,
a new shorthand client ID is generated, and the following
unconfirmed record is added to the server's state.
Noveck & Lever Expires July 7, 2018 [Page 63]
Internet-Draft nfsv4.1-msns-update January 2018
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed }
Subsequently, the server returns clientid_ret.
If old_clientid_ret has an unexpired lease with state, then no
state of old_clientid_ret is changed or deleted. The server
returns NFS4ERR_CLID_INUSE to indicate that the client should
retry with a different value for the
eia_clientowner.co_ownerid subfield of EXCHANGE_ID4args. The
client record is not changed.
4. Replacement of Unconfirmed Record
If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and
the server has the following unconfirmed record, then the
client is attempting EXCHANGE_ID again on an unconfirmed
client ID, perhaps due to a retry, a client restart before
client ID confirmation (i.e., before CREATE_SESSION was
called), or some other reason.
{ ownerid_arg, *, *, old_clientid_ret, unconfirmed }
It is possible that the properties of old_clientid_ret are
different than those specified in the current EXCHANGE_ID.
Whether or not the properties are being updated, to eliminate
ambiguity, the server deletes the unconfirmed record,
generates a new client ID (clientid_ret), and establishes the
following unconfirmed record:
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed }
5. Client Restart
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the
server has the following confirmed client record, then this
request is likely from a previously confirmed client that has
restarted.
{ ownerid_arg, old_verifier_arg, principal_arg,
old_clientid_ret, confirmed }
Noveck & Lever Expires July 7, 2018 [Page 64]
Internet-Draft nfsv4.1-msns-update January 2018
Since the previous incarnation of the same client will no
longer be making requests, once the new client ID is confirmed
by CREATE_SESSION, byte-range locks and share reservations
should be released immediately rather than forcing the new
incarnation to wait for the lease time on the previous
incarnation to expire. Furthermore, session state should be
removed since if the client had maintained that information
across restart, this request would not have been sent. If the
server supports neither the CLAIM_DELEGATE_PREV nor
CLAIM_DELEG_PREV_FH claim types, associated delegations should
be purged as well; otherwise, delegations are retained and
recovery proceeds according to section 10.2.1 of [RFC5661].
After processing, clientid_ret is returned to the client and
this client record is added:
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed }
The previously described confirmed record continues to exist,
and thus the same ownerid_arg exists in both a confirmed and
unconfirmed state at the same time. The number of states can
collapse to one once the server receives an applicable
CREATE_SESSION or EXCHANGE_ID.
+ If the server subsequently receives a successful
CREATE_SESSION that confirms clientid_ret, then the server
atomically destroys the confirmed record and makes the
unconfirmed record confirmed as described in section
16.36.3 of [RFC5661].
+ If the server instead subsequently receives an EXCHANGE_ID
with the client owner equal to ownerid_arg, one strategy is
to simply delete the unconfirmed record, and process the
EXCHANGE_ID as described in the entirety of Section 13.4.
6. Update
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server
has the following confirmed record, then this request is an
attempt at an update.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret,
confirmed }
Noveck & Lever Expires July 7, 2018 [Page 65]
Internet-Draft nfsv4.1-msns-update January 2018
Since the record has been confirmed, the client must have
received the server's reply from the initial EXCHANGE_ID
request. The server allows the update, and the client record
is left intact.
7. Update but No Confirmed Record
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server
has no confirmed record corresponding ownerid_arg, then the
server returns NFS4ERR_NOENT and leaves any unconfirmed record
intact.
8. Update but Wrong Verifier
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server
has the following confirmed record, then this request is an
illegal attempt at an update, perhaps because of a retry from
a previous client incarnation.
{ ownerid_arg, old_verifier_arg, *, clientid_ret, confirmed }
The server returns NFS4ERR_NOT_SAME and leaves the client
record intact.
9. Update but Wrong Principal
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server
has the following confirmed record, then this request is an
illegal attempt at an update by an unauthorized principal.
{ ownerid_arg, verifier_arg, old_principal_arg, clientid_ret,
confirmed }
The server returns NFS4ERR_PERM and leaves the client record
intact.
14. Security Considerations
The Security Considerations section of [RFC5661] needs the additions
below to properly address some aspects of trunking discovery,
referral, migration and replication.
The possibility that requests to determine the set of network
addresses corresponding to a given server might be interfered with
or have their responses corrupted needs to be taken into account.
In light of this, the following considerations should be taken
note of:
Noveck & Lever Expires July 7, 2018 [Page 66]
Internet-Draft nfsv4.1-msns-update January 2018
o When DNS is used to convert server named to addresses and
DNSSEC [RFC4033] is not available, the validity of the network
addresses returned cannot be relied upon. However, when the
client uses RPCSEC_GSS to access the designated server, it is
possible for mutual authentication to discover invalid server
addresses provided.
o The fetching of attributes containing location information
SHOULD be performed using RPCSEC_GSS with integrity protection,
as previously explained in the Security Considerations section
of [RFC5661]. It is important to note here that a client
making a request of this sort without using RPCSEC_GSS
including integrity protection needs be aware of the negative
consequences of doing so, which can lead to invalid host names
or network addresses being returned. In light of this, the
client needs to recognize that using such returned location
information to access an NFSv4 server without use of RPCSEC_GSS
(i.e. by using AUTH_SYS) poses dangers as it can result in the
client interacting with an unverified network address posing as
an NFSv4 server.
o Despite the fact that it is a REQUIREMENT (of [RFC5661]) that
"implementations" provide "support" for use of RPCSEC_GSS, it
cannot be assumed that use of RPCSEC_GSS is always available
between any particular client-server pair.
o When a client has the network addresses of a server but not the
associated host names, that would interfere with its ability to
use RPCSEC_GSS.
In light of the above, a server should present location entries
that correspond to file systems on other servers using a host
name. This would allow the client to interrogate the fs_locations
on the destination server to obtain trunking information (as well
as replica information) using RPCSEC_GSS with integrity,
validating the name provided while assuring that the response has
not been corrupted.
When RPCSEC_GSS is not available on a server, the client needs to
be aware of the fact that the location entries are subject to
corruption and cannot be relied upon. In the case of a client
being directed to another server after NFS4ERR_MOVED, this could
vitiate the authentication provided by the use of RPCSEC_GSS on
the destination. Even when RPCSEC_GSS authentication is available
on the destination, the server might validly represent itself as
the server to which the client was erroneously directed. Without
a way to decide whether the server is a valid one, the client can
only determine, using RPCSEC_GSS, that the server corresponds to
Noveck & Lever Expires July 7, 2018 [Page 67]
Internet-Draft nfsv4.1-msns-update January 2018
the name provided, with no basis for trusting that server. As a
result, the client should not use such unverified location entries
as a basis for migration, even though RPCSEC_GSS might be
available on the destination.
When a location attribute is fetched upon connecting with an NFS
server, it SHOULD, as stated above, be done using RPCSEC_GSS with
integrity protection. When this not possible, it is generally
best for the client to ignore trunking and replica information or
simply not fetch the location information for these purposes.
When location information cannot be verified, it can be subjected
to additional filtering to prevent the client from being
inappropriately directed. For example, if a range of network
addresses can be determined that assure that the servers and
clients using AUTH_SYS are subject to the appropriate set of
constrains (e.g. physical network isolation, administrative
controls on the operating systems used), then network addresses in
the appropriate range can be used with others discarded or
restricted in their use of AUTH_SYS.
To summarize considerations regarding the use of RPCSEC_GSS in
fetching location information, we need to consider the following
possibilities for requests to interrogate location information,
with interrogation approaches on the referring and destination
servers arrived at separately:
o The use of RPCSEC_GSS with integrity protection is RECOMMENDED
in all cases, since the absence of integrity protection exposes
the client to the possibility of the results being modified in
transit.
o The use of requests issued without RPCSEC_GSS (i.e. using
AUTH_SYS), while undesirable, may not be avoidable in all
cases. Where the use of the returned information cannot be
avoided, it should be subject to filtering to eliminate the
possibility that the client would treat an invalid address as
if it were a NFSv4 server. The specifics will vary depending
on the degree of network isolation and whether the request is
to the referring or destination servers.
15. IANA Considerations
This document does not require actions by IANA.
Noveck & Lever Expires July 7, 2018 [Page 68]
Internet-Draft nfsv4.1-msns-update January 2018
16. References
16.1. Normative References
[CSOR_AES]
National Institute of Standards and Technology,
"Cryptographic Algorithm Object Registration", URL
http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/
algorithms.html, November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <https://www.rfc-editor.org/info/rfc2203>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
DOI 10.17487/RFC5403, February 2009,
<https://www.rfc-editor.org/info/rfc5403>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>.
Noveck & Lever Expires July 7, 2018 [Page 69]
Internet-Draft nfsv4.1-msns-update January 2018
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016,
<https://www.rfc-editor.org/info/rfc7931>.
16.2. Informative References
[I-D.cel-nfsv4-mv0-trunking-update]
Lever, C. and D. Noveck, "NFS version 4.0 Trunking
Update", draft-cel-nfsv4-mv0-trunking-update-00 (work in
progress), November 2017.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
Appendix A. Classification of Document Sections
Using the classification appearing in Section 3.3, we can proceed
through the current document and classify its sections as listed
below. In this listing, when we refer to a Section X and there is a
Section X.1 within it, the classification of Section X refers to the
part of that section exclusive of subsections. In the case when that
portion is empty, the section is not counted.
o Sections 1 through 4, a total of five sections, are all
explanatory.
o Section 4.1 is a replacement section.
o Section 4.3 is an additional sections.
o Section 4.3 is a replacement sections.
o Section 4.4 is explanatory.
o Section 4.5 is a replacement section.
o Sections 4.5.1 and 4.5.2 are additional sections.
o Sections 4.5.3 through 4.5.5, a total of three sections, are all
replacement sections.
o Section 4.5.6 is an additional section.
o Section 5 is explanatory.
Noveck & Lever Expires July 7, 2018 [Page 70]
Internet-Draft nfsv4.1-msns-update January 2018
o Sections 6 and 7 are additional sections.
o Sections 8 through 8.9, a total of ten sections, are all
replacement sections.
o Sections 9 through 11.2, a total of eleven sections, are all
additional sections.
o Section 12 is explanatory.
o Sections 12.1 and 12.2 are replacement sections.
o Sections 12.3 and 12.4 are editing sections.
o Section 12.5 is explanatory.
o Section 13 is a replacement section, which consists of a total of
five sections.
o Section 14 is an editing section.
o Section 15 through Acknowledgments, a total of six sections, are
all explanatory.
To summarize:
o There are fifteen explanatory sections.
o There are twenty-two replacement sections.
o There are seventeen additional sections.
o There are three editing sections.
Appendix B. Updates to RFC5661
In this appendix, we proceed through [RFC5661] identifying sections
as unchanged, modified, deleted, or replaced and indicating where
additional sections from the current document would appear in an
eventual consolidated description of NFSv4.1. In this presentation,
when section X is referred to, it denotes that section plus all
included subsections. When it is necessary to refer to the part of a
section outside any included subsections, the exclusion is noted
explicitly.
o Section 1 is unmodified except that Section 1.7.3.3 is to be
replaced by Section 12.1 from the current document.
Noveck & Lever Expires July 7, 2018 [Page 71]
Internet-Draft nfsv4.1-msns-update January 2018
o Section 2 is unmodified except for the specific items listed
below:
o Section 2.10.4 is replaced by Section 12.2 from the current
document.
o Section 2.10.5 is modified as discussed in Section 12.4 of the
current document.
o Sections 3 through 10 are unchanged.
o Section 11 is extensively modified as discussed below.
o Section 11, exclusive of subsections, is replaced by Sections
4.1 and 4.2 from the current document.
o Section 11.1 is replaced by Section 4.3 from the current
document.
o Sections 11.2, 11.3, 11.3.1, and 11.3.2 are unchanged.
o Section 11.4 is replaced by Section 4.5 from the current
document. For details regarding subsections see below.
o New sections corresponding to Sections 4.5.1 and 4.5.2 from
the current document appear next.
o Section 11.4.1 is replaced by Section 4.5.3
o Section 11.4.2 is replaced by Section 4.5.4
o Section 11.4.3 is replaced by Section 4.5.5
o A new section corresponding to Section 4.5.6 from the
current document appears next.
o Section 11.5 is to be deleted.
o Section 11.6 is unchanged.
o New sections corresponding to Sections 6 and 7 from the current
document appear next.
o Section 11.7 is replaced by Section 8 from the current
document. For details regarding subsections see below.
o Section 11.7.1 is replaced by Section 8.1
Noveck & Lever Expires July 7, 2018 [Page 72]
Internet-Draft nfsv4.1-msns-update January 2018
o Sections 11.7.2, 11.7.2.1, and 11.7.2.2 are deleted.
o Section 11.7.3 is replaced by Section 8.2
o Section 11.7.4 is replaced by Section 8.3
o Sections 11.7.5 and 11.7.5.1 are replaced by Sections 8.4
and 8.4.1 respectively.
o Section 11.7.6 is replaced by Section 8.5
o Section 11.7.7, exclusive of subsections, is replaced by
Section 8.9. Sections 11.7.7.1 and 11.7.72 are unchanged.
o Section 11.7.8 is replaced by Section 8.6
o Section 11.7.9 is replaced by Section 8.7
o Section 11.7.10 is replaced by Section 8.8
o Sections 11.8, 11.8.1, 11.8.2, 11.9, 11.10, 11.10.1, 11.10.2,
11.10.3, and 11.11 are unchanged.
o New sections corresponding to Sections 9, 10, and 11 from the
current document appear next as additional sub-sections of
Section 11. Each of these has subsections, so there is a total
of seventeen sections added.
o Sections 12 through 14 are unchanged.
o Section 15 is unmodified except that the description of
NFS4ERR_MOVED in Section 15.1 is revised as described in
Section 12.3 of the current document.
o Sections 16 and 17 are unchanged.
o Section 18 is unmodified except that section 18.35 is replaced by
Section 13 in the current document.
o Sections 19 through 23 are unchanged.
In terms of top-level sections, exclusive of appendices:
o There is one heavily modified top-level section (Section 11)
o There are four other modified top-level sections (Sections 1, 2,
15, and 18).
Noveck & Lever Expires July 7, 2018 [Page 73]
Internet-Draft nfsv4.1-msns-update January 2018
o The other eighteen top-level sections are unchanged.
The disposition of sections of [RFC5661] is summarized in the
following table which provides counts of sections replaced, added,
deleted, modified, or unchanged. Separate counts are provided for:
o Top-level sections.
o Sections with TOC entries.
o Sections within Section 11.
o Sections outside Section 11.
In this table, the counts for top-level sections and TOC entries are
for sections including subsections while other counts are for
sections exclusive of included subsections.
+------------+------+------+--------+------------+--------+
| Status | Top | TOC | in 11 | not in 11 | Total |
+------------+------+------+--------+------------+--------+
| Replaced | 0 | 3 | 17 | 7 | 24 |
| Added | 0 | 5 | 22 | 0 | 22 |
| Deleted | 0 | 1 | 4 | 0 | 4 |
| Modified | 5 | 4 | 0 | 2 | 2 |
| Unchanged | 18 | 212 | 16 | 918 | 934 |
| in RFC5661 | 23 | 220 | 37 | 927 | 964 |
+------------+------+------+--------+------------+--------+
Acknowledgments
The authors wish to acknowledge the important role of Andy Adamson of
Netapp in clarifying the need for trunking discovery functionality,
and exploring the role of the location attributes in providing the
necessary support.
The authors also wish to acknowledge the work of Xuan Qi of Oracle
with NFSv4.1 client and server prototypes of transparent state
migration functionality.
The authors wish to thank Trond Myklebust of Primary Data for his
comments related to trunking, helping to clarify the role of DNS in
trunking discovery.
The authors wish to thank Olga Kornievskaia of Netapp for her helpful
review comments.
Noveck & Lever Expires July 7, 2018 [Page 74]
Internet-Draft nfsv4.1-msns-update January 2018
Authors' Addresses
David Noveck (editor)
NetApp
1601 Trapelo Road
Waltham, MA 02451
United States of America
Phone: +1 781 572 8038
Email: davenoveck@gmail.com
Charles Lever
Oracle Corporation
1015 Granger Avenue
Ann Arbor, MI 48104
United States of America
Phone: +1 248 614 5091
Email: chuck.lever@oracle.com
Noveck & Lever Expires July 7, 2018 [Page 75]