Binding Protocols for ONC RPC Version 2
updated by
- rfc-5665 — IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats
Extracted elements (26)
A well-known lookup service (RPCBIND/Port Mapper) is necessary because the range of well-known transport selectors is very small on some transports while the number of services is potentially very large, making static allocation impractical.
In RPCBIND version 4, RPCBPROC_CALLIT was renamed RPCBPROC_BCAST to make its intended use (broadcast RPC only) explicit, and RPCBPROC_INDIRECT was added as a separate procedure for unicast indirect calls that reports errors rather than being silent.
RPCBIND (versions 3 and 4) uses a transport-independent universal address format (an ASCII string) rather than raw port numbers, enabling the binding protocol to work over any transport, not just TCP/UDP. The Port Mapper (version 2) is retained for backward compatibility but is limited to TCP and UDP.
The network identifier (r_netid) is defined as a system-local string assigned by a system administrator, and cannot be depended upon to have the same value across different systems. This allows local flexibility while preserving universal address portability.
The Port Mapper (version 2) and RPCBIND (versions 3 and 4) all share the same RPC program number (100000) and port (111), but differ in address representation: Port Mapper uses raw TCP/UDP port numbers while RPCBIND uses transport-independent universal address strings.
Both RPCBIND (versions 3 and 4) and the Port Mapper (version 2) are contacted on well-known port 111 over TCP and UDP. Each transport supported by RPCBIND has its own assigned well-known address.
Only the owner of the service or the super-user is allowed to unset a service via RPCBPROC_UNSET. If r_netid is NULL, all mappings for (r_prog, r_vers, *) are deleted.
PMAPPROC_SET (Port Mapper) refuses to establish a mapping if one already exists for the tuple (prog, vers, prot). Returns TRUE on success, FALSE otherwise.
RPCBIND only accepts RPCBPROC_SET and RPCBPROC_UNSET requests from clients running on the same machine as the RPCBIND program. All other procedures can be called remotely.
RPCBPROC_CALLIT (v3) and RPCBPROC_BCAST (v4) only send a response if the remote procedure was successfully executed; they are silent (no response) on failure. This behavior is intentional for broadcast use.
RPCBPROC_GETADDR ignores the r_netid field of its argument; the network identifier is inferred from the transport on which the request arrived, not from the caller-supplied value.
RPCBPROC_SET refuses to establish a mapping if one already exists for the ordered set (r_prog, r_vers, r_netid). Neither r_netid nor r_addr can be NULL, and r_netid should be a valid network identifier on the registering machine.
The Port Mapper's PMAPPROC_CALLIT communicates with the remote program using UDP only, regardless of the transport on which the original request was received.
When a program becomes unavailable, it should unregister itself with RPCBIND (or Port Mapper) on the same machine by calling RPCBPROC_UNSET (or PMAPPROC_UNSET).
RPCBPROC_GETADDRLIST (RPCBIND version 4 only, procedure 11) returns a list of rpcb_entry items containing all addresses for a given service, allowing clients to discover alternate transports for reaching the same server.
RPCBPROC_GETSTAT (RPCBIND version 4, procedure 12) returns per-version statistics on RPCBIND activity, including call counts, success/failure breakdowns, and indirect-vs-broadcast distinctions, as an rpcb_stat_byvers array.
RPCBPROC_GETVERSADDR (RPCBIND version 4, procedure 9) is similar to RPCBPROC_GETADDR but uses the r_vers field to query a specific version; returns no address if that version is not registered.
RPCBPROC_INDIRECT (RPCBIND version 4, procedure 10) is similar to RPCBPROC_CALLIT but returns an error indication rather than being silent on failure. It is intended for indirect (unicast) RPC calls, not broadcast.
The Port Mapper program (program number 100000, version 2) maps RPC program and version numbers to TCP or UDP port numbers. Unlike RPCBIND, it is transport-specific and handles only TCP and UDP ports directly.
The RPCBIND program (program number 100000, versions 3 and 4) maps RPC program and version numbers to transport-independent universal addresses, enabling dynamic binding of remote programs over any transport. It listens on well-known port 111 for TCP and UDP.
The RFC explicitly states that security issues are not discussed in this memo. The only access control specified is that RPCBPROC_SET and RPCBPROC_UNSET are restricted to local clients, and that only the service owner or super-user may unset a registration.
Remote call arguments (rpcb_rmtcallargs) carry prog, vers, proc (all unsigned long), and args (opaque variable-length). Results (rpcb_rmtcallres) carry the remote universal address (string) and results (opaque variable-length).
The netbuf structure stores the transport-specific form of a universal transport address: maxlen (unsigned int) and buf (variable-length opaque). Used as input/output of RPCBPROC_UADDR2TADDR and RPCBPROC_TADDR2UADDR.
The Port Mapper mapping structure encodes: prog (unsigned int, program number), vers (unsigned int, version number), prot (unsigned int, protocol — IPPROTO_TCP=6 or IPPROTO_UDP=17), and port (unsigned int, port number).
The rpcb_entry structure provides a merged transport address plus netconfig metadata: r_maddr (string, merged address), r_nc_netid (string), r_nc_semantics (unsigned long: 1=CLTS, 2=COTS, 3=COTS_ORD, 4=RAW), r_nc_protofmly (string, protocol family), and r_nc_proto (string, protocol name).
The rpcb structure encodes an RPC service mapping: r_prog (unsigned long, program number), r_vers (unsigned long, version number), r_netid (variable-length string, network identifier), r_addr (variable-length string, universal address), and r_owner (variable-length string, service owner).