On Jan 11, 2008, at 3:00 PM, Andrew Sullivan wrote:
> On Fri, Jan 11, 2008 at 02:38:27PM -0800, Steve Atkins wrote:
>> I don't think there's ambiguity about what an dotted-quad without a
>> netmask
>> means, and hasn't been for a long time. Am I missing something?
>
> Well, maybe. The problem is actually that, without a netmask under
> CIDR,
> the address alone isn't really enough. You have to have a netmask
> to get
> the packets to the destination.
Not really. You may well need netmasks to configure your interface, but
there's absolutely no need for them to identify an IP endpoint, which
is all
you need to identify the destination the packet is going to, and that
is the
most common use of IP addresses.
> As it happens, we have some nice
> conventions, defined in the RFCs, for how to interpret hosts with no
> netmask; note though that some of those are only for humans. Or, to
> put it
> another way, without context, a dotted-quad is insufficient on its
> own.
> What you're really arguing is that the context ought to be storable
> somewhere else (maybe in a human's brain).
A dotted quad without any additional information is an IPv4 address,
the same as it would be if followed by "/32".
Netmasks are rarely needed at any level above routing
or (some forms of) address assignment, and that's where an awful lot
of use of IP
addresses happens. When you do need netmasks then the cidr type is
great, but that's not the common case.
(And the inet-with-a-netmask is an even odder duck, as it's packing
two mostly
unrelated bits of information into a single type).
> I'm not suggesting that's wrong,
> but I can see the "correctness" argument that someone might have
> made to get
> to the datatype as it exists. I think calling it "needless bloat"
> is just
> holding it to the wrong criteria.
>
>
> If you look at the binary wire data, that netmask is always
> represented in
> some sense. It can sometimes be more compact than the general-
> purpose data
> type, though, no question. This is why somewhere in this thread
> someone
> talked about optimisation: there certainly are ways to make these
> things
> more compact.
I think we're drifting a long way away from a -performance topic here,
as
we're agreed that inet or cidr are likely not the best types for the
original
poster to use.
Cheers,
Steve
