gnrc_rpl: old routes are not deleted

[a-podshivalov]

A simple test with 4 nrf52dk boards (flashed with gnrc_networking example) probably shows several routing and related issues. The steps are:

1) On board 1, start an RPL root:

ifconfig 8 add 2001:db8::1
rpl init 8
rpl root 1 2001:db8::1

2) Boards 2, 3, and 4 will be RPL nodes:

rpl init 8

3) Start BLE advertising on boards 2 and 3:

ble adv bleriot

4) Scan for bleriot on board 1 and connect (replace the numbers with actual ones from the scan output):

ble scan
ble connect 2
ble connect 3

5) Start ble advertising on board 4.

6) Scan for bleriot on board 2 and connect.

7) In some time (to speed up, use rpl send dis on non-root boards) the routing table on board 1 will be populated with downward routes to boards 2 and 3 directly and to board 4 through board 2, use nib route show to view the forwarding table.

8) Reset board 4 and re-initialize:

rpl init 8
ble adv bleriot

9) Scan for bleriot on board 3 and connect.

10) With nib route show on boards 2 and 3 observe that both of them have downward routes to board 4, and they distribute this route in RPL DAO messages to board 1 with approximately 60 seconds intervals. On board 1, the route to board 4 will be replaced with the one in the latest DAO received with either actual, from board 3, or stale, with board 2 as the next hop.

I think this is not the desired behaviour, and RPL, as described in RFC 6550, has some mechanisms to mitigate distribution of stale routes - but it seems none of them work in RIOT. Actually, the routes were distributed for a very long time, more than an hour in one of the experiments, so probably even route deletion from the forwarding table after a timeout does not work as intended.

Even more, a No-Path in DAO messages (a Transit Information option with a Path Lifetime equal to 0) leads to a contrary result - the FT entry is created by calling gnrc_ipv6_nib_ft_add with 0 timeout, resulting in a permanently stored entry.

Basically, the main question is: has anyone tested RIOT's RPL implementation in any decent-sized network with some dynamics, where nodes change parents? Probably the stale routes issue was never noticed on 802.15.4-based networks (and the test facilities like FIT IoT LAB let all nodes reach each other), but the connection-oriented link layer of BLE requires the routing table to be more or less up-to-date.

[a-podshivalov]

Seems to be similar to #17327, but for the 6LoBLE case this could be fixed with link-layer hints to RPL (as suggested in 16.1 of RFC6550, and this kind of link layer provides neighbor unreachability detection)

[maribu]

Sounds like this could be used for DoS