draft-ietf-nfsv4-minorversion1-29.txt   draft-ietf-nfsv4-minorversion1-PAv1.txt 
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: June 18, 2009 Editors Expires: October 7, 2009 Editors
December 15, 2008 April 05, 2009
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-29.txt draft-ietf-nfsv4-minorversion1-PAv1.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2009. This Internet-Draft will expire on October 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 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. to this document.
Abstract Abstract
skipping to change at page 9, line 49 skipping to change at page 9, line 49
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 481 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 481
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 482 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 482
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 486 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 486
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate 18.34. Operation 41: BIND_CONN_TO_SESSION - Associate
Connection with Session . . . . . . . . . . . . . . . . 488 Connection with Session . . . . . . . . . . . . . . . . 488
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 491 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 491
18.36. Operation 43: CREATE_SESSION - Create New Session and 18.36. Operation 43: CREATE_SESSION - Create New Session and
Confirm Client ID . . . . . . . . . . . . . . . . . . . 509 Confirm Client ID . . . . . . . . . . . . . . . . . . . 509
18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 519 18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 519
18.38. Operation 45: FREE_STATEID - Free Stateid with No 18.38. Operation 45: FREE_STATEID - Free Stateid with No
Locks . . . . . . . . . . . . . . . . . . . . . . . . . 520 Locks . . . . . . . . . . . . . . . . . . . . . . . . . 521
18.39. Operation 46: GET_DIR_DELEGATION - Get a directory 18.39. Operation 46: GET_DIR_DELEGATION - Get a directory
delegation . . . . . . . . . . . . . . . . . . . . . . . 521 delegation . . . . . . . . . . . . . . . . . . . . . . . 521
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 525 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 525
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 527 for a File System . . . . . . . . . . . . . . . . . . . 528
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using 18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using
a Layout . . . . . . . . . . . . . . . . . . . . . . . . 529 a Layout . . . . . . . . . . . . . . . . . . . . . . . . 529
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 532 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 533
18.44. Operation 51: LAYOUTRETURN - Release Layout 18.44. Operation 51: LAYOUTRETURN - Release Layout
Information . . . . . . . . . . . . . . . . . . . . . . 542 Information . . . . . . . . . . . . . . . . . . . . . . 543
18.45. Operation 52: SECINFO_NO_NAME - Get Security on 18.45. Operation 52: SECINFO_NO_NAME - Get Security on
Unnamed Object . . . . . . . . . . . . . . . . . . . . . 546 Unnamed Object . . . . . . . . . . . . . . . . . . . . . 547
18.46. Operation 53: SEQUENCE - Supply Per-Procedure 18.46. Operation 53: SEQUENCE - Supply Per-Procedure
Sequencing and Control . . . . . . . . . . . . . . . . . 547 Sequencing and Control . . . . . . . . . . . . . . . . . 548
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 553 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 554
18.48. Operation 55: TEST_STATEID - Test Stateids for 18.48. Operation 55: TEST_STATEID - Test Stateids for
Validity . . . . . . . . . . . . . . . . . . . . . . . . 555 Validity . . . . . . . . . . . . . . . . . . . . . . . . 556
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 557 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 558
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 561 18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 562
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims
Finished . . . . . . . . . . . . . . . . . . . . . . . . 561 Finished . . . . . . . . . . . . . . . . . . . . . . . . 562
18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 564 18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 565
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 564 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 565
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 565 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 566
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 565 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 566
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 569 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 570
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 569 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 570
20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 570 20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 571
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from
Client . . . . . . . . . . . . . . . . . . . . . . . . . 571 Client . . . . . . . . . . . . . . . . . . . . . . . . . 572
20.4. Operation 6: CB_NOTIFY - Notify Client of Directory 20.4. Operation 6: CB_NOTIFY - Notify Client of Directory
Changes . . . . . . . . . . . . . . . . . . . . . . . . 575 Changes . . . . . . . . . . . . . . . . . . . . . . . . 576
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously 20.5. Operation 7: CB_PUSH_DELEG - Offer Previously
Requested Delegation to Client . . . . . . . . . . . . . 579 Requested Delegation to Client . . . . . . . . . . . . . 580
20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable 20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable
Objects . . . . . . . . . . . . . . . . . . . . . . . . 580 Objects . . . . . . . . . . . . . . . . . . . . . . . . 581
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal
Resources for Recallable Objects . . . . . . . . . . . . 583 Resources for Recallable Objects . . . . . . . . . . . . 584
20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control 20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 584 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 585
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel 20.9. Operation 11: CB_SEQUENCE - Supply Backchannel
Sequencing and Control . . . . . . . . . . . . . . . . . 585 Sequencing and Control . . . . . . . . . . . . . . . . . 586
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending
Delegation Wants . . . . . . . . . . . . . . . . . . . . 587 Delegation Wants . . . . . . . . . . . . . . . . . . . . 588
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of 20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of
Possible Lock Availability . . . . . . . . . . . . . . . 588 Possible Lock Availability . . . . . . . . . . . . . . . 589
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of
Device ID Changes . . . . . . . . . . . . . . . . . . . 590 Device ID Changes . . . . . . . . . . . . . . . . . . . 591
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . . . 592 Operation . . . . . . . . . . . . . . . . . . . . . . . 593
21. Security Considerations . . . . . . . . . . . . . . . . . . . 592 21. Security Considerations . . . . . . . . . . . . . . . . . . . 593
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 594 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 595
22.1. Named Attribute Definitions . . . . . . . . . . . . . . 594 22.1. Named Attribute Definitions . . . . . . . . . . . . . . 595
22.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 595 22.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 596
22.1.2. Updating Registrations . . . . . . . . . . . . . . . 595 22.1.2. Updating Registrations . . . . . . . . . . . . . . . 596
22.2. Device ID Notifications . . . . . . . . . . . . . . . . 595 22.2. Device ID Notifications . . . . . . . . . . . . . . . . 596
22.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 596 22.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 597
22.2.2. Updating Registrations . . . . . . . . . . . . . . . 596 22.2.2. Updating Registrations . . . . . . . . . . . . . . . 598
22.3. Object Recall Types . . . . . . . . . . . . . . . . . . 596 22.3. Object Recall Types . . . . . . . . . . . . . . . . . . 598
22.3.1. Initial Registry . . . . . . . . . . . . . . . . . . 598 22.3.1. Initial Registry . . . . . . . . . . . . . . . . . . 599
22.3.2. Updating Registrations . . . . . . . . . . . . . . . 598 22.3.2. Updating Registrations . . . . . . . . . . . . . . . 599
22.4. Layout Types . . . . . . . . . . . . . . . . . . . . . . 598 22.4. Layout Types . . . . . . . . . . . . . . . . . . . . . . 599
22.4.1. Initial Registry . . . . . . . . . . . . . . . . . . 599 22.4.1. Initial Registry . . . . . . . . . . . . . . . . . . 600
22.4.2. Updating Registrations . . . . . . . . . . . . . . . 599 22.4.2. Updating Registrations . . . . . . . . . . . . . . . 601
22.4.3. Guidelines for Writing Layout Type Specifications . 599 22.4.3. Guidelines for Writing Layout Type Specifications . 601
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 601 22.5. Path Variable Definitions . . . . . . . . . . . . . . . 602
22.5.1. Path Variables Registry . . . . . . . . . . . . . . 601 22.5.1. Path Variables Registry . . . . . . . . . . . . . . 602
22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 603 22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 604
22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 603 22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 605
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 604 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 606
23.1. Normative References . . . . . . . . . . . . . . . . . . 604 23.1. Normative References . . . . . . . . . . . . . . . . . . 606
23.2. Informative References . . . . . . . . . . . . . . . . . 607 23.2. Informative References . . . . . . . . . . . . . . . . . 608
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 608 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 610
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 611 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 612
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 611 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 613
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 1 Protocol 1.1. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0 is described in [29]. It generally follows the version, NFSv4.0 is described in [29]. It generally follows the
guidelines for minor versioning model listed in Section 10 of RFC guidelines for minor versioning model listed in Section 10 of RFC
3530. However, it diverges from guidelines 11 ("a client and server 3530. However, it diverges from guidelines 11 ("a client and server
skipping to change at page 25, line 12 skipping to change at page 25, line 12
of facilities exist to pass results from one operation to another. of facilities exist to pass results from one operation to another.
Once an operation returns a failing result, the evaluation ends and Once an operation returns a failing result, the evaluation ends and
the results of all evaluated operations are returned to the client. the results of all evaluated operations are returned to the client.
With the use of the COMPOUND procedure, the client is able to build With the use of the COMPOUND procedure, the client is able to build
simple or complex requests. These COMPOUND requests allow for a simple or complex requests. These COMPOUND requests allow for a
reduction in the number of RPCs needed for logical file system reduction in the number of RPCs needed for logical file system
operations. For example, multi-component lookup requests can be operations. For example, multi-component lookup requests can be
constructed by combining multiple LOOKUP operations. Those can be constructed by combining multiple LOOKUP operations. Those can be
further combined with operations such as GETATTR, READDIR, or OPEN further combined with operations such as GETATTR, READDIR, or OPEN
plus READ to do more complicated sets of operation without incurring plus READ to do more complicated sets of operations without incurring
additional latency. additional latency.
NFSv4.1 also contains a considerable set of callback operations in NFSv4.1 also contains a considerable set of callback operations in
which the server makes an RPC directed at the client. Callback RPCs which the server makes an RPC directed at the client. Callback RPCs
have a similar structure to that of the normal server requests. In have a similar structure to that of the normal server requests. In
all minor versions of the NFSv4 protocol there are two callback RPC all minor versions of the NFSv4 protocol there are two callback RPC
procedures, CB_NULL and CB_COMPOUND. The CB_COMPOUND procedure is procedures, CB_NULL and CB_COMPOUND. The CB_COMPOUND procedure is
defined in an analogous fashion to that of COMPOUND with its own set defined in an analogous fashion to that of COMPOUND with its own set
of callback operations. of callback operations.
skipping to change at page 29, line 37 skipping to change at page 29, line 37
2.4.2. Server Release of Client ID 2.4.2. Server Release of Client ID
NFSv4.1 introduces a new operation called DESTROY_CLIENTID NFSv4.1 introduces a new operation called DESTROY_CLIENTID
(Section 18.50) which the client SHOULD use to destroy a client ID it (Section 18.50) which the client SHOULD use to destroy a client ID it
no longer needs. This permits graceful, bilateral release of a no longer needs. This permits graceful, bilateral release of a
client ID. The operation cannot be used if there are sessions client ID. The operation cannot be used if there are sessions
associated with the client ID, or state with an unexpired lease. associated with the client ID, or state with an unexpired lease.
If the server determines that the client holds no associated state If the server determines that the client holds no associated state
for its client ID (including sessions, opens, locks, delegations, for its client ID (associated state includes unrevoked sessions,
layouts, and wants), the server may choose to unilaterally release opens, locks, delegations, layouts, and wants), the server MAY choose
the client ID in order to conserve resources. If the client contacts to unilaterally release the client ID in order to conserve resources.
the server after this release, the server MUST ensure the client If the client contacts the server after this release, the server MUST
receives the appropriate error so that it will use the EXCHANGE_ID/ ensure the client receives the appropriate error so that it will use
CREATE_SESSION sequence to establish a new client ID. The server the EXCHANGE_ID/CREATE_SESSION sequence to establish a new client ID.
ought to be very hesitant to release a client ID since the resulting The server ought to be very hesitant to release a client ID since the
work on the client to recover from such an event will be the same resulting work on the client to recover from such an event will be
burden as if the server had failed and restarted. Typically a server the same burden as if the server had failed and restarted. Typically
would not release a client ID unless there had been no activity from a server would not release a client ID unless there had been no
that client for many minutes. As long as there are sessions, opens, activity from that client for many minutes. As long as there are
locks, delegations, layouts, or wants, the server MUST NOT release sessions, opens, locks, delegations, layouts, or wants, the server
the client ID. See Section 2.10.12.1.4 for discussion on releasing MUST NOT release the client ID. See Section 2.10.12.1.4 for a
inactive sessions. discussion on releasing inactive sessions.
2.4.3. Resolving Client Owner Conflicts 2.4.3. Resolving Client Owner Conflicts
When the server gets an EXCHANGE_ID for a client owner that currently When the server gets an EXCHANGE_ID for a client owner that currently
has no state, or that has state, but the lease has expired, the has no state, or that has state, but the lease has expired, the
server MUST allow the EXCHANGE_ID, and confirm the new client ID if server MUST allow the EXCHANGE_ID, and confirm the new client ID if
followed by the appropriate CREATE_SESSION. followed by the appropriate CREATE_SESSION.
When the server gets an EXCHANGE_ID for a new incarnation of a client When the server gets an EXCHANGE_ID for a new incarnation of a client
owner that currently has an old incarnation with state and an owner that currently has an old incarnation with state and an
skipping to change at page 36, line 20 skipping to change at page 36, line 20
Section 2.6.3.1.1.5), neither PUTFH nor SECINFO_NO_NAME can return Section 2.6.3.1.1.5), neither PUTFH nor SECINFO_NO_NAME can return
NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.1.7), READ cannot NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.1.7), READ cannot
return NFS4ERR_WRONGSEC. The issue is resolved by the fact that return NFS4ERR_WRONGSEC. The issue is resolved by the fact that
SECINFO and SECINFO_NO_NAME consume the current filehandle (note that SECINFO and SECINFO_NO_NAME consume the current filehandle (note that
this is a change from NFSv4.0). This leaves no current filehandle this is a change from NFSv4.0). This leaves no current filehandle
for READ to use, and READ returns NFS4ERR_NOFILEHANDLE. for READ to use, and READ returns NFS4ERR_NOFILEHANDLE.
2.6.3.1.2. LINK and RENAME 2.6.3.1.2. LINK and RENAME
The LINK and RENAME operations use both the current and saved The LINK and RENAME operations use both the current and saved
filehandles. When the current filehandle is injected into a series filehandles. Technically, the server MAY return NFS4ERR_WRONGSEC
of operations via a put filehandle operation, the server MUST return from LINK or RENAME if the security policy of the saved filehandle
NFS4ERR_WRONGSEC, per Section 2.6.3.1.1. LINK and RENAME MAY return
NFS4ERR_WRONGSEC if the security policy of the saved filehandle
rejects the security flavor used in the COMPOUND request's rejects the security flavor used in the COMPOUND request's
credentials. If the server does so, then if there is no intersection credentials. However, if the server does so, and if there is no
between the security policies of saved and current filehandles, this intersection between the security policies of saved and current
means it will be impossible for client to perform the intended LINK filehandles, this means it will be impossible for the client to
or RENAME operation. perform the intended LINK or RENAME operation.
For example, suppose the client sends this COMPOUND request: For example, suppose the client sends this COMPOUND request:
SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", where SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", where
filehandles bFH and aFH refer to different directories. Suppose no filehandles bFH and aFH refer to different directories. Suppose no
common security tuple exists between the security policies of aFH and common security tuple exists between the security policies of aFH and
bFH. If the client sends the request using credentials acceptable to bFH. If the client sends the request using credentials acceptable to
bFH's security policy but not aFH's policy, then the PUTFH aFH bFH's security policy but not aFH's policy, then the PUTFH aFH
operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME
request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH,
RENAME "c" "d", using credentials acceptable to aFH's security RENAME "c" "d", using credentials acceptable to aFH's security
policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on
the RENAME operation. the RENAME operation.
To prevent a client from an endless sequence of a request containing To prevent a client from starting endless cycle of a request
LINK or RENAME, followed by a request containing SECINFO_NO_NAME, the containing LINK or RENAME, followed by a request containing
server MUST detect when the security policies of the current and SECINFO_NO_NAME or SECINFO, the server MUST detect when the security
saved filehandles have no mutually acceptable security tuple, and policies of the current and saved filehandles have no mutually
MUST NOT return NFS4ERR_WRONGSEC in that situation. Instead the acceptable security tuple, and MUST NOT return NFS4ERR_WRONGSEC from
server MUST return NFS4ERR_XDEV. LINK or RENAME in that situation. Instead the server MUST do one of
two things:
Thus while a server MAY return NFS4ERR_WRONGSEC from LINK and RENAME, o The server can return NFS4ERR_XDEV.
the server implementor may reasonably decide the consequences are not
worth the security benefits, and so allow the security policy of the o The server can allow the security policy of the current filehandle
current filehandle to override that of the saved filehandle. to override that of the saved filehandle, and so return NFS4_OK.
2.7. Minor Versioning 2.7. Minor Versioning
To address the requirement of an NFS protocol that can evolve as the To address the requirement of an NFS protocol that can evolve as the
need arises, the NFSv4.1 protocol contains the rules and framework to need arises, the NFSv4.1 protocol contains the rules and framework to
allow for future minor changes or versioning. allow for future minor changes or versioning.
The base assumption with respect to minor versioning is that any The base assumption with respect to minor versioning is that any
future accepted minor version will be documented in one or more future accepted minor version will be documented in one or more
standards track RFCs. Minor version zero of the NFSv4 protocol is standards track RFCs. Minor version zero of the NFSv4 protocol is
skipping to change at page 38, line 40 skipping to change at page 38, line 40
"slot" in a future minor version. "slot" in a future minor version.
6. Minor versions must not delete attributes. 6. Minor versions must not delete attributes.
7. Minor versions must not delete flag bits or enumeration values. 7. Minor versions must not delete flag bits or enumeration values.
8. Minor versions may declare an operation MUST NOT be implemented. 8. Minor versions may declare an operation MUST NOT be implemented.
Specifying an operation MUST NOT be implemented is equivalent to Specifying an operation MUST NOT be implemented is equivalent to
obsoleting an operation. For the client, it means that the obsoleting an operation. For the client, it means that the
operation should not be sent to the server. For the server, an operation MUST NOT be sent to the server. For the server, an
NFS error can be returned as opposed to "dropping" the request NFS error can be returned as opposed to "dropping" the request
as an XDR decode error. This approach allows for the as an XDR decode error. This approach allows for the
obsolescence of an operation while maintaining its structure so obsolescence of an operation while maintaining its structure so
that a future minor version can reintroduce the operation. that a future minor version can reintroduce the operation.
1. Minor versions may declare an attribute MUST NOT be 1. Minor versions may declare an attribute MUST NOT be
implemented. implemented.
2. Minor versions may declare a flag bit or enumeration value 2. Minor versions may declare a flag bit or enumeration value
MUST NOT be implemented. MUST NOT be implemented.
9. Minor versions may downgrade features from REQUIRED to 9. Minor versions may downgrade features from REQUIRED to
RECOMMENDED, or RECOMMENDED to OPTIONAL. RECOMMENDED, or RECOMMENDED to OPTIONAL.
10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED 10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED
or RECOMMENDED to REQUIRED. or RECOMMENDED to REQUIRED.
11. A client and server that supports minor version X should support 11. A client and server that supports minor version X SHOULD support
minor versions 0 (zero) through X-1 as well. minor versions 0 (zero) through X-1 as well.
12. Except for infrastructural changes, a minor version must not 12. Except for infrastructural changes, a minor version must not
introduce REQUIRED new features. introduce REQUIRED new features.
This rule allows for the introduction of new functionality and This rule allows for the introduction of new functionality and
forces the use of implementation experience before designating a forces the use of implementation experience before designating a
feature as REQUIRED. On the other hand, some classes of feature as REQUIRED. On the other hand, some classes of
features are infrastructural and have broad effects. Allowing features are infrastructural and have broad effects. Allowing
infrastructural features to be RECOMMENDED or OPTIONAL infrastructural features to be RECOMMENDED or OPTIONAL
skipping to change at page 41, line 45 skipping to change at page 41, line 45
full network address (e.g. if using an IP-based transport, the source full network address (e.g. if using an IP-based transport, the source
port of the requester is part of the full network address) that the port of the requester is part of the full network address) that the
requester sent the request from. If using a connection-oriented requester sent the request from. If using a connection-oriented
transport, replies MUST be sent on the same connection the request transport, replies MUST be sent on the same connection the request
was received from. was received from.
If a connection is dropped after the replier receives the request but If a connection is dropped after the replier receives the request but
before the replier sends the reply, the replier might have an pending before the replier sends the reply, the replier might have an pending
reply. If a connection is established with the same source and reply. If a connection is established with the same source and
destination full network address as the dropped connection, then the destination full network address as the dropped connection, then the
replier MUST NOT send the reply until the client retries the request. replier MUST NOT send the reply until the requester retries the
The reason for this prohibition is that the client MAY retry a request. The reason for this prohibition is that the requester MAY
request over a different connection than is associated with the retry a request over a different connection that is associated with
session. the session.
When using RDMA transports there are other reasons for not tolerating When using RDMA transports there are other reasons for not tolerating
retries over the same connection: retries over the same connection:
o RDMA transports use "credits" to enforce flow control, where a o RDMA transports use "credits" to enforce flow control, where a
credit is a right to a peer to transmit a message. If one peer credit is a right to a peer to transmit a message. If one peer
were to retransmit a request (or reply), it would consume an were to retransmit a request (or reply), it would consume an
additional credit. If the replier retransmitted a reply, it would additional credit. If the replier retransmitted a reply, it would
certainly result in an RDMA connection loss, since the requester certainly result in an RDMA connection loss, since the requester
would typically only post a single receive buffer for each would typically only post a single receive buffer for each
skipping to change at page 43, line 28 skipping to change at page 43, line 28
parallelism. parallelism.
o The NFSv4.1 client (defined in Section 1.5, Paragraph 2) creates o The NFSv4.1 client (defined in Section 1.5, Paragraph 2) creates
transport connections and provides them to the server to use for transport connections and provides them to the server to use for
sending callback requests, thus solving the firewall issue sending callback requests, thus solving the firewall issue
(Section 18.34). Races between responses from client requests, (Section 18.34). Races between responses from client requests,
and callbacks caused by the requests are detected via the and callbacks caused by the requests are detected via the
session's sequencing properties which are a consequence of EOS session's sequencing properties which are a consequence of EOS
(Section 2.10.6.3). (Section 2.10.6.3).
o The NFSv4.1 client can add an arbitrary number of connections to o The NFSv4.1 client can associate an arbitrary number of
the session, and thus provide trunking (Section 2.10.5). connections with the session, and thus provide trunking
(Section 2.10.5).
o The NFSv4.1 client and server produces a session key independent o The NFSv4.1 client and server produces a session key independent
of client and server machine credentials which can be used to of client and server machine credentials which can be used to
compute a digest for protecting critical session management compute a digest for protecting critical session management
operations (Section 2.10.8.3). operations (Section 2.10.8.3).
o The NFSv4.1 client can also create secure RPCSEC_GSS contexts for o The NFSv4.1 client can also create secure RPCSEC_GSS contexts for
use by the session's backchannel that do not require the server to use by the session's backchannel that do not require the server to
authenticate to a client machine principal (Section 2.10.8.2). authenticate to a client machine principal (Section 2.10.8.2).
skipping to change at page 46, line 5 skipping to change at page 46, line 7
always has a fore channel. always has a fore channel.
The backchannel used for callback requests from server to client, and The backchannel used for callback requests from server to client, and
carries CB_COMPOUND requests and responses. Whether there is a carries CB_COMPOUND requests and responses. Whether there is a
backchannel or not is a decision by the client, however many features backchannel or not is a decision by the client, however many features
of NFSv4.1 require a backchannel. NFSv4.1 servers MUST support of NFSv4.1 require a backchannel. NFSv4.1 servers MUST support
backchannels. backchannels.
Each session has resources for each channel, including separate reply Each session has resources for each channel, including separate reply
caches (see Section 2.10.6.1). Note that even the backchannel caches (see Section 2.10.6.1). Note that even the backchannel
requires a reply cache because some callback operations are requires a reply cache (or at least, a slot table in order to detect
nonidempotent. retries) because some callback operations are nonidempotent.
2.10.3.1. Association of Connections, Channels, and Sessions 2.10.3.1. Association of Connections, Channels, and Sessions
Each channel is associated with zero or more transport connections Each channel is associated with zero or more transport connections
(whether of the same transport protocol or different transport (whether of the same transport protocol or different transport
protocols). A connection can be associated with one channel or both protocols). A connection can be associated with one channel or both
channels of a session; the client and server negotiate whether a channels of a session; the client and server negotiate whether a
connection will carry traffic for one channel or both channels via connection will carry traffic for one channel or both channels via
the CREATE_SESSION (Section 18.36) and the BIND_CONN_TO_SESSION the CREATE_SESSION (Section 18.36) and the BIND_CONN_TO_SESSION
(Section 18.34) operations. When a session is created via (Section 18.34) operations. When a session is created via
skipping to change at page 54, line 49 skipping to change at page 54, line 49
the request sent with that sequence ID. The sequence ID is a 32 bit the request sent with that sequence ID. The sequence ID is a 32 bit
unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 - unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 -
1). The first time a slot is used, the requester MUST specify a 1). The first time a slot is used, the requester MUST specify a
sequence ID of one (1) (Section 18.36). Each time a slot is reused, sequence ID of one (1) (Section 18.36). Each time a slot is reused,
the request MUST specify a sequence ID that is one greater than that the request MUST specify a sequence ID that is one greater than that
of the previous request on the slot. If the previous sequence ID was of the previous request on the slot. If the previous sequence ID was
0xFFFFFFFF, then the next request for the slot MUST have the sequence 0xFFFFFFFF, then the next request for the slot MUST have the sequence
ID set to zero (i.e. (2^32 - 1) + 1 mod 2^32). ID set to zero (i.e. (2^32 - 1) + 1 mod 2^32).
The sequence ID accompanies the slot ID in each request. It is for The sequence ID accompanies the slot ID in each request. It is for
the critical check at the server: it used to efficiently determine the critical check at the replier: it used to efficiently determine
whether a request using a certain slot ID is a retransmit or a new, whether a request using a certain slot ID is a retransmit or a new,
never-before-seen request. It is not feasible for the client to never-before-seen request. It is not feasible for the requester to
assert that it is retransmitting to implement this, because for any assert that it is retransmitting to implement this, because for any
given request the client cannot know whether the server has seen it given request the requester cannot know whether the replier has seen
unless the server actually replies. Of course, if the client has it unless the replier actually replies. Of course, if the requester
seen the server's reply, the client would not retransmit. has seen the reply, the requester would not retransmit.
The replier compares each received request's sequence ID with the The replier compares each received request's sequence ID with the
last one previously received for that slot ID, to see if the new last one previously received for that slot ID, to see if the new
request is: request is:
o A new request, in which the sequence ID is one greater than that o A new request, in which the sequence ID is one greater than that
previously seen in the slot (accounting for sequence wraparound). previously seen in the slot (accounting for sequence wraparound).
The replier proceeds to execute the new request, and the replier The replier proceeds to execute the new request, and the replier
MUST increase the slot's sequence ID by one. MUST increase the slot's sequence ID by one.
skipping to change at page 56, line 36 skipping to change at page 56, line 36
so, the embedded slot ID, sequence ID, and session ID (if present) so, the embedded slot ID, sequence ID, and session ID (if present)
in the request will not be in the reply, and the requester has in the request will not be in the reply, and the requester has
only the XID to match the reply to the request. only the XID to match the reply to the request.
Given that well formulated XIDs continue to be required, this begs Given that well formulated XIDs continue to be required, this begs
the question why SEQUENCE and CB_SEQUENCE replies have a session ID, the question why SEQUENCE and CB_SEQUENCE replies have a session ID,
slot ID and sequence ID? Having the session ID in the reply means slot ID and sequence ID? Having the session ID in the reply means
the requester does not have to use the XID to lookup the session ID, the requester does not have to use the XID to lookup the session ID,
which would be necessary if the connection were associated with which would be necessary if the connection were associated with
multiple sessions. Having the slot ID and sequence ID in the reply multiple sessions. Having the slot ID and sequence ID in the reply
means requester does not have to use the XID to lookup the slot ID means the requester does not have to use the XID to lookup the slot
and sequence ID. Furthermore, since the XID is only 32 bits, it is ID and sequence ID. Furthermore, since the XID is only 32 bits, it
too small to guarantee the re-association of a reply with its request is too small to guarantee the re-association of a reply with its
([36]); having session ID, slot ID, and sequence ID in the reply request ([36]); having session ID, slot ID, and sequence ID in the
allows the client to validate that the reply in fact belongs to the reply allows the client to validate that the reply in fact belongs to
matched request. the matched request.
The SEQUENCE (and CB_SEQUENCE) operation also carries a The SEQUENCE (and CB_SEQUENCE) operation also carries a
"highest_slotid" value which carries additional requester slot usage "highest_slotid" value which carries additional requester slot usage
information. The requester MUST always indicate the slot ID information. The requester MUST always indicate the slot ID
representing the outstanding request with the highest-numbered slot representing the outstanding request with the highest-numbered slot
value. The requester should in all cases provide the most value. The requester should in all cases provide the most
conservative value possible, although it can be increased somewhat conservative value possible, although it can be increased somewhat
above the actual instantaneous usage to maintain some minimum or above the actual instantaneous usage to maintain some minimum or
optimal level. This provides a way for the requester to yield unused optimal level. This provides a way for the requester to yield unused
request slots back to the replier, which in turn can use the request slots back to the replier, which in turn can use the
skipping to change at page 57, line 27 skipping to change at page 57, line 27
However, because of request pipelining, the requester may have However, because of request pipelining, the requester may have
active requests in flight reflecting prior values, therefore the active requests in flight reflecting prior values, therefore the
replier must not immediately require the requester to comply. replier must not immediately require the requester to comply.
o The enforced highest_slotid indicates the highest slot ID the o The enforced highest_slotid indicates the highest slot ID the
requester is permitted to use on a subsequent SEQUENCE or requester is permitted to use on a subsequent SEQUENCE or
CB_SEQUENCE operation. The replier's enforced highest_slotid CB_SEQUENCE operation. The replier's enforced highest_slotid
SHOULD be no less than the highest_slotid the requester indicated SHOULD be no less than the highest_slotid the requester indicated
in the SEQUENCE or CB_SEQUENCE arguments. in the SEQUENCE or CB_SEQUENCE arguments.
If a replier detects the client is being intransigent, i.e. it If a replier detects the requester is being intransigent, i.e. it
fails in a series of requests to honor the target highest_slotid fails in a series of requests to honor the target highest_slotid
even though the replier knows there are no outstanding requests a even though the replier knows there are no outstanding requests
higher slot ids, it MAY take more forceful action. When faced with higher slot ids, it MAY take more forceful action. When
with intransigence, the replier MAY reply with a new enforced faced with intransigence, the replier MAY reply with a new
highest_slotid that is less than its previous enforced enforced highest_slotid that is less than its previous enforced
highest_slotid. Thereafter, if the requester continues to send highest_slotid. Thereafter, if the requester continues to send
requests with a highest_slotid that is greater than the replier's requests with a highest_slotid that is greater than the replier's
new enforced highest_slotid the server MAY return new enforced highest_slotid the server MAY return
NFS4ERR_BAD_HIGHSLOT, unless the slot ID in the request is greater NFS4ERR_BAD_HIGHSLOT, unless the slot ID in the request is greater
than the new enforced highest_slotid, and the request is a retry. than the new enforced highest_slotid, and the request is a retry.
The replier SHOULD retain the slots it wants to retire until the The replier SHOULD retain the slots it wants to retire until the
requester sends a request with a highest_slotid less than or equal requester sends a request with a highest_slotid less than or equal
to the replier's new enforced highest_slotid. Also if a request to the replier's new enforced highest_slotid. Also if a request
is received with a slot that is higher than the new enforced is received with a slot that is higher than the new enforced
highest_slotid, and the sequence ID is one higher than what is in highest_slotid, and the sequence ID is one higher than what is in
the slot's reply cache, then the server can both retire the slot the slot's reply cache, then the server can both retire the slot
and return NFS4ERR_BADSLOT (however the server MUST NOT do one and and return NFS4ERR_BADSLOT (however the server MUST NOT do one and
not the other). (The reason it is safe to retire the slot is not the other). (The reason it is safe to retire the slot is
because that by using the next sequence ID, the client is because that by using the next sequence ID, the requester is
indicating it has received the previous reply for the slot.) Once indicating it has received the previous reply for the slot.) Once
the replier has forcibly lowered the enforced highest_slotid, the the replier has forcibly lowered the enforced highest_slotid, the
requester is only allowed to send retries to the to-be-retired requester is only allowed to send retries to the to-be-retired
slots. slots.
o The requester SHOULD use the lowest available slot when issuing a o The requester SHOULD use the lowest available slot when issuing a
new request. This way, the replier may be able to retire slot new request. This way, the replier may be able to retire slot
entries faster. However, where the replier is actively adjusting entries faster. However, where the replier is actively adjusting
its granted highest_slotid, it will not be able to use only the its granted highest_slotid, it will not be able to use only the
receipt of the slot ID and highest_slotid in the request. Neither receipt of the slot ID and highest_slotid in the request. Neither
skipping to change at page 59, line 50 skipping to change at page 59, line 50
retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP. retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP.
2.10.6.2. Retry and Replay of Reply 2.10.6.2. Retry and Replay of Reply
A requester MUST NOT retry a request, unless the connection it used A requester MUST NOT retry a request, unless the connection it used
to send the request disconnects. The requester can then reconnect to send the request disconnects. The requester can then reconnect
and re-send the request, or it can re-send the request over a and re-send the request, or it can re-send the request over a
different connection that is associated with the same session. different connection that is associated with the same session.
If the requester is a server wanting to re-send a callback operation If the requester is a server wanting to re-send a callback operation
over the backchannel of session, the requester of course cannot over the backchannel of a session, the requester of course cannot
reconnect because only the client can associate connections with the reconnect because only the client can associate connections with the
backchannel. The server can re-send the request over another backchannel. The server can re-send the request over another
connection that is bound to the same session's backchannel. If there connection that is bound to the same session's backchannel. If there
is no such connection, the server MUST indicate that the session has is no such connection, the server MUST indicate that the session has
no backchannel by setting the SEQ4_STATUS_CB_PATH_DOWN_SESSION flag no backchannel by setting the SEQ4_STATUS_CB_PATH_DOWN_SESSION flag
bit in the response to the next SEQUENCE operation from the client. bit in the response to the next SEQUENCE operation from the client.
The client MUST then associate a connection with the session (or The client MUST then associate a connection with the session (or
destroy the session). destroy the session).
Note that it is not fatal for a client to retry without a disconnect Note that it is not fatal for a requester to retry without a
between the request and retry. However the retry does consume disconnect between the request and retry. However the retry does
resources, especially with RDMA, where each request, retry or not, consume resources, especially with RDMA, where each request, retry or
consumes a credit. Retries for no reason, especially retries sent not, consumes a credit. Retries for no reason, especially retries
shortly after the previous attempt, are a poor use of network sent shortly after the previous attempt, are a poor use of network
bandwidth and defeat the purpose of a transport's inherent congestion bandwidth and defeat the purpose of a transport's inherent congestion
control system. control system.
A requester MUST wait for a reply to a request before using the slot A requester MUST wait for a reply to a request before using the slot
for another request. If it does not wait for a reply, then the for another request. If it does not wait for a reply, then the
requester does not know what sequence ID to use for the slot on its requester does not know what sequence ID to use for the slot on its
next request. For example, suppose a requester sends a request with next request. For example, suppose a requester sends a request with
sequence ID 1, and does not wait for the response. The next time it sequence ID 1, and does not wait for the response. The next time it
uses the slot, it sends the new request with sequence ID 2. If the uses the slot, it sends the new request with sequence ID 2. If the
replier has not seen the request with sequence ID 1, then the replier replier has not seen the request with sequence ID 1, then the replier
skipping to change at page 61, line 10 skipping to change at page 61, line 10
It is possible for server callbacks to arrive at the client before It is possible for server callbacks to arrive at the client before
the reply from related fore channel operations. For example, a the reply from related fore channel operations. For example, a
client may have been granted a delegation to a file it has opened, client may have been granted a delegation to a file it has opened,
but the reply to the OPEN (informing the client of the granting of but the reply to the OPEN (informing the client of the granting of
the delegation) may be delayed in the network. If a conflicting the delegation) may be delayed in the network. If a conflicting
operation arrives at the server, it will recall the delegation using operation arrives at the server, it will recall the delegation using
the backchannel, which may be on a different transport connection, the backchannel, which may be on a different transport connection,
perhaps even a different network, or even a different session perhaps even a different network, or even a different session
associated with the same client ID associated with the same client ID
The presence of a session between client and server alleviates this The presence of a session between the client and server alleviates
issue. When a session is in place, each client request is uniquely this issue. When a session is in place, each client request is
identified by its { session ID, slot ID, sequence ID } triple. By uniquely identified by its { session ID, slot ID, sequence ID }
the rules under which slot entries (reply cache entries) are retired, triple. By the rules under which slot entries (reply cache entries)
the server has knowledge whether the client has "seen" each of the are retired, the server has knowledge whether the client has "seen"
server's replies. The server can therefore provide sufficient each of the server's replies. The server can therefore provide
information to the client to allow it to disambiguate between an sufficient information to the client to allow it to disambiguate
erroneous or conflicting callback race condition. between an erroneous or conflicting callback race condition.
For each client operation which might result in some sort of server For each client operation which might result in some sort of server
callback, the server SHOULD "remember" the { session ID, slot ID, callback, the server SHOULD "remember" the { session ID, slot ID,
sequence ID } triple of the client request until the slot ID sequence ID } triple of the client request until the slot ID
retirement rules allow the server to determine that the client has, retirement rules allow the server to determine that the client has,
in fact, seen the server's reply. Until the time the { session ID, in fact, seen the server's reply. Until the time the { session ID,
slot ID, sequence ID } request triple can be retired, any recalls of slot ID, sequence ID } request triple can be retired, any recalls of
the associated object MUST carry an array of these referring the associated object MUST carry an array of these referring
identifiers (in the CB_SEQUENCE operation's arguments), for the identifiers (in the CB_SEQUENCE operation's arguments), for the
benefit of the client. After this time, it is not necessary for the benefit of the client. After this time, it is not necessary for the
skipping to change at page 71, line 13 skipping to change at page 71, line 13
operation or before the second CREATE_SESSION operation on a operation or before the second CREATE_SESSION operation on a
client ID. If it does not, the SSV mechanism will not generate client ID. If it does not, the SSV mechanism will not generate
tokens (Section 2.10.9). A client SHOULD send SET_SSV as soon as tokens (Section 2.10.9). A client SHOULD send SET_SSV as soon as
a session is created. a session is created.
o A SET_SSV request does not replace the SSV with the argument to o A SET_SSV request does not replace the SSV with the argument to
SET_SSV. Instead, the current SSV on the server is logically SET_SSV. Instead, the current SSV on the server is logically
exclusive ORed (XORed) with the argument to SET_SSV. Each time a exclusive ORed (XORed) with the argument to SET_SSV. Each time a
new principal uses a client ID for the first time, the client new principal uses a client ID for the first time, the client
SHOULD send a SET_SSV with that principal's RPCSEC_GSS SHOULD send a SET_SSV with that principal's RPCSEC_GSS
credentials, with RPCSEC_GSS service set to RPC_GSS_SVC_PRIVACY. credentials, with the RPCSEC_GSS service set to
RPC_GSS_SVC_PRIVACY.
Here are the types of attacks that can be attempted by an attacker Here are the types of attacks that can be attempted by an attacker
named Eve on a victim named Bob, and how SP4_SSV protection foils named Eve on a victim named Bob, and how SP4_SSV protection foils
each attack: each attack:
o Suppose Eve is the first user to log into a legitimate client. o Suppose Eve is the first user to log into a legitimate client.
Eve's use of an NFSv4.1 file system will cause the legitimate Eve's use of an NFSv4.1 file system will cause the legitimate
client to create a client ID with SP4_SSV protection, specifying client to create a client ID with SP4_SSV protection, specifying
that the BIND_CONN_TO_SESSION operation MUST use the SSV that the BIND_CONN_TO_SESSION operation MUST use the SSV
credential. Eve's use of the file system also causes an SSV to be credential. Eve's use of the file system also causes an SSV to be
skipping to change at page 77, line 18 skipping to change at page 77, line 18
or a total encoding of 16 bytes. The total number of XDR encoded or a total encoding of 16 bytes. The total number of XDR encoded
bytes is thus 8 + 4 + 20 + 16 = 48. bytes is thus 8 + 4 + 20 + 16 = 48.
GSS_Wrap() emits a token that is an XDR encoding of a value of data GSS_Wrap() emits a token that is an XDR encoding of a value of data
type ssv_seal_cipher_tkn4. Note that regardless whether the caller type ssv_seal_cipher_tkn4. Note that regardless whether the caller
of GSS_Wrap() requests confidentiality or not, the token always has of GSS_Wrap() requests confidentiality or not, the token always has
confidentiality. This is because the SSV mechanism is for confidentiality. This is because the SSV mechanism is for
RPCSEC_GSS, and RPCSEC_GSS never produces GSS_wrap() tokens without RPCSEC_GSS, and RPCSEC_GSS never produces GSS_wrap() tokens without
confidentiality. confidentiality.
There is one SSV per client ID. Effectively there is a single GSS There is one SSV per client ID. There is a single GSS context for a
context for a client ID / SSV pair. All SSV mechanism RPCSEC_GSS client ID / SSV pair. All SSV mechanism RPCSEC_GSS handles of a
handles of a client ID / SSV pair share the same GSS context. SSV client ID / SSV pair share the same GSS context. SSV GSS contexts do
GSS contexts do not expire except when the SSV is destroyed (causes not expire except when the SSV is destroyed (causes would include the
would include the client ID being destroyed or a server restart). client ID being destroyed or a server restart). Since one purpose of
Since one purpose of context expiration is to replace keys that have context expiration is to replace keys that have been in use for "too
been in use for "too long" hence vulnerable to compromise by brute long" hence vulnerable to compromise by brute force or accident, the
force or accident, the client can replace the SSV key by sending client can replace the SSV key by sending periodic SET_SSV
periodic SET_SSV operations, by cycling through different users' operations, by cycling through different users' RPCSEC_GSS
RPCSEC_GSS credentials. This way the SSV is replaced without credentials. This way the SSV is replaced without destroying the
destroying the SSV's GSS contexts. SSV's GSS contexts.
SSV RPCSEC_GSS handles can be expired or deleted by the server at any SSV RPCSEC_GSS handles can be expired or deleted by the server at any
time and the EXCHANGE_ID operation can be used to create more SSV time and the EXCHANGE_ID operation can be used to create more SSV
RPCSEC_GSS handles. Expiration of SSV RPCSEC_GSS handles does not RPCSEC_GSS handles. Expiration of SSV RPCSEC_GSS handles does not
imply that the SSV or its GSS context have expired. imply that the SSV or its GSS context have expired.
The client MUST establish an SSV via SET_SSV before the SSV GSS The client MUST establish an SSV via SET_SSV before the SSV GSS
context can be used to emit tokens from GSS_Wrap() and GSS_GetMIC(). context can be used to emit tokens from GSS_Wrap() and GSS_GetMIC().
If SET_SSV has not been successfully called, attempts to emit tokens If SET_SSV has not been successfully called, attempts to emit tokens
MUST fail. MUST fail.
skipping to change at page 78, line 13 skipping to change at page 78, line 13
resources vanish, the server takes action as specified in resources vanish, the server takes action as specified in
Section 2.10.12.2. Section 2.10.12.2.
2.10.10.2. Obligations of the Client 2.10.10.2. Obligations of the Client
The client SHOULD honor the following obligations in order to utilize The client SHOULD honor the following obligations in order to utilize
the session: the session:
o Keep a necessary session from going idle on the server. A client o Keep a necessary session from going idle on the server. A client
that requires a session, but nonetheless is not sending operations that requires a session, but nonetheless is not sending operations
risks having the session be destroyed by the server. This is risks having the server destroy the session. This is because
because sessions consume resources, and resource limitations may sessions consume resources, and resource limitations may force the
force the server to cull an inactive session. A server MAY server to cull an inactive session. A server MAY consider a
consider a session to be inactive if the client has not used the session to be inactive if the client has not used the session
session before the session inactivity timer (Section 2.10.11) has before the session inactivity timer (Section 2.10.11) has expired.
expired.
o Destroy the session when not needed. If a client has multiple o Destroy the session when not needed. If a client has multiple
sessions, one of which has no requests waiting for replies, and sessions, one of which has no requests waiting for replies, and
has been idle for some period of time, it SHOULD destroy the has been idle for some period of time, it SHOULD destroy the
session. session.
o Maintain GSS contexts for the backchannel. If the client requires o Maintain GSS contexts for the backchannel. If the client requires
the server to use the RPCSEC_GSS security flavor for callbacks, the server to use the RPCSEC_GSS security flavor for callbacks,
then it needs to be sure the contexts handed to the server via then it needs to be sure the contexts handed to the server via
BACKCHANNEL_CTL are unexpired. BACKCHANNEL_CTL are unexpired.
skipping to change at page 79, line 6 skipping to change at page 79, line 5
to establish a client ID. If it opts for SP4_MACH_CRED or SP4_SSV to establish a client ID. If it opts for SP4_MACH_CRED or SP4_SSV
protection, in the spo_must_enforce list of operations, it SHOULD at protection, in the spo_must_enforce list of operations, it SHOULD at
minimum specify: CREATE_SESSION, DESTROY_SESSION, minimum specify: CREATE_SESSION, DESTROY_SESSION,
BIND_CONN_TO_SESSION, BACKCHANNEL_CTL, and DESTROY_CLIENTID. If opts BIND_CONN_TO_SESSION, BACKCHANNEL_CTL, and DESTROY_CLIENTID. If opts
for SP4_SSV protection, the client needs to ask for SSV-based for SP4_SSV protection, the client needs to ask for SSV-based
RPCSEC_GSS handles. RPCSEC_GSS handles.
The client uses the client ID to send a CREATE_SESSION on a The client uses the client ID to send a CREATE_SESSION on a
connection to the server. The results of CREATE_SESSION indicate connection to the server. The results of CREATE_SESSION indicate
whether the server will persist the session reply cache through a whether the server will persist the session reply cache through a
server restarted or not, and the client notes this for future server restart or not, and the client notes this for future
reference. reference.
If the client specified SP4_SSV state protection when the client ID If the client specified SP4_SSV state protection when the client ID
was created, then it SHOULD send SET_SSV in the first COMPOUND after was created, then it SHOULD send SET_SSV in the first COMPOUND after
the session is created. Each time a new principal goes to use the the session is created. Each time a new principal goes to use the
client ID, it SHOULD send a SET_SSV again. client ID, it SHOULD send a SET_SSV again.
If the client wants to use delegations, layouts, directory If the client wants to use delegations, layouts, directory
notifications, or any other state that requires a backchannel, then notifications, or any other state that requires a backchannel, then
it needs to add a connection to the backchannel if CREATE_SESSION did it needs to add a connection to the backchannel if CREATE_SESSION did
skipping to change at page 82, line 49 skipping to change at page 82, line 49
returned to processes that were using the server. If the client returned to processes that were using the server. If the client
is using a "mount" paradigm, unmounting the server is advised. is using a "mount" paradigm, unmounting the server is advised.
If there is a reconfiguration event which results in the same network If there is a reconfiguration event which results in the same network
address being assigned to servers where the eir_server_scope value is address being assigned to servers where the eir_server_scope value is
different, it cannot be guaranteed that a session ID generated by the different, it cannot be guaranteed that a session ID generated by the
first will be recognized as invalid by the first. Therefore, in first will be recognized as invalid by the first. Therefore, in
managing server reconfigurations among servers with different server managing server reconfigurations among servers with different server
scope values, it is necessary to make sure that all clients have scope values, it is necessary to make sure that all clients have
disconnected from the first server before effecting the disconnected from the first server before effecting the
reconfiguration. Nonetheless, clients should not assume that servers reconfiguration. Nonetheless, clients cannot assume that servers
will always adhere to this requirement; clients MUST be prepared to will always adhere to this requirement; clients MUST be prepared to
deal with unexpected effects of server reconfigurations. Even where deal with unexpected effects of server reconfigurations. Even where
a session ID is inappropriately recognized as valid, it is likely a session ID is inappropriately recognized as valid, it is likely
that either the connection will not be recognized as valid, or that a that either the connection will not be recognized as valid, or that a
sequence value for a slot will not be correct. Therefore, when a sequence value for a slot will not be correct. Therefore, when a
client receives results indicating such unexpected errors, the use of client receives results indicating such unexpected errors, the use of
EXCHANGE_ID to determine the current server configuration and present EXCHANGE_ID to determine the current server configuration is
the client to the server is RECOMMENDED. RECOMMENDED.
A variation on the above is that after a server's network address A variation on the above is that after a server's network address
moves, there is no NFSv4.1 server listening. E.g. no listener on moves, there is no NFSv4.1 server listening. E.g. no listener on
port 2049, the NFSv4 server returns NFS4ERR_MINOR_VERS_MISMATCH, the port 2049, the NFSv4 server returns NFS4ERR_MINOR_VERS_MISMATCH, the
NFS server returns a PROG_MISMATCH error, the RPC listener on 2049 NFS server returns a PROG_MISMATCH error, the RPC listener on 2049
returns PROG_MISMATCH, or attempts to re-connect to the network returns PROG_MISMATCH, or attempts to re-connect to the network
address timeout. These SHOULD be treated as equivalent to SEQUENCE address timeout. These SHOULD be treated as equivalent to SEQUENCE
returning NFS4ERR_BADSESSION for these purposes. returning NFS4ERR_BADSESSION for these purposes.
When the client detects session loss, it needs to call CREATE_SESSION When the client detects session loss, it needs to call CREATE_SESSION
skipping to change at page 161, line 31 skipping to change at page 161, line 31
client ID and filehandle, and so, if it is used where current client ID and filehandle, and so, if it is used where current
filehandle does not match that associated with the current stateid, filehandle does not match that associated with the current stateid,
the operation to which the stateid is passed will return the operation to which the stateid is passed will return
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
8.2.4. Stateid Lifetime and Validation 8.2.4. Stateid Lifetime and Validation
Stateids must remain valid until either a client restart or a server Stateids must remain valid until either a client restart or a server
restart or until the client returns all of the locks associated with restart or until the client returns all of the locks associated with
the stateid by means of an operation such as CLOSE or DELEGRETURN. the stateid by means of an operation such as CLOSE or DELEGRETURN.
If the locks are lost due to revocation the stateid remains a valid If the locks are lost due to revocation, as long as the client ID is
designation of that revoked state until the client frees it by using valid, the stateid remains a valid designation of that revoked state
FREE_STATEID. Stateids associated with byte-range locks are an until the client frees it by using FREE_STATEID. Stateids associated
exception. They remain valid even if a LOCKU frees all remaining with byte-range locks are an exception. They remain valid even if a
locks, so long as the open file with which they are associated LOCKU frees all remaining locks, so long as the open file with which
remains open, unless the client does a FREE_STATEID to cause the they are associated remains open, unless the client does a
stateid to be freed. FREE_STATEID to cause the stateid to be freed.
It should be noted that there are situations in which the client's It should be noted that there are situations in which the client's
locks become invalid, without the client requesting they be returned. locks become invalid, without the client requesting they be returned.
These include lease expiration and a number of forms of lock These include lease expiration and a number of forms of lock
revocation within the lease period. It is important to note that in revocation within the lease period. It is important to note that in
these situations, the stateid remains valid and the client can use it these situations, the stateid remains valid and the client can use it
to determine the disposition of the associated lost locks. to determine the disposition of the associated lost locks.
An "other" value must never be reused for a different purpose (i.e. An "other" value must never be reused for a different purpose (i.e.
different filehandle, owner, or type of locks) within the context of different filehandle, owner, or type of locks) within the context of
skipping to change at page 174, line 50 skipping to change at page 174, line 50
When the server chooses to free all of a client's lock state, either When the server chooses to free all of a client's lock state, either
immediately upon lease expiration, or a result of the first attempt immediately upon lease expiration, or a result of the first attempt
to obtain a conflicting a lock, the server may report the loss of to obtain a conflicting a lock, the server may report the loss of
lock state in a number of ways. lock state in a number of ways.
The server may choose to invalidate the session and the associated The server may choose to invalidate the session and the associated
client ID. In this case, once the client can communicate with the client ID. In this case, once the client can communicate with the
server, it will receive an NFS4ERR_BADSESSION error. Upon attempting server, it will receive an NFS4ERR_BADSESSION error. Upon attempting
to create a new session, it would get an NFS4ERR_STALE_CLIENTID. to create a new session, it would get an NFS4ERR_STALE_CLIENTID.
Upon creating the new client ID and new session it would attempt to Upon creating the new client ID and new session the client will
reclaim locks not be allowed to do so by the server. attempt to reclaim locks. Normally, the server will not allow the
client to reclaim locks, because the server will not be in its
recovery grace period.
Another possibility is for the server to maintain the session and Another possibility is for the server to maintain the session and
client ID but for all stateids held by the client to become invalid client ID but for all stateids held by the client to become invalid
or stale. Once the client can reach the server after such a network or stale. Once the client can reach the server after such a network
partition, the status returned by the SEQUENCE operation will partition, the status returned by the SEQUENCE operation will
indicate a loss of locking state, i.e. the flag indicate a loss of locking state, i.e. the flag
SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED will be set in sr_status_flags. SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED will be set in sr_status_flags.
In addition, all I/O submitted by the client with the now invalid In addition, all I/O submitted by the client with the now invalid
stateids will fail with the server returning the error stateids will fail with the server returning the error
NFS4ERR_EXPIRED. Once the client learns of the loss of locking NFS4ERR_EXPIRED. Once the client learns of the loss of locking
skipping to change at page 177, line 17 skipping to change at page 177, line 20
either always assumes after it restarts that some edge condition either always assumes after it restarts that some edge condition
occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or
that the server record some information in stable storage. The that the server record some information in stable storage. The
amount of information the server records in stable storage is in amount of information the server records in stable storage is in
inverse proportion to how harsh the server intends to be whenever inverse proportion to how harsh the server intends to be whenever
edge conditions arise. The server that is completely tolerant of all edge conditions arise. The server that is completely tolerant of all
edge conditions will record in stable storage every lock that is edge conditions will record in stable storage every lock that is
acquired, removing the lock record from stable storage only when the acquired, removing the lock record from stable storage only when the
lock is released. For the two edge conditions discussed above, the lock is released. For the two edge conditions discussed above, the
harshest a server can be, and still support a grace period for harshest a server can be, and still support a grace period for
reclaims, requires that the server record in stable storage reclaims, requires that the server record in stable storage some
information some minimal information. For example, a server minimal information. For example, a server implementation could, for
implementation could, for each client, save in stable storage a each client, save in stable storage a record containing:
record containing:
o the co_ownerid field from the client_owner4 presented in the o the co_ownerid field from the client_owner4 presented in the
EXCHANGE_ID operation. EXCHANGE_ID operation.
o a boolean that indicates if the client's lease expired or if there o a boolean that indicates if the client's lease expired or if there
was administrative intervention (see Section 8.5) to revoke a was administrative intervention (see Section 8.5) to revoke a
byte-range lock, share reservation, or delegation and there has byte-range lock, share reservation, or delegation and there has
been no acknowledgement, via FREE_STATEID, of such revocation. been no acknowledgement, via FREE_STATEID, of such revocation.
o a boolean that indicates whether the client may have locks that it o a boolean that indicates whether the client may have locks that it
skipping to change at page 212, line 16 skipping to change at page 212, line 16
recalled delegation is not returned. Note that the client's lease recalled delegation is not returned. Note that the client's lease
might still be renewed, even though the recalled delegation is not might still be renewed, even though the recalled delegation is not
returned. In this situation, servers SHOULD revoke delegations that returned. In this situation, servers SHOULD revoke delegations that
are not returned in a period of time equal to the lease period. This are not returned in a period of time equal to the lease period. This
period of time should allow the client time to note the backchannel- period of time should allow the client time to note the backchannel-
down status and re-establish the backchannel. down status and re-establish the backchannel.
When delegations are revoked, the server will return with the When delegations are revoked, the server will return with the
SEQ4_STATUS_RECALLABLE_STATE_REVOKED status bit set on subsequent SEQ4_STATUS_RECALLABLE_STATE_REVOKED status bit set on subsequent
SEQUENCE operations. The client should note this and then use SEQUENCE operations. The client should note this and then use
TEST_STATEID to find which delegations have been recalled. TEST_STATEID to find which delegations have been revoked.
10.4.6. Delegation Revocation 10.4.6. Delegation Revocation
At the point a delegation is revoked, if there are associated opens At the point a delegation is revoked, if there are associated opens
on the client, these opens may or may not be revoked. If no lock or on the client, these opens may or may not be revoked. If no lock or
open is granted that is inconsistent with the existing open, the open is granted that is inconsistent with the existing open, the
stateid for the open may remain valid, and be disconnected from the stateid for the open may remain valid, and be disconnected from the
revoked delegation, just as would be the case if the delegation were revoked delegation, just as would be the case if the delegation were
returned. returned.
skipping to change at page 418, line 40 skipping to change at page 418, line 40
The server MUST return a value for each attribute that the client The server MUST return a value for each attribute that the client
requests if the attribute is supported by the server for the target requests if the attribute is supported by the server for the target
file system. If the server does not support a particular attribute file system. If the server does not support a particular attribute
on the target file system then it MUST NOT return the attribute value on the target file system then it MUST NOT return the attribute value
and MUST NOT set the attribute bit in the result bitmap. The server and MUST NOT set the attribute bit in the result bitmap. The server
MUST return an error if it supports an attribute on the target but MUST return an error if it supports an attribute on the target but
cannot obtain its value. In that case, no attribute values will be cannot obtain its value. In that case, no attribute values will be
returned. returned.
File systems which are absent should be treated as having support for File systems which are absent should be treated as having support for
a very small set of attributes as described in GETATTR Within an a very small set of attributes as described in Section 11.3.1, even
Absent File System (Section 5), even if previously, when the file if previously, when the file system was present, more attributes were
system was present, more attributes were supported. supported.
All servers MUST support the REQUIRED attributes as specified in File All servers MUST support the REQUIRED attributes as specified in
Attributes (Section 11.3.1), for all file systems, with the exception Section 5.6, for all file systems, with the exception of absent file
of absent file systems. systems.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.7.4. IMPLEMENTATION 18.7.4. IMPLEMENTATION
Suppose there is a write delegation held by another client for file Suppose there is a write delegation held by another client for file
in question and size and/or change are among the set of attributes in question and size and/or change are among the set of attributes
being interrogated. The server has two choices. First, the server being interrogated. The server has two choices. First, the server
can obtain the actual current value of these attributes from the can obtain the actual current value of these attributes from the
client holding the delegation by using the CB_GETATTR callback. client holding the delegation by using the CB_GETATTR callback.
skipping to change at page 454, line 10 skipping to change at page 454, line 10
exists, one is created and its filehandle becomes the current exists, one is created and its filehandle becomes the current
filehandle. On the other hand, if createdir has a value of TRUE and filehandle. On the other hand, if createdir has a value of TRUE and
the named attribute directory already exists, no error results and the named attribute directory already exists, no error results and
the filehandle of the existing directory becomes the current the filehandle of the existing directory becomes the current
filehandle. The creation of a named attribute directory assumes that filehandle. The creation of a named attribute directory assumes that
the server has implemented named attribute support in this fashion the server has implemented named attribute support in this fashion
and is not required to do so by this definition. and is not required to do so by this definition.
If the current file handle designates an object of type NF4NAMEDATTR If the current file handle designates an object of type NF4NAMEDATTR
(a named attribute) or NF4ATTRDIR (a named attribute directory), an (a named attribute) or NF4ATTRDIR (a named attribute directory), an
error of NFS4ERR_WRONG_TYPE is returned to the client. Name error of NFS4ERR_WRONG_TYPE is returned to the client. Named
attributes or a named attribute directory may have their own named attributes or a named attribute directory MUST NOT have their own
attributes. named attributes.
18.17.4. IMPLEMENTATION 18.17.4. IMPLEMENTATION
If the server does not support named attributes for the current If the server does not support named attributes for the current
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the filehandle, an error of NFS4ERR_NOTSUPP will be returned to the
client. client.
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access
18.18.1. ARGUMENTS 18.18.1. ARGUMENTS
skipping to change at page 511, line 18 skipping to change at page 511, line 18
The corresponding result is csr_sessionid, the session ID of the The corresponding result is csr_sessionid, the session ID of the
new session. new session.
csa_sequence: csa_sequence:
Each client ID serializes CREATE_SESSION via a per client ID Each client ID serializes CREATE_SESSION via a per client ID
sequence number (see Section 18.36.4). The corresponding result sequence number (see Section 18.36.4). The corresponding result
is csr_sequence, which MUST be equal to csa_sequence. is csr_sequence, which MUST be equal to csa_sequence.
In the next three arguments, the client offers a value that is to be In the next three arguments, the client offers a value that is to be
a property of the session. It is RECOMMENDED that the server accept a property of the session. Except where otherwise stated, it is
the value. If it is not acceptable, the server MAY use a different RECOMMENDED that the server accept the value, and if it is not
value. Regardless, the server MUST return the value the session will acceptable, the server MAY use a different value. Regardless, the
use (which will be either what the client offered, or what the server value the server returns (which will be either what the client
is insisting on). return the value used to the client. These offered, or what the server is insisting on) will be the value the
parameters have the following interpretation. session uses.
csa_flags: csa_flags:
The csa_flags field contains a list of the following flag bits: The csa_flags field contains a list of the following flag bits:
CREATE_SESSION4_FLAG_PERSIST: CREATE_SESSION4_FLAG_PERSIST:
If CREATE_SESSION4_FLAG_PERSIST is set, the client wants the If CREATE_SESSION4_FLAG_PERSIST is set, the client wants the
server to provide a persistent reply cache. For sessions in server to provide a persistent reply cache. For sessions in
which only idempotent operations will be used (e.g. a read-only which only idempotent operations will be used (e.g. a read-only
skipping to change at page 512, line 37 skipping to change at page 512, line 37
client), respectively. The results are in corresponding client), respectively. The results are in corresponding
structures called csr_fore_chan_attrs and csr_back_chan_attrs. structures called csr_fore_chan_attrs and csr_back_chan_attrs.
The results establish attributes for each channel, and on all The results establish attributes for each channel, and on all
subsequent use of each channel of the session. Each structure has subsequent use of each channel of the session. Each structure has
the following fields: the following fields:
ca_headerpadsize: ca_headerpadsize:
The maximum amount of padding the requester is willing to apply The maximum amount of padding the requester is willing to apply
to ensure that write payloads are aligned on some boundary at to ensure that write payloads are aligned on some boundary at
the replier. The replier should reply in ca_headerpadsize with the replier. For each channel, the server
its preferred value, or zero if padding is not in use. The
replier may decrease this value but MUST NOT increase it. + will reply in ca_headerpadsize with its preferred value, or
zero if padding is not in use, and
+ MAY decrease this value but MUST NOT increase it.
ca_maxrequestsize: ca_maxrequestsize:
The maximum size of a COMPOUND or CB_COMPOUND request that will The maximum size of a COMPOUND or CB_COMPOUND request that will
be sent. This size represents the XDR encoded size of the be sent. This size represents the XDR encoded size of the
request, including the RPC headers (including security flavor request, including the RPC headers (including security flavor
credentials and verifiers) but excludes any RPC transport credentials and verifiers) but excludes any RPC transport
framing headers. Imagine a request coming over a non-RDMA framing headers. Imagine a request coming over a non-RDMA
TCP/IP connection, and that it has a single Record Marking TCP/IP connection, and that it has a single Record Marking
header preceding it. The maximum allowable count encoded in header preceding it. The maximum allowable count encoded in
the header will be ca_maxrequestsize. If a requester sends a the header will be ca_maxrequestsize. If a requester sends a
request that exceeds ca_maxrequestsize, the error request that exceeds ca_maxrequestsize, the error
NFS4ERR_REQ_TOO_BIG will be returned per the description in NFS4ERR_REQ_TOO_BIG will be returned per the description in
Section 2.10.6.4. Section 2.10.6.4. For each channel, the server MAY decrease
this value but MUST NOT increase it.
ca_maxresponsesize: ca_maxresponsesize:
The maximum size of a COMPOUND or CB_COMPOUND reply that the The maximum size of a COMPOUND or CB_COMPOUND reply that the
requester will accept from the replier including RPC headers requester will accept from the replier including RPC headers
(see the ca_maxrequestsize definition). The NFSv4.1 server (see the ca_maxrequestsize definition). For each channel,
MUST NOT increase the value of this parameter in the server MAY decrease this value, but MUST NOT increase it.
CREATE_SESSION results. However, if the client selects a value However, if the client selects a value for ca_maxresponsesize
for ca_maxresponsesize such that a replier on a channel could such that a replier on a channel could never send a response,
never send a response, the server SHOULD return the server SHOULD return NFS4ERR_TOOSMALL in the CREATE_SESSION
NFS4ERR_TOOSMALL in the CREATE_SESSION reply. If a requester reply. After the session is created, if a requester sends a
sends a request for which the size of the reply would exceed request for which the size of the reply would exceed this
this value, the replier will return NFS4ERR_REP_TOO_BIG, per value, the replier will return NFS4ERR_REP_TOO_BIG, per the
the description in Section 2.10.6.4. description in Section 2.10.6.4.
ca_maxresponsesize_cached: ca_maxresponsesize_cached:
Like ca_maxresponsesize, but the maximum size of a reply that Like ca_maxresponsesize, but the maximum size of a reply that
will be stored in the reply cache (Section 2.10.6.1). If the will be stored in the reply cache (Section 2.10.6.1). For each
reply to CREATE_SESSION has ca_maxresponsesize_cached less than channel, server MAY decrease this value, but MUST NOT increase
it. If the reply to CREATE_SESSION has the value
ca_maxresponsesize_cached less than the value
ca_maxresponsesize, then this is an indication to the requester ca_maxresponsesize, then this is an indication to the requester
on the channel that it needs to be selective about which on the channel that it needs to be selective about which
replies it directs the replier to cache; for example large replies it directs the replier to cache; for example large
replies from nonidempotent operations (e.g. COMPOUND requests replies from nonidempotent operations (e.g. COMPOUND requests
with a READ operation), should not be cached. The requester with a READ operation), should not be cached. The requester
decides which replies to cache via an argument to the SEQUENCE decides which replies to cache via an argument to the SEQUENCE
(the sa_cachethis field, see Section 18.46) or CB_SEQUENCE (the (the sa_cachethis field, see Section 18.46) or CB_SEQUENCE (the
csa_cachethis field, see Section 20.9) operations. If a csa_cachethis field, see Section 20.9) operations. After the
requester sends a request for which the size of the reply would session is created, if a requester sends a request for which
exceed this value, the replier will return the size of the reply would exceed this value, the replier will
NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in return NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in
Section 2.10.6.4. Section 2.10.6.4.
ca_maxoperations: ca_maxoperations:
The maximum number of operations the replier will accept in a The maximum number of operations the replier will accept in a
COMPOUND or CB_COMPOUND. The server MUST NOT increase COMPOUND or CB_COMPOUND. For the backchannel, the server MUST
ca_maxoperations in the reply to CREATE_SESSION. If the NOT change the value the client offers. For the fore channel,
requester sends a COMPOUND or CB_COMPOUND with more operations the server MAY change the requested value. After the session
than ca_maxoperations, the replier MUST return is created, if a requester sends a COMPOUND or CB_COMPOUND with
more operations than ca_maxoperations, the replier MUST return
NFS4ERR_TOO_MANY_OPS. NFS4ERR_TOO_MANY_OPS.
ca_maxrequests: ca_maxrequests:
The maximum number of concurrent COMPOUND or CB_COMPOUND The maximum number of concurrent COMPOUND or CB_COMPOUND
requests the requester will send on the session. Subsequent requests the requester will send on the session. Subsequent
requests will each be assigned a slot identifier by the requests will each be assigned a slot identifier by the
requester within the range 0 to ca_maxrequests - 1 inclusive. requester within the range 0 to ca_maxrequests - 1 inclusive.
For the backchannel, the server MUST NOT change the value the
client offers. For the fore channel, the server MAY change the
requested value.
ca_rdma_ird: ca_rdma_ird:
This array has a maximum of one element. If this array has one This array has a maximum of one element. If this array has one
element, then the element contains the inbound RDMA read queue element, then the element contains the inbound RDMA read queue
depth (IRD). depth (IRD). For each channel, server MAY decrease this value,
but MUST NOT increase it.
csa_cb_program csa_cb_program
This is the ONC RPC program number the server MUST use in any This is the ONC RPC program number the server MUST use in any
callbacks sent through the backchannel to the client. The server callbacks sent through the backchannel to the client. The server
MUST specify an ONC RPC program number equal to csa_cb_program and MUST specify an ONC RPC program number equal to csa_cb_program and
an ONC RPC version number equal to 4 in callbacks sent to the an ONC RPC version number equal to 4 in callbacks sent to the
client. If a CB_COMPOUND is sent to the client, the server MUST client. If a CB_COMPOUND is sent to the client, the server MUST
use a minor version number of 1. There is no corresponding use a minor version number of 1. There is no corresponding
result. result.
skipping to change at page 518, line 16 skipping to change at page 518, line 26
Neither of these cases are permissible. Processing stops Neither of these cases are permissible. Processing stops
and NFS4ERR_CLID_INUSE is returned to the client. No and NFS4ERR_CLID_INUSE is returned to the client. No
changes are made to any client records on the server. changes are made to any client records on the server.
4. Session creation. The server confirmed the client ID, either in 4. Session creation. The server confirmed the client ID, either in
this CREATE_SESSION operation, or a previous CREATE_SESSION this CREATE_SESSION operation, or a previous CREATE_SESSION
operation. The server examines the remaining fields of the operation. The server examines the remaining fields of the
arguments. arguments.
5. The server creates the session by recording the parameter values The server creates the session by recording the parameter values
used (including whether the CREATE_SESSION4_FLAG_PERSIST flag is used (including whether the CREATE_SESSION4_FLAG_PERSIST flag is
set and has been accepted by the server) and allocating space for set and has been accepted by the server) and allocating space for
the session reply cache (if there is not enough space, the server the session reply cache (if there is not enough space, the server
returns NFS4ERR_NOSPC). For each slot in the reply cache, the returns NFS4ERR_NOSPC). For each slot in the reply cache, the
server sets the sequence ID to zero (0), and records an entry server sets the sequence ID to zero (0), and records an entry
containing a COMPOUND reply with zero operations and the error containing a COMPOUND reply with zero operations and the error
NFS4ERR_SEQ_MISORDERED. This way, if the first SEQUENCE request NFS4ERR_SEQ_MISORDERED. This way, if the first SEQUENCE request
sent has a sequence ID equal to zero, the server can simply sent has a sequence ID equal to zero, the server can simply
return what is in the reply cache: NFS4ERR_SEQ_MISORDERED. The return what is in the reply cache: NFS4ERR_SEQ_MISORDERED. The
client initializes its reply cache for receiving callbacks in the client initializes its reply cache for receiving callbacks in the
same way, and similarly, the first CB_SEQUENCE operation on a same way, and similarly, the first CB_SEQUENCE operation on a
slot after session creation MUST have a sequence ID of one. slot after session creation MUST have a sequence ID of one.
6. If the session state is created successfully, the server If the session state is created successfully, the server
associates the session with the client ID provided by the client. associates the session with the client ID provided by the client.
7. When a request that had CREATE_SESSION4_FLAG_CONN_RDMA set needs When a request that had CREATE_SESSION4_FLAG_CONN_RDMA set needs
to be retried, the retry MUST be done on a new connection that is to be retried, the retry MUST be done on a new connection that is
in non-RDMA mode. If properties of the new connection are in non-RDMA mode. If properties of the new connection are
different enough that the arguments to CREATE_SESSION need to different enough that the arguments to CREATE_SESSION need to
change, then a non-retry MUST be sent. The server will change, then a non-retry MUST be sent. The server will
eventually dispose of any session that was created on the eventually dispose of any session that was created on the
original connection. original connection.
On the backchannel, the client and server might wish to have many On the backchannel, the client and server might wish to have many
slots, in some cases perhaps more that the fore channel, in to deal slots, in some cases perhaps more that the fore channel, in to deal
with the situations where the network link has high latency and is with the situations where the network link has high latency and is
skipping to change at page 564, line 7 skipping to change at page 565, line 7
possible. possible.
RECLAIM_COMPLETE should only be done once for each server instance, RECLAIM_COMPLETE should only be done once for each server instance,
or occasion of the transition of a file system. If it is done a or occasion of the transition of a file system. If it is done a
second time, the error NFS4ERR_COMPLETE_ALREADY will result. Note second time, the error NFS4ERR_COMPLETE_ALREADY will result. Note
that because of the session feature's retry protection, retries of that because of the session feature's retry protection, retries of
COMPOUND requests containing RECLAIM_COMPLETE operation will not COMPOUND requests containing RECLAIM_COMPLETE operation will not
result in this error. result in this error.
When a RECLAIM_COMPLETE is done, the client effectively acknowledges When a RECLAIM_COMPLETE is done, the client effectively acknowledges
any locks not yet reclaimed as lost. This allows the server to again any locks not yet reclaimed as lost. This allows the server to re-
mark this client as able to subsequently recover locks if it had been enable this client to subsequently recover locks. The server might
prevented from doing so, be by logic to prevent the occurrence of have disabled the client's ability to recover locks in order to
edge conditions, as described in Section 8.4.3. prevent the occurrence of the edge conditions described in
Section 8.4.3.
18.52. Operation 10044: ILLEGAL - Illegal operation 18.52. Operation 10044: ILLEGAL - Illegal operation
18.52.1. ARGUMENTS 18.52.1. ARGUMENTS
void; void;
18.52.2. RESULTS 18.52.2. RESULTS
struct ILLEGAL4res { struct ILLEGAL4res {
skipping to change at page 593, line 31 skipping to change at page 594, line 31
protection on each remote procedure call and response. The use of protection on each remote procedure call and response. The use of
mechanisms without integrity leaves the user vulnerable to an mechanisms without integrity leaves the user vulnerable to an
attacker in the middle of the NFS client and server that modifies the attacker in the middle of the NFS client and server that modifies the
RPC request and/or the response. While implementations are free to RPC request and/or the response. While implementations are free to
provide the option to use weaker security mechanisms, there are three provide the option to use weaker security mechanisms, there are three
operations in particular that warrant the implementation overriding operations in particular that warrant the implementation overriding
user choices. user choices.
o The first two such operations are SECINFO and SECINFO_NO_NAME. It o The first two such operations are SECINFO and SECINFO_NO_NAME. It
is RECOMMENDED that the client send both operations such that they is RECOMMENDED that the client send both operations such that they
is protected with a security flavor that has integrity protection, are protected with a security flavor that has integrity
such as RPCSEC_GSS with either the rpc_gss_svc_integrity or protection, such as RPCSEC_GSS with either the
rpc_gss_svc_privacy service. Without integrity protection rpc_gss_svc_integrity or rpc_gss_svc_privacy service. Without
encapsulating SECINFO and SECINFO_NO_NAME and their results, an integrity protection encapsulating SECINFO and SECINFO_NO_NAME and
attacker in the middle could modify results such that the client their results, an attacker in the middle could modify results such
might select a weaker algorithm in the set allowed by server, that the client might select a weaker algorithm in the set allowed
making the client and/or server vulnerable to further attacks. by server, making the client and/or server vulnerable to further
attacks.
o The third operation that should definitely use integrity o The third operation that SHOULD use integrity protection is any
protection is any GETATTR for the fs_locations and GETATTR for the fs_locations and fs_locations_info attributes, in
fs_locations_info attributes. The attack has two steps. First order to mitigate the severity of a man in the middle attack. The
the attacker modifies the unprotected results of some operation to attack has two steps. First the attacker modifies the unprotected
return NFS4ERR_MOVED. Second, when the client follows up with a results of some operation to return NFS4ERR_MOVED. Second, when
GETATTR for the fs_locations or fs_locations_info attributes, the the client follows up with a GETATTR for the fs_locations or
attacker modifies the results to cause the client migrate its fs_locations_info attributes, the attacker modifies the results to
traffic to a server controlled by the attacker. cause the client migrate its traffic to a server controlled by the
attacker. With integrity protection, this attack is mitigated.
Relative to previous NFS versions, NFSv4.1 has additional security Relative to previous NFS versions, NFSv4.1 has additional security
considerations for pNFS (see Section 12.9 and Section 13.12), locking considerations for pNFS (see Section 12.9 and Section 13.12), locking
and session state (see Section 2.10.8.3), and state recovery during and session state (see Section 2.10.8.3), and state recovery during
grace period (see Section 8.4.2.1.1). grace period (see Section 8.4.2.1.1).
22. IANA Considerations 22. IANA Considerations
This section uses terms that are defined in [54]. This section uses terms that are defined in [54].
skipping to change at page 611, line 5 skipping to change at page 612, line 26
Amy Weaver, and Lisa Week. Amy Weaver, and Lisa Week.
Jari Arkko, David Black, Scott Bradner, Lisa Dusseault, Lars Eggert, Jari Arkko, David Black, Scott Bradner, Lisa Dusseault, Lars Eggert,
Chris Newman, and Tim Polk provided valuable review and guidance. Chris Newman, and Tim Polk provided valuable review and guidance.
Olga Kornievskaia found several errors in the SSV specification. Olga Kornievskaia found several errors in the SSV specification.
Ricardo Labiaga found several places where the use of RPCSEC_GSS was Ricardo Labiaga found several places where the use of RPCSEC_GSS was
underspecified. underspecified.
Others who provided comments include: Sunil Bhargo, Jason Those who provided miscellaneous comments include: Andy Adamson,
Goldschmidt, Vijay K. Gurbani, James Lentini, Anshul Madan, Archana Sunil Bhargo, Alex Burlyga, Jason Goldschmidt, Vijay K. Gurbani,
Ramani, Jim Rees, and Mahesh Siddheshwar. Sergey Klyushin, Ricardo Labiaga, James Lentini, Anshul Madan, Daniel
Muntz, Archana Ramani, Jim Rees, Mahesh Siddheshwar, Tom Talpey, and
Peter Varga.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
 End of changes. 73 change blocks. 
233 lines changed or deleted 250 lines changed or added

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