RPC Protocols Family

RPCBv3

ftp://ftp.rfc-editor.org/in-notes/rfc1833.txt.

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 is an IP address, and the transport selector is a TCP or UDP port number.
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.
RPCBv3 (Binding protocol version 3 for RPC) and RPCBv4 are both versions of a lookup service, which use the same RPC program number (100000). They both use port 111 over TCP and UDP transports.

The distinguishing characteristic of RPCBIND (versions 3 and 4) is that this protocol uses a transport-independent format for the transport address, known as the universal address format. An address in universal address format is an ASCII string representation of the transport dependent address. String representation of addresses corresponding to a transport are defined by the addressing authority for the transport. The RPCBIND protocol can be used for binding ONC RPC clients and servers over any transport.
The structure of the RPCBv3 is as follows:

Program
The program number

Version
The version number

Network ID
The network ID

Universal Address
The universal address

Interested in more details about testing this protocol?

RPCBV4

ftp://ftp.rfc-editor.org/in-notes/rfc1833.txt.

Binding protocol version 4 for RPC (RPCv4) is very similar to version 3, but with a few additional parameters. The protocol header structure is as follows:

Program
The program number

Version
The version number

Network ID
The network ID

Universal Address
The universal address

Interested in more details about testing this protocol?

RPCSEC GSS

ftp://ftp.rfc-editor.org/in-notes/rfc2203.txt.

The security protocol version 3 for RPC deals with integrity and privacy as well as authentication. It is described using the XDR language [Srinivasan-xdr]. It uses GSS-API interfaces to provide security services that are independent of the underlying security mechanism.

An RPC session based on the RPCSEC_GSS security consists of: context creation, RPC data exchange, and context destruction.

Context creation and destruction use control messages that are not dispatched to service procedures registered by an RPC server. The program and version numbers used in these control messages are the same as the RPC service's program and version numbers. The procedure number used is NULLPROC (zero). A field in the credential information (the gss_proc field) specifies whether a message is to be interpreted as a control message or a regular RPC message. If this field is set to RPCSEC_GSS_DATA, no control action is implied; in this case, it is a regular data message. If this field is set to any other value, a control action is implied.

Just as with normal RPC data exchange messages, the transaction identifier (the xid field in struct pc_msg), should be set to unique values on each call for context creation and context destruction. The protocol structure is as follows:

Version
The version number

Procedure
The procedure number

Sequence Number
The sequence number

Service
The service number

Interested in more details about testing this protocol?

RPCmap

ftp://ftp.rfc-editor.org/in-notes/rfc1833.txt.

The IPort Mapper protocol version 2 for RPC (RPCmap) protocol, port mapper program maps RPC program and version numbers to transport- specific port numbers. This program makes dynamic binding of remote programs possible. The port mapper protocol differs from the newer RPCBIND protocols in that it is transport specific in its address handling.

Program
The program number

Version
The version number

Protocol
The protocol number
6      IPPROTO_TCP
17    IPPROTO_UDP

Port Number
The port number

Interested in more details about testing this protocol?

1 2 3 4

SUN Protocols Information
MNTV1 | Mntv3 | MOUNT | NFS | NFS2 | NFS3 | NFSv4 | NLMv4 | NSMv1 | PMAP | RPC | RPCBv3 | RPCBV4 | RPCmap | RPCSEC GSS | YP (NIS)