Thread: Definitional issue for INET types
I tried fixing some of the known problems with comparison of INET values
(cf. thread "uniqueness not always correct" on 11/11/99, among others),
and was surprised to discover that my changes affected the results of
the inet regress test. Specifically, the regress test exercises all the
inet comparison operators on the two data values'10.1.2.3/8'::inet '10.0.0.0/32'::cidr
The old code believes that the first of these is greater, while my
revised code thinks the second is greater.
Now, my understanding of things is that '10.1.2.3/8' is just an
unreasonably verbose way of writing '10/8', because if you write /8
you are saying that only the first 8 bits mean anything. So it seems
to me that we are really comparing '10/8' and '10.0.0.0/32', and the
former should be considered the lesser in the same way that 'ab'
comes before 'abc' in dictionaries.
Is the regress test's expected output wrong, or have I missed
something?
regards, tom lane
Tom Lane wrote: > Now, my understanding of things is that '10.1.2.3/8' is just an > unreasonably verbose way of writing '10/8', because if you write /8 > you are saying that only the first 8 bits mean anything. Not really. In a classed view on a network, the /8 is undefined - and worse, there is no real concept of a address consisting of a network/netmask tuple. /8 might imply that 10.1.2.3 is in the class A segment, it might be considered a 255.0.0.0 netmask with any possible interpretation of the latter, or it might be entirely ignored. For ::cidr vs. ::cidr the answer is clear - apply the masks and match then, which would make 10/8 lesser by all means. > So it seems > to me that we are really comparing '10/8' and '10.0.0.0/32', and the > former should be considered the lesser in the same way that 'ab' > comes before 'abc' in dictionaries. > > Is the regress test's expected output wrong, or have I missed > something? Tough question. There are some nasty details differing between classed network notation and CIDR notation, and we certainly cannot reconcile them all in operators. As the significant digits are meaningless in classed notation, they might either be ignored or interpreted according to any rule applying to classed netmasks, which really depends on the context of the network device - a router, firewall or audit tool might each have different semantics and requirements. I'll see whether I can figure out something consistent for the inet data type. As it is right now, we might just as well drop it - it is both synonymous to cidr and to a cidr /32 host, which simply can't be. Personally, I don't think we would lose any functionality if we drop it, as long as we have functions that return classed network structures like the base address and a networks subnettable range. Sevo -- Sevo Stille sevo@ip23.net
On Thu, 17 Feb 2000, Tom Lane wrote: > '10.1.2.3/8'::inet '10.0.0.0/32'::cidr > The old code believes that the first of these is greater, while my > revised code thinks the second is greater. I think we can flip a three-sided coin here: 1) '10.1.2.3/8'::inet is not a valid inet input value, sort of in the same way as 10.5 is not a valid integer. 2) You coerce '10.1.2.3/8'::inet to essentially '10.0.0.0/8'::inet on input. (In some parts, implicit data mangling that loses information is not considered good practice.) 3) You can't compare inet and cidr because they're two different (albeit similar) things. If you want to compare them you have to explicitly cast inet to cidr or vice versa according to 1) or 2). In any case I believe you revised code has a very good point. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> 3) You can't compare inet and cidr because they're two different (albeit
> similar) things. If you want to compare them you have to explicitly cast
> inet to cidr or vice versa according to 1) or 2).
This might in fact be the right answer --- maybe CIDR and INET should
have different comparison semantics. Right now the two types seem to
share exactly the same operators, which makes me wonder why we have
both.
I don't suppose Paul Vixie is still reading this list. Someone should
contact him and ask where we went wrong. Who was our point man on the
network types to begin with?
regards, tom lane
Sevo Stille <sevo@ip23.net> writes:
> I'll see whether I can figure out something consistent for the inet data
> type. As it is right now, we might just as well drop it - it is both
> synonymous to cidr and to a cidr /32 host, which simply can't be.
> Personally, I don't think we would lose any functionality if we drop it,
> as long as we have functions that return classed network structures like
> the base address and a networks subnettable range.
Hmm. One way to throw the question into stark relief is to ask:
Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
and operations like SELECT DISTINCT should consider them identical?
Does your answer differ depending on whether you assume the values
are of CIDR or INET type?
Once we have decided if they are equal or not, we can certainly manage
to come up with a sort ordering for the cases that are not equal.
regards, tom lane
Tom Lane wrote: > Hmm. One way to throw the question into stark relief is to ask: > Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes > and operations like SELECT DISTINCT should consider them identical? > Does your answer differ depending on whether you assume the values > are of CIDR or INET type? Well, in a CIDR context, they positively are different, '10.0.0.0/32' is a host, and '10/8' is a network, and our application would positively treat either entirely different. CIDR consistently works by apply-mask-and-process. In a INET context, the answer is not that easy, as net and mask have no defined behaviour as a tuple. The mask will in some cases be a independent entity, which presumably is why Paul Vixie made meaningless net/mask combinations legal there. If INET is used to store e.g. a Cisco wildcard value, the /xx part is meaningless - however, 10.1.2.3/8 would not be a shorthand for 10/8 then. As far as ipmeter is concerned, we found out that INET is of no use for us - even if there are some strange things you might do with odd net/mask patterns, few of them follow any easily defined paradigm. Personally, I am all for dropping INET, or for defining it to be maskless (which could be done by forcing /32 for it). Sevo
Sevo Stille <sevo@ip23.net> writes:
>> Hmm. One way to throw the question into stark relief is to ask:
>> Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
>> and operations like SELECT DISTINCT should consider them identical?
>> Does your answer differ depending on whether you assume the values
>> are of CIDR or INET type?
> Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
> a host, and '10/8' is a network, and our application would positively
> treat either entirely different. CIDR consistently works by
> apply-mask-and-process.
OK. Now let's try you on this one: true or false?'10.1.2.3/8'::cidr = '10/8'::cidr
(which was actually the example I meant to ask about above, but
carelessly cut-and-pasted the wrong values :-(.)
> In a INET context, the answer is not that easy, as net and mask have no
> defined behaviour as a tuple. The mask will in some cases be a
> independent entity, which presumably is why Paul Vixie made meaningless
> net/mask combinations legal there.
I think that was the idea, all right, which would seem to suggest that
we ought to compare all the bits of the IP addresses, and then compare
the bitcounts (since the bitcount is just a compact representation of a
logically separate netmask, and has nothing to do with the validity of
the IP address). But I'm not sure whether this holds good for CIDR too.
> Personally, I am all for dropping INET, or for defining it to be
> maskless (which could be done by forcing /32 for it).
If you don't need a mask, leave out the /32 --- or even add a column
constraint requiring it to be 32. I don't see that it's necessary
to tell other people that they can't have a mask. CIDR may be a
different story however.
regards, tom lane