draft-ietf-nfsv4-rfc1831bis-08.txt   draft-ietf-nfsv4-rfc1831bis-09.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: August 25, 2008 February 22, 2008 Expires: December 12, 2008 June 10, 2008
RPC: Remote Procedure Call Protocol Specification Version 2 RPC: Remote Procedure Call Protocol Specification Version 2
draft-ietf-nfsv4-rfc1831bis-08.txt draft-ietf-nfsv4-rfc1831bis-09.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 July, 2008. Distribution of this draft is document will expire in December, 2008. 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. It is meant to supersede [RFC1831].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
4. The RPC Model . . . . . . . . . . . . . . . . . . . . . . . 1 4. The RPC Model . . . . . . . . . . . . . . . . . . . . . . . 1
5. Transports and Semantics . . . . . . . . . . . . . . . . . . 1 5. Transports and Semantics . . . . . . . . . . . . . . . . . . 1
6. Binding and Rendezvous Independence . . . . . . . . . . . . 1 6. Binding and Rendezvous Independence . . . . . . . . . . . . 1
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 1 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 1
8. RPC Protocol Requirements . . . . . . . . . . . . . . . . . 1 8. RPC Protocol Requirements . . . . . . . . . . . . . . . . . 1
8.1. RPC Programs and Procedures . . . . . . . . . . . . . . . 1 8.1. RPC Programs and Procedures . . . . . . . . . . . . . . . 1
8.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 1 8.2. Authentication, Integrity and Privacy . . . . . . . . . . 1
8.3. Program Number Assignment . . . . . . . . . . . . . . . . 1 8.3. Program Number Assignment . . . . . . . . . . . . . . . . 1
8.4. Other Uses of the RPC Protocol . . . . . . . . . . . . . . 1 8.4. Other Uses of the RPC Protocol . . . . . . . . . . . . . . 1
8.4.1. Batching . . . . . . . . . . . . . . . . . . . . . . . . 1 8.4.1. Batching . . . . . . . . . . . . . . . . . . . . . . . . 1
8.4.2. Broadcast Remote Procedure Calls . . . . . . . . . . . . 1 8.4.2. Broadcast Remote Procedure Calls . . . . . . . . . . . . 1
9. The RPC Message Protocol . . . . . . . . . . . . . . . . . . 1 9. The RPC Message Protocol . . . . . . . . . . . . . . . . . . 1
10. Authentication Protocols . . . . . . . . . . . . . . . . . 1 10. Authentication Protocols . . . . . . . . . . . . . . . . . 1
10.1. Null Authentication . . . . . . . . . . . . . . . . . . . 1 10.1. Null Authentication . . . . . . . . . . . . . . . . . . . 1
11. Record Marking Standard . . . . . . . . . . . . . . . . . . 1 11. Record Marking Standard . . . . . . . . . . . . . . . . . . 1
12. The RPC Language . . . . . . . . . . . . . . . . . . . . . 1 12. The RPC Language . . . . . . . . . . . . . . . . . . . . . 1
12.1. An Example Service Described in the RPC Language . . . . 1 12.1. An Example Service Described in the RPC Language . . . . 1
skipping to change at page 5, line 29 skipping to change at page 5, line 31
Authentication prevents one entity from masquerading as some Authentication prevents one entity from masquerading as some
other entity. other entity.
The conclusion is that even though there are tools to automatically The conclusion is that even though there are tools to automatically
generate client and server libraries for a given service, protocols generate client and server libraries for a given service, protocols
must still be designed carefully. must still be designed carefully.
5. Transports and Semantics 5. Transports and Semantics
The RPC protocol can be implemented on several different transport The RPC protocol can be implemented on several different transport
protocols. The RPC protocol does not care how a message is passed protocols. The scope of the definition of the RPC protocol excludes
from one process to another, but only with specification and how a message is passed from one process to another, and includes
interpretation of messages. However, the application may wish to only the specification and interpretation of messages. However, the
obtain information about (and perhaps control over) the transport application may wish to obtain information about (and perhaps control
layer through an interface not specified in this document. For over) the transport layer through an interface not specified in this
example, the transport protocol may impose a restriction on the document. For example, the transport protocol may impose a
maximum size of RPC messages, or it may be stream-oriented like TCP restriction on the maximum size of RPC messages, or it may be
[RFC793] with no size limit. The client and server must agree on stream-oriented like TCP [RFC793] with no size limit. The client and
their transport protocol choices. server must agree on their transport protocol choices.
It is important to point out that RPC does not try to implement any It is important to point out that RPC does not try to implement any
kind of reliability and that the application may need to be aware of kind of reliability and that the application may need to be aware of
the type of transport protocol underneath RPC. If it knows it is the type of transport protocol underneath RPC. If it knows it is
running on top of a reliable transport such as TCP, then most of the running on top of a reliable transport such as TCP, then most of the
work is already done for it. On the other hand, if it is running on work is already done for it. On the other hand, if it is running on
top of an unreliable transport such as UDP [RFC768], it must top of an unreliable transport such as UDP [RFC768], it must
implement its own time-out, retransmission, and duplicate detection implement its own time-out, retransmission, and duplicate detection
policies as the RPC protocol does not provide these services. policies as the RPC protocol does not provide these services.
skipping to change at page 7, line 14 skipping to change at page 7, line 16
to accomplish this task. to accomplish this task.
7. Authentication 7. Authentication
The RPC protocol provides the fields necessary for a client to The RPC protocol provides the fields necessary for a client to
identify itself to a service, and vice-versa, in each call and reply identify itself to a service, and vice-versa, in each call and reply
message. Security and access control mechanisms can be built on top message. Security and access control mechanisms can be built on top
of this message authentication. Several different authentication of this message authentication. Several different authentication
protocols can be supported. A field in the RPC header indicates protocols can be supported. A field in the RPC header indicates
which protocol is being used. More information on specific which protocol is being used. More information on specific
authentication protocols is in section 9: "Authentication Protocols". authentication protocols is in section 8.2: "Authentication,
Integrity and Privacy".
8. RPC Protocol Requirements 8. RPC Protocol Requirements
The RPC protocol must provide for the following: The RPC protocol must provide for the following:
o Unique specification of a procedure to be called. o Unique specification of a procedure to be called.
o Provisions for matching response messages to request messages. o Provisions for matching response messages to request messages.
o Provisions for authenticating the caller to service and vice- o Provisions for authenticating the caller to service and vice-
skipping to change at page 7, line 50 skipping to change at page 8, line 5
o Any other reasons why the desired procedure was not called. o Any other reasons why the desired procedure was not called.
8.1. RPC Programs and Procedures 8.1. RPC Programs and Procedures
The RPC call message has three unsigned integer fields -- remote The RPC call message has three unsigned integer fields -- remote
program number, remote program version number, and remote procedure program number, remote program version number, and remote procedure
number -- which uniquely identify the procedure to be called. number -- which uniquely identify the procedure to be called.
Program numbers are administered by a central authority (IANA). Once Program numbers are administered by a central authority (IANA). Once
implementors have a program number, they can implement their remote implementors have a program number, they can implement their remote
program; the first implementation would most likely have the version program; the first implementation would most likely have the version
number 1. Because most new protocols evolve, a version field of the number 1 but MUST NOT be the number zero. Because most new protocols
call message identifies which version of the protocol the caller is evolve, a version field of the call message identifies which version
using. Version numbers enable support of both old and new protocols of the protocol the caller is using. Version numbers enable support
through the same server process. of both old and new protocols through the same server process.
The procedure number identifies the procedure to be called. These The procedure number identifies the procedure to be called. These
numbers are documented in the specific program's protocol numbers are documented in the specific program's protocol
specification. For example, a file service's protocol specification specification. For example, a file service's protocol specification
may state that its procedure number 5 is "read" and procedure number may state that its procedure number 5 is "read" and procedure number
12 is "write". 12 is "write".
Just as remote program protocols may change over several versions, Just as remote program protocols may change over several versions,
the actual RPC message protocol could also change. Therefore, the the actual RPC message protocol could also change. Therefore, the
call message also has in it the RPC version number, which is always call message also has in it the RPC version number, which is always
skipping to change at page 8, line 39 skipping to change at page 8, line 41
number. The lowest and highest supported remote program version number. The lowest and highest supported remote program version
numbers are returned. numbers are returned.
o The requested procedure number does not exist. (This is usually o The requested procedure number does not exist. (This is usually
a client side protocol or programming error.) a client side protocol or programming error.)
o The parameters to the remote procedure appear to be garbage from o The parameters to the remote procedure appear to be garbage from
the server's point of view. (Again, this is usually caused by a the server's point of view. (Again, this is usually caused by a
disagreement about the protocol between client and service.) disagreement about the protocol between client and service.)
8.2. Authentication 8.2. Authentication, Integrity and Privacy
Provisions for authentication of caller to service and vice-versa are Provisions for authentication of caller to service and vice-versa are
provided as a part of the RPC protocol. The call message has two provided as a part of the RPC protocol. The call message has two
authentication fields, the credential and verifier. The reply authentication fields, the credential and verifier. The reply
message has one authentication field, the response verifier. The RPC message has one authentication field, the response verifier. The RPC
protocol specification defines all three fields to be the following protocol specification defines all three fields to be the following
opaque type (in the eXternal Data Representation (XDR) language opaque type (in the eXternal Data Representation (XDR) language
[RFC4506]): [RFC4506]):
enum auth_flavor { enum auth_flavor {
skipping to change at page 9, line 22 skipping to change at page 9, line 25
auth_flavor flavor; auth_flavor flavor;
opaque body<400>; opaque body<400>;
}; };
In other words, any "opaque_auth" structure is an "auth_flavor" In other words, any "opaque_auth" structure is an "auth_flavor"
enumeration followed by up to 400 bytes which are opaque to enumeration followed by up to 400 bytes which are opaque to
(uninterpreted by) the RPC protocol implementation. (uninterpreted by) the RPC protocol implementation.
The interpretation and semantics of the data contained within the The interpretation and semantics of the data contained within the
authentication fields is specified by individual, independent authentication fields is specified by individual, independent
authentication protocol specifications. (Section 9 defines the authentication protocol specifications.
various authentication protocols.)
If authentication parameters were rejected, the reply message If authentication parameters were rejected, the reply message
contains information stating why they were rejected. contains information stating why they were rejected.
As demonstrated by RPCSEC_GSS, it is possible for an "auth_flavor"
to also support integrity and privacy.
8.3. Program Number Assignment 8.3. Program Number Assignment
Program numbers are given out in groups of hexadecimal 20000000 Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart: (decimal 536870912) according to the following chart:
0 Reserved 0x00000000 Reserved
1 - 0x1fffffff To be assigned by IANA 0x00000001 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator 0x20000000 - 0x3fffffff Defined by local administrator
(some blocks assigned here) (some blocks assigned here)
0x40000000 - 0x5fffffff Transient 0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved 0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding 0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved 0x80000000 - 0xffffffff Reserved
The first group is a range of numbers administered by IANA and should The first group is a range of numbers administered by IANA and should
be identical for all sites. The second range is for applications be identical for all sites. The second range is for applications
peculiar to a particular site. This range is intended primarily for peculiar to a particular site. This range is intended primarily for
skipping to change at page 11, line 41 skipping to change at page 11, line 47
AUTH_REJECTEDCRED = 2, /* client must begin new session */ AUTH_REJECTEDCRED = 2, /* client must begin new session */
AUTH_BADVERF = 3, /* bad verifier (seal broken) */ AUTH_BADVERF = 3, /* bad verifier (seal broken) */
AUTH_REJECTEDVERF = 4, /* verifier expired or replayed */ AUTH_REJECTEDVERF = 4, /* verifier expired or replayed */
AUTH_TOOWEAK = 5, /* rejected for security reasons */ AUTH_TOOWEAK = 5, /* rejected for security reasons */
/* /*
* failed locally * failed locally
*/ */
AUTH_INVALIDRESP = 6, /* bogus response verifier */ AUTH_INVALIDRESP = 6, /* bogus response verifier */
AUTH_FAILED = 7, /* reason unknown */ AUTH_FAILED = 7, /* reason unknown */
/* /*
* kerberos errors * AUTH_KERB errors; deprecated. See [RFC2695]
*/ */
AUTH_KERB_GENERIC = 8, /* kerberos generic error */ AUTH_KERB_GENERIC = 8, /* kerberos generic error */
AUTH_TIMEEXPIRE = 9, /* time of credential expired */ AUTH_TIMEEXPIRE = 9, /* time of credential expired */
AUTH_TKT_FILE = 10, /* problem with ticket file */ AUTH_TKT_FILE = 10, /* problem with ticket file */
AUTH_DECODE = 11, /* can't decode authenticator */ AUTH_DECODE = 11, /* can't decode authenticator */
AUTH_NET_ADDR = 12, /* wrong net address in ticket */ AUTH_NET_ADDR = 12, /* wrong net address in ticket */
/* /*
* GSS related errors * RPCSEC_GSS GSS related errors
*/ */
RPCSEC_GSS_NOCRED = 13, /* no credentials for user */ RPCSEC_GSS_NOCRED = 13, /* no credentials for user */
RPCSEC_GSS_FAILED = 14 /* GSS failure, creds deleted */ RPCSEC_GSS_FAILED = 14 /* GSS failure, creds deleted */
}; };
The RPC message: The RPC message:
All messages start with a transaction identifier, xid, followed by a All messages start with a transaction identifier, xid, followed by a
two-armed discriminated union. The union's discriminant is a two-armed discriminated union. The union's discriminant is a
msg_type which switches to one of the two types of the message. The msg_type which switches to one of the two types of the message. The
xid of a REPLY message always matches that of the initiating CALL xid of a REPLY message always matches that of the initiating CALL
message. NB: The xid field is only used for clients matching reply message. NB: The xid field is only used for clients matching reply
messages with call messages or for servers detecting retransmissions; messages with call messages or for servers detecting retransmissions;
the service side cannot treat this id as any type of sequence number. the service side cannot treat this id as any type of sequence number.
skipping to change at page 12, line 28 skipping to change at page 12, line 34
union switch (msg_type mtype) { union switch (msg_type mtype) {
case CALL: case CALL:
call_body cbody; call_body cbody;
case REPLY: case REPLY:
reply_body rbody; reply_body rbody;
} body; } body;
}; };
Body of an RPC call: Body of an RPC call:
In version 2 of the RPC protocol specification, rpcvers must be equal In version 2 of the RPC protocol specification, rpcvers MUST be equal
to 2. The fields prog, vers, and proc specify the remote program, to 2. The fields prog, vers, and proc specify the remote program,
its version number, and the procedure within the remote program to be its version number, and the procedure within the remote program to be
called. After these fields are two authentication parameters: cred called. After these fields are two authentication parameters: cred
(authentication credential) and verf (authentication verifier). The (authentication credential) and verf (authentication verifier). The
two authentication parameters are followed by the parameters to the two authentication parameters are followed by the parameters to the
remote procedure, which are specified by the specific program remote procedure, which are specified by the specific program
protocol. protocol.
The purpose of the authentication verifier is to validate the The purpose of the authentication verifier is to validate the
authentication credential. Note that these two items are authentication credential. Note that these two items are
skipping to change at page 14, line 33 skipping to change at page 14, line 39
assignment as there is for program number assignment. The "flavor" assignment as there is for program number assignment. The "flavor"
of a credential or verifier refers to the value of the "flavor" field of a credential or verifier refers to the value of the "flavor" field
in the opaque_auth structure. Flavor numbers, like RPC program in the opaque_auth structure. Flavor numbers, like RPC program
numbers, are also administered centrally, and developers may assign numbers, are also administered centrally, and developers may assign
new flavor numbers by methods described in Appendix B. Credentials new flavor numbers by methods described in Appendix B. Credentials
and verifiers are represented as variable length opaque data (the and verifiers are represented as variable length opaque data (the
"body" field in the opaque_auth structure). "body" field in the opaque_auth structure).
In this document, two flavors of authentication are described. Of In this document, two flavors of authentication are described. Of
these, Null authentication (described in the next subsection) is these, Null authentication (described in the next subsection) is
mandatory - it must be available in all implementations. System mandatory - it MUST be available in all implementations. System
authentication (AUTH_SYS) is described in Appendix A. It is strongly authentication (AUTH_SYS) is described in Appendix A. Implementors
recommended that implementors include AUTH_SYS in their MAY include AUTH_SYS in their implementations to support existing
implementations to promote interoperability, since many applications applications. See "Security Considerations" for information about
make use of this flavor. See "Security Considerations" for other, more secure, authentication flavors.
information about other, more secure, authentication flavors.
10.1. Null Authentication 10.1. Null Authentication
Often calls must be made where the client does not care about its Often calls must be made where the client does not care about its
identity or the server does not care who the client is. In this identity or the server does not care who the client is. In this
case, the flavor of the RPC message's credential, verifier, and reply case, the flavor of the RPC message's credential, verifier, and reply
verifier is "AUTH_NONE". Opaque data associated with "AUTH_NONE" is verifier is "AUTH_NONE". Opaque data associated with "AUTH_NONE" is
undefined. It is recommended that the length of the opaque data be undefined. It is recommended that the length of the opaque data be
zero. zero.
skipping to change at page 15, line 26 skipping to change at page 15, line 31
length in bytes of the fragment's data. The boolean value is the length in bytes of the fragment's data. The boolean value is the
highest-order bit of the header; the length is the 31 low-order bits. highest-order bit of the header; the length is the 31 low-order bits.
(Note that this record specification is NOT in XDR standard form!) (Note that this record specification is NOT in XDR standard form!)
12. The RPC Language 12. The RPC Language
Just as there was a need to describe the XDR data-types in a formal Just as there was a need to describe the XDR data-types in a formal
language, there is also need to describe the procedures that operate language, there is also need to describe the procedures that operate
on these XDR data-types in a formal language as well. The RPC on these XDR data-types in a formal language as well. The RPC
Language is an extension to the XDR language, with the addition of Language is an extension to the XDR language, with the addition of
"program", "procedure", and "version" declarations. The following "program", "procedure", and "version" declarations. The keywords
example is used to describe the essence of the language. "program" and "version" are reserved in the RPC Language, and
implementations of XDR compilers MAY reserve these keywords even when
provided pure XDR, non-RPC, descriptions. The following example is
used to describe the essence of the language.
12.1. An Example Service Described in the RPC Language 12.1. An Example Service Described in the RPC Language
Here is an example of the specification of a simple ping program. Here is an example of the specification of a simple ping program.
program PING_PROG { program PING_PROG {
/* /*
* Latest and greatest version * Latest and greatest version
*/ */
version PING_VERS_PINGBACK { version PING_VERS_PINGBACK {
skipping to change at page 16, line 29 skipping to change at page 16, line 38
operation back to the client, and it returns the amount of time (in operation back to the client, and it returns the amount of time (in
microseconds) that the operation used. The next version, microseconds) that the operation used. The next version,
PING_VERS_ORIG, is the original version of the protocol and it does PING_VERS_ORIG, is the original version of the protocol and it does
not contain PINGPROC_PINGBACK procedure. It is useful for not contain PINGPROC_PINGBACK procedure. It is useful for
compatibility with old client programs, and as this program matures compatibility with old client programs, and as this program matures
it may be dropped from the protocol entirely. it may be dropped from the protocol entirely.
12.2. The RPC Language Specification 12.2. The RPC Language Specification
The RPC language is identical to the XDR language defined in RFC The RPC language is identical to the XDR language defined in RFC
1014, except for the added definition of a "program-def" described 4506, except for the added definition of a "program-def" described
below. below.
program-def: program-def:
"program" identifier "{" "program" identifier "{"
version-def version-def
version-def * version-def *
"}" "=" constant ";" "}" "=" constant ";"
version-def: version-def:
"version" identifier "{" "version" identifier "{"
skipping to change at page 17, line 31 skipping to change at page 17, line 38
o Only unsigned constants can be assigned to programs, versions o Only unsigned constants can be assigned to programs, versions
and procedures. and procedures.
o Current RPC language compilers do not generally support more o Current RPC language compilers do not generally support more
than one type-specifier in procedure argument lists; the usual than one type-specifier in procedure argument lists; the usual
practice is to wrap arguments into a structure. practice is to wrap arguments into a structure.
13. IANA Considerations 13. IANA Considerations
The assignment of RPC program numbers and authentication flavor The assignment of RPC program numbers and authentication flavor
numbers has in the past been performed by Sun Microsystems, Inc. numbers has in the past been performed by Sun Microsystems, Inc
This is inappropriate for an IETF standard protocol, as such work is (Sun). This is inappropriate for an IETF standards-track protocol,
done well by the Internet Assigned Numbers Authority (IANA). This as such work is done well by the Internet Assigned Numbers Authority
document proposes the transfer of authority over RPC program numbers (IANA). This document proposes the transfer of authority over RPC
and authentication flavor numbers described here from Sun program numbers and authentication flavor numbers described here from
Microsystems, Inc. to IANA and proposes how IANA will maintain and Sun Microsystems, Inc. to IANA and proposes how IANA will maintain
assign RPC program numbers and authentication flavor numbers. Users and assign RPC program numbers and authentication flavor numbers.
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 review this part of the document as well.
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.
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: the 32-bit number space as listed in Section 8.3. Detailed
information for the administration of the partitioned blocks in
0 Reserved Section 8.3. is given below.
1 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator
(see note1)
0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved
Detailed information for the administration of these blocks is given
below.
13.3.1. To be assigned by IANA 13.3.1. To be assigned by IANA
The first block will be administered by IANA, with previous The first block will be administered by IANA, with previous
assignments by Sun protected. Previous assignments were restricted assignments by Sun protected. Previous assignments were restricted
to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f), to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f),
therefore IANA should begin assignments at decimal 400000. therefore IANA should begin assignments at decimal 400000.
Individual numbers should be grated on a first-come, first-served Individual numbers should be grated on a first-come, first-served
basis, and blocks should be granted under rules related to the size basis, and blocks should be granted under rules related to the size
of the block. of the block.
skipping to change at page 18, line 48 skipping to change at page 18, line 49
administrative domain to use, in a similar manner to IP address administrative domain to use, in a similar manner to IP address
ranges reserved for private use. The expected use would be through ranges reserved for private use. The expected use would be through
the establishment of a local domain "authority" for assigning numbers the establishment of a local domain "authority" for assigning numbers
from this range. This authority would establish any policies or from this range. This authority would establish any policies or
procedures to be used within that local domain for use or assignment procedures to be used within that local domain for use or assignment
of RPC numbers from the range. The local domain should be of RPC numbers from the range. The local domain should be
sufficiently isolated that it would be unlikely that RPC applications sufficiently isolated that it would be unlikely that RPC applications
developed by other local domains could communicate with the domain. developed by other local domains could communicate with the domain.
This could result in RPC number contention, which would cause one of This could result in RPC number contention, which would cause one of
the applications to fail. In the absence of a local administrator, the applications to fail. In the absence of a local administrator,
this block can be utilized in a "Private Use" manner per [RFC2434]. this block can be utilized in a "Private Use" manner per [RFC5226].
13.3.3. Transient block 13.3.3. Transient block
The "Transient" block can be used by any RPC application on a "as The "Transient" block can be used by any RPC application on a "as
available" basis. This range is intended for services that can available" basis. This range is intended for services that can
communicate a dynamically selected RPC program number to clients of communicate a dynamically selected RPC program number to clients of
the service. Any mechanism can be used to communicate the number. the service. Any mechanism can be used to communicate the number.
Examples include shared memory when the client and server are located Examples include shared memory when the client and server are located
on the same system, or a network message (either RPC or otherwise) on the same system, or a network message (either RPC or otherwise)
that disseminates the selected number. that disseminates the selected number.
skipping to change at page 20, line 8 skipping to change at page 20, line 8
In these cases, the RPC protocol used with the various numbers may be In these cases, the RPC protocol used with the various numbers may be
different or the same. The numbers may be assigned dynamically by different or the same. The numbers may be assigned dynamically by
the application, or as part of a site-specific administrative the application, or as part of a site-specific administrative
decision. If possible, RPC services that dynamically assign RPC decision. If possible, RPC services that dynamically assign RPC
numbers should use the "Transient" RPC number block defined in numbers should use the "Transient" RPC number block defined in
section 2. If not possible, RPC number sub-blocks may be requested. section 2. If not possible, RPC number sub-blocks may be requested.
Assignment of RPC Number Sub-Blocks is controlled by the size of the Assignment of RPC Number Sub-Blocks is controlled by the size of the
sub-block being requested. "Specification Required" and "IESG sub-block being requested. "Specification Required" and "IESG
Approval" are used as defined by [RFC2434] Section 2. Approval" are used as defined by [RFC5226] Section 4.1.
Size of sub-block Assignment Method Authority Size of sub-block Assignment Method Authority
----------------- ----------------- --------- ----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG More than 1000 numbers IESG Approval required IESG
Note: sub-blocks can be any size. The limits given above are Note: sub-blocks can be any size. The limits given above are
maximums and smaller size sub-blocks are allowed. maximums and smaller size sub-blocks are allowed.
Sub-blocks sized up to 100 numbers may be assigned by IANA on a First Sub-blocks sized up to 100 numbers may be assigned by IANA on a First
skipping to change at page 20, line 33 skipping to change at page 20, line 33
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, however an Internet Draft must be submitted as an
Informational or Standards Track RFC. If accepted as either, IANA Informational or standards-track RFC. If accepted as either, IANA
will assign the requested number sub-block. 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
skipping to change at page 21, line 25 skipping to change at page 21, line 25
field of the "opaque_auth" structure. field of the "opaque_auth" structure.
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 as described in have been granted in the decimal range 390000-390255.
2.2.
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 to avoid conflicts with
currently granted numbers. currently granted numbers.
For authentication flavors to be used on the Internet, it is strongly For authentication flavors or RPCSEC_GSS mechanisms to be used on the
advised that an informational or standards-track RFC be published Internet, it is strongly advised that an informational or standards-
describing the authentication mechanism behaviour and parameters. track RFC be published describing the authentication mechanism
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. Use the lack of a verifier to permit the credential to be validated.
of AUTH_SYS is not recommended for services which permit clients to AUTH_SYS SHOULD NOT be used for services which permit clients to
modify data. modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or
REQUIRED for any standards-track RPC service.
[RFC2203] defines a new security flavor, RPCSEC_GSS, which permits [RFC2203] defines a new security flavor, RPCSEC_GSS, which permits
GSS-API [RFC2743] mechanisms to be used for securing RPC. All non- GSS-API [RFC2743] mechanisms to be used for securing RPC. All non-
trivial RPC programs developed in future should implement trivial RPC programs developed in future should implement
RPCSEC_GSS-based security appropriately. [RFC2623] describes how RPCSEC_GSS-based security appropriately. [RFC2623] describes how
this was done for a widely deployed RPC program. this was done for a widely deployed RPC program.
15. Appendix A: System Authentication 15. Appendix A: System Authentication
The client may wish to identify itself, for example, as it is The client may wish to identify itself, for example, as it is
skipping to change at page 26, line 11 skipping to change at page 26, line 11
Specification", RFC 1813, June 1995. Specification", RFC 1813, June 1995.
[RFC1831] [RFC1831]
R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995. Version 2", RFC 1831, August 1995.
[RFC1833] [RFC1833]
R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833, R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833,
August 1995. August 1995.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
[RFC2203] [RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification", Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification",
RFC 2203, September 1997 RFC 2203, September 1997
[RFC2434]
Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2623] [RFC2623]
Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS
Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2695]
Chiu, A., "Authentication Mechanisms for ONC RPC", RFC 2695,
September 1999.
[RFC2743] [RFC2743]
Linn. J., "Generic Security Service Application Program Interface Linn. J., "Generic Security Service Application Program Interface
Version 2, Update 1", RFC 2743, January 2000. Version 2, Update 1", RFC 2743, January 2000.
[RFC3530] [RFC3530]
Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C.,
Eisler, M., Noveck, D., "Network File System (NFS) version 4 Eisler, M., Noveck, D., "Network File System (NFS) version 4
Protocol", RFC 3530, April 2003. Protocol", RFC 3530, April 2003.
[RFC5226]
Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008.
22. Author's Address 22. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
nfsv4@ietf.org nfsv4@ietf.org
Robert Thurlow Robert Thurlow
Sun Microsystems, Inc. Sun Microsystems, Inc.
500 Eldorado Boulevard, UBRM05-171 500 Eldorado Boulevard, UBRM05-171
Broomfield, CO 80021 Broomfield, CO 80021
 End of changes. 31 change blocks. 
71 lines changed or deleted 78 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/