RPC: Remote Procedure Call Protocol Specification Version 2
obsoleted by
- rfc-5531 — RPC: Remote Procedure Call Protocol Specification Version 2
Extracted elements (30)
AUTH_SHORT is provided so that servers can issue a compact shorthand credential in the reply verifier, allowing clients to reduce network bandwidth and server CPU cycles on subsequent calls in place of the full AUTH_SYS credential.
Binding a client to a particular service and transport parameters is explicitly excluded from the RPC protocol specification, left to higher-level software, analogous to the role of a loader/linker relative to a JSR instruction.
Record marking (RM) is introduced solely to delimit RPC messages over stream transports like TCP, which have no inherent message boundaries. The RM header is not XDR-encoded to keep it simple and distinct from payload encoding.
RPC intentionally does not implement reliability, time-out, retransmission, or duplicate detection. These are left to the application or transport layer, enabling transport independence and allowing RPC to run over both reliable (TCP) and unreliable (UDP) transports.
The transaction ID (xid) is provided so that servers can optionally implement execute-at-most-once semantics by caching previously executed xids and refusing to re-execute calls with the same ID. However, servers may not use xid as a sequence number.
When a version mismatch occurs (PROG_MISMATCH or RPC_MISMATCH), the server returns the lowest and highest supported version numbers, enabling clients to retry with a compatible version.
When an AUTH_SHORT shorthand credential is flushed by the server, the call is rejected with AUTH_REJECTEDCRED, and the client should retry using the original AUTH_SYS credential.
For AUTH_NONE, it is recommended that the length of the opaque data be zero.
In version 2 of the RPC protocol, the rpcvers field in call_body must be equal to 2.
Null authentication (AUTH_NONE) must be available in all RPC implementations. It is mandatory.
Procedure 0 of any RPC protocol should have the same semantics across protocols and never require any kind of authentication.
System authentication (AUTH_SYS) is strongly recommended in all implementations to enhance interoperability, as many applications use this authentication style.
The reserved program number ranges (0x60000000–0xffffffff) should not be used; they are reserved for future use.
The xid of a REPLY message must always match the xid of the initiating CALL message. The server cannot treat xid as any type of sequence number.
Each RPC call is uniquely identified by three unsigned integer fields: remote program number, remote program version number, and remote procedure number.
The accept_stat enum encodes six outcomes for accepted calls: SUCCESS, PROG_UNAVAIL, PROG_MISMATCH, PROC_UNAVAIL, GARBAGE_ARGS, and SYSTEM_ERR.
The auth_flavor enum defines AUTH_NONE=0, AUTH_SYS=1, and AUTH_SHORT=2, with additional values to be assigned centrally. The flavor field in opaque_auth selects the authentication protocol.
The auth_stat enum defines eight authentication failure codes including AUTH_BADCRED, AUTH_REJECTEDCRED, AUTH_BADVERF, AUTH_REJECTEDVERF, AUTH_TOOWEAK, AUTH_INVALIDRESP, and AUTH_FAILED.
Authentication flavor numbers are administered centrally like program numbers; developers assign new flavors by applying to [email protected].
RPC program numbers are assigned in blocks of 0x20000000: 0x00000000–0x1fffffff (Sun/central authority), 0x20000000–0x3fffffff (site-local/debugging), 0x40000000–0x5fffffff (transient/dynamic), 0x60000000–0xffffffff (reserved).
AUTH_SYS authentication does not guarantee security by itself. It is only legitimate when the network and applications are secured externally and privileged transport addresses (e.g., privileged TCP/UDP ports) are used for communicating endpoints.
Each RPC call and reply message includes authentication fields (credential and verifier in calls; response verifier in replies), enabling security and access control mechanisms to be built on top of RPC.
The AUTH_SYS credential is only unique within a particular domain of machine names, uids, and gids, making it unsuitable as a global identity mechanism.
The accepted_reply contains a server-generated opaque_auth verifier, followed by a discriminated union on accept_stat; the PROG_MISMATCH arm carries a mismatch_info struct with unsigned int low and high version fields.
The authsys_parms credential body encodes: stamp (unsigned int), machinename (string, max 255 bytes), uid (unsigned int), gid (unsigned int), gids (counted array, max 16 entries).
The call_body contains: rpcvers (unsigned int, must be 2), prog, vers, proc (unsigned ints), then cred and verf (opaque_auth structures), followed by procedure-specific parameters.
The opaque_auth structure consists of an auth_flavor enum followed by an opaque body of up to 400 bytes, uninterpreted by the RPC protocol layer.
The record marking (RM) header for stream transports is a 4-byte big-endian value: the high-order bit is a boolean indicating last fragment, and the remaining 31 bits encode the fragment data length in bytes. This format is explicitly NOT XDR standard form.
The rejected_reply is a discriminated union on reject_stat: RPC_MISMATCH carries low/high unsigned int RPC version numbers; AUTH_ERROR carries an auth_stat enum value.
The rpc_msg structure begins with an unsigned int xid, followed by a discriminated union on msg_type (CALL=0 or REPLY=1) containing either call_body or reply_body.