There is an effort to release IPV4 addresses from 240.0.0.0 to 255.255.255.254 (known as the Class E addresses) for use as normal internet space due to IPv4 exhaustion. See:
The feature request is for OpenWRT to cleanly support this address range, or at least actively monitor the issue. My very limited testing showed this address range being blocked by OpenWRT, but I did not explore further. Even if that test had worked, I would still want the address range to be properly tested in OpenWRTs test suite before I had confidence that it would always be handled properly.
FWIW, Microsoft also has a blog with some info on this issue, where they note Windows currently blocks the range and Linux has compatibility issues. They do not discuss whether enabling the range is easy or hard. See:
The incentive has to come from IANA, at present they are defined as multicast with very specific MAC space mapping and behaviour.
Your ethernet switches will go into fireworks mode if you use multicast MAC as source.
I don't think there's much to add, IPv6 is present right now - and reclaiming IPv4 address blocks that have been blacklisted for 43 years just isn't going to happen any sooner than IPv6 proliferation.
This was added to the Linux kernel some time ago. In fact, a majority of the discussions took place in these forums by the person originally responsible for its introduction.
Despite this, since the RFCs note that the Class E IP space is for a new IP technology (i.e. a technology other than Unicast, Broadcast, Multicast, etc.), its use for such networking purposes as you describe would still be invalid.
Additionally, be handled as invalid or unrecognized on other OSes and devices - and hence may result in undesired behavior when used within your network.
OpenWrt does not block or allow any specific IP ranges in its default firewall ruleset, it inherits any specific handling of particular subnets from the Linux kernel.
If upstream Linux „unblocks“ the use of this range, OpenWrt follows unless specific configuration is needed (such as sysctls). In this case a ticket should be raised requesting updated defaults.
Given the lack of available manpower I strongly doubt that any developer will actively pursue this topic.
Despite this, since the RFCs note that the Class E IP space is for a new IP technology (i.e. a technology other than Unicast, Broadcast, Multicast, etc.), its use for such networking purposes as you describe would still be invalid.
Additionally, be handled as invalid or unrecognized on other OSes and devices - and hence may result in undesired behavior when used within your network.