Bug 586124 - RFE: support IPv6 on virtual networks
RFE: support IPv6 on virtual networks
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: Rhel6.1LibvirtTier2
  Show dependency treegraph
 
Reported: 2010-04-26 16:39 EDT by Peter Bieringer
Modified: 2015-09-27 22:13 EDT (History)
17 users (show)

See Also:
Fixed In Version: libvirt-0.8.7-1.el6
Doc Type: Enhancement
Doc Text:
The virtual networks created and used by libvirt for virtual guest connectivity were previously limited to only IPv4 connectivity; IPv6 traffic was explicitly disallowed. Full IPv6 connectivity is now supported on libvirt's virtual networks, including autoconf address/route discovery and a DNS server listening on an IPv6 address on the network. Note, however, that because autoconf is supported, there is no support for DHCPv6.
Story Points: ---
Clone Of: 567124
Environment:
Last Closed: 2011-05-19 09:18:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2010-04-26 16:39:44 EDT
Final RHEL6 should be also have fixed this issue because of:

http://www.redhat.com/rhel/beta/
Next generation networking: comprehensive IPv6 support

# rpm -q libvirt
libvirt-0.7.6-2.el6.i686

While cannot really test real setup (but tested that 0.7.1 lacks support), I assume, also libvirt-0.7.6 does not support proper setup of bridges for IPv6 because of:

# strings /usr/sbin/libvirtd |grep iptables | wc -l
31
# strings /usr/sbin/libvirtd |grep ip6tables | wc -l
0


+++ This bug was initially created as a clone of Bug #567124 +++

Description of problem:
After creation of some solated networks, libvirt does not setup IPv6 related ip6tables rules for bridge traffic.

Version-Release number of selected component (if applicable):
libvirt-0.7.1-15.fc12.i686

How reproducible:
Always

Steps to Reproduce:
1. Create an isolated network
2. try to communicate via IPv6 between nodes on this 
  
Actual results
No IPv6 packets received by other host


Expected results:
Packets receiving on other host


Additional info:
Unlike for IPv6, libvirt totally ignores IPv6 firewall setup for bridges:

IPv4:

# iptables -vnL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 



# ip6tables -vnL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  291 23568 REJECT     all      *      *       ::/0                 ::/0                reject-with icmp6-adm-prohibited 


Just note that such ACCEPT rules are required for ip6tables, too, manual setup helps currently, but libvirt should setup such rules also for IPv6.

--- Additional comment from pb@bieringer.de on 2010-03-07 10:57:06 EST ---

Here a small helper scriptlet, to be executed after related networks and IPv4 firewall rules are created by libvirtd. It supports at least isolated bridges:

It copies the related rules from FORWARD chain of IPv4 to IPv6.

r=0; iptables-save -t filter | grep '^-A FORWARD' | egrep '(-i virbr. -o virbr.|-i virbr. -j REJECT)' | sed 's/^-A FORWARD//' | sed 's/icmp/icmp6/' | while read line; do r=$[ $r + 1 ]; ip6tables -I FORWARD $r $line; done
Comment 2 RHEL Product and Program Management 2010-04-26 18:25:41 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 RHEL Product and Program Management 2010-04-27 07:41:34 EDT
This feature request did not get resolved in time for Feature Freeze
for the current Red Hat Enterprise Linux release and has now been
denied. You may re-open your request by requesting your support
representative to propose it for the next release.
Comment 5 Justin Clift 2010-10-15 06:49:26 EDT
As an additional data point, when looking at the dnsmasq man page today (version 2.52 on Fedora 13), it has this:

  Dnsmasq supports IPv6 for DNS, but not DHCP.

That will probably also need to be looked at when addressing this.
Comment 6 Daniel Berrange 2010-10-15 07:04:54 EDT
That isn't critical, because the IPv6 setup can use stateless autoconf instead of DHCP for IP assignment, and rely on DHCPv4 for picking up the nameserver addresses.
Comment 7 Laine Stump 2010-12-30 17:28:44 EST
A series of patches to implement this feature has been pushed upstream:

https://www.redhat.com/archives/libvir-list/2010-December/msg00915.html

It will be in the next rebase of libvirt for RHEL6.

commit 1ab80f32dd38462ef596c2af6b6d128a263ab0e5
    New virSocketAddr utility functions
commit 8322863fd59b8d5a6d13d9bfef0538d05e3f919f
    New virNetworkDef utility functions
commit cf7311892a282fe8de451fdb577dbcdb5d49cace
    Fix logging of failed iptables commands
commit 6e3e6db14fe80830cea3f427d8ff3fda7cc3f853
    Consistently return 0 on success, -1 on failure in bridge_driver.c
commit b23d417cc7d72f1a1f82053eb5fe1b47bd344007
    Pass prefix rather than netmask into iptables functions
commit 4713f074a5208599c1d1733c058e18c850527022
    Make virtual network netmasks optional
commit 20718b8bcbb0c1a15ca96083d2636a2445dde291
    Replace brSetInetAddress/brSetInetNetmask with brAddInetAddress
commit 008abeeeb9ffb0008433eb9933c0dc2263b75ac5
    make the <dhcp> element optional in network.rng
commit a950dd2a312b7263e221927f99f1e0e3f15eccc9
    Change virtual network XML parsing/formatting to support IPv6
commit ad48dfa15c2c7826d82905be13df7ff13d657588
    Support multiple IP addresses on one network in bridge_driver.c
commit 537e65e7b76aca61a6c367d06788810c6c980db5
    Update iptables.c to also support ip6tables.
commit 6ccce75240f2c8991be97b78f8a43ee7b6552733
    Turn on IPv6 support in the bridge_driver.c virtual network driver
commit 8090a56890457b192ff453a65f220c4b6617dc27
    Run radvd for virtual networks with IPv6 addresses
Comment 8 Jiri Denemark 2011-01-09 18:57:24 EST
Built into libvirt-0.8.7-1.el6
Comment 9 xhu 2011-01-11 01:28:21 EST
Verified it on RHEL6_x86_64 Server with the following component and it passed:
libvirt-0.8.7-1.el6
qemu-kvm-0.12.1.2-2.128.el6
kernel-2.6.32-94.el6

1 define and start the isolated network using the following xml:
# cat isolated_net.xml
<network>
        <name>isolatedbr1</name>
        <bridge name='br1' stp='on' forwardDelay='0'/>
        <ip address='10.0.0.1' netmask='255.255.255.0'>
                <dhcp>
                        <range start='10.0.0.2' end='10.0.0.254'/>
                </dhcp>
        </ip>
        <ip family="ipv6" address="2001:db8:ac10:fe01::1" prefix="64">
        </ip>
</network>

# virsh net-define isolated_net.xml
Network isolatedbr1 defined from isolated_net.xml

# virsh net-start isolatedbr1
Network isolatedbr1 started

2 check iptables and ip6tables rules:
# iptables -vnL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  br1    br1     0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      br1     0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  br1    *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable

# ip6tables -vnL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      br1    br1     ::/0                 ::/0
    0     0 REJECT     all      *      br1     ::/0                 ::/0                reject-with icmp6-port-unreachable
    0     0 REJECT     all      br1    *       ::/0                 ::/0                reject-with icmp6-port-unreachable

3 define and start two guest using isolatedbr1 network:
# virsh dumpxml test1
...
    <interface type='network'>
      <mac address='52:54:00:96:55:51'/>
      <source network='isolatedbr1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...

# virsh dumpxml test2
...
    <interface type='network'>
      <mac address='52:54:00:f3:32:4d'/>
      <source network='isolatedbr1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...

4 log into guest test1 and test2, config their ipv6 global addr and ping each other:
log into guest test1
# ifconfig eth0 inet6 add 2001:db8:ac10:fe01::2/64

log into guest test2
# ifconfig eth0 inet6 add 2001:db8:ac10:fe01::3/64

ping guest test2 ipv6 global addr in test1:
# ping6 2001:db8:ac10:fe01::3
PING 2001:db8:ac10:fe01::3(2001:db8:ac10:fe01::3) 56 data bytes
64 bytes from 2001:db8:ac10:fe01::3: icmp_seq=1 ttl=64 time=1.25 ms
64 bytes from 2001:db8:ac10:fe01::3: icmp_seq=2 ttl=64 time=0.213 ms
64 bytes from 2001:db8:ac10:fe01::3: icmp_seq=3 ttl=64 time=0.220 ms

ping guest test1 ipv6 global addr in test2i:
# ping6 2001:db8:ac10:fe01::2
PING 2001:db8:ac10:fe01::2(2001:db8:ac10:fe01::2) 56 data bytes
64 bytes from 2001:db8:ac10:fe01::2: icmp_seq=1 ttl=64 time=1.29 ms
64 bytes from 2001:db8:ac10:fe01::2: icmp_seq=2 ttl=64 time=0.206 ms
64 bytes from 2001:db8:ac10:fe01::2: icmp_seq=3 ttl=64 time=0.223 ms
Comment 11 Cui Chun 2011-01-31 21:24:45 EST
Rechecked it on the following test environment according to comment 9. It is passed.

Test environment:
libvirt-0.8.7-4.el6
qemu-kvm-0.12.1.2-2.132.el6
kernel-2.6.32-94.el6
Comment 12 Laine Stump 2011-05-03 11:32:52 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The virtual networks created/used by libvirt for virtual guest connectivity were previously limited to only IPv4 connectivity; IPv6 traffic was explicitly disallowed. With the inclusion of this feature, Full IPv6 connectivity is supported on libvirt's virtual networks, including autoconf address/route discovery and a DNS server listening on an IPv6 address on the network. (Since autoconf is supported, there is no support for DHCPv6)
Comment 13 Peter Bieringer 2011-05-03 14:59:49 EDT
Tried libvirt-0.8.8 on Fedora 14, can confirm that ip6tables ruleset setup is working like described in https://bugzilla.redhat.com/show_bug.cgi?id=586124#c9

BUT...why is ip6tables only adjusted, if an IPv6 address is configured?

An isolated network should setup iptables rules for IPv4 and IPv6 regardless whether an IPv4 or an IPv6 address is defined for such isolated network - this is imho completly independend. I want to use isolated networks to test router/dhcp/client setups, therefore DHCP servers or IPv6 helper services (like radvd or DHCPv6) should be optional, but not preventing setup the rules for the brige interfaces.
Comment 14 Peter Bieringer 2011-05-03 15:15:49 EDT
BTW: current behavior for IPv6 iptables rules is inconsistent to IPv4.

A config like:

<network>
  <name>isolated</name>
  <bridge name='virbr3' stp='on' delay='0' />
</network>

would create on activation iptables rules for IPv4, but not for IPv6 - this is not expected (at least by me).
Comment 17 Laura Bailey 2011-05-03 22:08:15 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-The virtual networks created/used by libvirt for virtual guest connectivity were previously limited to only IPv4 connectivity; IPv6 traffic was explicitly disallowed. With the inclusion of this feature, Full IPv6 connectivity is supported on libvirt's virtual networks, including autoconf address/route discovery and a DNS server listening on an IPv6 address on the network. (Since autoconf is supported, there is no support for DHCPv6)+The virtual networks created and used by libvirt for virtual guest connectivity were previously limited to only IPv4 connectivity; IPv6 traffic was explicitly disallowed. Full IPv6 connectivity is now supported on libvirt's virtual networks, including autoconf address/route discovery and a DNS server listening on an IPv6 address on the network. Note, however, that because autoconf is supported, there is no support for DHCPv6.
Comment 18 errata-xmlrpc 2011-05-19 09:18:23 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html

Note You need to log in before you can comment on or make changes to this bug.