Reading the ZigBee IP report more carefully, I noticed one mistake there. The MAC src and SLLAO of the registration NS are specified as the 16-bit short address in the ZigBee document. This is wrong, it should use its 64-bit IEEE address as the MAC src and the SLLAO as obviously this is known to be unique. The 16-bit address shouldn't be used at L2 yet until it has been confirmed.
When the NA response comes back to the host, the MAC dst is the 64-bit IEEE address and the IP dst is the address that the host tried to register (same as in the IP src of the NS). Thus there is no chance of a MAC duplicate there, which I think was the main concern below. Zach On Jul 9, 2010, at 10:35 AM, 6lowpan issue tracker wrote: > #87: GP16 as source address in initial NS > --------------------------------+------------------------------------------- > Reporter: z...@… | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------+------------------------------------------- > From ZigBee IP interop: > > Still some potential issues using GP16 in source address of > initial NS from joining node to parent router and NA back to > joining node from parent router on initial multihop-DAD. If parent > router has the same GP16 as the one randomly chosen by the joining > node in its routing tables (i.e a valid node already exists more > than one hop away), it has to make sure this new colliding GP16 is > properly addressed in preference to attempting to send it through > the routing mechanism. The parent router itself could also have the > same duplicate address as the chosen GP16. This would mean you are > trying to send back to itself. > > Furthermore, multihoming device could be an issue > – may send on another interface if it’s done through routing. > RFC2462 also states that tentative address (i.e. not been through > DAD) is not assigned to the interface, so strictly it can’t be > used. To comply with 4861, choices are are LL64 or unspecified. > > The authors have discussed this issue more, and think it can be solved > with better clarification in the draft: > > Using GP16 as the src IPv6 address is not an issue - as specified in > section 8.2: > > "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor > Cache entry for the address until it receives a successful ARO option > from the 6LBRs." > > Thus the router would not be confused by the duplicate address until it is > known that the address is not a duplicate. Perhaps we also need to make it > clear that the router must not create any routing state for the address > until it has received the success? > > Section 8.2 also tries to make it clear how the router responds by saying > > "Note that the 6LR does not create a Neighbor Cache entry until it > receives a successful ARO back from a 6LBR. Instead it uses the SLLA > option of the NA from the 6LBR to reach the host." > > 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2 > and elsewhere. Basically, an NS with a SLLAO does not modify an existing > NCE, nor does it create a NCE, until it is known that the address is not a > duplicate. The multicast DAD in 4861 works differently. > > -- > Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87> > 6lowpan <http://tools.ietf.org/6lowpan/> > -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
