[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                     Robert Thurlow
Internet Draft                                            February 2005
Document: draft-ietf-nfsv4-rpc-iana-03.txt



                RPC Numbering Authority Transfer to IANA



Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 August, 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: August 2005                                            [Page 1]


Title           RPC Numbering Authority Transfer to IANA   February 2005


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.  Security Considerations  . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . .  10
   6.  Full Copyright Statement . . . . . . . . . . . . . . . . .  10
   7.  Intellectual property  . . . . . . . . . . . . . . . . . .  10
   8.  Bibliography . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Author's Address . . . . . . . . . . . . . . . . . . . . .  13
























Expires: August 2005                                            [Page 2]


Title           RPC Numbering Authority Transfer to IANA   February 2005


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: August 2005                                            [Page 3]


Title           RPC Numbering Authority Transfer to IANA   February 2005


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: August 2005                                            [Page 4]


Title           RPC Numbering Authority Transfer to IANA   February 2005


   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: August 2005                                            [Page 5]


Title           RPC Numbering Authority Transfer to IANA   February 2005


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: August 2005                                            [Page 6]


Title           RPC Numbering Authority Transfer to IANA   February 2005


   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: August 2005                                            [Page 7]


Title           RPC Numbering Authority Transfer to IANA   February 2005


   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: August 2005                                            [Page 8]


Title           RPC Numbering Authority Transfer to IANA   February 2005


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: August 2005                                            [Page 9]


Title           RPC Numbering Authority Transfer to IANA   February 2005


4.  Security Considerations

   This document has no impact on RPC security; please see [RFC1831bis]
   and [RFC2623] for information about ROC security.

5.  IANA Considerations

   This entire document discusses a transition of a numbering service to
   IANA, so this section needs nothing further.

6.  Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

7.  Intellectual property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.




Expires: August 2005                                           [Page 10]


Title           RPC Numbering Authority Transfer to IANA   February 2005


8.  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: August 2005                                           [Page 11]


Title           RPC Numbering Authority Transfer to IANA   February 2005


   [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-05.txt, February 2005.






































Expires: August 2005                                           [Page 12]


Title           RPC Numbering Authority Transfer to IANA   February 2005


9.  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: August 2005                                           [Page 13]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/