This is a replacement for https://reviews.freebsd.org/D33265 I will try to replant its dependencies on top of that one, if phab allows that.

Silly question time: what is the maximum number of interfaces we can have on a system if the ifIndex will be global? What's its size on the RFCs?

I've also just scrolled through https://datatracker.ietf.org/doc/html/rfc2233#section-3.1.5 and its history and future.

One possible problem I do remain seeing with keeping a persistent (global) interface index between networks stacks is that we actually start leaking information back into the vnet about the overall host. There's probably a lot more about that still but we should rather be removing them than adding them.

I am still not convinced this is the better solution (probably it is the simpler solution) and I do understand that we are between Holidays and Years in the western world and that Nativity is coming up in the East and we may just have a lonely discussion here with people being away.

I wonder if the perforce commit email archives have the reason for why ifIndex was virtualized. I wonder if these email archives still exist after the late mailing list move or if we have to dig in personal mailboxes.

In D33672#761532, @bz wrote:

Silly question time: what is the maximum number of interfaces we can have on a system if the ifIndex will be global? What's its size on the RFCs?
I've also just scrolled through https://datatracker.ietf.org/doc/html/rfc2233#section-3.1.5 and its history and future.

We use 16-bit for index and MIB II defines it as 32 bit value. However, the ifindex reported in SNMP != system ifindex. The rfc2233#section-3.1.5 requires uniqueness of the value over time, and system ifindex can be reused. This is the reason why bsnmpd doesn't use system ifindex. So, to put it short. We are not bound by MIB II at all on the implementation of ifindex.

What keeps us sticking to 16 bit value is struct ifreq.