[libvirt] RFC: Supporting IPv6 on libvirt virtual networks
Daniel P. Berrange
berrange at redhat.com
Wed Nov 3 10:36:24 UTC 2010
On Tue, Nov 02, 2010 at 02:22:08PM -0400, Laine Stump wrote:
> 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, so if we're going to have an <radvd>
> subelement, it's going to need a *lot* of attributes/subelements of
> its own:
>
> 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.
The list of radvd.conf options is long, because it is a tool that has
to serve a million & one different deployment scenarios. The libvirt
virtual networking is just 1/2 scenarios and thus we don't need to
deal with the entire of radvd configuration. We actually don't care
about the fact that it is radvd from a XML configuration point of
view. What we're after is a mechanism to advertise the route to get
from the virtual network to the LAN. radvd is just the chosen impl
for that mechanism behind the scenes, not something the users are
to be exposed to directly.
In the same way with IPv4, we provide 3 canned configs and ignore
the million and one other possibly IPv4 setups, with IPv6 we are
doing the same, just providing a basic routed subnet and isolated
subnet. If the admin wants todo insanely clever stuff with radvd
that is beyond these two supported modes, they can setup that up
manually themselves.
> However, we can't merely ignore radvd, since our bridges don't
> exist at the time radvd is started by the system, and even if
> you've put the proper config in the static radvd.conf file, it
> can't be recognized until the interface exists, and the method of
> informing radvd that it needs to re-scan the conf file to find new
> interfaces is to send it a SIGHUP.
That isn't going to work. radvd is something that you only ever run
on machines that are network gateways. Virtalization hosts are thus
very unlikely to be running radvd at all. We are taking a non-gateway
host, and making it serve as a gateway solely for the virutal network
interface. As such, we need to be able to run radvd ourselves, solely
for the virbr0 device (and any other configured networks we have).
Running libvirt on a host that is already a network router, and thus
does have radvd running, is something that is really out of scope
for this. Therefore we should entirely manage radvd as we do for
dnsmasq.
> So, I'm thinking we can add an <radvd/> subelement to IP that, for
> now, will have no attributes and no subelements. If the ip/radvd
> subelement exists, libvirt will send radvd a SIGHUP when the
> network is brought up, and again if it is brought down.
I don't think we need a radvd element really. If the forwarding
method is 'routed', then we always need radvd to make that
functionality work. If it is 'isolated', then we don't want it.
To configure radvd, all we need to know is the interface name,
and bridge IPv6 address and the bridge prefix. We have all that
info already in the XML.
> Here is the example from formatnetwork.html on libvirt.org, updated with
> examples of
> the changes I'm proposing:
>
> <network>
> <ip address="192.168.122.1" netmask="255.255.255.0">
> <dhcp>
> <range start="192.168.122.100" end="192.168.122.254" />
> <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" />
> <host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11" />
> </dhcp>
> </ip>
> <ip family="ipv4" address="192.168.125.1" prefix="24">
> <ip family="ipv6" address="2001:db8:1::10" prefix="128"/>
> <ip family="ipv6" address="2001:4978:2ac::1" prefix="48">
> <radvd/>
> </ip>
> </network>
Ok, looks reasonable.
> NB: As previously discussed, we are making the assumptions that
>
> 1) nobody will want to use dhcp6 (although it's available, autoconf
> via radvd is the more accepted method of automatically getting an
> address).
Agreed.
> 2) any tftp booting required can be done with the IPv4 facilities
> already in place (ie, if that is needed, the guests will use both
> IPv4 and IPv6). Likewise for any other configuration required that
> isn't covered by ipv6 autoconf.
Agreed.
> 3) radvd configuration is outside the scope of libvirt, although
> libvirt can give it a kick now and then.
As described above, we need to manage it ourselves.
> Configuring the IP addresses of the bridge
> ------------------------------------------
>
> Unfortunately, libnl isn't available on all Linux platforms (libvirt's
> virtual networks are only available on Linux), for example RHEL5 has
> libnl, but it's an older version that is API-incompatible with the
> version used by libvirt.
How badly API incompatible ? Stupid little differences that can be
trivially #ifdef'd, or major differences that make it look like an
entirely different API ?
> iptables/ip6tables
> ------------------
>
> The ip6tables rules setup for the bridge will be similar to those we
> already setup for ipv4. See Bug 586124 for a short script that creates
> a workable set of rules.
>
> "mode=nat" anomoly
> ------------------
>
> 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).
That is fine. Doing mix configs for IPv4 vs IPv6 would just be
an endless source of confusion for everyone.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list