Sorry for the maybe stupid question, I have no deeper insights in the Contiki network stack: what will happen in a RPL network if I want to reach a (physical) direct neighbor that is not my direct neighbor in the RPL DODAG?

The routing logic is in tcpip_ipv6_output. To summarize:

• If the destination address is a link-local:
  • if the neighbor's MAC<->link-local IPv6 mapping is known, a link-local transmission will be done
  • else the packet is dropped
• if the destination address is global, and there is no route for it, it will be sent over to the default route (preferred parent)

Note that the MAC<->link-local IPv6 mapping can be known in two ways:

• whenever receiving a RPL DIO
• or if NDP is enabled, via a NS / NA

I would say 👍 for this one but with a good documentation on the impact.

With this modification you can no longer have link local communication except with your parent and children in the DODAG tree. If you rely only on DIO to have the LL address you can not reach an unknown host until it has sent a DIO first. However, DIO are multicast and therefore not acked and reliable. Also, you have the DIO suppression mechanism that could cause one node to never send a DIO in case of high density network. And you have also the case of Leaf nodes which never send multicast DIO.

On the other hand, this is exactly the behavior of 6LoWPAN-ND, hosts can not communicate directly, the traffic must go through a router. This remove the unnecessary traffic (NUD mainly) that NDP requires.

Lastly, NUD was the poor's man RPL probing, but now with #1053 it's not longer useful at all.

Note that the MAC<->link-local IPv6 mapping can be known in two ways:

• whenever receiving a RPL DIO

Okay, thanks, Simon, that was the piece of information I was wondering about. Basically, you rely on some upper layer mechanism (RPL in that case) to fill the neighbor cache. I don't think that this is RFC compliant, but will probably work in most cases (if all nodes run RPL).

Still, I wonder about the second issue you've mentioned:

NDP adds complexity and might have bad interactions with RPL, e.g. delete a neighbor RPL still needs

If a RPL neighbor is removed by NDP from the neighbor cache for whatever reason, you would just have to send out a new NS the next time you want to reach this neighbor. Either the node is still there and added to the NC again or it vanished and you want to inform RPL anyway (maybe starting a local repair).

(I'm not wondering about the NDP complexity issue. 😉)

@laurentderu good points, I will document this in contiki-default-conf.h.

@OlegHahm agreed. I realize now that what interacts poorly with RPL is Contiki's NDP implementation rather than NDP per se. In Contiki, when NDP removes a neighbor, we also lose information such as link estimates towards the neighbor. Whenever hearing a RPL DIO again, the neighbor will be re-added and RPL won't recall it had a bad link towards it. One could fix NDP to better play with RPL. But as NDP is of very limited usefulness along with RPL I don't know if this is worth the effort. What we need instead is 6LoWPAN-ND!

Maybe it actually is worth the effort. If someone thinks NDP should always be enabled I might try to find some time and look into improving the NDP-RPL interplay.

6LoWPAN-ND for Contiki is on its way, but it still need some refactoring and reviews before being proposed as PR

Is the 6LoWPAN-ND implementation an extension of the current NDP or is it fully independent? In the former case, does it make sense to try to improve the NDP-RPL interplay or do you think we should rather disable NDP for now?

@laurentderu I clarified the flag in contiki-default-conf.h

6LoWPAN-ND implementation is an extension of the current NDP, but there is no NUD nor AR anymore, so there won't be any removal of neighbour because of 6ND. So I would say that improving NDP-RPL interactions is not worth the effort.

Neighbour could be deleted by 6ND when their address timeout, but their are periodic messages to refresh them (and that could be linked with DAO) and the whole process is deterministic (and not subject to packet loss).

I agree with @laurentderu that we should rather bring in 6LoWPAN-ND than tune ND-classic + RPL. Let's get 6LoWPAN-ND in sooner rather than later! I hope to spend some time on it after the IPSO meeting next week.

The new setting is now fully documented as suggested by @laurentderu.
Will merge in a month unless someone shouts!

merging after timeout

Sorry to notice this only after it has been merged after the timeout, but I just wanted to make sure that this one does not break things. We tried turning off ND with RPL some time ago and the result was that things started failing. If I recall correctly, I think the problem was that RPL-without-ND wasn't very good at detecting that a neighbor had gone and just kept trying to reach it. Is this something you've seen @simonduq?

Not something I've seen, and I've worked with ND disabled for a while, but probably in settings different than yours.
Do you recall what kind of "trying to reach"? RPL control or routed traffic to parents / children?
If you have doubts I'm perfectly fine with a revert commit we merge immediately.

It was a while ago (well over a year ago, maybe even two years ago), and I don't we did any real analysis on what happened. But I think the problem was with DAO downward routes, which I don't think are handled in the same way as upward routes (e.g., no ETX is kept for them). If a node went away the parent would never figure this out, but would act as the node was still there and keep sending packets to it, even though they would time out at the CSMA layer.

The problem is that is ND is turned off and RPL is entering it "maximum" stability the default maximum interval of messages such as DIO will be higher than the lifetime of a neighbor. Then when that happens there is no ND to re-detect the neighbor and it will be "stale" / lost. We turned back ND on all platforms even when we used RPL due to that. Other options is changing RPL maximum interval or to make the neighbors longer lasting (I think they are configured for 10 minutes lifetime on many platforms).

@adamdunkels I see. RFC6550 even mentions NUD as a valid mechanism for use with RPL. What I don't like, however, is that with NUD, nodes decide to remove a link unilaterally: we might end up with no route to a child although alternate paths were available. OK for nodes leaving the network, but not for nodes that only lost connectivity with their current parent.

What would you think about relying on DAO route lifetime instead, which we could default to a few tens of minutes:
+ by the time you remove a route to a child, it should have already allocated a route to another parent (if any)
+ not all neighbors are polled periodically, only links in the DODAG are maintained
- DAO propagate end-to-end to the route, whereas NUD is link-local

@joakimeriksson that is another problem. Sounds like we could do a better job at disabling ND then: without ND I don't think we should care about the "stale" state at all.

I am not too afraid of sending a few ND messages - but we should probably consider allowing RPL to tune the lifetime of neighbors using the same type of lifetimes that RPL make use of. But I would probably also go for some other two-way mechanism to regularly confirm reachability of neighbors like the probing or similar. Using probing from the child to the parent each 5-10 minutes would make this not happen. I am not all in for diverging too far from the RFC's which we do without any ND. It is important to keep track of the neighbors and detect when they are gone also.

What I'm most afraid of is the resulting routing inconsistencies we can get. For the child->parent links I think we're currently fine, with or without NUD, now that we have probing. The problem is for parent->child IMO, and the two solutions I see are (1) re-enable NUD or/and (2) have non-infinite routes.