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

> > 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.0Routing entry for 204.152.184.0/21, supernet  Known via "bgp 1280", distance 20,
metric0  Tag 3557, type external  Last update from 198.32.176.3 2w0d ago  Routing Descriptor Blocks:  * 198.32.176.3,
from198.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 -rnDestination         Gateway            Flags    Refs      Use Interfacedefault             204.152.184.4
  UG          0 103154609  de1127                 127.0.0.1          UR          0        0  lo0127.0.0.1
127.0.0.1         UH          0    59294  lo0192.5.5.1           204.152.184.19     UGH         0  1160628
de0192.5.5.2          204.152.184.19     UGH         0   507879  de0192.5.5.88/29       204.152.184.19     UG
0       4  de0192.5.5.96/27       204.152.184.19     UG          0    35150  de0192.5.5.124/30      204.152.184.19
UG         0    12361  de0192.5.5.241         204.152.184.4      UGH         0    55164  de1198.32.176
204.152.184.1     UG          0    15250  de1198.32.176.6        204.152.184.1      UGHc        0       76
de1204.152.184/28     link#2             UC          0        0  de1204.152.184.1       0:c0:95:e0:1e:1c   UHLc
4     493  de1204.152.184.3       0:c0:95:e0:2e:8c   UHLc        0        1  lo0204.152.184.4       0:c0:95:e0:1e:24
UHLc       4     7125  de1204.152.184.5       0:c0:95:e0:26:80   UHLc        1        0  de1204.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?