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

[Ross Tajvar]

As an operator, I would be frustrated if I spent a while trying to get 0/8
or 240/4 to work, only to discover that I needed to use a special config
directive to "enable" those prefixes. My preference would be to include
them in a default-config bogons list.

On Sat, Nov 19, 2022 at 9:27 PM Seth David Schoen via Bird-users <
bird-users at trubka.network.cz> wrote:

> Daniel Suchy writes:
>
> > With respect to (for example) RFC 8212, such features should have
> > reverse logic - default behavior should be blocking that, but there
> > might be configuration option to change default prefix clasification
> > explicitly, if needed for any reason...
> >
> > In such cases, mind is changing. And it's more secure to have strict
> > defaults here...
> >
> > Your patch doesn't care about security here...
> >
> > For example - Junos has for these special cases different behavior (
> > routing-options martians x.x.x.x/y allow ). Such way of handling of
> > special prefixes should be generally preffered...
>
> Yes, I've been following this a lot because I'm working on a project to
> attempt to unreserve these addresses, and we are trying to document how
> everyone handles them, in addition to making proposals and patches to stop
> treating them specially.
>
> It does seem like infrastructure-oriented routing implementations have
> often preferred to keep a default of blocking them with an option for
> individual sites to change that.
>
> Would it be appropriate to do this with a default bird.conf entry (perhaps
> also shipped by OS packages), or do some people write their configurations
> from scratch without referring to default/example configurations? In the
> latter case, would you prefer to see a new configuration directive like the
> Junos version?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221122/5c740d8f/attachment.htm>