Actually, what I wrote below was incorrect after checking the details again. The draft (also in nd-11) does specify that the SLLA of the NS must correspond to the address being registered. In that case, the 16-bit short address. The clarification in Ticket #87 should still take care of this. Sorry for the confusion.
Zach On Jul 12, 2010, at 3:53 PM, Zach Shelby wrote: > 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 -- 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
