Re: [HACKERS] Re: inet/cidr/bind

I'm voting that the rest of the peanut gallary sit down and allow
PostgreSQL to adopt Vixie's world vision of the INET type.  If after the
release it is found to be lacking it can be addressed then.

Lets give the man some credit; he's got a better idea of what will be
useful than anyone else I've seen here.  Everyone else seems to be
stumbling around attempting to argue a point while trying to figure out
what the heck they're arguing about.  If you don't understand what Paul is
trying to do, then sit down, read a few books and come back when you do.

This whole issue is really heading towards a stalemate otherwise.

As usual, feel free to ignore me.

Paul, thanks for taking the time to educate everyone here.  Your patience
is appriciated and I only hope that the features you need will pan out in
the release.

On Mon, 19 Oct 1998, Paul A Vixie wrote:

> > > no.  the last three inputs are not valid where a host address is expected.
> > 
> > Can you amplify?  Is it correct as far as cidr goes?  If so, I have no
> > problem making it an error for the inet type.  My thinking was based
> > on the earlier concept of having one type and accepting networks in it.
> > If we have the separate cidr type then I guess inet should always require
> > 4 octets (until ipv6 anyway) and cidr should be used for networks.
> 
> Networks do not have to have all four octets specified, only enough octets
> to cover the prefix length that's given.  Networks should have default
> netmasks based on classful assumptions.  Networks never have any bits beyond
> their prefix length, which is why the question of "nonzero host part" does
> not even really arise.  There is no "host part" in a network.  And in my
> concept of them, they are variably sized.
> 
> > How about something like 192.63.0.0/16?  Should that be an error under the
> > inet type since it is the network?  I am thinking not since technically
> > 192.63.0.0 is a valid host under 192.63/16 although it is generally
> > avoided since there is still software that assumes that it is the
> > network or even the broadcast.
> 
> The all-zeros host address is available and value, but as you say, deprecated.
> 
> > > so shall i test the inet_cidr_ functions and punt them on in?
> > 
> > Ok, before I have a reality shift, the inet_cidr_ functions are simply
> > the original inet_net_ functions renamed, right?
> 
> No.  The inet_net_ functions describe CIDRized networks.  The inet_cidr_
> functions, which I've written but not yet committed to BIND 8.next, are
> new.  I am absolutely loathe to submit them at this point, since the act
> of bridging host addresses and their prefix lengths makes no sense to me.
> 
> Here's a cisco showing a CIDR block (mine, as it turns out):
> 
>     palo-alto>sho ip rou 204.152.184.0
>     Routing entry for 204.152.184.0/21, supernet
>       Known via "bgp 1280", distance 20, metric 0
>       Tag 3557, type external
>       Last update from 198.32.176.3 2w0d ago
>       Routing Descriptor Blocks:
>       * 198.32.176.3, from 198.32.176.3, 2w0d ago
>           Route metric is 0, traffic share count is 1
>           AS Hops 1
> 
> Here's a BSD/OS box showing a bunch of CIDR blocks (inside my network):
> 
>     # netstat -rn
>     Destination         Gateway            Flags    Refs      Use Interface
>     default             204.152.184.4      UG          0 103154609  de1
>     127                 127.0.0.1          UR          0        0  lo0
>     127.0.0.1           127.0.0.1          UH          0    59294  lo0
>     192.5.5.1           204.152.184.19     UGH         0  1160628  de0
>     192.5.5.2           204.152.184.19     UGH         0   507879  de0
>     192.5.5.88/29       204.152.184.19     UG          0        4  de0
>     192.5.5.96/27       204.152.184.19     UG          0    35150  de0
>     192.5.5.124/30      204.152.184.19     UG          0    12361  de0
>     192.5.5.241         204.152.184.4      UGH         0    55164  de1
>     198.32.176          204.152.184.1      UG          0    15250  de1
>     198.32.176.6        204.152.184.1      UGHc        0       76  de1
>     204.152.184/28      link#2             UC          0        0  de1
>     204.152.184.1       0:c0:95:e0:1e:1c   UHLc        4      493  de1
>     204.152.184.3       0:c0:95:e0:2e:8c   UHLc        0        1  lo0
>     204.152.184.4       0:c0:95:e0:1e:24   UHLc        4     7125  de1
>     204.152.184.5       0:c0:95:e0:26:80   UHLc        1        0  de1
>     204.152.184.16/29   link#1             UC          0        0  de0
>     ^C
> 
> The things which are "hosts" have four octets, are of fixed length, and do not
> have netmasks.  The things which are "networks" have some other number of
> octets, are variably sized, and do have netmasks (actually, prefix lengths).
> 
> At the risk of reopening a discussion which ought to have been closed a long
> while back, I suggest that polymorphism is bad and that an INET type which is
> built out of BIND's inet_net_ functions is perfectly capable of holding a
> host address (since /32 is the default if all four octets are specified),
> and that we run absolutely zero risk if we call the type INET, add indexing
> linkages for it, and get outta town.
> 
> There is an argument for a sugartype called IHOST which generates a /32 INET
> but uses inet_pton() and inet_ntop() for parsing/printing so as to avoid the
> "/%d" that nobody needs to see and also to ensure that only fully formed host
> addresses can be input.
> 
> There is an argument for another, completely separate type, called MACADDR,
> which is an IEEE 48-bit address (suitable for ethernet or fddi arp tables).
> 
> There is no argument I know of for a type which combines the host address and
> the netmask of its interface.  I've got applications in mind for each of the
> above three types -- has anybody got a specific application they want to build
> which requires a CIDR-like host address which is of fixed size, has the
> ability to preserve the "unset"-ness of the prefix length from input through
> storage to output, and also has the ability to preserve a particular prefix
> length from input through storage to output?
> 
> I'll use INET in a registry database like IANA's or InterNIC's.
> 
> I'll use INET, IHOST and MACADDR in a distributed DHCP database.
> 
> What would anybody use a mixture of INET and IHOST for, that they could not
> do just as easily with a pair of IHOST's?
> 
> Forget the number theory for a moment and let's talk about applications which
> are uniquely enabled by any new type we consider.  Once that's done, we can
> talk about avoiding unfortunate overlaps.
> 
> I've got the code done for supporting hosts-with-prefixes, but I don't like it
> and I would not use it in any PgSQL application I can imagine.  Help?
> 

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |