On Fri, 2006-31-03 at 17:00 -0800, David Daney wrote: > jamal wrote: > > On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote: > >
> > While the patch does seem reasonable - given the link local addresses > > are well defined, I am curious why is this not being done in the user > > space apps you mention? > > The user space apps do broadcast for the portion of the protocol used to > probe and claim an address. The kernel ARP driver is relied on to > satisfy normal arp requests. If everyone using link local is supposed to be making a claim first, then why do you need to worry about already established vertices? i.e a new node coming in will broadcast; a node already claiming the IP will respond and supposedly the new node will pick the next link local and retry with another broadcast. Is this insufficient? > > The only time linux ever sends unicast ARPs is when it is pretty much > > established who owns the IP address i.e neighbor is reachable. > > Broadcasts are always sent at the beginning when it hasnt been > > validated if things are sane. In other words, conflict resolution > > is achievable from user space (ex look at iproute2/ip/ifcfg). > > > > This is the key. RFC 3927 section 2.5 requires broadcast on the > 169.254.0.0/16 network when normally ARP would unicast. > And thats the part i didnt understand. Note my question above. > On a switched network that has been partitioned but then healed, you may > never see an address conflict unless *all* ARP packets are broadcast. > For better or worse the RFC requires broadcast. > This may be true for a lot of OSes - but possibly not for Linux (given Linux actually follows a very robust state transition that will catch. Did you actually run into a problem or was this a pharmacy-cowboy raid to look for bugs/non-conformance? Can you describe the problem you encountered? > The alternative would be to disable ARP on an interface if it were > configured on the 169.254.0.0/16 network and handle the entire (slightly > modified) ARP protocol from a user space daemon. The current daemons do > *not* do it this way. > I am not sure you even need to do that - but lets not digress. > The patch adds 13 bytes (6 machine instructions) to arp.o on on i686, > from an efficiency point of view it make sense to do it in the kernel > driver and not duplicate the entire ARP in user space. > > I suppose one could add a configure option to conditionally include this > code, but I would not go so far as to suggest it. i am just curious as whether it is achievable in user space or not. Clearly if achievable in user space that would be the preference. Otherwise it is such a small patch and i am indifferent. 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
