Connected: An Internet Encyclopedia
Sun RPC Numbers

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1700

Sun RPC Numbers


To obtain SUN Remote Procedure Call (RPC) numbers send an e-mail
request to "".

The RPC port management service ('portmap' in SunOS versions less than
5.0 and 'rpcbind' in SunOS versions greater than 5.0) "registers" the
IP port number that is allocated to a particular service when that
service is created. It does not allocate ports on behalf of those

For an exact specification of the semantics refer to the source code
of svcudp_create() and svctcp_create() in the archives.  In short
however is that these interfaces, and svc_tli_create their Transport
Independent RPC equivalent, take either a user specified port number
or RPC_ANY (-1) which effectively means "I don't care."  In the "I
don't care" case the create code simply calls socket(2) or t_open(3n)
which allocates an IP port based on the rules:

	if euid of the requesting process is 0 (i.e., root)
		allocate the next available port number in the
		reserved port range.
		allocate the next available port in the non-reserved

Port numbers count up sequentially.

Can a port that is "assigned" can be used when the assignee's service
is not present?  Say port 501 is assigned to the "jeans" service.  On
a machine that does not have the "jeans" service, nor has any clients
that might be expecting to use it, is port 501 available for other
uses?  Any dynamic allocation process, like the portmapper, that
chooses the next unused port might allocate port 501 dynamically to a
process that asked for a "I don't care" port.  So any dynamic
allocation scheme may pick an unused port that happened to correspond
to a port number that had been "assigned" but was currently unused.

While it might be desirable, it is impossible to guarantee that any
unused port, even though officially assigned to a service, is not
picked by a dynamic allocator since such an assignment might occur
long after the delivery of the system into a site that doesn't watch
for the latest list.

There is the restriction that only "superuser" on BSD derived systems
such as SunOS can bind to a port number that is less than 1024.  So
programs have used this information in the past to identify whether or
not the service they were talking to was started by the superuser on
the remote system.  Making this assumption is dangerous because not
all system enforce this restriction.

Sun RPC services use ports that are currently unused.  If someone
noted that an RPC service was using port 781, it would be just as
happy using port 891, or 951.  The service doesn't care what port it
gets, remote clients will query the portmapper to ask it what port
number was assigned to the service when it was started.  The key is
that the port was not currently in use.  The only port that ONC/RPC
must have is 111 its assigned port for the portmap service.

The most common complaint comes when people put a new service on their
system.  When they configure their systems they put the new service
configuration commands at the end of their system startup scripts.
During startup, several network services may be started. Those
services that are ONC/RPC based just pick the next available port,
those that have pre-assigned ports bind to their pre-assigned port.
Clearly the correct sequence is to have all services that need a
particular port to be started first (or if they are "latent" services
that are started by inetd, to have inetd started).  Finally, the RPC
services should be started as they will be assigned unused ports. (In
the BSD networking code (which we use) the algorithm for picking
ports is in the file in_pcb.c, function in_pcbbind().)

Services should be started in this order:

   a) Services that will "run" continuously and have an assigned
      port. Note that this includes rpcbind (nee portmap) that has
      port 111 assigned to it.

   b) inetd - which will automatically create sockets for those
      services that have reserved ports but only run on demand
      (like finger)

   c) RPC services - which will automatically pick unused ports and
      maximize efficiency of the "IP Port" namespace.

The include file /usr/include/netinet/in.h defines a constant
IPPORT_RESERVED to be 1024.  The relevant text is:
    * Ports < IPPORT_RESERVED are reserved for
    * privileged processes (e.g. root).
    * Ports > IPPORT_USERRESERVED are reserved
    * for servers, not necessarily privileged.
   #define IPPORT_RESERVED         1024
   #define IPPORT_USERRESERVED     5000
Portmap does not allocate ports, the kernel allocates ports.  The code
that does this is part of nearly every UNIX system in the world (and
since the BSD code is 'free' it is often the same code).  RPC services
ask the kernel to allocate them a port by calling the "bind()" system
call.  The parameter they pass is "INADDR_ANY" which means "allocate
me any IP port you want".  The kernel does that by looking at all of
the ports that are currently in use and picking one that is not
currently used.  The number picked is either less that 1024 if the
process is privledged, or greater than 1024 if the process is not
privledged.  After the kernel has allocated a port, the service
registers this allocation with portmap.  The portmapper is merely a
registry of previously allocated ports.  Note "allocated" here is
being used in the sense that they are used by an open socket, not
assigned a well known name.

The role of /etc/services is to provide an idea to people who are
looking at network traffic as to where a packet may have originated
from or is headed to.  For services like finger that have assigned
ports, they can just hard code the port they want into their
executable. (it isn't like it will change, and if they read it from
/etc/services and someone had mistyped the port number it won't
interoperate with clients anyway!)

It is not practical to read the /etc/services file into the kernel to
prevent it from giving out port numbers that are "pre-assigned", nor
is it generally desirable since with the correct ordering of startup
it is completely unneccesary.

Editors Note: This information was supplied by Chuck McManis of Sun.


Connected: An Internet Encyclopedia
Sun RPC Numbers