Re: [HACKERS] cidr - Mailing list pgsql-hackers

> Thus spake Bruce Momjian
> > OK, let me explain what I think Paul was saying.  cidr is used for
> > networks.  You can use it for hosts by specifying /32.  It is not the
> > same as a netmask.  For example:
> >
> >     host    192.24.45.32
>
> Right but a netmask could be specified as 255.255.255.0/32.  Better yet,
> if all you want to store is a netmask in a field, use an int.  Every
> netmask can be specified in dotted notation or as a mask length.

But we want the int to print as a IP address, and I don't think we want
two types for IP addresses.  Too messy.

>
> > My idea is to internally store the new type as 8 bytes:
> >
> >     ____ ____ ____ ____ ____ ___ ___ ____
> >     cidr addr  x  .  x .  x .  x ip6 ip6
> >     bits len
>
> Why bother with the addr len?  Just expand it out with zeroes before
> storing it.

192.0.0.1 and 192.0.0.1.0.0 are different because one is IPv6, and the
other is not.  We must keep that distinction stored somewhere.  Might
was well use eight bytes.  The padding is going to take that much in
most cases anyway, unless they use char (length of 1) or int2 after the
field.

>
> Maybe we could make cidr bits equal to -1 if we are storing a host with
> indeterminate netmask rather than setting it to 32.  That allows us
> to specify raw IP numbers without faking a netmask.

Yes, that was the idea.  No one wants to see a netmask of
255.255.255.0/32.  I don't want to field those support e-mails.


>
> > Again, not sure we want to merge address and netmask for hosts in the
> > same field.
>
> Well, someone earlier suggested two different types, cidr for IPs with
> network info and inet for IPs by themselves.  The only argument against
> that as I recall was that the cidr type would hold IPs alone as a special
> case so why bother creating two different types?
>
> To review, here, I think, are the types of data we want to store and how
> I think we can handle them with the addition of a single cidr type.
>
> IP alone can be entered as a dotted quad with no netmask.  This would be
> stored as if a /32 was appended (or /-1 if we want a special flag.)
>
> IP and netmask can be entered as x.x.x.x/m or x.x.x.x:m.m.m.m.  If the
> former then store the IP and netmask.  If the latter then convert the
> dotted mask to masklen and store as the former.  Raise an exception if
> the dotted mask form is invalid such as 255.255.0.255.

Not sure if storing both IP and netmask in the same field is wise.  You
would have:

    192.0.0.3/24    cidr
    192.0.0.3:255.255.0.0   host/netmask
    192.0.0.3    host, implied netmask A,B,C class?
    192.0.0.3/32    host?
    192.0.0.3/32:255.255.255.0  host?/netmask

Interesting.  Comments?

>
> Network alone can be stored the same as IP numbers.  You need to specify
> the mask length since networks can end in zeroes.  Perhaps we can special
> case inputs that don't have all 4 octets and apply the old class rules
> but still store them like cidr addresses.  There is no need to add a
> flag to differentiate networks from addresses into the type since we
> use the field for one or the other so we know what it is when we need
> to display it.  It's like using int to store both ID numbers and counts.
> The database doesn't need to know the difference because we use any
> particular field to store one or the other.

Printing?

>
> Netmasks alone can be stored in an int field.

Again, we want a unified type, that makes sense to people.  It must
print out properly.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)