Re: 16 year old bug

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 23 Aug 2010 21:46:16 -0400 (EDT)
    From:        der Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201008240146.VAA08612%Sparkle.Rodents-Montreal.ORG@localhost>

  | I wouldn't say _nothing_.  See below.

That's why I said "essentially nothing" - for your two /29's, you must have
had a max of 14 hosts.   You could have renumbered those in less than
half an hour, even if you had to manually do it to every one.   While that's
not nothing, it is close enough... (essentially nothing).   The real benefit
of this scheme was for big nets with hundreds or thousands of hosts that
would need to be renumbered - but for them, they're almost certainly going
to be forced into the renumber path, due to having some hosts that just
don't support non-contig masks, so in the place where the benefit really
should exist, it generally turns out to be illusory,

  | Irrelevant.  Nobody off-network can tell whether I'm using
  | noncontiguous netmasks within my network, so nobody but my
  | co-administrators has standing to even comment on the question.

That's true, you can do whatever you like on your network, and whoever
it was who used the term "illegal" was clearly incorrect, no matter what
you do, the police (not even the network police) aren't going to come and
cart you away because of it.

What should have been used instead was "leads to undefined behaviour".

That is, implementations are free to to whatever they like (these days)
if you use non-contig masks.  They can make them work (as NetBSD still
does) where that is possible, or they can simply ignore any netmask bits
set to the right of the first 0 bit, or they can count the number of set
bits, and treat the mask as meaning a /n for that number (simply ignore
your given mask except to use to count the set bits, then use that number
of the leftmost bits as the network number) or whatever else they like
(including issuing an error message when you attempt to configure it,
which some people might expect as the correct approach.)

That's the point of standardisation, and so is 100% in scope for the IETF
to make decisions about - what's defined is not how you're permitted to
run your network, but what you can expect of an implementation that you
obtain that claims it implements the standard.

You can, if you want, with IPv4 (and even with IPv6) use non-contig masks
if you like, you just can't expect that any random implementation will
do the same things with them that you anticipate.

You could if you wanted (again in either IPv4 or IPv6) run your network
with the destination address in the packets before the source address,
which (after all, and with hindsight) is the more rational way to design
the packets - things would work (very marginally) better [it makes a
difference for things that do switching/forwarding in hardware, they can
start the destination addr lookup than number of bit times sooner.]

You're free to do pretty much whatever you want, except to complain that
others aren't implementing it for you (well, you're also free to complain
of course, but you can expect to be ignored).

Right now I can't think of a particularly good reason for NetBSD to go
rip the non-contig mask handling code out of the kernel, so it is likely
to remain supported for some time yet (after all, it's there, and works).
But should someone decide to rewrite the forwarding code sometime, I
can't think of a good reason they should feel the need to continue to
handle this stuff.

kre