7:26 a.m.
On 10/27/2012 03:18 PM, Gene Czarcinski wrote:
OK, I have the basic implementation for libvirt support of dhcp6. Let
me say again that 98% of the work was already done. There is still a
bunch of work today which includes writing some tests, understanding
how things such as bootp, dhcp-host, etc. should be supported with
dhcp6, as well as the items I discuss below.
1. Right now, the only way that dhcp6 is in effect is if there is no
dhcp4 range definition. This will be fixed/expanded so that, at a
minimum, you can have both a dhcp4 and dhcp6 on the same interface.
However, it appears to be easier to just pass to dnsmasq ANY/EVERY
dhcp4 range or dhcp6 range defined in the xml.
Comments? Any input on which approach to use or avoid?
For the current situation,
the implementation is for one (the first)
IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough little
gotchas that need to be worked out.
2. I have modified radvd so both stateful (dhcp6) and stateless
(SLAAC) addressing is supported with radvd for the default route. This
is done on an interface basis (that is the way it works). So if any
dhcp6 range is specified, then stateful is used. The way this is
implemented will make it easy to add some tests verifying that the
configuration parameters are working. I intend this to be an
expansion to networkxml2argvtest since it has the xml specification
files which determine both dnsmasq and radvd configuration parameters.
NC ... working fine.
3. After completing what I thought was code that should result in a
guest getting dhcp6 addresses, it was not working. Once more it took
me a little time to realize that ip6tables rules were blocking it. [I
have been down this path before, you would think I would realize the
problem sooner.]
3a. In looking over the ip6tables rules, I saw a whole bunch of
additions at the top of the INPUT chain which were accepts for udp/tcp
port 53. In looking at the code in bridge_driver.c, I found that,
every time a network device was started, 3 FORWARD rules and 2 INPUT
rules were added, but, when the network device was destroyed, only the
3 FORWARD rules were removed. I believe this is a bug (but not high
priority) and I will be submitting a separate patch to fix this.
3b. There are two different approaches for the rule which allows the
dhcp6 server to work. I could add (actually insert) one rule to the
INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport
547". Or, I could add (insert) a rule specifying "-i virbr__" for
every IPv6 device which would be removed when the device was destroyed.
OBE - I
chose the approach of adding (and removing) a rule per
interface. The rule adds "--dport 547" but does NOT specify "-d
ff02::1:2". This works With the radvd configuration and a dhcp-range
specified for a ipv6 subnet, a guest will get a dhcp6 address and RA
default route.
4. After getting all of this working to my satisfaction, my next
mountain to climb is VM ... it really does not like network xml
definitions which include a dhcp-range for an ipv6 definition.
Comments?
NOTE: I am implementing all of this assuming that my previous patches
have been accepted ... the ones for creating a dnsmasq conf-file for
parameters rather than using the dnsmasq command-line.
I am sure that someone could spend the time refitting the dhcp6
patches to the old code but why get aggravated? If you folks do not
want to do things that way, fine, please say so. But if it is going
to be accepted, then I would like some indication of this.
5. As far as I can tell
(or at least this is for dnsmasq),
"dhcp-no-override", "enable-tftp", "tftp-root=", and
"dhcp-boot=" are
all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not
looked to see what network_conf.c does.
6. Handling of the info for addn-hosts file and the dhcp-hostsfile.
This currently works because things are forced so that one and only one
IPv4 dhcp definition will be handled. With the addition of IPv6 dhcp,
things fall apart.
6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file
in both form and function. The <dns>-<host> specification is done on an
interface bases and, thus, the processing of the data and creation of
the file should only be done once.
6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for
every ip definition that is processed for dhcp. Initially, this will be
for dhcp4 only until I can figure out how to do it for dhcp6.
6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two
functions [one for addn-hosts and one for dhcp-hosts]. Additionally, all
the functions which call dnsmasqSave() need to be reworked appropriately.
7. So far, the only things I have done involving the xml specification
is to enable <dhcp> for IPv6. However, the xml to specify a dns
addn-hosts appears, IMHO, to be overly verbose and complicated. So,
while allowing the current xml to be valid, I suggest adding an
alternate form for which is similar to that used for dhcp-host. An
example is "<host ip='1.2.3.4' name='one' />"
Comments, suggestions, etc. still appreciated.
Gene