Hi Dario,
The assumptions in the steps you provided below are incorrect. In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 . Also section 8.2 says: 8.2. Duplicate Address Detection The ARO can be used, in addition to registering an address in a 6LR, to have the 6LR verify that the address isn't used by some other host. There are two levels of check for duplicate MAC addresses in case of multihop DAD: 1) At 6LR (neighbor Cache) - when the request comes in 2) If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link -Samita From: [email protected] [mailto:[email protected]] On Behalf Of Dario Tedeschi Sent: Tuesday, July 13, 2010 12:49 PM To: [email protected] Subject: Re: [6lowpan] #87: GP16 as source address in initial NS There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem: 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR 2. 6LR sends NS+ARO+address to 6LBR. 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry. 4. 6LR sends NA+ARO+success to Host[A]. All good so far. 5. Sometime passes 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration. 7. 6LR sends NS+ARO+address to 6LBR. 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]). 9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS. Dario 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.
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
