Subject: Example email from vendor: Probe after cable connection or not?

From: Stuart Cheshire <[email-masked]>
Date: Thu, 22 May 2003 13:08:23 -0700

Below is an email from a vendor I received today. I have removed names 
and email addresses to protect the innocent. This is just today's example 
of how the slightest vagueness or omission in the document makes it 
susceptible to misinterpretation. We at Apple have to answer questions of 
this nature on a regular basis, something I mention because I suspect it 
is a task that most people on this list have been spared.

Background information for the email below: As part of the licensing 
procedure for products to use Apple's Rendezvous logo, we verify that the 
device correctly probes to verify the uniqueness of its address at the 
times it is supposed to, including, specifically, when it is connected to 
an Ethernet hub while already powered on -- what the author of the email 
below refers to as "hot-plugging".

> Regarding the hot-plugging issue and auto IP behavior. In the
> reference spec for auto ip (draft-ietf-zeroconf-ipv4-linklocal-07.txt)
> it doesnt talk specifically about hot plugging. However, in section 4
> it comes close when it talks about joining a previously separate
> network. I know its not the same, but as far as the node and how it
> acts when it is configured and a new "group" of nodes is introduced,
> the spec indicates that it is better to handle these types of
> conflicts when they occur and not necessarily waste network bandwidth
> with probes. Now I agree that hot-plugging is an event that we can
> detect, and as such it is different than the "joined network" scenario.
> However, I would think that (when a cable is unplugged) it is just as
> likely (if not more likely) that the same network is being plugged
> back into than it is a different network being plugged into. So, in
> many cases, we would be sending probes on the network for no reason.
>
> Our code does work if the network is changed. Its just that our code
> would detect the collision sometime later and then go through the
> process of dealing with the conflict at that point rather than
> immediately. Our code will also not send unnecessary probes in either
> case, which is better if we are plugged back into the same network.

The LL document says *how* you configure, probe and announce LL 
addresses, but not *when* you should do this. Looking back, I think we 
assumed that the "when" would be obvious: you do it whenever there is 
plausible risk there there might be some other host already using that 
same address which would be disrupted by your use of that address; 
namely, you do it after any new attachment to a network link.

To spell this out, you need to probe for address uniqueness:

* Upon reboot/startup
* Upon wake from sleep (if network interface was inactive during sleep)
* Upon bringing up previously inactive network interface
* Upon Ethernet hardware link-state change that indicates
  a cable was attached.
* Upon association with a wireless base station.
* etc.
* (but NOT periodically as a matter of course)

I would have thought it obvious that if a device is powered on without 
the cable attached, then performing address probes without the cable 
connected is unlikely to yield any useful information, and consequently, 
when the cable is subsequently connected, any assumption that your 
address has been verified unique is completely baseless. However, this is 
evidently not obvious.

We need to explicitly spell out the occasions when address probing is 
necessary, either in IPv4LL itself, or in some other "wrapper" document 
that describes the times at which the rules described in IPv4LL are to be 
applied.

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