Subject: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes

From: Erik Guttman <[email-masked]>
Date: Wed, 5 May 2004 01:02:06 +0200

Please post discussion of this issue to the mailing list over the 
next two weeks
ending May 18, 2004.  In order to accept this issued, we will need a strong WG
consensus given that this is very late in the process.

Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of
current issues and their status.

[LL57]

Description of Issue:		Straightforward editorial fixes
Submitter Name:		Stuart Cheshire
Submitter Email Address:	[email-masked]
Date first submitted:		04 May 04
Reference:
Comment Type ['t'ech|'e'dit]:	e
Prio ['S' Must|1 should|2 may]:	1
Section:			1.9
Rationale/Explanation:
Lengthy Description:
Requested Change:

---

>1.9.  When to configure a IPv4 Link-Local address

Search and replace "a IP" with "an IP"

---

[Stuart]

>2.4.  Announcing an Address
>
>    The host MUST then announce its claimed address by broadcasting
>    PROBE_N ARP announcements, spaced PROBE_MAX seconds apart.

Change to:

>  ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart

Add to section 9:

ANNOUNCE_N        2
ANNOUNCE_INTERVAL 2 seconds

---

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
>    ten seconds) then it MAY elect to attempt to defend its address

becomes

    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
|  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 using this
    address and configure a new IPv4 Link-Local address as described
    above.  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.

---

2.6.2

>    Whichever interface is used, if the destination address is in the
>    169.254/16 prefix (excluding the address 169.254.255, which is the
>    broadcast address for the Link-Local prefix), then the sender MUST

169.254.244

becomes

169.254.255.255

---

3.1

>  >   This answer is usually answered by referring to a routing table,
>  >   which expresses which interface (with which address) to send, and how

becomes

   This question is usually answered by referring to a routing table,
   which expresses on which interface (with which address) to send, and how

---

from:

>  >3.4.  Unintentional Autoimmunity

to:

>  >3.4.  Unintentional Autoimmune Response

---

6.1
From:

    IPv4 Link-Local addresses used by an application may change over
    time. Some application software encountering an address change will
    fail. For example, client TCP connections will fail,

to:

    IPv4 Link-Local addresses used by an application may change over
    time. Some application software encountering an address change will
    fail. For example, existing client TCP connections will be aborted,

---

6.2
From:

>    If the FTP client transmits its passive IPv4

to:

>    If the FTP client transmits its stale out-of-date passive IPv4

---

---

From: Ralph Droms <[email-masked]>
Date: Tue, 04 May 2004 21:16:48 -0400

Comments inline.

- Ralph

At 01:02 AM 5/5/2004 +0200, Erik Guttman wrote:
>Please post discussion of this issue to the mailing list over the next two 
>weeks

OK with me.

>ANNOUNCE_INTERVAL 2 seconds

OK with me.

>    in an endless loop with both hosts trying to defend the same address.

Is the replacement of "ten" with "WATCH_WAIT" the only proposed change?  If
so, I agree - noting that "WATCH_WAIT" needs to be added to the section
in which constants are defined.

>>    broadcast address for the Link-Local prefix), then the sender MUST

Assuming 169.254.255 is what is replaced, this change is OK with me.

>   which expresses on which interface (with which address) to send, and how

OK with me.

>>  >3.4.  Unintentional Autoimmune Response

OK with me.

>    fail. For example, existing client TCP connections will be aborted,

OK with me.

>>    If the FTP client transmits its stale out-of-date passive IPv4

OK with me.

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 May 2004 07:45:44 +0700

Date:        Wed, 5 May 2004 01:02:06 +0200
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <a05200f16bcbdce7de92d@[80.139.178.51]>

Most of this issue is (or seems to be) editorial, and if someone
checks, and decides that the changes are all editorial (changing "a IP"
to "an IP" clearly is) then I have no problems with most of them.

However, this one, which is mixed in with all that noise ...

  | 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
  | >    ten seconds) then it MAY elect to attempt to defend its address
  | 
  | becomes
  | 
  |     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
  | |  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 using this
  |     address and configure a new IPv4 Link-Local address as described
  |     above.  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.

if fundamentally wrong.

I know that Stuart believes that the most important issue is to
prevent 2 hosts getting locked up, each refusing to abandon a
duplicated address.    I disagree.   For me, the most important issue
is to prevent the trivial ability of a host to cause my system to
abandon its addresses after which it can take over all my TCP
connections (they're on the same link, by definition using LL addresses,
on many media types, that means the "bad guy" has all the info needed
to pick up my connections, after I have abandoned the address, and
what's more, with nothing to interfere with his continued use of the
connections - my host won't be sending any packets that might get
in the way, which it would if I had retained the address).

By all means, Stuart can make his implementations release addresses as
soon as it sees a conflict (or a 2nd conflict) - I just won't use anything
that absurd on any system I care about.   There's no need for the spec
to prohibit that kind of behaviour.   But the spec must not try and
enforce it.

Leave this text as it is.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 May 2004 11:39:06 -0000

Comments interspersed. One or two are genuine editorial mistakes, several appear to be pedantic filibusters!

> Search and replace "a IP" with "an IP"

[philip]
I'm comfortable with either.

> ANNOUNCE_INTERVAL 2 seconds

[philip]
The change is probably better. I believe this is more than an editorial change since it decouples ANNOUNCE_INTERVAL from PROBE_MAX.

>     in an endless loop with both hosts trying to defend the same address.

[philip]
I see no need for the change.

However, if we are to parameterize WATCH_WAIT as proposed we should do it properly. The text should read:

"...and it has not seen any other conflicting ARP packets within WATCH_WAIT seconds then it MAY elect..."

and in section 9:
WATCH_WAIT    10 seconds for IEEE802

> >    broadcast address for the Link-Local prefix), then the sender MUST

[philip]
Agreed

>    which expresses on which interface (with which address) to send, and how

[philip]
Agree changing "answer" to "question".
Neutral on adding "on" - it is a very pedantic change.

> >  >3.4.  Unintentional Autoimmune Response

[philip]
This change adds nothing so don't make it.

>     fail. For example, existing client TCP connections will be aborted,

[philip]
It's way too late to make trivial changes like this - there is no grammatical error, the difference in meaning is minimal and it is an example not a technical definition.

> >    If the FTP client transmits its stale out-of-date passive IPv4

[philip]
It's way too late to make trivial changes like this - there is no grammatical error, the difference in meaning is minimal and it is an example not a technical definition.