Subject: Re: Draft status?

From: Stuart Cheshire <[email-masked]>
Date: Mon, 8 Apr 2002 23:18:08 -0700

>I skimmed recent posts and could not understand for sure whats
>the current link-local draft state ... the current draft seems
>to be the 04 version and expiration date of January ...
>
>I saw the 'summary of issues...' post from November ... 
>
>Is there any idea if and when link-local will become an RFC?
>
>Thanks
>   -Nevo

I'm glad you asked :-)

As a result of IETF Last-Call on Draft-04, a number of issues were 
raised. The "Summary of Issues" email thread in November proposed 
resolutions to all those issues.

Also, in the DHC Working Group at the Salt-Lake City IETF meeting, one of 
our Area Directors made a very valid observation -- that waiting 8-10 
seconds before using an IP address may be unacceptable for many new 
devices that wish to use Zeroconf. If the Working Group is in agreement, 
I think we can address this concern with the addition of the following 
text:

>2.3 Shorter Timeouts on Appropriate Network Technologies
>
>   The time values specified above are intended for use on technologies
>   such as Ethernet, where switches that implement Spanning Tree
>   [802.1d] often silently discard all packets for several seconds. The
>   time values specified above result in a delay of 8-10 seconds before
>   a chosen IP address may be used. For a desktop machine using DHCP,
>   this may not be a great problem, but for other types of device,
>   particularly portable hand-held wireless devices, a ten-second delay
>   before networking services becomes available may not be acceptable.
>   For this reason, shorter time values may be used on network
>   technologies that allow the device to determine when the link has
>   become active and can be reasonably trusted to deliver packets
>   reliably. On these network technologies the recommended time values
>   are: The host should first wait for a random time interval selected
>   uniformly in the range 0-200 milliseconds, and then send four probe
>   packets, waiting 200 milliseconds after each probe, making a total
>   delay of 800-1000 milliseconds before a chosen IP address may be
>   used.
>
>   Should future versions of the IEEE Spanning Tree Protocol be enhanced
>   to inform clients when the link is ready to begin forwarding packets,
>   then the shorter time values may be used on these networks too.

I urge anyone with an opinion for or against this text to send mail to 
the list. If we can get consensus on this last remaining timeout 
question, then as soon as I hear from our Area Directors and from Keith 
Moore that they approve of the resolutions to the earlier issues, I can 
submit draft-05 and request that the RFC Editor publish it as a Standards 
Track RFC.

For those eager to see a preview of what draft-05 should look like, the 
current working copy is available at:

<http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal-04bis.txt>

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

---

From: Brad Hards <[email-masked]>
Date: Tue, 9 Apr 2002 16:56:23 +1000

On Tue, 9 Apr 2002 16:18, Stuart Cheshire wrote:
<snip>
> I'm glad you asked :-)
Interestingly, this informative response doesn't actually answer the question 
:)

> devices that wish to use Zeroconf. If the Working Group is in agreement,
Seems reasonable.

> >   a chosen IP address may be used. For a desktop machine using DHCP,
I'm not sure what the DHCP reference is supposed to be for. Can you clarify

> >   technologies that allow the device to determine when the link has
Is this intended to mean media sense (aka the "link good" light) ?

> >   are: The host should first wait for a random time interval selected
s/should/SHALL?
and perhaps something along the lines of "waiting not less than 200 
milliseconds" for the interval between ARPs.
I am thinking of devices where we can start this process early in the boot 
cycle, and then do other initialisation things (which might take more than 
200ms), which is something productive to do instead of just sleeping for 
200ms.

> >   delay of 800-1000 milliseconds before a chosen IP address may be
Is the initial delay intended to avoid a whole stack of machines starting up 
together crashing down on the poor networking media at once?

> <http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal-04bis.txt>
I'm on it...

Brad

BTW: Thanks to whoever sprang for, and set up, those nice new(?) websites.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Apr 2002 07:19:19 -0700 (PDT)

> then the shorter time values may be used on these networks too.

Such a "future version" of IEEE Spanning Tree Protocol already
exists. It's called 802.1w "Rapid Spanning Tree". If you need more
information, you can correspond with Tony Jeffree. 

> the list. 

It's worth remembering that adhoc networking scenarios 
often do not involve switches (e.g. adhoc 802.11 wireless
networks). Adhoc wireless networks do meet the definition of "allowing the
device to determine when the link has become active". 

However, where authentication is required, an initial delay may be
inserted; since authentication may operate separately from ARP, there may
be no way for the ARP module to know what the appropriate time intervals
are in a given situation, just given information about the nature of the
link. 

As a result, it is difficult for one or even two
recommendations to fit all circumstances. I'd note that RFC 2462 takes
the approach of defining the variables involved, such as the number of
transmits (DupAddrDetectTransmits), the retransmission timer interval
(ReTransTimer), and the jitter interval
MAX_RTR_SOLICITATION_DELAY (default of 1 second).