Date: Fri, 29 Jul 2016 17:50:19 +0800 From: Julian Elischer <julian@freebsd.org> To: "Dr. Rolf Jansen" <rj@obsigna.com>, freebsd-ipfw@freebsd.org Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <c62fa048-63c8-aef6-5bad-b0a6719f6acb@freebsd.org> In-Reply-To: <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <CAHu1Y739PvFqqEKE74BjzgLa7NNG6Kh55NPnU5MaA-8HsrjkFw@mail.gmail.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <c2cd797d-66db-8673-af4e-552dfa916a76@freebsd.org> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <C0CC7001-16FE-40BF-A96A-1FA51A0AFBA7@obsigna.com> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <CAFPNf59w6BHgDjLNHW=rQckZAFG4gqPHL49vLXiDmMAxVPOcKg@mail.gmail.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <leeb@ratnaling.org>: >>> >>> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c62fa048-63c8-aef6-5bad-b0a6719f6acb>