Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes
Robert Elz <[email protected]> Wed, 05 May 2004 07:45:44 +0700
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
Date: Wed, 5 May 2004 01:02:06 +0200
From: Erik Guttman <[email protected]>
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