Philip Hazel <ph10@???> wrote:
>There have been some requests for the ability to hold lists of networks
>in separate files, instead of having to have large lists in the config-
>uration file.
>My first plan was to try to arrange for some kind of lookup item, along
>the lines of the facility in host lists, but I got defeated because of
>the problem of masks. I suspect that the sort of files people actually
>want will have entries along the lines of
>131.111.0.0/255.255.0.0
>203.111.56.0/255.255.255.0
>5f03:1200:836f::/48
>(the last one being an IPv6 address with a 48-bit mask, and yes, I will
>provide this masking syntax for v4 addresses too). In other words, the
>requirement will be for each item to have its own mask. Given this, I
>cannot see any way of setting up any kind of keyed database lookup,
>because you don't know what mask to apply to the subject address before
>looking it up.
How exactly you want to do this is probably dependant on the size of lists,
but heres a few ideas that might spark of some more ideas :-)
1. Implement it in a way similar to partial-dbm, ie try a series of masks
on the address until one matches (eg address/8, address/16, address/24)
if you could specify the start, end and step this should satisfy most
peoples requirements. You would have to either force either /num or /mask
format or preprocess the file for this to work reasonably
2. With the netmasks sorted (okay you may not be able to mix IPv4 and IPv6)
a binary search will get you to the key, the key before or the key after
the one you want (assuming you want a multiple of 8 or 16 for IPv6). For the
likes of "sender_net_reject" this could be read on first use, kept internally
in an easy to search binary format and looked up on each connection.
3. Store in dbm format key'd on the first octet only, then treat the result as
a list of netmasks to check (this should reduce the search by a factor of 10
or 20), for IPv6 you'd probably want to store on the 1st 1 octets. This of
course assumes a mask of at least 8 or 16.
I'm not however convinced that any of the above suggestions end up
significantly (or any) quicker than a simple linear match, except perhaps
for large netlists (how big *do* peoples netlists get??)
--
Brian http://www.wonderland.org/~eternal/
