7

Lately I have been doing some research on the Address Resolution Protocol, and even though I know the idea behind it I still have some questions.

Q1: Are there more types of ARP messages that I am missing aside the following?:

  • ARP Request
  • ARP Reply
  • Gratuitous ARP Request (ARP.Protocol_Source = ARP.Protocol_Target)
  • Gratuitous ARP Reply (Reply without a Request)
  • ARP Probe (ARP.Protocol_Source = 0.0.0.0)

Q2: Does ARP actually care about the Ethernet Header?

For as far as I know ARP doesn't really care about the Ethernet Header at all. It doesn't matter if you Unicast or Broadcast the Ethernet Header because ARP will still respond, and I wouldn't be surprised if the Ethernet.Source can be different from ARP.Hardware_Source too.

Q3: Which packets fill the ARP cache?

I always thought that ARP Requests and ARP Gratuitous Requests filled the ARP cache with , are there more packets that do this (Gratuitous ARP Replies?), and is it implementation dependent in some cases?

Q4: When are Gratuitous Replies and when Gratuitous Requests used?

If any official documentation could be quoted that would be extra helpful!

Improve this question

2 Answers 2

Reset to default
3

When in doubt, go to the source, RFC 826, An Ethernet Address Resolution Protocol

  1. There are two type of ARP messages: REQUEST and REPLY.

  2. The RFC specifies the ethernet header. An ARP request involves determining the ethernet address of the destination, so it uses the broadcast address since it doesn't know the unicast address. An ARP reply will know the ethernet address, so it will be a unicast.

    Ethernet transmission layer (not necessarily accessible to the user):  
    48.bit: Ethernet address of destination  
    48.bit: Ethernet address of sender  
    16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION

    It then causes this packet to be broadcast to all stations on the Ethernet cable originally determined by the routing mechanism.

  3. The way the ARP cache works is OS-dependent, and there is nothing requiring a host to maintain an ARP cache.

  4. The use of gratuitous ARP is not officially documented, but some hosts and OSes use it to do things like resolve address conflicts; Wireshark has a pretty good explanation (with examples): Gratuitous ARP

Gratuitous ARP could mean both gratuitous ARP request or gratuitous ARP reply. Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826) but could be used in some cases. A gratuitous ARP request is an AddressResolutionProtocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff. Ordinarily, no reply packet will occur. A gratuitous ARP reply is a reply to which no request has been made.

Improve this answer
8
  • Regarding #2. Many client OS's (Win7, XP Vista, Linux Mint, Ubuntu) implement a targeted ARP refresh when an ARP entry times out. They send the usual ARP request, but instead of sending it to the mac address of ffff.ffff.ffff, they send it to the MAC address that just expired in the ARP cache. This isn't (to my knowledge) required by the RFC, its just an efficiency improvement added by the people who wrote the ARP software for those OS's. So in a way, I would say no, ARP does not care about the ethernet header -- the header is just the transport which delivers the arp "packet".
    – Eddie
    Jan 15, 2016 at 17:13
  • Some implementations of ARP may do what you describe, but the RFC is clear that an ARP REQUEST is sent as a broadcast. Also, the ethertype header field is required to be set to ether_type$ADDRESS_RESOLUTION. Based on the RFC, ARP does care about the ethernet header, but non-standard implementations may not care.
    – Ron Maupin ♦
    Jan 15, 2016 at 17:32
  • @RonMaupin Thanks for your replies! Point #1, #2 and #4 are clear to me now. However I find the the RFC states that an ARP entry should be updated by either an ARP Request or Reply. Quote: "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."
    – Christian Veenman
    Jan 15, 2016 at 23:04
  • And if the entry is not yet in the ARP Table it is: "?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." However I wonder: Is this in practise the case for all modern OSes (Windows, Mac, Linux), or is this standard rarely applied? I hope you can help me on this!
    – Christian Veenman
    Jan 15, 2016 at 23:05
  • Unfortunately, the question about how the modern OSes handle it is off-topic here, but you could ask that question on Super User for client devices and Server Fault for server devices.
    – Ron Maupin ♦
    Jan 16, 2016 at 0:03
1

An addendum for the reference:

rfc5226 speficies IANA registry for ARP

Improve this answer

Your Answer

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

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