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