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 <bird-users@trubka.network.cz> 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).