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
