> > 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.
[Pascal] I do not find those arguments very convincing: - An attacker can claim the same address on the next LR and get the same chances to hijack - If an attacker has access to the medium, then it can register tons of different global addresses from a number of forged mac addresses. If he has access to the geography, then it can simply jam the spectrum. > > So, tentative NCE is useful and the implementation can flag this entry not to > include it in the regular data path. [Pascal] Which illustrates again the danger of mixing the properties and usages of the registration table and the neighbor cache. The state that you are talking about (PENDING_VALIDATION_BY_LBR) does not exist in the classical Neighbor Cache FSM. It makes a sense to me to keep the table and the cache abstractly separate - exactly like we did with MIPv6 and the BCE -, because though the data have a lot in common, the lifecycles and operations are really different. > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
