0

I'm studying networking and I have a question about when an ARP table should update.

Consider this scenario:

Host A has the MAC address of host B in its ARP table.

Host B's ARP table is empty.

Host A sends a message to host B. In the link layer frame encapsulating that message, there's information about host A's MAC address.

My question is, when host B receives the message, does it update the ARP table to have the MAC address of host A automatically, or will it have to send an ARP broadcast to find host A the next time it wants to communicate to host A?

3

My question is, when host B receives the message, does it update the ARP table to have the MAC address of host A automatically, or will it have to send an ARP broadcast to find host A the next time it wants to communicate to host A?

Only ARP messages update an ARP table.

ARP is a process, like IPv4 is a process. Ethernet has an EtherType field (other IEEE protocols that use MAC addressing have something similar). The field tells ethernet to which process it should send the payload of the frame.

When the EtherType is 0x0800, the frame payload is sent to IPv4 because it is an IPv4 packet; when the EtherType is 0x86dd, the frame payload is sent to IPv6 because it is an IPv6 packet; when the EtherType is 0x0806 the frame payload is sent to ARP because it is an ARP packet. As you can see, ARP never sees any packets except ARP packets.

This may seem a weakness, but it is by design. Ethernet has a lot of broadcasts for various reasons, and a host must process all of them to see if the broadcast pertains to it. Many of the broadcasts are for ARP, but other broadcasts are for other reasons, and you would be putting entries into the ARP table for hosts with which your host has no interest in communicating. Even a host seeing an ARP broadcast not destined for it will first check to see if the source host is in its ARP table. If so, it updates the ARP table, if not, it ignores it. This may not seem like a big deal today, but back when hosts (even what were considered large hosts) had minimal RAM, it was a very big deal. ARP was defined in 1982, when IBM PCs (released in 1981) were still shipping with 64K of RAM.

ARP is detailed in RFC 826, An Ethernet Address Resolution Protocol, and it has pseudo code for how to process received ARP packets:

Negative conditionals indicate an end of processing and a discarding of the packet.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.