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

Stuart Cheshire <> Mon, 02 August 2004 22:54 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA12220; Mon, 2 Aug 2004 18:54:26 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Brisg-0000op-Lb; Mon, 02 Aug 2004 15:53:58 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1Briog-0007Fp-Hi for; Mon, 02 Aug 2004 15:49:50 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA00200 for <>; Mon, 2 Aug 2004 15:49:48 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BrirZ-00039o-N6 for; Mon, 02 Aug 2004 15:52:52 -0400
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id i72Jp9wF020526 for <>; Mon, 2 Aug 2004 12:51:09 -0700 (PDT)
Received: from ( by (Content Technologies SMTPRS 4.3.6) with ESMTP id <>; Mon, 2 Aug 2004 12:49:15 -0700
Received: from [] ( []) by (8.12.11/8.12.11) with SMTP id i72JnCQg004282; Mon, 2 Aug 2004 12:49:13 -0700 (PDT)
Message-Id: <>
Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft
Date: Mon, 02 Aug 2004 12:49:15 -0700
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <>
To: Ted Lemon <>,
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: DHCP discussion list <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>I think it's worth having a standard that says what the right thing to 
>do is.   Stuart's draft seemed like a good candidate, but did not get 
>widespread support from the DHC working group, if I remember correctly.

I would say it got luke-warm support.

I plan to update the draft, as soon as I get time.

>   There was also some question as to whether it was even on-topic for 
>the working group, since it actually changes the semantics of ARP 

No, it doesn't change ARP semantics in any way. Everything it recommends 
is 100% consistent with RFC 826.

The question of whether to announce via ARP request or response is 
something that really doesn't matter, and is therefore the thing 
guaranteed to generate the greatest amount of debate. As John Schnizlein 
correctly pointed out, "RFC 826 explicitly does not discriminate between 
request or reply messages before updating its table".

Here's what I plan to put in the next draft:

Why are ARP Announcements performed using ARP Request packets and not
ARP Reply packets?

There are two reasons, one is historical precedent, and the other is

The historical precedent is that Gratuitous ARP is described in Stevens
Networking [Ste94] as using ARP Request packets. What Stevens describes
as Gratuitous ARP is what this document calls an ARP Announcement. BSD
Unix, Windows, Mac OS 9, Mac OS X, etc. all use ARP Request packets as
described in Stevens. At this stage, trying to mandate that they all
switch to using ARP Reply packets would be futile.

The practical reason is that ARP Request packets are more likely to work
correctly with more existing ARP implementations, some of which may not
implement RFC 826 correctly. The Packet Reception rules in RFC 826 state
that the opcode is the last thing to check in packet processing, so it
really shouldn't matter, but there may be "creative" implementations
that have different packet processing depending on the ar$op field, and
there are several reasons why these are more likely to accept gratuitous
ARP Requests than gratuitous ARP Replies:

* An incorrect ARP implementation may expect that ARP Replies are only
sent via unicast. RFC 826 does not say this, but an incorrect
implementation may assume it, and the "principle of least surprise"
dictates that where there are two or more ways to solve a networking
problem that are otherwise equally good, the one with the fewest unusual
properties is the one likely to have the fewest interoperability
problems with existing implementations. An ARP Announcement needs to
broadcast information to all hosts on the link. Since ARP Request
packets are always broadcast, and ARP Reply packets are not, receiving
an ARP Request packet via broadcast is less surprising than receiving an
ARP Reply packet via broadcast.

* An incorrect ARP implementation may expect that ARP Replies are only
received in response to ARP Requests that have been issued recently by
that implementation. Unexpected unsolicited Replies may be ignored.

* An incorrect ARP implementation may ignore ARP Replies where ar$tha
doesn't match its hardware address.

* An incorrect ARP implementation may ignore ARP Replies where ar$tpa
doesn't match its IP address.

In summary, there are more ways that an incorrect ARP implementation
might plausibly reject an ARP Reply (which usually occurs as a result of
being solicited by the client) than an ARP Request (which is already
expected to occur unsolicited).

Stuart Cheshire <>
 * Wizard Without Portfolio, Apple Computer, Inc.

dhcwg mailing list