[ On Tue, May 13, 1997 at 15:01:59 (+0100), Philip Hazel wrote: ]
> Subject: File-based net lists
>
> 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.
Hmmm... and for smail too! ;-)
[I recently added patches from Gray Watson that implement a list of
networks from which remote SMTP relay is allowed: smtp_remote_allow.
His patches supplied a match_ip() function that instead of a mask allows
only wildcard matching on the dotted quad.]
> (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.
Binary search works OK with the wild-card matching, assuming you can
properly sort the list, but is probably impossible for the netmask or
"/BITS" representations, at least in their ASCII form.
> What I have implemented today, because I think it will be useful anyway,
> is the ability to give a file name instead of a network specification in
> a netlist. The file is then read, and each line interpreted as if it
> were an item in the list. The reading happens each time the list is
> scanned, so the file can be changed without restarting the daemon.
That's about as far as I've got too....
> Does anybody think I should be doing more than this, and if so, have you
> any bright ideas as to how to specify it? I don't want to do anything
> like inferring Class B or Class C networks from IP addresses, because
> this doesn't carry over to IPv6.
Well, there are efficient algorithms for searching through network
addresses -- routing algorithms.
The actual bitmask representing the network address should be relatively
easy to use as a key.
Both of these mechanisms probably preclude using an easy to administer
ASCII file of course (except as input to a db creation routine)....
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
