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
