I'l split this up into a couple of chunks so we can more easily do the base infrastructure for the llatbl changes for IPv6 and the IPv4.
The rtr and prefix parts are unrelated to that.

In case I don't hear from you I'll go ahead and commit this the next days.

Thanks a lot for the feedback. let me know what you think about the suggestion to move the basic functionality into llatbl?

Address variable naming.
Address conditional checks.

Ignoring the one maximum value, is anyone interest in actually reviewing this?

inet_pton() stroes network byte order, so lose the original (now extra)
htonl() and unbreak IPv4 support.

In D22487#491857, @darkfiberiru_gmail.com wrote:

Trying to understand your bootp comment in summary. Are you pointing at no support yet for https://tools.ietf.org/html/rfc5970 or that there just isn't a ipv6 option for defining boot info like bootp had?

Approved by: bz (co-mentor)

Address kp's catch of the SYSCTL_OPAQUE size.

Thanks a lot for reviewing! Much appreciated!

In D22334#488613, @ae wrote:

The most of code that uses m_pullup() does check first, that the call is needed. Do you think that now it is considered as light enough, to do not check this?

Rename FOO_<> to FOO.<> as requested by @imp.

libkvm does know about VNETs (see kvm_private.c / kvm_vnet.c) as much as it knows about DPCPU. I seem to remember however it needs something selected, such as a PID or curthread from the dump, as it gets VNET information from there. This is probably something that should be generally fixed for netstat and not just for mrouting, though I am sure I tested that on a core dump back then. People may have broken it or the netstat parts were never merged.

I'd like to commit the main part of the change with(out) the two changes I commented on the next 24 hours.
Does anyone want to have a look?

In general I really like the changes. I've not looked into the large chunks of sysctls / UDP / TCP in too much detail. I'll try to do them based on their individual git changes the next days (at least sysctl and UDP). Hope someone else will do the TCP bits.

All your "stub functions" return (0), when in fact they probably should return an error? Or what happens if someone tries to set a (hw)breakpoint on these architectures?