Add IPv6 support for LinuxContainer

[yordsel]

Summary

• Add IPv6 address and route configuration to LinuxContainer, matching existing LinuxPod functionality
• Extend NetlinkSession with IPv6 support methods (addressAdd6, routeAddDefault6)
• Update vminitd gRPC handlers to support IpAddrAdd6 and IpRouteAdd6 requests
• Add ipv6Gateway field to NATInterface and NATNetworkInterface protocols

Details

LinuxContainer was missing IPv6 configuration that LinuxPod already had. This adds the missing calls to configure IPv6 addresses and routes on the network interface inside Linux containers when IPv6 is available.

The implementation follows the existing IPv4 patterns and reuses internal helper methods to avoid code duplication.

Test plan

• Verified IPv6 connectivity from host to container (ping6)
• Verified IPv6 connectivity between containers
• Verified DNS resolution for both A and AAAA records
• Verified backward compatibility with IPv4-only networks

🤖 Generated with Claude Code

[jglogan]

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