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?
