Re: Summary: what to do about INET/CIDR

* Alex Pilosov <alex@pilosoft.com> [001027 21:20]:
> Please read below if the whole thing with inet/cidr doesn't make you puke
> yet ;) The semi-longish proposal is at the bottom.
> 
> On Fri, 27 Oct 2000, Tom Lane wrote:
[snip]
> Actually, now that I think longer about the whole scheme in terms of
> actual IP experience, here are my ideas:
> a) inet is crock. I don't know anyone who would need to _care_ about a
> netmask of a host, who wouldn't have a lookup table of networks/masks.
> (Think /etc/hosts, and /etc/netmasks).
> 
> Storing a netmask of a network in a inet actually violates the relational
> constraints: netmask is not a property of an IP address, its a property of
> a network.
Not necessarily, especially for novices.  Some people may want to
store the netmask with the IP of a host (think ifconfig being
AUTOGEN'd). 

> 
> 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. 
> 
> 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. 
> 
> 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?
> 
> 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. 
> 
> select network from networks 
> where $1<<network 
> order by network_prefix(network)
> desc limit 1;
> 
> 
> I realise that this sounds a little bit strange after all the arguments
> about inet, but if you think about it, this is the only sane way to deal
> with these datatypes. 
> 
> Right now, the datatypes we have look and sound pretty but are pretty much
> useless in reality. Yes, it is nice to be able to store a netmask with
> every IP address, it is useless in reality. (Yes, please, someone tell me
> if you are using inet with netmasks and you actually like it).
> 
See above. 
> 
> I'd especially like to get input of Marc on this, as he's both a core team
> member and has actual networking background...Oh yeah, if Marc can comment
> on whether 10/8 or 10.0.0.0/8 is a proper way to represent a network, it'd
> be great too :)
> 
> 

-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749