Support for 240/4 and 0/8 addresses in NetBSD

Hi!

The IPv4 address ranges 0/8 and 240/4 were reserved in the 1980s for
different purposes (0/8 for a proposed ICMP-based autoconfiguration method
that was superseded by BOOTP and deprecated, and 240/4 for "future use",
contemplating possible eventual future addressing modes or semantics
other than unicast or multicast, which never arrived).  Unfortunately,
these addressing policies leave hundreds of millions of addresses wasted.

Since 2008, there have been proposals to make historically reserved
addresses usable on the Internet, which could help alleviate some of
the intense IPv4 scarcity pressure, whether these addresses end up
getting used as public or private address space.  (Some people are
less enthusiastic about continuing to try to mitigate IPv4 scarcity
because they see that as competing with IPv6 adoption, but many of the
organizations that want IPv4 space have already adopted and deployed
IPv6, but still need IPv4 addresses in order to interoperate with other
networks -- hence, for example, only about 100 of the top 1,000,000
web sites are IPv6-only today.)

This process is complex because of the heterogeneous behavior of different
devices and operating systems.  Currently most Unix-like operating systems
(at least Linux, OpenBSD, FreeBSD, and Solaris for both 240/4 and 0/8,
and macOS and Solaris for 240/4) support these addresses in their current
versions, either as a default behavior or as an opt-in via a sysctl.
Most new commercial routers also support at least 240/4 routing either
by default or as an opt-in.  We haven't found any reports that this
support has broken anything for any users.

I'm working on a project that is trying to make it feasible to use
these addresses in the long run, so we're trying to encourage more
OS developers to make them work.  I noticed that NetBSD still has the
traditional behavior in sys/netinet/in.c, and I've made a two-line patch
(exactly akin to patches we've made in other OS kernels) to remove these
special cases.  I've tested it on the current released NetBSD, and it
seems to interoperate properly on a LAN numbered with addresses from
these ranges (with other systems that already support them, obviously
not with those that don't).

NetBSD's existing support might be called "partial" since, as with
other systems that have inherited the BSD network implementation, it
forbids these addresses in in_canforward() but not in other contexts
like assignment to an interface.  (I don't think the partial support
will confuse users in practice, but it could be seen as an inconsistency.)

Would you be interested in my patch, or any other references or
background, or in discussing this topic further?

Thanks!