VM Networking improvements

[hoh]

With contributions from @tomribbens

• 1. IP ranges used by VMs should be updated because they are not following RFC1918

• 2. Network configuration commands are changed from iptables to nft

• Port forwarding - from a public IPv4 port on the host to a port on the guest
  Dedicated issue: As a VM developer, I would like to talk with a VM using raw TCP sockets #148
  Related: Feature: IPv4 port mapping could not be defined aleph-message#30

• IPv6 access to every virtual machine
  Dedicated issue: VMs don't have IPv6 access #221

• A Wireguard VPN between virtual machines from the same user, across hosts.

Notes

• Using the same IPv4 range inside VMs on all tap networks might be possible.
• Using the same Tap interface for all VMs of a user’s cluster would be ideal.

Include (and improve) the cleanup of network configuration on VM stop and on supervisor crash/start.

[hoh]

Solving this issue as well would be handy: #18

[tomribbens]

I've been looking at point 1, on making the ip addresses RFC1918 compliant. The easy way obviously would be to limit the vm_id generated to be limited to 4096 (assigning /24 networks out of 172.16.0.0/12 gives 12 bits to work with) and then modifying the guest_ip and host_ip functions in firecracker/microvm.py to f"172.{16 + self.vm_id // 256}.{self.vm_id % 256}.1".

There are 2 issues with that:

• This puts a hard limit on amount of VMs at 4096, which I understand is bordering on potentially not enough
• This is not flexible at all if in the future a change to another address pool is wanted

I would propose as a solution to make two new settings, VM_ADDRESS_POOL and VM_NETWORK_SIZE. This would make everything more flexible on a host per host basis.

However, this would mean passing those settings to the MicroVM class, which doesn't seem to be cleanest either. Therefor I would propose to move the calculation of the ip addresses out of firecracker/microvm.py and into functions called by the create_a_vm() function. This seems cleaner as the VM logic itself has no business determining the IP addresses, but should be a function in the supervisor anyway.

Additionally, this would make it easier in the future when looking at using a single tap interface per user, as at that point more knowledge about other VMs is required to determine which IP address to hand out, which is clearly a supervisor task.

[hoh]

That reads like the right way to go ! 👍

[tomribbens]

Did some research into sharing the tap interface between multiple hosts. As I understand it currently, this would require the tap interface to be set with the option multi_queue, but this currently is not supported by Firecracker:

firecracker-microvm/firecracker#750