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

[Ondrej Zajicek]

On Sat, Dec 31, 2022 at 08:56:02PM +0100, Maria Matejka via Bird-users wrote:
> Hello!
> 
> On 12/31/22 16:17, Bernd Naumann via Bird-users wrote:
> > On 31.12.22 15:45, Juliusz Chroboczek via Bird-users wrote:
> > > > from my perspective the time to prolong the IPv4 usage is over.
> > > 
> > > I agree.
> > > [..]
> > > [..] I, for one, have changed my mind on the
> > > subject multiple times.
> 
> To clarify (and maybe amend a little) my position, I shall state this:
> 
> First of all, there is the previous patch which we reworked and merged, not
> realizing that if somebody has a policy "accept unless bad", then we are
> changing their behavior and they start accepting inherently bogon prefixes
> by upgrading to 2.0.10-11. This wasn't right and we should definitely fix it
> in 2.0.12 by reverting such unintended default behavior change.

Hi

I did not want to delve into this issue as i have no strong opinion one
way or the other, but i must disagree here. It was pretty clear to me
that merging the previous patch was changing the default behavior (so it
was an intended change), that is why i was hesitant with it. But it was
probably the least bad option and we should stick with it. The issue with
changing the default behavior cannot be undone by changing it again, that
just makes it two issues instead of one, and changing something to be
allowed is much less likely to break some setup than changing something
to be forbidden.

In this specific case, such change was unlikely to cause real problems
outside of pretty artificial scenarios, while reverting it would
obviously break setups that use 240/4.

In general, i think that 'keeping stable behavior' is a commitment that
should not be interpreted so strictly that it would conflict with
allowing new behavior. For example, we sometimes add new BGP capabilities
and make them enabled by default.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."