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 . OK, but removing step 7 still does not solve the problem: How does the 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 address points to Host[A]? I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems strange to me: In an implementation, one has to break the layering so that you can send specific ICMP packets to link-layer addresses instead of just passing all ICMP packets to the IP layer as is normally done. Besides that, the concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending the DAD failure to the node that was the original defender of the address - is that not an odd thing to do? [SC>] There are few cases where 6lowpan-nd is highly optimized. This is one of them. Section 6.5.1 says that, upon receiving the NS registration request, 6LR checks its NC for any duplicate, if it is found, then it would respond NA back with duplicate address error set directly to the node using the MAC address found from SLLA. This check is only in the control path of the packet, so I don't see a problem with implementation of 6lowpan-nd.. Thanks, -Samita 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: At 6LR (neighbor Cache) - when the request comes in If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link I understand that the ARO is used in DAD; that's not what I'm questioning. My issue is with having the GP16 address in the NS and then having to send an NA response to the same GP16 address. -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
