From owner-freebsd-net@FreeBSD.ORG Thu Aug 14 12:08:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F5EE49D; Thu, 14 Aug 2014 12:08:57 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 351032C8B; Thu, 14 Aug 2014 12:08:57 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 788B41534ED; Thu, 14 Aug 2014 14:08:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7WALQPu2SGS; Thu, 14 Aug 2014 14:08:24 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:cdb4:168:33e1:2262] (unknown [IPv6:2001:4cb8:3:1:cdb4:168:33e1:2262]) by smtp.digiware.nl (Postfix) with ESMTP id 9921C1534EC; Thu, 14 Aug 2014 14:08:24 +0200 (CEST) Message-ID: <53ECA6B2.8010003@digiware.nl> Date: Thu, 14 Aug 2014 14:08:18 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo , "Alexander V. Chernikov" Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw , "Andrey V. Elsukov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:08:57 -0000 On 2014-08-14 13:15, Luigi Rizzo wrote: > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < > melifaro@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@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@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? 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) ). Thanx for the nice work, --WjW