Re: Please review draft-ietf-zeroconf-ipv4-linklocal-15.txt !

Erik Guttman wrote:

> The change would remove the sense of the text in section 2.5.
> Argument:
>
> The text in section 2.5 says if a host is configured with
> an address A and has this address is in use, and the host
> detects an arp from a source address A it may elect to
> defend.  It sends its own arp from source address A and
> waits 10 seconds, for 802 networks.  If the host receives
> another arp from source address A it gives up the address.
> Otherwise it keeps the address configuration for A.
> 
> If this 10 second interval is described as "time to
> continue to defend your address, for IEEE 802 networks"
> this indicates we are waiting and watching for 10 seconds
> to defend an address.  If the 10 second interval is
> described as "min interval between defensive ARPs" there
> is no obvious relationship to the text in section 2.5.

I do not understand this comment AT ALL.

What do you mean by "no obvious relationship to the text in section 2.5"?

Section 2.5. is called "Conflict Detection and DEFENSE"
                                               ^^^^^^^
It says:

   MAY elect to attempt to defend its address, by ...
                           ^^^^^^
   broadcasting one single ARP announcement

The whole point of this section is about when to defend and when to give 
up. The answer to that question is determined by seeing if the last 
conflict was within DEFEND_INTERVAL seconds, if so, the host is not 
allowed to defend again. DEFEND_INTERVAL is the minimum interval between 
defensive ARPs.

There is no "waiting and watching" for anything. There is just:

1. Normal ARP operation, like any IPv4 host.
2. If you see a conflicting ARP, send a single defensive ARP.
3. To prevent a network storm where two hosts get in a loop constantly
   sending defensive ARPs back and forth as fast as they can, a host
   is not allowed to defend more than once per DEFEND_INTERVAL seconds.

The draft even explains this:

   This is necessary to ensure that two hosts do not
   get stuck in an endless loop with both hosts trying to defend the
   same address.

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