I think I was one of the people who were pro having this header, but thinking about it again, I was wondering if it would make sense to make some of the fields configurable through functions, more specifically UNIVERSAL_ADDRESS_MAX_ENTRIES, FIB_MAX_FIB_TABLE_ENTRIES, and FIB_MAX_REGISTERED_RP. For example, if you're certain your application only runs one routing protocol, having FIB_MAX_REGISTERED_RP set to 5 would waste valuable space, but if you wanted to change this value, you'd always have to have a modified RIOT branch and keep that up to date... Which can be pretty annoying. Alternatively to the setting (and getting?) by functions thing, a flag-based approach (so that you can set the values in the Makefile) like in https://github.com/RIOT-OS/RIOT/blob/master/pkg/microcoap/0004-increment_max_segments.patch could be an option..
Sorry for thinking of this only just now :(
What do you think?

@Lotterleben good point. I like the idea to configure stuff on compile time like
make FIB_MAX_REGISTERED_RP=1 and so on :)
I will change that tomorrow accordingly

thanks :)

@Lotterleben changed to configure on compile time, but this may produce unwanted side-effects.
The defines are set right for the FIB/Universal address only (bad news).

When including the ng_fib.h in a main, for instance in the hello-world example (with USEMODULE += fib of course) and calling say make UNIVERSAL_ADDRESS_SIZE=17,
the main will use the UNIVERSAL_ADDRESS_SIZE default value of 16, while the FIB will initialize and use it with the new value 17. (same applies for all other defines)

You can reproduce it by e.g. printing the value of the defines in the FIB (e.g. in fib_init()) and in the main accordingly.
So I recommend to not provide this compile time configuration.

Hrrrrm thats not good :( If this is the case, it shouldn't be used, but there must be a way... I'll think about it some more on my way to the Uni.

Okay, I've opened an issue to document this: #3256
Let's stick to the other way for now and update as soon as the issue is resolved.

@Lotterleben agreed, removed the command line configuration possibility.

thanks, then.. ack if travis says yes

needs rebase

Just wondering, do we still want to pursue this one? :)

@Lotterleben I still want to do the housekeeping for the cluttered FIB configuration properties :).
I close this for now and make a new PR to adopt it for the current state and incoming changes.