Thread

Re: [HACKERS] cidr

Paul A Vixie <vixie@vix.com> — 1998-07-21T04:59:18Z

> I missed some of the earlier discussion.  Is there going to be a separate
> IP type or is that just x.x.x.x/32?  I like the idea of a host type as
> well.  I would love to sort my IPs and have 198.96.119.99 precede
> 198.96.119.100.

the ordering functions given in the implementation i posted here yesterday
do that, and they also show 192.5.5/24 as being "before" 192.5.5.0/32, which
is important for those of us who import routing tables into database tables.

i don't see a need for a separate type for /32's; if someone enters just the
dotted quad (198.96.119.100 for example) the "/32" will be assumed.  i'd be
willing to see the "/32" stripped off in the output function since it's a bit
redundant -- i didn't do that but it's out of habit rather than strong belief.

if folks really can't get behind "CIDR" then may i suggest "INET"?  it's not
a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST".  it is capable of
representing either a network or a host, classlessly.  that makes it a CIDR
to those in the routing or registry business.  and before someone asks: no,
it is not IPv4-specific.  my implementation encodes the address family and
is capable of supporting IPv6 if the "internallength" wants to be 13 or if
someone knows how to make it variable-length.

Re: [HACKERS] cidr

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-07-21T05:13:34Z

> > I missed some of the earlier discussion.  Is there going to be a separate
> > IP type or is that just x.x.x.x/32?  I like the idea of a host type as
> > well.  I would love to sort my IPs and have 198.96.119.99 precede
> > 198.96.119.100.
> 
> the ordering functions given in the implementation i posted here yesterday
> do that, and they also show 192.5.5/24 as being "before" 192.5.5.0/32, which
> is important for those of us who import routing tables into database tables.
> 
> i don't see a need for a separate type for /32's; if someone enters just the
> dotted quad (198.96.119.100 for example) the "/32" will be assumed.  i'd be
> willing to see the "/32" stripped off in the output function since it's a bit
> redundant -- i didn't do that but it's out of habit rather than strong belief.

The only problem is that if we assume /32, how do we auto-netmask class
A/B/C addresses?  I guess we don't.  If they want a netmask, they are
going to have to specify it in cidr format.

I will be honest.  I always found the network/host IP address
distinction to be very unclearly outlined in old/non-cidr address
displays, and this causes major confusion for me when trying to figure
out how things are configured.


> if folks really can't get behind "CIDR" then may i suggest "INET"?  it's not
> a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST".  it is capable of
> representing either a network or a host, classlessly.  that makes it a CIDR
> to those in the routing or registry business.  and before someone asks: no,
> it is not IPv4-specific.  my implementation encodes the address family and
> is capable of supporting IPv6 if the "internallength" wants to be 13 or if
> someone knows how to make it variable-length.

I like INET too.  It is up to you.

-- 
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)

Re: [HACKERS] cidr

Marc G. Fournier <scrappy@hub.org> — 1998-07-21T12:04:56Z

On Tue, 21 Jul 1998, Bruce Momjian wrote:

> > if folks really can't get behind "CIDR" then may i suggest "INET"?  it's not
> > a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST".  it is capable of
> > representing either a network or a host, classlessly.  that makes it a CIDR
> > to those in the routing or registry business.  and before someone asks: no,
> > it is not IPv4-specific.  my implementation encodes the address family and
> > is capable of supporting IPv6 if the "internallength" wants to be 13 or if
> > someone knows how to make it variable-length.
> 
> I like INET too.  It is up to you

	I'm sticking to this one like glue...the proper terminology is a
CIDR...using anything else would be tailoring to "those that don't want to
know better", which I believe is the business Micro$loth is in, no? 

	If you don't know what a CIDR is, you probably shouldn't be using
it and should get out of networking...

Re: [HACKERS] cidr

Matthew N. Dodd <winter@jurai.net> — 1998-07-21T14:00:03Z

On Mon, 20 Jul 1998, Paul A Vixie wrote:
> i don't see a need for a separate type for /32's; if someone enters just the
> dotted quad (198.96.119.100 for example) the "/32" will be assumed.  i'd be
> willing to see the "/32" stripped off in the output function since it's a bit
> redundant -- i didn't do that but it's out of habit rather than strong belief.

I don't see a problem with having a separate type for /32's.  It doesn't
hurt anything, and it takes up less room that a CIDR.  When you've got
several million records this becomes an issue.  (Not from a perspective of
space, but more data requires more time to muck through during queries.)

Plus, it would enable me to use my existing data without reloading.
(ignoring the fact that 6.4 will probably require this.)

/* 
   Matthew N. Dodd		| A memory retaining a love you had for life	
   winter@jurai.net		| As cruel as it seems nothing ever seems to
   http://www.jurai.net/~winter | go right - FLA M 3.1:53	
*/

Re: [HACKERS] cidr

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-07-21T15:01:10Z

> On Mon, 20 Jul 1998, Paul A Vixie wrote:
> > i don't see a need for a separate type for /32's; if someone enters just the
> > dotted quad (198.96.119.100 for example) the "/32" will be assumed.  i'd be
> > willing to see the "/32" stripped off in the output function since it's a bit
> > redundant -- i didn't do that but it's out of habit rather than strong belief.
> 
> I don't see a problem with having a separate type for /32's.  It doesn't
> hurt anything, and it takes up less room that a CIDR.  When you've got
> several million records this becomes an issue.  (Not from a perspective of
> space, but more data requires more time to muck through during queries.)

I would like one type, and we can specifiy a way of pulling out just
hosts or class addresses.

> 
> Plus, it would enable me to use my existing data without reloading.
> (ignoring the fact that 6.4 will probably require this.)

Yep.

-- 
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)