On 07/28/10 01:40 PM, Dario Tedeschi wrote:
My point is that since we are doing some kind of DAD (by having address
registration), sending a "duplicate" response to the appropriate node
needs similar technical consideration as in classic DAD. Specifically,
that sending a "duplicate" response to the duplicate address is
problematic.
I don't think so. The approach in 4862 was based on concerns around the
behavior of token ring and fddi where sending a unicast packet to a MAC
address, when two stations use the same MAC address, could be
problematic. We also have the same issue with Ethernet bridges learning
MAC addresses.
But for 6lowpan we don't have those issues since even if the MAC address
is duplicate both radios will receive the packet.
Note that the above is all about duplicate *MAC* addresses.
In the case of duplicate *IP* addresses with unique MAC addresses there
is no issue in sending a unicast response.
I'm sure that's why RFC text like the above even exists and
part of the reason why the "Target Address" field in an NS exists. The
designers of classic ND must have experienced or thought of this
technicality.
FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc)
using duplicate MAC addresses. To my knowledge the duplicate IP address
case is part of test suites.
Using a trick like "a temporary NCE" in an implementation might work,
but it comes with its own problems. Wouldn't it just be simpler and
safer if the requesting NS used a valid source address (one that is
considered unique in the WPAN).
Are you talking about the source IP address or source MAC address? For
IP we don't have an issue.
The use of a tentative NCE also has the benefit of removing a security
issue we have in nd-11 where an off-link attacker can cause NCE to be
created, which is something that isn't possible in base ND.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
