Binding Protocols for ONC RPC Version 2 (RFC1833)
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]
Network Working Group R. Srinivasan Request for Comments: 1833 Sun Microsystems Category: Standards Track August 1995
Binding Protocols for ONC RPC Version 2
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols.
TABLE OF CONTENTS
1. Introduction 1 2. RPCBIND Program Protocol 2 2.1 RPCBIND Protocol Specification (in RPC Language) 3 2.2 RPCBIND Operation 9 2.2.1 RPCBIND Version 3 9 2.2.2 RPCBIND, Version 4 10 3. Port Mapper Program Protocol 11 3.1 Port Mapper Protocol Specification (in RPC Language) 11 3.2 Port Mapper Operation 13 References 14 Security Considerations 14 Author’s Address 14
This document specifies the binding protocols used in conjunction with ONC RPC Version 2. As a prerequisite, the reader is expected to be familiar with  and  which describe the ONC RPC Version 2 and XDR (eXternal Data Representation) protocols.
An RPC service is identified by its RPC program number, version number, and the transport address where it may be reached. The transport address, in turn, consists of a network address and a transport selector. In the case of a service available over TCP/IP or UDP/IP, the network address will be an IP address, and the transport selector will be a TCP or UDP port number.
Srinivasan Standards Track [Page 1]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
A client program needs to know the RPC program number, version number, and the transport address corresponding to a service in order to utilize the service. Of these, the RPC program number and version number are usually built into the client program, as part of the service definition. The network address component of the transport address is usually available in a name service, or is given as a parameter to the client program. The transport selector (ie., the TCP or UDP port) is usually determined dynamically, and varies with each invocation of the service. Server programs allocate a transport address, and register it with a well-known lookup service (well-known because it uses a fixed transport selector, and resides at the same network address as the server). Client programs consult the lookup service in order to obtain the server’s transport address.
Such a lookup service is very desirable because the range of well- known transport selectors is very small for some transports and the number of services is potentially very large. By running only the lookup service on a well-known transport selector, the transport addresses of other remote programs can be ascertained by querying the lookup service.