Re: 16 year old bug
On Tue 24 Aug 2010 at 11:10:55 -0400, der Mouse wrote: I believe that non-contiguous netmasks actually are illegal nowadays. Cite? RFC 4632 (CIDR Address Strategy), section 5.1: ...which is titled Rules for Route Advertisement. (Also, 4632 is a BCP, not a standard.) An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. With respect to route aggregation in advertisements (ie, exterally-visible behaviour). See the second paragraph of 5.2. Also (thinking perversely), this never says that the 1-bits in the mask must be left-justified... a mask of 0011 1100 has the whole mask contiguous... /~\ The ASCII Mouse -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: 16 year old bug
On Tue, 24 Aug 2010 17:53:38 -0700 Matt Thomas m...@3am-software.com wrote: I've been removing the use of radix and switching to ptree in the network rework. What's a ptree, patricia tree? Why is it better than radix tree?
Re: 16 year old bug
On Mon, Aug 23, 2010 at 09:46:16PM -0400, der Mouse wrote: I have. For a significant time (years) I was running my house LAN with a netmask ending in (binary) 11011000, I think it was - a /29 expanded by adding a second /29 from higher up. (The memory is very fuzzy, but 255.255.255.216 looks right.) The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of necessary. Was it useful? Definitely. Not visible outside its parent network, of course, but that's true of most subnetting schemes, including CIDR ones, and it was in live use for years. Pretty much the same result can be obtained by running something like Roy's parpd on the router and just configuring the end machines for the bigger subnet. Joerg
Re: 16 year old bug
der Mouse wrote: I believe that non-contiguous netmasks actually are illegal nowadays. Cite? RFC 4632 (CIDR Address Strategy), section 5.1: An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. I haven't bothered checking RFC 1519, but I would expect the same thing being said there. RFC 4632 obsoletes RFC 1519, so RFC 1519 is only of historical interest today anyway. They became illegal when CIDR was implemented. Implemented? I doubt it. Standardized, at most. But even then, it would take years to eliminate everything that supports them - indeed, I just now tried it and find that NetBSD 4.0.1 appears to support them. Implemented was the wrong word. Deployed is probably more correct. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: 16 year old bug
Steven Bellovin wrote: On Aug 24, 2010, at 12:02 42AM, der Mouse wrote: Was [running my house LAN with a noncontiguous netmask], for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. Actually, no. Unsupportable? I don't see anything unsupportable about it. Every system I tried (which admittedly wasn't all that many) supported it fine. Even today, I tried NetBSD 4.0.1 (the most recent I have easy admin access to) and it appeared to support it as well as whatever I was using at the time did - though admittedly I didn't actually verify that packets were routed the way the resulting routing table implied. Likely to cause bugs? Nonsense. Likely to expose existing bugs, perhaps. Do you not consider exposing existing bugs a good thing? I know I certainly do. Obsoleted 20 years ago? Perhaps. Strikes me as pretty functional and useful for an obsoleted feature. Besides, this _was_ 20 years ago - well, actually more like 15±5; I didn't have much of a house LAN before maybe 1991, and I stopped using the address space this was embedded in sometime around 2000-2001. The problem is, as has been noted, the lack of a good definition of the routing table with mixed prefixes. If everyone uses a mask of, say, 0xA596695A, it all just works. But if some routers use 0xA95696A5 and others use 0xA596695A, the semantics are unclear. The fact that the semantics are unclear don't automatically make it non-functional. IP was designed with the throught that things might work differently in different parts of the network, and that each packet might be routed differently, and things will still work. Quite frankly, the routers might be as confused as they want to. As long as they forward packets along *some* route, we'll probably be just happy. If routers managed to set up some kind of loop, in which certain masks makes two routers just send a packet back and forth, then we get a broken situation, but I can't really see a correctly configured router being setup in a way that this situation exists. But maybe I just lack imagination. So, when all is said and done (from my side), my view is that while I believe that non-continuous masks are not allowed I see no good reason to forbid people to set them up if they want to. Non-contiguous masks can indeed be useful, albeit only in specialized topologies and networks. I could have used them in a paper I published just 1.5 years ago. The trouble is that they conflicted with the routing table definition necessary for CIDR, and CIDR was and is necessary for the survival of the Internet. None of this, however, has any relationship to what the original poster said, which is that the current code is also used in IPsec and has a performance bug. And *that* is completely unrelated to whether or not non-contiguous masks are a good idea! Indeed. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: 16 year old bug
Date:Mon, 23 Aug 2010 21:46:16 -0400 (EDT) From:der Mouse mo...@rodents-montreal.org Message-ID: 201008240146.vaa08...@sparkle.rodents-montreal.org | 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
Re: 16 year old bug
There is only one reason to use non-contiguous IP masks for *ROUTING* tables (vs for IPsec SPDs, where a there might be multiple IP subnets in the 5-tuple): IPv4 scarcity Whether or not it's real scarcity or not, does not matter. Would I spend any time fixing non-contiguous netmask bugs? No. I'd tell the person to go to IPv6. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition.
Re: 16 year old bug
Date:Tue, 24 Aug 2010 08:43:52 -0400 From:Michael Richardson m...@sandelman.ca Message-ID: 5933.1282653...@marajade.sandelman.ca | There is only one reason to use non-contiguous IP masks for *ROUTING* | tables (vs for IPsec SPDs, where a there might be multiple IP subnets in | the 5-tuple): | IPv4 scarcity It actually doesn't help for that at all. Ambiguous masks might, perhaps, but they just don't work, and never did. But non-contig masks (the simple ones) can always be turned into contig ones by just moving the bits in the addresses around (and hence renumbering hosts). Since there is a contig mask for every non-contig (simple) scheme that you can devise, using non-contig itself cannot possibly have any effect upon address usage. It just saves renumbering effort (occasionally). And some people consider it sexy... kre
Re: 16 year old bug
On Mon, 23 Aug 2010 23:21:37 -0400 Thor Lancelot Simon t...@panix.com wrote: On Mon, Aug 23, 2010 at 10:15:58PM -0400, Perry E. Metzger wrote: On Mon, 23 Aug 2010 21:46:16 -0400 (EDT) der Mouse mo...@rodents-montreal.org wrote: The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of necessary. Was it useful? Definitely. Was it, for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. That's silly. A bitmask is a bitmask, and there's nothing magical or difficult about masked compare. It is difficult to reason about the effects of non-contiguous bitmasks when dealing with security critical code. What happens when one is using bitmasks as part of generating data structures in filter code? What happens when you deal with non-contiguous blocks as part of building routing data structures? There are loads of places where odd effects can happen. Code that is rarely or ever used is code where dragons lurk. I could care less whether support for noncontiguous subnet masks were to disappear, Then don't argue against it. but I would strongly prefer that nothing _else_ in the system that relies on the IP stack supporting them be needlessly broken in the process just so we can say we're modern and stylish. That's just irresponsible. I don't think anyone was arguing in favor of breaking the stack in order to be stylish. I think people were arguing in favor of getting rid of a whole class of problems by doing input validation. -- Perry E. Metzgerpe...@piermont.com
Re: 16 year old bug
On Tue, 24 Aug 2010 09:25:10 +0200 Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Aug 23, 2010 at 11:21:37PM -0400, Thor Lancelot Simon wrote: That's silly. A bitmask is a bitmask, and there's nothing magical or difficult about masked compare. Even the bug OpenBSD just fixed -- now that it basically doesn't matter any more -- is hardly complex nor is the fix so. The issue with non-cont netmask is that it dramatically complicates the lookup code. I'd say that at least 1/3 of the radix tree implementation is just related to this feature. And is rarely tested, and thus more likely to be a place where bugs lurk, including security bugs. -- Perry E. Metzgerpe...@piermont.com
Re: 16 year old bug
Matt Thomas m...@3am-software.com wrote: On Aug 24, 2010, at 12:25 AM, Joerg Sonnenberger wrote: On Mon, Aug 23, 2010 at 11:21:37PM -0400, Thor Lancelot Simon wrote: That's silly. A bitmask is a bitmask, and there's nothing magical or difficult about masked compare. Even the bug OpenBSD just fixed -- now that it basically doesn't matter any more -- is hardly complex nor is the fix so. The issue with non-cont netmask is that it dramatically complicates the lookup code. I'd say that at least 1/3 of the radix tree implementation is just related to this feature. Even worse, it's inefficient on newer hardware. Most platforms have a count-leading operation which dramatically increases the lookups. Also knowing the datatype and using datatype specific comparison speeds it up even more. I've been removing the use of radix and switching to ptree in the network rework. Seems like there are good reasons to kill that code, especially the code complexity. I am also keen to see your ptree-based code. -- Mindaugas
16 year old bug
... has been found by OpenBSD: Their commit message: Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. For masks of identical length rn_lexobetter() did not stop on the first non-equal byte. This leads rn_addroute() to not detecting duplicate entries and thus we might create a very long list of masks to check for each node. This can have a huge impact on IPsec performance, where non-contiguous masks are used for the flow lookup. In a setup with 1300 flows we saw 400 duplicate masks and only a third of the expected throughput. The patch is attached. Any comments? Christoph Index: sys/net/radix.c === RCS file: /cvsroot/src/sys/net/radix.c,v retrieving revision 1.43 diff -u -p -r1.43 radix.c --- sys/net/radix.c 27 May 2009 17:46:50 - 1.43 +++ sys/net/radix.c 23 Aug 2010 11:50:07 - @@ -559,12 +559,15 @@ rn_lexobetter( const u_char *lim; if (*mp *np) - return 1; /* not really, but need to check longer one first */ - if (*mp == *np) - for (lim = mp + *mp; mp lim;) - if (*mp++ *np++) -return 1; - return 0; + return 1; + if (*mp *np) + return 0; + /* + * Must return the first difference between the masks + * to ensure deterministic sorting. + */ + lim = mp + *mp; + return (memcmp(mp, np, *lim) 0); } static struct radix_mask *
Re: 16 year old bug
On Mon Aug 23 2010 at 13:53:40 +0200, Christoph Egger wrote: ... has been found by OpenBSD: Their commit message: Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. For masks of identical length rn_lexobetter() did not stop on the first non-equal byte. This leads rn_addroute() to not detecting duplicate entries and thus we might create a very long list of masks to check for each node. This can have a huge impact on IPsec performance, where non-contiguous masks are used for the flow lookup. In a setup with 1300 flows we saw 400 duplicate masks and only a third of the expected throughput. The patch is attached. Any comments? The test for this is missing.
Re: 16 year old bug [with non-contiguous netmasks]
On Mon, 23 Aug 2010, Christoph Egger wrote: [OpenBSD] commit message: Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. I suggest removing support for non-contiguous netmasks. They are unusable with CIDR (introduced in 1993 in RFCs 1517, 1518, and 1519). Even RFC 950 (August 1985) recommended that subnet bits should be contiguous. --apb (Alan Barrett)
Re: 16 year old bug
Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. [...] Does our IPSEC code actually _use_ non-continguous netmasks? While RFC950 technically allows them, they're recommended against, and most modern network hardware will turn their nose up at them AFAIK. (Note that I'm not saying that there isn't a bug in the way this routine is used - but if non-contiguous netmasks are used elsewhere, I'd be very surprised if other pieces of code also were not similarly 'buggy'.)
Re: 16 year old bug [with non-contiguous netmasks]
On Mon, Aug 23, 2010 at 03:43:06PM +0200, Alan Barrett wrote: On Mon, 23 Aug 2010, Christoph Egger wrote: [OpenBSD] commit message: Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. I suggest removing support for non-contiguous netmasks. They are Then please find another way for IPsec to match packets, before you rip out the one it uses now. Thor
Re: 16 year old bug [with non-contiguous netmasks]
Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. I suggest removing support for non-contiguous netmasks. They are Then please find another way for IPsec to match packets, before you rip out the one it uses now. If you can't rely on the masks being contiguous, why not use (e.g.) heapsort instead? I'd think the whole reason you have the specific netmask-sorting algo is for the optimized case where you _do_ have contiguous netmasks; if that doesn't hold, though, you may as well use something that's already in the kernel and (presumably) tuned.
Re: 16 year old bug
Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. Does our IPSEC code actually _use_ non-continguous netmasks? I haven't looked at the IPsec code, so this is a guess, but the wording makes it sound as though this is an implementation technique used internally by IPsec rather than being the externally-visible use of noncontiguous netmasks everyone seems to be taking it for. That said, 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. 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. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 16 year old bug
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. 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 believe that non-contiguous netmasks actually are illegal nowadays. They became illegal when CIDR was implemented. That said, it might be worth having a way to enable the legacy view of network address classes and netmasks, if someone wants to...? Johnny
Re: 16 year old bug [with non-contiguous netmasks]
On Mon, Aug 23, 2010 at 03:43:06PM +0200, Alan Barrett wrote: On Mon, 23 Aug 2010, Christoph Egger wrote: [OpenBSD] commit message: Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. I suggest removing support for non-contiguous netmasks. They are unusable with CIDR (introduced in 1993 in RFCs 1517, 1518, and 1519). Even RFC 950 (August 1985) recommended that subnet bits should be contiguous. Agreed. I think it was pretty much the consensus too when this was discussed the last time. Joerg
Re: 16 year old bug
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
Re: 16 year old bug
Date:Mon, 23 Aug 2010 11:48:58 -0700 From:Dennis Ferguson dennis.c.fergu...@gmail.com Message-ID: 3950466d-2c2e-4c4e-b697-a16c62971...@gmail.com | 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. This is actually a different issue - that's ambiguous netmasks, and you're right, they were never supported - we did at one stage consider whether or not they ever could be, but the reasons for using them were so obscure, and the possible effects so scary, that no-one ever bothered to define anything, so those things never worked, sensibly anyway, anywhere. If they did, they would allow a whole set of new (not necessarily useful) routing possibilities, that IPv4 (and IPv6 of course) can't handle today. On the other hand, simple non-contig netmasks, with no ambiguity, certainly were permitted originally. They work just fine. They also offer essentially nothing over contig netmasks - they're just a permutation of the bits in the addresses. The one (the only) reason they were permitted, that I know of anyway, was that by allowing them we apparently let some (perhaps hypothetical) sites implement subnets without altering their existing IP numbering scheme. I personally never saw such a site, and have no direct evidence one ever existed (or that anyone ever actually used non-contig netmasks for this reason) - but that was the argument anyway. Use of them effectively died when original MacOS IP used a GUI for its netmask config (back before everyone used DHCP for this purpose) - with a slider to set the division between the network and host parts - obviously nothing non-contig was possible. Since just about every site that could conceivably have wanted to use non-contig netmasks was likely to also have macs, and want to use IP on them - use of a non-contig mask simply failed. So they just died away... | 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. As was I. | You are almost 20 years too late to influence that outcome. Yes, they're dead. | 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. Agreed. And to correct (which you also kind of did just above) an earlier statement on this issue from someone else - it wasn't CIDR that killed non-contig netmasks, CIDR is pretty much irrelevant to this (CIDR affects external routing, as in BGP, subnet masks are an intra-domain routing factor (as in IGP rather than EGP). If CIDR was relevant to the decision (which I don't think it was, as you indicate, this was all pre-CIDR) it would have only been in that it made people think more about netmasks, and what else should be done with them. Unfortunately, I'm not sure that much of this work ever got documented, there was much interesting work done in the first router requirements attempt (which was where much of this was discussed) but it essentially all vanished into a black hole... kre
Re: 16 year old bug
On the other hand, simple non-contig netmasks, with no ambiguity, certainly were permitted originally. They work just fine. They also offer essentially nothing over contig netmasks - they're just a permutation of the bits in the addresses. I wouldn't say _nothing_. See below. The one (the only) reason they were permitted, that I know of anyway, was that by allowing them we apparently let some (perhaps hypothetical) sites implement subnets without altering their existing IP numbering scheme. I personally never saw such a site, and have no direct evidence one ever existed (or that anyone ever actually used non-contig netmasks for this reason) - but that was the argument anyway. I have. For a significant time (years) I was running my house LAN with a netmask ending in (binary) 11011000, I think it was - a /29 expanded by adding a second /29 from higher up. (The memory is very fuzzy, but 255.255.255.216 looks right.) The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of necessary. Was it useful? Definitely. Not visible outside its parent network, of course, but that's true of most subnetting schemes, including CIDR ones, and it was in live use for years. 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. Out of scope. A host's routing implementation is not visible from the network; it is not a matter for the IETF to standardize. If you want to forbid noncontiguous netmasks in wire protocols like BGP or RIP or whatever, that is in scope, but also irrelevant to what you're describing. You are almost 20 years too late to influence that outcome. 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. Of course, NetBSD may, if it wishes, desupport them. It also may, if it wishes, desupport netmask boundaries falling other than on octet boundaries. I would call the one a bug just as I would the other. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 16 year old bug
I believe that non-contiguous netmasks actually are illegal nowadays. Cite? They became illegal when CIDR was implemented. Implemented? I doubt it. Standardized, at most. But even then, it would take years to eliminate everything that supports them - indeed, I just now tried it and find that NetBSD 4.0.1 appears to support them. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 16 year old bug
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. That...disagrees with my experience. I ran my house LAN with a noncontiguous netmask for years without any such standard. Worked just fine. Perhaps you meant to work consistently in certain cases rather than to work at all? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 16 year old bug
On Mon, 23 Aug 2010 21:46:16 -0400 (EDT) der Mouse mo...@rodents-montreal.org wrote: The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of necessary. Was it useful? Definitely. Was it, for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. I would say that the robustness of the networking code is more important than a rare use that provides slight convenience. Of course, NetBSD may, if it wishes, desupport them. It also may, if it wishes, desupport netmask boundaries falling other than on octet boundaries. I would call the one a bug just as I would the other. That is your privilege. I believe, however, that you are alone in this opinion. -- Perry E. Metzgerpe...@piermont.com
Re: 16 year old bug
On Mon, Aug 23, 2010 at 10:15:58PM -0400, Perry E. Metzger wrote: On Mon, 23 Aug 2010 21:46:16 -0400 (EDT) der Mouse mo...@rodents-montreal.org wrote: The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of necessary. Was it useful? Definitely. Was it, for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. That's silly. A bitmask is a bitmask, and there's nothing magical or difficult about masked compare. Even the bug OpenBSD just fixed -- now that it basically doesn't matter any more -- is hardly complex nor is the fix so. If it were so onerous to write correct code to do masked compares on bitstrings I shudder to think what else in our kernel would be broken forever. But it's not. I could care less whether support for noncontiguous subnet masks were to disappear, but I would strongly prefer that nothing _else_ in the system that relies on the IP stack supporting them be needlessly broken in the process just so we can say we're modern and stylish. That's just irresponsible. Thor
Re: 16 year old bug
Was [running my house LAN with a noncontiguous netmask], for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. Actually, no. Unsupportable? I don't see anything unsupportable about it. Every system I tried (which admittedly wasn't all that many) supported it fine. Even today, I tried NetBSD 4.0.1 (the most recent I have easy admin access to) and it appeared to support it as well as whatever I was using at the time did - though admittedly I didn't actually verify that packets were routed the way the resulting routing table implied. Likely to cause bugs? Nonsense. Likely to expose existing bugs, perhaps. Do you not consider exposing existing bugs a good thing? I know I certainly do. Obsoleted 20 years ago? Perhaps. Strikes me as pretty functional and useful for an obsoleted feature. Besides, this _was_ 20 years ago - well, actually more like 15±5; I didn't have much of a house LAN before maybe 1991, and I stopped using the address space this was embedded in sometime around 2000-2001. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 16 year old bug
On Aug 24, 2010, at 12:02 42AM, der Mouse wrote: Was [running my house LAN with a noncontiguous netmask], for practical purposes, unsupportable? Was it something likely to cause subtle bugs all over the networking stack? Was it something obsoleted more or less 20 years ago? All yes. Actually, no. Unsupportable? I don't see anything unsupportable about it. Every system I tried (which admittedly wasn't all that many) supported it fine. Even today, I tried NetBSD 4.0.1 (the most recent I have easy admin access to) and it appeared to support it as well as whatever I was using at the time did - though admittedly I didn't actually verify that packets were routed the way the resulting routing table implied. Likely to cause bugs? Nonsense. Likely to expose existing bugs, perhaps. Do you not consider exposing existing bugs a good thing? I know I certainly do. Obsoleted 20 years ago? Perhaps. Strikes me as pretty functional and useful for an obsoleted feature. Besides, this _was_ 20 years ago - well, actually more like 15±5; I didn't have much of a house LAN before maybe 1991, and I stopped using the address space this was embedded in sometime around 2000-2001. The problem is, as has been noted, the lack of a good definition of the routing table with mixed prefixes. If everyone uses a mask of, say, 0xA596695A, it all just works. But if some routers use 0xA95696A5 and others use 0xA596695A, the semantics are unclear. Variable-length masks are not simply a matter of the enterprise/ISP boundary. They can and do occur within an organization. My own department has at least 3 different prefix lengths. And that problem is old -- I'm sure other folks who've been in this racket for a while remember the SUBNETSARELOCAL kernel configuration option. Non-contiguous masks can indeed be useful, albeit only in specialized topologies and networks. I could have used them in a paper I published just 1.5 years ago. The trouble is that they conflicted with the routing table definition necessary for CIDR, and CIDR was and is necessary for the survival of the Internet. None of this, however, has any relationship to what the original poster said, which is that the current code is also used in IPsec and has a performance bug. And *that* is completely unrelated to whether or not non-contiguous masks are a good idea! --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: 16 year old bug
t...@panix.com (Thor Lancelot Simon) writes: I could care less whether support for noncontiguous subnet masks were to disappear, but I would strongly prefer that nothing _else_ in the system that relies on the IP stack supporting them be needlessly broken in the process just so we can say we're modern and stylish. That's just irresponsible. If you (not you Thor :-)) wanted to be modern and stylish you would just use IPv6 and no noncontigous netmask would bother you. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
