Re: LL32 Multihoming

>I am fine with adding text to 3.4 to discuss how to avoid auto immune
>problems in this case.   I even drafted up a version of his text to
>send out.  That is, I fully support Stuart's effort to add clarifying
>text for LL32.
>
>But then I looked closer at the preceding text and saw his point 2b.
>We can't suggest that without reopening LL14 and LL15.  That was the 
>concern I brought up.

I think we can declare agreement on this.

The behaviour I described as 2(b) is a private internal implementation 
decision appropriate for a certain project, and no more needs to be said 
about that here.

The important point, on which I think we agree, is that an auto-immune 
packet storm is bad.

Draft-08 already contains text such as the following:

   At any time, if a host receives an ARP packet (request *or*
   reply) where the 'sender IP address' is the host's own IP
   address, but the 'sender hardware address' does not match
   any of the host's own interface addresses, then this is a
   conflicting ARP packet, indicating an address collision.

This is good. There is no need to change any of this.

My specific complaint was about the overly simplistic language in the 
"Unintentional Autoimmunity" section which says, "The simplest solution 
to this problem is to run the algorithm independently on each interface."

There are two problems with this:

1. This new addition contradicts existing text elsewhere in the document, 
such as the section I quoted, where interfaces are not treated 
independently.

2. It is pure unsubstantiated speculation. No *actual* implementer has 
stated that they have implemented IPv4LL independently on multiple 
interfaces, or whether this was indeed "the simplest solution", or 
whether there were any unanticipated problems when those interfaces were 
then connected to the same physical link.

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