RPL as fix for the border router issue

Hi, at the f2f meeting today we Oleg proposed to have RPL run on the border router as an alternative to [1] (since RPL always uses link-local addresses as next hop, the neighbor cache would never be asked for GUAs). This seemed to work (it ran for about 30 min), but we (Cenk, Hauke and I) discussed that the manual configuration for RPL currently needed is a big negative point in light of the fully automated border router configuration. And while we could implement a half-assed bootstapping mechanism until tomorrow, we decided against this solution and stick with [1] for this release and have it done properly instead with a proper interface bootstrapping/configuration mechanism at some point in the future.

Cheers, Martine

[1] https://github.com/RIOT-OS/RIOT/pull/5309

Out of mailing-list:

Hi Martin,

Regarding manual-configuration for RPL, the way contiki is doing it to prevent manual config on the border router is bypassing the network layers and doing kind of horrible things.

As I see most RIOT like a linux host, if I should do the same stuff dynamically I would be using ssh to configure the host with the adapted addresses/interfaces/routes. Or a script run at startup wih configuration files.

So what about a RIOT shell script (with expect on the serial line?) to configure it "automatically with a manually run script". This way, there could be a start_network script which would take care of everything automatically with manual configuration anyway.

So even if I would love to have RPL border routers now to use on IoT-LAB I agree with not bypassing the manual configuration in a quick-fix way.

Regards, Gaƫtan - IoT-LAB Team

Hi Gaetan,

(My name is Martine, not Martin). As for scripting: this would require a shell and while it is currently available in most examples, this isn't desirable (especially for in-network hosts and routers). A way to statically configure the interfaces is preferable, because of that.