III. The Proposed Protocol

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 (still to be assigned) 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. However, these difficulties should not be insurmountable, as is shown in Appendix A, where we sketch two possible implementations for 4.2BSD Unix.

RARP uses the same packet format that is used by ARP, namely:

      ar$hrd (hardware address space) -  16 bits
      ar$pro (protocol address space) -  16 bits
      ar$hln (hardware address length) - 8 bits
      ar$pln (protocol address length) - 8 bits
      ar$op  (opcode) - 16 bits
      ar$sha (source hardware address) - n bytes,
                                       where n is from the ar$hln field.
      ar$spa (source protocol address) - m bytes,
                                       where m is from the ar$pln field.
      ar$tha (target hardware address) - n bytes
      ar$tpa (target protocol address) - m bytes

ar$hrd, ar$pro, ar$hln and ar$pln are the same as in regular ARP (see [1]). Suppose, for example, that 'hardware' addresses are 48-bit Ethernet addresses, and 'protocol' addresses are 32-bit Internet Addresses. That is, we wish to determine Internet Addresses corresponding to known Ethernet addresses. Then, in each RARP packet, ar$hrd = 1 (Ethernet), ar$pro = 2048 decimal (the Ethertype of IP packets), ar$hln = 6, and ar$pln = 4.

There are two opcodes: 3 ('request reverse') and 4 ('reply reverse'). An opcode of 1 or 2 has the same meaning as in [1]; packets with such opcodes may be passed on to regular ARP code. A packet with any other opcode is undefined. 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.

The ar$sha, ar$spa, $ar$tha, and ar$tpa fields of the RARP packet are interpreted as follows:

When the opcode is 3 ('request reverse'):

      ar$sha is the hardware address of the sender of the packet.

      ar$spa is undefined.

      ar$tha is the 'target' hardware address.

         In the case where the sender wishes to determine his own
         protocol address, this, like ar$sha, will be the hardware
         address of the sender.

      ar$tpa is undefined.

When the opcode is 4 ('reply reverse'):

      ar$sha is the hardware address of the responder (the sender of the
      reply packet).

      ar$spa is the protocol address of the responder (see the note
      below).

      ar$tha is the hardware address of the target, and should be the
      same as that which was given in the request.

      ar$tpa is the protocol address of the target, that is, the desired
      address.

Note that the requirement that ar$spa in opcode 4 packets be filled in with the responder's protocol is purely for convenience. For instance, if a system were to use both ARP and RARP, then the inclusion of the valid protocol-hardware address pair (ar$spa, ar$sha) may eliminate the need for a subsequent ARP request.