Subject: [dhcwg] IPv4 Address Conflict Detection

From: Stuart Cheshire <[email-masked]>
Date: Mon, 4 Feb 2002 11:44:34 -0800

At the DHC WG meeting in Salt Lake City we briefly talked about address 
conflict detection. The feedback I got was that while it is definitely 
useful to nail down a clear specification of how do do address conflict 
detection properly, it doesn't have an obvious natural "home" in any 
current IETF WG, so I should just solicit feedback and then send it in as 
an individual submission. The two working groups we felt had expertise in 
this area are DHC and MOBILEIP, hence this email:

----------------

From time to time people ask how Mac OS, Windows, and other OSs do that 
thing they do where they give an error message if two hosts are 
accidentally configured with the same IP address.

Detecting address conflicts is not difficult, but to date there has been 
no IETF Standard specifying how to do it. The only RFC I could find that 
even mentions IPv4 address conflict detection is RFC 2131, where it says 
things like:

    If the client detects that the address is already in use
    (e.g., through the use of ARP), the client MUST send
    a DHCPDECLINE message to the server

Unfortunately, RFC 2131 doesn't go into much detail about trivia like how 
many ARP packets to send, how long to wait, etc. This is not a criticism 
of RFC 2131, because defining IPv4 address conflict detection is rightly 
outside the scope of RFC 2131. Ideally, there should have been an 
existing specification for RFC 2131 to reference, like this:

    If the client detects that the address is already in use [RFC xxxx],
    the client MUST send a DHCPDECLINE message to the server

Sadly, that specification did not exist when RFC 2131 was written. To 
remedy this, I have written a short draft specifying how to detect 
address conflicts.

<http://www.ietf.org/internet-drafts/draft-cheshire-ipv4-acd-00.txt>

I'm sending this email not because I think that DHC or MOBILEIP ought to 
take on this work, but because I think that if it eventually becomes an 
RFC then DHC and MOBILEIP may want to reference it in their own 
standards, so I want to give everyone a chance to take a look and see if 
they like what it says.

DHCP depends on a conflict detection mechanism in order to trigger a DHCP 
DECLINE packet. My hope is that this draft is a clear specification of 
how to perform that conflict detection, so that if/when RFC 2131 is 
updated, it can reference this specification instead of again saying, 
"e.g., through the use of ARP."

I think it makes sense to publish IPv4 Address Conflict Detection as a 
separate standard, because while address conflict detection is important 
for a DHCP client, it is useful no matter how a host is configured. If a 
host is configured manually, then address conflict detection allows the 
host to display an error message if two hosts are accidentally given the 
same address. If a host is using a Zeroconf self-assigned link-local 
address, then address conflict detection is the mechanism that tells the 
host it needs to select a different address.

Right now, as written, draft-00 specifies that a host probe the network 
for 8-10 seconds before beginning to use an IP address. For a desktop 
machine using DHCP, this is probably fine. For a small mobile device, it 
may not be fine. A small mobile device may want to be allowed to access 
the network much quicker than that. For this reason, feedback from 
MOBILEIP would be good. One of the problems on today's networks is that 
Ethernet switches that implement spanning tree often silently discard all 
packets for many seconds, which makes it hard to say how long a host 
should probe before using an address. One possibility is that we could 
revise the draft to say that on networks where successful connectivity 
can be determined by the hardware with some acceptable degree of 
certainty, all the timeouts can be ten times shorter than currently 
specified: i.e. 0-200ms initial delay, four packets 200ms apart, for a 
total probing time of 800-1000ms. Thoughts?

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 5 Feb 2002 06:32:14 +0100 (MET)

I think the idea of probing and waiting _before_ using an address is
completely wrong. Since it involves waiting for something _not_ to
happen. The better approach is to detect the conflict -- if there is
one. See:
@misc{ vatn-effect,
         author = "Jon-Olov Vatn and Gerald Q. Maguire Jr.",
	  title = "The effect of using co-located care-of addresses on macro
	            handover latency",
            url = "http://citeseer.nj.nec.com/264743.html" }

ftp://ftp.it.kth.se/Reports/ts/1998/nts14-coloc.pdf

This paper shows that the DHCP server can be doing testing of
addresses in advance and this significantly reduce the time required
to assign and address. This is critical if you are going to give a
mobile device an IP address on a new segment when it arrive and avoid
having to drop packets for it (for example from an audio stream).

See also:

Jon-Olov Vatn, "Long Random Wait Times for Getting a Care-of Address
are a Danger to Mobile Multimedia", 1999 IEEE International Workshop
on Mobile Multimedia Communications (MoMuC'99), 15-17 November 1999,
San Diego, CA USA.
   http://www.it.kth.se/~vatn/research/momuc-copyright.pdf

For his licentiate thesis which includes the above and more see:
  http://www.it.kth.se/~vatn/mac/lic_prop.fm5.ps

Chip

---

From: "s. goswami" <[email-masked]>
Date: Tue, 5 Feb 2002 00:58:56 -0500 (EST)

If a DHCP server is used, should not it know what addresses are
usuable and what not ? Why should the host's DHCP client be
reponsible for figuirng out if the IP addresses is all ready
being used ? If DHCP client figures out that the IP address
is being us but the DHCP server can not figure that out, would
not there be a problem (i.e if a particular MAC address is offered
a particular IP adress as is done in many cases) ?

---

From: [email-masked]
Date: Tue, 5 Feb 2002 09:54:46 -0500

From: Gerald Maguire <[email-masked]>

   one.

IMHO, detecting address conflicts is not a matter of a single
strategy.  For instance, if there aren't resource limitations, DHCP
clients should check for address conflicts, but DHCP servers should
also.  Hosts should also continuously monitor their interfaces for
evidence of duplicate addresses (e.g., ARPs from other hosts holding
the same address).

Especially because this is the first attempt to formalize address
conflict detection, we should be documenting all methods that are
known to be useful, preferably with notes on their costs and benefits,
and circumstances in which they are known to be particularly useful.

Dale