Problem with ipfw table add 0.0.0.0/8

[Barney Wolff]

On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote:
> On 13.05.2014 16:05, Dennis Yusupoff wrote:
> > I think that universal table for all kind of data (ipv4, ipv6, ports,
> > etc) is a bad idea by design. At least unless you haven't any ability to
> It is not always "universal" in kernel.
> Actually, different radix tables are used to store both IPv4 and IPv6 in 
> single table.
> > specify address family on add, to avoid attempts to guess what user
> > meant. Something like "ipfw table X add DEEF.DE ipv6".
> I'm going to add explicit table type/naming setup soon.
> Idea is the following:
> 
> 1) Existing table can be named and addressed by either number or name.
> However, you still need to assign table number manually.
> 
> 2) Table type/name can be specified explicitly via one of the following 
> commands:
> * ipfw table 1 create [type <cidr|u32|ifindex|iface>] [name "table_name"]
> * ipfw table <num|name> name "table_name"
> * ipfw table "table_name" type <cidr|u32|ifindex|iface>
> 
> 3) ipfw(8) stops trying to guess appropriate type based on used value. 
> Instead,
> it requests table type from kernel and interprets value according to 
> returned type.
> Default type for all tables is cidr
> 
> 4) Table(s) can be returned to default values using ipfw table 
> <num|all|name> destroy.
> Destroy means:
> * flush
> * table tries (or other structures) freed
> * type set to cidr

Please avoid violating POLA.  I for one have scripts that automatically add
entries and would need to be modified if separate ipfw tables become required
for ipv4 and ipv6.  I'd have no problem, of course, with changes to ipfw
internals as long as the existing public API continues to work.