draft-ietf-nfsv4-rfc1831bis-09.txt   draft-ietf-nfsv4-rfc1831bis-10.txt 
Network File System Version 4 Working Group R. Thurlow Network File System Version 4 Working Group R. Thurlow
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Intended status: Draft Standard Intended status: Draft Standard
Obsoletes: 1831 Obsoletes: 1831
Expires: December 12, 2008 June 10, 2008 Expires: April 30, 2009 October 30, 2008
RPC: Remote Procedure Call Protocol Specification Version 2 RPC: Remote Procedure Call Protocol Specification Version 2
draft-ietf-nfsv4-rfc1831bis-09.txt draft-ietf-nfsv4-rfc1831bis-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire in December, 2008. Distribution of this draft is document will expire in April, 2009. Distribution of this draft is
unlimited. unlimited.
Abstract Abstract
This document describes the ONC (Open Network Computing) Remote This document describes the ONC (Open Network Computing) Remote
Procedure Call (ONC RPC Version 2) protocol as it is currently Procedure Call (ONC RPC Version 2) protocol as it is currently
deployed and accepted. It is meant to supersede [RFC1831]. deployed and accepted. This document obsoletes [RFC1831].
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Changes since RFC 1831 . . . . . . . . . . . . . . . . . . . 1 2. Changes since RFC 1831 . . . . . . . . . . . . . . . . . . . 1
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 1 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 1
skipping to change at page 2, line 39 skipping to change at page 2, line 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 1 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 1
13.1. Numbering Requests to IANA . . . . . . . . . . . . . . . 1 13.1. Numbering Requests to IANA . . . . . . . . . . . . . . . 1
13.2. Protecting Past Assignments . . . . . . . . . . . . . . . 1 13.2. Protecting Past Assignments . . . . . . . . . . . . . . . 1
13.3. RPC Number Assignment . . . . . . . . . . . . . . . . . . 1 13.3. RPC Number Assignment . . . . . . . . . . . . . . . . . . 1
13.3.1. To be assigned by IANA . . . . . . . . . . . . . . . . 1 13.3.1. To be assigned by IANA . . . . . . . . . . . . . . . . 1
13.3.2. Defined by local administrator . . . . . . . . . . . . 1 13.3.2. Defined by local administrator . . . . . . . . . . . . 1
13.3.3. Transient block . . . . . . . . . . . . . . . . . . . . 1 13.3.3. Transient block . . . . . . . . . . . . . . . . . . . . 1
13.3.4. Reserved block . . . . . . . . . . . . . . . . . . . . 1 13.3.4. Reserved block . . . . . . . . . . . . . . . . . . . . 1
13.3.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 1 13.3.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 1
13.4. RPC Authentication Flavor Number Assignment . . . . . . . 1 13.4. RPC Authentication Flavor Number Assignment . . . . . . . 1
13.4.1. Assignment Policy . . . . . . . . . . . . . . . . . . . 1
13.4.2. Auth Flavors vs. Pseudo-flavors . . . . . . . . . . . . 1
14. Security Considerations . . . . . . . . . . . . . . . . . . 1 14. Security Considerations . . . . . . . . . . . . . . . . . . 1
15. Appendix A: System Authentication . . . . . . . . . . . . . 1 15. Appendix A: System Authentication . . . . . . . . . . . . . 1
16. Appendix B: Requesting RPC program or authentication 16. Appendix B: Requesting RPC program or authentication
numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 1 numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 1
17. Full Copyright Statement . . . . . . . . . . . . . . . . . 1 17. Full Copyright Statement . . . . . . . . . . . . . . . . . 1
18. Intellectual property . . . . . . . . . . . . . . . . . . . 1 18. Intellectual property . . . . . . . . . . . . . . . . . . . 1
19. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 1 19. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 1
20. Normative References . . . . . . . . . . . . . . . . . . . 1 20. Normative References . . . . . . . . . . . . . . . . . . . 1
21. Informative References . . . . . . . . . . . . . . . . . . 1 21. Informative References . . . . . . . . . . . . . . . . . . 1
22. Author's Address . . . . . . . . . . . . . . . . . . . . . 1 22. Author's Address . . . . . . . . . . . . . . . . . . . . . 1
skipping to change at page 3, line 17 skipping to change at page 3, line 17
This document specifies version two of the message protocol used in This document specifies version two of the message protocol used in
ONC Remote Procedure Call (RPC). The message protocol is specified ONC Remote Procedure Call (RPC). The message protocol is specified
with the eXternal Data Representation (XDR) language [RFC4506]. This with the eXternal Data Representation (XDR) language [RFC4506]. This
document assumes that the reader is familiar with XDR. It does not document assumes that the reader is familiar with XDR. It does not
attempt to justify remote procedure calls systems or describe their attempt to justify remote procedure calls systems or describe their
use. The paper by Birrell and Nelson [XRPC] is recommended as an use. The paper by Birrell and Nelson [XRPC] is recommended as an
excellent background for the remote procedure call concept. excellent background for the remote procedure call concept.
2. Changes since RFC 1831 2. Changes since RFC 1831
This document is intended to replace RFC 1831 as the authoritative This document obsoletes RFC 1831 as the authoritative document
document describing RPC, without introducing any over-the-wire describing RPC, without introducing any over-the-wire protocol
protocol changes. The main changes from RFC 1831 are: changes. The main changes from RFC 1831 are:
o Addition of an Appendix which describes how an implementor can o Addition of an Appendix which describes how an implementor can
request new RPC program numbers and authentication flavor request new RPC program numbers and authentication flavor
numbers from IANA, rather than from Sun Microsystems numbers from IANA, rather than from Sun Microsystems
o Addition of an "IANA Considerations" section which describes o Addition of an "IANA Considerations" section which describes
past program and authentication flavor number assignment policy past program and authentication flavor number assignment policy
and how IANA is intended to assign them in future and how IANA is intended to assign them in future
o Clarification of the RPC Language Specification to match current o Clarification of the RPC Language Specification to match current
skipping to change at page 18, line 9 skipping to change at page 18, line 9
program numbers and authentication flavor numbers described here from program numbers and authentication flavor numbers described here from
Sun Microsystems, Inc. to IANA and proposes how IANA will maintain Sun Microsystems, Inc. to IANA and proposes how IANA will maintain
and assign RPC program numbers and authentication flavor numbers. and assign RPC program numbers and authentication flavor numbers.
Users of RPC protocols will benefit by having an independent body Users of RPC protocols will benefit by having an independent body
responsible for RPC number assignments. responsible for RPC number assignments.
13.1. Numbering Requests to IANA 13.1. Numbering Requests to IANA
Appendix B of this document describes the information to be sent to Appendix B of this document describes the information to be sent to
IANA to request one or more RPC numbers and the rules that apply. IANA to request one or more RPC numbers and the rules that apply.
IANA should review this part of the document as well. IANA should store the request for documentary purposes, and put the
following information into the public registry:
o The short description of purpose and use
o The program number(s) assigned
o The short identifier string(s)
13.2. Protecting Past Assignments 13.2. Protecting Past Assignments
Sun has made assignments in both number spaces since the original Sun has made assignments in both number spaces since the original
deployment of RPC. The assignments made by Sun Microsystems are deployment of RPC. The assignments made by Sun Microsystems are
still valid, and will be preserved. Sun will communicate all current still valid, and will be preserved. Sun will communicate all current
assignments in both number spaces to IANA before final handoff of assignments in both number spaces to IANA before final handoff of
number assignment is done. number assignment is done. At the time of submission of this draft,
current assignments were listed at:
http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt
13.3. RPC Number Assignment 13.3. RPC Number Assignment
Future IANA practice should deal with the following partitioning of Future IANA practice should deal with the following partitioning of
the 32-bit number space as listed in Section 8.3. Detailed the 32-bit number space as listed in Section 8.3. Detailed
information for the administration of the partitioned blocks in information for the administration of the partitioned blocks in
Section 8.3. is given below. Section 8.3. is given below.
13.3.1. To be assigned by IANA 13.3.1. To be assigned by IANA
skipping to change at page 20, line 32 skipping to change at page 20, line 41
with a single RPC protocol or multiple RPC protocols, and whether the with a single RPC protocol or multiple RPC protocols, and whether the
numbers are dynamically assigned or statically (through numbers are dynamically assigned or statically (through
administrative action) assigned. administrative action) assigned.
Sub-blocks of up to 1000 numbers must be documented in detail. The Sub-blocks of up to 1000 numbers must be documented in detail. The
documentation must describe the RPC protocol or protocols that are to documentation must describe the RPC protocol or protocols that are to
be used in the range. It must also describe how the numbers within be used in the range. It must also describe how the numbers within
the sub-block are to be assigned or used. the sub-block are to be assigned or used.
Sub-blocks sized over 1000 numbers must be documented as described Sub-blocks sized over 1000 numbers must be documented as described
above, however an Internet Draft must be submitted as an above, and the assignment must be approved by the IESG. It is
Informational or standards-track RFC. If accepted as either, IANA expected that this will be rare.
will assign the requested number sub-block.
In order to avoid multiple requests of large blocks of numbers the In order to avoid multiple requests of large blocks of numbers the
following rule is proposed. following rule is proposed.
Requests up to and including 100 RPC numbers are handled via the Requests up to and including 100 RPC numbers are handled via the
First Come First Served assignment method. This 100 number First Come First Served assignment method. This 100 number
threshhold applies to the total number of RPC numbers assigned to an threshhold applies to the total number of RPC numbers assigned to an
individual or entity. For example, if an individual or entity first individual or entity. For example, if an individual or entity first
requests say 70 numbers, and then later requests 40 numbers, then the requests say 70 numbers, and then later requests 40 numbers, then the
request for the 40 numbers will be assigned via the Specification request for the 40 numbers will be assigned via the Specification
Required method. As long as the total number of numbers assigned Required method. As long as the total number of numbers assigned
does not exceed 1000, IANA is free to waive the Specification does not exceed 1000, IANA is free to waive the Specification
Required assignment for incremental requests of less than 100 Required assignment for incremental requests of less than 100
numbers. numbers.
If an individual or entity has under 1000 numbers and later requests If an individual or entity has under 1000 numbers and later requests
an additional set of numbers such that the individual or entity would an additional set of numbers such that the individual or entity would
over 1000 numbers, then the individual or entity will have the be granted over 1000 numbers, then the additional request will
additional request submitted to the IESG. IESG is free to waive the require IESG Approval.
IESG Action Required assignment method for incremental requests of
less than 1000 numbers.
13.4. RPC Authentication Flavor Number Assignment 13.4. RPC Authentication Flavor Number Assignment
The second number space is the authentication mechanism identifier, The second number space is the authentication mechanism identifier,
or "flavor", number. This number is used to distinguish between or "flavor", number. This number is used to distinguish between
various authentication mechanisms which can be optionally used with various authentication mechanisms which can be optionally used with
an RPC message. An authentication identifier is used in the "flavor" an RPC message. An authentication identifier is used in the "flavor"
field of the "opaque_auth" structure. field of the "opaque_auth" structure.
13.4.1. Assignment Policy
Appendix B of this document describes the information to be sent to
IANA to request one or more RPC auth numbers and the rules that
apply. IANA should store the request for documentary purposes, and
put the following information into the public registry:
o The short identifier string(s)
o The auth number(s) assigned
o The short description of purpose and use
13.4.2. Auth Flavors vs. Pseudo-flavors
Recent progress in RPC security has moved away from new auth flavors Recent progress in RPC security has moved away from new auth flavors
as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS
[RFC2203] flavor and inventing novel GSS-API mechanisms which can be [RFC2203] flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094] flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3530]) will require the registration of 'pseudo- [RFC1813] and [RFC3530]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255. have been granted in the decimal range 390000-390255. New pseudo-
flavor requests should be granted by IANA within this block on a
First Come First Served basis.
For non-pseudo-flavor requests, IANA should begin granting RPC For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 to avoid conflicts with authentication flavor numbers at 400000 on a First Come First Served
currently granted numbers. basis to avoid conflicts with currently granted numbers.
For authentication flavors or RPCSEC_GSS mechanisms to be used on the For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards- Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism track RFC be published describing the authentication mechanism
behaviour and parameters. behaviour and parameters.
14. Security Considerations 14. Security Considerations
AUTH_SYS as described in Appendix A is known to be insecure due to AUTH_SYS as described in Appendix A is known to be insecure due to
the lack of a verifier to permit the credential to be validated. the lack of a verifier to permit the credential to be validated.
 End of changes. 13 change blocks. 
19 lines changed or deleted 47 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/