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

Thus spake Paul A Vixie
> > 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

So that's the type a above.

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

Originally I thought we were calling 'a' the cidr type and 'b' the inet
type hence my confusion. I still think that that is the better but since
we have working code and it is already named, I guess we should go with it.

For convenience, let's call my 'b' type above a CHOST type for CIDRized
host. So hopefully we all have the types straight.

INET holds CIDRized networks
IHOST holds host end-addresses
CHOST host plus netmask.

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

So it is designed for CHOST then? Well, you know my opinion.

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

<TANGENT>Right. I wonder if we should consider making this a compile-time
option or something post-6.4.</TANGENT>

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

So unless someone is violently opposed then Bruce, can you put it back to
the way it was before I submitted my patch to inet.c? That gives us the
INET type as defined above.

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

You think it should be a differnt type then? You can do it with one if
you use /32 for hosts, right? In fact, make a naked ip imply /32 for
INET type but /-1 for CHOST type (if we go with it.)

In fact, forget the -1 idea. Default both types to /32 and never print
the bits for the CHOST type. That simplifies the calculations.

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

Actually, I don't even know if that is in or not. In any case, it either
is or isn't. We don't need to dwell on it. (So why am I? :-) )

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

It becomes messy. In fact, I would use an integer for the netmask in that
situation.

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

That's why I'm saying get rid of the -1 hack that I originally proposed.

So, INET is in. The question is what to do with IHOST and CHOST. I
think CHOST should go in. You can use it for IHOST too.

I'm going to talk to Bruce in IRC now. I have another idea for making
one type for all 3 but I'm not sure of some details of the type system.

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.