Re: Proposed: replace radvd with dnsmasq for Router Advertizing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 4, 2012 at 7:12 AM, Gene Czarcinski <gene@xxxxxxxxx> 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.
>
> Gene
>
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Doug Goldstein

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]