Herbert Xu wrote:
On Fri, Mar 31, 2006 at 09:49:31PM -0500, jamal wrote:
The RFC seems to talk about sender IP address instead though...
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.
I think you have a point here. The current patch works because the only
time ARP will be sending packets is if the sender and destination are on
the same network, so you obtain the same results testing either the
sender or destination. In cases where the destination is unknown it
will be broadcasting anyhow, so not matching the destination does not
matter.
I think a new patch is in order that actually makes the required test.
I will post a new version.
And Section 4 says:
Sending ARP replies that have IPv4 Link-Local sender addresses via
broadcast instead of unicast ensures that these conflicts can be
detected as soon as they become potential problems, but no sooner.
For example, if two disjoint network links are joined, where hosts A
and B have both configured the same Link-Local address, X, they can
remain in this state until A, B or some other host attempts to
initiate communication. If some other host C now sends an ARP
request for address X, and hosts A and B were to both reply with
conventional unicast ARP replies, then host C might be confused, but
A and B still wouldn't know there is a problem because neither would
have seen the other's packet. Sending these replies via broadcast
allows A and B to see each other's conflicting ARP packets and
respond accordingly.
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. 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.
I don't think I was thinking clearly at the time. I think there would
have to be major changes to the networking drivers to route address
resolution requests to user space. In light of this, at least in the
short term, tweeks to the ARP have to be done in the kernel driver.
-
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
