gnrc_ndp: add external routers to FIB when RPL is enabled

[Yonezawa-T2]

Summary

This patch adds FIB entries when a 6LoWPAN border router received Router Advertisements from external network.

What I want to do

Suppose a 6LoWPAN network with RPL routing. The root is connected to the internet and a leaf node is connected a intranet. I want exchange packets between the intranet and the internet via the 6LoWPAN network.

I don't want to do manual network settings as much as possible. It should be configured by IPv6 Router Advertisement and/or RPL.

What we need

The FIB of the root node should forward all packets addressed to the intranet or 6LoWPAN nodes to the 6LoWPAN network, and all other packets to the upstream router given by Router Advertisements.

The FIB of the leaf node should forward all packets addressed to the intranet to the intranet router given by Router Advertisements, and all other packets to the RPL parent.

The current FIB implementation only stores internal entries for 6LoWPAN (and manually configured external nodes, but not prefixes).

How to achieve this

When the RPL root received a Router Advertisement from non-6LoWPAN network, register it as a upstream gateway.
When the RPL leaf received a Router Advertisement with Prefix Information from non-6LoWPAN network, register the prefix as a external network. Propagate it with RPL DAO message up to the root.

Changes on gnrc_ndp.c register routers to FIB. Changes on gnrc_rpl_control_messages.c propagate them up to the root node.

This patch guess prefix lengths of FIB entries with universal_address_compare. It should be updated when #4279 is merged.

Usage

Tested on two OS X machines and three XBees using examples/gnrc_xbee_border_router (#4448). Use https://github.com/Yonezawa-T2/RIOT/tree/xbee_border_router branch, which contains several fixes of other Pull Requests, for testing.

RIOT 1 (examples/gnrc_xbee_border_router on OS X 1):

ifconfig 6 add unicast fd00::2/64
ifconfig 7 add unicast fd01::2/64
rpl init 6
rpl root 0 fd00::2

OS X 1:

sudo ifconfig tap0 inet6 fd01::1/64 up
sudo route -n add -inet6 -prefixlen 64 fd00:: fd01::2
sudo route -n add -inet6 -prefixlen 64 fd02:: fd01::2
sudo sysctl -w net.inet6.ip6.forwarding=1
sudo rtadvd -d -D -f tap0

RIOT 2 (examples/gnrc_xbee_router, not a border router, on OS X 1):

rpl init 6
rpl router 0

RIOT 3 (examples/gnrc_xbee_border_router on OS X 2):

ifconfig 7 add unicast fd02::2/64
rpl init 6
rpl leaf 0

OS X 2:

sudo ifconfig tap0 inet6 fd02::1/64 up
sudo route -n add -inet6 -prefixlen 64 fd01:: fd02::2
sudo sysctl -w net.inet6.ip6.forwarding=1
sudo rtadvd -d -D -f tap0

ping6 fd01::1

Change XBEE_DENIED_ADDRESSES in Makefile to prohibit direct communication between RIOT 1 and RIOT 3.

[BytesGalore]

@Yonezawa-T2 sorry for the late reply.
I think the concept of this PR will produce routing loops if more then a single node receives router advertizements to the (same) intranet, and in turn announces its connectivity in DAOs on upward path.
The root or any common predecessor-node in the DODAG will get ambiguous information for the forwarding towards the intranet.
But please correct me if I misunderstood the concept.

I think you would need another RPL-Instance and DODAG with the intranet-connected leaf-node as its root.
The root of the Internet connected DODAG would need to join the intranet connected Instance and DODAG. The both root-nodes would then be routers between the DODAGs.
@cgundogan what do you think?

[Yonezawa-T2]

If I understand correctly, it would not result in loops. RPL DODAG is DAG, that is acyclic, so that looped route will not formed in RPL network in ideal situation. Actually, loops may be formed in general due to device movement and/or packet loss, but it is not related to this pull request. It is general RPL problem and shoud be resolved with loop avoidance mechanisms.

Because RPL DODAG is DAG, not tree, RPL allows multiple routes to the destination. Receiving ambiguous information for the forwarding towards the intranet is not a problem.

Let's see an example.

Assuming four RIOT nodes are incorporated into a 6LoWPAN network. The root node fd00::2 is connected to the internet via gateway fd01::ff. Two nodes fd00::4 and fd00::5 are connected to the same intranet router fd02::6. fd02::5 has two parent nodes fd00:3 and fd00::4.

fd00::4 emits DAO message upto the root. fd00::5 then emits two DAO messages to its two parents fd00::3 and fd00::4.

Now fibroutes of each nodes have the following state. Note that fib_add_entry overrides entries when it is called with existing destinations. Every node can send packets to other nodes correctly.

The upstream route and the downstream route between fd00::5 and the root are different, but this does not harm.

[cgundogan]

you can initialize this statically by using ipv6_addr_t default_route_prefix = IPV6_ADDR_UNSPECIFIED; and ignore the memset below

[BytesGalore]

@Yonezawa-T2 now I see you're totally right, I must admit I didn't look too closely into your code and focused on your images/descriptions.

I still can imagine of difficult situations when nodes move in the DODAG or messages get lost.
The information on changes propagates on every RA upwards, but doesn't reach all nodes.
That's no problem for non-storing MOP where all messages traverse first to the root node.
In storing MOP we can end up in a situation where the intranet connected node chooses different parents and after some time it drops the connection to the intranet.
Now it only updates its new parents. The nodes of the former branch will keep the FIB entry to the former intranet connected node until its lifetime expires.
The nodes of this branch will forward all packets destined in the intranet to the former connected node.
In turn the node will forward the packets towards another node connected to the intranet, which would be perfect.
Or it doesn't know one and forwards the packets towards the root node.
Now things get really messy if the intranet destined packet is forwarded to one node of the former branch (still assuming the left node is connected).

Please don't get me wrong I like your proposition :)
We could argue that this inconsistency will be resolved eventually when the lifetime of the FIB entry expires. But this would require to always set it to a finite and short (whatever short means) value when receiving DAOs advertizing an external prefix.

[cgundogan]

I am still unsure whether it is a good idea to set up routes in the fib as
a reaction of receiving RAs. Is such behaviour specified somewhere? IMO
this could lead to unexpected results and introduce new attack vectors by
tampering with other nodes' forwarding table.

Besides of my concerns above, I like the changes to RPL that you presented
here. Could you PR them separately?

[Yonezawa-T2]

@BytesGalore Yes, it does form a loop, but it is a general problem of RPL, not related to intranets.

Suppose a pure (no internet nor intranet connected) 6LoWPAN network.

Now the node fd00::3 crashes, reboots, and set fd00::1 as its parent. It sends a DAO to fd00::1 but not to fd00::2. Fibroutes becomes to the following state.

Suppose fd00::2 want to send a packet to fd00::4. It still think that fd00::3 have a route to fd00::4, so that it forward the packet to fd00::3. On the contrary, fd00::3 does not have a route to fd00::4, so it forward the packet to the root. The root node also still think fd00::2 have a route to fd00::4, it forward the packet to fd00::2, results in a loop.

RPL defines loop avoidance mechanisms for such case but RIOT does not support it yet.

[Yonezawa-T2]

@cgundogan I will split the commit and make a PR. Manually configureing fibroute of the leaf is acceptable.

[BytesGalore]

IMO this could lead to unexpected results and introduce new attack vectors by tampering with other nodes' forwarding table.

@cgundogan could you give an example how the attack vectors would manifesting?

[cgundogan]

@cgundogan could you give an example how the attack vectors would manifesting?

@BytesGalore In the scenario above: A malicious node would be able to announce faulty "routes" via the RA message. AFAIK, there is no such thing as seting up routes when receiving RAs

[BytesGalore]

A malicious node would be able to announce faulty "routes" via the RA message

@cgundogan I see, and we would just accept them.

AFAIK, there is no such thing as setting up routes when receiving RAs

I also never stumbled upon such behaviour.

[OlegHahm]

AFAIK, there is no such thing as seting up routes when receiving RAs

Well, RFC4861 tells you to configure the sender of an RA as default router. Since the actual datastructures (FIB and neighbor cache for RIOT) are implementation specific, you could interpret this statement this way.

[cgundogan]

Well, RFC4861 tells you to configure the sender of an RA as default router. Since the actual datastructures (FIB and neighbor cache for RIOT) are implementation specific, you could interpret this statement this way.

Sounds convicing. Currently, RPL just puts all FIB entries into DAOs. Should we also consult the default routers list and put that information into DAOs?

[kYc0o]

Feature freeze -> postponed.

[OlegHahm]

What is the status of this PR?

[miri64]

I would say postpone. If activity is happening here in the next few hours I might be convinced to reverse the postponement ;-)

[OlegHahm]

@cgundogan, @BytesGalore, what is your opinion on this PR?

[OlegHahm]

bump

[smlng]

@miri64 you kind of expert here, is this still the way to go or obsolete with changes/advances on NIB and so on?

[miri64]

This PR is based on the old neighbor discovery implementation and FIB (which still can be used, when a back-end for the NIB is implemented). While the concept seems sound it still requires adaption, so I would say we close this for now as memo.