The ARP packet has a duplicate of the sender/destination hardware address. Theoretically, you could have a case where a device sent

Layer3: ARP Request From AA:BB:CC:DD:EE:FF To FF:FF:FF:FF:FF:FF LookingFor IAm Proto IPv4 HW Ethernet

But, after masquerading, the packet looks like this:

Layer2: From 00:11:22:33:44:55 To FF:FF:FF:FF:FF:FF
Layer3: ARP Request From AA:BB:CC:DD:EE:FF To FF:FF:FF:FF:FF:FF LookingFor IAm Proto IPv4 HW Ethernet

Will the replying device reply using the Layer2 source information, or will it use the self-reported information in the ARP packet?


1 Answer 1


ARP is a protocol above OSI layer-2, and it relies on what is in the ARP packet to make its decisions. RFC 826, An Ethernet Address Resolution Protocol explains what ARP does:

Packet Reception:

When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. 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?
    [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?
      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!!)
        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.

Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the <protocol type, sender protocol address> pair, then the new hardware address supersedes the old one. Related Issues gives some motivation for this.

Generalization: The ar$hrd and ar$hln fields allow this protocol and packet format to be used for non-10Mbit Ethernets. For the 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other hardware networks, the ar$pro field may no longer correspond to the Ethernet type field, but it should be associated with the protocol whose address resolution is being sought.

Obviously, ARP will reply to the hardware address in the ARP packet, but that doesn't mean there is or is not a problem (see below).

Whether or not the ARP packet actually contains the original MAC address is unknown because the masquerading may actually modify the ARP packet to contain the modified MAC address. MAC address translation does not have a standard the way NAT and NAPT do, and NAT and NAPT actually fix up the transport protocol (TCP, UDP, and ICMP) for the new IP address assigned to a packet. What is to say that MAC address translation does not do that for ARP? That would be an obvious part to include in MAC address translation. That is where the actual switch model and configuration come into question. Without that, we have no basis for saying what MAC address translation does or does not do for ARP because it is not a standard protocol.

There is also the question of what the switch does for its MAC address table. Does it actually put the source host MAC address in it table with that interface, does it put the modified address in its MAC address table with that interface, or does it do both? Since there is no standard for MAC address translation the way there is for NAT and NAPT, again, we cannot know unless you explain the switch model and configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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