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

[Nico Schottelius]

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


--
Sustainable and modern Infrastructures by ungleich.ch