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

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

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.

> The all-zeros host address is available and value, but as you say, deprecated.

But not illegal, 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.

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.

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

So host only - no additional information carried in the type?

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

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

Radius server for Ascend terminal servers.

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