Network Working Group Robert Thurlow Internet Draft September 2004 Document: draft-ietf-nfsv4-rpc-iana-02.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 March, 2005. 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: March 2005 [Page 1] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 2] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 3] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 4] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 5] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 6] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 7] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 8] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 9] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 10] Title RPC Numbering Authority Transfer to IANA September 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-04.txt, March 2005. Expires: March 2005 [Page 11] Title RPC Numbering Authority Transfer to IANA September 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: March 2005 [Page 12]