3
  1. Can the Ethernet source, ARP request SHA, ARP reply THA differ? I take it for granted, that ARP request SHA, and ARP reply THA are always the same. But I'm not sure about whether the Ethernet source address of the ARP request (as well as the Ethernet destination address in ARP reply) must be the same as this address as well.

This would imply that any host A can do an ARP request on behalf of host B.

  1. Also, can ARP request TPA, and ARP reply SPA differ?

This would imply that for any ARP request for a certain MAC address, instead of the owner of the IP in the ARP request TPA, somebody else answers in his stead. This would also imply to me, that I can get several answers for a single ARP request.

EDIT: for clarification:

SHA := source hardware address
SPA := source protocol address
THA := target hardware address
TPA := target protocol address
6

Question 1:

Can the Ethernet source, ARP request SHA, ARP reply THA differ? I take it for granted, that ARP request SHA, and ARP reply THA are always the same. But I'm not sure about whether the Ethernet source address of the ARP request (as well as the Ethernet destination address in ARP reply) must be the same as this address as well.

If I'm understanding your question, you are asking if these three fields are always the same: ARP Request Ethernet Source ARP Request Source Hardware Address and ARP Reply Target Hardware Address.

We can compare the values on a traditional "normal" ARP conversation, and a Proxy ARP.

Traditional ARP Request / Reply

ARP Request

enter image description here enter image description here

ARP Reply

enter image description here enter image description here

SHA and THA show up in Wireshark as "Source MAC Address" and "Target MAC Address" and looking at the images above, it seems that all three fields match (across the two frames, of course) -- they are both 00:53:ff:ff:aa:aa. This also matches the Ethernet Source in the original Request. So it seems for a Regular ARP, all three values match.

Next we'll look at a Proxy ARP:

Proxy ARP

ARP Request

enter image description here

ARP Reply (via Proxy)

enter image description here

Again it seems the Source MAC in the Ethernet Header of the ARP Reply matches the Sender MAC Address in the ARP Reply, and also the Target MAC Address in the ARP Request.

But there is one "other" type of ARP conversation we haven't looked at yet...

ARP Probe and Announcement

There is one place I did find it different though... that is in the ARP Probe and Announcement sequence. Specifically in the ARP Announcement

enter image description here

This is the ARP Announcement, notice the THA is 00:00:00:00:00:00. The Announcement isn't really "answering" a question, so the THA/TPA fields are ignored. In fact, the ARP Announcement still has an OPcode of 1, technically making it an ARP Request.

So in a way, the ARP Probe/Announcement sequence does not have an ARP Reply -- only ARP Requests. And in that case, then the Ethernet SRC and the SHA always match each other -- but there is no THA in a Reply to match against.

Question 2:

Also, can ARP request TPA, and ARP reply SPA differ?

TPA := target protocol address
SPA := source protocol address

Looking at the captures above, it seems in all cases the Request TPA and the Reply SPA are identical.

I can't imagine a situation in which they would be different. But I'll admit I haven't explicitly researched this point specifically.

However, I am inclined to believe that if they were different, the original sender would simply look at the incoming reply as a Gratuitous ARP and not as an answer to the original sender's original question.

  • Are you sure this is an ARP proxy? in the response ether$source and arp$SHA are the same. – hgiesel Feb 22 '18 at 17:16
  • @hgiesel Why wouldn't they be the same? The Proxy ARP Response is essentially saying "Here, use my MAC to get to the Target IP you were asking about". – Eddie Feb 22 '18 at 17:19
  • @hgiesel I'm trying to think of a situation in which a node would respond via Proxy to provide another node's MAC address -- AND that the "other node" wouldn't be able to respond to the ARP directly. AKA, without needing a Proxy ARP intervention. – Eddie Feb 22 '18 at 17:22
  • OK, I see you answered to @jonathanjo s answer, I think maybe his answer confused me – hgiesel Feb 22 '18 at 17:29
  • 1
    My answer was wrong: Eddie is correct. If reply is for a different protocol address, we have an unanswered request + a gratuitous ARP. – jonathanjo Feb 23 '18 at 10:10
2

Regarding 1., I found this excerpt from RFC 826:

The Address Resolution module then sets the ar$hrd field to ares_hrd$Ethernet, ar$pro to the protocol type that is being resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet address), ar$pln to the length of an address in that protocol, ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address of itself, ar$spa with the protocol address of itself, and ar$tpa with the protocol address of the machine that is trying to be accessed

Which means, that at least according to the original specification, this is not intended to be done.

1

Looking at RFC 826, you can easily find that the request SHA/SPA should always match the reply THA/TPA:

        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.

This comes from the section detailing how a received ARP packet is handled. Since the request's SHA/SPA are now swapped to the reply's THA/TPA, they should match.

So does this match the Ethernet source? Again back to RFC 826:

                                                The Address
Resolution module then sets the ar$hrd field to
ares_hrd$Ethernet, ar$pro to the protocol type that is being
resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
address), ar$pln to the length of an address in that protocol,
ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address
of itself, ar$spa with the protocol address of itself, and ar$tpa
with the protocol address of the machine that is trying to be
accessed.  It does not set ar$tha to anything in particular,
because it is this value that it is trying to determine.  It
could set ar$tha to the broadcast address for the hardware (all
ones in the case of the 10Mbit Ethernet) if that makes it
convenient for some aspect of the implementation.

Since this is all driver level implementation, this should be the driver of the interface out of which the ARP request is being sent. As such, the Ethernet source of that interface should be the SHA. So yes, all three (Ethernet source address, request SHA and reply THA) should match.

As for the request TPA being the same as the SPA, we can expand out the previously quoted section of RFC 826 a bit:

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?
  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.

So, if an interface is not the TPA, it should hit a negative condition in response to ?Am I the target protocol address? and end the processing. If it is a match to the TPA, then again we swap the TPA and SPA. So again they should be the same.

Additionally, if the TPA in the request where to reply with a different SPA, note that the original requester upon receipt of the reply would put the reply SPA into its ARP table. It would still not have an entry for the original request's TPA and as such would start the ARP process again.


Now, all that being said, that is what should happen. RFC 826 does not specify any sort of check to verify that the Ethernet address of an ARP frame matches that of the SHA. That doesn't mean such a check doesn't exist, it may be added to the driver or implemented on the network to help prevent abuses of ARP that you allude to in asking your questions.

Also, I should point out that if you step outside of Ethernet to FDDI, the FDDI source address will not match the SHA. There is some ARP "ugliness" that was necessary when Ethernet was bridged to Token Ring that required the payload of ARP packets to be modified by the bridge due to differences in the bit order used for addressing. When FDDI came along later, while it used the same bit order as Token Ring, for ARP payloads they used the Ethernet ordering of bits to avoid this "ugliness."

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.