From owner-freebsd-ipfw@freebsd.org Fri Jul 29 09:50:30 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 7CC3FBA6130 for ; Fri, 29 Jul 2016 09:50:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F6321278 for ; Fri, 29 Jul 2016 09:50:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-233-115.lns20.per1.internode.on.net [121.45.233.115]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u6T9oOWq080360 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jul 2016 02:50:27 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org 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> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> From: Julian Elischer Message-ID: Date: Fri, 29 Jul 2016 17:50:19 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 09:50:30 -0000 On 29/07/2016 5:22 PM, Julian Elischer wrote: > On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: >>> Am 28.07.2016 um 23:48 schrieb Lee Brown : >>> >>> 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: >>> >>> 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) >> = 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. > there is code to take ranges and produce cidr sets. > > We used to have exactly that code in the appletalk code before we > took it out. Appletalk uses ranges. > https://svnweb.freebsd.org/base/release/3.2.0/sys/netatalk/at_control.c?view=annotate#l703 > though htat uassumes input in the form af an appletak sockaddr.. there is also this python module https://pythonhosted.org/netaddr/tutorial_01.html#support-for-non-standard-address-ranges > > maybe you can find other versions on the net. > however if you fully populate the table, you will get the correct > result because more specific entries will > override less specific entries. To do that you would have to have a > way to describe to your program what > value each table entry should output. > If you did what you do now, then you would specify the value for the > required countries, and give a default falue for "all others". > aggregation of adjacent ranges with same value would be an > optimisation. > > > >> >> Best regards >> >> Rolf >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >