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

From: Erik Guttman <[email-masked]>
Date: Tue, 22 Jun 2004 14:06:57 +0200 (CEST)

Folks,

Let's arrive at a decision within the next week about these proposed
changes.  If I hear nothing or there is no serious dissent, I will
recommend we make the changes.  Please respond by June 29, 2004.

I mention the section numbers where the changes are made to assist your
evaluation.

Here is my opinion about the changes amount to:

START_WAIT

1) change:     START_WAIT renamed to PROBE_WAIT
   section:    1.3
   rationale:  esthetic
   impact      changes must be consistent

2) change      START_WAIT renamed to PROBE_WAIT
   section:    2.2.1
   rationale   esthetic
   impact      changes must be consistent

3) change      START_WAIT renamed to PROBE_WAIT
   section     9
   rationale   esthetic
   impact      changes must be consistent

ANNOUNCE_N

1) change:     ANNOUNCE_N renamed to ANNOUNCE_NUM
   section:    1.3
   rationale:  as 2)
   impact:     all references must be consistent

2) change      ANNOUNCE_N renamed to ANNOUNCE_NUM
   section     2.4
   rationale:  esthetic, maybe the new constant is slightly clearer
   impact:     all references must be consistent

3) change      ANNOUNCE_N renamed to ANNOUNCE_NUM
   section     9
   rationale   as 2)
   impact      all references must be consistent

WATCH_WAIT

1) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    1.3
   rationale:  as 3)
   impact:     all references must be consistent

2) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    2.5
   rationale:  as 3)
   impact:     all references must be consistent

3) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    9
   rationale:  the naming change is esthetic.
               the text for WATCH_WAIT in draft 15 inappropriate, it
               should changed from:

Was:
    DEFEND_INTERVAL     10 seconds  (after probes, wait for defense)
    WATCH_WAIT          10 seconds  (time to continue to defend your address,
                                     for IEEE 802 networks)

Becomes:
    DEFEND_INTERVAL     10 seconds  (min interval between defensive ARPs)

   impact:     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.

DEFEND_INTERVAL

1)  change     DEFEND_INTERVAL becomes ANNOUNCE_WAIT

     from:

   When ready to begin probing, the host should then wait for a random
   time interval selected uniformly in the range zero to START_WAIT
   seconds, and should then send PROBE_NUM probe packets, each of these
   probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart.

   If during this period, from the beginning of the probing process
   until DEFEND_INTERVAL seconds after the last probe packet is sent,
         ^^^^^^^^^^^^^^^
   the host receives any ARP packet (Request *or* Reply) on the
   interface where the probe is being performed where the packet's
   'sender IP address' is the address being probed for, then the host
   MUST treat this address as being in use by some other host, and MUST
   select a new pseudo-random address and repeat the process.  In
   addition, if during this period the host receives any ARP probe where
   the packet's 'target IP address' is the address being probed for, and
   the packet's 'sender hardware address' is not the hardware address of
   the interfaces the host is attempting to configure, then the host
   MUST similarly treat this as an address collision and select a new
   address as above. This can occur if two (or more) hosts attempt to
   configure the same IPv4 Link-Local address at the same time.

    section    2.2.1
    rationale  This is an error:  This adds 9 seconds of needless delay.
    impact:

      This significantly changes the protocol operation.  Given a 10
      second constant, the protocol functions as follows.

       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]     -5
       probe  (instantaneous)
       wait   [DEFEND_INTERVAL=10]           13-15
       announce (instantaneous)
       wait   [ANNOUNCE_INTERVAL=2]          14-17

      That is, a host will wait
2)  change:    DEFEND_INTERVAL changed to ANNOUNCE WAIT

   was:

   becomes:
     rationale:
     impact:

3)  change     add ANNOUNCE_WAIT   1 second (delay before announcing)
               instead of DEFEND_INTERVAL 10 seconds (after probes wait
                                                      for defense)
    section    9
    rationale  see 1)
    impact     see 1)

On Mon, 21 Jun 2004, Stuart Cheshire wrote:

> >Stuart,
> >
> >Please send specific FROM/TO text change proposals and specify which
> >sections would change.
> >
> >Thanks,
> >
> >Erik
>
> Specific diffs attached.
>
> It's basically just a textual cleanup so the symbolic constants make
> sense and are internally consistent. Summary:
>
> START_WAIT      -> PROBE_WAIT
> DEFEND_INTERVAL -> ANNOUNCE_WAIT
> ANNOUNCE_N      -> ANNOUNCE_NUM (for consistency with PROBE_NUM)
> WATCH_WAIT      -> DEFEND_INTERVAL (min interval between defensive ARPs)
>
> Stuart Cheshire <[email-masked]>
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
>

---

From: Erik Guttman <[email-masked]>
Date: Tue, 22 Jun 2004 14:15:53 +0200 (CEST)

Oops - sorry, I sent the email before it was done - I wanted to add
the following:

On Tue, 22 Jun 2004, Erik Guttman wrote:
>       This changes the protocol operation.  Given a 10

         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.
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)

---

From: Erik Guttman <[email-masked]>
Date: Tue, 22 Jun 2004 14:46:03 +0200 (CEST)

Folks,

This is additional material to what I posted already, concerning
changing DEFEND_INTERVAL to ANNOUNCE_WAIT in the last paragraph of
section 2.2.1

Suggested change:

  WAS
    If, by DEFEND_INTERVAL seconds after the transmission of the last ARP
    probe no conflicting ARP Reply or ARP probe has been received, then
    the host has successfully claimed the desired IPv4 Link-Local
    address.

  note: DEFEND_INTERVAL is 10 seconds

  BECOMES
    If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP
    probe no conflicting ARP Reply or ARP probe has been received, then
    the host has successfully claimed the desired IPv4 Link-Local
    address.

  note:  ANNOUNCE_WAIT is proposed to be 1 second
   section: 2.2.1
   rationale: fixes a problem
   impact:

     This seriously impacts the protocol in that the host will wait either
     10 seconds or 1 second after the final probe in order to configure
     the address.  [I suggest that 2 seconds is the correct value here,
     as this is consistent with earlier work and only changed due to an
     editorial oversight.]

Note that in early drafts of the protocol, this was '2 seconds':

draft-ietf-zeroconf-ipv4-linklocal-07.txt

   If, by two seconds after the transmission of the last ARP probe
   no conflicting ARP reply has been received, then the host has
   successfully claimed the desired link-local address.

draft-ietf-zeroconf-ipv4-linklocal-12.txt &
draft-ietf-zeroconf-ipv4-linklocal-13.txt &
draft-ietf-zeroconf-ipv4-linklocal-14.txt

   If, by PROBE_MAX seconds after the transmission of the last ARP probe
   no conflicting ARP Reply or ARP probe has been received, then the
   host has successfully claimed the desired Link-Local IPv4 address.

  where:    PROBE_MAX              2 seconds

draft-ietf-zeroconf-ipv4-linklocal-15.txt

   If, by DEFEND_INTERVAL seconds after the transmission of the last ARP
   probe no conflicting ARP Reply or ARP probe has been received, then
   the host has successfully claimed the desired IPv4 Link-Local
   address.

  where:  DEFEND_INTERVAL     10 seconds  (after probes, wait for defense)

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 22 Jun 2004 15:36:44 +0100

This is clearly an editorial mixup rather than a technical disagreement.

I mildly prefer changing the name START_WAIT to PROBE_WAIT in two places (2.2.1 & 9) - this does not affect the standard but is an editorial improvement.

I mildly prefer changing the name ANNOUNCE_N to ANNOUNCE_NUM in three places (1.3, 2.4 & 9) - this does not affect the standard but is an editorial improvement.

The time in section 2.2.1 (currently called DEFEND_INTERVAL) after the last probe has been 2 seconds for a long time (many drafts). Changing it to 10 seconds was almost certainly an accident and should be rectified. I support making this 2 seconds (not 1 second) in section 9.

ANNOUNCE_WAIT is a very reasonable name for this constant since the next step in the process is to announce the address. I support changing the name DEFEND_INTERVAL to ANNOUNCE_WAIT in three places (2.2.1 twice & 9).

I mildly prefer changing WATCH_WAIT to DEFEND_INTERVAL since this is marginally clearer (it occurs in the section on defending an address).

I do not support the current text around WATCH_WAIT - separate mail to follow.

regards,
Philip Nye

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 22 Jun 2004 15:58:11 +0100

The use of the symbol WATCH_WAIT in draft 15 is incorrect. This issue is independent of whether the symbol is called WATCH_WAIT or DEFEND_INTERVAL.

The purpose of a symbolic name is to allow changes to the value to accommodate different situations without changes in the text of the document.

The symbol name must be the same for all networks but it's value may change from network to network. The current text only defines the *symbol name* for IEEE802 networks, rather than defining its value.

Proposed change in section 2.5

   (b) If a host currently has active TCP connections or other reasons
   to prefer to keep the same IPv4 address, and it has not seen any
   other conflicting ARP packets recently (for IEEE 802, within the last
                                           ^^^^^^^^^^^^^^
                                               DELETE
   WATCH_WAIT seconds) then it MAY elect to attempt to defend its
   address, by recording the time that the conflicting ARP packet was
   received, and then broadcasting one single ARP announcement, giving
   its own IP and hardware addresses as the sender addresses of the ARP.
   Having done this, the host can then continue to use the address
   normally without any further special action.  However, if this is not
   the first conflicting ARP packet the host has seen, and the time
   recorded for the previous conflicting ARP packet is recent (within
   WATCH_WAIT seconds for IEEE 802) then the host MUST immediately cease
                     ^^^^^^^^^^^^^
                         DELETE
   using this address and configure a new IPv4 Link-Local address as
   described above...
   
Becomes

   (b) If a host currently has active TCP connections or other reasons
   to prefer to keep the same IPv4 address, and it has not seen any
   other conflicting ARP packets recently (within the last
   WATCH_WAIT seconds) then it MAY elect to attempt to defend its
   address, by recording the time that the conflicting ARP packet was
   received, and then broadcasting one single ARP announcement, giving
   its own IP and hardware addresses as the sender addresses of the ARP.
   Having done this, the host can then continue to use the address
   normally without any further special action.  However, if this is not
   the first conflicting ARP packet the host has seen, and the time
   recorded for the previous conflicting ARP packet is recent (within
   WATCH_WAIT seconds) then the host MUST immediately cease
   using this address and configure a new IPv4 Link-Local address as
   described above...

and in section 9

Becomes

   WATCH_WAIT          10 seconds for IEEE 802 networks
                       currently unspecified for other network types
                       (time to continue to defend your address)

regards,
Philip Nye