> Am 03.08.2016 um 11:13 schrieb Julian Elischer <jul...@freebsd.org>: > > On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer <jul...@freebsd.org>: >>> >>> looking for thoughts from people who know the new IPFW features well.. >>> >>> >>> A recent addition to our armory is the geoip program that, given an address >>> can tell you what country it is in and given a country code, can give an >>> ipfw table that describes all the ip addresses in that country. >>> >>> SO I was thinking how to use this, and the obvious way would be to have a >>> set of rules for each country, and use the "skipto tablearg" facility to >>> skip to the right rules for each country. But the trouble is that a >>> tablearg skipto is very inefficient. It's also a hard thing to set up with >>> a set of rules for each country (how many countries are there in the >>> internet allocation system?). >> >> As of today a total of 236 country codes are in use for IPv4 delegations. If >> this helps for anything, a command line switch to the geoip tool could be >> added for letting it output the country code (as the hex encoded CC taken as >> a plain decimal integer) as the value for the given table entry. In the >> moment you can give one value for all entries generated by geoip, with this >> switch set, the output of geoip could look like: >> >> $ geoip -t "DE:BR:US" -x >> ... >> table 0 add 93.157.48.0/21 4445 >> table 0 add 93.158.236.0/22 4252 >> table 0 add 93.159.96.0/19 4445 >> table 0 add 93.159.248.0/21 4445 >> table 0 add 93.180.72.0/21 4445 >> table 0 add 93.180.152.0/21 4445 >> table 0 add 93.181.0.0/18 4445 >> table 0 add 93.183.0.0/18 5553 >> ... >> >> Given that ... >> 0x4445 = 'DE' >> 0x4252 = 'BR' >> 0x5553 = 'US' > > well it would have to be the decimal value so DE would be 6869, as while 4445 > works 444F is a problem :-)
Yes, you're right, I was taken away by the wave of enthusiasm, before thinking about the subject up to the end. > 0x444F would work but we waste even more address space. You'd have to > multiply the numbers by some scaler, because adjacent numbers would not be > enough for one rule to do something and another rule to skip on to somewhere > else. (well, you could have multiple rules at the same number but that has > its limitations. > The idea would certainly work. it would mean setting aside all the rules > between 6565 and 9090 however. > A more compact encoding could be something like ((name[0]-'A') * > 32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and offset > by a given offset. > > so AF (Afghanistan) would be the first 0*32+5 * 10 would give an offset of > 50.. plus a user supplied offset turns it into say, 15050.. I understand the reasons, however, any complicated encoding will defeat the idea of the value can be sort of numeric mnemonic for the country code – well, so it is. I elaborated on your idea and came-up with the following formula: val = (C1-60)*1000 + C2*10 + offset. The offset can be given as the parameter to the -x flag. $ geoip -t "DE:BR:US" -4 -x 30000 ... table 0 add 93.157.48.0/21 38690 table 0 add 93.158.236.0/22 36820 table 0 add 93.159.96.0/19 38690 table 0 add 93.159.248.0/21 38690 table 0 add 93.180.72.0/21 38690 table 0 add 93.180.152.0/21 38690 table 0 add 93.181.0.0/18 38690 table 0 add 93.183.0.0/18 55830 ... The limits (without offset) are: AA = 5650 -- actually AD = 5680 ZZ = 30900 With this formula, the offset must be less than 34735. Although, this wastes a considerable amount of rule number space, the advantage is that the numbers are still accessible by mental arithmetic, and the other constraint of having a step > 1 is fulfilled as well. Anyway, this one is not graved in stone, we can agree on another one. > or there could be a translation into iso3166 numeric codes where Afghanistan > is 004, but then you have the worry of keeping the data up to date as they > add new country codes, which in my opinion makes it a bad solution. Agreed, too much dependencies, let's forget the numeric iso codes. BTW: The ipdb tools are now IPv6 aware. $ geoip 2001:1900:2254:206a::50:5 2001:1900:2254:206a::50:5 in 2001:1900:0:0:0:0:0:0 - 2001:1900:ffff:ffff:ffff:ffff:ffff:ffff in US $ geoip -t "DE:BR:US" -p ... ... 217.194.64.0/20 217.194.224.0/20 217.195.0.0/20 217.195.32.0/20 217.197.80.0/20 217.198.128.0/20 217.198.240.0/20 217.199.64.0/20 217.199.192.0/20 217.224.0.0/11 2001:400:0:0:0:0:0:0/32 2001:408:0:0:0:0:0:0/32 2001:418:0:0:0:0:0:0/32 2001:420:0:0:0:0:0:0/32 2001:428:0:0:0:0:0:0/32 2001:430:0:0:0:0:0:0/32 2001:438:0:0:0:0:0:0/32 ... ... $ geoip -t "" -p | wc -l 137097 For processing only IPv4 addresses, add the -4 switch (this reproduces the old behaviour) $ geoip -4 -t "" -p | wc -l 106637 For processing only IPv6 addresses, add the -6 switch $ geoip -6 -t "" -p | wc -l 30460 106637+30460 = 137097 After running 'make install' of the new version, the IP database needs to be updated using the ipdb-update.sh script. This will now generate two binary database files (*.v4 and *.v6). 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-unsubscr...@freebsd.org"
