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

> 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