Hi Colin,
Here is an attempt to address your concerns. From: [email protected] [mailto:[email protected]] On Behalf Of Colin O'Flynn Sent: Tuesday, August 17, 2010 1:09 PM To: [email protected] Subject: [6lowpan] ND Short Address Collisions 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. [SC>] Your concern is about responding to the neighbor who tried to use its neighbor's GP16 address by having a duplicate 16-bit MAC address. I assume there is no issue in detecting the duplicate address by using the ARO fields EUI-64 and address to be registered. How do we handle this problem today? If the MAC address is a duplicate one and it remained undetected so far - then bad luck! Do you assume that when RS is sent, the node uses LL64 unique address and receive RA correctly? 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. [SC>] Temporary NCE is added for detecting duplicates at the first hop immediately. 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). [SC>] Section 5.5 already addresses how many times the NS can be retransmitted for address registration. Do you want to see a specific sentence on that again on section 5.5.1 (Sending NS)? 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. [SC>] Yes. As in any other case today. #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. [SC>] How is it a ND issue? 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). [SC>] You are talking about an optimization/hack for a special case. We cannot assume that SLLAO is always same as EUI-64. 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. [SC>] In a deployment, ideally one should use LL64 address in order to maintain uniqueness. But if one wants to use LL64 for communication and then verify LL16 address with the 6LR/6LBR to make sure that is unique before using it, that is a unique requirement. That is beyond DAD check. However, if this solution is nice to have through ND, we will look into it. However, I'd like to make sure that folks understand that this should not hold the draft from starting WG-LC - agree? Thanks, -Samita -Colin
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
