[libvirt] Proposed: replace radvd with dnsmasq for Router Advertizing
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. 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. At some point in the future, it can be decided whether to keep using radvd or not. Comments? Suggestions? Gene
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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.
I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan. Jirka
On 11/02/2012 11:58 AM, Jiri Denemark wrote:
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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. I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan. I can do that but then the individual backporting to (for example) CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and change a libvirtd.conf parameter.
If the default is to use dnsmasq, then there are going to be mistakes made. If the default is to use radvd, then many systems will not change. Gene
On 11/02/2012 12:39 PM, Gene Czarcinski wrote:
On 11/02/2012 11:58 AM, Jiri Denemark wrote:
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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. I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan. I can do that but then the individual backporting to (for example) CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and change a libvirtd.conf parameter.
(actually, the parameter/config option wouldn't need to be changed just to use dhcpv6, it would only need to be changed if you wanted to use dnsmasq for ipv6 router advertisement instead of radvd) So there are 3 possibilities for deciding whether to use radvd or dnsmasq for router advertisement: 1) configure-time option to set a compile flag which will compile the code to use either radvd or dnsmasq. 2) libvirtd.conf parameter which will be checked at runtime. 3) runtime probe of dnsmasq version (similar to how we currently run "qemu-kvm -help" to learn the qemu version / available options). Option (1) puts the burden on the distro package maintainer (or the individual, if they're building for themselves). It could be setup to autodetect the dnsmasq version and provide the most logical setting as default. As you say, though, if someone on a distro that's using an old dnsmasq wanted to switch to using dnsmasq for RA instead of radvd, they would need to build their own libvirt, rather than just upgrading dnsmasq. Option (2) puts the burden on the admin, and leaves open the possibility of a misinformed/uninformed admin seeing the option and tweaking it when they shouldn't, leading to support headaches. Option (3) would be the most reliable as long as we never need to manually disable use of dnsmasq for RA due to a bug in a newer version of dnsmasq. Another potential problem is if the output of "dnsmasq --version" changes in some way that's incompatible with whatever code we have to parse the version number, we could potentially make the wrong choice. (Another thing in favor of either (2) or (3) is that all the code would always be compiled, and I've seen Eric advocate that recently as a way to prevent code going "stale" because it's #ifdef'ed out most of the time.)
If the default is to use dnsmasq, then there are going to be mistakes made. If the default is to use radvd, then many systems will not change.
I'm kind of leaning towards making the decision automatically based on a runtime examination of the dnsmasq version. Any other opinions?
On 11/03/2012 08:58 PM, Laine Stump wrote:
On 11/02/2012 12:39 PM, Gene Czarcinski wrote:
On 11/02/2012 11:58 AM, Jiri Denemark wrote:
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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. I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan. I can do that but then the individual backporting to (for example) CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and change a libvirtd.conf parameter. (actually, the parameter/config option wouldn't need to be changed just to use dhcpv6, it would only need to be changed if you wanted to use dnsmasq for ipv6 router advertisement instead of radvd)
So there are 3 possibilities for deciding whether to use radvd or dnsmasq for router advertisement:
1) configure-time option to set a compile flag which will compile the code to use either radvd or dnsmasq.
2) libvirtd.conf parameter which will be checked at runtime.
3) runtime probe of dnsmasq version (similar to how we currently run "qemu-kvm -help" to learn the qemu version / available options).
Option (1) puts the burden on the distro package maintainer (or the individual, if they're building for themselves). It could be setup to autodetect the dnsmasq version and provide the most logical setting as default. As you say, though, if someone on a distro that's using an old dnsmasq wanted to switch to using dnsmasq for RA instead of radvd, they would need to build their own libvirt, rather than just upgrading dnsmasq.
Option (2) puts the burden on the admin, and leaves open the possibility of a misinformed/uninformed admin seeing the option and tweaking it when they shouldn't, leading to support headaches.
Option (3) would be the most reliable as long as we never need to manually disable use of dnsmasq for RA due to a bug in a newer version of dnsmasq. Another potential problem is if the output of "dnsmasq --version" changes in some way that's incompatible with whatever code we have to parse the version number, we could potentially make the wrong choice.
(Another thing in favor of either (2) or (3) is that all the code would always be compiled, and I've seen Eric advocate that recently as a way to prevent code going "stale" because it's #ifdef'ed out most of the time.)
If the default is to use dnsmasq, then there are going to be mistakes made. If the default is to use radvd, then many systems will not change. I'm kind of leaning towards making the decision automatically based on a runtime examination of the dnsmasq version. Any other opinions?
Trying to probe the dnsmasq to find out if it could or could not handle RA is not something that makes sense to me. Supporting RA was first implemented in dnsmasq-2.60 so we know that both 2.59 (F16 and original F17) and 2.48 (CentOS 6 and RHEL 6) will need to use radvd. Let me say again, I assume that anyone wishing to run libvirt-1.0.0 or later will likely rebuild the rpm on that system and given what it takes to rebuild libvirt, rebuilding dnsmasq is trivial. Anyway, I am now proposing option 4: 1. Add the code to have dnsmasq support RA. 2. Add a boolean switch which determines whether radvd or dnsmasq is being used for RA. 3. Add code so that the boolean switch is set by a libvirtd.conf parameter at runtime. 4. Add code to specify the default setting of the libvirtd.conf parameter at build/compile time. My recommendation is that the default should be set to dnsmasq. Pro: Moves things forward; allows older systems which do not want to update dnsmasq a relatively easy way to make things work. If the system backported libvirt does later update dnsmasq, it is an easy change to libvirtd.conf to switch. Con: While the radvd related code will be compiled in, if the default is to use dnsmasq, there will need to be a special regression test to ensure that it still works. Gene
On Sun, Nov 4, 2012 at 6:26 AM, Gene Czarcinski <gene@czarc.net> wrote:
On 11/03/2012 08:58 PM, Laine Stump wrote:
On 11/02/2012 12:39 PM, Gene Czarcinski wrote:
On 11/02/2012 11:58 AM, Jiri Denemark wrote:
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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.
I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan.
I can do that but then the individual backporting to (for example) CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and change a libvirtd.conf parameter.
(actually, the parameter/config option wouldn't need to be changed just to use dhcpv6, it would only need to be changed if you wanted to use dnsmasq for ipv6 router advertisement instead of radvd)
So there are 3 possibilities for deciding whether to use radvd or dnsmasq for router advertisement:
1) configure-time option to set a compile flag which will compile the code to use either radvd or dnsmasq.
2) libvirtd.conf parameter which will be checked at runtime.
3) runtime probe of dnsmasq version (similar to how we currently run "qemu-kvm -help" to learn the qemu version / available options).
Option (1) puts the burden on the distro package maintainer (or the individual, if they're building for themselves). It could be setup to autodetect the dnsmasq version and provide the most logical setting as default. As you say, though, if someone on a distro that's using an old dnsmasq wanted to switch to using dnsmasq for RA instead of radvd, they would need to build their own libvirt, rather than just upgrading dnsmasq.
Option (2) puts the burden on the admin, and leaves open the possibility of a misinformed/uninformed admin seeing the option and tweaking it when they shouldn't, leading to support headaches.
Option (3) would be the most reliable as long as we never need to manually disable use of dnsmasq for RA due to a bug in a newer version of dnsmasq. Another potential problem is if the output of "dnsmasq --version" changes in some way that's incompatible with whatever code we have to parse the version number, we could potentially make the wrong choice.
(Another thing in favor of either (2) or (3) is that all the code would always be compiled, and I've seen Eric advocate that recently as a way to prevent code going "stale" because it's #ifdef'ed out most of the time.)
If the default is to use dnsmasq, then there are going to be mistakes made. If the default is to use radvd, then many systems will not change.
I'm kind of leaning towards making the decision automatically based on a runtime examination of the dnsmasq version. Any other opinions?
Trying to probe the dnsmasq to find out if it could or could not handle RA is not something that makes sense to me.
Supporting RA was first implemented in dnsmasq-2.60 so we know that both 2.59 (F16 and original F17) and 2.48 (CentOS 6 and RHEL 6) will need to use radvd. Let me say again, I assume that anyone wishing to run libvirt-1.0.0 or later will likely rebuild the rpm on that system and given what it takes to rebuild libvirt, rebuilding dnsmasq is trivial.
Anyway, I am now proposing option 4:
1. Add the code to have dnsmasq support RA.
2. Add a boolean switch which determines whether radvd or dnsmasq is being used for RA.
3. Add code so that the boolean switch is set by a libvirtd.conf parameter at runtime.
4. Add code to specify the default setting of the libvirtd.conf parameter at build/compile time.
My recommendation is that the default should be set to dnsmasq.
Pro: Moves things forward; allows older systems which do not want to update dnsmasq a relatively easy way to make things work. If the system backported libvirt does later update dnsmasq, it is an easy change to libvirtd.conf to switch.
Con: While the radvd related code will be compiled in, if the default is to use dnsmasq, there will need to be a special regression test to ensure that it still works.
Gene
--
This sounds like the bastard love child between Laine's option 1 and option 2. I would say it it suffers from all of the cons that Laine mentioned that weren't listed here. Laine's option 3 still sounds the best. -- Doug Goldstein
On 11/05/2012 12:29 AM, Doug Goldstein wrote:
On 11/03/2012 08:58 PM, Laine Stump wrote:
On 11/02/2012 12:39 PM, Gene Czarcinski wrote:
On 11/02/2012 11:58 AM, Jiri Denemark wrote:
On Fri, Nov 02, 2012 at 08:25:42 -0400, 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.
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. I think this should rather be handled by configure script (perhaps with an additional option if needed). Otherwise, I agree with the plan. I can do that but then the individual backporting to (for example) CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and change a libvirtd.conf parameter. (actually, the parameter/config option wouldn't need to be changed just to use dhcpv6, it would only need to be changed if you wanted to use dnsmasq for ipv6 router advertisement instead of radvd)
So there are 3 possibilities for deciding whether to use radvd or dnsmasq for router advertisement:
1) configure-time option to set a compile flag which will compile the code to use either radvd or dnsmasq.
2) libvirtd.conf parameter which will be checked at runtime.
3) runtime probe of dnsmasq version (similar to how we currently run "qemu-kvm -help" to learn the qemu version / available options).
Option (1) puts the burden on the distro package maintainer (or the individual, if they're building for themselves). It could be setup to autodetect the dnsmasq version and provide the most logical setting as default. As you say, though, if someone on a distro that's using an old dnsmasq wanted to switch to using dnsmasq for RA instead of radvd, they would need to build their own libvirt, rather than just upgrading dnsmasq.
Option (2) puts the burden on the admin, and leaves open the possibility of a misinformed/uninformed admin seeing the option and tweaking it when they shouldn't, leading to support headaches.
Option (3) would be the most reliable as long as we never need to manually disable use of dnsmasq for RA due to a bug in a newer version of dnsmasq. Another potential problem is if the output of "dnsmasq --version" changes in some way that's incompatible with whatever code we have to parse the version number, we could potentially make the wrong choice.
(Another thing in favor of either (2) or (3) is that all the code would always be compiled, and I've seen Eric advocate that recently as a way to prevent code going "stale" because it's #ifdef'ed out most of the time.)
If the default is to use dnsmasq, then there are going to be mistakes made. If the default is to use radvd, then many systems will not change. I'm kind of leaning towards making the decision automatically based on a runtime examination of the dnsmasq version. Any other opinions?
Trying to probe the dnsmasq to find out if it could or could not handle RA is not something that makes sense to me.
Supporting RA was first implemented in dnsmasq-2.60 so we know that both 2.59 (F16 and original F17) and 2.48 (CentOS 6 and RHEL 6) will need to use radvd. Let me say again, I assume that anyone wishing to run libvirt-1.0.0 or later will likely rebuild the rpm on that system and given what it takes to rebuild libvirt, rebuilding dnsmasq is trivial.
Anyway, I am now proposing option 4:
1. Add the code to have dnsmasq support RA.
2. Add a boolean switch which determines whether radvd or dnsmasq is being used for RA.
3. Add code so that the boolean switch is set by a libvirtd.conf parameter at runtime.
4. Add code to specify the default setting of the libvirtd.conf parameter at build/compile time.
My recommendation is that the default should be set to dnsmasq.
Pro: Moves things forward; allows older systems which do not want to update dnsmasq a relatively easy way to make things work. If the system backported libvirt does later update dnsmasq, it is an easy change to libvirtd.conf to switch.
Con: While the radvd related code will be compiled in, if the default is to use dnsmasq, there will need to be a special regression test to ensure that it still works.
Gene
-- This sounds like the bastard love child between Laine's option 1 and
On Sun, Nov 4, 2012 at 6:26 AM, Gene Czarcinski <gene@czarc.net> wrote: option 2. I would say it it suffers from all of the cons that Laine mentioned that weren't listed here. Laine's option 3 still sounds the best. OK, I give up (mostly). First of all, I will check with Simon Kelley as to which version has solid RA support for stateful (enable-ra) and stateless (ra-only) support. This may be 2.60 but it also may be later. I will also check as to the best method of obtaining support info from dnsmasq ... likely it is --version.
This is for dnsmasq-RA versus radvd only. Since I am doing this test, I could also check to see if dnsmasq is 2.63 or later for DHCPv6. Yes, it will take dnsmasq-2./63+patches or dnsmasq-2.64test7 or later for it to really work. If you try it with an earlier or unpatched version, you quickly fine out from the descriptive message in syslog. Gene
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? 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).
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.
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.
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.
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 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.
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
On Sun, Nov 4, 2012 at 7:12 AM, Gene Czarcinski <gene@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:
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Doug Goldstein
On 11/05/2012 12:27 AM, Doug Goldstein wrote:
On Sun, Nov 4, 2012 at 7:12 AM, Gene Czarcinski <gene@czarc.net> 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
On 11/03/2012 09:01 PM, Laine Stump wrote: 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
On 11/06/2012 12:40 PM, Gene Czarcinski wrote:
On 11/06/2012 11:50 AM, Gene Czarcinski wrote:
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. Try "dig chaos txt version.bind"
Yeah, I saw that thread (I subscribed to dnsmasq-discuss last week). I think that's overkill for what we're doing. running "dig" from libvirt just increases the number of external binaries we're dependent on, but you still need to parse the text output. Is there any reason for preferring this over simply running "dnsmasq --help"? (other than maybe hoping that the output would be less likely to change format over time). I actually think that it's more important to reduce the count of external binary dependencies...
On 11/06/2012 01:56 PM, Laine Stump wrote:
On 11/06/2012 11:50 AM, Gene Czarcinski wrote:
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. Try "dig chaos txt version.bind" Yeah, I saw that thread (I subscribed to dnsmasq-discuss last week). I
On 11/06/2012 12:40 PM, Gene Czarcinski wrote: think that's overkill for what we're doing. running "dig" from libvirt just increases the number of external binaries we're dependent on, but you still need to parse the text output. Is there any reason for preferring this over simply running "dnsmasq --help"? (other than maybe hoping that the output would be less likely to change format over time). I actually think that it's more important to reduce the count of external binary dependencies...
It is not clear to me how to make "dig" work anyway ... dnsmasq is not running yet. So it is back to doing "dnsmasq --version" and capturing the output in a buffer. Then parsing the buffer for the release and setting a flag appropriately. Once the flag is set, the actually doing the code to use dnsmasq or radvd is "simple". Development is a "work in progress." Naturally, I am doing this on top of the three patches I submitted earlier today. For the version, I am going to be looking for "2.63" or later. Besides being for radvd versus dnsmasq, for DHCPv6 I could add a warning if it was 2.63 and deny/fail/ignore DHCPv6 definitions if it was earlier. Overkill? Gene
participants (4)
-
Doug Goldstein -
Gene Czarcinski -
Jiri Denemark -
Laine Stump