tcp-ip@ucbvax.ARPA (06/25/85)
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> I would like to draw people attention to a little noticed part of the ARP spec (RFC826) that, when ignored, leads to buggy implementations. The problem is that if you have a mapping in your cache for a given (protocol address, hardware address) pair then if the destination changes its hardware address (quite common if, for example, your Ethernet board breaks and you install a new one), you may not notice that his hardware address has changed and then (apparently inexplicably) lose contact with the destination. This bug exists in several implementations of ARP, including at least one commercial one (which I won't name unless they don't fix it). What is annoying is that if people *followed the spec* this wouldn't happen. This problem is explicity approached in the spec. In the section 'Packet Reception', the correct algorithm to prevent this is given, along with a note (at the end of the paragraph after the algorithm). In the section 'Related Issues', paragraph three elaborates. Note that this approach does not help if the data in the ARP packets is corrupted. However, we have not noticed this kind of fault here at MIT. We have noticed the 'moving host' one with some regularity. Timeouts would be necessary to fix the 'corrupted data' problem, since the protocol provides no checksum. Noel -------