>To get to the other change. Rfc 826 describes (but does not mandate) an
>algorithm to update the ARP table. This algorithm always updates its
>table if an arp packet comes in. It does not do much validation whether
>it makes sense, if for instance it came in from the appropriate
>interface. So again, the change I'm proposing is merely backed up by my
>"common sense", in this case, hosts with addresses that do not fit the
>network number they are on are misconfigured and are not to be trusted.

ooh ooh ooh!!  then perhaps you can do something that i've thought
about, but not yet found the skill or depth of knowledge to
accomplish.

for arp responses (or updates) that are received that are not entered
into the arp table because of the network number mismatch, netbsd
currently (in my experience) only logs the bad address.  it does not
log either of two much more informative pieces of information: namely,
the interface on which the update was received, nor the hardware
address that the arp update came from.

two pieces of information like this would have been invaluable to me
in tracking down just such a problem some time ago.  and probably will
be again.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."