Hubert Feyrer <hubert@feyrer.de> writes:

> On Fri, 19 Mar 2004 ragge@ludd.luth.se wrote:
> > A solution to this is to send out a new ARP request some time before
> > the entry is removed (if the routing entry has been active since the
> > last ARP update), and let the reply refresh the ARP entry, hence
> > avoid the arp entry update delay time.
> 
> Um, why update the entry at all if it's already known _and_ in active use?

The proposed solution sounds nice from a functionality point of view.
One could have some slowtimeout hook that walked the arp table and
sent requests for anything that is close to expiring, in order to
avoid adding any per-packet processing.
This is in fact exactly how racoon gets replacement SAs for ones that
are about to expire (due to soft timer expiration, rather than walking
the table, but it's semantically identical) and have been used.

So this could be 'option ARP_PROACTION', to avoid compiling in the
code for those that don't need it.  That might even keep everybody
happy...

Just because we used an arp entry recently doesn't mean it is still
correct.  I saw a problem with a host that refreshed the timer on each
use, and when a peer was rebooted with a new interface it was annoying
to clean up, since waiting 20 minutes didn't work.

Linux has a mechanism that marks an arp entry fresh when a TCP packet
is received that acks something, as that validates that the arp entry
at least caused the packet to get delivered.

-- 
        Greg Troxel <gdt@ir.bbn.com>