ng_ndp: cache determined next-hop in FIB

[miri64]

RFC 4861 recommends the store the determined next-hop in the "Destination Cache". For my implementation I use the FIB as such, if it is availabe, so I cache the next hops not fount in the FIB also in there to shorten the determination for later packages.

[BytesGalore]

please change to FIB_LIFETIME_NO_EXPIRE (same below)

[BytesGalore]

The added FIB entries need to be removed if the neighbour node is not reachable anymore, since then a next-hop request (if the FIB is active) will always successfully lead to nirvana.
Probably this can be done here [1]?

[1] https:/authmillenon/RIOT/blob/ng_ndp/enh/cache-next-hop/sys/net/network_layer/ng_ndp/ng_ndp.c#L262

[miri64]

@BytesGalore does fib_remove_entry() remove the entry too, if dst is the next_hop entry? For l376ff it isn't that problematic if it doesn't, but for 380ff I insert the default router as next hop for dst, not dst itself. Alternative could be to use the default router lifetime there as lifetime.

[miri64]

Also, can routing protocols cope with the fact, that this would "randomly" remove stuff from the FIB. @Lotterleben @cgundogan?

[BytesGalore]

@BytesGalore does fib_remove_entry() remove the entry too, if dst is the next_hop entry?

yup, no mercy. The FIB do not determine if an entry is allowed to be deleted.

@authmillenon you're right this is a problem since usually each routing protocol is responsible for a specific prefix.
Changing entries handled by them will result in topology and routing inconsistencies.

[miri64]

So maybe I should give them a "reasonable lifetime" instead?

I think about

• next_hop == ip: reachability time, and
• next_hop == default_router: router lifetime

[BytesGalore]

+1 for the reasonable lifetimes if they expire the FIB entry is removed automatically.

Also, can routing protocols cope with the fact, that this would "randomly" remove stuff from the FIB.

The FIB can handle access and manipulation from different sources.
If the destination addresses have no collisions then everything is fine :)

[miri64]

Since the routing protocols probably use prefixes for the next-hop entries and I am using the full addresses, there should be no collision right?

Just one OT question popping-up: How ARE prefixes handled in the FIB? Up until now I assumed this is the dst_len of the add function, but this is in byte, right? Prefixes are usually given in bits (and with IPv4 the thing gets even more complicated with subnet-masks....)

[BytesGalore]

Since the routing protocols probably use prefixes for the next-hop entries and I am using the full addresses, there should be no collision right?

If this is the case right :)
But I'm not certain if the routing protocols only use prefixes for next-hops.

How ARE prefixes handled in the FIB?

Currently with bytes (I know this is wrong 😊) but,
when #2818 is merged the FIB uses Bits for a prefix. Additionally with #3157 a prefix entry in the FIB is marked with a specific flag.

[BytesGalore]

oh, and when using IPv4, the subnet mask shouldn't be needed when an entry is flagged as prefix, since the trailing 0-Bits define the size of the subnet.

[miri64]

oh, and when using IPv4, the subnet mask shouldn't be needed when an entry is flagged as prefix, since the trailing 0-Bits define the size of the subnet.

But weren't subnet masks introduced because there weren't enough prefixes left, making subnets defined by stuff like e.g. 63.255.0.0 possible, too?

[miri64]

(I know this discussion is going a little bit meta now :D will fix the timeouts soon).

[miri64]

oh and regarding overwriting entries of RPs: this should be more or less impossible, since in l351 it is checked if there is already something in the FIB. I say "more or less" since I think the IPv6 thread can't be preempted by the routing protocol in this function, but I might be wrong there.

[miri64]

To recap: I assume that it is safe to just remove the destination if the neighbor becomes unreachable, since it is unlikely that the routing protocol will add it exactly as in this function.

[BytesGalore]

But weren't subnet masks introduced because there weren't enough prefixes left,

somehow. If I remember right they were extended form Class-Network prefixes only to enable an arbitrary number of significant bits for private networks.

making subnets defined by stuff like e.g. 63.255.0.0 possible, too?

I can't tell for sure, but feels like not (or a proprietary and error-prone solution).

[miri64]

Rebased and had to squash, since ng_ndp.c was too different now.

[BytesGalore]

ACK, lets see what travis says