draft-ietf-nfsv4-rfc3530-migration-update-04.txt   draft-ietf-nfsv4-rfc3530-migration-update-05.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft Internet-Draft Dell
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: September 30, 2014 B. Baker Expires: March 26, 2015 B. Baker
ORACLE ORACLE
March 29, 2014 September 22, 2014
NFSv4.0 migration: Specification Update NFSv4.0 migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-04 draft-ietf-nfsv4-rfc3530-migration-update-05
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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 30, 2014. This Internet-Draft will expire on March 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . 5 4.2. Client Identity Data Items . . . . . . . . . . . . . . . 6
4.3. Server Release of Client ID . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 15 4.7. Mixing Client Id String Approaches . . . . . . . . . . . 15
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 . . . . . . . . . . 22 4.9. Client Id String Construction Details . . . . . . . . . . 22
5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23 5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23
5.1. Changes from Replaced Sections . . . . . . . . . . . . . 23 5.1. Changes from Replaced Sections . . . . . . . . . . . . . 24
5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24 5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24
5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24 5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24
5.3.1. Migration and clientid's . . . . . . . . . . . . . . 26 5.3.1. Migration and Clientid's . . . . . . . . . . . . . . 26
5.3.2. Migration and state owner information . . . . . . . . 27 5.3.2. Migration and State Owner Information . . . . . . . . 27
5.4. Replication and State . . . . . . . . . . . . . . . . . . 31 5.4. Replication and State . . . . . . . . . . . . . . . . . . 31
5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31 5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31
5.6. Migration and the Lease_time Attribute . . . . . . . . . 34 5.6. Migration and the Lease_time Attribute . . . . . . . . . 34
6. Server Implementation Considerations . . . . . . . . . . . . 34 6. Server Implementation Considerations . . . . . . . . . . . . 35
6.1. Relation of Locking State Transfer to Other Aspects of 6.1. Relation of Locking State Transfer to Other Aspects of
Filesystem Motion . . . . . . . . . . . . . . . . . . . . 34 Filesystem Motion . . . . . . . . . . . . . . . . . . . . 35
6.2. Preventing Locking State Modification During Transfer . . 36 6.2. Preventing Locking State Modification During Transfer . . 36
7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39 7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39
7.1. Summary of Additional Changes from Previous Documents . . 39 7.1. Summary of Additional Changes from Previous Documents . . 40
7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40 7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40
7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41 7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41
7.5. Security Considerations revision . . . . . . . . . . . . 45 7.5. Security Considerations for Inter-server Information
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 Transfer . . . . . . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7.6. Security Considerations Revision . . . . . . . . . . . . 46
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . 46 11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 46 11.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 5, line 46 skipping to change at page 6, line 5
some implementation guidance to help implementers choose one or some implementation guidance to help implementers choose one or
the other of these. the other of these.
o It adds a discussion of issues involved for clients in interacting o It adds a discussion of issues involved for clients in interacting
with servers whose behavior is not consistent with use of uniform with servers whose behavior is not consistent with use of uniform
client id strings client id strings
o It adds a description of how server behavior might be used by the o It adds a description of how server behavior might be used by the
client to determine server address trunking patterns. client to determine server address trunking patterns.
4.2. Client Identity data items 4.2. Client Identity Data Items
The NFSv4 protocol contains a number of protocol entities to identify The NFSv4 protocol contains a number of protocol entities to identify
clients and client-based entities, for locking-related purposes: clients and client-based entities, for locking-related purposes:
o The nfs_client_id4 structure which uniquely identifies a specific o The nfs_client_id4 structure which uniquely identifies a specific
client boot instance. That identification is presented to the client boot instance. That identification is presented to the
server by doing a SETCLIENTID operation. server by doing a SETCLIENTID operation.
o The clientid4 which is returned by the server upon completion of a o The clientid4 which is returned by the server upon completion of a
successful SETCLIENTID operation. This id is used by the client successful SETCLIENTID operation. This id is used by the client
skipping to change at page 10, line 5 skipping to change at page 10, line 8
The client must also employ the SETCLIENTID operation when it The client must also employ the SETCLIENTID operation when it
receives a NFS4ERR_STALE_STATEID error using a stateid derived from receives a NFS4ERR_STALE_STATEID error using a stateid derived from
its current clientid4, since this indicates a situation, such as its current clientid4, since this indicates a situation, such as
server reboot which has invalidated the existing clientid4 and server reboot which has invalidated the existing clientid4 and
associated stateids (see the section entitled "lock-owner" for associated stateids (see the section entitled "lock-owner" for
details). details).
See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM
for a complete specification of these operations. for a complete specification of these operations.
4.3. Server Release of Client ID 4.3. Server Release of Client Id
If the server determines that the client holds no associated state If the server determines that the client holds no associated state
for its clientid4, the server may choose to release that clientid4. for its clientid4, the server may choose to release that clientid4.
The server may make this choice for an inactive client so that The server may make this choice for an inactive client so that
resources are not consumed by those intermittently active clients. resources are not consumed by those intermittently active clients.
If the client contacts the server after this release, the server must If the client contacts the server after this release, the server must
ensure the client receives the appropriate error so that it will use ensure the client receives the appropriate error so that it will use
the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new
identity. It should be clear that the server must be very hesitant identity. It should be clear that the server must be very hesitant
to release a client ID since the resulting work on the client to to release a client ID since the resulting work on the client to
skipping to change at page 10, line 40 skipping to change at page 10, line 43
there is no mapping to the previous owner) will in rare cases result there is no mapping to the previous owner) will in rare cases result
in NFS4ERR_CLID_INUSE. in NFS4ERR_CLID_INUSE.
In that event, when the server gets a SETCLIENTID specifying a client In that event, when the server gets a SETCLIENTID specifying a client
id string for which the server has a clientid4 that currently has no id string for which the server has a clientid4 that currently has no
state, or for which it has state, but where the lease has expired, state, or for which it has state, but where the lease has expired,
the server MUST allow the SETCLIENTID, rather than returning the server MUST allow the SETCLIENTID, rather than returning
NFS4ERR_CLID_INUSE. The server MUST then confirm the new client ID NFS4ERR_CLID_INUSE. The server MUST then confirm the new client ID
if followed by the appropriate SETCLIENTID_CONFIRM. if followed by the appropriate SETCLIENTID_CONFIRM.
4.4. client id string Approaches 4.4. Client Id String Approaches
One particular aspect of the construction of the nfs_client_id4 One particular aspect of the construction of the nfs_client_id4
string has proved recurrently troublesome. The client has a choice string has proved recurrently troublesome. The client has a choice
of: of:
o Presenting the same id string to multiple server addresses. This o Presenting the same id string to multiple server addresses. This
is referred to as the "uniform client id string approach" and is is referred to as the "uniform client id string approach" and is
discussed in Section 4.6. discussed in Section 4.6.
o Presenting different id strings to multiple server addresses. o Presenting different id strings to multiple server addresses.
skipping to change at page 12, line 22 skipping to change at page 12, line 26
in their NFSv4.0 client. in their NFSv4.0 client.
Both approaches have to deal with the asymmetry in client and server Both approaches have to deal with the asymmetry in client and server
identity information between client and server. Each seeks to make identity information between client and server. Each seeks to make
the client's and the server's views match. In the process, each the client's and the server's views match. In the process, each
encounters some combination of inelegant protocol features and/or encounters some combination of inelegant protocol features and/or
implementation difficulties. The choice of which to use is up to the implementation difficulties. The choice of which to use is up to the
client implementer and the sections below try to give some useful client implementer and the sections below try to give some useful
guidance. guidance.
4.5. Non-Uniform client id string Approach 4.5. Non-Uniform Client Id String Approach
The non-uniform client id string approach is an attempt to handle The non-uniform client id string approach is an attempt to handle
these matters in NFSv4.0 client implementations in as NFSv3-like a these matters in NFSv4.0 client implementations in as NFSv3-like a
way as possible. way as possible.
For a client using the non-uniform approach, all internal recording For a client using the non-uniform approach, all internal recording
of clientid4 values is to include, whether explicitly or implicitly, of clientid4 values is to include, whether explicitly or implicitly,
the server IP address so that one always has an (IP-address, the server IP address so that one always has an (IP-address,
clientid4) pair. Two such pairs from different servers are always clientid4) pair. Two such pairs from different servers are always
distinct even when the clientid4 values are the same, as they may distinct even when the clientid4 values are the same, as they may
skipping to change at page 13, line 9 skipping to change at page 13, line 16
is more complex in the case of non-uniform client id strings. For is more complex in the case of non-uniform client id strings. For
example, migration of a lease can result in multiple leases for the example, migration of a lease can result in multiple leases for the
same client accessing the same server addresses, vitiating many of same client accessing the same server addresses, vitiating many of
the advantages of this approach. Therefore, client implementations the advantages of this approach. Therefore, client implementations
that support migration with transparent state migration SHOULD NOT that support migration with transparent state migration SHOULD NOT
use the non-uniform client id string approach, except where it is use the non-uniform client id string approach, except where it is
necessary for compatibility with existing server implementations (For necessary for compatibility with existing server implementations (For
details of arranging use of multiple client id string approaches, see details of arranging use of multiple client id string approaches, see
Section 4.7). Section 4.7).
4.6. Uniform client id string Approach 4.6. Uniform Client Id String Approach
When the client id string is kept uniform, the server has the basis When the client id string is kept uniform, the server has the basis
to have a single clientid4/lease for each distinct client. The to have a single clientid4/lease for each distinct client. The
problem that has to be addressed is the lack of explicit server problem that has to be addressed is the lack of explicit server
identity information, which was made available in NFSv4.1. identity information, which was made available in NFSv4.1.
When the same client id string is given to multiple IP addresses, the When the same client id string is given to multiple IP addresses, the
client can determine whether two IP addresses correspond to a single client can determine whether two IP addresses correspond to a single
server, based on the server's behavior. This is the inverse of the server, based on the server's behavior. This is the inverse of the
strategy adopted for the non-uniform approach in which different strategy adopted for the non-uniform approach in which different
skipping to change at page 15, line 5 skipping to change at page 15, line 12
approach, which most client implementations have been following. approach, which most client implementations have been following.
Until substantial implementation experience is obtained with this Until substantial implementation experience is obtained with this
approach, reluctance to embrace something so new is to be approach, reluctance to embrace something so new is to be
expected. expected.
o Mapping between server network addresses and leases is more o Mapping between server network addresses and leases is more
complicated in that it is no longer a one-to-one mapping. complicated in that it is no longer a one-to-one mapping.
How to balance these considerations depends on implementation goals. How to balance these considerations depends on implementation goals.
4.7. Mixing client id string Approaches 4.7. Mixing Client Id String Approaches
As noted above, a client which needs to use the uniform client id As noted above, a client which needs to use the uniform client id
string approach (e.g. to support migration), may also need to support string approach (e.g. to support migration), may also need to support
existing servers with implementations that do not work properly in existing servers with implementations that do not work properly in
this case. this case.
Some examples of such server issues include: Some examples of such server issues include:
o Some existing NFSv4.0 server implementations of IP address o Some existing NFSv4.0 server implementations of IP address
failover depend on clients' use of a non-uniform client id string failover depend on clients' use of a non-uniform client id string
skipping to change at page 16, line 12 skipping to change at page 16, line 20
uniform client id string approach as the default, but allow a mount uniform client id string approach as the default, but allow a mount
option to specify use of the non-uniform client id string approach option to specify use of the non-uniform client id string approach
for particular mount points, as long as such mount points are not for particular mount points, as long as such mount points are not
used when migration is to be supported. used when migration is to be supported.
In the case in which the same server has multiple mounts, and both In the case in which the same server has multiple mounts, and both
approaches are specified for the same server, the client could have approaches are specified for the same server, the client could have
multiple clientid's corresponding to the same server, one for each multiple clientid's corresponding to the same server, one for each
approach and would then have to keep these separate. approach and would then have to keep these separate.
4.8. Trunking Determination when using Uniform client id strings 4.8. Trunking Determination when Using Uniform Client Id Strings
This section provides an example of how trunking determination could This section provides an example of how trunking determination could
be done by a client following the uniform client id string approach be done by a client following the uniform client id string approach
(whether this is used for all mounts or not). Clients need not (whether this is used for all mounts or not). Clients need not
follow this procedure but implementers should make sure that the follow this procedure but implementers should make sure that the
issues dealt with by this procedure are all properly addressed. issues dealt with by this procedure are all properly addressed.
We need to clarify the various possible purposes of trunking We need to clarify the various possible purposes of trunking
determination and the corresponding requirements as to server determination and the corresponding requirements as to server
behavior. The following points should be noted: behavior. The following points should be noted:
skipping to change at page 20, line 7 skipping to change at page 20, line 15
in parallel. in parallel.
There are a number of things that should be noted at this point. There are a number of things that should be noted at this point.
o That the SETCLIENTID operations done on the various IPn addresses o That the SETCLIENTID operations done on the various IPn addresses
in the procedure above will never be confirmed by in the procedure above will never be confirmed by
SETCLIENTID_CONFIRM operations directed to the various IPn SETCLIENTID_CONFIRM operations directed to the various IPn
addresses. If these callback updates are to be confirmed, they addresses. If these callback updates are to be confirmed, they
will be confirmed by SETCLIENTID_CONFIRM operations directed at will be confirmed by SETCLIENTID_CONFIRM operations directed at
the original IP address X, which can only happen if SCn was the original IP address X, which can only happen if SCn was
generated by an IPn which trunked with X, allowing the SETCLIENTID generated by an IPn which was trunked with X, allowing the
to be successfully confirmed, and allowing us to infer the SETCLIENTID to be successfully confirmed, and allowing us to infer
existence of that trunking relationship. the existence of that trunking relationship.
o That the number of successful SETCLIENTID_CONFIRM operations done o That the number of successful SETCLIENTID_CONFIRM operations done
should never be more than one. If both SCn and SCm are accepted should never be more than one. If both SCn and SCm are accepted
by X, then it indicates that both IPn and IPm are trunked with X, by X, then it indicates that both IPn and IPm are trunked with X,
but that is only possible if IPn and IPm are trunked together. but that is only possible if IPn and IPm are trunked together.
Since these two addresses were earlier recognized as not trunked Since these two addresses were earlier recognized as not trunked
together, this should be impossible, if the servers in question together, this should be impossible, if the servers in question
are implemented correctly. are implemented correctly.
Further processing depends on the success or failure of the various Further processing depends on the success or failure of the various
skipping to change at page 22, line 31 skipping to change at page 22, line 41
trunked. trunked.
This choice has a lot of complexity associated with it, and it is This choice has a lot of complexity associated with it, and it is
likely that few implementations will use it. When the set of likely that few implementations will use it. When the set of
locking state on IPn is small (e.g. a single stateid) but not locking state on IPn is small (e.g. a single stateid) but not
empty, most client implementations are likely to either fail the empty, most client implementations are likely to either fail the
MOUNT or implement a more stringent verification procedure using MOUNT or implement a more stringent verification procedure using
the existing stateid on IPn as a basis to generate further state the existing stateid on IPn as a basis to generate further state
as raw material for the trunking verification process. as raw material for the trunking verification process.
4.9. Client id string construction details 4.9. Client Id String Construction Details
This section gives more detailed guidance on client id construction. This section gives more detailed guidance on client id construction.
Note that among the items suggested for inclusion, there are many Note that among the items suggested for inclusion, there are many
that may conceivably change. In order for the client id string to that may conceivably change. In order for the client id string to
remain valid in such circumstances, the client should either: remain valid in such circumstances, the client should either:
o Use a saved copy of such value, rather than the changeable value o Use a saved copy of such value, rather than the changeable value
itself. itself.
o Save the constructed client id string, rather than constructing it o Save the constructed client id string, rather than constructing it
skipping to change at page 26, line 13 skipping to change at page 26, line 23
it normally would in response to a server failure. The new server it normally would in response to a server failure. The new server
must take care to allow for the recovery of state information as it must take care to allow for the recovery of state information as it
would in the event of server restart. would in the event of server restart.
In those situations in which state has not been transferred, as shown In those situations in which state has not been transferred, as shown
by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim
locks in order to take advantage of cases in which the destination locks in order to take advantage of cases in which the destination
server has set up a file-system-specific grace period in support of server has set up a file-system-specific grace period in support of
the migration. the migration.
5.3.1. Migration and clientid's 5.3.1. Migration and Clientid's
Handling of clientid values is similar to that for stateids. Handling of clientid values is similar to that for stateids.
However, there are some differences that derive from the fact that a However, there are some differences that derive from the fact that a
clientid is an object which spans multiple filesystems while a clientid is an object which spans multiple filesystems while a
stateid is inherently limited to a single filesystem. stateid is inherently limited to a single filesystem.
The clientid4 and nfs_client_id4 information (id string and boot The clientid4 and nfs_client_id4 information (id string and boot
verifier) will be transferred with the rest of the state information verifier) will be transferred with the rest of the state information
and the destination server should use that information to determine and the destination server should use that information to determine
appropriate clientid4 handling. Although the destination server may appropriate clientid4 handling. Although the destination server may
skipping to change at page 27, line 20 skipping to change at page 27, line 29
to an inability to recall delegations. The client can determine the to an inability to recall delegations. The client can determine the
new clientid (the value c) from the response to SETCLIENTID. new clientid (the value c) from the response to SETCLIENTID.
The client can use its own information about leases with the The client can use its own information about leases with the
destination server to see if lease merger should have happened. When destination server to see if lease merger should have happened. When
there is any ambiguity, the client MAY use the above procedure to set there is any ambiguity, the client MAY use the above procedure to set
the proper callback information and find out, as part of the process, the proper callback information and find out, as part of the process,
the correct value of its clientid with respect to the server in the correct value of its clientid with respect to the server in
question. question.
5.3.2. Migration and state owner information 5.3.2. Migration and State Owner Information
In addition to stateids, the locks they represent, and clientid In addition to stateids, the locks they represent, and clientid
information, servers also need to transfer information related to the information, servers also need to transfer information related to the
current status of openowners and lockowners. current status of openowners and lockowners.
This information includes: This information includes:
o The sequence number of the last operation associated with the o The sequence number of the last operation associated with the
particular owner. particular owner.
skipping to change at page 42, line 47 skipping to change at page 43, line 22
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.
7.4.5.1. IMPLEMENTATION (preparatory phase) 7.4.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 43, line 36 skipping to change at page 44, line 9
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.
7.4.5.2. IMPLEMENTATION (main phase) 7.4.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 the x, c, l, s }, where l may or may not equal k. If so, and since
id verifier v of the request matches that which is confirmed and the id verifier v of the request matches that which is confirmed
recorded, the server treats this as a probable callback and 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
skipping to change at page 44, line 32 skipping to change at page 45, line 6
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 may o The server has no confirmed { *, x, *, *, * } for x. It may or
not have recorded an unconfirmed { u, x, c, l, s }, where l may or may not have recorded an unconfirmed { u, x, c, l, s }, where l
may not equal k, and u may or may not equal v. Any unconfirmed may or may not equal k, and u may or may not equal v. Any
record { u, x, c, l, * }, regardless whether u == v or l == k, is unconfirmed record { u, x, c, l, * }, regardless whether u == v or
replaced with an unconfirmed record { v, x, d, k, t } where d != l == k, is replaced with an unconfirmed record { v, x, d, k, t }
c, t != s. where d != 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.
7.5. Security Considerations revision 7.5. Security Considerations for Inter-server Information Transfer
Although the means by which the source and destination server
communicate is not specified by NFSv4.0, the following security-
related requirements for inter-server communication should be noted.
o Communication between source and destination servers needs to be
carried out in a secure manner, either on a private network, or
using a security mechanism that ensures privacy.
o Effective implementation of the filesystem migration function
requires that a trust relationship exist between source and
destination servers.
o The source server may communicate to the destination sever
security-related information to be used to make more rigorous the
validation of client's identity. For example, the destination
server might reject a SETCLIENTID done with a different principal
or with a different IP address than was done previously by the
client on the source server. However, the destination server MUST
NOT use this information to allow any operation to be performed by
the client that would not be allowed otherwise.
7.6. 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.
8. Security Considerations 8. Security Considerations
Is modified as specified in Section 7.5. Is to be modified as specified in Section 7.6.
In addition, the material in Section 7.5 should be noted.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. 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 Primary Data and Robert Thurlow
Oracle. We also thank Tom Haynes of NetApp and Spencer Shepler of of Oracle. We also thank Tom Haynes of Primary Data and Spencer
Microsoft for their guidance and suggestions. Shepler of 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.
11. References 11. References
11.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.
11.2. Informative References 11.2. Informative References
skipping to change at page 46, line 28 skipping to change at page 47, line 25
[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", RFC System (NFS) Version 4 Minor Version 1 Protocol", 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", 2014, <http://www.ietf.org/id/ (NFS) Version 4 Protocol", 2014, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-32.txt>. draft-ietf-nfsv4-rfc3530bis-33.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", 2014, <http://www.ietf.org/id/ issues to resolve", 2014, <http://www.ietf.org/id/
draft-ietf-nfsv4-migration-issues-05.txt>. draft-ietf-nfsv4-migration-issues-06.txt>.
Work in progress. Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
26 Locust Avenue Dell
Lexington, MA 02421 300 Innovative Way
Nashua, NH 03062
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: dave_noveck@dell.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
 End of changes. 38 change blocks. 
64 lines changed or deleted 92 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/