Samita, 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.
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
