Bug 586124

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.

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.

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.

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.

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

Built into libvirt-0.8.7-1.el6

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

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

    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)

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.

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).

    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.

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