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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 2 Aug 2004 12:55:21 -0700

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

I really don't know what overhead you're talking about.

There are no extra packets to do ongoing conflict detection (and no 
change to existing packets). If you mean CPU overhead, there really isn't 
any, because this is just a tiny refinement to the existing code path for 
handling received ARP packets. All the draft says is that if you see 
someone else broadcast an ARP packet, and when you go to update your ARP 
cache you find that it's YOUR OWN IP address that you're about to update 
to point to some other machine's hardware address, that's bad news, and 
you probably shouldn't ignore it. That's all: When you observe that the 
network is broken, then you should at least alert the user in some way so 
that they have an idea what is wrong.

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

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

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 5 Aug 2004 11:41:50 -0700

>If it really doesn't matter, why are we having this discussion?  Are
>you proposing we change DHCP to use an ARP request for announcements?

I don't have any personal reason to want it to be one way rather than the 
other, but I do believe that a good specification shouldn't leave things 
unspecified. That means we need to decide whether the document will 
specify ARP request, or ARP reply. It matters little which it is, but we 
should decide.

I originally assumed that it would be logical to use a gratuitous ARP 
response, but when I started investigating, it seemed that everyone else 
thought otherwise.

Stevens, "TCP/IP Illustrated, Volume 1: The Protocols" (1994) specifies 
that hosts announce their new address using a broadcast ARP Request.

BSD systems announce their new address using a broadcast ARP Request.

Macintosh systems announce their new address using a broadcast ARP 
Request.

Windows systems announce their new address using a broadcast ARP Request.

So, despite what RFC 2131 may say, it appears that almost all deployed 
systems in the field actually use ARP Request.

Why?

I thought about it and compiled a list of all the reasons for picking one 
rather than the other (already posted to dhcwg), and found that on 
balance the evidence came out slightly in favour of using ARP Request 
(which may explain why that's what all the systems do).

In conclusion, (i) the arguments weigh slightly in favour of ARP Request, 
and (ii) most deployed systems in the field use ARP Request, so that's 
what I decided to write in the ACD draft.

To answer your question, we are having this discussion because this is 
one of those cases where it's equally possible for an intelligent person 
to argue either side of the argument. Whichever choice the document 
picks, there is unfortunately an opposing camp willing to fight 
indefinitely over the decision. If we change the document, then the other 
camp becomes willing to fight indefinitely to have it changed back.

I'm not proposing that we change DHCP. This draft is not DHCP. This draft 
is Address Conflict Detection as applied generally to any configuration 
mechanism, including manual static IP addresses. I'm documenting Address 
Conflict Detection AS IT EXISTS NOW and has existed for a decade or more. 
If in future DHCP wants to adopt this standardized Address Conflict 
Detection mechanism, that's a decision for DHC.