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

> I think we (at least I) are still confused about what the types are. I
> see two types on the table;
>
> a) A type to hold networks only
> b) A type to hold hosts with optional netmasks
>
> Can we agree that these are the two types we are discussing? If so can we
> agree on which is which? I have been assuming that A was cidr and B was
> inet but perhaps I have it backwards.

I am challenging the (b) type above. I see three types:

INET holds CIDRized networks
IHOST holds host end-addresses
MACADDR holes IEEE 48-bit ether/fddi addresses

As to whether the type names are backwards, probably not. It's only if we
postulate type (b) above that an ambiguity arises as to whether the type we
were calling CIDR refers to hosts+netmasks or to CIDRized networks.

Certainly the new inet_cidr_ functions were written for the former while the
existing inet_net_ functions were written for the latter.

> > The all-zeros host address is available ..., but as you say, deprecated.
>
> But not illegal, right?

Nope, just unusable on Suns.

> > 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.
>
> OK, so it looks like I had it backwards all along. So we can just put the
> inet.c function back in exactly as it was then? If we agree on this then
> we are half way there and at least we have something for 6.4 right now.

Agreed.

> > 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.
>
> So host only - no additional information carried in the type?

That would be my preference. But as it would be the same underlying type,
it would be possible to ask for all supernet INETs of some IHOST -- the
supernet/subnet comparison functions would be inherently polymorphic. I've
already got an application in mind that would benefit from this polymorphism.

> > 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).
>
> Nothing to do with our current discussion, right? You are just mentioning
> it for completeness and we shall never speak of it again, or at least not
> till after 6.4?

I'd thought that the fellow who wrote ip_and_mac had already submitted the
MACADDR type. If not, then clearly it is way too late to consider it for 6.4.

> > ... -- 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?
>
> Radius server for Ascend terminal servers.

Is there no way to accomplish this without efficiency loss using a pair of
IHOSTs, one for the host address and one for the netmask?

I note that polymorphism of the supernet/subnet tests between (a) and (b) as
denoted in the top of the text I've quoted in this message is a lot more work
than the inherent polymorphism of supernet/subnet tests between an INET and
an IHOST as I've proposed them here.