2

I have the situation that an IP address moves from one device to another and no Gratuitous ARP (Address Resolution Protocol) message gets send out to update the members on this network.

There is a device on this network which needs probably due to a long ARP cache timeout up to 20 minutes to start communicating again. Another device sends its ARP request right away after it recognizes a broken connection and so it is pretty quick available on the network again.

I am wondering if there is some definition that a device must re-send an ARP request if its target MAC address or the IP communication is not available anymore?

This question is somehow related to the question "How does ARP handle a move of an IP address to another device?".

2

I am wondering if there is some definition that a device must re-send an ARP request if its target MAC address or the IP communication is not available anymore?

No there is not. There isn't even a requirement that hosts have entries in their ARP table time out.

RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware discusses problems related to this:

It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).

If a host moves, any connections initiated by that host will work, assuming its own address resolution table is cleared when it moves. However, connections initiated to it by other hosts will have no particular reason to know to discard their old address. However, 48.bit Ethernet addresses are supposed to be unique and fixed for all time, so they shouldn't change. A host could "move" if a host name (and address in some other protocol) were reassigned to a different physical piece of hardware. Also, as we know from experience, there is always the danger of incorrect routing information accidentally getting transmitted through hardware or software error; it should not be allowed to persist forever. 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. Or perhaps receiving of a packet from a host should reset a timeout in the address resolution entry used for transmitting packets to that host; if no packets are received from a host for a suitable length of time, the address resolution entry is forgotten. This may cause extra overhead to scan the table for each incoming packet. Perhaps a hash or index can make this faster.

The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move. Recall that if the is already in the translation table, then the sender hardware address supersedes the existing entry. Therefore, on a perfect Ethernet where a broadcast REQUEST reaches all stations on the cable, each station will be get the new hardware address.

Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.

Since hosts don't transmit information about anyone other than themselves, rebooting a host will cause its address mapping table to be up to date. Bad information can't persist forever by being passed around from machine to machine; the only bad information that can exist is in a machine that doesn't know that some other machine has changed its 48.bit Ethernet address. Perhaps manually resetting (or clearing) the address mapping table will suffice.

This issue clearly needs more thought if it is believed to be important. It is caused by any address resolution-like protocol.

  • This actually means I cannot issue a complain at the device manufacturer if a device does not communicate with a replacement device which has the same IP address as the old one. – Michael Uray Feb 16 '17 at 20:55
  • Unfortunately, many RFCs leave specific methods or implementations up to the OS manufacturers. I would still gripe to device manufacturer because you are the customer, and this causes you pain. It should be a simple matter for the device to send a gratuitous ARP when it comes onto the network. You wouldn't really be asking for much, unlike asking to support a new protocol that must be designed from scratch. – Ron Maupin Feb 16 '17 at 20:58
  • I actually meant the manufacturer of the device which does not send out an ARP request on a broken connection for 20 minutes. The router itself runs on an OpenWRT system and there is probably some at least some hotplug-scripting solution possible (forum.openwrt.org/viewtopic.php?id=69878), but that does not help if the device is separated by a switch and the OpenWRT system does not recognize a connection change. Regularly cyclic sending (e.g. evey minute) would fix this, but I would not call that a "nice" solution. – Michael Uray Feb 17 '17 at 17:02

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.