On Sat, 30 Jul 2016 11:17:13 -0300, Dr. Rolf Jansen wrote: > I finished the work on CIDR conformity of the IP ranges tables > generated by the tool geoip. The main constraint is that the start > and end address of an IP block given by the delegation files MUST BE > PRESERVED during the transformation to a set of CIDR records. This > target is achieved by: > > 1. Finding the largest common netmask boundary of the start address > utilizing > int(log2(addr_count)); then iteration like Euclid's algorithm in > computing > a GCD. > > 2. Output the CIDR with the given start address and the masklen belonging > to the found netmask. > > 3. If the CIDR does not match the whole original IP range then set the start > address of the next CIDR block to the next boundary of the common > netmask, > and loop over starting at 1. until the original range has been satisfied. > > I carefully tested the algorithm and a table that I pipe by the new > geoip tool into ipfw is 100 % identical to the output of the ipfw > command 'table N list'.
Great. I suppose that caters for some of the odd delegations one sees, such as perhaps a /16 then a /15 (ie 3/4 of a /14) followed by maybe a /12, maybw with another /15 tacked on the end .. but I'm unsure if that applies to country allocations as much as it does within countries. > It is worth to note, that already the original RIR delegation files > contain 457 non CIDR conforming IPv4 ranges in a total of 165815 > original records. I guess that this number will increase in the > future because the RIR's ran empty on new IPv4 ranges and are urged > to subdivide returned old ranges for new delegations. The above > algorithm is ready for this. Yes, and just as well. I'm surprised it's as few as 457 .. I looked into it a bit back when 115.70/17 was first allocated to my ISP, after previously having been, as I recall, in China .. so of course we fell foul of a number of (probably perennially) out-of-date geoip blockers, for months in some cases .. malevolent beasts if not kept well fed :) > Generally, CIDR conforming tables are more than twice as large as > optimized (joined adjacencies) IP range tables. All said changes have > been pushed to GitHup already. So how many table entries does 'the world' come to, around 400,000? > I am still a little bit amazed how ipfw come to accept incorrect CIDR > ranges and arbitrarily moves the start/end addresses in order to > achieve CIDR conformity, and that without any further notice, and > that given that ipfw can be considered as being quite relevant to > system security. Or, may I assume that ipfw knows always better than > the user what should be allowed or denied. Otherwise, perhaps I am > the only one ever who input incorrect CIDR ranges for processing by > ipfw. You've lost me here, Rolf. Do you mean that ipfw adds incorrect table entries for a given IPv4 address and mask length? Or that it c/should itself accept IP ranges and generate the needed CIDR entries to match? If the former, how to reproduce for a bug report? If the latter, might you contemplate adding that functionality to ipfw - or is ipfw better off being driven to generate tables from the output of such as geoip? cheers, Ian _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[email protected]"
