[CFT] new tables for ipfw

[Alexander V. Chernikov]

On 14.08.2014 16:08, Willem Jan Withagen wrote:
> On 2014-08-14 13:15, Luigi Rizzo wrote:
>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov <
>> melifaro at yandex-team.ru> wrote:
>>
>>>   On 14.08.2014 14:44, Luigi Rizzo wrote:
>>>
>>>
>>>
>>>
>>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov <
>>> melifaro at yandex-team.ru> wrote:
>>>
>>>>    On 14.08.2014 13:23, Luigi Rizzo wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov <
>>>> melifaro at yandex-team.ru> wrote:
>>>>
>>>>> Hello list.
>>>>>
>>>>> I've been hacking ipfw for a while and It seems there is something 
>>>>> ready
>>>>> to test/review in projects/ipfw branch.
>>>>>
>>>>
>>>>   ​this is a fantastic piece of work, thanks for doing it and for
>>>> integrating the feedback.
>>>>   ​
>>>> I have some detailed feedback that will send you privately,
>>>>   but just a curiosity:
>>>>
>>>>    ​...​
>>>>>
>>>>> Some examples (see ipfw(8) manual page for the description):
>>>>>
>>>>>
>>>>> ​...
>>>>>
>>>>>
>>>>>    ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64"
>>>>>
>>>>
>>>>   ​why do we need to specify mask lengths in the above​ ?
>>>>
>>>>   Well, since we're hashing IP we have to know mask to cut host 
>>>> bits in
>>>> advance.
>>>> (And the real reason is that I'm too lazy to implement hierarchical
>>>> matching (check /32, then /31, then /30) like how, for example,
>>>>
>>>
>>>   ​oh well for that we should use cidr:radix
>>>
>>>   Research results have never shown a strong superiority of
>>> hierarchical hash tables over good radix implementations,
>>>   and in those cases one usually adopts partial prefix
>>> expansion so you only have, say, masks that are a
>>>   multiple of 2..8 bits so you only need a small number of
>>> hash lookups.
>>>
>>> Definitely, especially for IPv6. So I was actually thinking about 
>>> covering
>>> some special sparse cases (e.g. someone having a bunch of /32 and a 
>>> bunch
>>> of /30 and that's all).
>>>
>>> Btw, since we're talking about "good radix implementation": what 
>>> license
>>> does DXR have? :)
>>> Is it OK to merge it as another cidr implementation?
>>>
>>
>> "cidr" is a very ugly name, i'd rather use "addr"
>>
>> DXR has a ​bsd license and of course it is possible to use it.
>> You should ask Marko Zec for his latest version of the code
>> (and probably make sure we have one copy of the code in the source 
>> tree).
>>
>> Speaking of features, one thing that would be nice is the ability
>> for tables to reference the in-kernel tables (e.g. fibs, socket
>> lists, interface lists...), perhaps in readonly mode.
>> How complex do you think that would be ?
>
> I'm a very happy user of ipfw and I think these are nice improvements 
> and will make things more flexible...
>
> I have 2 nits to pick with the current version.
>
> I've found the notation ipnr:something rather frustrating when using 
> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the 
> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s.
> compare
>     2001:4cb8:3:1::1
>     2001:4cb8:3:1::1:80
>     [2001:4cb8:3:1::1]:80
> The first and the last are the same host but a different port, the 
> middle one is just a different host.
>
> Could/should we do the same in ipfw?
Well, we should, but I'm unsure if we have host:port notation anywhere 
in current (or new) syntax:
>
> And I keep running into the
>     ipfw add deny all from table(50) to any
> notation. the ()'s need to be escaped in most any shell. Where as I 
> look at the syntax there is little reason to require the ()'s.
> the keyword table always needs to be followed by a number (and in the 
> new version a (word|number) ).
We need _some_ discriminator to ensure that the next parameter after 
"to" or "from" is not hostname.
We also have some other places where tables are used: "via 
interface|table(X)", lookup X, flow table(X) [new].
I agree that parenthesis might not be the best choice. (and something 
like :tablename:, %tablename%, or even table:tablename might look better).
Theoretically, we can support both (old/new) and show rules with new one 
by default.

>
> Thanx for the nice work,
> --WjW
>