Summary

  • ONC RPC services could choose transport ports dynamically; RFC 1057’s portmapper gave clients a fixed place to look up the selected port.
  • The registration connected a program number, version and transport to a port on one machine. It was a directory answer, not proof of service health or identity.

The address was stable; the service port was not

Imagine an administrator restarting a machine’s file service. The server process can bind to an available port rather than reserve a globally coordinated number. But a client that knows only the host address and RPC program still has a practical problem: where should its call go? If every service had to use a fixed, globally assigned port, the small port space would become a scarce namespace for a potentially large and changing set of programs.

RFC 1057, published by Sun Microsystems in June 1988, documented a different arrangement. The RPC program number and version described what the client wanted; TCP or UDP identified the transport. A local portmapper, listening at the well-known port 111, connected those identifiers to the server’s chosen transport port. The client first asked the mapper, then contacted the service. The call protocol and the binding lookup were separate steps.

The specification describes PMAPPROC_SET as the service’s registration operation. A server supplied its program number, version, transport protocol and port to the mapper on the same machine. The mapper refused a duplicate mapping for the same program, version and protocol tuple. When the service ended, PMAPPROC_UNSET was the corresponding removal operation. A client used PMAPPROC_GETPORT; a zero result meant that no mapping was registered for the requested tuple.

This was a compact division of responsibility. A service chose where it could listen; the mapper exposed that choice through a predictable rendezvous; the client used the returned port to reach the service. The endpoint was dynamic, while the lookup point remained conventional.

What the answer established

The mapper’s answer was narrow. It reported a registration in a host-local table. RFC 1057 did not make GETPORT an end-to-end health check, a proof that a network path was open, or a cryptographic statement about which program occupied the port. A client still had to make the RPC call and interpret its result. If the service had stopped but its mapping remained, discovery could succeed while the later connection failed. If the mapping disappeared, the client had to handle that outcome as a service-binding failure.

The distinction matters because “found” can sound stronger than “listed.” A port number says where a service was registered to listen at that moment. It does not say that packets can reach it, that the listener will accept this client, or that it will complete the requested procedure. RFC 1057 separately discusses authentication and transport semantics; the portmapper itself was not a substitute for them.

The table also belonged to the machine that ran the service. It was not a global registry of all RPC programs. Clients needed the host’s network address from some other source, then asked that host’s mapper for the transport port. The system therefore split discovery across layers: name or configuration supplied the host, the RPC program number and version selected the interface, and portmapper supplied the transport endpoint.

RFC 1057 included more than lookup. PMAPPROC_DUMP returned the mapper’s entries. PMAPPROC_CALLIT supported broadcast calls: a client sent a request to the well-known mapper port at a broadcast address, and each mapper that received it could invoke the locally registered program. The RFC specified that the mapper returned a reply only if the call executed successfully; otherwise it stayed silent. That behavior made the fixed rendezvous useful where service ports differed by machine, but it did not turn broadcast into a guaranteed delivery or a complete inventory of responders.

The program-number ranges supplied another coordination boundary. RFC 1057 divided numbers among Sun-defined, user-defined, transient and reserved blocks. That allocation kept a service’s logical program identifier distinct from its changing transport port. One number named the RPC program; another value, resolved locally, named where the current instance listened.

Binding grew beyond TCP and UDP

The original mapper protocol was tied to TCP and UDP port numbers. RFC 1833, published in 1995, documented port-mapper version 2 alongside RPCBIND versions 3 and 4. It explained the same pressure: a server might choose a transport address dynamically, while clients needed a fixed lookup service at the server’s address. The newer RPCBIND versions represented transport addresses as universal-address strings and included a network identifier, broadening binding beyond the original TCP/UDP port mapping.

That later document helps clarify the boundary of the 1988 design. RFC 1057 did not make the RPC program itself dependent on a single transport port. It introduced a rendezvous convention that could map the service’s program and version onto a transport-specific listener. Later binding formats generalized the address representation, while the separation between RPC message protocol and service rendezvous remained visible. RFC 5531’s later specification explicitly describes binding and rendezvous as independent from the RPC message protocol.

The design’s useful claim was therefore modest: clients need not know a service’s port in advance if the server and client share a lookup convention. That arrangement saved scarce fixed ports and allowed service instances to select ports locally. Its cost was a dependency on a second conversation before the call, plus operational state that had to track service start, registration, shutdown and removal.

The RFCs record protocol design, not a census of historical deployments or measured reliability. They do not show how often stale registrations occurred or how quickly particular systems repaired them. The safe conclusion is about architecture: portmapper made an RPC endpoint discoverable through a stable local rendezvous, but left reachability, authentication and successful execution to later steps.

A directory answer is a starting point

The portmapper is easy to mistake for a small detail in a remote-call protocol. It exposed a deeper design choice: service identity and transport location change at different rates. Program number and version describe the interface a client seeks; a transport port describes where one server process currently accepts traffic. By separating them, RFC 1057 allowed the listener to move without changing the service’s logical name.

That flexibility does not eliminate coordination. It moves coordination into registration and lookup. Operators must keep the mapping aligned with the running process; clients must treat the answer as a locator and still test the actual call. The portmapper made the endpoint movable, not self-validating.

Primary documents: RFC 1057 — RPC Version 2; RFC 1833 — Binding Protocols for ONC RPC; RFC 5531 — ONC RPC Version 2.