Non-continious network mask support

[Joerg Sonnenberger]

Hi all,
is there any objection to add code to detect and reject non-continious
network masks in the route code for all protocol and refuse them? I want
to merge that to the NetBSD 4 branch for preparing users and remove the
actual backend later in HEAD. The support is not really used by anyone
according to network people I talked with. It seems that at least Linux
for example already disallows that.

The feature is not really required as it can be emulated by splitting
the routes into smaller continious parts, so I don't really think we
loose anything. It is a major requirement for more intelligent index and
lookup datastructures.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Joerg Sonnenberger
is there any objection to add code to detect and reject
non-continious network masks in the route code for all protocol and
refuse them?
The feature is not really required as it can be emulated by splitting
the routes into smaller continious parts,

Except that this can be verbose - extremely verbose in extreme cases.
For example, to route a netmask of 255.254.57.96 under such a
resteriction would require thirty-two routes. A netmask of 255.255.0.1
would require 32768 routes. The real question is not "can we emulate
this" but "do enough people still use this to make it worth keeping".

If we do this, I think we either should forbid noncontiguous netmasks
on interfaces or add corresponding code somewhere to do the splitting
you refer to when adding or removing interface routes for interfaces
with noncontiguous netmasks.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by der Mouse
If we do this, I think we either should forbid noncontiguous netmasks
on interfaces or add corresponding code somewhere to do the splitting
you refer to when adding or removing interface routes for interfaces
with noncontiguous netmasks.

I want to kill the "feature" completely. I don't want the kernel to
handle it at all -- I don't think any non-local network still depends on
it, so admins should be able to convert the networks accordingly if they
still have such rules.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Joerg Sonnenberger

If we [remove routes to noncontiguous netmasks], I think we either
should forbid noncontiguous netmasks on interfaces or add
corresponding code somewhere to do the splitting you refer to when
adding or removing interface routes for interfaces with
noncontiguous netmasks.

I want to kill the "feature" completely.

Another reason to be glad I'mn not tracking -current, I guess. (I'd
much rather just pay a performance penalty if noncontiguous netmasks
are used. But I don't expect my opinion to make much difference.)

Post by Joerg Sonnenberger
I don't want the kernel to handle it at all -- I don't think any
non-local network still depends on it, so admins should be able to
convert the networks accordingly if they still have such rules.

You can't imagine any reason to use them, so no such reason exists?

Hrrmpf. (Well, actually, I suppose it's more "...so you're willing to
make NetBSD useless for such networks". Still hrrmpf.)

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by der Mouse

Post by Joerg Sonnenberger

If we [remove routes to noncontiguous netmasks], I think we either
should forbid noncontiguous netmasks on interfaces or add
corresponding code somewhere to do the splitting you refer to when
adding or removing interface routes for interfaces with
noncontiguous netmasks.

I want to kill the "feature" completely.

Another reason to be glad I'mn not tracking -current, I guess. (I'd
much rather just pay a performance penalty if noncontiguous netmasks
are used. But I don't expect my opinion to make much difference.)

It is not so much about the performance penalty, but the code
complexity. I would have to keep track of the original routes, check any
new route for possible affecting a non-contiguous netmask route, resolve
that conflict, possibly readd the partial route etc. That's a lot of
complexity for a functionality almost noone is using. I expect to find
it in pre-CIDR networks if it is still used at all. The real question
for those users is whether or not they have to equivalent route setup
already for other operating systems like Linux. I guess that is the
case. I'm asking this now as I want to deprecate it for NetBSD 4 first.

Post by der Mouse

Post by Joerg Sonnenberger
I don't want the kernel to handle it at all -- I don't think any
non-local network still depends on it, so admins should be able to
convert the networks accordingly if they still have such rules.

You can't imagine any reason to use them, so no such reason exists?

I can image reasons to use them, but I don't think they outweight the
complexity.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Zafer Aydogan]

Post by Joerg Sonnenberger
Hi all,
is there any objection to add code to detect and reject non-continious
network masks in the route code for all protocol and refuse them? I want
to merge that to the NetBSD 4 branch for preparing users and remove the
actual backend later in HEAD.

I'd appreciate your work very much :)
Especially if it makes it into 4.0.

Zafer.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de