Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

From: Stuart Cheshire <[email-masked]>
Date: Mon, 13 Jan 2003 11:33:58 -0800

>So, what's out of spec, other than the acd draft?   (In theory,
>if everyone did ARP exactly as specified, the request should
>also suffice instead of a reply (though it is a perverse kind of
>"request") - but in practice, ARP implementations don't tend to
>conform exactly to the spec, sending ARP reply (unsolicited reply)
>works...)

I propose adding the following text to the 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
practicality.

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 if 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 <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2003 15:51:33 -0600

> [...]

FWIW, I think this text is very helpful, and should be included in the 
draft.