[libvirt] Proposed: replace radvd with dnsmasq for Router Advertizing

Tue Nov 6 16:50:55 UTC 2012

On 11/05/2012 12:27 AM, Doug Goldstein wrote:
> On Sun, Nov 4, 2012 at 7:12 AM, Gene Czarcinski <gene at czarc.net> wrote:
>> On 11/03/2012 09:01 PM, Laine Stump wrote:
>>> On 11/02/2012 08:25 AM, Gene Czarcinski wrote:
>>>> I have been doing some testing and dnsmasq is capable of handling the
>>>> service currently provided by radvd.  To implement this in dnsmasq
>>>> requires the following:
>>>>
>>>> if an IPv6 dhcp-range is specified, then add:
>>>>         enable-ra
>>>>
>>>> if no IPv6 dhcp-range is specified, then add:
>>>>         dhsp-range=<IPv6-subnet>,ra-only
>>>>
>>>> Tested.  The second one will work with basic dnsmasq-2.6.3.  The first
>>>> one and dhcp-range itself only works with dnsmasq-2.64 (when released)
>>>> or dnsmasq-2.63+patches.
>>> Is this the proper support matrix?
>>>
>>>
>>> dnsmasq       RA       dhcpv6
>>> < 2.63        no       no
>>> = 2.63        yes      no
>>>> 2.63        yes      yes
>>> Meaning that radvd isn't needed for 2.63 and beyond, but you can't do
>>> dhcp6 until 2.64, right?
>> Not really.  It does require two small patches be applied to dnsmas-2.63 ...
>> on ads 14 lines of code and the other about 22 lines of code.  Without the
>> patches (just running dnsmasq-2.63 for example), it can be rightly claimed
>> that that dnsmasq supported dhcp-range dhcp-host for IPv6 ... it does work
>> ... just not for libvirt.
> Relying on some magical formula saying that 2.63 + patches is good
> enough is going to be flawed and lead to tons of support problems.
> Unless you add the ability to query for that feature set then this is
> a non-starter.
>
>> The two problems fixed are:
>>
>> 1. Using the same solution that is used for IPv4, allow sharing of the
>> address for multiple instances of dnsmasq.
>>
>> 2. Fix the dnsmasq DHCPv6 packet filtering so that valid DHCPv6 requests are
>> processed even if "interface=" was not specified.
>>
>> I have redone my two patches so that they are now the same as Simon Kelley's
>> in dnsmasq-2.64 (I am currently running dnsmasq-2.64test7) and I have
>> submitted a Fedora RFE to have dnsmasq-2.63 updated with the patches:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=867054
> I would personally NACK that as you're changing the behavior of a
> shipped version without changing a version number.
>
>> I would appreciate any influence any of you folks may have to get that
>> accepted.
>>
>> BTW, one aspect of all of this is that NetworkManager also needs updating so
>> that it will send the correct request to dnsmasq for DHCPv6 and dynamic dns
>> updating.  That update in "in progress."
>>
>> I have a number of patches and proposed patches which, now that
>> libvirt-1.0.0 has been released, I will be updating and
>> submitting/resubmitting.  This includes:
>>
>> 1. patch to put dnsmasq parameters into a conf file rather than on the
>> command line.
>>
>> 2. patch to add interface= to the dnsmasq parameters ... this is not one of
>> my show stoppers
>>
>> 3. Proposed patch to add and addition conf-file or conf-dir so that
>> log-queries and/or log-dhcp could be specified for an instance of dnsmasq.
>> Optionally, add a libvirtd.conf parameter to determine is this capability is
>> enabled.
>>
>> 4. Proposed patch to always allow IPv4 and IPv6 packets between guests on a
>> network even if no gateway addresses are specified.
>>
>> ** all of the above will work with dnsmasq => 2.48
>>
>> ** the following requires dnsmasq-2.63+patches or dnsmasq-2.64
>>
>> 5. Patch to add DHCPv6 support to libvirt
>>
>> The listed order above more or less is also how they need to be applied.  If
>> any of the above will get an outright rejection (e.g., (2) for
>> "interface="), I would appreciate knowing sooner rather than later.
>>
>> Comments/suggestions appreciated!
>>
>>
>>> In that case, if someone asks for dhcp6, you can assume that they have a
>>> new enough dnsmasq. (alternately, if we have a runtime check of the
>>> dnsmasq version, we could even log a proper error when we encountered
>>> <dhcp> in an ipv6 element, rather than just relying on whatever message
>>> dnsmasq outputs in that case).
>> A simple test could be to check if radvd is to be used.  If it is, then
>> DHCPv6 support is unlikely and disabled.
>>
>>>> Since dnsmasq-2.48 does not support IPv6 dhcp but does handle IPv6 for
>>>> dns and CentOS 6 does include radvd, I also propose that a
>>>> libvirtd.conf option be added.  If the option is not present or set
>>>> off, then radvd is used.  If the option is set on, then dnsmasq is used.
>>> See my other mail with the counter-proposal of doing a runtime check of
>>> the dnsmasq version.
>> I do no see how that would work for determining if patches were applied or
>> not.  See my response to the other message.
> Yeah assuming a user has patched their dnsmasq is a non-starter. We
> either depend on 2.64 or we don't.
>
>>>> At some point in the future, it can be decided whether to keep using
>>>> radvd or not.
>>> We definitely have to keep using it for now, as not everyone has a
>>> dnsmasq new enough to do route advertisement.
>> I agree that keeping support for it makes sense.  See the other message for
>> my new proposal.
>>
Sorry, I have been a bit busy re-fitting some patches based on v1.0.0 to 
fit on the current git master/origin.

I sent some email to Simon Kelly (dsnmasq developer) about what is being 
discussed here.

He said that the RA support is fairly new so he recommends using a 
recent version.  Although I found some reference to "enable-ra" for 
stateful IPv6 in dnsmasq-2.60, IO did not find anything specifically on 
"ra-only" which would be for stateless IPv6.  Therefore, I recommend 
that if any dnsmasq early 2.63 is used, then radvd would be used.  With 
dnsmasq-2.63 or later, dnsmasq will be used.

I am looking into an alternate method of obtaining the dnsmasq version 
but the dnsmasq version will be the deciding rule for radvd versus 
dnsmasq usage.

On a related item: DHCPv6.  I can add this test in to see if DHCPv6 
should be supported.  It does work for dnsmasq-2.63 although it is much 
better with a couple of patches or "real soon now" dnsmasq-2.64.

There are two little problems with unpatched dnsmasq-2.63: you can run 
only one instance supporting DHCPv6 and, if you do not have interface= 
specified, it will ignore DHCPv6 requests.  Other than that, it does work.

Gene