RFC 826 has some tidbits:

  • When an ARP request is received, it does the following (important) things:
    • If the sender’s <IP, MAC> is already present, update. This happens irrespective of whether the ARP request is for it or not.
    • If the sender’s pair is not present in the cache, then add it to the cache only if the ARP request is intended for self. This requirement is for hosts, but not for routers/switches, because it makes sense for the host to cache only those entries that it is talking to. One more subtle thing to note here is that the sender’s information is populated first and then the opcode is looked at. This, I believe, is an implementation convenience. To expand more, the information in the ARP reply comes in the sender fields (naturally). So, the first thing to do would be to populate the sender’s information into the cache and then check if it is a reply or a request. So, this way, we will learn the other host’s entry as well.
  • When an ARP request is sent out, an incomplete entry is kept in the ARP table (to be filled in later). So, when a response comes back, it is updated even before checking “am I the target protocol address?”. So, target protocol address is not really needed in the ARP reply, but kept just in case.
  • Typically when a host moves, its ARP table is cleared, but others’ are not cleared.
  • Perhaps failure to initiate a connection should inform the Address Resolution module to delete the information on the basis that the host is not reachable, possibly because it is down or the old translation is no longer valid.
  • The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move – because we update the entry at every ARP broadcast request packet – if we have that entry
  • ARP refresh is generally unicast to the target so as to not disturb other hosts in the network

RFC 5227 adds some interesting things over RFC 826:

  • When we are doing an ARP probe (broadcast ARP request) to see whether an IP address is owned by somebody or not, we have to keep the sender’s IP address as zero because if the IP address is already owned by somebody else, then our probe will poison the caches of other hosts.
  • An ARP announcement (broadcast ARP request) i ssimilar to ARP probe, but the sender and the target IP address is the same. (GARP)
  • An ARP broadcast request is an “assertion” and a “question” – the sender fields assert its information, the target fields question informaiton.
  • It is probably impossible to ask any truly pure question; asking any question necessarily invites    speculation about why the interrogator wants to know the answer.
  • In some applications of IPv4 Address Conflict Detection (ACD), it may be advantageous to deliver ARP  Replies using broadcast instead of unicast because this allows address conflicts to be detected sooner    than might otherwise happen – the tradeoff with increased broadcast traffic is worth having compared to increased reliability and fault tolerance.
  • RFC 826 implies that replies to ARP Requests are usually delivered using unicast, but it is also acceptable to deliver ARP Replies using broadcast.
  • The RFC has a nice definition of two hosts residing on the same link – when a packet is sent from one host to another, it arrives unmodified (in its entirety) to the destination and a broadcast packet reaches all the nodes in the link. Actually link layer header may be modified (in non-Ethernet [token ring] cases), but IP header and IP payload should not be modified. That is a more precise definition
  • Probing an address takes place during many events – not just IP address configuraiton – link toggle, link connected etc.
  • For ARP Probe – this initial random delay helps ensure that a large number of hosts powered on at the  same time do not all send their initial probe packets simultaneously.
  • While we are doing a probe:
    • If an ARP request/reply comes with “sender’ address same as the probe address, ACD (Address Conflict Detection) cries foul
    • If an ARP probe comes for the same address but with different “sender” hardware address, then ACD cries foul. This is the reason why sender hardware address “must” be populated. If, because of some loop, the ARP probe packet comes back to us, then this will save us from crying foul.
  • ARP probe rate limit can kick in if conflict detection crosses a threshold
  • ARP Announcement is same as ARP Probe but with sender and target fields having the same IP address. The Opcde is NOT a reply, but a request
  • When a host wants to defend an address (and other host also wants to do the same), then for very ARP announcement made, if we send another announcement in return, then there will be an endless loop.
  • Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address.
  • ARP replies as broadcast is desirable when we want to quickly resolve conflicts – like when two hosts are partitioned and initially assume that both have unique IP address. This is mandatory in ACD of dynamically configured IPv4 link local address.
  • Broadcast ARP Replies SHOULD NOT be used universally. Broadcast ARP Replies should be used where the benefit of faster conflict detection outweighs the cost of increased broadcast traffic and increased  packet processing load on the participant network hosts.
  • The “principle of least surprise” dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementation – because of which ARP announcements are “requests” and not “replies”. In summary, there are more ways that an incorrect ARP implementation    might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited)
  • What Stevens describes as Gratuitous ARP is the exact same packet that this document refers to by the more descriptive term ‘ARP Announcement’
  • GARP is not active – it is just passive. ARP Announcement is in fact, active.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s