Re: [RFC] ARP notify option
On Wed, 7 Mar 2007 08:42:39 +0200 (EET) Pekka Savola <[EMAIL PROTECTED]> 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] 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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARP notify option
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 -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARP notify option
On Tue, 06 Mar 2007 15:18:07 -0600 "Chris Friesen" <[EMAIL PROTECTED]> 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. > > Chris I copied the ARP generation from other places that were doing gratuitous ARP already: Xen and irlan. Our local switch used REPLY's to do the same thing. One could imagine making it a ternary value and having 2 generate REQUEST's. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARP notify option
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. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARP notify option
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: > This adds another inet device option to enable gratuitous ARP > when device is brought up or address change. This is handy for > clusters or virtualization. This looks good. I'll test with Xen. What about the source addr selection? thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARP notify option
Stephen Hemminger wrote: > This adds another inet device option to enable gratuitous ARP > when device is brought up or address change. This is handy for > clusters or virtualization. > Thanks Stephen. Haven't tested this yet, but it definitely cleans up a warty corner of netfront. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ARP notify option
This adds another inet device option to enable gratuitous ARP
when device is brought up or address change. This is handy for
clusters or virtualization.
Tested on a normal device (not Xen).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |6 ++
include/linux/inetdevice.h |2 ++
include/linux/sysctl.h |1 +
net/ipv4/devinet.c | 16
4 files changed, 25 insertions(+)
--- net-2.6.22.orig/Documentation/networking/ip-sysctl.txt 2007-03-05
14:35:31.0 -0800
+++ net-2.6.22/Documentation/networking/ip-sysctl.txt 2007-03-05
16:46:47.0 -0800
@@ -732,6 +732,12 @@
The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}
+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.
+
arp_accept - BOOLEAN
Define behavior when gratuitous arp replies are received:
0 - drop gratuitous arp frames
--- net-2.6.22.orig/include/linux/inetdevice.h 2007-03-05 14:35:34.0
-0800
+++ net-2.6.22/include/linux/inetdevice.h 2007-03-05 16:46:47.0
-0800
@@ -26,6 +26,7 @@
int arp_announce;
int arp_ignore;
int arp_accept;
+ int arp_notify;
int medium_id;
int no_xfrm;
int no_policy;
@@ -84,6 +85,7 @@
#define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter ||
(in_dev)->cnf.arp_filter)
#define IN_DEV_ARP_ANNOUNCE(in_dev)(max(ipv4_devconf.arp_announce,
(in_dev)->cnf.arp_announce))
#define IN_DEV_ARP_IGNORE(in_dev) (max(ipv4_devconf.arp_ignore,
(in_dev)->cnf.arp_ignore))
+#define IN_DEV_ARP_NOTIFY(in_dev) (ipv4_devconf.arp_notify ||
(in_dev)->cnf.arp_notify)
struct in_ifaddr
{
--- net-2.6.22.orig/include/linux/sysctl.h 2007-03-05 14:35:34.0
-0800
+++ net-2.6.22/include/linux/sysctl.h 2007-03-05 16:46:47.0 -0800
@@ -495,6 +495,7 @@
NET_IPV4_CONF_ARP_IGNORE=19,
NET_IPV4_CONF_PROMOTE_SECONDARIES=20,
NET_IPV4_CONF_ARP_ACCEPT=21,
+ NET_IPV4_CONF_ARP_NOTIFY=22,
__NET_IPV4_CONF_MAX
};
--- net-2.6.22.orig/net/ipv4/devinet.c 2007-03-05 14:35:34.0 -0800
+++ net-2.6.22/net/ipv4/devinet.c 2007-03-05 16:46:47.0 -0800
@@ -1089,6 +1089,14 @@
}
}
ip_mc_up(in_dev);
+ /* fall through */
+ case NETDEV_CHANGEADDR:
+ if (IN_DEV_ARP_NOTIFY(in_dev))
+ arp_send(ARPOP_REQUEST, ETH_P_ARP,
+in_dev->ifa_list->ifa_address,
+dev,
+in_dev->ifa_list->ifa_address,
+NULL, dev->dev_addr, NULL);
break;
case NETDEV_DOWN:
ip_mc_down(in_dev);
@@ -1495,6 +1503,14 @@
.proc_handler = &proc_dointvec,
},
{
+ .ctl_name = NET_IPV4_CONF_ARP_NOTIFY,
+ .procname = "arp_notify",
+ .data = &ipv4_devconf.arp_notify,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+ {
.ctl_name = NET_IPV4_CONF_NOXFRM,
.procname = "disable_xfrm",
.data = &ipv4_devconf.no_xfrm,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
