RARP suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). Network hosts such as diskless workstations frequently do not know their protocol addresses when booted; they often know only their hardware interface addresses. To communicate using higher-level protocols like IP, they must discover their protocol address from some external source. RARP requires one or more server hosts to maintain a database of mappings from hardware address to protocol address and respond to requests from client hosts.
We propose that RARP be specified as a separate protocol at the data-link level. For example, if the medium used is Ethernet, then RARP packets will have an Ethertype different from that of ARP. This recognizes that ARP and RARP are two fundamentally different operations, not supported equally by all hosts. The impact on existing systems is minimized; existing ARP servers will not be confused by RARP packets. It makes RARP a general facility that can be used for mapping hardware addresses to any higher level protocol address.This approach provides the simplest implementation for RARP client hosts, but also provides the most difficulties for RARP server hosts.
RARP uses the same packet format that is used by ARP.The only differences
are that the frame type is for an RARP request or reply, and the op field
has a value of 3 for an RARP request and 4 for an RARP reply. As with ARP,
the RARP request is broadcast and the RARP reply is normally unicast.
As in ARP, there are no "not found" or "error" packets, since
many RARP servers are free to respond to a request. The sender of
a RARP request packet should timeout if it does not receive a reply for
this request within a reasonable amount of time.
RARP Server Design
While the concept of RARP is simple, the design of an RARP server is system dependent and complex. The complication with an RARP server is that the server normally provides the mapping from a hardware address to an IP address for many hosts . This mapping is contained in a disk file . Since kernels normally don't read and parse disk files, the function of an RARP server is provided as a user process, not as part of the kernel's TCP/IP implementation.To further complicate matters, RARP requests are transmitted as Ethernet
frames with a specific Ethernet frame type field
This means an RARP server must have some way of sending and receiving
Ethernet frames of this type. Since the sending and receiving of these
frames is system dependent, the implementation of an RARP server is tied
to the system.
For more details refer RFC 903
TCP/IP Illustrated Vol. I (Richard Stevens)