LL32 Multihoming

>> The phrase "run the algorithm independently on each interface" may
>> seem a simple thing to say, but when you have Ethernet and wireless,
>> and (unknown to you) the wireless base station you're talking to is
>> bridged onto the same Ethernet, the interfaces aren't independent
>> any more, even if you wish they were.
>
>We disagree.  If each interface runs the algorithm independently then
>the hosts wireless and wired interface will select and defend
>properly.  Only if they attempt to select and defend the same address
>will they fail.  In that case they need to choose different addreses.
>Using the algorithm, they are very likely to choose a different
>address that the other interface did not choose, and therefore will
>succeed.

Speaking as someone who has implemented this code, the problem is this:

1. Many IPv4 APIs (setsockopt IP_ADD_MEMBERSHIP, IP_MULTICAST_IF, etc.) 
identify interfaces using IPv4 addresses.

1(b). Therefore: It is helpful to ensure that each local interface has a 
different IPv4 address.

2. If a host sends from interface A to destination address B, and the 
host also has an interface with address B, this is ambiguous and problems 
arise.

2(b). Therefore: It is helpful to ensure that no local interface has an 
IPv4 address that it identical to *any* peer connected via *any* 
interface.

When you put these two requirement together, it means that if a host with 
address A on Ethernet, and address B on AirPort, sees its own AirPort 
packet come back on the Ethernet interface, then it may do the wrong 
thing. It may incorrectly conclude that some other host on the Ethernet 
has the same address as its AirPort interface, and proceed to change its 
AirPort address to something else. This results in an infinite 
"autoimmune" response packet storm. I know. It happened. It was bad.

The fix is that when receiving an apparently conflicting ARP packet, it 
should check *all* of its MAC addresses, to make sure the packet didn't 
come from itself. This does in fact fix the problem.

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org