RARP (Reverse ARP)

Before DHCP, there were other protocols to assign an IP address to a host. First, there was RARP (Reverse ARP), later came BOOTP (Bootstrap Protocol).

Before DHCP, there were other protocols to assign an IP address to a host. First, there was RARP (Reverse ARP), later came BOOTP (Bootstrap Protocol). https://vimeo.com/296874553 RARP is an old protocol and we don't use it anymore to assign IP addresses to hosts. It has been replaced by BOOTP and la

RARP is an old protocol and we don’t use it anymore to assign IP addresses to hosts. It has been replaced by BOOTP and later by DHCP.

So, what exactly is RARP? You probably know ARP. We use ARP to figure out the MAC address of a remote IP address that you want to reach. RARP uses the same packets but for a different reason. We use RARP to figure out what our own IP address is.

RARP was used by old diskless workstations. These old hosts don’t have a disk so there is nothing to store an IP address on. They do have a hardcoded MAC address though. When the workstation starts, it broadcasts a RARP request with its own MAC address.

On the same network as the hosts, we have a RARP server listening to the RARP requests. This server has a table that contains a combination of MAC and IP addresses. When it receives a RARP request, it checks its table to find the matching IP address for the MAC address in the RARP request packet. The RARP server then replies with a RARP reply to the host. When the host receives the RARP reply, it knows its IP address.

Here’s what this process looks like. The host does a RARP request:

Reverse Arp Request

And the RARP server replies with the RARP reply:

Reverse Arp Reply

RARP is a simple protocol and has some disadvantages:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

515 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,

    Nice explanation. Crisp and to the point. I have one question though.
    How would the client identify that the Offer and the Ack message that the server sends? In other words, how would the client understand that it is the intended recipient of those messages from the DHCP server. Say, for instance two new clients are connected to the network at the same time, then there would be two sets of offer and ack messages broadcasted from the server. How would each client pick the right message?

    Cheers,
    Vj

  2. Hi Saranya,
    This topic can be a little bit confusing because there are two different layers that can perform broadcast or unicast - Layer 2 and Layer 3.

    Here is a summary of what happens at each layer for each phase:

    Phase      Layer 3      Layer 2
    Discover   Broadcast    Broadcast
    Offer      Broadcast    Unicast
    Request    Broadcast    Broadcast
    Ack        Broadcast    Unicast
    

    Note:
    Layer 3 broadcast = 255.255.255.255
    Layer 2 broadcast = FFFF.FFFF.FFFF

    You may notice that layer 3 is always broadcast. This is because the whole purpose of DHCP is for the clien

    ... Continue reading in our forum

  3. Dear Rene/Andrew,
    Thank you for this great lesson. Mr Andrew with reference to your reply # 27608 above particularly this point " Additionally, you may notice that all communication from the DHCP server at layer 2 is unicast. The reason for this is because the DHCP server obtained the client’s MAC address when the client sent out its initial Discover message.", I am still confused on where broadcast happens and where unicast happens. From the Wireshark captures above I do not see Unicast happening anywhere. Even for Offer and Ack from the server the dest mac ad

    ... Continue reading in our forum

  4. Hello Samit

    This is an excellent question and it shows that you’re thinking deeply about the subject. It is true that the DHCPOFFER when sent can technically be sent using a unicast MAC address since the MAC address of the host making the request, and thus the destination of the DHCPOFFER frame, is known. However, some operating systems and NIC drivers don’t always use this logic when operating DHCP.

    Some client implementations are unable to receive such unicast frames until the implementation has been configured with a valid IP address. Remember, when we en

    ... Continue reading in our forum

  5. Hello Swapnil

    DHCP can provide a multitude of information to hosts. The most common implementations include IP address, subnet mask, default gateway and DNS server. There are many more elements that DHCP can offer and these are called DHCP options. Some of the most common include NTP servers, log servers, cookie servers, interface MTU, default TCP TTL, NetBIOS name server and IRC chat server to name just a few.

    These options are indicated using an option number. DHCP option numbers can range any where from 0 to 255. Some of these numbers are standard vendo

    ... Continue reading in our forum

35 more replies! Ask a question or join the discussion by visiting our Community Forum