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

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
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 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 <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg