Re: Re: ARP relay

On Mon, 2005-05-02 at 15:35, Freek Dijkstra wrote:

> No, ARP replies are needed to avoid duplicate IP addresses when joining 
> two network segments on layer 1 or layer 2. I don't think I'm refering 
> to bridging like you are, and I certainly did not refer to ARP relaying 
> (whatever that might be ;-) ).

Ok, but in this case one should just handle each network interface on
its own - each interface would have its own link local address. 

A linux kernel would answer ARP-Requests for one of its IP addresses on
any interface, regardless whether the an IP address belongs to that
interface (afaik, BSD wouldn't). For Linux, an IP address belongs (more
or less) to the system, not to the interface. Don't be confused by what
ifconfig suggests, that program has been written for the IP-stack in
Linux 2.0, wich has been completly replaced in Linux 2.2.

> I just mentioned ARP reply broadcasting just like ARP requests are 
> broadcasted (and only for those with a link-local sender IP address), as 
> is mentioned in the last paragraph of section 2.5 of the internet-draft, 
> and illustrated in section 4.

There is a patch for Linux 2.4, that would broadcast ARP requests and
adjust the route depending on what interface the response has been
recieved on.

> By the way -- you are right that multi-homed hosts (hosts with multiple 
> physical interfaces) are a problem. The internet-draft unfortunately 
> does not present a good solution for that problem.

I was basically talking about multihomed hosts, because my interest is
in servers, which should be usable from multiple IPv4 link local
networks.

The problem in the specs is that an ip link-local addresses are strictly
scoped to a single physical network - within that single network, an IP
address must be unique (obviously). To make the whole stuff work for
multihomed hosts, it was neccessary to introduce the additional
constraint that IP addresses in two adjacent networks must be uniqe. For
Example

                   +--------+             +--------+   
  ---- Net A ------| Host 2 |--- Net B ---| Host 4 |--- Net C ---
         |         +--------+      |      +--------+      |
         |                         |                      |
     +--------+                +--------+             +--------+
     | Host 1 |                | host 3 |             | host 5 |
     +--------+                +--------+             +--------+

where host 1 & 2 are in net A, host 2 & 3 in net B and host 4 & 5 are in
net C.
To allow host 2 to speak to host 1 and 3, these hosts must not have the
same IP address. Likewise, to allow host 4 to speak to 3 and 5, 3 and 5
must not have the same address. 

However, as there is no way that 2 could talk to 5 and likewise there is
no way for 4 to reach 1 (no routing !), host 1 and 5 are allowed to have
the same address !

To avoid that 1 and 3 get the same address, 2 had to relay ARP packets
between Net A and B. Likewise host 4 had to relay ARP packets between
Net B and C. But no ARP packet from net A ever must reach net C. Any ARP
packet relayed by host 2 must be marked in some way, so that host 4 does
not relay it further to net C. At this point, the suggestion to use a
fake sender MAC to mark relayed packets comes into play. 

> By the way -- I haven't checked if modern kernels do broadcast ARP 
> replies. MacOS X does, a 2.4 kernel does not, but I haven't found the 
> time to test a 2.6 kernel.

The answer has just to be sent out on the interface where the request
came in. Broadcasting ARP replies does not help too much.

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