Re: [6lowpan] ND Short Address Collisions

[Dario Tedeschi]

I support this idea. Colin O'Flynn wrote: Hello,   Would there be support for putting in 6lowpan-ND that you must send from an address based on the EUI-64 instead of anticipated 16-bit address? I think it is more consistent with what is already in 6lowpan-ND. Consider the following:   From the assumptions section of 6lowpan-ND, we have:      o  EUI-64s are globally unique.      o  All nodes in the LLN have an EUI-64 interface identifier in order       to do address auto-configuration and detect duplicate addresses.   Thus 6lowpan-ND is already assuming we have a link-local address based on an EUI-64. Based on those two assumptions you could greatly simplify processing of NA by performing the following when you receive a NA message:          [1] Is the EUI-64 my address? If so skip to general processing (not shown here)          [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing more to do.          [3] Generate an address by performing the address autoconfiguration                algorithm on the EUI64 in the ARO with the link-local prefix          [4] Forward the message to the address generated in step 3, recalculating ICMPv6 checksum   Such a setup has the following disadvantages:  -You ALWAYS transmit the registered address in the ARO on first hop, wasting 16 bytes   But the following advantages: -Cannot have collision of two 802.15.4 ACK’s because you are transmitting to two nodes at once -Less FLASH usage, since you have removed temporary NCE, and always use the same ARO Length which further simplifies code -Less SRAM usage, since you never need a neighbor cache entry for multi-hop DAD to complete -ARO registered address can be changed by ABR. For example if ABR notices a node is re-registering after that node reboots, the ABR could change registered address to nodes old address in NA it sends back. -Avoids “hacks” when sending last-hop NA. By “hack” I mean that people may just take registered address out of ARO, and send 802.15.4 message to lower 16 bits of registered address, since they are only every registering GP16 addresses in their case. By instead explicitly using EUI-64 to generate address, you decouple the registered IPv6 address from the MAC address used during registration. Thus the same code could in the future be used to register any address, not just GP16 addresses. It is only the final hop that knows if there should be any correlation between IPv6 address & 802.15.4 address, not intermediate nodes. -Does not need SLLAO in initial NS   Comments?     -Colin     From: 6lowpan-boun...@ietf.org [mailto:6lowpan-boun...@ietf.org] On Behalf Of Westergreen Mads-MWEST2 Sent: August 18, 2010 3:14 PM To: robert.cra...@gridmerge.com; Dario Tedeschi Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND Short Address Collisions   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 mwe...@freescale.com 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: 6lowpan-boun...@ietf.org [mailto:6lowpan-boun...@ietf.org] On Behalf Of Robert Cragie Sent: 18. august 2010 06:52 To: Dario Tedeschi Cc: 6lowpan@ietf.org 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 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 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan         _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan