[libvirt] RFC: adding configuration for standard dhcp options to <network>

[Gene Czarcinski]

On 11/26/2012 03:12 PM, Laine Stump wrote:
> 5) With so many options, it may save lots of repetitive code in the
> parser/formatter to make a generic <option> element:
>
>         <option name='dns-server' value='x.x.x.x'/>
>         <option name='ntp-server' value='y.y.y.y'/>
>         <option name='smtp-server' value='z.z.z.z'/>
>         <option family='ipv6' name='dns-server' value='xxxx::1'/>
>         <option number='201' value='/netboot/boot-dir/' force='yes'/>
>
> The final is an example of something I just noticed in the BZ I
> mentioned above - it is both using an option number and forcing the
> option to be sent back to the client even if the client doesn't request
> it. This is apparently needed for some clients.
>
> There is a precedent for the "name/value" type of object in nwfilter
> parameters. The advantages in this case are
>
>    a) the code for the parser couple possibly be much smaller, with just
> a single
>       enum + VIR_ENUM_(DECL|IMPL)
>
>    b) it would be easier to support the options by number (which are all
> defined
>       somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq)
>
> On the other hand, if we allowed any possible option by specifying a
> number (and even if not, depending on how the parser was implemented),
> it would be easier to create a situation where "bad stuff" could be
> injected into the dnsmasq commandline (we should have some type of
> intelligent parsing of the values - known options should have a type
> associated with them, and unknown should at least be checked for
> dangerous characters).
>
> Any opinions from those with more XML experience?
>
>
I also prefer the new/separate option element.

Some related observations:

1. Many of the dhcp options available with dnsmasq are IPv4 only and I 
am not sure that there is much support for additional IPv6 options in 
dhcp-sever or dhclient.

2. RA also has provisions for supplying the address of a nameserver and 
dnsmasq does provide this information for both state-full (DHCPv6) and 
state-less (SLAAC) operation.  This is done automatically when dnsmasq 
has with enable-ra or ra-only specified. The address supplied by dnsmasq 
is the IPv6 link-local address on the machine it is running on.

3. As far as IPv6 options, I believe that this change is redundant to 
the support dnsmasq is providing.  Of course, if you are using radvd for 
RA support, then, for IPv6, you could also specify the RDNSS and DNSSL 
(currently, this is not done by libvirt).

4. Doesn't this tie libvirt more strongly to dnsmasq?  Don't get me 
wrong, I strongly believe in dnsmasq and its use by libvirt.  I also 
believe that there would have to be an extremely good set of reasons to 
adopt something else.

Gene