ARP relay

On Sun, 2005-05-01 at 13:18, Freek Dijkstra wrote:

<snip>
>  since some 
> things have to be fixed in the kernel (for example, ARP replies must be 
> broadcasted, 

I assume that you want to avoid duplicate IP addresses in adjacent
networks. But blindly broadcasting ARP replies will lead to a number of
serious problems.

The networks on different interfaces may be connected with bridges, in
which case we got multiple interfaces into the same physical network
(think WLan accesspoint). Broadcasting ARP replies would then trash the
ARP-tables in the bridge and connected switches.

Also, there is no way to find out from the recieved packet, whether an
ARP reply actually has been relayed by another multi-homed host. Without
a mechanism to avoid multiple relaying of ARP repliess, such packets
could circulate in the network forever. 

As it is impossible to add a "ttl" to relayed ARP replies, another way
to mark such packets is needed. Maybe one could use a fixed "fake"
source MAC address for relayed packets. When an ARP reply with this MAC
address is recieved, it would not be relayed further.

But just relaying ARP replies was not enough, some sort of proxy was
needed that would keep a list of IPv4 link local addresses on each
interface and defend the addresses on one interface on all other
interfaces (using said fake MAC as source address). There is no need to
implement this proxy in the kernel.

Ciao
  Andi

-- 
Andreas Hofmeister
Coreworks Systementwicklung GbR
Burkheimerstr. 3
79111 Freiburg
fon ++49.761.45684.21
http://www.coreworks.de



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20