The engine also sets any non-zero bits to 0 after the CIDR boundary, so:
161.15/14 becomes 161.12.0.0/14
These rules are the same whether the network part is specified or not.
you might want to be a bit more in line with internet standards. apologies for being too off balance here at apnic to give you an exact ref. but 127.1 is 127.0.0.1 etc.
Randy, you're showing your age. Yes, I know that inet_aton() on most systems interpret IP addresses specified with fewer-than-4 octets the way you indicate, and that this probably has roots down in arcane Internet History. The fact that the BSD documentation for inet_aton() makes explicit reference to class A/B/C networks points to this being a rather old convention. Also, inet_aton() is used to interpret an IP address when it stands alone (i.e. no mask given), which isn't really the case here. However, leaving aside the issue of the exact historical reference, the question remains why it would be a useful convention to adhere to in this particular context. Personally, I think it would add more confusion, because it mixes old classfull rules with classless notation, and would force you to put otherwise needless junk in your lookup string to force the "right" interpretation: in order to look up 161.15.0.0/14, you could not write 161.15/14, because that would become 161.0.0.15/14, so instead you'd have to write e.g. 161.15.1/14, which would become 161.15.0.1/14, which when masked with the prefix, becomes the intended 161.15.0.0/14. Perhaps if you disagree you could explain why this would be useful? There's also something to be said for not rocking the boat, as I think the current implementation has done what it does now for quite a while. Therefore, let's rather stick with the current rules. Regards, - Håvard