Hi Colin and all, We have been discussing the short address and duplicate MAC address implementation issues for a while. The similar problem may happen in IPv6 today during DAD phase. My understanding is that Neighbor discovery protects the hosts from having duplicate IP-addresses while we are discussing the corner case of how to solve duplicate MAC address via 6lowpan-ND.
Please note that 6lowpan-ND assumes that link is secure and each host possesses EUI-64 unique number for its interface. Thus if one turns on short MAC address (16bit MAC) feature which is not guaranteed to be unique, it is very logical to assume that uniqueness of such MAC address would be verified at the link-level during the bootstrap by checking with a network-wide authentication server or via DHCP service. ND-12 updates section 8.2 with the following text: " For the synchronous multihop DAD the 6LR performs some additional checks to ensure that it has a Neighbor Cache entry it can use to respond to the host when it receives a response from a 6LBR. This consists of checking for an already existing (Tentative or Registered) Neighbor Cache entry for the registered address with a different EUI-64. If such a Registered NCE exists, then the 6LR SHOULD respond that the address is a duplicate. If such a Tentative NCE exists, then the 6LR SHOULD silently ignore the ARO thereby relying on the host retransmitting the ARO." The IETF draft will define specification in general case, but it will not provide specification for each implementation in a specific standard development organization. By using GP16 addresses, ZigBee can specify additional constraints upon using 6lowpan-nd for deployment. But it does not require change in the IETF document. Please understand this difference. Zach provided some examples as to how to support GP16 addresses in ND phase on the mailing list. In later version, we can add one of those examples in the Appendix section of the document to clarify usage in short MAC address cases, if that is helpful for ZigBee IP implementation. Please see below. These are some of my personal comments. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Carsten Bormann > Sent: Monday, August 23, 2010 12:10 PM > To: Colin O'Flynn > Cc: 6lowpan 6lowpan > Subject: Re: [6lowpan] ND Short Address Collisions > > On Aug 21, 2010, at 13:45, Colin O'Flynn wrote: > > > putting in 6lowpan-ND that you must send from an address based on the EUI- > 64 > [SC>] Originally we had the restriction of EUI-64-based address support only. ND-simple and other previous version of 6lowpan-nd. But we relaxed that to support other types of addresses [ as mentioned by Carsten below] and ofcourse GP16 addresses. But we still require a EUI-64 bit unique number to identify an interface uniquely in ARO. In terms of SLLAO, we require SLLAO to be provided with NS because no state or NCE is created before then. This is done for maintaining generality of implementations and for double checking the uniqueness of link-layer addresses for the requested address registration. Also note that 6lowpan-nd allows a tentative NCE after receiving RS, but there is a timeout. Thanks, -Samita From: [email protected] [mailto:[email protected]] On Behalf Of Colin O'Flynn Sent: Saturday, August 21, 2010 4:45 AM To: 'Westergreen Mads-MWEST2'; [email protected]; 'Dario Tedeschi' Cc: [email protected] Subject: Re: [6lowpan] ND Short Address Collisions 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 > (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit > address.) > > One of the decisions we made on the way from ND-08 to ND-09 was to simplify > the protocol by basing more of it on the assumption of uniqueness of the > EUI-64 address. > Your proposal therefore seems like a logical consequence, as it seems it > indeed simplifies things more. > > But let's consider what we lose: > > -- the use of privacy addresses in this capacity. Since we already need to > have the EUI-64 exposed to do DAD, I see little loss. > -- the use of CGA (cryptographically generated addresses) in this capacity. > Well, maybe not. Since a CGA SHOULD be about as unique as an EUI-64, it > MIGHT be a good substitute if the keys are generated with the same care that > we think EUI-64s are instilled. > -- any other scheme that really wants to use a different kind of address for > uniqueness. > > I haven't formed an opinion yet -- I'm still in the process of trying to > understand the trade-offs. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
