30 Oct
2012
30 Oct
'12
9:35 p.m.
On 10/30/2012 02:28 PM, Laine Stump wrote: > On 10/30/2012 11:58 AM, Gene Czarcinski wrote: >> >> Well, ff02::1:2 does have some meaning in dhcp6. >> >> From what I have seen by "well behaved" clients is that the client >> always uses port 546 and the server always uses port 547. But, >> dnsmasq have some comments/code which indicates that not all clients >> are "well behaved." >> >> In dhcp6, a little four dhcpv6 dance is performed to establish the >> clients address: >> >> 1. dhcpv6 solicit: from=fe80::client:546 to=ff02::1:2:547 >> 2. dhcpv6 advertise: from=fe80::server:547 to=fe80::client:546 >> 3. dhcpv6 request: from=fe80::client:546 to=ff02::1:2:547 >> 4. dhcpv6 reply: from=fe80::server:547 to=fe80::client:546 >> >> Or, in other words: (1) need dhcpv6, (2) I serve it, (3) OK, give me >> one, and (4) here it is. > Ah, so that address has a special meaning/function. OK, I took the easy approach. I will go back and "do it right" so that both "-d ff02::1:2" and "--dport 547" are specified. > > >> Since dnsmasq does its own packet filtering and with bind-interfaces >> having a real meaning, it all works (assuming that radvd has the right >> configuration). >>> >>>> This works With the radvd configuration and a dhcp-range specified for >>>> a ipv6 subnet, a guest will get a dhcp6 address and RA default route. >>> Interesting - so both radvd and dnsmasq are involved, correct? >> Yes, why not? > No reason. Just curious. > >> Sometime in the future this should be reconsidered and either >> everything is done by dnsmasq or it is at least an option. > Yeah, it couldn't be mandatory, at least not now, since there are still > lots of people using dnsmasq versions that don't have all the required > capabilities. I am having second thoughts and think it might be a good idea to just have dnsmasq do everything since it can do both dhcp6 and RA. This sure does simplify things: if you have dhcp6, add the dnsmasq parameter "enable-ra". If not, don't add it. About being compatible with old code. I see the dhcp6 patches and this potential patch as being based on v1.0.0 and not being back-ported. So I am not sure I see a potential conflict. > > >> I must say that having dnsmasq do everything does have appeal ... >> one less dependency. >>>>> 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 have no problem with the "convert from long commandline to conf file" >>> patch except for the bit that points to a "conf directory" where user >>> supplied conf files can be added. Aside from that part needing to be in >>> a spearate patch, if we're going to add that kind of configurability, we >>> need to do it in a way that will allow us to easily see that the user is >>> playing outside the fence (otherwise we spend a lot of time chasing >>> "bugs" that end up being caused by user-supplied options). >> Originally, I wanted the conf-dir so that I could pop in/out some >> configuration changes that would happen when dnsmasq re-read the >> configuration. Well, it does not work that way and dnsmasq has to be >> restarted for some of the more interesting changes. Given this, I >> believe that conf-dir serves no useful purpose and should be removed >> and I will remove it and resubmit the patch. >>> Because we're in freeze right now I haven't spent a lot of time >>> discussing that, but planned to send a message about it when I get a >>> minute. >> Right now I am working on getting dhcpv6 functional and, while what I >> have works, there is still more to do. >>>>> 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. >>>> 5. As far as I can tell (or at least this is for dnsmasq), >>>> "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are >>>> all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not >>>> looked to see what network_conf.c does. >>> "what network_conf.c does"? Well, it of course doesn't deal directly >>> with those options, but the config that feeds into some of those options >>> is parsed in virNetworkIPParseXML(), and is only done if the <ip> >>> element is ipv4. But then you've already seen that code if you have dhcp >>> working for ipv6 - the <dhcp> element is also only parsed for ipv6. The >>> format-side code doesn't have that extra check; I guess I figured that >>> if there was no way to configure ipv6 with dhcp or tftp, it was safe to >>> assume any ip element with dhcp or tftp info was ipv4 anyway. >> I have now dived into network_conf.c and a little into dnsmasq.c. Yet >> again I was surprised because most of what was needed for dhcpv6 was a >> little tweaking here and there. > I'd like to think that's because we've tried to do things in a manner > that anticipates future expansions, but some of it may be pure luck :-) A little luck can go a long way because no matter how good you are, it is impractical to predict the future. > >> To support dhcp-host for IPv6, I did assumed that for IPv6 no MAC >> address would be specified since it does not have a defined meaning in >> DHCPv6. Therefore, in dnsmasq.c/hostsfileAdd(), if the mac==NULL, I >> use the IPv6 format of <hostname>,[<ipv6-addr>] whereas for IPv4 it >> is either MAC,<ipv4-addr>,<hostname. or MAC,<ipv4-addr>. >> >> This way most of the code works as is. Dnsmasq has lots of options >> and different ways that dhcp-host= can be specified, but this is >> simple and I know it works. >>>> 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. >>>> This currently works because things are forced so that one and only >>>> one IPv4 dhcp definition will be handled. With the addition of IPv6 >>>> dhcp, things fall apart. >>>> >>>> 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file >>>> in both form and function. The <dns>-<host> specification is done on >>>> an interface bases and, thus, the processing of the data and creation >>>> of the file should only be done once. >>>> >>>> 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for >>>> every ip definition that is processed for dhcp. Initially, this will >>>> be for dhcp4 only until I can figure out how to do it for dhcp6. >>>> >>>> 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two >>>> functions [one for addn-hosts and one for dhcp-hosts]. Additionally, >>>> all the functions which call dnsmasqSave() need to be reworked >>>> appropriately. >>> I've actually never liked the "dnsmasqContext" concept, as it seems like >>> overkill and has conceptual problems such as what you've described. I >>> would be just as happy with replacements that were simpler and easier to >>> deal with. I think part of what complicates dnsmasq.[hc] is that it's in >>> the util directory, so it isn't allowed to understand the contents of >>> virNetworkDef, and must instead be sent the list of hosts in a simpler >>> format. If, instead, there was a file src/network/bridge_dnsmasq.[hc], >>> that could have functions that took virNetworkDef as an arg, and just >>> immediately return a string (or, in a separate function, write to a >>> file). That should simplify calling, and writing tests. And existing >>> dnsmasq-related functions in bridge_driver.c could be moved there as >>> well, reducing clutter in bridge_driver.c. (Of course I'm saying all >>> this without ever seriously considering it, just talking off the cuff, >>> so I may be completely wrong :-) >> Right now I have fixed things up so they work. I would like to leave >> this as an exercise for someone else [or at least a later time]. >> >> Besides, isn't bridge_driver.c pretty much for dnsmasq only? > Right now, yes. It's always possible that an alternative could come > along, of course... The alternative would have to be really good to replace all the functionality of dnsmasq and would likely have it's own driver. > > >>>> 7. So far, the only things I have done involving the xml specification >>>> is to enable <dhcp> for IPv6. However, the xml to specify a dns >>>> addn-hosts appears, IMHO, to be overly verbose and complicated. >>> It is made that way because a single IP address may have multiple >>> hostnames associated with it, and we want to avoid having multiple >>> methods of describing the same thing. What you propose in the next >>> couple sentences was already proposed, tried, and rejected when dns host >>> support was originally added. >> OK. >>>> So, while allowing the current xml to be valid, I suggest adding an >>>> alternate form for which is similar to that used for dhcp-host. An >>>> example is "<host ip='1.2.3.4' name='one' />" >>>> >>> There are a few places in libvirt's XML where the same thing can be >>> expressed in two different ways, but that is only done when necessary >>> because the existing XML is unable to completely describe the new >>> functionality but backward compatibility is required. It creates all >>> sorts of problems when formatting the config back into XML though (which >>> of the two do you choose? Or do you do both? Either of these is a bad >>> answer), therefore we definitely don't want to do that except in cases >>> where it is absolutely necessary; this isn't one of those cases. >> This is why I have tried to tweak and bend things so it works (and >> because it mostly worked before). >> >> And now, as the saying goes, one more thing. >> >> I now realize that I am going to need to get into virsh net-update >> since I am adding things to the xml specification and net-update will >> need to differentiate between dhcp4 and dhcp6 changes. >> >> Another thought that occurs to me is whether there has any >> consideration been given having a "virsh net-restart" which would just >> restart dnsmasq and radvd. Typing stuff in for the command line of >> net-update is a little prone to typos. > You can always put them in (temporary) files :-) I am still thinking about this and I still have to fix net-update for dhcp6. Gene