draft-ietf-nfsv4-rfc3530-migration-update-01.txt   draft-ietf-nfsv4-rfc3530-migration-update-02.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft EMC Internet-Draft EMC
Updates: 3530 (if approved) P. Shivam Updates: 3530 (if approved) P. Shivam
Intended status: Standards Track C. Lever Intended status: Standards Track C. Lever
Expires: August 19, 2013 B. Baker Expires: February 09, 2014 B. Baker
ORACLE ORACLE
February 15, 2013 August 08, 2013
NFSv4.0 migration: Specification Update NFSv4.0 migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-01 draft-ietf-nfsv4-rfc3530-migration-update-02
Abstract Abstract
The migration feature of NFSv4 allows for responsibility for a single The migration feature of NFSv4 allows for responsibility for a single
filesystem to move from one server to another, without disruption to filesystem to move from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the clients. Recent implementation experience has shown problems in the
existing specification for this feature in NFSv4.0. This document existing specification for this feature in NFSv4.0. This document
clarifies and corrects the NFSv4.0 specification (RFC3530 and clarifies and corrects the NFSv4.0 specification (RFC3530 and
possible successors) to address these problems. possible successors) to address these problems.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2013. This Internet-Draft will expire on February 09, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Identity Definition . . . . . . . . . . . . . . . . . . 5 4. Client Identity Definition . . . . . . . . . . . . . . . . . 5
4.1. Differences from Replaced Sections . . . . . . . . . . . . 5 4.1. Differences from Replaced Sections . . . . . . . . . . . 5
4.2. Client Identity data items . . . . . . . . . . . . . . . . 6 4.2. Client Identity data items . . . . . . . . . . . . . . . 5
4.3. Server Release of Client ID . . . . . . . . . . . . . . . 9 4.3. Server Release of Client ID . . . . . . . . . . . . . . . 10
4.4. client id string Approaches . . . . . . . . . . . . . . . 10 4.4. client id string Approaches . . . . . . . . . . . . . . . 10
4.5. Non-Uniform client id string Approach . . . . . . . . . . 12 4.5. Non-Uniform client id string Approach . . . . . . . . . . 12
4.6. Uniform client id string Approach . . . . . . . . . . . . 13 4.6. Uniform client id string Approach . . . . . . . . . . . . 13
4.7. Mixing client id string Approaches . . . . . . . . . . . . 14 4.7. Mixing client id string Approaches . . . . . . . . . . . 14
4.8. Trunking Determination when using Uniform client id 4.8. Trunking Determination when using Uniform client id
strings . . . . . . . . . . . . . . . . . . . . . . . . . 16 strings . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Client id string construction details . . . . . . . . . . 21 4.9. Client id string construction details . . . . . . . . . . 21
5. Locking and Multi-Server Namespace . . . . . . . . . . . . . . 22 5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 22
5.1. Changes from Replaced Sections . . . . . . . . . . . . . . 22 5.1. Changes from Replaced Sections . . . . . . . . . . . . . 22
5.2. Lock State and Filesystem Transitions . . . . . . . . . . 22 5.2. Lock State and Filesystem Transitions . . . . . . . . . . 23
5.3. Migration and State . . . . . . . . . . . . . . . . . . . 23 5.3. Migration and State . . . . . . . . . . . . . . . . . . . 23
5.3.1. Migration and clientid's . . . . . . . . . . . . . . . 24 5.3.1. Migration and clientid's . . . . . . . . . . . . . . 24
5.3.2. Migration and state owner information . . . . . . . . 25 5.3.2. Migration and state owner information . . . . . . . . 25
5.4. Replication and State . . . . . . . . . . . . . . . . . . 28 5.4. Replication and State . . . . . . . . . . . . . . . . . . 29
5.5. Notification of Migrated Lease . . . . . . . . . . . . . . 29 5.5. Notification of Migrated Lease . . . . . . . . . . . . . 29
5.6. Migration and the Lease_time Attribute . . . . . . . . . . 31 5.6. Migration and the Lease_time Attribute . . . . . . . . . 32
6. Additional Changes . . . . . . . . . . . . . . . . . . . . . . 32 6. Server Implementation Considerations . . . . . . . . . . . . 32
6.1. Summary of Additional Changes from Previous Documents . . 32 6.1. Relation of Locking State Transfer to Other Aspects of
6.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 32 Filesystem Motion . . . . . . . . . . . . . . . . . . . . 32
6.3. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 33 6.2. Preventing Locking State Modification During Transfer . . 34
6.4. Security Considerations revision . . . . . . . . . . . . . 37 7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7.1. Summary of Additional Changes from Previous Documents . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 7.3. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.4. Security Considerations revision . . . . . . . . . . . . 42
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.2. Informative References . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document is a standards track document which corrects the This document is a standards track document which corrects the
existing definitive specification of the NFSv4.0 protocol, in existing definitive specification of the NFSv4.0 protocol, in
[RFC3530] and the one expected to become definitive (now in [RFC3530] and the one expected to become definitive (now in
[cur-rfc3530-bis]). Given this fact, one should take the current [cur-rfc3530-bis]). Given this fact, one should take the current
document into account when learning about NFSv4.0, particularly if document into account when learning about NFSv4.0, particularly if
one is concerned with issues that relate to: one is concerned with issues that relate to:
skipping to change at page 26, line 46 skipping to change at page 27, line 14
If filesystem migration encounters a situation where owner If filesystem migration encounters a situation where owner
information needs to be merged, it MAY decline to transfer such information needs to be merged, it MAY decline to transfer such
state, even if it chooses to handle other cases in which locks for a state, even if it chooses to handle other cases in which locks for a
given owner are spread among multiple filesystems. given owner are spread among multiple filesystems.
As a way of understanding the situations which need to be addressed As a way of understanding the situations which need to be addressed
when owner information needs to be merged, consider the following when owner information needs to be merged, consider the following
scenario: scenario:
o There is client C and two servers X and Y. There are two o There is client C and two servers X and Y. There are two
clientid's designating C, which we refer to as CX and CY. clientid's designating C, which we refer to as CX and CY.
o Initially server X supports filesystems F1, F2, F3, and F4. These o Initially server X supports filesystems F1, F2, F3, and F4. These
will be migrated, one-at-a-time, to server Y. will be migrated, one-at-a-time, to server Y.
o While these migrations are proceeding, the client makes locking o While these migrations are proceeding, the client makes locking
requests for filesystem F1 through F4 on behalf of owner O (either requests for filesystem F1 through F4 on behalf of owner O (either
a lockowner or an openowner), with each request going to X or Y a lockowner or an openowner), with each request going to X or Y
depending on where the relevant filesystem is being supported at depending on where the relevant filesystem is being supported at
the time the request is made. the time the request is made.
skipping to change at page 32, line 23 skipping to change at page 32, line 38
needs to reclaim or re-obtain its locks), the client should fetch the needs to reclaim or re-obtain its locks), the client should fetch the
value of lease_time on the new (i.e., destination) server, and use it value of lease_time on the new (i.e., destination) server, and use it
for subsequent locking requests. However the server must respect a for subsequent locking requests. However the server must respect a
grace period at least as long as the lease_time on the source server, grace period at least as long as the lease_time on the source server,
in order to ensure that clients have ample time to reclaim their in order to ensure that clients have ample time to reclaim their
locks before potentially conflicting non-reclaimed locks are granted. locks before potentially conflicting non-reclaimed locks are granted.
The means by which the new server obtains the value of lease_time on The means by which the new server obtains the value of lease_time on
the old server is left to the server implementations. It is not the old server is left to the server implementations. It is not
specified by the NFS version 4.0 protocol. specified by the NFS version 4.0 protocol.
6. Additional Changes 6. Server Implementation Considerations
This chapter provides suggestions to help server implementers deal
with issues involved in the transparent transfer of filesystem-
related data between servers. Servers are not obliged to follow
these suggestions, but should be sure that their approach to the
issues handle all the potential problems addressed below.
6.1. Relation of Locking State Transfer to Other Aspects of Filesystem
Motion
In many cases, state transfer will be part of a larger function
wherein the contents of a filesystem are transferred from server to
server. Although specifics will vary with the implementation, the
relation between the transfer of persistent file data and metadata
and the transfer of state will typically be described by one of the
cases below.
o In some implementations, access to the on-disk contents of a
filesystem can be transferred from server to server by making the
storage devices on which the filesystem resides physically
accessible from multiple servers, and transferring the right and
responsibility for handling that filesystem from server to server.
In such implementations, the transfer of locking state happens on
its own, as described in Section 6.2. The transfer of physical
access to the file system happens after the locking state is
transferred and before any subsequent access to the filesystem.
In cases where such transfer is not instantaneous, there will be a
period in which all operations on the filesystem are held off,
either by having the operations themselves return NFS4ERR_DELAY,
or, where this is not allowed, by using the techniques described
below in Section 6.2.
o In other implementations, file system data and metadata must be
copied from the server where it has existed to the destination
server. Because of the typical amounts of data involved, it is
generally not practical to hold off access to the filesystem while
this transfer is going on. Normal access to the filesystem,
including modifying operations, will generally happen while the
transfer is going on.
Eventually the filesystem copying process will complete. At this
point, there will be two valid copies of the filesystem, one on
each of the source and destination servers. Servers may maintain
that state of affairs by making sure that each modification to
filesystem data is done on both the source and destination
servers.
Although the transfer of locking state can begin before the above
state of affairs is reached, servers will often wait until it is
arrived at to begin transfer of locking state. Once the transfer
of locking state is completed, as described in the section below,
clients may be notified of the migration event and access the
destination filesystem on the destination server.
o Another case in which file system data and metadata must be copied
from server to server involves a variant of the pattern above. In
cases in which a single filesystem moves between or among a small
set of servers, it will transition to a server on which a previous
instantiation of that same filesystem existed before. In such
cases, it is often more efficient to update the previous
filesystem instance to reflect changes made while the active
filesystem was residing elsewhere, rather than copying the
filesystem data anew.
In such cases, the copying of file system data and metadata is
replaced by a process which validates each visible filesystem
object, copying new objects and updating those that have changed
since the filesystem was last present on the destination server.
Although this process is generally shorter than a complete copy,
it is generally long enough that it is not practical to hold off
access to the filesystem while this update is going on.
Eventually the filesystem updating process will complete. At this
point, there will be two valid copies of the filesystem, one on
each of the source and destination servers. Servers may maintain
that state of affairs just as is done in the previous case.
Similarly, the transfer of locking state, once it is complete,
allows the clients to be notified of the migration event and
access the destination filesystem on the destination server.
6.2. Preventing Locking State Modification During Transfer
When transferring locking state from the source to a destination
server, there will be occasions when the source server will need to
prevent operations that modify the state being transferred. For
example, if the locking state at time T is sent to the destination
server, any state change that occurs on the source server after that
time but before the filesystem transfer is made effective will mean
that the state on the destination server will differ from that on the
source server, which matches what the client would expect to see.
In general, a server can prevent some set of server-maintained data
from changing by returning NFS4ERR_DELAY on operations which attempt
to change that data. In the case of locking state for NFSv4.0, there
are two specific issues that might interfere:
o Returning NFS4ERR_DELAY will not prevent state from changing in
that owner-based sequence values will still change, even though
NFS4ERR_DELAY is returned. For example OPEN and LOCK will change
state (in the form of owner seqid values) even when they return
NFS4ERR_DELAY.
o Some operations which modify locking state are not allowed to
return NFS4ERR_DELAY.
Note that the first problem and many instances of the second can be
addressed by returning NFS4ERR_DELAY on the operations that establish
a filehandle within the target as one of the filehandles associated
with the request, i.e. as either the current or saved filehandle.
This would require returning NFS4ERR_DELAY under the following
circumstances:
o On a PUTFH that specifies a filehandle within the target
filesystem.
o On a LOOKUP or LOOKUPP that crosses into the target filesystem.
Note that if the server establishes and maintains a situation in
which no request has, as either the current or saved filehandle, a
filehandle within the target filesystem, no special handling of
SAVEFH or RESTOREFH is required. Thus the fact that these operations
cannot return NFS4ERR_DELAY is not a problem since neither will
establish a filehandle in the target filesystem as the current
filehandle.
If the server is to establish the situation described above, it may
have to take special note of long-running requests which started
before state migration. Part of any solution to this issue will
involve distinguishing two separate points in time at which handling
for the target filesystem will change. Let us distinguish;
o A time T after which the previously mentioned operations will
return NFS4ERR_DELAY.
o A later time T' at which the server can consider filesystem
locking state fixed, making it possible for it to be sent to the
destination server.
For a server to decide on T', it must ensure that requests started
before T, cannot change target filesystem locking state, given that
all those started after T are dealt with by returning NFS4ERR_DELAY
upon setting filehandles within the target filesystem. Among the
ways of doing this are:
o Keeping track of the earliest request started which is still in
execution (for example, by keeping a list of active requests
ordered by request start time). The server can then define T' to
be the first time at which the earliest-started active request
started after time T.
o Keeping track of the count of requests, started before time T
which have a filehandle within the target filesystem as either the
current or saved filehandle. The server can then define T' to be
the first time after T at which the count is zero.
The set of operations that change locking state include two that
cannot be dealt with by the above approach, because they are not
filesystem-specific and do not use a current filehandle as an
implicit parameter.
o RENEW can be dealt with by applying the renewal to state for non-
transitioning filesystems. The effect of renewal for the
transitioning filesystem can be ignored, as long as the servers
make sure that the lease on the destination server has an
expiration time that is no earlier than the latest renewal done on
the source server. This can be easily accomplished by making the
lease expiration on the destination server equal to the time the
state transfer was completed plus the lease period.
o RELEASE_LOCKOWNER can be handled by propagating the fact of the
lockowner deletion (e.g. by using an RPC) to the destination
server. Such a propagation RPC can be done as part of the
operation or the existence of the deletion can be recorded locally
and propagation of owner deletions to the destination server done
as a batch later. In either case, the actual deletions on the
destination server have to be delayed until all of the other state
information has been transferred.
The approach outlined above prevents all reference to the
transitioning filesystem, rather than limiting the delayed operations
to those that change locking state on the transitioning filesystem.
Because of this, servers may choose to limit the time during which
this broad approach is used by adopting a layered approach to the
issue.
o During the preparatory phase, operations that change, create, or
destroy locks or modify the valid set of stateid's will return
NFS4ERR_DELAY. During this phase, seqids may change. Also,
RELEASE_LOCKOWNER operations may be processed as long as the fact
of the owner deletion is recorded locally for later transmission.
o During the restrictive phase, operations that change locking state
for the filesystem in transition are prevented by returning
NFS4ERR_DELAY on any attempt to make a filehandle within the that
filesystem either the current or saved filehandle for a request.
RELEASE_LOCKOWNER operations may be processed only if the deletion
is communicated immediately to the destination server.
A possible sequence would be the following.
o The server enters the preparatory phase for the transitioning
filesystem.
o At this point locking state, including stateids, locks, owner
strings are transferred to the destination server. The seqids
associated with owners are either not transferred, or transferred
on a provisional basis, subject to later change.
o After the above has been transferred, the server may enter the
restrictive phase for the filesystem.
o At this point, the updated seqid values may be sent to the
destination server.
Reporting regarding pending owner deletions (as a result of
RELEASE_LOCKOWNER operations) can be communicated at the same
time.
o Once it is known that all of this information has been transferred
to the destination server, and there are no pending
RELEASE_LOCKOWNER notifications outstanding, the source server may
treat the filesystem transition as having occurred and return
NFS4ERR_MOVED when an attempt is made to access it.
7. Additional Changes
This chapter contains a number of items which relate to the changes This chapter contains a number of items which relate to the changes
in the chapters above, but which, for one reason or another, exist in in the chapters above, but which, for one reason or another, exist in
different portions of the specification to be updated. different portions of the specification to be updated.
6.1. Summary of Additional Changes from Previous Documents 7.1. Summary of Additional Changes from Previous Documents
We summarize here all the remaining changes, not included in the two We summarize here all the remaining changes, not included in the two
main chapters. main chapters.
o New definition of the CLID_INUSE error. o New definition of the CLID_INUSE error.
o A revised description of SETCLIENTID, which brings the description o A revised description of SETCLIENTID, which brings the description
into sync with the rest of the spec regarding CLID_INUSE. into sync with the rest of the spec regarding CLID_INUSE.
o A revision to the Security Considerations section, indicating why o A revision to the Security Considerations section, indicating why
integrity protection is needed for the SETCLIENTID operation. integrity protection is needed for the SETCLIENTID operation.
6.2. NFS4ERR_CLID_INUSE definition 7.2. NFS4ERR_CLID_INUSE definition
The definition of this error is now as follows The definition of this error is now as follows
The SETCLIENTID operation has found that the id string within the The SETCLIENTID operation has found that the id string within the
specified nfs_client_id4 was previously presented with a different specified nfs_client_id4 was previously presented with a different
principal and that client instance currently holds an active principal and that client instance currently holds an active
lease. A server MAY return this error if the same principal is lease. A server MAY return this error if the same principal is
used but a change in authentication flavor gives good reason to used but a change in authentication flavor gives good reason to
reject the new SETCLIENTID operation as not bona fide. reject the new SETCLIENTID operation as not bona fide.
6.3. Operation 35: SETCLIENTID - Negotiate Client ID 7.3. Operation 35: SETCLIENTID - Negotiate Client ID
6.3.1. SYNOPSIS 7.3.1. SYNOPSIS
client, callback, callback_ident -> clientid, setclientid_confirm client, callback, callback_ident -> clientid, setclientid_confirm
6.3.2. ARGUMENT 7.3.2. ARGUMENT
struct SETCLIENTID4args { struct SETCLIENTID4args {
nfs_client_id4 client; nfs_client_id4 client;
cb_client4 callback; cb_client4 callback;
uint32_t callback_ident; uint32_t callback_ident;
}; };
6.3.3. RESULT 7.3.3. RESULT
struct SETCLIENTID4resok { struct SETCLIENTID4resok {
clientid4 clientid; clientid4 clientid;
verifier4 setclientid_confirm; verifier4 setclientid_confirm;
}; };
union SETCLIENTID4res switch (nfsstat4 status) { union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
SETCLIENTID4resok resok4; SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE: case NFS4ERR_CLID_INUSE:
clientaddr4 client_using; clientaddr4 client_using;
default: default:
void; void;
}; };
6.3.4. DESCRIPTION 7.3.4. DESCRIPTION
The client uses the SETCLIENTID operation to notify the server of its The client uses the SETCLIENTID operation to notify the server of its
intention to use a particular client identifier, callback, and intention to use a particular client identifier, callback, and
callback_ident for subsequent requests that entail creating lock, callback_ident for subsequent requests that entail creating lock,
share reservation, and delegation state on the server. Upon share reservation, and delegation state on the server. Upon
successful completion the server will return a shorthand client ID successful completion the server will return a shorthand client ID
which, if confirmed via a separate step, will be used in subsequent which, if confirmed via a separate step, will be used in subsequent
file locking and file open requests. Confirmation of the client ID file locking and file open requests. Confirmation of the client ID
must be done via the SETCLIENTID_CONFIRM operation to return the must be done via the SETCLIENTID_CONFIRM operation to return the
client ID and setclientid_confirm values, as verifiers, to the client ID and setclientid_confirm values, as verifiers, to the
server. The reason why two verifiers are necessary is that it is server. The reason why two verifiers are necessary is that it is
skipping to change at page 34, line 13 skipping to change at page 39, line 29
The callback information provided in this operation will be used if The callback information provided in this operation will be used if
the client is provided an open delegation at a future point. the client is provided an open delegation at a future point.
Therefore, the client must correctly reflect the program and port Therefore, the client must correctly reflect the program and port
numbers for the callback program at the time SETCLIENTID is used. numbers for the callback program at the time SETCLIENTID is used.
The callback_ident value is used by the server on the callback. The The callback_ident value is used by the server on the callback. The
client can leverage the callback_ident to eliminate the need for more client can leverage the callback_ident to eliminate the need for more
than one callback RPC program number, while still being able to than one callback RPC program number, while still being able to
determine which server is initiating the callback. determine which server is initiating the callback.
6.3.5. IMPLEMENTATION 7.3.5. IMPLEMENTATION
To understand how to implement SETCLIENTID, make the following To understand how to implement SETCLIENTID, make the following
notations. Let: notations. Let:
x be the value of the client.id subfield of the SETCLIENTID4args x be the value of the client.id subfield of the SETCLIENTID4args
structure. structure.
v be the value of the client.verifier subfield of the v be the value of the client.verifier subfield of the
SETCLIENTID4args structure. SETCLIENTID4args structure.
skipping to change at page 34, line 38 skipping to change at page 40, line 10
callback_ident fields of the SETCLIENTID4args structure. callback_ident fields of the SETCLIENTID4args structure.
s be the setclientid_confirm value returned in the SETCLIENTID4resok s be the setclientid_confirm value returned in the SETCLIENTID4resok
structure. structure.
{ v, x, c, k, s } be a quintuple for a client record. A client { v, x, c, k, s } be a quintuple for a client record. A client
record is confirmed if there has been a SETCLIENTID_CONFIRM record is confirmed if there has been a SETCLIENTID_CONFIRM
operation to confirm it. Otherwise it is unconfirmed. An operation to confirm it. Otherwise it is unconfirmed. An
unconfirmed record is established by a SETCLIENTID call. unconfirmed record is established by a SETCLIENTID call.
6.3.5.1. IMPLEMENTATION (preparatory phase) 7.3.5.1. IMPLEMENTATION (preparatory phase)
Since SETCLIENTID is a non-idempotent operation, let us assume that Since SETCLIENTID is a non-idempotent operation, let us assume that
the server is implementing the duplicate request cache (DRC). the server is implementing the duplicate request cache (DRC).
When the server gets a SETCLIENTID { v, x, k } request, it first does When the server gets a SETCLIENTID { v, x, k } request, it first does
a number of preliminary checks as listed below before proceeding to a number of preliminary checks as listed below before proceeding to
the main part of SETCLIENTID processing. the main part of SETCLIENTID processing.
o It first looks up the request in the DRC. If there is a hit, it o It first looks up the request in the DRC. If there is a hit, it
returns the result cached in the DRC. The server does NOT remove returns the result cached in the DRC. The server does NOT remove
skipping to change at page 35, line 27 skipping to change at page 40, line 46
o Otherwise, the server is being asked to do a SETCLIENTID for a o Otherwise, the server is being asked to do a SETCLIENTID for a
client by a non-matching principal while there is active state and client by a non-matching principal while there is active state and
the server rejects the SETCLIENTID request returning an the server rejects the SETCLIENTID request returning an
NFS4ERR_CLID_INUSE error, since use of a single client with NFS4ERR_CLID_INUSE error, since use of a single client with
multiple principals is not allowed. Note that even though the multiple principals is not allowed. Note that even though the
previously used clientaddr is returned with this error, the use of previously used clientaddr is returned with this error, the use of
the same id string with multiple clientaddr's is not prohibited, the same id string with multiple clientaddr's is not prohibited,
while its use with multiple principals is prohibited. while its use with multiple principals is prohibited.
6.3.5.2. IMPLEMENTATION (main phase) 7.3.5.2. IMPLEMENTATION (main phase)
If the SETCLIENTID has not been dealt with by DRC processing, and has If the SETCLIENTID has not been dealt with by DRC processing, and has
not been rejected with an NFS4ERR_CLID_INUSE error, then the main not been rejected with an NFS4ERR_CLID_INUSE error, then the main
part of SETCLIENTID processing proceeds, as described below. part of SETCLIENTID processing proceeds, as described below.
o The server checks if it has recorded a confirmed record for { v, o The server checks if it has recorded a confirmed record for { v,
x, c, l, s }, where l may or may not equal k. If so, and since x, c, l, s }, where l may or may not equal k. If so, and since the
the id verifier v of the request matches that which is confirmed id verifier v of the request matches that which is confirmed and
and recorded, the server treats this as a probable callback recorded, the server treats this as a probable callback
information update and records an unconfirmed { v, x, c, k, t } information update and records an unconfirmed { v, x, c, k, t }
and leaves the confirmed { v, x, c, l, s } in place, such that t and leaves the confirmed { v, x, c, l, s } in place, such that t
!= s. It does not matter if k equals l or not. Any pre-existing != s. It does not matter if k equals l or not. Any pre-existing
unconfirmed { v, x, c, *, * } is removed. unconfirmed { v, x, c, *, * } is removed.
The server returns { c, t }. It is indeed returning the old The server returns { c, t }. It is indeed returning the old
clientid4 value c, because the client apparently only wants to clientid4 value c, because the client apparently only wants to
update callback value k to value l. It's possible this request is update callback value k to value l. It's possible this request is
one from the Byzantine router that has stale callback information, one from the Byzantine router that has stale callback information,
but this is not a problem. The callback information update is but this is not a problem. The callback information update is
only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }. only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }.
The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t
}. }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
skipping to change at page 36, line 23 skipping to change at page 41, line 44
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM
{ d, t }. { d, t }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
for x. for x.
o The server has previously recorded a confirmed { u, x, c, l, s } o The server has previously recorded a confirmed { u, x, c, l, s }
record such that v != u, l may or may not equal k, and recorded an record such that v != u, l may or may not equal k, and recorded an
unconfirmed { w, x, d, m, t } record such that c != d, t != s, m unconfirmed { w, x, d, m, t } record such that c != d, t != s, m
may or may not equal k, m may or may not equal l, and k may or may may or may not equal k, m may or may not equal l, and k may or may
not equal l. Whether w == v or w != v makes no difference. The not equal l. Whether w == v or w != v makes no difference. The
server simply removes the unconfirmed { w, x, d, m, t } record and server simply removes the unconfirmed { w, x, d, m, t } record and
replaces it with an unconfirmed { v, x, e, k, r } record, such replaces it with an unconfirmed { v, x, e, k, r } record, such
that e != d, e != c, r != t, r != s. that e != d, e != c, r != t, r != s.
The server returns { e, r }. The server returns { e, r }.
The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM
{ e, r }. { e, r }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
for x. for x.
o The server has no confirmed { *, x, *, *, * } for x. It may or o The server has no confirmed { *, x, *, *, * } for x. It may or may
may not have recorded an unconfirmed { u, x, c, l, s }, where l not have recorded an unconfirmed { u, x, c, l, s }, where l may or
may or may not equal k, and u may or may not equal v. Any may not equal k, and u may or may not equal v. Any unconfirmed
unconfirmed record { u, x, c, l, * }, regardless whether u == v or record { u, x, c, l, * }, regardless whether u == v or l == k, is
l == k, is replaced with an unconfirmed record { v, x, d, k, t } replaced with an unconfirmed record { v, x, d, k, t } where d !=
where d != c, t != s. c, t != s.
The server returns { d, t }. The server returns { d, t }.
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM
{ d, t }. The server does NOT remove client (lock/share/ { d, t }. The server does NOT remove client (lock/share/
delegation) state for x. delegation) state for x.
The server generates the clientid and setclientid_confirm values and The server generates the clientid and setclientid_confirm values and
must take care to ensure that these values are extremely unlikely to must take care to ensure that these values are extremely unlikely to
ever be regenerated. ever be regenerated.
6.4. Security Considerations revision 7.4. Security Considerations revision
The last paragraph of the "Security Considerations" section should be The last paragraph of the "Security Considerations" section should be
revised to read as follows: revised to read as follows:
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and the principal used for these operations is checked against and
match the previous use of these operations. In addition, use of match the previous use of these operations. In addition, use of
integrity protection is desirable on the SETCLIENTID operation, to integrity protection is desirable on the SETCLIENTID operation, to
prevent an attack whereby a change in the boot verifier forces an prevent an attack whereby a change in the boot verifier forces an
undesired loss of client state. See the section "Client Identity undesired loss of client state. See the section "Client Identity
Definition" for further discussion. Definition" for further discussion.
7. Security Considerations 8. Security Considerations
Is modified as specified in Section 6.4. Is modified as specified in Section 7.4.
8. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Acknowledgements 10. Acknowledgements
The editor and authors of this document gratefully acknowledge the The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of NetApp and Robert Thurlow of contributions of Trond Myklebust of NetApp and Robert Thurlow of
Oracle. We also thank Tom Haynes of NetApp and Spencer Shepler of Oracle. We also thank Tom Haynes of NetApp and Spencer Shepler of
Microsoft for their guidance and suggestions. Microsoft for their guidance and suggestions.
Special thanks go to members of the Oracle Solaris NFS team, Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues an NFSv4.0 migration prototype and identifying many of the issues
addressed here. addressed here.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
10.2. Informative References 11.2. Informative References
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol", RFC
RFC 5661, January 2010. 5661, January 2010.
[cur-rfc3530-bis] [cur-rfc3530-bis]
Haynes, T., Ed. and D. Noveck, Ed., "Network File System Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", 2013, <http://www.ietf.org/id/ (NFS) Version 4 Protocol", 2013, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-24.txt>. draft-ietf-nfsv4-rfc3530bis-26.txt>.
Work in progress. Work in progress.
[info-migr] [info-migr]
Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4 migration: Implementation experience and spec "NFSv4 migration: Implementation experience and spec
issues to resolve", 2012, <http://www.ietf.org/id/ issues to resolve ", 2012, <http://www.ietf.org/id/draft-
draft-ietf-nfsv4-migration-issues-02.txt>. ietf-nfsv4-migration-issues-03.txt>.
Work in progress. Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
EMC Corporation EMC Corporation
228 South Street 228 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US US
Phone: +1 508 249 5748 Phone: +1 508 249 5748
Email: david.noveck@emc.com Email: david.noveck@emc.com
Piyush Shivam Piyush Shivam
skipping to change at page 39, line 4 skipping to change at page 44, line 21
Email: david.noveck@emc.com Email: david.noveck@emc.com
Piyush Shivam Piyush Shivam
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1019 Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com Email: piyush.shivam@oracle.com
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
US US
Phone: +1 248 614 5091 Phone: +1 734 274 2396
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
Bill Baker Bill Baker
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1081 Phone: +1 512 401 1081
Email: bill.baker@oracle.com Email: bill.baker@oracle.com
 End of changes. 39 change blocks. 
80 lines changed or deleted 310 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/