[PATCH] Don't treat 0/8 and 240/4 specially in IPv4 classification

Seth David Schoen schoen at loyalty.org
Wed Dec 21 06:13:40 CET 2022


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).


More information about the Bird-users mailing list