s/of/or

Does it also make sense to outsource the changes to this file to its own PR? Doesn't seem like that there are any dependencies to your RPL refactorings?

Basically yes, but then no routing protocol will work in mainline RIOT until we merge this PR or adjust the other protocols.

Since FIB handles the lifetime of routes, would it make sense to remove this _rpl_update_routing_table thread completely and just pass a function callback (EDIT: or another kind of signalling) to the fib, which should be executed when a certain condition holds? (e.g. route lifetime expired) @BytesGalore @OlegHahm

@cgundogan the FIB works completely without threads. The exact invalidation point in time of a route is fixed and known, but not monitored by the FIB. A route lifetime and its invalidation is only performed on demand when the specific FIB entry is touched.
So if the lifetime of a route exceeds, probably the parent invalidation will not be triggered.

Taking the address from the parent results in these link-local addresses we see. In the former implementation rpl_get_routing_table()[i].address returned global addresses. I think the proper way would be to consult the fib and get the global destination address for those link-local addresses, and skip all parents without an entry in the fib.

EDIT: Or simply iterate over all entries in the fib istead of the parents, like in the implementation before

Unfortunately its not possible that the FIB replies a global address for a given next-hop address, since a next-hop address can be easily used for a large number of destinations.
Iterating is also not possible due to the separation concept of the FIB. But even if iterating would be possible, the FIB can have more entries than just the next-hops from RPL parents.

Fortunately not all is lost :D we could keep the global address for a parent in rpl_parents[i].addr instead of the local one, and ask the FIB for the global address when needed.

On second thought, iterating over the parents to fill the DAO is not the right way, because DAOs accumulate the routes they encounter up the dodag to the root. By iterating over the parents we can only put their addresses in the DAO but not the addresses the node accumulated through other DAOs (from children). In my opinion there should be a way to iterate over all targets in the fib and write them into the DAO.

This way we loose the downward route information for sub-DODAGS right?

I fear so, yes. How could we approach this issue? Is it possible to implement something like a generic iterator for the fib?

I have to think a bit more on it.
Just to clarify for myself, what we need to know here are all destinations addresses reachable from this node, which are constructed (storing MOP assumed) by receiving DIOs and all target options from all received DAOs right?

Correct, a DAO includes the address of the sending node in addition to all addresses it received from its children's DAOs, recursively. (storing MOP)

@cgundogan enhancing the data structures in the FIB or using the type field (uint32_t) for additional indication is no problem.
Maybe (and very related to your proposition), and this is also just thinking out loud, the FIB could return a full set of next-hop/destination tuples based on matching type field or just specific bits of it.

Maybe something like this:

typedef struct entries{
    ng_ipv6_addr_t dst;
    ng_ipv6_addr_t next_hop;
};

/**
* param[in]  bitmask indicate the bits to use in the search
* param[in]  typevalue the query type
* param[out] arr_entries array to store matching entries
* param[in, out] arr_entries_size indicates the storage spce on in and the use count when returned
*/
void fib_get_entry_set(uint32_t bitmask, uint32_t typevalue, entries* arr_entries, size_t* arr_entries_size);

@cgundogan I've opened #2818 as proposition for a function that could help here