Hi, So, I've been continuing to work on possibilities for this and I see three main approaches. I was wondering what the developers and users think of these options.
(1) Don't hard-code the special treatment of 0/8 and 240/4 (like my original patch), but also include a default like route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit; in the sample bird.conf (and maybe in the documentation too). (2) Add a new configuration directive available in bird.conf like "unbogon" or "unicast" or something similar, which takes a netblock as an argument and instructs BIRD not to reject that specific netblock (or its subnets). Like one might then say something like unbogon 0.0.0.0/8; unbogon 240.0.0.0/4; (3) Add a new configuration directive with no arguments that is disabled by default, but, when encountered, disables the behavior of rejecting any IPv4 blocks as bogons. (However, netblocks could still be individually prohibited with additional configuration like in option 1.) In a kernel TCP/IP implementation I would imagine options like 2 and 3 could pose efficiency concerns because they would add more tests to the critical path for routing decisions. But in BIRD's case this is probably not relevant because tests for address range validity do not need to be repeated extremely often. I have a patch for option 1 already, but I've also been looking at the configuration parser and could complete a patch for options 2 or 3 if either of these would be preferable. To be clear about the reason for suggesting this, we've been proposing changes at IETF that would eventually eliminate the special treatment of these ranges in Internet standards. We would like to demonstrate that this is technically feasible and conduct tests in the future to understand the extent to which historically reserved address can or can't be used on the Internet. Apart from that, several large networks are already known to be making unofficial internal use of subnets of 240/4 as private address space. (If any of those networks are using BIRD, they've most likely patched it themselves.) Most TCP/IP implementations (except Microsoft Windows) have already done something similar to option 1 above, while several commercial infrastructure-oriented routers have done something similar to option 2 (I speculate at the request of customers who use 240/4 unofficially).
