[libvirt] dhcp6, radvd, ip6tables, etc.

[Gene Czarcinski]

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?

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.

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.

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.

Gene