On 17.05.2014 23:57, Barney Wolff wrote:
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
I haven't said anything about splitting IPv4 and IPv6 tables.
internals as long as the existing public API continues to work.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"