INTERNET-DRAFT M. Rosenau Expires: July 25, 2008 January 25, 2008 Category: Experimental DYNAMIC RPC NUMBER ASSIGNMENT AND DISTRIBUTION Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Rosenau Dynamic RPC number assignment [Page 1] Abstract The RPC port mapper described in [1] and [2] allows a service to bind to any free TCP or UDP port. A client that wants to establish a connection to a server will ask the RPC portmapper for the TCP or UDP port of the service and establish the connection. The problem is that clients now need to know the RPC application number of the service they want to connect to. These numbers are assigned by the IANA for registered applications. For "experimental" applications there is a range of application numbers that is managed by the local network's administrator. Especially when using such "experimental" applications in wide area networks there is the problem that the client needs to know the server application's RPC application number. The protocol described in this document allows a server host the dynamical assigning of RPC numbers. It allows clients to ask the server for for RPC number by the application name. Rosenau Dynamic RPC number assignment [Page 2] 1. INTRODUCTION The UDP and TCP port numbers for services is very limited. Therefore it is not possible to assign a unique port to every service (such as port 80 for HTTP) that has the same value on all hosts in the internet. The resulting problem is that a client that wants to connect to a server must know the UDP or TCP port number of the service desired. The RPC port mapper described in [1] and [2] was introduced to solve this problem. This works well for services and applications that have a fixed application number assigned by the IANA. For "experimental" applications this is not the case. For these applications the local network administrator assigns a number in the range between 0x20000000 and 0x3FFFFFFF. This solution has two drawbacks: * The local network administrator must care for the RPC numbers. This means more effort for the network administrator. * When using applications between local networks (e.g. over the internet) the client must know the RPC number assigned in the server's network. This document that describes a service and a protocol that allows the automatic assignment of RPC numbers to applications and services. It allows a client to query for the RPC number and the TCP or UDP port number by the application name. Rosenau Dynamic RPC number assignment [Page 3] 2. PROTOCOL The protocol described in this document is based on RPC. The following procedures are defined (in RPC language): struct asgstruc { unsigned int udpport; unsigned int tcpport; unsigned int vers; bool rpcproto; string appname<>; }; struct infostruc { unsigned int prog; unsigned int udpport; unsigned int tcpport; unsigned int vers; bool rpcproto; }; struct regstruc { infostruc info; string appname<>; }; program NMPMAP_PROG { version NMPMAP_VERS { void NMPMAPPROC_NULL(void) = 0; infostruc NMPMAPPROC_QUERY(string<>) = ; string<> NMPMAPPROC_QUERYID(unsigned int) = ; unsigned int NMPMAPPROC_ASSIGN(asgstruc) = ; bool NMPMAPPROC_REGISTER(regstruc) = ; bool NMPMAPPROC_UNSET(string<>) = ; } = ; } = ; Rosenau Dynamic RPC number assignment [Page 4] NMPMAPPROC_NULL: This is just a dummy procedure doing nothing. NMPMAPPROC_QUERY: This procedure takes the name of a service as argument. It returns the "infostruc" for this RPC service. The "infostruc" structure contains the following elements: prog: The RPC application number of the program. udpport: The UDP port number; 0 if no UDP port is used. tcpport: The TCP port number; 0 if no TCP port is used. vers: The program version number. rpcproto: True if the program uses an RPC-based protocol (e.g. NFS) False if the program uses different protocols (e.g. HTTP) The procedure is intended for applications that dynamically register their RPC numbers but it should also work with appliction names from configuration files. This means a query for "portmapper" should return {prog=100000, udpport=111 and tcpport=111}. NMPMAPPROC_QUERYID: This procedure takes an RPC application number as argument. It returns the application name of the application assigned to the RPC program number. The procedure is intended for applications that dynamically register their RPC numbers but it should also work with "static" appliction names. This means a query for 100000 should return "portmapper". Rosenau Dynamic RPC number assignment [Page 5] NMPMAPPROC_ASSIGN: This procedure can only be called by clients that are allowed to register RPC applications (portmapper function PMAPPROC_SET). Typically these are applications running on the local machine. The argument is a "asgstruc" structure that contains the application name (appname) and most fields of the "infostruc" structure described above describing the calling application. The procedure automatically assigns an RPC number from a pool of free RPC numbers to the calling application. Then it calls the port mapper's PMAPPROC_SET procedure. The procedure returns the RPC program number assigned if PMAPPROC_SET succeeded. It returns 0 if assigning or PMAPPROC_SET failed. NMPMAPPROC_REGISTER: This procedure is called to assign an already known program number to an application name. The argument is a "regstruc" structure that contains all information about the application. The calling application must already have called PMAPPROC_SET. Only applications that are allowed to call PMAPPROC_SET are allowed to call this procedure. The procedure returns true on success. NMPMAPPROC_UNSET: This procedure removes an entry registered by NMPMAPPROC_ASSIGN or NMPMAPPROC_REGISTER. The procedure does not call the port mapper's PMAPPROC_UNSET function; this must be done by the calling application after calling this function. Only applications that are allowed to call PMAPPROC_UNSET are allowed to call this procedure. The procedure returns true on success. Rosenau Dynamic RPC number assignment [Page 6] 3. APPLICATION NAMES Applications mentioned in configuration files like /etc/rpc should use the name used there. Example: portmapper Application names managed by a domain name's owner use the application name followed by a dot and the domain name. Example: myapplication.subdomain.anywhere.com Application names managed by people not owning a domain must not use dots in the application name. They use the application name followed by a dot and the e-mail address. Example: myapplication.my-address@anywhere.com REFERENCES [1] THE RPC PROTOCOL, RFC 1050 [2] THE RPC PROTOCOL, Version 2, RFC 1057 AUTHOR Martin Rosenau Johannes Schuster Weg 14 76185 Karlsruhe Germany Email: martin a t rosenau-ka.de Rosenau Dynamic RPC number assignment [Page 7] Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. 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. Rosenau Dynamic RPC number assignment [Page 8]