The virtual network has never supported NAT with IPv6 since this feature
didn't exist at the time. NAT has been available since RHEL-7 vintage
though, and it is desirable to be able to use it.
This series enables it with
<forward mode=3D"nat">
<nat ipv6=3D"yes"/>
</forward>
Note that I do NOT actually change the default.xml to enable use of IPv6
because that will cause failure if the user has force disabled IPv6 on
their host kernel.
Of course our current default.xml is already broken if someone has done
the reverse and force disabled IPv4.
We've also long had a problem with guests bringing up the default
network with the same subnet as the host. We'll have this same issue
with IPv6 too.
On my prompting Laine proposed a way to deal with the clash by tearing
down a network, if we see a real host NIC get assigned the same subnet.
Meanwhile we also have complaints about the fact that libvirt does
anything todo with networking in the %post of the RPM.
I'm thinking that we can do something entirely different by introducing
a concept of "automatic subnet selection" into the virtual network.
Consider if we made default.xml be able to contain only:
<network>
<name>default</name>
<forward/>
<ip family=3D"ipv4" autoaddr=3D"yes">
<dhcp/>
</ip>
<ip family=3D"ipv6" autoaddr=3D"yes"/>
</network>
Conceptually this means
- Try to gimme a subnet with IPv4 and DHCP
- Try to gimme a subnet with IPv6 and RAs
Now when we start the virtual network
- If IPv4 is not enabled on host, don't assign addr
- Else
- Iterate N=3D1..254 to find a free range for IPv4
- Use 192.168.N.0/24 for subnet
- Use 192.168.N.1 for host IP
- Use 192.168.N.2 -> 192.168.N.254 for guest DHCP
- If IPv6 is not enabled on host, don't assign addr
- Else
- Generate NNNN:NNNN as 4 random bytes
- Use fd00:add:f00d:NNNN:NNNN::0/64 for IPv6 subnet
- Use fd00:add:f00d:NNNN:NNNN::1 for host IP
- Use route advertizement for IPv6 zero-conf
With NNNN:NNNN, even with 1000 guests running, we have just a 0.02%
chance of clashing with a guest for IPv6.
The "live" XML would always reflect the currently assigned addresses
Proactively monitor the address allocations of the host. If we see
a conflicting address appear, take down the dnsmasq intance, generate
a new subnet, bring dnsmasq back online.
Ideally we would have to bring the guest network links offline and
then online again to force DHCP re-assignment immediately.
In v2:
- Fix short circuit XML closing tag
- Fix error checking in enum conversion
- Fix docs typos
- Improve RNG schema
Daniel P. Berrang=C3=A9 (3):
util: add support for IPv6 masquerade rules
conf: add an attribute to turn on NAT for IPv6 virtual networks
network: wire up support for IPv6 NAT rules
docs/formatnetwork.html.in | 14 ++
docs/schemas/network.rng | 5 +
src/conf/network_conf.c | 30 ++-
src/conf/network_conf.h | 2 +
src/network/bridge_driver_linux.c | 23 +-
src/util/viriptables.c | 33 +--
.../nat-ipv6-masquerade-linux.args | 228 ++++++++++++++++++
.../nat-ipv6-masquerade.xml | 17 ++
tests/networkxml2firewalltest.c | 1 +
.../nat-network-forward-nat-ipv6.xml | 10 +
.../nat-network-forward-nat-ipv6.xml | 10 +
tests/networkxml2xmltest.c | 1 +
12 files changed, 342 insertions(+), 32 deletions(-)
create mode 100644 tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.a=
rgs
create mode 100644 tests/networkxml2firewalldata/nat-ipv6-masquerade.xml
create mode 100644 tests/networkxml2xmlin/nat-network-forward-nat-ipv6.xml
create mode 100644 tests/networkxml2xmlout/nat-network-forward-nat-ipv6.xml
--=20
2.26.2
