@yordsel Could you create issues in container and containerization that describe the use case for this? We'll want those for something of this scope.

As a starting point, see my comment at the bottom of apple/container#1004.

The vmnet framework handles all of the networking for us. We tell it what we want (today a NAT bridge with external access, or a host-only NAT bridge), and optionally specify a subnet (CIDRv4) or prefix address (CIDRv6). What we don't specify, vmnet will assign for us (which is generally best for IPv4 as you'll better avoid conflicts).

For IPv6 if you let vmnet use the defaults, you'll get an /64 prefix with SLAAC with EUI-64 derived IPv6 addresses and Linux networking will take care of everything (except for the DNS server, for which I have most of the code ready to go).

If you set a /64 prefix without calling vmnet_network_configuration_disable_nat66(), you'll get this automatic behavior as well.

If you disable NAT66 or if you use a prefix other than /64, then I think what you have here becomes useful. The issue you file for container should describe how container or any other containerization client will use what you have here to bring things up. If you can demonstrate to yourself that all this works using cctl that's even better.

We'll want tests for as much as you can. For example, have your AI assistant of choice add unit tests to check packet parsing for the netlink calls you're adding/refactoring, like the ones that already exist, and then look them over to make sure they make sense to you. These are primarily useful as regression tests once we know that everything works; for example, the ones that are already there are validating your ipv4/ipv6 extracted methods.