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

[Maria Matejka]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221221/ba2f9849/attachment-0001.htm>