On Sat, 2006-01-04 at 15:25 +1100, Herbert Xu wrote:
> On Fri, Mar 31, 2006 at 09:49:31PM -0500, jamal wrote:
[..]
> > 
> > my understanding: the sender is trying to claim that IP and is setting
> > the destination to the IP it is trying to claim and see if someone
> > responds.
> 
> Are you sure? I read this from Section 2.5:
> 
>    All ARP packets (*replies* as well as requests) that contain a Link-
>    Local 'sender IP address' MUST be sent using link-layer broadcast
>    instead of link-layer unicast.  This aids timely detection of
>    duplicate addresses.  An example illustrating how this helps is given
>    in Section 4.
> 

Ok, its a little more than grat arp (which i assumed it was). However,
the cause-fatale given in section 4 for why you wanna broadcast does
sound very lame. To quote: You do this in case "two disjoint network
links are joined".
I translate this to mean that somehow someone is going to take two hubs
or two switches of already established connections and join them
together and therefore linklocal addresses in one broadcast domain will
possibly conflict with linklocal in the other - it didnt seem practical
at all. I could be wrong and there maybe other cases not mentioned in
the RFC where you would need to do this. Hopefully, the original poster
can explain what kind of problems they saw that prompted the patch.
[..]
> So it is clear to me that the idea is that the conflictee will see the
> broadcast from the conflicter bearing the conflicter's source IP address
> which is in the 169.254/16 network.
> 
> The destination IP on the other hand can be anywhere.
> 
> BTW, I like your idea of moving STP to user-space.  In fact I think we
> can extend it to move ARP to user-space as well. 

Theres some arp user space daemon attempts already. The most prominent
is by alexey in iproute2/misc/arpd.c; i have a feeling its a little
stagnated.

>  Hopefully when we have
> proper xfrm resolution queueing it will be a template that we can reuse
> for all cases where we need user-space help to determine the fate of
> packet in kernel-space.
> 

indeed arpd resolution is similar to acquires in a few ways - check it
out; control messages are sent to user space using netlink.

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

Reply via email to