Path: utzoo!utgpu!watmath!clyde!att!ucbvax!DECWRL.DEC.COM!mogul From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dynamic IP address assignment [actually: ARP cache timeouts] Message-ID: <8811282322.AA28571@acetes.pa.dec.com> Date: 28 Nov 88 23:22:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: Perhaps the right thing to do is to reset the ARP age timer on receipt of a packet from that (IP? Ethernet? both?) address; that will deal with persistent attempts to reach a host which has gone away. This seems inefficient because it adds code to the path of every received packet, and as you've observed, the layering is weird. Also, it doesn't really address the problem of bad mappings (someone has changed their IP or the Ether address; when you receive a packet from them, how do you figure this out?) A simple fix is to reset the ARP cache timer only when the entry is created, not when it is used. This means that a bad entry will never persist beyond a single timeout period, no matter how often you try to make contact (4.xBSD resets on every use, so it is really hard to get rid of a stale entry). The inefficiency here is that every 20 minutes (or whenever), each connection pauses while the ARP cache is reloaded. On the other hand, since this all happens at interrupt level, the pause should be pretty small. If one wanted to avoid this pause altogether, one could change the state machine in the ARP implementation from effectively a three-state system (EMPTY->INCOMPLETE->COMPLETE->EMPTY) by adding a fourth state, SUSPICIOUS. The transition from COMPLETE to SUSPICIOUS would be made when the timer goes off, at which point a new ARP request would be generated. A successful reply would return the state to COMPLETE. In SUSPICIOUS state, the entry would still be useable, but after a few seconds in this state it would revert to INCOMPLETE (i.e., because no reply is received). Thus, the normal case would be for connections to proceed without waiting for an ARP reply, but if the mapping changes, there is a strict bound on the lifetime of a stale entry. This mechanism avoids most need for rebroadcasting, too, since we think we know the target Ethernet address when we get "suspicious". Neither the "simple fix" nor the 4-state version require any change to the ARP protocol or to the behaviour of other hosts. I'd go with the simple fix, since the cost of waiting 10 mSec once in a while seems unimportant. -Jeff