Re: [PATCH] Don't treat 0/8 and 240/4 specially in IPv4 classification
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?
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@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?
On Tue, 22 Nov 2022 at 20:42, Ross Tajvar via Bird-users <bird-users@trubka.network.cz> wrote:
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.
A middle ground could be to in the 2.X releases to use the current behaviour (default inclusion in the bogons, enable 0/8 and 240/4 to work using a config directive. *Then* in the 3.X releases, switch the behaviour (major behaviour change) to defaulting to omtting 0/8 and 240/4 from the default hard-coded bogons. Re-add the networks to the default (built-in) bogons list using a config directive.
participants (3)
-
Chriztoffer -
Ross Tajvar -
Seth David Schoen