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