<html><head></head><body>Hello!<br><br>TL;DR: 240/4 is already allowed, allowing 0/8 is not tested.<br><br>Long version:<br><br>I have several reasons why to reject this patch:<br><br>(1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose. <br><br>(2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing.<br><br>(3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable.<br><br>There are good technical reasons to keep legacy IP classifications, and even reclassifying 240/4 as site-local was essentially a bad compromise itself. I regret changing the default behavior in such a way that less vigilant operators may let unassigned 240/4 through BGP on the public internet. It's just a security hole itself.<br><br>If there is any problem or missing feature in BIRD in IPv6 routing, fixing or reporting that is the way to go.<br><br>Thank you for your understanding.<br><br>Maria<br><br><br><br><div class="gmail_quote">On 21 December 2022 06:13:40 CET, Seth David Schoen via Bird-users <bird-users@trubka.network.cz> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">Hi,<br><br>So, I've been continuing to work on possibilities for this and I see<br>three main approaches. I was wondering what the developers and users<br>think of these options.<br><br>(1) Don't hard-code the special treatment of 0/8 and 240/4 (like my<br>original patch), but also include a default like<br><br>route 0.0.0.0/8 prohibit;<br>route 240.0.0.0/4 prohibit;<br><br>in the sample bird.conf (and maybe in the documentation too).<br><br>(2) Add a new configuration directive available in bird.conf like<br>"unbogon" or "unicast" or something similar, which takes a netblock as an<br>argument and instructs BIRD not to reject that specific netblock (or its<br>subnets). Like one might then say something like<br><br>unbogon 0.0.0.0/8;<br>unbogon 240.0.0.0/4;<br><br>(3) Add a new configuration directive with no arguments that is<br>disabled by default, but, when encountered, disables the behavior of<br>rejecting any IPv4 blocks as bogons. (However, netblocks could<br>still be individually prohibited with additional configuration like<br>in option 1.)<br><br>In a kernel TCP/IP implementation I would imagine options like 2 and<br>3 could pose efficiency concerns because they would add more tests to<br>the critical path for routing decisions. But in BIRD's case this is<br>probably not relevant because tests for address range validity do not<br>need to be repeated extremely often.<br><br>I have a patch for option 1 already, but I've also been looking at the<br>configuration parser and could complete a patch for options 2 or 3 if<br>either of these would be preferable.<br><br>To be clear about the reason for suggesting this, we've been proposing<br>changes at IETF that would eventually eliminate the special treatment<br>of these ranges in Internet standards. We would like to demonstrate<br>that this is technically feasible and conduct tests in the future to<br>understand the extent to which historically reserved address can or<br>can't be used on the Internet. Apart from that, several large networks<br>are already known to be making unofficial internal use of subnets of<br>240/4 as private address space. (If any of those networks are using<br>BIRD, they've most likely patched it themselves.)<br><br>Most TCP/IP implementations (except Microsoft Windows) have already done<br>something similar to option 1 above, while several commercial<br>infrastructure-oriented routers have done something similar to option 2<br>(I speculate at the request of customers who use 240/4 unofficially).<br></pre></blockquote></div></body></html>