I also agree with this approach!.
Br, Mads Westergreen Senior Platform Architect, Wireless Connectivity Operation Freescale Semiconductor Mobile: +45 20 31 45 03 e-mail [email protected] This e-mail, and any associated attachments have been classified as: [ ] Freescale Semiconductor General Business [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary From: [email protected] [mailto:[email protected]] On Behalf Of Robert Cragie Sent: 18. august 2010 06:52 To: Dario Tedeschi Cc: [email protected] Subject: Re: [6lowpan] ND Short Address Collisions I did raise this at the IETF meeting in Maastricht but let's say it wasn't met with universal approval. What was put in was a tentative NCE, which is better than what was there before but still has the issues Colin has pointed out below. I have always thought the right way is to carry the 16-bit tentative MAC address in the ARO option all the way to the ABRO, which then really just views it as a number at that point. Only when it finally gets back to the joining node does it then become a true MAC address and is then autoconfigured as an IPv6 address. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 18/08/2010 12:48 AM, Dario Tedeschi wrote: Hi Colin I'm all for item #3. It makes handling of IP address conflicts simpler, helps avoid media-access issues (like you mention in #2) and is more inline with the IPv6 paradigm. Dario Colin O'Flynn wrote: 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
