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 < [email protected]> 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? > > > >
