lkml.org 
[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Broadcast ARP packets on link local addresses (Version2).
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-07 18:20    [W:0.370 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site