Hi Mads, > > Wouldn't it just be much simpler to have the short address in an option > instead of adding a temporary NC entry that you don't use. > [SC>] My apology for the late response.
A separate option for a secondary address was one of the solutions the authors discussed before. But this way there might be some compatibility issues with other existing protocols such as SEND. BTW, tentative NCE are there to protect the pending registration from being hijacked by an another node. If tentative NCE is not recorded, and a multihop DAD request on the way, then the second node came in and sent the registration request, if the response of this request arrives earlier than the first request, the wrong node gets in and the original request is denied. Also this can induce a flood of multihop DAD requests from 6LR to 6LBR by an attacker. So, tentative NCE is useful and the implementation can flag this entry not to include it in the regular data path. Thanks, -Samita > It would make the ND process much simpler and clean. > > Br, > Mads > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Samita Chakrabarti > Sent: 7. oktober 2010 01:19 > To: 'Colin O'Flynn'; [email protected] > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > I'd assume that temporary NCE will not be used for data sending. I think the > purpose of creating temporary NCE is to prevent processing the duplicate > request when the previous one is under flight to/from the 6LBR. > > I'd add a flag to the NCE marking it as temporary and will not use for > sending data or determining nexthop resolution. Thus a little modification > is needed in NCE-lookup code in the kernel and the ND response messages > could use the SLLAO for MAC-address and turn the temporary entry to > permanent entry by clearing the flag after DAD verification. > > Erik and Zach, do you have similar view on the temporary NCE? Looks like we > need to check the document to see if there is enough clarification. > > Thanks, > -Samita > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Colin O'Flynn > > Sent: Wednesday, October 06, 2010 9:38 AM > > To: [email protected] > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > Hello, > > > > I had a question / possible problem with 6lowpan-nd and would > > appreciate clarification from the 6lowpan-nd authors or others > familiar with it. > > > > Assume you have the following network, for simplicity I've used all > fe80:: > > addresses. I'll bring a hypothetical network up here: > > > > Step #1: Initial State > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > > > Consider router 2. It's neighbor cache (NC) will have the following: > > > > NC: > > fe80::11:22 > > > > > > As it cannot talk to fe80::33:44 directly it should not be present in > > the NC. > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > send > > directly to this device. Indeed all connectivity for the ABR will be > broken > > until that temporary NCE times out. > > > > If this is correct I can see two possible solutions: > > > > #1) Update 6lowpan-nd to say that you check the joining node's address > > > is not in the NC OR the ABR you will be performing multi-hop ND with. > > It doesn't matter if the address is of some intermediate node as it > > will > still > > result in the default router being used, you just need to check > > against > the > > ABR. > > > > #2) Send from a known-unique address and carry the address in the ARO, > > > but > I > > think this won't be accepted still... > > > > Regards, > > > > -Colin > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
