Testing IPv6 Networking in KVM: Part 2
When last we met, in Testing IPv6 Networking in KVM: Part 1, we learned about IPv6 private addressing. Today, we're going to use KVM to create networks for testing IPv6 to our heart's content.
Should you desire a refresh in using KVM, see Creating Virtual Machines in KVM: Part 1 and Creating Virtual Machines in KVM: Part 2 - Networking.
Creating Networks in KVM
You need at least two virtual machines in KVM. Of course, you may create as many as you like. My little setup has Fedora, Ubuntu, and openSUSE. To create a new IPv6 network, open Edit > Connection Details > Virtual Networks in the main Virtual Machine Manager window. Click on the button with the green cross on the bottom left to create a new network (Figure 1).
Give your new network a name, then click the Forward button. You may opt to not create an IPv4 network if you wish. When you create a new IPv4 network the Virtual Machine Manager will not let you create a duplicate network, or one with an invalid address. On my host Ubuntu system a valid address is highlighted in green, and an invalid address is highlighted in a tasteful rosy hue. On my openSUSE machine there are no colored highlights. Enable DHCP or not, and create a static route or not, then move on to the next window.
Check "Enable IPv6 network address space definition" and enter your private address range. You may use any IPv6 address class you wish, being careful, of course, to not allow your experiments to leak out of your network. We shall use the nice IPv6 unique local addresses (ULA), and use the online address generator at Simple DNS Plus to create our network address. Copy the "Combined/CID" address into the Network field (Figure 2).
Virtual Machine Manager thinks my address is not valid, as evidenced by the rose highlight. Can it be right? Let us use ipv6calc to check:
$ ipv6calc -qi fd7d:844d:3e17:f3ae::/64 Address type: unicast, unique-local-unicast, iid, iid-local Registry for address: reserved(RFC4193#3.1) Address type has SLA: f3ae Interface identifier: 0000:0000:0000:0000 Interface identifier is probably manual set
ipv6calc thinks it's fine. Just for fun, change one of the numbers to something invalid, like the letter g, and try it again. (Asking "What if...?" and trial and error is the awesomest way to learn.)
Let us carry on and enable DHCPv6 (Figure 3). You can accept the default values, or set your own.
We shall skip creating a default route definition and move on to the next screen, where we shall enable "Isolated Virtual Network" and "Enable IPv6 internal routing/networking".
VM Network Selection
Now you can configure your virtual machines to use your new network. Open your VMs, and then click the "i" button at the top left to open its "Show virtual hardware details" screen. In the "Add Hardware" column click on the NIC button to open the network selector, and select your nice new IPv6 network. Click Apply, and then reboot. (Or use your favorite method for restarting networking, or renewing your DHCP lease.)
What does ifconfig tell us?
$ ifconfig ens3: flags=4163 UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.30.207 netmask 255.255.255.0 broadcast 192.168.30.255 inet6 fd7d:844d:3e17:f3ae::6314 prefixlen 128 scopeid 0x0 inet6 fe80::4821:5ecb:e4b4:d5fc prefixlen 64 scopeid 0x20
And there is our nice new ULA, fd7d:844d:3e17:f3ae::6314, and the auto-generated link-local address that is always present. Let's have some ping fun, pinging another VM on the network:
vm1 ~$ ping6 -c2 fd7d:844d:3e17:f3ae::2c9f PING fd7d:844d:3e17:f3ae::2c9f(fd7d:844d:3e17:f3ae::2c9f) 56 data bytes 64 bytes from fd7d:844d:3e17:f3ae::2c9f: icmp_seq=1 ttl=64 time=0.635 ms 64 bytes from fd7d:844d:3e17:f3ae::2c9f: icmp_seq=2 ttl=64 time=0.365 ms vm2 ~$ ping6 -c2 fd7d:844d:3e17:f3ae:a:b:c:6314 PING fd7d:844d:3e17:f3ae:a:b:c:6314(fd7d:844d:3e17:f3ae:a:b:c:6314) 56 data bytes 64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=1 ttl=64 time=0.744 ms 64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=2 ttl=64 time=0.364 ms
When you're struggling to understand subnetting, this gives you a fast, easy way to try different addresses and see whether they work. You can assign multiple IP addresses to a single interface and then ping them to see what happens. In a ULA, the interface, or host, portion of the IP address is the last four quads, so you can do anything to those and still be in the same subnet, which in this example is f3ae. This example changes only the interface ID on one of my VMs, to show how you really can do whatever you want with those four quads:
vm1 ~$ sudo /sbin/ip -6 addr add fd7d:844d:3e17:f3ae:a:b:c:6314 dev ens3 vm2 ~$ ping6 -c2 fd7d:844d:3e17:f3ae:a:b:c:6314 PING fd7d:844d:3e17:f3ae:a:b:c:6314(fd7d:844d:3e17:f3ae:a:b:c:6314) 56 data bytes 64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=1 ttl=64 time=0.744 ms 64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=2 ttl=64 time=0.364 ms
Now try it with a different subnet, which in this example is f4ae instead of f3ae:
$ ping6 -c2 fd7d:844d:3e17:f4ae:a:b:c:6314 PING fd7d:844d:3e17:f4ae:a:b:c:6314(fd7d:844d:3e17:f4ae:a:b:c:6314) 56 data bytes From fd7d:844d:3e17:f3ae::1 icmp_seq=1 Destination unreachable: No route From fd7d:844d:3e17:f3ae::1 icmp_seq=2 Destination unreachable: No route
This is also a great time to practice routing, which we will do in a future installment along with setting up auto-addressing without DHCP.