[PATCH] net: Broadcast ARP packets on link local addresses (Version2).

[PATCH] net: Broadcast ARP packets on link local addresses (Version2).

[David Daney]

From: David Daney

Here is a new version of the patch I sent March 31.  For background,
this is my description from the first patch:

> When an internet host joins a network where there is no DHCP server,
> it may auto-allocate an IP address by the method described in RFC
> 3927.  There are several user space daemons available that implement
> most of the protocol (zcip, busybox, ...).  The kernel's APR driver
> should function in the normal manner except that it is required to
> broadcast all ARP packets that it originates in the link local address
> space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.

> The current ARP code is non-compliant because it does not broadcast
> some ARP packets as required by RFC 3927.

> This patch to net/ipv4/arp.c checks the source address of all ARP
> packets and if the fall in 169.254.0.0/16, they are broadcast instead
> of unicast.

All of that is still true.

The changes in this version are that it tests the source IP address
instead of the destination.  The test now matches the test described
in the RFC.  Also a small cleanup as suggested by Herbert Xu.

Some comments on the first version of the patch suggested that I do
'X' instead.  Where 'X' was behavior different than that REQUIRED by
the RFC (the RFC's always seem to capitalize the word 'required').

The reason that I implemented the behavior required by the RFC is so
that a device running the kernel can pass compliance tests that
mandate RFC compliance.

If the patch is deemed good and correct, great, please apply it.

Othwise comments about how to improve it are always welcome.  But keep
in mind that I would like to end up with something that complies with
the RFC.

This patch is against 2.6.16.1

Signed-off-by: David Daney <ddaney@avtrex.com>

---

--- net/ipv4/arp.c.orig	2006-03-31 13:44:50.000000000 -0800
+++ net/ipv4/arp.c	2006-04-05 13:33:19.000000000 -0700
@@ -690,6 +690,11 @@ void arp_send(int type, int ptype, u32 d
 	if (dev->flags&IFF_NOARP)
 		return;
 
+        /* If link local address (169.254.0.0/16) we must broadcast
+         * the ARP packet.  See RFC 3927 section 2.5 for details. */
+	if ((src_ip & htonl(0xFFFF0000UL)) == htonl(0xA9FE0000UL))
+		dest_hw = NULL;
+
 	skb = arp_create(type, ptype, dest_ip, dev, src_ip,
 			 dest_hw, src_hw, target_hw);
 	if (skb == NULL) {

Re: Broadcast ARP packets on link local addresses (Version2).

[Janos Farkas]

On 2006-04-05 at 14:22:08, David Daney wrote:
> The changes in this version are that it tests the source IP address
> instead of the destination.  The test now matches the test described
> in the RFC.  Also a small cleanup as suggested by Herbert Xu.
>
> Some comments on the first version of the patch suggested that I do
> 'X' instead.  Where 'X' was behavior different than that REQUIRED by
> the RFC (the RFC's always seem to capitalize the word 'required').
>
> The reason that I implemented the behavior required by the RFC is so
> that a device running the kernel can pass compliance tests that
> mandate RFC compliance.

Sorry for chiming in this late in the discussion, but...  Shouldn't it
be more correct to not depend on the ip address of the used network,
but to use the "scope" parameter of the given address?

Example

# ip ad sh
...
N: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether ...
    inet 169.254.3.3/16 brd 169.254.255.255 scope link eth0
    inet ... scope global eth0

The only drawback is that the scope is usually set manually, and maybe
some tools don't handle it right now, since it's available since just a
few years :)  Scopes, when set right, also may do some appropriate
magic, as I understand, like selecting the correct the source address,
and not allowing link-local addresses to reach out to other scopes.
(Which is also mentioned in the RFC, but this strictness prevent
transparent NAT of clients to the internet.)

I did not look however, whether the scope is available on the place the
patch is modifying currently.  Does the idea look sane to anyone else?

> +        /* If link local address (169.254.0.0/16) we must broadcast
> +         * the ARP packet.  See RFC 3927 section 2.5 for details. */
> +     if ((src_ip & htonl(0xFFFF0000UL)) == htonl(0xA9FE0000UL))
> +             dest_hw = NULL;

Janos

Re: Broadcast ARP packets on link local addresses (Version2).

[David Daney]

Janos Farkas wrote:
> On 2006-04-05 at 14:22:08, David Daney wrote:
> 
>>The changes in this version are that it tests the source IP address
>>instead of the destination.  The test now matches the test described
>>in the RFC.  Also a small cleanup as suggested by Herbert Xu.
>>
>>Some comments on the first version of the patch suggested that I do
>>'X' instead.  Where 'X' was behavior different than that REQUIRED by
>>the RFC (the RFC's always seem to capitalize the word 'required').
>>
>>The reason that I implemented the behavior required by the RFC is so
>>that a device running the kernel can pass compliance tests that
>>mandate RFC compliance.
> 
> 
> Sorry for chiming in this late in the discussion, but...  Shouldn't it
> be more correct to not depend on the ip address of the used network,
> but to use the "scope" parameter of the given address?
> 

RFC 3927 specifies the Ethernet arp broadcast behavior for only 
169.254.0.0/16.  Presumably you could set the scope parameter to local 
for addresses outside of that range or even for protocols other than 
Ethernet.  Since broadcasting ARP packets usually adversely effects 
usable network bandwidth, we should probably only do it where it is 
absolutely required.  The overhead of testing the value required by the 
RFC is quite low (3 machine instructions on i686 is the size of the 
entire patch), so using some proxy like the scope parameter would not 
even be a performance win.

David Daney

Re: Broadcast ARP packets on link local addresses (Version2).

[Janos Farkas]

On 4/6/06, David Daney <ddaney@avtrex.com> wrote:
> Janos Farkas wrote:
> > Shouldn't it
> > be more correct to not depend on the ip address of the used network,
> > but to use the "scope" parameter of the given address?

> RFC 3927 specifies the Ethernet arp broadcast behavior for only
> 169.254.0.0/16.  Presumably you could set the scope parameter to local
> for addresses outside of that range or even for protocols other than
> Ethernet.  Since broadcasting ARP packets usually adversely effects
> usable network bandwidth, we should probably only do it where it is
> absolutely required.  The overhead of testing the value required by the
> RFC is quite low (3 machine instructions on i686 is the size of the
> entire patch), so using some proxy like the scope parameter would not
> even be a performance win.

Indeed, I just have a bad feeling about hardwiring IP addresses this deep.

The problems with "my" idea would be, summarily, after a day:

Q: Is there are reason to use broadcast ARP semantics for other IP
address ranges?
A: Maybe, but no RFC defines that.
Q: Is there are reason to NOT use broadcast ARP semantics for the
defined IP address ranges?
A: Maybe, but the RFC is against it.
Q: Is there a reason to expect people (and tools) to use/define scopes?
A: Probably, but it's still uncommon practice :)  I mean, how many of
us have 192.168.x.x addresses with "global" scope? I know I do.

I'm still in a losing position :)

Janos

Re: Broadcast ARP packets on link local addresses (Version2).

[jamal]

On Thu, 2006-06-04 at 09:17 -0700, David Daney wrote:
> Janos Farkas wrote:

> > Sorry for chiming in this late in the discussion, but...  Shouldn't it
> > be more correct to not depend on the ip address of the used network,
> > but to use the "scope" parameter of the given address?
> > 
> 

Excellent point! It was bothering me as well but i couldnt express my
view eloquently as you did.

> RFC 3927 specifies the Ethernet arp broadcast behavior for only 
> 169.254.0.0/16.

Thats besides the point. You could, for example, use 1.1.1.1/24 in your
network instead of the 10.x or 192.x; and i have seen people use 10.x
in what appears to be public networks. We dont have speacial checks for 
RFC 1918 IP addresses for example.

169.254.0.0/16 is by definition link local. I think point made by Janos
is we should look at the attributes rather than value.

Have your user space set it to be link local and then fix the kernel if
it doesnt do the right thing.

>   Presumably you could set the scope parameter to local 
> for addresses outside of that range or even for protocols other than 
> Ethernet.  Since broadcasting ARP packets usually adversely effects 
> usable network bandwidth, we should probably only do it where it is 
> absolutely required.  The overhead of testing the value required by the 
> RFC is quite low (3 machine instructions on i686 is the size of the 
> entire patch), so using some proxy like the scope parameter would not 
> even be a performance win.
> 

Again, that is beside the point. 

cheers,
jamal

Re: Broadcast ARP packets on link local addresses (Version2).

[David Daney]

jamal wrote:
> On Thu, 2006-06-04 at 09:17 -0700, David Daney wrote:
> 
>>Janos Farkas wrote:
> 
> 
>>>Sorry for chiming in this late in the discussion, but...  Shouldn't it
>>>be more correct to not depend on the ip address of the used network,
>>>but to use the "scope" parameter of the given address?
>>>
>>
> 
> Excellent point! It was bothering me as well but i couldnt express my
> view eloquently as you did.
> 
> 
>>RFC 3927 specifies the Ethernet arp broadcast behavior for only 
>>169.254.0.0/16.
> 
> 
> Thats besides the point. You could, for example, use 1.1.1.1/24 in your
> network instead of the 10.x or 192.x; and i have seen people use 10.x
> in what appears to be public networks. We dont have speacial checks for 
> RFC 1918 IP addresses for example.
> 

Following your logic through, It seems that you are advocating 
broadcasting *all* ARP packets on *all* link local addresses.  That 
would mean that on a 192.168.* switched Ethernet network with DHCP that 
twice as many ARP packets would be broadcast.

I don't think that is a good idea.  On networks with DHCP or statically 
allocated addresses, it would be a hard sell to tell people that they 
have to broadcast *all* ARP traffic even though there are neither 
standards that require nor suggest such action.

The scope parameter, as far as I can tell, is used to make routing 
decisions.  Overloading it to also implement the RFC 3927 ARP 
broadcasting requirement would result in generation of unnecessary 
network traffic in configurations that are probably the majority of 
Linux deployments.

> 169.254.0.0/16 is by definition link local. I think point made by Janos
> is we should look at the attributes rather than value.
> 

The converse is not true.  And that is my problem with this idea.

> Have your user space set it to be link local and then fix the kernel if
> it doesnt do the right thing.
> 

I could see adding an additional interface attribute that specifies link 
local, and then testing that.  But that adds substantially more overhead 
as you would have to allocate space for the attribute somewhere, and 
have extra code to allow setting/querying of the attribute from user space.

The requirement of RFC 3927 is very tightly targeted.  My patch does 
only what is required, no more.  It does not change ARP behavior for 
commonly deployed configurations.

> 
>>  Presumably you could set the scope parameter to local 
>>for addresses outside of that range or even for protocols other than 
>>Ethernet.  Since broadcasting ARP packets usually adversely effects 
>>usable network bandwidth, we should probably only do it where it is 
>>absolutely required.  The overhead of testing the value required by the 
>>RFC is quite low (3 machine instructions on i686 is the size of the 
>>entire patch), so using some proxy like the scope parameter would not 
>>even be a performance win.
>>
> 
> 
> Again, that is beside the point. 

It may be beside your point, I happen to think that it has some relevance.

David Daney

Re: Broadcast ARP packets on link local addresses (Version2).

[Mark Butler]

David Daney wrote:

> Following your logic through, It seems that you are advocating 
> broadcasting *all* ARP packets on *all* link local addresses.  That 
> would mean that on a 192.168.* switched Ethernet network with DHCP 
> that twice as many ARP packets would be broadcast.

192.168.* addresses are not considered "link local", they are rather 
"private" or "site local" addresses.

> The scope parameter, as far as I can tell, is used to make routing 
> decisions.  Overloading it to also implement the RFC 3927 ARP 
> broadcasting requirement would result in generation of unnecessary 
> network traffic in configurations that are probably the majority of 
> Linux deployments.

No extra network traffic, but there is some measurable overhead to 
looking up the scope in the routing table.

One problem is having this type of scheme behave properly by default, 
i.e. in the absence of user specified entries.  Having to create an 
entry for every interface in the system just to get RFC standard 
behavior is silly.

- Mark

Re: [PATCH] net: Broadcast ARP packets on link local addresses (Version2).

[Anand Kumria]

On Wed, 05 Apr 2006 14:22:08 -0700, David Daney wrote:

> From: David Daney
> 
> Here is a new version of the patch I sent March 31.  For background,
> this is my description from the first patch:
> 
>> When an internet host joins a network where there is no DHCP server,
>> it may auto-allocate an IP address by the method described in RFC
>> 3927.  There are several user space daemons available that implement
>> most of the protocol (zcip, busybox, ...).  The kernel's APR driver
>> should function in the normal manner except that it is required to
>> broadcast all ARP packets that it originates in the link local address
>> space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.
> 
>> The current ARP code is non-compliant because it does not broadcast
>> some ARP packets as required by RFC 3927.
> 
>> This patch to net/ipv4/arp.c checks the source address of all ARP
>> packets and if the fall in 169.254.0.0/16, they are broadcast instead
>> of unicast.
> 
> All of that is still true.
> 
> The changes in this version are that it tests the source IP address
> instead of the destination.  The test now matches the test described
> in the RFC.  Also a small cleanup as suggested by Herbert Xu.
> 
> 
> If the patch is deemed good and correct, great, please apply it.

Could any of the network maintainers comment on this? It'd be nice if
the kernel was even more RFC compliant and, better, did the right
thing too.

Anand
 
> This patch is against 2.6.16.1
> 
> Signed-off-by: David Daney <ddaney@avtrex.com>
> 
> ---
> 
> --- net/ipv4/arp.c.orig	2006-03-31 13:44:50.000000000 -0800
> +++ net/ipv4/arp.c	2006-04-05 13:33:19.000000000 -0700
> @@ -690,6 +690,11 @@ void arp_send(int type, int ptype, u32 d
>  	if (dev->flags&IFF_NOARP)
>  		return;
>  
> +        /* If link local address (169.254.0.0/16) we must broadcast
> +         * the ARP packet.  See RFC 3927 section 2.5 for details. */
> +	if ((src_ip & htonl(0xFFFF0000UL)) == htonl(0xA9FE0000UL))
> +		dest_hw = NULL;
> +
>  	skb = arp_create(type, ptype, dest_ip, dev, src_ip,
>  			 dest_hw, src_hw, target_hw);
>  	if (skb == NULL) {