Re: [RFC] ARP notify option

Stephen Hemminger
2007-03-07T17:02:19Z

On Wed, 7 Mar 2007 08:42:39 +0200 (EET)
Pekka Savola <pekkas@netcore.fi> wrote:

> On Tue, 6 Mar 2007, Chris Friesen wrote:
> > Stephen Hemminger wrote:
> >> +arp_notify - BOOLEAN
> >> + Define mode for notification of address and device changes.
> >> + 0 - (default): do nothing
> >> + 1 - Generate gratuitous arp replies when device is brought up
> >> + or hardware address changes.
> >
> > Did you consider using gratuitous arp requests instead? I remember reading
> > about some hardware that updated its arp cache on gratuitous requests but not
> > gratuitous replies.
>
> You might be interested in taking a look at:
>
> http://tools.ietf.org/id/draft-cheshire-ipv4-acd
>
> There has been some follow-up discussion on this in the thread
> starting at:
>
> http://www1.ietf.org/mail-archive/web/int-area/current/msg00611.html
>
> In particular, you may be interested in this comment about ARP
> request and ARP reply for gratuitous ARP:
>
> http://www1.ietf.org/mail-archive/web/int-area/current/msg00669.html

Looks like REQUESTS make more sense. (See below). I will
rework this patch.

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

During IETF deliberation of IPv4 Address Conflict Detection from 2000
to 2005, a question that kept being asked repeatedly was, "Shouldn't
ARP Announcements be performed using gratuitous ARP Reply packets?"

On the face of it, this seems reasonable. A conventional ARP Reply
is an answer to a question. If in fact no question had been asked,
then it would be reasonable to describe such a reply as gratuitous.
This description would seem to apply perfectly to an ARP
Announcement: an answer to an implied question that in fact no one
asked.

However reasonable this may seem in principle, there are two reasons
why in practice ARP Request packets are the better choice. One is
historical precedent, and the other is practicality.

Expires 11th January 2006 Cheshire [Page 14]
\f
Internet Draft IPv4 Address Conflict Detection 11th July 2005

The historical precedent is that, as described above in Section 4,
Gratuitous ARP is described in Stevens Networking [Ste94] as using
ARP Request packets. 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).