BTW, what is the point of CCing lkml? This is a networking issue. People interested in networking discussions join netdev. I have taken it, please keep it that way.
On Fri, 2006-07-04 at 09:18 -0700, David Daney wrote: > 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 is what i am saying, yes, if you choose to define an arbitrary IPV4 address to be link local. In theory you should only define the 169 address. > That > would mean that on a 192.168.* switched Ethernet network with DHCP that > twice as many ARP packets would be broadcast. > I am not sure i followed that logic. If you define an address to be link local, you should expect to be living with that consequence. > 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. I am assuming you have some form of configuration, no? You should only configure an IP address to be link local if you really mean it to be so. > The scope parameter, as far as I can tell, is used to make routing > decisions. Overloading it to also implement the RFC 3927 ARP I think you should look at the code. IPV4 address configuration is not the same as routing configuration. The concept of scoping exists in v6 as well. > > broadcasting requirement would result in generation of unnecessary > network traffic in configurations that are probably the majority of > Linux deployments. > If you choose to configure something to be link local, then you should live with the consequences. > > 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. > 10.0.0.1 is not supposed to be routed outside either. But we dont stop people who are dumb enough to do it. > > 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. It exists. Just use it. For testing just use the ip utility. > 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. > A variation of your patch which checks if the address is link local attribute set is what is needed (instead of checking for address 169.x.x.x). User space sets 169.x.x.x to be linklocal when it installs it. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
