RARP: Reverse Address Resolution Protocol
When a system with a local disk is bootstrapped it normally obtains its IP
address from a configuration file that is read from a disk file. But a system
without a disk, such as an X terminal or a diskless workstation, needs some
other way to obtain its IP address.
Each computer on a network has a unique hardware address, assigned by
the manufacturer of the network interface. The principle of RARP is for the
diskless workstation to read its unique hardware address from the interface card
and send an RARP request (an RARP request broadcast in a frame over the
network) asking for someone to reply with the diskless system’s IP address (in
an RARP reply).
The format of an RARP request is identical to an ARP (Address resolution
protocol) request discussed in Lecture 2. The only differences are that the frame
type (in the frame header) is (8035)16 for an RARP request or reply, and the
operation field in the Ethernet data portion has the value 3 for an RARP request
and 4 for an RARP reply.
An RARP server attached to the physical network normally provides the
mapping from a hardware address to an IP address for many hosts (the diskless
systems on the network). The mapping is contained in a disk file (normally
/etc/ethers on Unix systems. The reply from the server is unicast (to the
sender of the RARP request).
As with ARP requests, RARP requests are sent as hardware (Ethernet) level
broadcasts. This means they are not forwarded by routers. Thus the server
must be present on the same physical network as the diskless workstation. To
allow diskless stations to bootstrap even when the main RARP server is down,
multiple RARP servers are provided on a single network. As the number of
servers increases, the network traffic increases, since every server sends an RARP
reply to every RARP request. The diskless system normally uses the first RARP
reply that it receives. Furthermore, there is a chance that each RARP server can
try to respond at about the same time, increasing the probability of collisions
on an Ethernet (This is not a problem with ARP, because only a single host
sends an ARP reply).