One document matched: draft-ietf-nfsv4-rpc-iana-01.txt
Differences from draft-ietf-nfsv4-rpc-iana-00.txt
Network Working Group Robert Thurlow
Internet Draft May 2004
Document: draft-ietf-nfsv4-rpc-iana-01.txt
RPC Numbering Authority Transfer to IANA
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Discussion and suggestions for improvement are requested. This
document will expire in October, 2003. Distribution of this draft is
unlimited.
Abstract
Network services based on RPC [RFC1831] use program numbers rather
than well known transport ports to permit clients to find them, and
use authentication flavor numbers to define the format of the
authentication data passed. The assignment of RPC program numbers
and authentication flavor numbers is still performed by Sun
Microsystems, Inc. This is inappropriate for an IETF standard
protocol, as such work is done well by the Internet Assigned Numbers
Authority (IANA). This document defines how IANA will maintain and
assign RPC program numbers and authentication flavor numbers.
Expires: November 2004 [Page 1]
Title RPC Numbering Authority Transfer to IANA May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Past Sun Assignment Practice . . . . . . . . . . . . . . . . 3
2.1. RPC Program Numbers . . . . . . . . . . . . . . . . . . . 3
2.1.1. RPC Program Number Assignments . . . . . . . . . . . . . 3
2.1.2. RPC Program Protocol Definitions . . . . . . . . . . . . 4
2.1.3. RPC Program Numbers Actually Assigned . . . . . . . . . 4
2.2. RPC Authentication Flavor Numbers . . . . . . . . . . . . 4
3. Proposed IANA Assignment Practice . . . . . . . . . . . . . 4
3.1. Protecting Past Assignments . . . . . . . . . . . . . . . 4
3.2. RPC Number Assignment . . . . . . . . . . . . . . . . . . 5
3.2.1. To be assigned by IANA . . . . . . . . . . . . . . . . . 5
3.2.2. Defined by local administrator . . . . . . . . . . . . . 5
3.2.3. Transient block . . . . . . . . . . . . . . . . . . . . 6
3.2.4. Reserved block . . . . . . . . . . . . . . . . . . . . . 6
3.2.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 6
3.2.6. Information Necessary To Grant RPC Program Numbers . . . 8
3.3. RPC Authentication Flavor Number Assignment . . . . . . . 9
3.3.1. Information Necessary To Grant RPC Authentication Flavor
Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 10
5. Author's Address . . . . . . . . . . . . . . . . . . . . . 12
Expires: November 2004 [Page 2]
Title RPC Numbering Authority Transfer to IANA May 2004
1. Introduction
This procedure will explain how RPC number assignments have been made
in the past and how they should be made in the future in order to
transfer the authority for assigning RPC program and authentication
flavor numbers from Sun Microsystems to IANA (the Internet Assigned
Number Authority). Users of RPC protocols will benefit by having an
independent body responsible for RPC number assignments.
2. Past Sun Assignment Practice
The administrator for these numbers was previously Sun Microsystems,
Inc. Requests for number assignments were sent to "rpc@sun.com" as
described in [RFC1831]. This section details the rules Sun used to
grant numbers.
2.1. RPC Program Numbers
Each application that uses RPC will typically require at least one
RPC program number. Because of this, there are hundreds of program
numbers assigned, some in delegated "blocks".
2.1.1. RPC Program Number Assignments
The program number is a 32-bit field partitioned into several blocks,
as defined by [RFC1831] paragraph 7.3. The table from the RFC is
shown in hexadecimal:
0 - 0x1fffffff defined by rpc@sun.com
0x20000000 - 0x3fffffff defined by user
0x40000000 - 0x5fffffff transient
0x60000000 - 0x7fffffff reserved
0x80000000 - 0x9fffffff reserved
0xa0000000 - 0xbfffffff reserved
0xc0000000 - 0xdfffffff reserved
0xe0000000 - 0xffffffff reserved
The "defined by user" block was not managed by Sun, but was intended
for controlled use by local administrative domains in a manner
similar to the "Defined by local administrator" block proposed in
Section 3.2.2. The "transient" block was intended to be used
dynamically by applications which prearranged a particular program
number and used it only while the application was in use. This is
similar to the "Transient" block proposed in Section 3.2.3.
Expires: November 2004 [Page 3]
Title RPC Numbering Authority Transfer to IANA May 2004
2.1.2. RPC Program Protocol Definitions
Sun Microsystems, Inc.'s former policy was to ask for RPC protocol
definitions in XDR definition language [RFC1833]. This information
was not useful, and was in some cases proprietary. Sun will not
transfer such definitions to IANA; the choice to publish such
protocols is left to the owner of the protocol.
2.1.3. RPC Program Numbers Actually Assigned
Prior to the assumption of RPC program number assignment
responsibilities by IANA, Sun Microsystems, Inc. assigned individual
and small groups of RPC numbers only within the range of 100000 to
399999, decimal. A small number of large blocks was also granted.
In hexadecimal format, these assigned blocks are:
0x20010000 - 0x2001ffff
0x20020000 - 0x2002ffff
0x20020000 - 0x20020007
0x20030000 - 0x2003ffff
0x20040000 - 0x2004ffff
0x7f000000 - 0x7fffffff
2.2. RPC Authentication Flavor Numbers
In contrast to the case with RPC program numbers, RPC authentication
flavor numbers are assigned only when a new authentication method is
developed, which is rare. Standards which define or discuss
authentication flavors include [RFC1057], [RFC1831], [RFC2203],
[RFC2623] and [RFC2695]. Since less than 20 authentication flavor
numbers plus two number blocks have been granted, it has not been
necessary to formally subdivide the 32-bit range. Individual
assignments are within the decimal range 0-300002. One of the
granted blocks is held by a group within Sun Microsystems, Inc. to
allocate 'pseudo-flavors' for use with RPCSEC_GSS; this decimal range
390000-390255 will be relinquished to IANA for further assignments
for the same purpose.
3. Proposed IANA Assignment Practice
3.1. Protecting Past Assignments
Sun has made assignments in both number spaces since the original
deployment of RPC. The assignments made by Sun Microsystems are
still valid, and existing holders of number assignments from this
range do not need to reapply for numbers. The conventions and
procedures for future assignments must account for the protection of
Expires: November 2004 [Page 4]
Title RPC Numbering Authority Transfer to IANA May 2004
these numbers. Sun will communicate all current assignments in both
number spaces to IANA before final handoff of number assignment is
done.
3.2. RPC Number Assignment
Future IANA practice should deal with the following partitioning of
the 32-bit number space:
0 Reserved
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.
3.2.1. To be assigned by IANA
The first block will be administered by IANA, with previous
assignments by Sun protected. Previous assignments were restricted
to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f),
therefore IANA should begin assignments at decimal 400000.
Individual numbers should be grated on a first-come, first-served
basis, and blocks should be granted under rules related to the size
of the block.
3.2.2. Defined by local administrator
The "Defined by local administrator" block is available for any local
administrative domain to use, in a similar manner to IP address
ranges reserved for private use. The expected use would be through
the establishment of a local domain "authority" for assigning numbers
from this range. This authority would establish any policies or
procedures to be used within that local domain for use or assignment
of RPC numbers from the range. The local domain should be
sufficiently isolated that it would be unlikely that RPC applications
developed by other local domains could communicate with the domain.
This could result in RPC number contention, which would cause one of
the applications to fail. In the absence of a local administrator,
this block can be utilized in a "Private Use" manner per [RFC2434].
Note1: Sun delegated a small number of large RPC blocks in this
range; see Section 2.1.3.
Expires: November 2004 [Page 5]
Title RPC Numbering Authority Transfer to IANA May 2004
3.2.3. Transient block
The "Transient" block can be used by any RPC application on a "as
available" basis. This range is intended for services that can
communicate a dynamically selected RPC program number to clients of
the service. Any mechanism can be used to communicate the number.
Examples include shared memory when the client and server are located
on the same system, or a network message (either RPC or otherwise)
that disseminates the selected number.
The transient block is not administered. An RPC service uses this
range by selecting a number in the transient range and attempting to
register that number with the local system's RPC bindery (see the
RPCBPROC_SET or PMAPPROC_SET procedures in "Binding Protocols for ONC
RPC", [RFC1833]). If successful, no other RPC service was using that
number and the RPC Bindery has assigned that number to the requesting
RPC application. The registration is valid until the RPC Bindery
terminates, which normally would only happen if the system reboots
causing all applications, including the RPC service using the
transient number, to terminate. If the transient number registration
fails, another RPC application is using the number and the requestor
must select another number and try again. To avoid conflicts, the
recommended method is to select a number randomly from the transient
range.
3.2.4. Reserved block
The "Reserved" blocks are available for future use. RPC applications
must not use numbers in these ranges unless their use is allowed by
future action by the IESG.
3.2.5. RPC Number Sub-Blocks
RPC numbers are usually assigned for specific RPC services. Some
applications, however, require multiple RPC numbers for a service.
The most common example is an RPC service that needs to have multiple
instances of the service active simultaneously at a specific site.
RPC does not have an "instance identifier" in the protocol, so either
a mechanism must be implemented to multiplex RPC requests amongst
various instances of the service, or unique RPC numbers must be used
by each instance.
In these cases, the RPC protocol used with the various numbers may be
different or the same. The numbers may be assigned dynamically by
the application, or as part of a site-specific administrative
decision. If possible, RPC services that dynamically assign RPC
numbers should use the "Transient" RPC number block defined in
Expires: November 2004 [Page 6]
Title RPC Numbering Authority Transfer to IANA May 2004
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
sub-block being requested. "Specification Required" and "IESG
Approval" are used as defined by [RFC2434] Section 2.
Size of sub-block Assignment Method Authority
----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG
Note: sub-blocks can be any size. The limits given above are
maximums and smaller size sub-blocks are allowed.
Sub-blocks sized up to 100 numbers may be assigned by IANA on a First
Come First Served basis. The RPC Service Description included in the
range must include an indication of how the sub-block is managed. At
minimum, the statement should indicate whether the sub-block is used
with a single RPC protocol or multiple RPC protocols, and whether the
numbers are dynamically assigned or statically (through
administrative action) assigned.
Sub-blocks of up to 1000 numbers must be documented in detail. The
documentation must describe the RPC protocol or protocols that are to
be used in the range. It must also describe how the numbers within
the sub-block are to be assigned or used.
Sub-blocks sized over 1000 numbers must be documented as described
above, however an Internet Draft must be submitted as an
Informational or Standards Track RFC. If accepted as either, IANA
will assign the requested number sub-block.
In order to avoid multiple requests of large blocks of numbers the
following rule is proposed.
Requests up to and including 100 RPC numbers are handled via the
First Come First Served assignment method. This 100 number
threshhold applies to the total number of RPC numbers assigned to an
individual or entity. For example, if an individual or entity first
requests say 70 numbers, and then later requests 40 numbers, then the
request for the 40 numbers will be assigned via the Specification
Required method. As long as the total number of numbers assigned
does not exceed 1000, IANA is free to waive the Specification
Required assignment for incremental requests of less than 100
numbers.
If an individual or entity has under 1000 numbers and later requests
Expires: November 2004 [Page 7]
Title RPC Numbering Authority Transfer to IANA May 2004
an additional set of numbers such that the individual or entity would
over 1000 numbers, then the individual or entity will have the
additional request submitted to the IESG. IESG is free to waive the
IESG Action Required assignment method for incremental requests of
less than 1000 numbers.
3.2.6. Information Necessary To Grant RPC Program Numbers
[RFC1831bis] describes how users request new RPC program numbers. If
changes are made to that procedure, IANA should continue to request
the following information:
o Name of person or company which will use the number
o An "identifier string" which associates the number with a
service
o Email address of the contact person for the RPC service which
will be using the number.
o A short description of the purpose of the RPC service
This information is needed to associate the RPC number with an RPC
service, and in turn to associate an RPC service with the company or
person who originated the RPC service. This information may be
necessary for network administrators to manage their networks or
firewalls. Network administrators who observe RPC transactions on
their network may need to contact the company or person who created
or deployed the service to understand the application's behavior.
This may happen if the service is thought to be operating improperly,
or if its operation is having an impact on the local network.
In most cases, interested parties only need to know the name of the
RPC service using the number. IANA will make this list available
through publication or other means to allow for lookup of RPC
services by RPC number. To be effective, this requires that the
"identifier string" be meaningful. The string should clearly
identify the RPC service or application with which the RPC number is
to be associated. Sites supporting RPC services typically publish a
mapping of RPC numbers to RPC identifiers. For example, UNIX systems
publish this mapping in the file "/etc/rpc".
Expires: November 2004 [Page 8]
Title RPC Numbering Authority Transfer to IANA May 2004
3.3. RPC Authentication Flavor Number Assignment
The second number space is the authentication mechanism identifier,
or "flavor", number. This number is used to distinguish between
various authentication mechanisms which can be optionally used with
an RPC message. An authentication identifier is used in the "flavor"
field of the "opaque_auth" structure.
Recent progress in RPC security has focused on using the existing
RPCSEC_GSS flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3010]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255 as described in
2.2.
For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 to avoid conflicts with
currently granted numbers.
3.3.1. Information Necessary To Grant RPC Authentication Flavor Numbers
[RFC1831bis] describes how users request new RPC Authentication
Flavor numbers. If changes are made to that procedure, IANA should
continue to request the following information:
o Name of person or company which will use the number
o An "identifier string" which associates the number with a
service
o Email address of the contact person for the RPC service which
will be using the number.
o A description of the authentication flavor.
o If the authentication flavor is a 'pseudo-flavor' intended for
use with RPCSEC_GSS and NFS, mappings analogous to those in
Section 4.2 of [RFC2623] are required.
For authentication flavors to be used on the Internet, it is strongly
advised that an informational or standards-track RFC be published
describing the authentication mechanism behaviour and parameters.
Expires: November 2004 [Page 9]
Title RPC Numbering Authority Transfer to IANA May 2004
4. Bibliography
[RFC1057]
Sun Microsystems Inc., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1057, August 1995.
[RFC1831]
R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995.
[RFC1832]
R. Srinivasan, "XDR: External Data Representation Standard", RFC
1832, August 1995.
[RFC1833]
R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833,
August 1995.
[RFC2203]
M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol Specification", RFC
2203, September 1997.
[RFC2434]
T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2623]
M. Eisler, "NFS Version 2 and Version 3 Security Issues and the NFS
Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2695]
A. Chiu, "Authentication Mechanisms for ONC RPC", RFC 2695, September
1999.
[RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC 1094, March 1989.
Expires: November 2004 [Page 10]
Title RPC Numbering Authority Transfer to IANA May 2004
[RFC1813]
B. Callaghan, B. Pawlowski. P. Staubach, "NFS Version 3 Protocol
Specification", RFC 1813, June 1995.
[RFC3010]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.
[RFC1831bis]
R. Thurlow, "RPC: Remote Procedure Call Protocol Specification
Version 2", draft-ietf-nfsv4-rfc1831bis-02.txt, May 2004.
Expires: November 2004 [Page 11]
Title RPC Numbering Authority Transfer to IANA May 2004
5. Author's Address
Address comments related to this memorandum to:
nfsv4-wg@sunroof.eng.sun.com
Robert Thurlow
Sun Microsystems, Inc.
500 Eldorado Boulevard, UBRM05-171
Broomfield, CO 80021
Phone: 877-718-3419
E-mail: robert.thurlow@sun.com
Expires: November 2004 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-19 10:37:25 |