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

Thus spake Paul A Vixie
> > 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 IHOST as I proposed it, it would have the same on-disk format as INET,
> but with a fixed /32 and with different parsing and printing functions:
> the parser would object unless all four octets and no /## was specified,
> and the printer would just print the octets and elide the /32.  There are
> functions in BIND, i.e., inet_pton() and inet_ntop(), which do that kind
> of parsing and printing.
> 
> > In fact, forget the -1 idea.  Default both types to /32 and never print
> > the bits for the CHOST type.  That simplifies the calculations.
> 
> If we're never printing the bits for CHOST, it's not different from IHOST?

I meant default to /32 if it isn't specified.  If it is then use what is
specified and print it if it isn't 32.  So:

Input               Stored as           Output as
=========           =========           =========
198.96.119.226/28   198.96.119.226/28   198.96.119.226/28
198.96.119.226/32   198.96.119.226/32   198.96.119.226
198.96.119.226      198.96.119.226/32   198.96.119.226

The middle one is the hairy one.  Using -1 for unspecified let's us
output /32 if that was what was input.  If we can live with not
printing /32 ever then we can simplify the handling.

> > > 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.
> 
> "Messy" is not as strong a concern as performance, though, is it?  If the
> only time we need a host address and a netmask together is when a Radius
> server using an SQL backend had to do some string arithmetic before sending
> the Radius reply, then that's not as compelling an argument as it might be.

Actually, what is stored in the database (using CHOST) is exactly what
the terminal server needs - no calculations.  To be complete I would
need to use the following to store everything I need without CHOST.

network::inet
gateway::ihost
masklen::integer

Now I guess I could get the masklen from the network but even then it
isn't straightforward since I would have to do string operations on
it to extract the bits after the slash.  Either way it now becomes
possible for the two to get out of sync so now I have to also check
the network and gateway to make sure that the latter is within the
former every time I use it.

With CHOST I just select the field and pass it to the Radius function
that called me.

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