RPC: Remote Procedure Call Protocol Specification Version 2
obsoletes
- rfc-1831 — RPC: Remote Procedure Call Protocol Specification Version 2
updated by
- rfc-9289 — Towards Remote Procedure Call Encryption by Default
Extracted elements (30)
Binding a client to a particular service and transport is intentionally NOT part of the RPC protocol specification, leaving rendezvous to higher-level software (e.g., the RPC binder/portmapper) so the core protocol remains transport-independent.
Recent RPC security work focuses on new GSS-API mechanisms used with the existing RPCSEC_GSS flavor rather than defining new auth_flavor values, because RPCSEC_GSS already provides a negotiation framework (pseudo-flavors) for NFS security.
RPC does not implement reliability; applications running over unreliable transports (UDP) must implement their own timeouts, retransmission, and duplicate detection. Over TCP, a reply implies exactly-once execution, but no reply does not imply non-execution.
The transaction ID (xid) is used only for matching replies to calls and detecting retransmissions; servers may use it to implement execute-at-most-once semantics by caching previously executed xids, but must not treat it as a sequence number.
A server may return an AUTH_SHORT verifier containing an opaque shorthand credential; the client may subsequently use this shorthand in place of the full AUTH_SYS credential. If the server flushes the cache, it rejects with AUTH_REJECTEDCRED and the client must revert to AUTH_SYS.
Batching uses reliable stream transports (TCP) where the client sends a sequence of calls without waiting for replies; a final non-batch call is used to flush the pipeline and obtain acknowledgement.
When an RPC version mismatch occurs (RPC_MISMATCH), the server returns the lowest and highest supported RPC version numbers; when a program version mismatch occurs (PROG_MISMATCH), it returns the lowest and highest supported program version numbers, enabling client adaptation.
Any new transport mechanism used to carry ONC RPC messages SHOULD be specified by means of a Standards Track RFC.
AUTH_DH is considered obsolete and insecure; it SHOULD NOT be used for services that permit clients to modify data, and MUST NOT be specified as RECOMMENDED or REQUIRED for any Standards Track RPC service.
AUTH_SYS SHOULD NOT be used for services that permit clients to modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or REQUIRED for any Standards Track RPC service.
In version 2 of the RPC protocol, the rpcvers field in the call_body MUST be equal to 2. The first implementation of a new remote program MUST NOT use version number zero.
Null authentication (AUTH_NONE) MUST be available in all RPC implementations. It is the mandatory baseline authentication flavor.
Standards Track RPC services MUST mandate support for RPCSEC_GSS and MUST mandate support for an authentication pseudo-flavor with appropriate levels of security covering authentication, integrity, or data privacy.
The server is not allowed to examine the xid field in any way except as a test for equality. It must not treat xid as a sequence number.
RPC programs are identified by a 32-bit program number, a version number (MUST NOT be zero), and a procedure number, all carried as unsigned integers in the call_body.
The accept_stat enumeration defines six values for accepted replies: SUCCESS=0, PROG_UNAVAIL=1, PROG_MISMATCH=2, PROC_UNAVAIL=3, GARBAGE_ARGS=4, SYSTEM_ERR=5.
The auth_flavor enumeration defines AUTH_NONE=0, AUTH_SYS=1, AUTH_SHORT=2, AUTH_DH=3, and RPCSEC_GSS=6, with additional values to be assigned by IANA.
The auth_stat enumeration defines 15 authentication failure codes (AUTH_OK through RPCSEC_GSS_CTXPROBLEM=14), covering remote failures, local failures, deprecated Kerberos errors, and RPCSEC_GSS errors.
The rejected_reply discriminates on RPC_MISMATCH (returns low/high supported RPC version numbers) and AUTH_ERROR (returns an auth_stat value). A PROG_MISMATCH accepted reply likewise returns low/high supported program version numbers.
The Authentication Status (auth_stat) Number registry is maintained by IANA on a First Come First Served basis; new values may be added as new authentication flavors introduce new error conditions.
The RPC Authentication Flavor Number registry (transferred from Sun to IANA) assigns flavor numbers on a First Come First Served basis starting at 400000; RPCSEC_GSS pseudo-flavors for NFS are granted in the range 390000–390255.
The RPC Program Number registry (transferred from Sun to IANA) partitions the 32-bit space: 0x00000001–0x1fffffff assigned by IANA (starting at 400000), 0x20000000–0x3fffffff for local administrators, 0x40000000–0x5fffffff transient, remainder reserved.
AUTH_SYS lacks a verifier to validate credentials and is therefore insecure; it must not be mandated for Standards Track services. AUTH_DH is obsolete and insecure per RFC 2695. All non-trivial new RPC programs should implement RPCSEC_GSS-based security.
RPCSEC_GSS (RFC 2203) using GSS-API mechanisms is the recommended security framework for ONC RPC, supporting simple authentication, integrity (non-repudiation), and data privacy as appropriate to the service.
Basic call-reply state: client sends CALL with xid and blocks; server receives, processes, and sends REPLY with matching xid; client matches reply to call via xid and resumes. Server may cache xid to provide execute-at-most-once semantics on retransmissions.
The AUTH_SYS credential (authsys_parms) encodes: stamp (unsigned int), machinename (string up to 255 bytes), uid (unsigned int), gid (unsigned int), and gids (array of up to 16 unsigned ints).
The call_body contains four unsigned 32-bit fields (rpcvers, prog, vers, proc) followed by two opaque_auth fields (cred and verf), then procedure-specific parameters.
The opaque_auth structure encodes an auth_flavor enum (32 bits) followed by a variable-length opaque body of at most 400 bytes.
The Record Marking (RM) header for stream transports is a 4-byte big-endian value: the high-order bit is a boolean indicating the last fragment, and the remaining 31 bits encode the fragment data length in bytes (0 to 2^31-1). This encoding is NOT XDR standard form.
The RPC message (rpc_msg) begins with a 32-bit unsigned transaction identifier (xid), followed by a discriminated union on msg_type selecting either a call_body or reply_body.