Connected: An Internet Encyclopedia
RFC 1700 - sun-rpc-numbers

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

Search: |  | Search Depth: |
Search Type: | String RegEx | Search Options: | NoCase WholeWord

    SUN RPC NUMBERS

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

    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
    services.

    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.
    	else
    		allocate the next available port in the non-reserved
    		range.

    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
RFC 1700 - sun-rpc-numbers