[dhcwg] IPv4 Address Conflict Detection

Stuart Cheshire <cheshire@apple.com> Mon, 04 February 2002 20:26 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05200 for <dhcwg-archive@odin.ietf.org>; Mon, 4 Feb 2002 15:26:48 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28901 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 15:26:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26876; Mon, 4 Feb 2002 14:44:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26857 for <dhcwg@ns.ietf.org>; Mon, 4 Feb 2002 14:44:40 -0500 (EST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04183 for <dhcwg@ietf.org>; Mon, 4 Feb 2002 14:44:35 -0500 (EST)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g14JiaQ14760 for <dhcwg@ietf.org>; Mon, 4 Feb 2002 11:44:36 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58dd5e6a1d118164e13b4@mailgate2.apple.com>; Mon, 4 Feb 2002 11:44:34 -0800
Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g14JiY026372; Mon, 4 Feb 2002 11:44:34 -0800 (PST)
Message-Id: <200202041944.g14JiY026372@scv2.apple.com>
Date: Mon, 04 Feb 2002 11:44:34 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: DHCP discussion list <dhcwg@ietf.org>
cc: mobile-ip@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: [dhcwg] IPv4 Address Conflict Detection
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

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 <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg