TODO

                       NOTE WELL
                       =========

	*NONE* of the items are being actively worked on.
        So, if you're interested in one of these features,
        it means you'll have to submit a patch... :-)


read list of interfaces with SIOCGIFCONF (AF_INET6 support in the kernel would
be nice) or from /proc

support for few protocol constants defined in RFC 4861 Sec 10 is missing.

consider whether UnicastOnly flag should be detected by radvdump.

The following parts of RFC4861 are not implemented:
 - section 6.2.5: when AdvSendAdvertisements changes to FALSE, we don't send 
   a final RA with zero Router Lifetime (we just send it when shutting down).
   (SHOULD)
 - section 6.2.8: if the link-local address of the router changes, it should
   multicast a few RAs from the old address with zero router lifetime, and a
   few from the new address. (SHOULD).

Consider whether to support RFC 4286 (Multicast Router Discovery).

Consider whether to support multiple IPv4 addresses with Base6to4Interface
(currently the code just picks one).

Consider whether to support multiple prefixes and routes with a single
configuration line (instead of having to specify each prefix/route
separately) somewhat similar to how RDNSS configuration already supports.

Consider whether to support a generalization of Base6to4Interface for
arbitrary IPv6 prefixes, to be used for automatic generation of downstream
prefixes.  Also consider whether this would need to support multiple IPv6
prefixes on the upstream interfaces.  See question 3 in README for more on
this.

Use getifaddrs() instead of ioctl SIOCGIFADDR and other friends.  The
problem with this is that e.g. RHL73's glibc didn't support getifaddrs(),
and before glibc 2.3.3 getifaddrs() didn't use netlink so it didn't work
well with IPv6.  These old compat concerns are likely moot now..

Implement Secure Neighbor Discovery (RFC 3971).

Interface reconfiguration is only supported on Linux.  Consider whether to
support that (and privilege separation as a result) on BSD as well.

The restrictions of the (privilege separation) master process could
be restricted as currently it basically only needs to write to /proc,
do some logging and nothing else.

Triggered by: https://bugzilla.redhat.com/show_bug.cgi?id=554125
Known problems (probably can't do anything about these):
 - If interface MAC address changes, radvd will keep sending the old MAC
   in its LL option (until HUP signal).  The kernel will keep sending
   Ethernet frames with the old MAC until interface is flapped.
   More: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508466

AdvRASolicitedUnicast: Further improvement is possible.
- If we get a RS and are about to send a multicast RA, then we can further save
  battery on the client device by NOT sending a unicast response, and just
  letting the client wait for the multicast response. This should be
  implemented as a new time value, specifying the maximum amount of time
  remaining to as a deciding factor between send-solicited-RA-now vs
  wait-for-next-multicast.
- The above can also form part of rate-limiting of unicast RA responses when
  network topology has recently changed.

The following parts of RFC7222 are not yet implemented:
- Section 5.1.3: Networks that serve battery-powered devices SHOULD NOT send
  multicast RAs too frequently (see Section 4) unless the information in the RA
  packet has substantially changed.  If there is a desire to ensure that hosts
  pick up configuration changes quickly, those networks MAY send frequent
  Router Advertisements for a limited period of time (e.g., not more than one
  minute) immediately after a configuration change.