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.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?