Red Hat Bugzilla – Bug 186322
add support for IPv6 and DHCPv6 and provide pump replacement for anaconda
Last modified: 2013-01-09 22:41:52 EST
It would be nice for dhcdbd to support IPv6, as that would go a long way to
having support for the same in NetworkManager. We'd like to make NetworkManager
the default in anaconda and IPv6 is a big feature for the next release, so this
would help us out a lot.
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
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
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.
Ping. Any updates now?
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:
CVSROOT=':ext:rhlinux.redhat.com:/usr/local/CVS' cvs co libdhcp
CVSROOT=':gserver:U@cvs.devel.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 -
Please also see:
(the readme file from the source tarball).
Created attachment 130042 [details]
Patch against latest anaconda-18.104.22.168 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
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-22.214.171.124 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'
Closing this bug since it's "working" in rawhide.