Hello Maria, [off list]
I love your answer! Finally a clear statement on that re-classification mess. Next time we meet, remind me to buy you a drink of your choice! Thanks a lot for this, I fully support & agree with your statements. Best regards, Nico Maria Matejka via Bird-users <[email protected]> writes: > Hello! > > TL;DR: 240/4 is already allowed, allowing 0/8 is not tested. > > Long version: > > I have several reasons why to reject this patch: > > (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. > > (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. > > (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. > > 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. > > If there is any problem or missing feature in BIRD in IPv6 routing, fixing or > reporting that is the way to go. > > Thank you for your understanding. > > Maria > > On 21 December 2022 06:13:40 CET, Seth David Schoen via Bird-users > <[email protected]> wrote: > > 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). -- Sustainable and modern Infrastructures by ungleich.ch
