What happens if your own computer does not know its IP address, because it has no storage capacity, for example? In these cases, the Reverse Address Res­o­lu­tion Protocol (RARP) can help. The RARP is the coun­ter­part to the ARP – the Address Res­o­lu­tion Protocol.

The Reverse ARP is now con­sid­ered obsolete, and outdated. Newer protocols such as the Bootstrap Protocol (BOOTP) and the Dynamic Host Con­fig­u­ra­tion Protocol (DHCP) have replaced the RARP. However, it is useful to be familiar with the older tech­nol­o­gy as well. For instance, you can still find some ap­pli­ca­tions which work with RARP today. It also helps to be familiar with the older tech­nol­o­gy in order to better un­der­stand the tech­nol­o­gy which was built on it.

What is the RARP?

The RARP is a protocol which was published in 1984 and was included in the TCP/IP protocol stack. The RARP is on the Network Access Layer (i.e. the lowest layer of the TCP/IP protocol stack) and is thus a protocol used to send data between two points in a network. Each network par­tic­i­pant has two unique addresses more or less: a logical address (the IP address) and a physical address (the MAC address). While the IP address is assigned by software, the MAC address is built into the hardware. You have already been assigned a Media Access Control address (MAC address) by the man­u­fac­tur­er of your network card.

It is possible to not know your own IP address. This may happen if, for example, the device could not save the IP address because there was in­suf­fi­cient memory available. In such cases, the Reverse ARP is used. This protocol can use the known MAC address to retrieve its IP address. Therefore, its function is the complete opposite of the ARP. The ARP uses the known IP address to determine the MAC address of the hardware.

How does the RARP work?

Who knows the IP address of a network par­tic­i­pant if they do not know it them­selves? A special RARP server does. This server, which responds to RARP requests, can also be a normal computer in the network. However, it must have stored all MAC addresses with their assigned IP addresses. If a network par­tic­i­pant sends an RARP request to the network, only these special servers can respond to it.

Since the re­quest­ing par­tic­i­pant does not know their IP address, the data packet (i.e. the request) must be sent on the lowest layers of the network as a broadcast. This means that the packet is sent to all par­tic­i­pants at the same time. However, only the RARP server will respond. If there are several of these servers, the re­quest­ing par­tic­i­pant will only use the response that is first received. The request-response format has a similar structure to that of the ARP.

The following in­for­ma­tion can be found in their re­spec­tive fields:

  • Hardware Address Space: These two bytes contain the type of hardware address.
  • Protocol Address Space: This field, which is 2 bytes long, specifies the type of network protocol.
  • Hardware Address Length: This is 8 bits and defines the length n of the hardware address.
  • Protocol Address Length: This field defines the length m of the network address.
  • Opcode: This field is two bytes long and defines the type of operation. An RARP request has the value 3 and the cor­re­spond­ing response the value 4.
  • Source Hardware Address: This is where the MAC address of the sender is stored. The actual length of this field is n and is defined by the in­for­ma­tion under Hardware Address Length. A standard Ethernet network consists of 6 bytes.
  • Source Protocol Address: This field would normally contain the IP address of the sender, but since the IP address is not known during a request, the field remains undefined. The response, however, will contain the IP address of the server. The length of this field is m and is dependent on the Protocol Address Length. Normally, though, the field is the same length as an IPv4 address (i.e. 4 bytes).
  • Target Hardware Address: This field contains the target’s MAC address. Since there is no specific target for an RARP request, this field also contains the sender’s address. The server also includes the address of the re­quest­ing client in the response. The length of this field is also n and is specif­i­cal­ly 6 bytes long for Ethernet networks.
  • Target Protocol Address: This last field remains undefined during a request and contains in the response the in­for­ma­tion requested by the server: the par­tic­i­pant’s IP address. The length of this field is also m, which is usually defined as 4 bytes.

There are important dif­fer­ences between the ARP and RARP. First and foremost, of course, the two protocols obviously differ in terms of their spec­i­fi­ca­tions. While the MAC address is known in an RARP request and is re­quest­ing the IP address, an ARP request is the exact opposite. The IP address is known, and the MAC address is being requested. The two protocols are also different in terms of the content of their operation fields: The ARP uses the value 1 for requests and 2 for responses. The RARP on the other hand uses 3 and 4. This means that a server can recognize whether it is an ARP or RARP from the operation code.

Issues with the Reverse ARP

The Reverse Address Res­o­lu­tion Protocol has some dis­ad­van­tages which even­tu­al­ly led to it being replaced by newer ones. To be able to use the protocol suc­cess­ful­ly, the RARP server has to be located in the same physical network. The computer sends the RARP request on the lowest layer of the network. As a result, it is not possible for a router to forward the packet. In addition, the RARP cannot handle sub­net­ting because no subnet masks are sent. If the network has been divided into multiple subnets, an RARP server must be available in each one.

In addition, the network par­tic­i­pant only receives their own IP address through the request. As pre­vi­ous­ly mentioned, a subnet mask is not included and in­for­ma­tion about the gateway cannot be retrieved via Reverse ARP. Therefore, it is not possible to configure the computer in a modern network. These drawbacks led to the de­vel­op­ment of BOOTP and DHCP.

Go to Main Menu