1:22 p.m.
There are a couple of bugzilla records open requesting IPv6 support on
libvirt's virtual networks:
https://bugzilla.redhat.com/show_bug.cgi?id=514749
https://bugzilla.redhat.com/show_bug.cgi?id=586124
This is a first cut at describing what that support will look
like. Please send any comments/criticisms/suggestions you may have.
Changes to network XML
----------------------
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.
b) The address attribute can now be either an ipv4 dotted quad, or an
ipv6 address, eg "2001:db8:1::10" (the schema will allow either in
any case, but the parser will validate that it is appropriate for
the given family - see (b))
b) new attributes:
family="ipv4|ipv6".
Optional. It will default to ipv4 if not specified.
prefix="<some number>"
Optional. This is used to specify how many significant bits are
in the ipv6 address. This will also be usable for ipv4, but the
parser will make sure that only one of netmask or prefix is given
for an ipv4 address (since netmasks generally aren't specified as
such in IPv6, the netmask attribute will not be allowed if family
is ipv6).
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.
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.
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.
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>
The original ipv4 address example remains unchanged, but notice that
we can also give a 2nd ipv4 address, and can use "prefix" instead of
"netmask" if we want.
The example configs the bridge with two ipv6 addresses, so guests
connected to the bridge can be on either of these networks or both. In
addition, radvd will be SIGHUPed when the network is brought up, so if
it is configured properly, it will begin giving out addresses on the
network via IPv6 autoconf (presumably on the 2001:4978:2ac::/28
network, although that's completely dependent on the radvd config.
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).
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.
3) radvd configuration is outside the scope of libvirt, although
libvirt can give it a kick now and then.
Configuring the IP addresses of the bridge
------------------------------------------
Currently, libvirt uses the SIOCSIFADDR ioctl to set the (single) ipv4
address of the bridge. This ioctl does not support IPv6. In order to
configure and IPv6 address (or more than one IPv4 address) we will
need to use netlink (ie libnl).
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.
libvirt already uses libnl directly for macvtap support, and
indirectly for netcf (the iface-* commands), but both of those are
conditionally compiled. In order to continue supporting older
platforms, all this IPv6 stuff will need to be optional, and
conditional on the presence of the right libnl version. If libnl is
available, the default will be --with-ipv6, otherwise, the default
will be --without-ipv6.
Also, src/network/bridge_driver.c:networkDisableIPV6, which tweaks
some kernel tunables to disallow adding IPv6 addresses to a bridge, is
currently called for all networks' bridges when they are brought
up. This will of course now be called only if the network has no IPv6
config.
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).
9:14 p.m.
On 03/11/2010, at 5:26 AM, Laine Stump <laine(a)laine.org> wrote:
<snip>
<ip family="ipv6" address="2001:db8:1::10"
prefix="128"/>
<ip family="ipv6" address="2001:4978:2ac::1"
prefix="48">
<radvd/>
Is "radvd" too implementation dependent?
Just thinking that as we expand out our platform support over time, if we support setting
up bridges on other OS's then would radvd be what's used? (I actually have no
idea, it may very well be)
5:05 a.m.
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
5:36 a.m.
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 :|
9:24 a.m.
On Wed, Nov 03, 2010 at 10:36:24AM +0000, Daniel P. Berrange wrote:
On Tue, Nov 02, 2010 at 02:22:08PM -0400, Laine Stump wrote:
> 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.
Taking this excample, and assuming its for virbr0, then an radvd
config would simply comprise
interface virbr0
{
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
prefix 2001:db8:1::/128
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
prefix 2001:4978:2ac::/48
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Regards,
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 :|
10:49 a.m.
On 11/03/2010 06:36 AM, Daniel P. Berrange wrote:
On Tue, Nov 02, 2010 at 02:22:08PM -0400, Laine Stump wrote:
> 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.
Okay, I'll take your word for that, and use your example in the other
email as the model config.
Can I assume it's okay to do this:
1) run a separate radvd instance for each interface
2) store the pid in /var/run/libvirt/network/${netname}-radvd.pid
3) create the conf file to be used by radvd in
/var/run/libvirt/network/${netname}-radvd.conf
??
Also, similar to dnsmasq, I will leave it running if libvirtd exits, and
check for it the next time libvirtd starts up.
> 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.
But once I get this all running, that's exactly what I will be doing
(using the same machine as a virt host and an IPv6 router). :-P
Sure, it's not what I'd do if I had lots of equipment and space, but in
my limited hardware setup at home, I only have a single machine that I
can depend on to be always on, and always connected to the network.
Anyway, as long as radvd can have multiple instances running (as long as
none of them are attempting to use the same interface), this shouldn't
be a problem.
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.
So I guess the idea is that in isolated mode, the machines could talk
amongst themselves using the link-local IPv6 address (fe80:...), right?
As far as in routed mode, I have two questions:
1) Can we be 100% sure that users will always want want (or at least be
able to tolerate) route discovery on a routed IPv6 network? (I don't
have enough experience using IPv6 in the real world to know the answer)
2) What about the people who do want to adjust the radvd config in some
manner, should we require them to setup their own bridge from scratch?
3) (kind of related to (2)) If no IPv6 addresses are given in the XML,
should we continue to disable IPv6 capabilities on the bridge (thus
preventing someone from rolling their own radvd/whatever without needing
to create their own bridge).
> 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 ?
A good question. I'm not sure. My statement here is based totally on an
email where the NetworkManager maintainer (Dan Williams) told me that
when they started using libnl-1.1 in the version of NetworkManager
that's in RHEL-5, they had to build their own private copy of libnl,
since the -1.0 in RHEL5 was ABI incompatible.
A quick look through the header files of 1.0 vs 1.1 shows that the name
of at least one header file has changed, and there are some new
functions, and some others eliminated. Much of it is the same, though.
My worry would be about functions whose signature remains the same, but
have different semantics.
11:25 a.m.
On Thu, Nov 04, 2010 at 11:49:32AM -0400, Laine Stump wrote:
On 11/03/2010 06:36 AM, Daniel P. Berrange wrote:
>On Tue, Nov 02, 2010 at 02:22:08PM -0400, Laine Stump wrote:
>> 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.
Okay, I'll take your word for that, and use your example in the other
email as the model config.
Can I assume it's okay to do this:
1) run a separate radvd instance for each interface
2) store the pid in /var/run/libvirt/network/${netname}-radvd.pid
3) create the conf file to be used by radvd in
/var/run/libvirt/network/${netname}-radvd.conf
??
Also, similar to dnsmasq, I will leave it running if libvirtd exits, and
check for it the next time libvirtd starts up.
Yes, treat it in the same way we treat dnsmasq, unless we find
something that requires a different approach.
> 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.
So I guess the idea is that in isolated mode, the machines could talk
amongst themselves using the link-local IPv6 address (fe80:...), right?
No, in isolated mode we still configure the IPv6 network as normal.
They simply won't be able to route to the LAN, because the firewall
rules will block traffic.
As a general rule you can't directly use link-local addresses from
applications, unless they've been explicitly designed to allow it,
and most haven't. The link local addresses are used in the router
advertisment protocol, to get a real address, at which point normal
apps can talk.
As far as in routed mode, I have two questions:
1) Can we be 100% sure that users will always want want (or at least be
able to tolerate) route discovery on a routed IPv6 network? (I don't
have enough experience using IPv6 in the real world to know the answer)
As long as the radvd we're running is only sending traffic on the
the bridge interface we've created, it is no problem. We'd only
cause trouble if say we accidentally let it use a real physical
NIC on the LAN.
2) What about the people who do want to adjust the radvd config in
some
manner, should we require them to setup their own bridge from scratch?
They're out of scope of this functionality. The fact that we're using
radvd is just a private implementation detail. We're not providing a
general purpose IPv6 management API here.
3) (kind of related to (2)) If no IPv6 addresses are given in the
XML,
should we continue to disable IPv6 capabilities on the bridge (thus
preventing someone from rolling their own radvd/whatever without needing
to create their own bridge).
We should continue to set /net/ipv6/conf/%s/disable_ipv6=1 when
no IPv6 address is in XML. If someone really wants to roll their own
config, using libvirt's bridge, then they can toggle the setting
back to 0 at the same time as they manually configure the addresses
The other settings
/net/ipv6/conf/%s/accept_ra
/net/ipv6/conf/%s/autoconf
need to be set to 0 at all times. An interface which is used as a
gateway must always have autoconf=0, and accept_ra=0 is required
to prevent the guest hijacking the host network by sending out
its own router advertisments.
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 :|
1:49 p.m.
On Tue, 02 Nov 2010 14:22:08 -0400
Laine Stump <laine(a)laine.org> wrote:
There are a couple of bugzilla records open requesting IPv6 support
on
libvirt's virtual networks:
https://bugzilla.redhat.com/show_bug.cgi?id=514749
https://bugzilla.redhat.com/show_bug.cgi?id=586124
This is a first cut at describing what that support will look
like. Please send any comments/criticisms/suggestions you may have.
As a user I'm really looking forward to this. Without IPv6 support,
it's difficult to move away from the script based networking. (which in
turn doesn't play nice with a qemu locked down with SELinux)
prefix="<some number>"
Optional. This is used to specify how many significant bits are
in the ipv6 address. This will also be usable for ipv4, but the
parser will make sure that only one of netmask or prefix is given
for an ipv4 address (since netmasks generally aren't specified as
such in IPv6, the netmask attribute will not be allowed if family
is ipv6).
I suppose omitting this for IPv6 would be shorthand for the standard
64-bit prefix?
You write optional here, but your examples doesn't omit it so just so
I'm not misinterpreting I figure I'd ask. :)
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 agree with the points already brought up in this thread. I would like
to request though that you keep this point that it is possible to not
have router advertisement. I don't have any actual failure scenarios to
motivate this, but I like the general principle of disabling features
that aren't necessary. :)
Given the scenario under which libvirt is commonly used, have you given
any thought to more dynamic prefix management? With IPv4 NAT "solves"
the issue of the machine moving around different connections. With
IPv6, something else is needed. I believe DHCPv6 can query for a
network that the machine in turn can delegate. Not sure how you
would go about getting that functionality connected to libvirt somehow
though. :)
Any idea of the time frame for getting basic support into the main
repo? And any plans for RHEL 6 given the "comprehensive IPv6
support"? :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
5134
days inactive
5137
days old
7 comments
5 participants
participants (5)
-
Daniel P. Berrange -
jclift＠redhat.com -
Laine Stump -
Paolo Bonzini -
Pierre Ossman