[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC: Supporting IPv6 on libvirt virtual networks



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]