From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 13 20:15:17 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34843C81; Wed, 13 Aug 2014 20:15:17 +0000 (UTC) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [IPv6:2a02:6b8:0:801::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D496828CC; Wed, 13 Aug 2014 20:15:16 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id B78BA242003E; Thu, 14 Aug 2014 00:15:13 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 842892C0466; Thu, 14 Aug 2014 00:15:13 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id D5oUBPMVhc-FDI8IIgA; Thu, 14 Aug 2014 00:15:13 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: bec30993-e604-4ed7-b5f9-0b49c088db7c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1407960913; bh=e7LzCQGxvt/6/+XjalQzxu+zIdQQ8+xm1C0tENFEx84=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=x4qYgWvKxHN9sguEIgji/qUq1X7+qfZQXsgqMHAc95Gb83WHRYW3pt2pf4hf+gy7q +HddDu2vV3EG7Upwz2DYF9W8vaxQLa+sMvl0yLJezI72Cd+AY8Z0jo6RMUJM59zdHL CREt6TzhbytGOLKd8dYBLw0ggvas8HClDx/pk9lM= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53EBC750.1050203@yandex-team.ru> Date: Thu, 14 Aug 2014 00:15:12 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-ipfw , Luigi Rizzo Subject: [CFT] new tables for ipfw Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:15:17 -0000 Hello list. (sorry for posting twice, patch seems to be too big to be posted as attachment). I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. Main user-visible changes are related to tables: 1) Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names (*1). 2) Tables are now set-aware (default off), so you can switch/move them atomically with rules. 3) More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. 4) New table types are added (flow) so you can match multiple packet fields at once. 5) Ability to add different type of lookup algorithms for particular table type has been added. 5) New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. 6) No ABI breakage has happened: all functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC. Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 added: 1.1.1.1/32 1111 added: 2.2.2.2/32 2222 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 4444 ipfw: Adding record failed: record already exists ^^^^^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 1111 2.2.2.2/32 2222 4.4.4.4/32 4444 # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 5555 added(reverted): 3.3.3.3/32 3333 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 5555 ipfw: Adding record failed: record already exists ^^^^^ Returns error and reverts added records IPFW internals has also changed significantly, mostly userland-interaction part. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so 1) All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. 2) The remaining opcodes (except NAT handlers) were also converted to be able to eliminate all older opcodes at once 3) All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods 4) struct ip_fw is now different for kernel and userland 5) tablearg value has been changed to 0 to ease future extensions 6) Batched add/delete has been added to tables code 7) Batched rule addition is coming soon (most of the changes has been already done) 8) interface tracking API has been added (started on demand) to permit effective interface tables operations 9) O(1) skipto cache (*2), currently turned on by default (eats 512K). This has to be made optional 10) Rule counters were separated from rule itself and made per-cpu. However, this part is not finished yet (problems with timestamps/api) 11) Make radix entries fit into 128 bytes 12) Make struct ip_fw more compact so more rules will fit into 64 bytes 13) Make interface tables use array of existing ifindexes for faster match 14) Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces. * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer. 15) Probably some more less significant/forgotten features This is not final version: probably more documentation/style is required, there are definitely some uncaught bugs, and so on. However, test/feedback/review is welcome. All these changes are available in projects/ipfw branch (synced to recent -HEAD), but may be easily applied to recent 9/10 (at least kernel part). Branch: svn://svn.freebsd.org/base/projects/ipfw Web: http://svnweb.freebsd.org/base/projects/ipfw/ Today's patch to -HEAD is available at http://static.ipfw.ru/patches/ipfw_tables3.diff From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 09:23:30 2014 Return-Path: Delivered-To: freebsd-ipfw@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 D2A71183; Thu, 14 Aug 2014 09:23:30 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C88602A3C; Thu, 14 Aug 2014 09:23:29 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id mc6so759024lab.20 for ; Thu, 14 Aug 2014 02:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qLnNumXXyFcABLj2bZlBea8o9c4ElCwxyy/4vTWdB0Q=; b=BG8DsbvqisjzDD5/wd8zyEMJFi4x4EsVInMArCg6FQAYk/yQtqwJgipJkqCt/82SZo vVBmZz3JwZUwtXrdbj0hOElwDuV46I5IFtd6nNJwBHXHXNzNQMeqa1qoyKxiFOMgdzfZ aLcefMQ/NvMMQBtKOuKKPF5+YP2pXezvU3PsPkrgE9tfT3RTbTYp9KZckqiK37fdXYLA D9E8z6ojL13NTGf67iTfVZlvKgkDzxffCtgJjRJVxTPERBjYwjPtx1SLCYS20yV4wyzb M8U7Kos4jYBeZwMhA58DfQpuqHnsRUdWiXPvCPH1LszgR5mC5lF1DgCNLX/Hh56e1O5N RYTQ== MIME-Version: 1.0 X-Received: by 10.112.34.8 with SMTP id v8mr3417820lbi.47.1408008207733; Thu, 14 Aug 2014 02:23:27 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Thu, 14 Aug 2014 02:23:27 -0700 (PDT) In-Reply-To: <53EBC687.9050503@yandex-team.ru> References: <53EBC687.9050503@yandex-team.ru> Date: Thu, 14 Aug 2014 11:23:27 +0200 X-Google-Sender-Auth: ecJUl9nK6T04x2mzyb5kx4-yzI8 Message-ID: Subject: Re: [CFT] new tables for ipfw From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 09:23:30 -0000 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. > =E2=80=8Bthis is a fantastic piece of work, thanks for doing it and for integrating the feedback. =E2=80=8B I have some detailed feedback that will send you privately, but just a curiosity: =E2=80=8B...=E2=80=8B > > Some examples (see ipfw(8) manual page for the description): > > > =E2=80=8B... > > > ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" > =E2=80=8Bwhy do we need to specify mask lengths in the above=E2=80=8B ? cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 09:57:38 2014 Return-Path: Delivered-To: freebsd-ipfw@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 3EB03977; Thu, 14 Aug 2014 09:57:38 +0000 (UTC) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [IPv6:2a02:6b8:0:801::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5EC42E61; Thu, 14 Aug 2014 09:57:37 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id 391062420040; Thu, 14 Aug 2014 13:57:34 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 07E3A2C05E8; Thu, 14 Aug 2014 13:57:34 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id QrJ3r13hHk-vYIinBAU; Thu, 14 Aug 2014 13:57:34 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: af1fc88a-0435-4944-bb04-1597ac39686e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408010254; bh=JY9TNqE3DCEys9ey1ITFb8tzgD32DcqPEv6CaI0BciQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=BbBtOxPA9Uv/vKjaVpBOzkigMICGbOACc+Bf+h9ehYDfuwTKahGi/f1I3OOFkDKk6 83Ho0QLt4+sDQVx+XTF1aW58/916IdnSdlSwslCnFD4xyQf9XrfKiZig32UOTnAO6K P5KrtyePryxp49yAUBtSMzuOZp/6Ve38cDnKFyPE= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53EC880B.3020903@yandex-team.ru> Date: Thu, 14 Aug 2014 13:57:31 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 09:57:38 -0000 On 14.08.2014 13:23, Luigi Rizzo wrote: > > > > On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov > > 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, this is done in ipset), so this particular algorithm supports only single IPv4 and single IPv6 mask. Anyway, it is not too hard to add another algo which is doing the above. > > cheers > luigi > From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 10:44:25 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9244E10C; Thu, 14 Aug 2014 10:44:25 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 767372452; Thu, 14 Aug 2014 10:44:24 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so830781lbd.36 for ; Thu, 14 Aug 2014 03:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9Emzx579XucHI7hUvpY/DO6lq6rtCJOQWVx1mxAHX64=; b=uRLkuqXFU0MCzpuCZ8sP5jyLMAM3tkS7LziIiuveoncQBv530ugxYXQPgkGXWzHgvi 8q6N08Q4ay4Poj2Neofn9fWXFEwBBKguTvzz+CPJW/YgKn3Q9GC54X9D6PMh/aYJQJju vySml/18qWKEIOqLf7SzMc5QXoNEkRVIbVMRElcexYMwMn1twyhkB50ODCNZyw601OPy I23F51M7/BJXKjh1SVqLQhCqN8oUTwCP8gvoHluc6Q1Poc2SJahMPSRWi/lwL+z6sZK/ ES8SwarTXQc5XPKAhurDkvicQSpcC1AenUKbbgOJ6gxDjNmPlTgeVOWYtufM6NEc8eBt rplA== MIME-Version: 1.0 X-Received: by 10.112.22.37 with SMTP id a5mr3942315lbf.76.1408013062224; Thu, 14 Aug 2014 03:44:22 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Thu, 14 Aug 2014 03:44:22 -0700 (PDT) In-Reply-To: <53EC880B.3020903@yandex-team.ru> References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> Date: Thu, 14 Aug 2014 12:44:22 +0200 X-Google-Sender-Auth: nW20OSYRnenml96i0Nu5cYilVFA Message-ID: Subject: Re: [CFT] new tables for ipfw From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 10:44:25 -0000 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. >> > > =E2=80=8Bthis is a fantastic piece of work, thanks for doing it and for > integrating the feedback. > =E2=80=8B > I have some detailed feedback that will send you privately, > but just a curiosity: > > =E2=80=8B...=E2=80=8B >> >> Some examples (see ipfw(8) manual page for the description): >> >> >> =E2=80=8B... >> >> >> ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" >> > > =E2=80=8Bwhy do we need to specify mask lengths in the above=E2=80=8B ? > > 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, > =E2=80=8Boh 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. =E2=80=8Bcheers luigi=E2=80=8B From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 10:57:31 2014 Return-Path: Delivered-To: freebsd-ipfw@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 7DE113A0; Thu, 14 Aug 2014 10:57:31 +0000 (UTC) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2691E255B; Thu, 14 Aug 2014 10:57:31 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id C7DA264057F; Thu, 14 Aug 2014 14:57:17 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 91D3F2C05E8; Thu, 14 Aug 2014 14:57:17 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id GSBR0eaIlo-vHIuD88D; Thu, 14 Aug 2014 14:57:17 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 91582161-a429-4f64-ac2f-2c09a2800245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408013837; bh=C+koB9qYLL8VFaE+z35vJXaKL3HUkLAZlQGsbLzMFeY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=wOSECESQV0uOrFbR6net5+GTv26/yo/kmk5NanHYbdGlfYNmE/TyUl1GIegPKdK7X dkGansgFFMiCcC/FKckFhOHHskeprosAp3NSwvYlizJ4oWTbxdnWRgupTZy6fP6r7M Hv/iJy7CfdoSPQqm7SZed1y92p9PRud5/H8p/rSA= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53EC960A.1030603@yandex-team.ru> Date: Thu, 14 Aug 2014 14:57:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 10:57:31 -0000 On 14.08.2014 14:44, Luigi Rizzo wrote: > > > > On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov > > wrote: > > On 14.08.2014 13:23, Luigi Rizzo wrote: >> >> >> >> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov >> > 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? > > ​cheers > luigi​ > From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 11:15:44 2014 Return-Path: Delivered-To: freebsd-ipfw@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 A4A247A7; Thu, 14 Aug 2014 11:15:44 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5922736; Thu, 14 Aug 2014 11:15:43 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id ty20so867206lab.18 for ; Thu, 14 Aug 2014 04:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5vQ9XaXkb2TRo8Op0LYVTotfjensTxi6TzsIoWM0Q/0=; b=ifr45WBFl4WJRP3yxwrr+FzzLwHKA/m1RhAgWgdJI0orulB5yVMJmVWpBCGoFC6tEX 4nqTQHGGnAaJ1NNFAJmzRvwearJqITADKCMYdlagnqdWFEXhjLPlURP1qwRX3dZWm688 2VH+KsFvA/XFSfOsXuxnUgyEJfX99ezdZHZH1fCz08ZsUggBFL6JotRUDvHGyvpRln/7 4K10JuvOXEy6EzwBtj1wk3ck/giZSPOg8GeuBPQ5CmCT6PflNpi6nPVxBCPzSnvmaYFW y52dyq0SereKQ36wXscYfMFNB5h4CGZZlrZ1txTB/RmT2T6mihv2Ar29EeRKZB6rNK6Y xAtA== MIME-Version: 1.0 X-Received: by 10.112.56.206 with SMTP id c14mr2605618lbq.27.1408014941450; Thu, 14 Aug 2014 04:15:41 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Thu, 14 Aug 2014 04:15:41 -0700 (PDT) In-Reply-To: <53EC960A.1030603@yandex-team.ru> References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> Date: Thu, 14 Aug 2014 13:15:41 +0200 X-Google-Sender-Auth: 0dMTaJr-5B2dBosDFQ5DsvybrVU Message-ID: Subject: Re: [CFT] new tables for ipfw From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 11:15:44 -0000 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 read= y >>> to test/review in projects/ipfw branch. >>> >> >> =E2=80=8Bthis is a fantastic piece of work, thanks for doing it and for >> integrating the feedback. >> =E2=80=8B >> I have some detailed feedback that will send you privately, >> but just a curiosity: >> >> =E2=80=8B...=E2=80=8B >>> >>> Some examples (see ipfw(8) manual page for the description): >>> >>> >>> =E2=80=8B... >>> >>> >>> ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" >>> >> >> =E2=80=8Bwhy do we need to specify mask lengths in the above=E2=80=8B ? >> >> 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, >> > > =E2=80=8Boh 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 coverin= g > 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 =E2=80=8Bbsd 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 ? cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 11:52:41 2014 Return-Path: Delivered-To: freebsd-ipfw@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 403EDF25; Thu, 14 Aug 2014 11:52:41 +0000 (UTC) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C98E32ABF; Thu, 14 Aug 2014 11:52:40 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id BF81064057F; Thu, 14 Aug 2014 15:52:37 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 8453D2C05F8; Thu, 14 Aug 2014 15:52:37 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id hicEnCyaNo-qbI8Ml1r; Thu, 14 Aug 2014 15:52:37 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: e7c1dd03-f5f2-4e3f-8ed2-29970b6f0154 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408017157; bh=6AcoeR2+4Di8V0QUtEsMUTVKHMoqYXLh+iK3vgGdRwY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=pwplYCuiuO/PpnZmmpOh6xwU/gvfBqAZdlde+T/GVS1flCmZRvBvO2T+wGUo8bWDo +9i+7tz9nDTB7WvCb3BTKDaQL6TxyznP5DjTKhEvlrd6zCLlJ7n4BnZoqopXg0t1e2 6Id52j3PPPryDRNOJFkX4tmtXtfZdQJh6sdSLiXk= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53ECA302.8010100@yandex-team.ru> Date: Thu, 14 Aug 2014 15:52:34 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo 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 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 11:52:41 -0000 On 14.08.2014 15:15, Luigi Rizzo wrote: > > > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov > > wrote: > > On 14.08.2014 14:44, Luigi Rizzo wrote: >> >> >> >> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov >> > wrote: >> >> On 14.08.2014 13:23, Luigi Rizzo wrote: >>> >>> >>> >>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov >>> > >>> 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" Ok, no problem with that. "addr" really sounds better. > > 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). Great!. I'll ask him :) > > 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 ? Implementing algo support for particular provider like sockets/iflists shouldn't be hard. Most of the algorithms complexity lies in table modifications. Here we have to support lookup and dump operations, so it is the question of providing necessary bindings to existing mechanisms (via some direct binding or utilizing things like kernel_sysctl for dump support). It looks like the following maps well to current table concept: * such tables are not created by default * user issues `ipfw table kfib create type addr algo "addr:kernel fib=0"` or `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` or `ipfw table kiface create type iface algo "iface:kernel"` * tables have special "readonly" type, flush_all requests are ignored * no state stored internally So generic table handling code needs to be modified to support read-only tables (and making more callbacks optional). Additionally, we might need to proxy "info" request info algo callback (optional, "real" algorithms won't implement it) to be able to show number of items (and some other info) to user. > > cheers > luigi > From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 12:08:57 2014 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions 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 From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 12:08:57 2014 Return-Path: Delivered-To: freebsd-ipfw@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 C38AE4A0; Thu, 14 Aug 2014 12:08:57 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 274362C8A; Thu, 14 Aug 2014 12:08:56 +0000 (UTC) Received: from x23 (31.147.112.155) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 14 Aug 2014 14:07:44 +0200 Date: Thu, 14 Aug 2014 14:08:18 +0200 From: Marko Zec To: "Alexander V. Chernikov" Subject: Re: [CFT] new tables for ipfw Message-ID: <20140814140818.3539d9c5@x23> In-Reply-To: <53ECA302.8010100@yandex-team.ru> References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> Organization: FER X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [31.147.112.155] Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:08:57 -0000 On Thu, 14 Aug 2014 15:52:34 +0400 "Alexander V. Chernikov" wrote: > On 14.08.2014 15:15, Luigi Rizzo wrote: > > > > > > > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov=20 > > > wrote: > > > > On 14.08.2014 14:44, Luigi Rizzo wrote: > >> > >> > >> > >> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov > >> > > >> wrote: > >> > >> On 14.08.2014 13:23, Luigi Rizzo wrote: > >>> > >>> > >>> > >>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov > >>> > > >>> 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. > >>> > >>> > >>> =E2=80=8Bthis is a fantastic piece of work, thanks for doing = it > >>> and for integrating the feedback. > >>> =E2=80=8B > >>> I have some detailed feedback that will send you > >>> privately, but just a curiosity: > >>> > >>> =E2=80=8B...=E2=80=8B > >>> > >>> Some examples (see ipfw(8) manual page for the > >>> description): > >>> > >>> =E2=80=8B... > >>> > >>> > >>> ipfw table mi_test create type cidr algo "cidr:hash > >>> masks=3D/30,/64" > >>> > >>> > >>> =E2=80=8Bwhy do we need to specify mask lengths in the above= =E2=80=8B ? > >> 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, > >> > >> > >> =E2=80=8Boh 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" > Ok, no problem with that. "addr" really sounds better. > > > > DXR has a =E2=80=8Bbsd 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). > Great!. I'll ask him :) The so far cleanest DXR implementation is significantly C++ poluted and wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) I'll try to backport the fixes to the original C-only / BSD implementation over the weekend and let you know how it goes... Marko > > > > 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 ? > Implementing algo support for particular provider like > sockets/iflists shouldn't be hard. Most of the algorithms complexity > lies in table modifications. Here we have to support > lookup and dump operations, so it is the question of providing > necessary bindings to existing mechanisms (via some direct binding or > utilizing things like kernel_sysctl for dump support). >=20 > It looks like the following maps well to current table concept: > * such tables are not created by default > * user issues > `ipfw table kfib create type addr algo "addr:kernel fib=3D0"` > or > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=3D0"` > or > `ipfw table kiface create type iface algo "iface:kernel"` > * tables have special "readonly" type, flush_all requests are ignored > * no state stored internally >=20 > So generic table handling code needs to be modified to support > read-only tables (and making more callbacks optional). > Additionally, we might need to proxy "info" request info algo > callback (optional, "real" algorithms won't implement it) to be able > to show number of items (and some other info) to user. >=20 >=20 >=20 > > > > cheers > > luigi > > >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 12:46:12 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 982711F1; Thu, 14 Aug 2014 12:46:12 +0000 (UTC) Received: from forward-corp1g.mail.yandex.net (forward-corp1g.mail.yandex.net [IPv6:2a02:6b8:0:1402::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CD4A2194; Thu, 14 Aug 2014 12:46:11 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1g.mail.yandex.net (Yandex) with ESMTP id F0FC7366005A; Thu, 14 Aug 2014 16:46:07 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id AF7062C05E8; Thu, 14 Aug 2014 16:46:07 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id iAsmop7sNc-k7IK310a; Thu, 14 Aug 2014 16:46:07 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 91582161-a429-4f64-ac2f-2c09a2800245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408020367; bh=gDd+ENkKuIiuie79a1gdzWuvzE7SKND9vNrKHd6ds7g=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Fu+fAS5TS9gkMrIFBGWgDDm0aZrIRDZWvTF5nnQH6fG8+3Ok/vpvwpIt00+wRAjhi KExt79k9Z64clx4h1hCi/W+yUbF8MmUqOIXzv1yuR2kkNPq1P5B+iM5Tl5SphHEtL0 Rw325ARHwOuhDyEGiDNO5BgD37o6+Otfi1m9FRuA= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53ECAF8C.2020007@yandex-team.ru> Date: Thu, 14 Aug 2014 16:46:04 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marko Zec Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> <20140814140818.3539d9c5@x23> In-Reply-To: <20140814140818.3539d9c5@x23> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:46:12 -0000 On 14.08.2014 16:08, Marko Zec wrote: > On Thu, 14 Aug 2014 15:52:34 +0400 > "Alexander V. Chernikov" wrote: > >> On 14.08.2014 15:15, Luigi Rizzo wrote: >>> >>> >>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov >>> > wrote: >>> >>> On 14.08.2014 14:44, Luigi Rizzo wrote: >>>> >>>> >>>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov >>>> > >>>> wrote: >>>> >>>> On 14.08.2014 13:23, Luigi Rizzo wrote: >>>>> >>>>> >>>>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov >>>>> > >>>>> 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" >> Ok, no problem with that. "addr" really sounds better. >>> 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). >> Great!. I'll ask him :) > The so far cleanest DXR implementation is significantly C++ poluted and > wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) > > I'll try to backport the fixes to the original C-only / BSD > implementation over the weekend and let you know how it goes... Great! I've got 2012 version half-ported (and radix fix has been merged to the tree), but something definitely has changed since then :) I'd be happy to hear from you :) > > Marko > > >>> 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 ? >> Implementing algo support for particular provider like >> sockets/iflists shouldn't be hard. Most of the algorithms complexity >> lies in table modifications. Here we have to support >> lookup and dump operations, so it is the question of providing >> necessary bindings to existing mechanisms (via some direct binding or >> utilizing things like kernel_sysctl for dump support). >> >> It looks like the following maps well to current table concept: >> * such tables are not created by default >> * user issues >> `ipfw table kfib create type addr algo "addr:kernel fib=0"` >> or >> `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` >> or >> `ipfw table kiface create type iface algo "iface:kernel"` >> * tables have special "readonly" type, flush_all requests are ignored >> * no state stored internally >> >> So generic table handling code needs to be modified to support >> read-only tables (and making more callbacks optional). >> Additionally, we might need to proxy "info" request info algo >> callback (optional, "real" algorithms won't implement it) to be able >> to show number of items (and some other info) to user. >> >> >> >>> cheers >>> luigi >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 12:48:04 2014 Return-Path: Delivered-To: freebsd-ipfw@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 4C9F03E6; Thu, 14 Aug 2014 12:48:04 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFCFE21BF; Thu, 14 Aug 2014 12:48:03 +0000 (UTC) Received: by mail-yk0-f173.google.com with SMTP id 131so898577ykp.32 for ; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ePQ9LG1QGGFI/AblEX+zFI8vzPgtWO4QCmJkHqbG+JE=; b=0waehPueWCO1MsNUqXE+mWKSMi/SZwett4cvJi7bnnz2BR59w5MMtvWE7bD3wvT3vp eM5sg0FEkX0d02FvJujb/qmO85wrCbGImCrqy/g/AQz79xvVN74oNSprPjL4IVXG2bXY R2340mUnpBU2+HAD+m6fYXgAVXffiJW4J72OO/Mw2/z8YT/h4720fhinT8bfeb7BfBnk 3ZVqHsWZmrl/y3mef5SMi5NqPOd6DhCvu9iWN97sms3Z/UfkAiX3RUlFMMhI/G0dUaND WCHlJoz4PElNkzKBN6JVt9isNSzzkHsi9eMne13jdFzOoKxmE7nrVgj5Ljw/0ITtDrZp JTlg== MIME-Version: 1.0 X-Received: by 10.236.104.133 with SMTP id i5mr17370383yhg.137.1408020483112; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) Received: by 10.170.218.197 with HTTP; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) In-Reply-To: <20140814140818.3539d9c5@x23> References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> <20140814140818.3539d9c5@x23> Date: Thu, 14 Aug 2014 05:48:03 -0700 Message-ID: Subject: Re: [CFT] new tables for ipfw From: Mehmet Erol Sanliturk To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:48:04 -0000 On Thu, Aug 14, 2014 at 5:08 AM, Marko Zec wrote: > On Thu, 14 Aug 2014 15:52:34 +0400 > "Alexander V. Chernikov" wrote: > > > On 14.08.2014 15:15, Luigi Rizzo wrote: > > > > > > > > > > > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov > > > > wrote: > > > > > > On 14.08.2014 14:44, Luigi Rizzo wrote: > > >> > > >> > > >> > > >> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov > > >> > > > >> wrote: > > >> > > >> On 14.08.2014 13:23, Luigi Rizzo wrote: > > >>> > > >>> > > >>> > > >>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov > > >>> > > > >>> 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. > > >>> > > >>> > > >>> =E2=80=8Bthis is a fantastic piece of work, thanks for doin= g it > > >>> and for integrating the feedback. > > >>> =E2=80=8B > > >>> I have some detailed feedback that will send you > > >>> privately, but just a curiosity: > > >>> > > >>> =E2=80=8B...=E2=80=8B > > >>> > > >>> Some examples (see ipfw(8) manual page for the > > >>> description): > > >>> > > >>> =E2=80=8B... > > >>> > > >>> > > >>> ipfw table mi_test create type cidr algo "cidr:hash > > >>> masks=3D/30,/64" > > >>> > > >>> > > >>> =E2=80=8Bwhy do we need to specify mask lengths in the abov= e=E2=80=8B ? > > >> 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, > > >> > > >> > > >> =E2=80=8Boh 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" > > Ok, no problem with that. "addr" really sounds better. > > > > > > DXR has a =E2=80=8Bbsd 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). > > Great!. I'll ask him :) > > The so far cleanest DXR implementation is significantly C++ poluted and > wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) > > I'll try to backport the fixes to the original C-only / BSD > implementation over the weekend and let you know how it goes... > > Marko > > > > > > > > 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 ? > > Implementing algo support for particular provider like > > sockets/iflists shouldn't be hard. Most of the algorithms complexity > > lies in table modifications. Here we have to support > > lookup and dump operations, so it is the question of providing > > necessary bindings to existing mechanisms (via some direct binding or > > utilizing things like kernel_sysctl for dump support). > > > > It looks like the following maps well to current table concept: > > * such tables are not created by default > > * user issues > > `ipfw table kfib create type addr algo "addr:kernel fib=3D0"` > > or > > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=3D0"` > > or > > `ipfw table kiface create type iface algo "iface:kernel"` > > * tables have special "readonly" type, flush_all requests are ignored > > * no state stored internally > > > > So generic table handling code needs to be modified to support > > read-only tables (and making more callbacks optional). > > Additionally, we might need to proxy "info" request info algo > > callback (optional, "real" algorithms won't implement it) to be able > > to show number of items (and some other info) to user. > > > > > > > > > > > > cheers > > > luigi > > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" The link is http://www.nxlab.fer.hr/dxr/ Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 13:05:12 2014 Return-Path: Delivered-To: freebsd-ipfw@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 BE29E740; Thu, 14 Aug 2014 13:05:12 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i47.relay.mailchannels.net [184.154.112.221]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC622471; Thu, 14 Aug 2014 13:05:06 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|lee@dilkie.com Received: from data.snhdns.com (ip-10-236-1-24.us-west-2.compute.internal [10.236.1.24]) by relay.mailchannels.net (Postfix) with ESMTPA id 2C393120101; Thu, 14 Aug 2014 12:46:48 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|lee@dilkie.com Received: from data.snhdns.com (data.snhdns.com [10.253.92.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.2.12); Thu, 14 Aug 2014 12:46:50 GMT X-MC-Relay: Good X-MailChannels-SenderId: totalchoicehosting|x-authuser|lee@dilkie.com X-MailChannels-Auth-Id: totalchoicehosting X-MC-Ingress-Time: 1408020410499 Received: from [142.46.160.218] (port=51123 helo=[192.168.51.11]) by data.snhdns.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHuQY-0002l2-9M; Thu, 14 Aug 2014 08:46:46 -0400 Message-ID: <53ECAFB9.50507@dilkie.com> Date: Thu, 14 Aug 2014 08:46:49 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Willem Jan Withagen , 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> <53ECA6B2.8010003@digiware.nl> In-Reply-To: <53ECA6B2.8010003@digiware.nl> X-AuthUser: lee@dilkie.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:05:12 -0000 On 8/14/2014 08:08, Willem Jan Withagen wrote: > 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? the first and second forms are valid, but as ipv6 addresses *with no port*, The third is an ipv6 address with a port. If the intent of the second form is an address and port, it will not be parsed that way by standard parsers and violates the ivp6 addressing rfc's. -lee From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 15:21:06 2014 Return-Path: Delivered-To: freebsd-ipfw@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 BCAD3BF5; Thu, 14 Aug 2014 15:21:06 +0000 (UTC) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [IPv6:2a02:6b8:0:801::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61C8F2456; Thu, 14 Aug 2014 15:21:06 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id 2B9442420040; Thu, 14 Aug 2014 19:21:02 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id EC9682C05E8; Thu, 14 Aug 2014 19:21:01 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id h8jc9gbi16-L1IW4HC6; Thu, 14 Aug 2014 19:21:01 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 91582161-a429-4f64-ac2f-2c09a2800245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408029661; bh=rpQSF12tsRSa8XZPJqei1gilw40bceJOWEK9tZiTCuw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IA6/h/D4rU/JS8Sh9YWCFvNuBcza79FpjUiIRq5P+AbuFDjTdBuxrlFahwKz8mYrm GdWEgMP6ueGODIggrLIYVtsIuf8Ou5tjdKHJcjAxzo8IJQvRjffEWAl3wx4a1b0chN nLS7XxDn8xbLZn15MOq/4mcv3MFH8s4V6lhBqInA= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53ECD3DA.6060501@yandex-team.ru> Date: Thu, 14 Aug 2014 19:20:58 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Willem Jan Withagen , Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA6B2.8010003@digiware.nl> In-Reply-To: <53ECA6B2.8010003@digiware.nl> 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-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:21:06 -0000 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@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? 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 > From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 15:28:05 2014 Return-Path: Delivered-To: freebsd-ipfw@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 30D9CF7F; Thu, 14 Aug 2014 15:28:05 +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 DDA872544; Thu, 14 Aug 2014 15:28:04 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 0888D153A8A; Thu, 14 Aug 2014 17:28:01 +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 kbaq5KYLrgTo; Thu, 14 Aug 2014 17:27:50 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 26961153A74; Thu, 14 Aug 2014 17:27:50 +0200 (CEST) Message-ID: <53ECD576.8040801@digiware.nl> Date: Thu, 14 Aug 2014 17:27:50 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lee Dilkie , 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> <53ECA6B2.8010003@digiware.nl> <53ECAFB9.50507@dilkie.com> In-Reply-To: <53ECAFB9.50507@dilkie.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:28:05 -0000 On 14-8-2014 14:46, Lee Dilkie wrote: > > On 8/14/2014 08:08, Willem Jan Withagen wrote: >> 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? > > the first and second forms are valid, but as ipv6 addresses *with no port*, > > The third is an ipv6 address with a port. > > If the intent of the second form is an address and port, it will not be > parsed that way by standard parsers and violates the ivp6 addressing rfc's. I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. So I think you rephrased what I meant to say. Thanx, --WjW From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 15:53:23 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F21DC8C4; Thu, 14 Aug 2014 15:53:22 +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 81F912828; Thu, 14 Aug 2014 15:53:22 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id CBA65153A51; Thu, 14 Aug 2014 17:53:19 +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 0HacgiO8Xawi; Thu, 14 Aug 2014 17:52:48 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id A4E9D1534D2; Thu, 14 Aug 2014 17:52:48 +0200 (CEST) Message-ID: <53ECDB51.2030201@digiware.nl> Date: Thu, 14 Aug 2014 17:52:49 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA6B2.8010003@digiware.nl> <53ECD3DA.6060501@yandex-team.ru> In-Reply-To: <53ECD3DA.6060501@yandex-team.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw , "Andrey V. Elsukov" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:53:23 -0000 On 14-8-2014 17:20, Alexander V. Chernikov wrote: > 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@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? > Well, we should, but I'm unsure if we have host:port notation anywhere > in current (or new) syntax: I can not answer that right from the top of my head. But I remember digging in the code to see how adresses were converted and how IPv6 fitted in there. And that because of the problem described above. But the main reason for "reporting" this, is that I forsee to possibility that with the new syntax it might be possible to run into this. But you have disgned the syntax, so I'll take your word for it that would not happen. >> 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. (I'm looking at this from a parseable grammar view, perhaps not 100% fitting) Well my argument is that after the table-keyword "table" there would always be the table-identifier, be it a name or a number. So "table" is a reserved word, now this would exclude hostnames called "table", is that (your) problem? So while parsing the keyword would always consume the next token as the qualifier that goes with the table-keyword. If that results in a not parseable sentence then the sentence needs to be rejected. Regards, --WjW From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 15:58:58 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BF0EA88; Thu, 14 Aug 2014 15:58:58 +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 44CC12884; Thu, 14 Aug 2014 15:58:58 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 1A7D91534C0; Thu, 14 Aug 2014 17:58:56 +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 jdMbXqM6EbJy; Thu, 14 Aug 2014 17:58:46 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C55191534D2; Thu, 14 Aug 2014 17:58:46 +0200 (CEST) Message-ID: <53ECDCB7.8090703@digiware.nl> Date: Thu, 14 Aug 2014 17:58:47 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lee Dilkie , 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> <53ECA6B2.8010003@digiware.nl> <53ECAFB9.50507@dilkie.com> <53ECD576.8040801@digiware.nl> <53ECDB62.5030708@dilkie.com> In-Reply-To: <53ECDB62.5030708@dilkie.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw , "Andrey V. Elsukov" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:58:58 -0000 On 14-8-2014 17:53, Lee Dilkie wrote: > > On 8/14/2014 11:27 AM, Willem Jan Withagen wrote: >> On 14-8-2014 14:46, Lee Dilkie wrote: >>> On 8/14/2014 08:08, Willem Jan Withagen wrote: >>>> 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? >>> the first and second forms are valid, but as ipv6 addresses *with no port*, >>> >>> The third is an ipv6 address with a port. >>> >>> If the intent of the second form is an address and port, it will not be >>> parsed that way by standard parsers and violates the ivp6 addressing rfc's. >> I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. >> So I think you rephrased what I meant to say. >> >> Thanx, >> --WjW >> > > and re-reading your original post, yes you did state it correctly. > > ipfw needs to be fixed to understand the correct format of ipv6 addresses. > > however, this isn't the only offender. netstat's output is also > incorrect (linux example) > > > tcp 0 0 :::22 > :::* LISTEN > > should be > > tcp 0 0 [::]:22 > [::]:* LISTEN > > I don't understand why folks dream up incompatible, and unparsable, ipv6 > address formats. Why bother with rfc's if no-one writes to them. > > (see rfc5952) It think that that was the RFC I found when looking into getting the browser to do the right thing when I want it to go to: [2001:4cb8:3:1::1]:8080 Well the RFC would be an argument to at least spec an IPv6 address in a ipfw rule to be allowed either with or without []'s. And if you run into trouble by not using the []'s, they are "easily" added. --WjW From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 16:15:50 2014 Return-Path: Delivered-To: freebsd-ipfw@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 C6D10D19; Thu, 14 Aug 2014 16:15:50 +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 826432B2B; Thu, 14 Aug 2014 16:15:50 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E1264153A8B; Thu, 14 Aug 2014 18:15:47 +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 aE2DA3iUEnrT; Thu, 14 Aug 2014 18:15:36 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id F02DC1534EC; Thu, 14 Aug 2014 18:15:35 +0200 (CEST) Message-ID: <53ECE0A8.7010705@digiware.nl> Date: Thu, 14 Aug 2014 18:15:36 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA6B2.8010003@digiware.nl> <53ECD3DA.6060501@yandex-team.ru> In-Reply-To: <53ECD3DA.6060501@yandex-team.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw , "Andrey V. Elsukov" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 16:15:50 -0000 On 14-8-2014 17:20, Alexander V. Chernikov wrote: >> 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: I now remember the case, sort of I think: When using an IPv6 address the last time I ran into the snag with: (From the ipfw(8) manual) ip-addr: .... addr:mask Matches all addresses with base addr (specified as an IP address, a network number, or a hostname) and the mask of mask, specified as a dotted quad. As an example, 1.2.3.4:255.0.255.0 or 1.0.3.0:255.0.255.0 will match 1.*.3.*. This form is advised only for non-contiguous masks. It is better to resort to the addr/masklen format for contiguous masks, which is more compact and less Which tried to use the last quad of an IPv6 adress in a very convoluted case, which I cannot reproduce any longer. Reading the manual, one of my problems is now clearly a RTFM: how to use ftp-data in a rule without the complaint that data is not a valid port-name. :) again something learned. --WjW From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 16:31:03 2014 Return-Path: Delivered-To: freebsd-ipfw@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 AE62570B; Thu, 14 Aug 2014 16:31:03 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i47.relay.mailchannels.net [184.154.112.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9632DEA; Thu, 14 Aug 2014 16:31:01 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|lee@dilkie.com Received: from data.snhdns.com (ip-10-236-1-24.us-west-2.compute.internal [10.236.1.24]) by relay.mailchannels.net (Postfix) with ESMTPA id E3EA16031D; Thu, 14 Aug 2014 15:53:22 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|lee@dilkie.com Received: from data.snhdns.com (data.snhdns.com [10.245.145.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.2.12); Thu, 14 Aug 2014 15:53:24 GMT X-MC-Relay: Good X-MailChannels-SenderId: totalchoicehosting|x-authuser|lee@dilkie.com X-MailChannels-Auth-Id: totalchoicehosting X-MC-Ingress-Time: 1408031604671 Received: from [216.191.234.70] (port=49055 helo=[10.39.164.100]) by data.snhdns.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHxKu-00089c-UZ; Thu, 14 Aug 2014 11:53:09 -0400 Message-ID: <53ECDB62.5030708@dilkie.com> Date: Thu, 14 Aug 2014 11:53:06 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Willem Jan Withagen , 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> <53ECA6B2.8010003@digiware.nl> <53ECAFB9.50507@dilkie.com> <53ECD576.8040801@digiware.nl> In-Reply-To: <53ECD576.8040801@digiware.nl> X-AuthUser: lee@dilkie.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw , "Andrey V. Elsukov" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 16:31:03 -0000 On 8/14/2014 11:27 AM, Willem Jan Withagen wrote: > On 14-8-2014 14:46, Lee Dilkie wrote: >> On 8/14/2014 08:08, Willem Jan Withagen wrote: >>> 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? >> the first and second forms are valid, but as ipv6 addresses *with no port*, >> >> The third is an ipv6 address with a port. >> >> If the intent of the second form is an address and port, it will not be >> parsed that way by standard parsers and violates the ivp6 addressing rfc's. > I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. > So I think you rephrased what I meant to say. > > Thanx, > --WjW > and re-reading your original post, yes you did state it correctly. ipfw needs to be fixed to understand the correct format of ipv6 addresses. however, this isn't the only offender. netstat's output is also incorrect (linux example) tcp 0 0 :::22 :::* LISTEN should be tcp 0 0 [::]:22 [::]:* LISTEN I don't understand why folks dream up incompatible, and unparsable, ipv6 address formats. Why bother with rfc's if no-one writes to them. (see rfc5952) -lee From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 22:01:33 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D90C0E80; Thu, 14 Aug 2014 22:01:32 +0000 (UTC) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E908E2E86; Thu, 14 Aug 2014 20:28:37 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id 0F8AE640582; Fri, 15 Aug 2014 00:28:32 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id BDA7F2C05F8; Fri, 15 Aug 2014 00:28:32 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::a5]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id HJ7r5n9jg8-SWIWUmvU; Fri, 15 Aug 2014 00:28:32 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: b1347399-3fcd-4e6f-a81f-1a68edba693f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408048112; bh=AMhV+l3u5lxVYwQRR0+Y4s9FBo/KJnT4CWVFgwmsEcM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=xde01vkgzPfZyegBt7DxlWDZoR69gzEzUGykzvJJugnBOw6wDGiziLPBk8Ll2qmuZ NUzoE70kr6gD6ug1m6sq3Cn2pXfb6CP6rBWvk+ffHpFRz+RAKWWRm1CpUj0WezOw7s qu2ZELAgZ0lmr6Xp8585azQYHLkJAMhWXynv2okM= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53ED1BEB.7000409@yandex-team.ru> Date: Fri, 15 Aug 2014 00:28:27 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> In-Reply-To: <53ECA302.8010100@yandex-team.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:01:33 -0000 On 14.08.2014 15:52, Alexander V. Chernikov wrote: > On 14.08.2014 15:15, Luigi Rizzo wrote: >> >> >> >> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov >> > wrote: >> >> On 14.08.2014 14:44, Luigi Rizzo wrote: >>> >>> >>> >>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov >>> > wrote: >>> >>> On 14.08.2014 13:23, Luigi Rizzo wrote: >>>> >>>> >>>> >>>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov >>>> > >>>> 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" > Ok, no problem with that. "addr" really sounds better. >> >> 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). > Great!. I'll ask him :) >> >> 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 ? Well, the most major problem is that tables handling code assumed that we do known number of items in advance, and since we're holding locks it won't change, so we don't need large contigious buffer to dump data to. This is not the case with "external" tables, so we can't _reliably_ dump them (the same situation as in case of dynamic states). Anyway, I've added cidr:kfib algo ( http://svnweb.freebsd.org/base?view=revision&revision=270001 ) and it looks funny. Quoting commit message: # ipfw table fib2 create algo "cidr:kfib fib=2" # ipfw table fib2 info +++ table(fib2), set(0) +++ kindex: 2, type: cidr, locked valtype: number, references: 0 algorithm: cidr:kfib fib=2 items: 11, size: 288 # ipfw table fib2 list +++ table(fib2), set(0) +++ 10.0.0.0/24 0 127.0.0.1/32 0 ::/96 0 ::1/128 0 ::ffff:0.0.0.0/96 0 2a02:978:2::/112 0 fe80::/10 0 fe80:1::/64 0 fe80:2::/64 0 fe80:3::/64 0 ff02::/16 0 # ipfw table fib2 lookup 10.0.0.5 10.0.0.0/24 0 # ipfw table fib2 lookup 2a02:978:2::11 2a02:978:2::/112 0 # ipfw table fib2 detail +++ table(fib2), set(0) +++ kindex: 2, type: cidr, locked valtype: number, references: 0 algorithm: cidr:kfib fib=2 items: 11, size: 288 IPv4 algorithm radix info items: 0 itemsize: 200 IPv6 algorithm radix info items: 0 itemsize: 200 > Implementing algo support for particular provider like sockets/iflists > shouldn't be hard. Most of the algorithms complexity lies in table > modifications. Here we have to support > lookup and dump operations, so it is the question of providing > necessary bindings to existing mechanisms (via some direct binding or > utilizing things like kernel_sysctl for dump support). > > It looks like the following maps well to current table concept: > * such tables are not created by default > * user issues > `ipfw table kfib create type addr algo "addr:kernel fib=0"` > or > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` > or > `ipfw table kiface create type iface algo "iface:kernel"` > * tables have special "readonly" type, flush_all requests are ignored > * no state stored internally > > So generic table handling code needs to be modified to support > read-only tables (and making more callbacks optional). > Additionally, we might need to proxy "info" request info algo callback > (optional, "real" algorithms won't implement it) to be able to show > number of items (and some other info) to user. > > > >> >> cheers >> luigi >> > From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 22:16:29 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FDACAB1; Thu, 14 Aug 2014 22:16:29 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6952C49B3; Thu, 14 Aug 2014 22:16:29 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:51592 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XHsWV-0006Xl-8c; Thu, 14 Aug 2014 03:44:47 -0700 From: To: , "'Lee Dilkie'" , "'Luigi Rizzo'" , "'Alexander V. Chernikov'" References: <53ECD576.8040801@digiware.nl> <53ED30BD.2020701@elischer.org> In-Reply-To: <53ED30BD.2020701@elischer.org> Subject: RE: Re: [CFT] new tables for ipfw Date: Thu, 14 Aug 2014 15:16:10 -0700 Message-ID: <046e01cfb80d$5aada9d0$1008fd70$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIWIEg38v1/m2jBgbgOgS+Xzd46CgIIhOPrmzOSUDA= Content-Language: en-us Sender: devin@shxd.cx Cc: 'Devin Teske' , 'Julian Elischer' X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:16:29 -0000 NB: Please CC me on replies, I'm off-list > On 14-8-2014 14:46, Lee Dilkie wrote: >> >> On 8/14/2014 08:08, Willem Jan Withagen wrote: >>> 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? >> >> the first and second forms are valid, but as ipv6 addresses *with no port*, >> >> The third is an ipv6 address with a port. >> >> If the intent of the second form is an address and port, it will not be >> parsed that way by standard parsers and violates the ivp6 addressing rfc's. > > I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. > So I think you rephrased what I meant to say. Might want to have a look at IPv6 address validators. Execute on FreeBSD 9.3 or 10.1: bsdconfig includes -adF 'ip.*6' | less -R Or on FreeBSD 9.2 or 10.0: less '+/ip[^ ]*6' /usr/share/bsdconfig/media/tcpip.subr less '+/ip[^ ]*6' /usr/share/bsdconfig/networking/ipaddr.subr (output from 9.3 command pasted below) dteske@scribe9.vicor.com ~ $ bsdconfig includes -dF 'ip.*6' >>> Functions in media/tcpip.subr matching `ip.*6': + f_validate_ipaddr6 $ipv6_addr Returns zero if the given argument (an IPv6 address) is of the proper format. The return status for invalid IP address is one of: 1 One or more individual segments within the IP address (separated by colons) contains one or more invalid characters. Segments must contain only combinations of the characters 0-9, A-F, or a-f. 2 Too many/incorrect null segments. A single null segment is allowed within the IP address (separated by colons) but not allowed at the beginning or end (unless a double-null segment; i.e., "::*" or "*::"). 3 One or more individual segments within the IP address (separated by colons) exceeds the length of 4 hex-digits. 4 The IP address entered has either too few (less than 3), too many (more than 8), or not enough segments, separated by colons. 5* The IPv4 address at the end of the IPv6 address is invalid. * When there is an error with the dotted-quad IPv4 address at the end of the IPv6 address, the return value of 5 is OR'd with a bit-shifted (<< 4) return of f_validate_ipaddr. >>> Functions in networking/ipaddr.subr matching `ip.*6': + f_dialog_ip6error $error $ipv6_addr Display a msgbox with the appropriate error message for an error returned by the f_validate_ipaddr6 function above. + f_dialog_validate_ipaddr6 $ipv6_addr Returns zero if the given argument (an IPv6 address) is of the proper format. If the IP address is determined to be invalid, the appropriate error will be displayed using the f_dialog_ip6error function above. (end pasted output) Yes, the code is shell. But you can trivially convert the logic into something like C using nothing more than strchr, strlen, and fnmatch. -- Devin From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 15 13:25:13 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BFD08E0; Fri, 15 Aug 2014 13:25:13 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7D32D20; Fri, 15 Aug 2014 13:25:13 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XIDXm-000D82-Q8; Fri, 15 Aug 2014 13:11:30 +0400 Message-ID: <53EE0A30.4020800@FreeBSD.org> Date: Fri, 15 Aug 2014 17:25:04 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dmitry Selivanov Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> <53DCA25C.1000108@FreeBSD.org> <53DF55FA.8010303@FreeBSD.org> <20140804115817.GA13814@onelab2.iet.unipi.it> <53DFE438.5050209@FreeBSD.org> <53E4BE62.4050303@rlan.ru> In-Reply-To: <53E4BE62.4050303@rlan.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 13:25:13 -0000 On 08.08.2014 16:11, Dmitry Selivanov wrote: > 04.08.2014 23:51, Alexander V. Chernikov пишет: >> On 04.08.2014 15:58, Luigi Rizzo wrote: >>> On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: >>>> On 02.08.2014 12:33, Alexander V. Chernikov wrote: >>>>> On 02.08.2014 10:33, Luigi Rizzo wrote: >>>>>> >>>>>> >>>>>> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov >>>>>> > wrote: >>>>>> >>>>>> Hello all. >>>>>> >>>>>> I'm currently working on to enhance ipfw in some areas. >>>>>> The most notable (and user-visible) change is named table >>>>>> support. >>>>>> The other one is support for different lookup algorithms >>>>>> for different >>>>>> key types. >>>>>> >>>>>> For example, new ipfw permits writing this: >>>>>> >>>>>> ipfw table tb1 create type cidr >>>>>> ipfw add allow ip from table(tl1) to any >>>>>> ipfw add allow ip from any lookup dst-ip tb1 >>>>>> >>>>>> ipfw table if1 create type iface >>>>>> ipfw add skipto tablearg ip from any to any via table(if1) >>>>>> >>>>>> or even this: >>>>>> ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port >>>>>> ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 >>>>>> ipfw add allow ip from any to any flow table(fl1) >>>>>> >>>>>> all these changes fully preserve backward compatibility. >>>>>> (actually tables needs now to be created before use and >>>>>> their type needs >>>>>> to match with opcode used, but new ipfw(8) performs >>>>>> auto-creation >>>>>> for cidr tables). >>>>>> >>>>>> There is another thing I'm going to change and I'm not sure >>>>>> I can keep >>>>>> the same compatibility level. >>>>>> >>>>>> Table values, from one point of view, can be classified to >>>>>> the following >>>>>> types: >>>>>> >>>>>> - skipto argument >>>>>> - fwd argument (*) >>>>>> - link to another object (nat, pipe, queue) >>>>>> - plain u32 (not bound to any object) >>>>>> (divert/tee,netgraph,tag/utag,limit) >>>>>> >>>>>> There are the following reasons why I think it is necessary >>>>>> to implement >>>>>> explicit table values typing (like tables): >>>>>> - Implementing fwd tablearg for IPv6 hosts requires >>>>>> indirection table >>>>>> - Converting nat/pipe instance ids to names renders values >>>>>> unusable >>>>>> - retiring old hack with storing saved pointer of found >>>>>> object/rule >>>>>> inside rule w/o proper locking >>>>>> - making faster skipto >>>>>> >>>>>> >>>>>> ??????i don't buy the idea that you need typed arguments >>>>>> for all the cases above. Maybe the case that >>>>>> may make sense is the fwd argument (and in the future >>>>>> something else). >>>>>> We already discussed, i think, the fact that now it >>>>>> is legal to have references to non existing things >>>>>> (skipto, pipes etc.) implemented as u32. >>>>>> Removing that would break configurations. >>>>> It depends on actual implementation. This can be preserved by >>>>> auto-creating necessary objects in kernel and/or in userspace, so >>>>> we can (and should) avoid breaking in this particular way. >>>> Can you please explain your vision on values another time? >>>> As far as I understand, you're not against it in general, but the >>>> details matter: >>>> * IP address can be one of the types (it won't break much, and we can >>>> simply skip that one for MFC) >>>> * what about typing for nat/pipes ? we're not going to convert >>>> their ids >>>> to names? (or maybe you can suggest other non-disruptive way?) >>>> * everything else is type "u32" >>> >>> Correct, I am mostly concerned about the details, not on the general >>> concept. >>> >>> To summarize the discussion Alexander and I had about converting >>> identifiers from numbers to arbitrary strings (this is partly related >>> to the values stored in tables, but I think we should have a coherent >>> behaviour) >>> >>> 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits >>> or less) >>> for rules, pipes, queues, tables, probably nat instances. >>> >>> 2. CURRENTLY, in all the above contexts, it is legal to reference a >>> non existing object (rule, pipe, table names, etc.), >>> and the kernel will do something reasonable, namely jump to the >>> next rule, drop traffic for non existing pipes, and so on. >>> >>> 3. of course we want to preserve backward compatibility both for >>> the ioctl interface, and for user configurations. >>> >>> 4. The in-kernel representation of identifiers is not visible to users, >>> so we can use a numeric representation in the kernel for >>> identifiers. >>> Strings like "12345" are converted with atoi() or the like, >>> whereas for other identifiers or numbers outside of the 2^16 range >>> the kernel manages a translation table, allocating new numeric >>> identifiers if a new string appears. >>> This permits backward compatibility for old rulesets, and does not >>> impact performance because the translation table is only >>> used during rules additions or deletion. >> Yes. However this requires either holding either (1) 2 pointers (old&new >> arrays), or (2) 65k+ index array, or (3) chained hash table. >> (1) would require additional pointers for each subsystem (and some >> additional management), >> (2) will definitely upset embedded guys and >> (3) is worse in terms of performance >>> >>> With this in mind, i think we should follow a similar approach for >>> objects stored in tables, hence >>> >>> if an u32 value was available in the past, it must be >>> available also in the new implementation. >>> >>> The issue with tables is that some convoluted configuration could >>> use the same table to reference pipes _and_ rules _and_ perhaps >>> other things represented as numbers (the former is not too strange, >>> if i have a large configuration i might place sections at rules >>> 12000, 13000, 14000... and associate pipes with the same numberic >>> identifier to each block of rules). >>> >>> Typed table values would clearly disturb backward compatibility >>> in the above configurations. However it should not be difficult >>> to accept arbitrary strings as the values stored in tables, and >>> then store multiple representations as appropriate, including: >> Well, I've thought about thas one. It may be an option, but the details >> are not so promising (below) >>> - the string representation, unconditionally >>> - for names that can be resolved by DNS, the ipv6 and ipv4 address(es) >>> associated with them. ipfw already translates hostnames in rules >>> so this is POLA >> I'm not happy what ipfw(8) is doing instead of translation. The proper >> way would be not simply using first AF_INET answer but saving ALL >> IPv4+IPv6 records inside rule (and some more tracking should be done >> afterwards, but that's totally different story). Additionally, I'm >> unsure if we really need next-hop value expressed as hostname (how can >> we deal with multiple addresses and diffrent AFs?). We may store strings >> (and I think we should do it) but I'm unsure about this particular >> option of interpreting them. >>> - for other strings, a u32 from the translation table as previously >>> indicated >>> - and for numeric values, the u32 representation (truncated if needed, >>> according to whatever is the existing behaviour) >>> - >>> If we cannot generate an u32 we will put some value (e.g. 0) >>> that hopefully will not cause confusion. >> As far as I understand, we accept some string "s" as table value inside >> the kernel, than, we have some logic that says: >> oh, dummynet pipe has the same name "s"s, oh, nat entity with name "s" >> has just been created, let's save indices. >> >> That would require additional indirection table like: >> >> index | [ skipto idx | nat idx | pipe idx | queue idx | fwd index ] >> ( so we will have 2-level indirection table for fwd if we do IPv6) >> >> We can optimize this if we use "same name -> same kidx" approach >> regardless of kernel object we're refering to. That might require some >> more memory, but that's OK from my point of view. >> >> So we end up with >> int [ skipto idx | fwd idx | obj idx ] >> >> idx "0" is special value which means the same as 2.CURRENT >> >> That looks better, but still way to complex. >> I do care about compatibility, but it's hard to improve things without >> changing. >> >> I'd like to propose the following: >> * Split values into 3 types ("ip|nexthop", "number", "object") >> * Do not insist on object existence, use value "0" to mimic 2.CURRENT >> behavior. >> * Retain full compatibility by introducing special value type "legacy" >> which matches any type and is backed by given indirection table. >> * Issue warning in ipfw(8) binary on all auto-created tables that >> auto-creation is legacy and this behavior will be dropped in next major >> release (e.g. 11.0) >> * Save this behavior in MFC but drop "legacy" tables in head after a >> month after actual MFC. >> >> That do you think? >>> >>> If we do it this way, we should be able to preserve backward >>> compatibility _and_ add features that people may need. >>> >>> cheers >>> luigi >>> > Here is my idea: tablearg should contain more than one value. I think > getting several values from one table lookup is faster than several > table lookups with one value. > Let tablearg be not just uint32, but array with different value types > inside it. There are some use cases where we might need 2-level value lookup (e.g. algo returning index for index table where actual data reside) and each data item can really be up to 64-bytes long. The problem is in actual partitioning and compatibility. > > For example I have many such rules: > allow src-ip 1.2.3.4 MAC any 11:22:33:44:55:66 recv vlan1234 dst-ip > 1.1.1.1 Sorry, what task are you solving by using given rules? > > These rules can be replaced with such construction: > allow src-ip table(1) MAC any tablearg[1] recv tablearg[2] dst-ip > tablearg[3] > > But I don't think indexing by value is a good idea. I think > index==starting byte is a better way: > allow src-ip table(1) MAC any tablearg:0 recv tablearg:6 dst-ip > tablearg:32 > where MAC's 6 bytes are from 0 to 5 in tablearg; iface string is from > 6 and till \0, but less than 26 bytes; and IPv4's 4 bytes are from 32 > to 35. > So we need to create table for it: > table 1 set MAC:0 string:6:26 ip:32 > table 1 add 1.2.3.4 11:22:33:44:55:66 vlan1234 1.1.1.1 > > String can be used both for iface and comment. > Other possible value types: > uint16 for nat, pipe, skipto and other 2-bytes actions > IPv4 4 bytes > CIDRv4 5 bytes > IPv6 16 bytes > CIDRv6 17 bytes > table_id 2 bytes - link to another table Well, it seems we have enough space to store most of these, however, problems seem to remain the same: typing and compatibility. When you're creating new table (or it is auto-created) which values types should be assumed ? All of them? What should `ipfw table X list` show as "value" field ? How should ipfw(8) treat "add 1.1.1.1 0" input? What will happen if we want to add another type field to this list? (MAC address of Infiniband MAC address, for example). > > Table value length can be set for example with loader tunable like > net.inet.ip.fw.table_value_length. > Even with default uint32 value length we can get 2 uint16 values or 4 > uint8 values, this can help in some configurations. > > This way is more complex, but much more flexible. It's like netgraph > subsystem. > I think it suites both Alexander and Luigi requests. > > From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 15 14:19:16 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE9111DF; Fri, 15 Aug 2014 14:19:16 +0000 (UTC) Received: from mail.rlan.ru (mail.rlan.ru [213.234.25.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03C372540; Fri, 15 Aug 2014 14:19:15 +0000 (UTC) Message-ID: <53EE16DE.9020209@rlan.ru> Date: Fri, 15 Aug 2014 18:19:10 +0400 From: Dmitry Selivanov User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> <53DCA25C.1000108@FreeBSD.org> <53DF55FA.8010303@FreeBSD.org> <20140804115817.GA13814@onelab2.iet.unipi.it> <53DFE438.5050209@FreeBSD.org> <53E4BE62.4050303@rlan.ru> <53EE0A30.4020800@FreeBSD.org> In-Reply-To: <53EE0A30.4020800@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:19:16 -0000 15.08.2014 17:25, Alexander V. Chernikov пишет: > On 08.08.2014 16:11, Dmitry Selivanov wrote: >> 04.08.2014 23:51, Alexander V. Chernikov пишет: >>> On 04.08.2014 15:58, Luigi Rizzo wrote: >>>> On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: >>>>> On 02.08.2014 12:33, Alexander V. Chernikov wrote: >>>>>> On 02.08.2014 10:33, Luigi Rizzo wrote: >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov >>>>>>> > wrote: >>>>>>> >>>>>>> Hello all. >>>>>>> >>>>>>> I'm currently working on to enhance ipfw in some areas. >>>>>>> The most notable (and user-visible) change is named table support. >>>>>>> The other one is support for different lookup algorithms for different >>>>>>> key types. >>>>>>> >>>>>>> For example, new ipfw permits writing this: >>>>>>> >>>>>>> ipfw table tb1 create type cidr >>>>>>> ipfw add allow ip from table(tl1) to any >>>>>>> ipfw add allow ip from any lookup dst-ip tb1 >>>>>>> >>>>>>> ipfw table if1 create type iface >>>>>>> ipfw add skipto tablearg ip from any to any via table(if1) >>>>>>> >>>>>>> or even this: >>>>>>> ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port >>>>>>> ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 >>>>>>> ipfw add allow ip from any to any flow table(fl1) >>>>>>> >>>>>>> all these changes fully preserve backward compatibility. >>>>>>> (actually tables needs now to be created before use and their type needs >>>>>>> to match with opcode used, but new ipfw(8) performs auto-creation >>>>>>> for cidr tables). >>>>>>> >>>>>>> There is another thing I'm going to change and I'm not sure I can keep >>>>>>> the same compatibility level. >>>>>>> >>>>>>> Table values, from one point of view, can be classified to the following >>>>>>> types: >>>>>>> >>>>>>> - skipto argument >>>>>>> - fwd argument (*) >>>>>>> - link to another object (nat, pipe, queue) >>>>>>> - plain u32 (not bound to any object) >>>>>>> (divert/tee,netgraph,tag/utag,limit) >>>>>>> >>>>>>> There are the following reasons why I think it is necessary to implement >>>>>>> explicit table values typing (like tables): >>>>>>> - Implementing fwd tablearg for IPv6 hosts requires indirection table >>>>>>> - Converting nat/pipe instance ids to names renders values unusable >>>>>>> - retiring old hack with storing saved pointer of found object/rule >>>>>>> inside rule w/o proper locking >>>>>>> - making faster skipto >>>>>>> >>>>>>> >>>>>>> ??????i don't buy the idea that you need typed arguments >>>>>>> for all the cases above. Maybe the case that >>>>>>> may make sense is the fwd argument (and in the future >>>>>>> something else). >>>>>>> We already discussed, i think, the fact that now it >>>>>>> is legal to have references to non existing things >>>>>>> (skipto, pipes etc.) implemented as u32. >>>>>>> Removing that would break configurations. >>>>>> It depends on actual implementation. This can be preserved by >>>>>> auto-creating necessary objects in kernel and/or in userspace, so >>>>>> we can (and should) avoid breaking in this particular way. >>>>> Can you please explain your vision on values another time? >>>>> As far as I understand, you're not against it in general, but the >>>>> details matter: >>>>> * IP address can be one of the types (it won't break much, and we can >>>>> simply skip that one for MFC) >>>>> * what about typing for nat/pipes ? we're not going to convert their ids >>>>> to names? (or maybe you can suggest other non-disruptive way?) >>>>> * everything else is type "u32" >>>> >>>> Correct, I am mostly concerned about the details, not on the general concept. >>>> >>>> To summarize the discussion Alexander and I had about converting >>>> identifiers from numbers to arbitrary strings (this is partly related >>>> to the values stored in tables, but I think we should have a coherent >>>> behaviour) >>>> >>>> 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) >>>> for rules, pipes, queues, tables, probably nat instances. >>>> >>>> 2. CURRENTLY, in all the above contexts, it is legal to reference a >>>> non existing object (rule, pipe, table names, etc.), >>>> and the kernel will do something reasonable, namely jump to the >>>> next rule, drop traffic for non existing pipes, and so on. >>>> >>>> 3. of course we want to preserve backward compatibility both for >>>> the ioctl interface, and for user configurations. >>>> >>>> 4. The in-kernel representation of identifiers is not visible to users, >>>> so we can use a numeric representation in the kernel for identifiers. >>>> Strings like "12345" are converted with atoi() or the like, >>>> whereas for other identifiers or numbers outside of the 2^16 range >>>> the kernel manages a translation table, allocating new numeric >>>> identifiers if a new string appears. >>>> This permits backward compatibility for old rulesets, and does not >>>> impact performance because the translation table is only >>>> used during rules additions or deletion. >>> Yes. However this requires either holding either (1) 2 pointers (old&new >>> arrays), or (2) 65k+ index array, or (3) chained hash table. >>> (1) would require additional pointers for each subsystem (and some >>> additional management), >>> (2) will definitely upset embedded guys and >>> (3) is worse in terms of performance >>>> >>>> With this in mind, i think we should follow a similar approach for >>>> objects stored in tables, hence >>>> >>>> if an u32 value was available in the past, it must be >>>> available also in the new implementation. >>>> >>>> The issue with tables is that some convoluted configuration could >>>> use the same table to reference pipes _and_ rules _and_ perhaps >>>> other things represented as numbers (the former is not too strange, >>>> if i have a large configuration i might place sections at rules >>>> 12000, 13000, 14000... and associate pipes with the same numberic >>>> identifier to each block of rules). >>>> >>>> Typed table values would clearly disturb backward compatibility >>>> in the above configurations. However it should not be difficult >>>> to accept arbitrary strings as the values stored in tables, and >>>> then store multiple representations as appropriate, including: >>> Well, I've thought about thas one. It may be an option, but the details >>> are not so promising (below) >>>> - the string representation, unconditionally >>>> - for names that can be resolved by DNS, the ipv6 and ipv4 address(es) >>>> associated with them. ipfw already translates hostnames in rules >>>> so this is POLA >>> I'm not happy what ipfw(8) is doing instead of translation. The proper >>> way would be not simply using first AF_INET answer but saving ALL >>> IPv4+IPv6 records inside rule (and some more tracking should be done >>> afterwards, but that's totally different story). Additionally, I'm >>> unsure if we really need next-hop value expressed as hostname (how can >>> we deal with multiple addresses and diffrent AFs?). We may store strings >>> (and I think we should do it) but I'm unsure about this particular >>> option of interpreting them. >>>> - for other strings, a u32 from the translation table as previously >>>> indicated >>>> - and for numeric values, the u32 representation (truncated if needed, >>>> according to whatever is the existing behaviour) >>>> - >>>> If we cannot generate an u32 we will put some value (e.g. 0) >>>> that hopefully will not cause confusion. >>> As far as I understand, we accept some string "s" as table value inside >>> the kernel, than, we have some logic that says: >>> oh, dummynet pipe has the same name "s"s, oh, nat entity with name "s" >>> has just been created, let's save indices. >>> >>> That would require additional indirection table like: >>> >>> index | [ skipto idx | nat idx | pipe idx | queue idx | fwd index ] >>> ( so we will have 2-level indirection table for fwd if we do IPv6) >>> >>> We can optimize this if we use "same name -> same kidx" approach >>> regardless of kernel object we're refering to. That might require some >>> more memory, but that's OK from my point of view. >>> >>> So we end up with >>> int [ skipto idx | fwd idx | obj idx ] >>> >>> idx "0" is special value which means the same as 2.CURRENT >>> >>> That looks better, but still way to complex. >>> I do care about compatibility, but it's hard to improve things without >>> changing. >>> >>> I'd like to propose the following: >>> * Split values into 3 types ("ip|nexthop", "number", "object") >>> * Do not insist on object existence, use value "0" to mimic 2.CURRENT >>> behavior. >>> * Retain full compatibility by introducing special value type "legacy" >>> which matches any type and is backed by given indirection table. >>> * Issue warning in ipfw(8) binary on all auto-created tables that >>> auto-creation is legacy and this behavior will be dropped in next major >>> release (e.g. 11.0) >>> * Save this behavior in MFC but drop "legacy" tables in head after a >>> month after actual MFC. >>> >>> That do you think? >>>> >>>> If we do it this way, we should be able to preserve backward >>>> compatibility _and_ add features that people may need. >>>> >>>> cheers >>>> luigi >>>> >> Here is my idea: tablearg should contain more than one value. I think getting several values from one table lookup is faster than several table lookups with one value. >> Let tablearg be not just uint32, but array with different value types inside it. > There are some use cases where we might need 2-level value lookup (e.g. algo returning index for index table where actual data reside) and each data item can > really be up to 64-bytes long. The problem is in actual partitioning and compatibility. >> >> For example I have many such rules: >> allow src-ip 1.2.3.4 MAC any 11:22:33:44:55:66 recv vlan1234 dst-ip 1.1.1.1 > Sorry, what task are you solving by using given rules? Small ISP, clients have static IP with MAC-authorization. Src iface must be checked to prevent IP-spoofing. Dst-IP sometimes is used for p2p-channels. >> >> These rules can be replaced with such construction: >> allow src-ip table(1) MAC any tablearg[1] recv tablearg[2] dst-ip tablearg[3] >> >> But I don't think indexing by value is a good idea. I think index==starting byte is a better way: >> allow src-ip table(1) MAC any tablearg:0 recv tablearg:6 dst-ip tablearg:32 >> where MAC's 6 bytes are from 0 to 5 in tablearg; iface string is from 6 and till \0, but less than 26 bytes; and IPv4's 4 bytes are from 32 to 35. > >> So we need to create table for it: >> table 1 set MAC:0 string:6:26 ip:32 >> table 1 add 1.2.3.4 11:22:33:44:55:66 vlan1234 1.1.1.1 >> >> String can be used both for iface and comment. >> Other possible value types: >> uint16 for nat, pipe, skipto and other 2-bytes actions >> IPv4 4 bytes >> CIDRv4 5 bytes >> IPv6 16 bytes >> CIDRv6 17 bytes >> table_id 2 bytes - link to another table > Well, it seems we have enough space to store most of these, however, problems seem to remain the same: typing and compatibility. > When you're creating new table (or it is auto-created) which values types should be assumed ? All of them? Default - as usually uint32. > What should `ipfw table X list` show as "value" field ? I added table "header" in this line: table 1 set MAC:0 string:6:26 ip:32 So `ipfw table X list` should show something like this: ---table(0)--- 1.2.3.4/32 11:22:33:44:55:66 vlan1234 1.1.1.1 We can also add "header" description in output (with or without additional parameter - depends on compatibility needs) like this: ---table(0)--- addr MAC iface IPv4 > How should ipfw(8) treat "add 1.1.1.1 0" input? It should look at table "header" and return error message like "Value doesn't match table header" > What will happen if we want to add another type field to this list? (MAC address of Infiniband MAC address, for example). I don't think there is a sense to mix both MAC[6] and MAC[20] values in 1 table. It is easier to create 2 tables with different "headers". For Infiniband we can add another type: MAC20 (or something like this). Or we can use "MAC"-type like string type(see above): MAC:6:25 (1st and last bytes, or 1st and length). > >> >> Table value length can be set for example with loader tunable like net.inet.ip.fw.table_value_length. >> Even with default uint32 value length we can get 2 uint16 values or 4 uint8 values, this can help in some configurations. >> >> This way is more complex, but much more flexible. It's like netgraph subsystem. >> I think it suites both Alexander and Luigi requests. >> >> > From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 15 15:20:23 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57212ABF; Fri, 15 Aug 2014 15:20:23 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF1652C86; Fri, 15 Aug 2014 15:20:22 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XIFLD-000EOJ-GP; Fri, 15 Aug 2014 15:06:39 +0400 Message-ID: <53EE252D.10109@FreeBSD.org> Date: Fri, 15 Aug 2014 19:20:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dmitry Selivanov Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> <53DCA25C.1000108@FreeBSD.org> <53DF55FA.8010303@FreeBSD.org> <20140804115817.GA13814@onelab2.iet.unipi.it> <53DFE438.5050209@FreeBSD.org> <53E4BE62.4050303@rlan.ru> <53EE0A30.4020800@FreeBSD.org> <53EE16DE.9020209@rlan.ru> In-Reply-To: <53EE16DE.9020209@rlan.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:20:23 -0000 On 15.08.2014 18:19, Dmitry Selivanov wrote: > 15.08.2014 17:25, Alexander V. Chernikov пишет: >> On 08.08.2014 16:11, Dmitry Selivanov wrote: >>> 04.08.2014 23:51, Alexander V. Chernikov пишет: >>>> On 04.08.2014 15:58, Luigi Rizzo wrote: >>>>> On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov >>>>> wrote: >>>>>> On 02.08.2014 12:33, Alexander V. Chernikov wrote: >>>>>>> On 02.08.2014 10:33, Luigi Rizzo wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hello all. >>>>>>>> >>>>>>>> I'm currently working on to enhance ipfw in some areas. >>>>>>>> The most notable (and user-visible) change is named table >>>>>>>> support. >>>>>>>> The other one is support for different lookup algorithms >>>>>>>> for different >>>>>>>> key types. >>>>>>>> >>>>>>>> For example, new ipfw permits writing this: >>>>>>>> >>>>>>>> ipfw table tb1 create type cidr >>>>>>>> ipfw add allow ip from table(tl1) to any >>>>>>>> ipfw add allow ip from any lookup dst-ip tb1 >>>>>>>> >>>>>>>> ipfw table if1 create type iface >>>>>>>> ipfw add skipto tablearg ip from any to any via table(if1) >>>>>>>> >>>>>>>> or even this: >>>>>>>> ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port >>>>>>>> ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 >>>>>>>> ipfw add allow ip from any to any flow table(fl1) >>>>>>>> >>>>>>>> all these changes fully preserve backward compatibility. >>>>>>>> (actually tables needs now to be created before use and >>>>>>>> their type needs >>>>>>>> to match with opcode used, but new ipfw(8) performs >>>>>>>> auto-creation >>>>>>>> for cidr tables). >>>>>>>> >>>>>>>> There is another thing I'm going to change and I'm not >>>>>>>> sure I can keep >>>>>>>> the same compatibility level. >>>>>>>> >>>>>>>> Table values, from one point of view, can be classified >>>>>>>> to the following >>>>>>>> types: >>>>>>>> >>>>>>>> - skipto argument >>>>>>>> - fwd argument (*) >>>>>>>> - link to another object (nat, pipe, queue) >>>>>>>> - plain u32 (not bound to any object) >>>>>>>> (divert/tee,netgraph,tag/utag,limit) >>>>>>>> >>>>>>>> There are the following reasons why I think it is >>>>>>>> necessary to implement >>>>>>>> explicit table values typing (like tables): >>>>>>>> - Implementing fwd tablearg for IPv6 hosts requires >>>>>>>> indirection table >>>>>>>> - Converting nat/pipe instance ids to names renders >>>>>>>> values unusable >>>>>>>> - retiring old hack with storing saved pointer of found >>>>>>>> object/rule >>>>>>>> inside rule w/o proper locking >>>>>>>> - making faster skipto >>>>>>>> >>>>>>>> >>>>>>>> ??????i don't buy the idea that you need typed arguments >>>>>>>> for all the cases above. Maybe the case that >>>>>>>> may make sense is the fwd argument (and in the future >>>>>>>> something else). >>>>>>>> We already discussed, i think, the fact that now it >>>>>>>> is legal to have references to non existing things >>>>>>>> (skipto, pipes etc.) implemented as u32. >>>>>>>> Removing that would break configurations. >>>>>>> It depends on actual implementation. This can be preserved by >>>>>>> auto-creating necessary objects in kernel and/or in userspace, so >>>>>>> we can (and should) avoid breaking in this particular way. >>>>>> Can you please explain your vision on values another time? >>>>>> As far as I understand, you're not against it in general, but the >>>>>> details matter: >>>>>> * IP address can be one of the types (it won't break much, and we >>>>>> can >>>>>> simply skip that one for MFC) >>>>>> * what about typing for nat/pipes ? we're not going to convert >>>>>> their ids >>>>>> to names? (or maybe you can suggest other non-disruptive way?) >>>>>> * everything else is type "u32" >>>>> >>>>> Correct, I am mostly concerned about the details, not on the >>>>> general concept. >>>>> >>>>> To summarize the discussion Alexander and I had about converting >>>>> identifiers from numbers to arbitrary strings (this is partly related >>>>> to the values stored in tables, but I think we should have a coherent >>>>> behaviour) >>>>> >>>>> 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 >>>>> bits or less) >>>>> for rules, pipes, queues, tables, probably nat instances. >>>>> >>>>> 2. CURRENTLY, in all the above contexts, it is legal to reference a >>>>> non existing object (rule, pipe, table names, etc.), >>>>> and the kernel will do something reasonable, namely jump to the >>>>> next rule, drop traffic for non existing pipes, and so on. >>>>> >>>>> 3. of course we want to preserve backward compatibility both for >>>>> the ioctl interface, and for user configurations. >>>>> >>>>> 4. The in-kernel representation of identifiers is not visible to >>>>> users, >>>>> so we can use a numeric representation in the kernel for >>>>> identifiers. >>>>> Strings like "12345" are converted with atoi() or the like, >>>>> whereas for other identifiers or numbers outside of the 2^16 >>>>> range >>>>> the kernel manages a translation table, allocating new numeric >>>>> identifiers if a new string appears. >>>>> This permits backward compatibility for old rulesets, and does >>>>> not >>>>> impact performance because the translation table is only >>>>> used during rules additions or deletion. >>>> Yes. However this requires either holding either (1) 2 pointers >>>> (old&new >>>> arrays), or (2) 65k+ index array, or (3) chained hash table. >>>> (1) would require additional pointers for each subsystem (and some >>>> additional management), >>>> (2) will definitely upset embedded guys and >>>> (3) is worse in terms of performance >>>>> >>>>> With this in mind, i think we should follow a similar approach for >>>>> objects stored in tables, hence >>>>> >>>>> if an u32 value was available in the past, it must be >>>>> available also in the new implementation. >>>>> >>>>> The issue with tables is that some convoluted configuration could >>>>> use the same table to reference pipes _and_ rules _and_ perhaps >>>>> other things represented as numbers (the former is not too strange, >>>>> if i have a large configuration i might place sections at rules >>>>> 12000, 13000, 14000... and associate pipes with the same numberic >>>>> identifier to each block of rules). >>>>> >>>>> Typed table values would clearly disturb backward compatibility >>>>> in the above configurations. However it should not be difficult >>>>> to accept arbitrary strings as the values stored in tables, and >>>>> then store multiple representations as appropriate, including: >>>> Well, I've thought about thas one. It may be an option, but the >>>> details >>>> are not so promising (below) >>>>> - the string representation, unconditionally >>>>> - for names that can be resolved by DNS, the ipv6 and ipv4 >>>>> address(es) >>>>> associated with them. ipfw already translates hostnames in rules >>>>> so this is POLA >>>> I'm not happy what ipfw(8) is doing instead of translation. The proper >>>> way would be not simply using first AF_INET answer but saving ALL >>>> IPv4+IPv6 records inside rule (and some more tracking should be done >>>> afterwards, but that's totally different story). Additionally, I'm >>>> unsure if we really need next-hop value expressed as hostname (how can >>>> we deal with multiple addresses and diffrent AFs?). We may store >>>> strings >>>> (and I think we should do it) but I'm unsure about this particular >>>> option of interpreting them. >>>>> - for other strings, a u32 from the translation table as previously >>>>> indicated >>>>> - and for numeric values, the u32 representation (truncated if >>>>> needed, >>>>> according to whatever is the existing behaviour) >>>>> - >>>>> If we cannot generate an u32 we will put some value (e.g. 0) >>>>> that hopefully will not cause confusion. >>>> As far as I understand, we accept some string "s" as table value >>>> inside >>>> the kernel, than, we have some logic that says: >>>> oh, dummynet pipe has the same name "s"s, oh, nat entity with name "s" >>>> has just been created, let's save indices. >>>> >>>> That would require additional indirection table like: >>>> >>>> index | [ skipto idx | nat idx | pipe idx | queue idx | fwd index ] >>>> ( so we will have 2-level indirection table for fwd if we do IPv6) >>>> >>>> We can optimize this if we use "same name -> same kidx" approach >>>> regardless of kernel object we're refering to. That might require some >>>> more memory, but that's OK from my point of view. >>>> >>>> So we end up with >>>> int [ skipto idx | fwd idx | obj idx ] >>>> >>>> idx "0" is special value which means the same as 2.CURRENT >>>> >>>> That looks better, but still way to complex. >>>> I do care about compatibility, but it's hard to improve things without >>>> changing. >>>> >>>> I'd like to propose the following: >>>> * Split values into 3 types ("ip|nexthop", "number", "object") >>>> * Do not insist on object existence, use value "0" to mimic 2.CURRENT >>>> behavior. >>>> * Retain full compatibility by introducing special value type "legacy" >>>> which matches any type and is backed by given indirection table. >>>> * Issue warning in ipfw(8) binary on all auto-created tables that >>>> auto-creation is legacy and this behavior will be dropped in next >>>> major >>>> release (e.g. 11.0) >>>> * Save this behavior in MFC but drop "legacy" tables in head after a >>>> month after actual MFC. >>>> >>>> That do you think? >>>>> >>>>> If we do it this way, we should be able to preserve backward >>>>> compatibility _and_ add features that people may need. >>>>> >>>>> cheers >>>>> luigi >>>>> >>> Here is my idea: tablearg should contain more than one value. I >>> think getting several values from one table lookup is faster than >>> several table lookups with one value. >>> Let tablearg be not just uint32, but array with different value >>> types inside it. >> There are some use cases where we might need 2-level value lookup >> (e.g. algo returning index for index table where actual data reside) >> and each data item can >> really be up to 64-bytes long. The problem is in actual partitioning >> and compatibility. >>> >>> For example I have many such rules: >>> allow src-ip 1.2.3.4 MAC any 11:22:33:44:55:66 recv vlan1234 dst-ip >>> 1.1.1.1 >> Sorry, what task are you solving by using given rules? > Small ISP, clients have static IP with MAC-authorization. Src iface > must be checked to prevent IP-spoofing. Dst-IP sometimes is used for > p2p-channels. >>> >>> These rules can be replaced with such construction: >>> allow src-ip table(1) MAC any tablearg[1] recv tablearg[2] dst-ip >>> tablearg[3] >>> >>> But I don't think indexing by value is a good idea. I think >>> index==starting byte is a better way: >>> allow src-ip table(1) MAC any tablearg:0 recv tablearg:6 dst-ip >>> tablearg:32 >>> where MAC's 6 bytes are from 0 to 5 in tablearg; iface string is >>> from 6 and till \0, but less than 26 bytes; and IPv4's 4 bytes are >>> from 32 to 35. >> >>> So we need to create table for it: >>> table 1 set MAC:0 string:6:26 ip:32 >>> table 1 add 1.2.3.4 11:22:33:44:55:66 vlan1234 1.1.1.1 >>> >>> String can be used both for iface and comment. >>> Other possible value types: >>> uint16 for nat, pipe, skipto and other 2-bytes actions >>> IPv4 4 bytes >>> CIDRv4 5 bytes >>> IPv6 16 bytes >>> CIDRv6 17 bytes >>> table_id 2 bytes - link to another table >> Well, it seems we have enough space to store most of these, however, >> problems seem to remain the same: typing and compatibility. >> When you're creating new table (or it is auto-created) which values >> types should be assumed ? All of them? > Default - as usually uint32. I can't see "uint32" value in the list you have specified before. I'll rephrase: what value types (from the list above or similar) should ipfw(8) or kernel fill in case of "default" table? (And once again, what should we print as value) ? Please think about a) old ipfw binaries b) new ipfw binaries using exactly the same ruleset they are already using (with, for example, both "skipto tablearg" and "fwd tablearg " tables). >> What should `ipfw table X list` show as "value" field ? > I added table "header" in this line: > table 1 set MAC:0 string:6:26 ip:32 I don't think that user should be able to set any offsets in userland. Exact offsets of variable of given type needs to be enforced by kernel, so you may fill that you want "mac" and "ip" as values for given table, but not lengths or offsets. > So `ipfw table X list` should show something like this: > ---table(0)--- > 1.2.3.4/32 11:22:33:44:55:66 vlan1234 1.1.1.1 > We can also add "header" description in output (with or without > additional parameter - depends on compatibility needs) like this: > ---table(0)--- addr MAC iface IPv4 >> How should ipfw(8) treat "add 1.1.1.1 0" input? > It should look at table "header" and return error message like "Value > doesn't match table header" >> What will happen if we want to add another type field to this list? >> (MAC address of Infiniband MAC address, for example). > I don't think there is a sense to mix both MAC[6] and MAC[20] values > in 1 table. It is easier to create 2 tables with different "headers". > For Infiniband we can add another type: MAC20 (or something like > this). Or we can use "MAC"-type like string type(see above): MAC:6:25 > (1st and last bytes, or 1st and length). >> >>> >>> Table value length can be set for example with loader tunable like >>> net.inet.ip.fw.table_value_length. >>> Even with default uint32 value length we can get 2 uint16 values or >>> 4 uint8 values, this can help in some configurations. >>> >>> This way is more complex, but much more flexible. It's like netgraph >>> subsystem. >>> I think it suites both Alexander and Luigi requests. >>> >>> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 15 16:40:20 2014 Return-Path: Delivered-To: freebsd-ipfw@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 2205480E for ; Fri, 15 Aug 2014 16:40:20 +0000 (UTC) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E06F027F8 for ; Fri, 15 Aug 2014 16:40:19 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id a141so1832586oig.23 for ; Fri, 15 Aug 2014 09:40:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=69EVvCJEooLRxNxKB3EIageqalelt/v9XwfuMRZfA+8=; b=LhnSkgjpKP5EMEe1z7VcgQCyUxRFSXfQ0poae8RRDxVlncG3ZdhBzjw9K/5RD4QhlC wlZ5B53Jcyu++Eq55pY0XB4SohjST0OsOZXuJrEI0GOCXtpxbAjST0Or8ciSqitrTyPG KXGm7z8xQowhiyBQdKzy6uKezY5+jKZZM34BRgGfartnnEAxLQgKw/it8M3pcfchjKDg WSW5DQsyACT/Aj8vSwgYYRPY11/5KkOFrKpbM/89Wxfi/+vDhzeaJtPe6vOtht6qzy31 waWl7lenwNqon/ODU9AnYpa/jqjfSrZpyy1RxahpiUR9spAcvniHvcySZa16z93oL6VU POFw== X-Gm-Message-State: ALoCoQm0/SV51g3ddCcv7BUdX9sgwLQQRsR3w+XxXYX9X0kqE7AS75slpb5D/zWgcLm7k6mjFgTb MIME-Version: 1.0 X-Received: by 10.60.135.37 with SMTP id pp5mr21196811oeb.54.1408120813075; Fri, 15 Aug 2014 09:40:13 -0700 (PDT) Received: by 10.60.120.37 with HTTP; Fri, 15 Aug 2014 09:40:13 -0700 (PDT) In-Reply-To: <53EBC750.1050203@yandex-team.ru> References: <53EBC750.1050203@yandex-team.ru> Date: Fri, 15 Aug 2014 09:40:13 -0700 Message-ID: Subject: Re: [CFT] new tables for ipfw From: Michael Sierchio To: "freebsd-net@freebsd.org" , freebsd-ipfw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:40:20 -0000 On Wed, Aug 13, 2014 at 1:15 PM, Alexander V. Chernikov wrote: > I've been hacking ipfw for a while and It seems there is something ready = to > test/review in projects/ipfw branch. =D0=9E=D1=82=D0=BB=D0=B8=D1=87=D0=BD=D0=B0=D1=8F =D1=80=D0=B0=D0=B1=D0=BE= =D1=82=D0=B0! Thanks so much. Copious examples will be helpful - the ipfw man page is already too huge, and ipfw merits an entire guide on its own, with examples. I'm volunteering, but the new features will be - well, new. - M