Hi, For context: I'm currently working on a patch set for OpenBSD that adds support for AX.25 network interfaces.
Constants for interface types are defined in <net/if_types.h> based on the IANA registry for ifTypes maintained as: https://www.iana.org/assignments/ianaiftype-mib As the bottom of this file, we see a comment: /* private usage... how should we define these? */ Oh dear. There is no private use range defined in this registry, and as far as I can tell once we'd made up our own assignments here no questions were asked when we made up more. There are a total of 11 "private" interface types defined, all of which clash with types defined in the IANA registry we claim to base these defines on. Before I'd looked too far into this, I read about the IANA registry and went and registered an interface type for AX.25, which is now allocated as 298. The process for this was entirely painless and they responded within days. This presents another problem because the if_type member of the if_data struct is defined as a u_char and so the type I've been assigned isn't even going to fit. Before I go any further here, I wanted to ask whether this has come up before, whether anyone is looking at it, any ideas, etc? If no one has yet looked at this and no one cares how it is fixed, I would do the following: 1. Register each of the types we have as "private" allocations with IANA. 2. Increase the if_type member to be a u_int32_t. 3. Track down all the places that this might be used, and make sure they are also changed to handle a u_int32_t. 4. See how badly things break during an upgrade, and if some compatibility things need to be done (e.g. have two sets of ioctls for a release period). 5. Sync if_types.h with the IANA registry again, which will mean that the private use types change their numerical value. The only place that I can think of that really might break is SNMP clients, because I think that the ifType may appear in the SNMP tree. This is unfortunate, but there are probably more clients that are currently interpreting CARP interfaces as "Internal LAN on a bridge per IEEE 802.1ap" and MBIM as "Gigabit-capable passive optical networks (G-PON) as per ITU-T G.948". If we want to have standards compliance, we *should* fix this. Any comments and thoughts are welcome. Thanks, Iain.
