Re: 16 year old bug

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 23 Aug 2010, at 07:40 , der Mouse wrote:

>> and most modern network hardware will turn their nose up at them
>> AFAIK.
> 
> IMO anything that pretends to implement IPv4 but which doesn't do
> noncontiguous netasks is simply broken, I don't care whether it comes
> from Cisco or Netgear or NetBSD.

For that to work at all across multiple implementations would require a
standard to tell you, when your destination address matches more
than one route, which of those routes takes precedence.  There is
a standard rule for routes with contiguous masks (the route with the
most 1-bits in the mask wins), but there isn't one for routes with
non-contiguous masks even though there are at least two reasonable, but
incompatible, alternatives (and many unreasonable, incompatible alternatives)
that could be chosen to define that precedence.  To see the problem,
consider the following two routes:

    10.141.42.91/255.191.255.255  -> A
    10.192.0.0/255.192.0.0        -> B

If you get a packet destined to 10.205.42.91 should you send it to
A or B?  The first route explicitly matches 31 of 32 address bits
in the destination while the second only matches 10.  Should it
matter that one of those 10 is "higher-order" than 22 of the 31?

Without a standard rule that results in all routers picking the
same route you can't use such routes and expect them to do something
useful.  IPv4 never had a rule for that so IPv4 never supported
routes like that, whether it explicitly banned such routes or not.

> Not, I suppose, that anyone necessarily cares what I consider broken.
> 
> Slow-path them.  Require a sysctl switch (the way we do for source
> routes).  Fine.  But outright desupport them?  I'd call that a bug,
> even if it is done deliberately.

I was actually at the pre-CIDR IETF meeting where it was discussed
whether to standardize the forwarding lookup for routes with
non-contiguous masks or disallow them altogether.  You are almost
20 years too late to influence that outcome.  If something else in the
kernel uses this functionality then that is an issue, but this shouldn't
be confused with anything related to standard IPv4.

Dennis Ferguson