Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft

babatke@ra.rockwell.com Thu, 08 July 2004 14:05 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22502; Thu, 8 Jul 2004 10:05:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiYk0-0006yg-8X; Thu, 08 Jul 2004 09:15:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiY2n-0002GF-Dy for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 08:30:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16977 for <dhcwg@ietf.org>; Thu, 8 Jul 2004 08:30:22 -0400 (EDT)
From: babatke@ra.rockwell.com
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiY2h-0006IE-Lt for dhcwg@ietf.org; Thu, 08 Jul 2004 08:30:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiY0V-0005Va-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 08:28:08 -0400
Received: from mkedef1.rockwellautomation.com ([208.22.104.18] helo=raclesmtp01.ra.rockwell.com) by ietf-mx with esmtp (Exim 4.12) id 1BiXyr-0004j5-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 08:26:25 -0400
To: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002
Message-ID: <OF4BB0B60D.D7213ABE-ON85256ECB.00442327-85256ECB.004445E9@ra.rockwell.com>
Date: Thu, 8 Jul 2004 08:26:11 -0400
X-MIMETrack: Serialize by Router on RACleSMTP01/Cleveland/RA/Rockwell(Release 5.0.11 |July 24, 2002) at 07/08/2004 08:26:24 AM, Serialize complete at 07/08/2004 08:26:24 AM
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1266130667=="
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

> I guess I am missing the value of formality that
> distinguishes between the "probe" ARP-request and the
> "announce" ARP-request. The DHCP specification of an
> ARP-request followed by an ARP-reply always made sense
> to me.

Not trying to turn this into a discussion/critique of
the IPv4 ACD mechanism ... but the ARP "probe" is an ARP
request with the sender IP address set to all 0, so that
other hosts' ARP caches aren't affected.  The "announce"
message then has the sender IP filled in (and so, when sent
after the probing finds no conflict, results in ARP
caches being updated).


> "Ongoing conflict detection and defense" appears
> an unnecessary overhead unless hosts make up addresses
> rather than relying on a simple allocator such as DHCP to
> assign them. It would have been easy enough to define an
> initial election mechanism for which host on a subnet,
> lacking a DHCP server, should provide simple address
> allocation. The result would be a tiny amount of extra work
> for one host instead of all the "ongoing conflict detection
> and defense" for all hosts.

Again ... don't want to critique the ACD mechanism, but it's not
really much overhead to do ongoing detection.  You just have to
recognize that another host has issued an ARP with your address.

To give this some DHCP context ... in the industrial application
space (which is where I work), it is a very real possibility
to have a mixed network, where some devices get addresses via DHCP,
and some have addresses manually configured (e.g., if the device
doesn't support DHCP).

And in an industrial control application, address conflicts can
be a serious problem.  Therefore, even devices who obtain their
addresses via a DHCP server need to be able to detect address
conflicts and take an action that is appropriate for the 
application.   Stuart Cheshire's mechanism seems to make sense.

Brian Batke
Rockwell Automation
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg