Re: Summary: what to do about INET/CIDR

On Fri, 27 Oct 2000, Larry Rosenman wrote:

> Not necessarily, especially for novices. Some people may want to
> store the netmask with the IP of a host (think ifconfig being
> AUTOGEN'd).
For a single host? Or for a network of hosts? But yes, I see your point if
a single host has x interfaces, and you are autogenerating ifconfig, with
my proposal, you'd need to insert each network into networks table.

> > 99% of people who would be storing IP addresses into postgres database
> > really do not know nor care what is a netmask on that IP. Only people who
> > would care are ones who store their _internal_ addresses (read: addresses
> > used on networks they manage). There is usually a very limited number of
> > such networks (<1000).
> I disagree. I'm an ISP, and the network engineer for same. I have a
> BOATLOAD of Netblocks from ARIN and providers in a BUNCH of sizes. I
> need to subnet them out to customers and for internal use. I like
> Tom's latest proposal. This one LOSES functionality for ME.
Explain how does it lose functionality?

> > It makes no sense to have in database both 10.0.0.1/24 and 10.0.0.2/16.
> > None whatsoever.
> Not necessarily, especially with RFC1918 addresses, and reuse within
> different unconnected networks of the SAME enterprise.
Makes no sense to have them in one table, anyway, I stand corrected.
For people in situation you describe, you can have a second table of
networks, and second function to look up networks in that table.

> > This does NOT apply to CIDR datatype, as there are real applications (such
> > as storing routing tables) where you would care about netmask, but won't
> > care about a host part.
> >
> > What I am suggesting is we do the following:
> > a) inet will NOT have a netmask
> Please DONT. See above.
> >
> > b) all the fancy comparison functions on inet should be deleted.
> > (leave only > >= = <= <)
> >
> Maybe. I think they should stay, but I'm one lowly network engineer.
> > c) the only things you can do on inet is to convert it to 4 octets (of
> > int1), to a int8, and to retrieve its network from a table of networks.
> >
> > d) have a table, 'networks' (or any other name, maybe pg_networks?) which
> > would have one column 'network', with type cidr.
> > create table networks (network cidr not null primary key)
> Why?
Because netmask is a property of a network, not of an IP address.

> > e) have a function network(inet) which would look up the address in a
> > table of networks using longest-prefix-match. I.E. something similar to:
> No need. Let the user do it themselves. Similar to what we did for
> macaddr's back in the summer.
Yeah, it can be user-defined (or a contrib), no question about it, and for
people who have more than one table of networks, it will _have_ to be
user-defined.

Actually, that's probably what I'll end up doing on my own.