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

From: [email-masked]
Date: Wed, 7 Jul 2004 15:53:31 -0400

> Just before the section of the RFC you quoted
> is the part that recommends that the client issue
> an ARP request to discover if the address is already
> in use. This part seems most like the 
> conflict detection part of ZeroConf.

Yes, this is the ARP "probe" that is more formalized
in the IPv4 ACD document.

> The part you quoted is there for the case when there
> is no other host with the address in question, but there
> might have been previously. That is why the (other host's)
> ARP caches are cleared.

The IPv4 ACD document calls this an ARP "announcement".
And the behavior is the same -- after probing for an
address and finding no conflict, you issue an ARP 
request for your own address, which causes ARP
caches to be updated. (except the DHCP RFC
says reply not request ... hence my question).

> The combination of both the request and the reply,
> which is clearer from the longer context of the text,
> first checks for a duplicate address, then provides other
> hosts a cache update for the host newly using the address.

Which is what the IPv4 ACD mechanism does ... but in a more
well-defined way, and it also includes 'ongoing conflict
detection and defense".

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 07 Jul 2004 19:11:02 -0400

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.

"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.

John

---

From: [email-masked]
Date: Thu, 8 Jul 2004 08:26:11 -0400

> 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