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

From: Erik Guttman <[email-masked]>
Date: Tue, 8 Jun 2004 09:30:34 +0200 (CEST)

Over the course of the next week, ending June 15, 2004, please review the
latest internet draft specifying IPv4LL.  The goal is

 * to verify the changes we have agreed upon
 * to find any additional typographic or technical errors

Also - if any of the suggested resolutions of any zeroconf issues are not
acceptable to you, this is the time to express your concern.  Please
indicate how the resolution is flawed and why the process we arrived at it
was inadequate.

Thank you,

Erik Guttman
ZEROCONF WG Chair

---------- Forwarded message ----------
Date: Mon, 07 Jun 2004 15:43:54 -0400
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-zeroconf-ipv4-linklocal-15.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Zero Configuration Networking Working Group of the IETF.

	Title		: Dynamic Configuration of Link-Local IPv4 Addresses
	Author(s)	: B. Aboba, et al.
	Filename	: draft-ietf-zeroconf-ipv4-linklocal-15.txt
	Pages		: 31
	Date		: 2004-6-7

To participate in wide-area IP networking, a host needs to be
configured, either manually by the user or automatically from a
source on the network such as a DHCP server.  Unfortunately, such
external configuration information may not always be available.  It
is therefore beneficial for a host to be able to depend on a useful
subset of IP networking functions even when no configuration is
available.  This document describes how a host may automatically
configure an interface with an IPv4 address within the 169.254/16
prefix that is valid for communication with other devices connected
to the same physical (or logical) link.  Communication using Link-
Local IPv4 addresses is not suitable for communication with devices
not directly connected to the same physical (or logical) link.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-15.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-zeroconf-ipv4-linklocal-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-15.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Jun 2004 10:37:38 -0700

>         action time span                      total time
>         ------ ---------------------------    ----------
>         delay  [0..START_WAIT=1]              0-1
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     1-3
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     2-5
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     3-7
>         configure address! (instantaneous)
>         wait   [DEFEND_INTERVAL=1]            13-17
>         announce (instantaneous)
>         wait   [ANNOUNCE_INTERVAL=2]          14-17
>         announce (instantaneous)
>
>
>I have gotten this table wrong before, so please check it yourself.

No, the time-line as specified by draft-15 is:

         action  interval                       total time
         ------  ---------------------------    ----------
         delay   [0-1]
         probe 1                                 0-1
         wait    [1-2]
         probe 2                                 1-3
         wait    [1-2]
         probe 3                                 2-5
         wait    [10]
         configure address!                     12-15
         announce
         wait    [2]
         announce                               14-17

It takes 12-15 seconds before the host can start begin useful 
communications using the address.

>The alternative Stuart presents is:
>
>         action time span                      total time
>         ------ ---------------------------    ----------
>         delay  [0..START_WAIT=1]              0-1
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     1-3
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     2-5
>         probe  (instantaneous)
>         wait   [PROBE_MIN=1, PROBE_MAX=2]     3-7
>         configure address! (instantaneous)
>  *      wait   [DEFEND_INTERVAL=1]            4-8
>         announce (instantaneous)
>         wait   [ANNOUNCE_INTERVAL=2]          5-9
>         announce (instantaneous)

What I actually proposed was this:

         action  interval                       total time
         ------  ---------------------------    ----------
         delay   [0-1]
         probe 1                                 0-1
         wait    [1-2]
         probe 2                                 1-3
         wait    [1-2]
         probe 3                                 2-5
         wait    [1]
         configure address!                      3-6
         announce
         wait    [2]
         announce                                5-8

The only difference is that the wait before announcing (what I call 
ANNOUNCE_WAIT) is one second instead of ten.

It now takes 3-6 seconds before the host can start begin useful 
communications using the address.

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

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Jun 2004 10:08:28 -0700

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.