From owner-freebsd-ipfw@freebsd.org Fri Jul 29 08:54:08 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C0F7BA7345 for ; Fri, 29 Jul 2016 08:54:08 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2170019A2 for ; Fri, 29 Jul 2016 08:54:07 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1469782444; l=2394; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=dEiTR4QavjrH88BBHMK/iw2Wo1O2Ur0JxcsTIJrCMd0=; b=BVFvJ3N2cDRUxsPVSZ6ByWfoavEyp0iOVncNcIV5jds616pf80rnzkB4dj+WGwNUUA/ GmbtSnT53ldPNDZJ+0opUCaX4B7oIREKVXSpdPv2+FWpwXIZrwdprNBht1ozJpudqvsRu ljYezY4XcYWci+hcXl+iL3J6O2nlthztV9E= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2BqlKi/2sgPrOHjSDsnQ= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bd1d9e9f.virtua.com.br [189.29.158.159]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id 601786s6T8s2sB0 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 29 Jul 2016 10:54:02 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id B8737229861E for ; Fri, 29 Jul 2016 05:53:59 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ipfw divert filter for IPv4 geo-blocking From: "Dr. Rolf Jansen" In-Reply-To: Date: Fri, 29 Jul 2016 05:53:58 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> To: freebsd-ipfw@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 08:54:08 -0000 > Am 28.07.2016 um 23:48 schrieb Lee Brown : >=20 > That makes sense to me. Your /20 range encompasses 201.222.16.0 - > 201.222.31.255. > If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges: >=20 > 201.222.20.0/22 (201.222.20.0-201.222.23.255) > 201.222.24.0/22 (201.222.24.0-201.222.27.255) > 201.222.28.0/22 (201.222.28.0-201.222.31.255) Ian, Julian and Lee, Thank you vary much for your responses. In order not bloat the thread, I = answer only to one message. I found the problem. As a matter of fact, the respective IP ranges in = the LACNIC delegation statistics file are 3 adjacent blocks with 1024 = addresses, i.e. those that you listed in your message above: $grep 201.222.2 /usr/local/etc/ipdb/IPRanges/lacnic.dat lacnic|BR|ipv4|201.222.20.0|1024|20140710|allocated|164725 lacnic|BR|ipv4|201.222.24.0|1024|20140630|allocated|138376 lacnic|BR|ipv4|201.222.28.0|1024|20140701|allocated|129095 However, my database compilation combines adjacent blocks with the same = country code, and the ranges above turn into one block of 3072 = addresses, which obviously doesn't have a valid netmask - log(3072) =3D = 11,5849625. My divert filter daemon is agnostic about this, because the = exact ranges are stored in the database and for the purpose of country = code lookup the address lookup routine doesn't need to work with = netmasks. I choose it this way, because I read some RIR documentation = stating that delegated address blocks are not necessarily complete CIDR = ranges. Even if the above ranges conform to CIDR, future delegations may = be different, and I wanted to stay on the safe side. So far so good. Now, the actual problem with ipfw tables in the given = context is that explicit IP ranges are not accepted but ranges must be = given in CIDR notation, and I simply forgot about the tiny detail that = CIDR is inherently granular, and that this may of course conflict with = my CC/IP database optimization strategy. Without combining adjacencies, = the complete database has 165815 instead of 83274 records. Perhaps, I = add an option to the db tool for CIDR conformity. In this respect, it is = not sufficient to forget about optimization but I need to check also = whether, the delegation files contain already some non-CIDR ranges, = which needs to be broken down. Best regards Rolf