Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt

From: Stuart Cheshire <[email-masked]>
Date: Wed, 11 Jul 2001 15:16:13 -0700

>Doesn't the latter rule mean that devices that implement this
>specification WILL NOT interoperate with existing devices that use
>link-local addresses? I.e, for the stacks that already support
>link-local addresses, do they always set the TTL to 255?

I can attest that Mac OS certainly sets TTL=255 for all outgoing unicast 
packets.

>What about the case where a node uses a link-local address, shuts
>down, and then restarts. Per the document, it should try to use the
>same address. Other devices could still be trying to communicate with
>the device using its previous (and soon-to-be current) address.

Good observation. If no one makes strong arguments to the contrary, I 
will change "any ARP packet" to "any ARP probe" as you suggested.

>This would be better, but might still be a bit aggressive. In a large
>environment with a bridged network, the traffic could be a problem. We
>want this to follow the "do no harm" rule if a device gets plugged in
>somewhere where the zeroconf stuff gets invoked, even though maybe it
>shouldn't. I'm not sure what the right number should be.

I think we're getting into slightly obscure cases here. We're talking 
about a large bridged network, with a DOS attack going on, and the 
administrators doing nothing to fix it, and one packet a minute from each 
machine being "too much traffic".

>I agree the defend once handles the case of a newly booting
>device. But what about a bridge network being connected together?

Exactly the same, in the common case where one of our hosts in question 
broadcasts an ARP request in preparation for initiating some outgoing 
communication:

1. Host A sends an ARP
2. Host B sees A's ARP, B has no open connections, B politely defers.

- OR -

1. Host A sends an ARP
2. Host B sees A's ARP, B has active connections on this address, so
   Host B defends once ("Hey, get lost, that's my address.")
3. Host A sees B's ARP, A has no open connections, A politely defers.

- OR -

1. Host A sends an ARP
2. Host B sees A's ARP, B has active connections on this address, so
   Host B defends once ("Hey, get lost, that's my address.")
3. Host A sees B's ARP, A has active connections on this address, so
   Host A defends once ("You get lost, I'm using this address.")
4. Host B can't defend twice, so B politely defers.

Finally, remember that these collisions are *rare* events. We're putting 
a lot of brain cycles into worrying about tuning something that almost 
never happens.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org