Bug 186322

Agreed, this has been on my to-do list for some time now; but NM also has to
handle IPv6 addresses and options, and request an 'ipv6_up' from dhcdbd .
Also NM must handle configuration of nameservers with IPv6 addresses - this
is already supported by the bind named d-bus support.

One point to note is that Ted Lemon of the ISC / Nominum (our upstream dhclient
source) is developing a new dhclient that fully supports both DHCPv6 and D-BUS
natively - this will be the way to go for the future, but it remains to be seen
whether this will be ready for FC-6. 

In any case, I'll get dhcdbd or its ISC replacement IPv6 ready for FC-6 .

We need this as early as possible so we can start integrating it into anaconda
for FC6.  Please let us know when you have experimental versions you'd like to
get tested.

I've now split this bug in two:

1. After discussion with the bug reporters, this bug really covers only
   DHCPv6 /IPv6 support for anaconda, and a replacement for the pump
   dhcp library currently used by anaconda.

2. I've cloned this bug as bug 187775 to cover needed enhancements to 
   dhcdbd and NetworkManager to provide NM IPv6 support.

The anaconda pump replacement turns out to be much more straightforward 
than I guessed initially - it should be complete within one week.

I now have a test program using the ISC dhcp and dhcpv6 packages compiled into a
shared library, that is able to do DHCP and DHCPv6 client sessions in a single
process .

I am now working on developng pump API replacement with calls to this library,
and will develop a minimally modified version of anaconda's loader2/net.c that
uses itto get both IPv4 and IPv6 addresses with DHCP and DHCPv6 - this should 
be ready for anaconda testing within one week.

Jason -- any updates here?

Yes, while I haven't been able to devote as much time as I would have liked
to this over the past couple of weeks, I do have a test program working with
library versions of dhcp and dhcpv6, and hope to complete the anaconda/net.c
port to use them within the next week or so - I am currently working on this,
and I'll update this bug when done.

Jason,

Ping.  Any updates now?

Thanks,

David

I will ensure that the work is complete by the end of this week - I'm currently
working on it as my top priority.

There will be new 'dhcp-devel-libdhcp4client' and 'dhcpv6-devel-libdhcp6client' 
subpackages of dhcp and dhcpv6, and a new 'libdhcp-' package that will use
them and the 'libnl' netlink interface package currently in FC to provide a
complete network configuration  library, with an interface very similar to 
that of libpump.

I now have the libdhcp4client and libdhcp6client work mostly complete, have a 
working test program that uses them to do DHCPv4 and DHCPv6 sessions in the same 
process, and have almost completed the libdhcp network configuration library,
and am now  putting them altogether and working on the modifications to 
loader2/net.c to use them.

NOTE: one thing that became apparent during testing, is that you do not need
a dhcpv6 client to use an automatically configured IPv6 interface ; all you 
need is to have the radvd daemon running somewhere on your network, and then 
the kernel will automatically configure the interface with IPv6 addresses on
the radvd advertised prefixes when they are brought 'UP' - no user space address 
assignment need be done by the client. I suggest having an 'IPv6 network uses
radvd' setting or some such to avoid requiring users to set up a dhcpv6 server.

I am very sorry it has taken so long to get a working version of this library
together - but now it is here:
   http://people.redhat.com/~jvdias/libdhcp
   CVSROOT=':ext:rhlinux.redhat.com:/usr/local/CVS' cvs co libdhcp
   CVSROOT=':gserver:U.redhat.com:/cvs/devel' cvs co libdhcp
and ready to build in beehive.

The README file in the source tarball provides sufficient description of the API
to get started, and I'm now finishing off the Doxygen documentation.
Also, today I'm submitting a 'libdhcp/pump.h' that will provide an almost 
identical API to that of pump.

I hope it is not too late to be of use -

Regards,
Jason.

Please also see:
  http://people.redhat.com/~jvdias/libdhcp/README
(the readme file from the source tarball).

Created attachment 130042 [details]
Patch against latest anaconda-11.1.0.21 source to make loader2 use libdhcp

There is now a slot-in pump replacement header file and a pump-compatible API 
in libdhcp-1.2 . 

Please check out the 'test_pump_static.c' and 'test_pump_dhcp.c' in the
/usr/share/doc/libdhcp-1.2/examples directory from the libdhcp installation
for examples of using the pump compatibility API - just type 'make' in that
directory to build them. Running them under valgrind reports 0 errors or
memory leaks.

The first stab at the Doxygen documentation is now shipped in 
/usr/share/doc/libdhcp-*/html - this is still work in progress,
and I hope to submit updated Doxygen documentation later today.

Here is a patch against the latest anaconda-11.1.0.21 source to allow loader2
to compile and link with libdhcp .  The one missing piece in the current FC-6
distro is a static /usr/lib/libnl.a - I've mailed Chris Aillon a patch to 
make libnl build a static version of itself in libnl-devel, and I hope to get
this built later today.

If using libnl is a major stumbling block, removing its use altogether from
libdhcp would not be difficult - libdhcp only uses the lowest level libnl API
for raw message building / sending - I removed any use of the libnl cache from
libdhcp to avoid the memory leaks and valgrind errors that resulted. 
But having libnl support in libdhcp I think is a good idea since it allows 
users to do much more with libdhcp, eg. set queue disciplines / firewall rules
that are not catered for by libdhcp alone.

libdhcp is now in Fedora Core, and so I guess this bug should be in 'MODIFIED'
status.

Closing this bug since it's "working" in rawhide.