Hi Samita, For clarity I used all link-local addresses, they indeed would normally be global addresses.
I am talking about case 2. But assume you register with the *exact same* address of the 6LBR. You will create the temporary NCE with the *exact same* address of the 6LBR. Hence you just broke connectivity to the 6LBR, and the multihop-ND will fail. The connectivity will be broken until the temporary NCE times out. Depending on the timeouts this could take a bit as the attaching node may retry a few times, since it won't hear any response to the NS at all. Eventually 6lowpan-nd will recover of course, since the attaching node will try a new address and the temporary NCE will be removed. Regards, -Colin -----Original Message----- From: Samita Chakrabarti [mailto:[email protected]] Sent: October 7, 2010 7:10 PM To: 'Colin O'Flynn'; 'Westergreen Mads-MWEST2'; [email protected] Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, I missed one point yesterday in your example, so let's discuss that now (see in-line in the example scenario): The example scenario: > > 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. > > OK. > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. I am not sure I understand this sentence. Are you talking about the ABRO option 6LBR address? 6LBR Address: IPv6 address of the 6LBR that is the origin of the included version number There are two cases: 1) 6LBR is a neighbor of 6LR through which the duplicate-addressed node is registering 2) 6LBR is multi-hop away from the 6LR ABRO 6LBR option should carry the global IPv6 address of the 6LBR interface in route-over scenario. Case 1) - Let's assume, 6LR saved fe80::33:44 in its NC since it received the RA directly from the 6LBR; in this case if a node wants to register with fe80::33:44, this will be immediately detected before adding a temporary NCE. Case 2) 6LBR is multiple hop away from 6LR. If a node tries to register with fe80::33:44 address, then 6LR will add it in its neighbor cache since there is no conflict. But it'll send the multihop DAD request to 6LBR's global IPv6 address. In this case routing table will be consulted and nexthop is determined to be the next 6LR of MAC address ending with 11:22. The NCE will be consulted for fe80::11:22. So I don't see any issue here. When 6LBR received this multihop DAD request it should be able to find out the conflict with its own address and send an error to the global address of the sending 6LR. Are you trying to use route-over topology and link-local IP-addresses over multiple hops - that is not a correct usage. -Samita > > 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 > -----Original Message----- > From: Colin O'Flynn [mailto:[email protected]] > Sent: Thursday, October 07, 2010 2:30 AM > To: 'Westergreen Mads-MWEST2'; 'Samita Chakrabarti'; [email protected] > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Samita, > > > I'd assume that temporary NCE will not be used for data sending. > > What is the temporary NCE used for anymore? With the errors-to address you > don't need it to send the response, and if the address is successful you > create the NCE before sending the response so it will exist at the correct > point. > > Regards, > > -Colin > > > > -----Original Message----- > From: Westergreen Mads-MWEST2 [mailto:[email protected]] > Sent: October 7, 2010 9:59 AM > To: Samita Chakrabarti; Colin O'Flynn; [email protected] > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > 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
