Hello,
I had some questions/concern about 6lowpan-ND: #1) I know there was much discussion about handling the case when a node registers to a parent, and that parent already has a node registered to it with the same address (or it is the parents address), and how to route the response back. I'm not convinced the addition of a 'temporary' NC makes a lot of sense to be honest. I think a better solution is to explicitly spell out in 6lowpan-ND what happens when the case of a response not being received occurs. The easiest solution I can think of is that after sending MAX_UNICAST_SOLICIT times, you take the same action as if you had a duplicate address. You try that maybe 3 times, and if it still fails select another router (if available). Then what happens in the case of a duplicate entry, is the NA is routed to the wrong device or yourself. It will throw it away since it is either not expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an extra few messages since the target will be re-trying but the chances of this are minimal at least. #2) An interesting aspect of the above is that when the NA is sent back, there are actually two nodes listening they will both send an 802.15.4 ACK. This will result in a collision and the parent may not actually hear the ACK, resulting it in thinking a failure occurred at the 802.15.4 layer. We may not care about this, but if someone ties together the failure at the 802.15.4 layer to higher layers it might result in unnecessary traffic. #3) Considering the above, what was so wrong with sending from a known-unique IPv6 address for that first hop? There is zero added complexity, and a minimal overhead in terms of bytes. Since you are carrying the EUI-64 inline you actually already have that nodes address anyway, and could eliminate the SLLAO from the initial NS if wanted (this could be a link-specific optimization , and need not be part of 6lowpan-ND). Indeed the best idea would be to send from the link-local address based on the EUI-64. Nodes which are using mostly 'plain' ND with special extensions would still work fine in their neighbor table. Nodes which are specially programmed could avoid needing an entry in the neighbor table since they can form the destination of the NA based on the EUI-64. Regards, -Colin
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
