1

When hosts on the same local network communicate, they manage their own ARP tables which translate between IP addresses and MAC addresses. Thus when computer A needs to send data to IP address computer B, it looks at its ARP entry to know which MAC address to send data to.

However, let's say I were to flop two IP addresses for two of the hosts. How would a host know that it would need to update it's ARP table? It thinks it already has a MAC address entry for each IP address, but those entries are no longer correct.

3

Entries in an ARP table on modern OSes will time out. This is not an official part of RFC 826, An Ethernet Address Resolution Protocol, although the RFC does discuss it at the end:

Related issue:

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 <protocol type, sender protocol address> 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.


Edit based on your comments:

The protocol theory does not cover your situation, and it leaves it up to the OS-specific implementation. Unfortunately, we cannot answer what a particular host will do, as that is up to the host OS, which is off-topic here. Different OSes, and even different versions of the same OS, could do things differently. There is no one answer to what happens.

I understand that this is not a very satisfactory answer (someone even voted it down), but it is reality. You may discover that a particular host does something, but you cannot depend on any other hosts (especially with different OSes) doing the same thing. As Zac67, points out, one host OS may send a gratuitous ARP when changing its address, but that does not guarantee other hosts will do the same thing.

ARP was something added to IPv4, and it is not really a part of IPv4, but it is a separate process. The problem was taken into account when IPv6 was created, and IPv6 has built into it NDP (Neighbor Discovery Protocol) that, among other things, replaces ARP, and it solves the very problem you have pointed out with ARP.

6
  • So let's say a host sent a message to the wrong host due to bad ARP table. Would the host that accidentally received the message somehow respond saying "hey wrong MAC address, please refresh"?
    – Izzo
    Sep 12 '20 at 16:20
  • 1
    No, because the frame would be sent to the host with the destination MAC address on the frame, but the wrong IPv4 address. The destination would, because it received a frame for its MAC address, pass the packet to IPv4, where it would discover it is the wrong IPv4 address. What a host will do with that is up to the host OS implementation, which is off-topic here, but it would probably just drop the packet.
    – Ron Maupin
    Sep 12 '20 at 16:29
  • The host could send an ICMP Redirect or other error message back to the originator of the misdirected packet. In practice, many hosts no longer generate or pay attention to these kinds of ICMP messages due to their potential misuse. Sep 12 '20 at 16:49
  • @RonMaupin I guess what I'm curious about is how will the sender be notified that it sent the IP packet to the wrong host? From an IP perspective, the host will not get a response (because we sent to the wrong host). How is this typically resolved?
    – Izzo
    Sep 12 '20 at 17:59
  • That is completely up to the host OS, which is off-topic here. Linux could do it differently than Windows, etc. Some could send some ICMP response, and some could simply drop the packet and ignore it. In any case, what a host will do is not for theis site. You could ask on the different SE sites, such as Ask Different, Unix & Linux, Android Enthusiasts, Super User, Server Fault, etc., but remember that each OS could have a different way.
    – Ron Maupin
    Sep 12 '20 at 18:02
1

In addition to the timeout described by Ron, devices changing their IP addresses often send out a gratuitous ARP (GARP - usually a request for self) as broadcast to notify the network of the MAC address change.

GARP is especially important when you use virtual IP addresses without virtual MAC addresses.

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.