TODO

* Review entire server code line-by-line to find any security
holes that can be exploited by client sending us bad data.
E.g. most likely buffer overruns.

* Currently we assume that a single ethernet address (or
equivalent cliid) may only appear in a single entry in bootptab.
We use that value as a key to what we expect will be a single
entry.  (We expect that when we do a lookup in bootptab by
hardware address, client id, IP address, or entry name, we'll
get back either a single entry, or no entry...NOT multiple entries.)
What if we want to be able to assign multiple IP
addresses to one hardware address (with the multiple IPs
each being on different IP subnets)?  Major revision to
data structs, access, etc. to support getting multiple entries
back, then we choose the appropriate one (if any) to hand to
client based on client's present location.  

* Related to last item, some clients use same enet address
on multiple physical interfaces (e.g. Suns).  Can we support
having multiple simultaneous bindings for the client?
This would require more than the item above to work -- we'd
also need to change a binding so that it the key isn't
the cliid, ip, or hostname, but instead is a subnet identifier
concatenated with the cliid, ip, or hostname.  That way the
same device can have multiple simultaneous bindings on different
subnets (no more than one per subnet at a time, though).
That's in keeping with the RFC, which says that bindings are
identified by cliid concatenated with subnet identification.

* Add code to detect if server is already running so second
copy exits.  Two servers running can corrupt bindings directory.

* Improve portability.  Make better use of autoconf to learn
system's capabilities.

* We are not deaemonizing entirely as recommended in latest
edition of W. Richard Stevens' books.

* WinNT, Win98 Second Edition clients can put option 0 in Parameter Request List
options (PAD).  At high enough debuglevel, we complain; we
should silently ignore it.

* chaddr is not being printed when its value is all zeros.

* Add RFC2241 support (Novell Directory Services)

* Add RFC2242 support (Netware/IP)

* fix the DHCPINFORM code, which is presently commented out.

* The -U and -G options are not a complete solution to surrendering
root privileges, because even when we use them, we must still retain
real uid corresponding to root, to allow us to manipulate the IP ARP
cache and open a raw IP socket to perform IP PING.  It would be nice
to be able to surrender root entirely after startup; that would probably
require splitting these functions up into separate processes.

* See the "BUGS" section of the dhcpd.8 man page.

* At a high enough debuglevel, at startup we should log all of the settings we
are running with.  (I.e. the value of all possible commandline
options and args, whether or not they are specified, as well
any compile-time-only options (just LOG_FACILITY in the latter class).)
Do this after parsing commandline options and args, but before anything else.

* Add an option (e.g. -v perhaps) that just says to print the version
and the value of all compile-time options, then exit.

* Allow you to specify some DHCP options which will only be sent to the
DHCP client if the client asks for them in a DHCP Parameter Request List option.
even WHEN the :nr: option is specified in bootptab.  Presently, if :nr:
is not specified, then the server only sends DHCP clients a fixed set of
DHCP options, plus any the client specifically requests in its DHCP Parameter
Request List option.  The existing :nr: bootptab tag allows you to force the
server to send the client all the options that appear in its bootptab entry.
But there's no "in-between", to let you say "Always send these options regardless
of whether the client asks for them, but only send these options if the client
asks for them."

* The accessflags field in dhcpd.conf's "network" statement could use
some improvement.  The 'registerered' or 'roaming' flags don't provide enough
granularity.  Today you can use 'roaming' to indicate which subset of
bootptab clients may be assigned a dynamic address (those with the 'ro'
tag in their bootptab entries).  How about being able to define different groups,
so that each dynamic pool (defined by a different "network" statement) may
be made available to different (possibly overlapping) sets of clients?
This would require that you be able to define multiple groups of clients (e.g.
perhaps with something like :ro=groupname1 groupname2 groupname3: in bootptab),
then be able to indicate in the network's accessflags which groups are eligible
to use the pool (e.g. groupname1|groupname3).

* Add RFC 2485 support (Open Group's User Authentication Protocol Option)

* We have a portability problem in adding a broadcast route.
We have reports that main.c does not compile on IRIX 6.5.3, 6.5, NetBSD.
And on at least one Linux platform, although it compiles, it is unable
to add a broadcast route.  We assume that if net/route.h exists (and we're not 
running on AIX nor have you set the undocumented NOBROADCAST definition), then 
we should try to add a host route to 255.255.255.255 via my_ip_addr, using an 
ioctl().  We assume that struct ortentry rtentry (if it exists, else struct rtentry)
declared in net/route.h has a member named rt_dst, but it doesn't on all
systems. So we fail to compile. Or on some other systems, it compiles, but
cannot be executed. We need to enhance configure recognize systems on which this
is not the right way to add a route, and provide different code in main.c for
those systems. (This situation may have been improved in patchlevel 9.)

* We have a report that snmp/snmp_var.c does not compile on IRIX 6.5.3.
The snmp code has some portability issues that need to be addressed.

* If you wish to use dhcpcmd, presently you must edit the list of DHCP server
IP addresses into dhcpcmd.c.  This should at least be handled as a compile-time
option.

* If the host supports the IP_RECVDSTADDR socket option and the recvmsg()
function, then attempt to use them (instead of the usual recvfrom() function)
to obtain the destination IP address of received packets.  (We must check
for these at compile time, and also at runtime, using the older approach
if they are not available or appear to not work.  We must also provide
a runtime option to disable use of them, in case they appear to be available
and work, but actually do not work.)  Having the destination IP address of
received packets would allow us to more accurately determine the client's
DHCP state, in particular, to distinguish between RENEWING and REBINDING.

* Add RFC 2610 support (Service Location Protocol Options)

* Replace the data structure used to store 'generic tags' in the struct host.
Presently it stores all generic tags in a single vector containing the concatenated
(type, length, data) for each generic tag.  Replace this with a structure that
stores each generic tag individually.  

* Once the item above is done, we can easily fix the documented bug that generic
tags are not returned to DHCP-speaking clients that request them via a
Parameter Request List option (unless the bootptab entry has an 'nr' tag,
which forces all generic tags to be returned).

* Stop using a struct flags to track which options have already been inserted
into a reply packet.  Switch to using a struct Bitvector of size 256.  Once
we do that, we can avoid inserting generic tags that have the same option code
as a well-known tag already inserted.

* Reject any entry in bootptab file that contains a multicast hardware address.

* RFC 3118 (Authentication for DHCP Messages)
I presently have no plans to implement this.

* RFC 3203 (DHCP reconfigure extension)
I presently have no plans to implement this.

* RFC 3396 (Encoding Long Options) 

* RFC 3442 (Classless Static Route Option for IPv4)

* RFC 4039 (Rapid Commit Option)
