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

From: Stuart Cheshire <[email-masked]>
Date: Thu, 29 May 2003 18:02:42 -0700

>If this text is acceptable to you I will open a new 'issue' for
>discussion.  It looks completely reasonable and uncontroversial to me.
>I want to follow the 'issue' procedure since I have been wrong about how
>controversial things can prove quite often in this WG.

Thank you Erik.

I am torn between the desire to get the document finished, and the desire 
to not have obvious known omissions in it. If you think this new issue 
will not cause substantial delay, please introduce it. My proposed 
wording would be:

2.2 Claiming a Link-Local Address

   After it has selected an address, a host MUST test to see if
   the address is already in use before beginning to use it. To be 
   more specific, any time that a network interface transitions from
   an inactive to an active state, the host is in a position where
   it has no knowledge of what addresses may be currently in use on
   that link. Were it immediately to begin using an address which is
   already in use by some other host, this would be disruptive to that
   other host. For this reason, before using the address (e.g. using
   it as the source address in an IP packet, or as the Sender IP
   address in an ARP packet) a host MUST perform the probing test
   described below to achieve better confidence that using the address
   will not cause disruption. Examples of events that entail an
   interface becoming active include:

      * Reboot/startup
      * Wake from sleep (if network interface was inactive during
        sleep)
      * Bringing up previously inactive network interface
      * Ethernet hardware link-state change that indicates
        a cable was attached.
      * Association with a wireless base station.
      * etc.
 
   Note that a host MUST NOT perform this check periodically as a
   matter of course.  This would be a waste of network bandwidth,
   and is unnecessary due to the ability of hosts to passively
   discover conflicts, as described in Section 2.5.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 May 2003 14:48:14 +0700

Date:        Thu, 29 May 2003 18:02:42 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | I am torn between the desire to get the document finished, and the desire 
  | to not have obvious known omissions in it. If you think this new issue 
  | will not cause substantial delay, please introduce it. My proposed 
  | wording would be:

(even before this gets an issue number, etc...)   This all looks fine
to me.  Include it in the doc.

What's more, if we can get people implementing LL's to actually do this,
we may be able to also get them to improve the rest of the networking
stacks - there are far too many systems where the drivers simply don't
make this kind of state change available to the network stack at all,
and if we can contribute to getting that fixed, because of this need
for LL address probing, that's a very good thing.

kre