On 11/05/2012 12:27 AM, Doug Goldstein wrote:
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.
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list