[libvirt] RFC: Supporting IPv6 on libvirt virtual networks

[Paolo Bonzini]

On 11/02/2010 07:22 PM, Laine Stump wrote:
> 1) The <ip> element of the network xml will be expanded in the following
> ways:
>
> a) <ip> can now appear multiple times (although I think only one of
> these can/should be allowed to have a <dhcp> element). The bridge
> interface (eg virbr0) will be configured with all given ips.

While this can make sense as an initial implementation limit, I think in 
general it makes sense to have multiple <dhcp> elements, with one 
dnsmasq instance per <dhcp> (the need to invoke multiple dnsmasq 
instances is a limitation of dnsmasq's command-line syntax, for example 
dhcpd wouldn't need it).

So, it seems okay but it should be documented as a limit of libvirt 
rather than a limit of the specification.

> family="ipv4|ipv6".
>
> Optional. It will default to ipv4 if not specified.

I do prefer ipv4/ipv6, but I'll just point out inet/inet6 as a possible 
alternative.

> 2) New subelements of <ip>
>
> If we want to avoid requiring the admin to login to the hosts to
> configure radvd for advertising addresses, the ipv6 version of <ip>
> is going to need radvd config information. The list of options is
> rather long, and I don't see how we could assume a hardcoded
> default for any of them

If I had to pick four, those would be AdvSendAdvert, AdvOnLink, 
AdvAutonomous, AdvRouterAddr.  However...

> http://linux.die.net/man/5/radvd.conf
>
> For this reason, I think we can at least initially *not* include all
> this config, and not attempt to run radvd ourselves.

... as an initial plan I agree.

However, if you were to keep the <radvd/> element I would move it under 
<interface> instead.  This is for two reasons:

1) The idea, is that elements within <ip> represent services listening 
on those interfaces (<dhcp> and <tftp> currently).  You cannot SIGHUP 
radvd only on some prefixes.

2) If, in the future, you add the ability to run radvd autonomously, an 
empty <radvd/> tag would have a different meaning than "send a SIGHUP to 
radvd".  In particular, currently if there is no entry for an interface 
in radvd.conf adding the <radvd/> tag makes no difference.  If libvirtd 
were to manage radvd, the empty tag would likely mean "start radvd with 
some default arguments".


In other words, the schema should reflect the fact that radvd is not 
handled the same way as dnsmasq.  As an alternative idea I wonder: does 
it make sense to do do the radvd SIGHUP unconditionally or based on a 
/etc/libvirtd.conf flag?

(As an aside: when libvirtd starts managing radvd autonomously, if ever, 
I would use a name like <ndp> for neighbor discovery protocol, rather 
than radvd).

> libvirt's virtual networks have three modes: isolated, routed, and
> nat. If mode=isolated or mode=routed, IPv6 and IPv4 will be handled
> the same. However, since there is no NAT for IPv6, if you specify
> mode='nat' on a network, and give it an IPv6 address, the IPv6 traffic
> will be routed, while IPv4 traffic will be NATed. (Since there is a
> single mode attribute for the entire network, it will not be possible
> to specify isolated IPv6 and routed/nat IPv4, or isolated IPv4 and
> routed IPv6).

It could be possible to represent this in the schema by splitting out 
the dev attribute into a new element, like this:

<physdev dev="eth1">
<forward mode="nat" family="ipv4">
<forward mode="isolated" family="ipv6">

My iptables-fu is too small to understand if it would make sense to have 
multiple physdev elements.

Paolo