Update CRD types to support IPv6 and dual-stack

[yangna0420]

Background

Part of the Supervisor workload network IPv6/dual-stack support initiative.
This PR extends the net-operator-api CRD types to support IPv6 and dual-stack
configurations for VDS-backed networks.

Changes

NetworkInterface

• Add Prefix *int32 to IPConfig — unified prefix length for both IPv4 and IPv6,
  takes precedence over SubnetMask when set. SubnetMask is now deprecated.
• Add IPFamilyPolicy to NetworkInterfaceSpec — values: IPv4Only, IPv6Only,
  DualStack. When unset, allocation is auto-detected from available IPPool families.

VSphereDistributedNetwork

• Add IPv6Gateway string — default IPv6 gateway for static-pool mode.
• Add IPv6Prefix *int32 — IPv6 prefix length (e.g. 64 for a /64 network).
• Add IPv6AssignmentMode — allows independent assignment modes for IPv4 and IPv6
  (e.g. static IPv4 pool + DHCPv6 for IPv6).

Network

• Add SupportedIPFamilies []corev1.IPFamily to NetworkStatus — exposes the IP
  families available on a network to regular users, who cannot read
  VSphereDistributedNetwork CRs due to RBAC restrictions.

Consumers

These changes are referenced by net-operator, vm-operator, and WCP service.

Self-testing:

1. We have run make generate and make lint locally. There is an error in make lint that there is no new file.
2. We have completed the integration test and announced our demo in Broadcom's lighting space

[ihgann]

I don't know what this is intended to mean. Is this saying that the default behavior is DualStack if available on the underlying Network?

[hkumar1402]

Should the default behavior be dictated by some global ipFamily behavior at VSphereDistributedNetwork level rather than assuming dual stack?

[yangna0420]

@ihgann @hkumar1402

1. If an IPFamilyPolicy is defined, ip will be allocated according IPFamilyPolicy.

2. If the IPFamilyPolicy is not defined, then it will continue to query the IPPools the NetworkInterface consumes.

• If the IPPools are dual-stack, two IPs for each IPFamily will be allocated.
• If all IPPools are single-stacks, only one ip will be assigned from the same IP family.

[yangna0420]

@ihgann Thanks for your comments, I have updated the description of IPFamilyPolicy, you could check the file api/v1alpha1/networkinterface_types.go

         // IPFamilyPolicy specifies the IP family policy for this network interface.
	// Values: IPv4Only, IPv6Only, DualStack.
	// When set to IPv4Only, only an IPv4 address will be allocated.
	// When set to IPv6Only, only an IPv6 address will be allocated.
	// When set to DualStack, both IPv4 and IPv6 addresses will be allocated.
	// If not specified, the allocation is determined by the IP families available in the
	// IPPools referenced by the backing Network: if both IPv4 and IPv6 pools are present,
	// one address per IP family will be allocated (equivalent to DualStack); if only a
	// single IP family is available, only one address of that family will be allocated.
	// Users can discover the supported IP families by inspecting the SupportedIPFamilies
	// field on the Network object.
	// +optional
	// +kubebuilder:validation:Enum=IPv4Only;IPv6Only;DualStack
	IPFamilyPolicy NetworkInterfaceIPFamilyPolicy `json:"ipFamilyPolicy,omitempty"`

[ihgann]

How would a user know which to request? At least in the Supervisor, user RBAC prevents regular users from reading VSphereDistributedNetwork CRs, so I think IPFamilyPolicy also needs to be expressed on the Network type?

[yangna0420]

@ihgann That's a great observation. I've added a SupportedIPFamilies []corev1.IPFamily field to NetworkStatus on the Network type (api/v1alpha1/network_types.go) — the Network viewer role already has aggregate-to-view: true so this is accessible to regular users. The net-operator controller will be responsible for populating this field during VSphereDistributedNetwork reconciliation by inspecting the IP families of the referenced IPPools. This gives users a clear signal of which IPFamilyPolicy values are valid for a given network.

[hkumar1402]

Should we just deprecate SubnetMask in favor of prefix length for both IPv4 and IPv6? We could add a comment saying if set, overrides SubnetMask for IPv4 and add a deprecated comment on SubnetMask.

[yangna0420]

@hkumar1402 Good point. I've updated the Prefix field to apply to both IPv4 and IPv6 (not just IPv6 as before), so it takes precedence over SubnetMask when set. SubnetMask is now marked as deprecated. This avoids a breaking change for existing consumers while providing a cleaner, unified API going forward. A follow-up to remove SubnetMask from the implementation layer can be tracked separately once all consumers have migrated.

[hkumar1402]

Do we need an additional field for IPv6 (IPv6AssignmentMode) to enable say static IPv4 assignment and DHCPv6 IPv6 assignment?

[yangna0420]

After talked with Hailing, I will update this patch to support the IPv6AssignmentMode.

[yangna0420]

@hkumar1402 Yes, absolutely needed. As you noted, a common dual-stack scenario is static IPv4 pool assignment with DHCPv6 for IPv6. I've added IPv6AssignmentMode to VSphereDistributedNetworkSpec. When unset, it falls back to IPAssignmentMode to preserve backward compatibility. The net-operator VDS provider will need a follow-up change to use IPv6AssignmentMode when allocating IPv6 addresses (I already discussed this with Hailing and will update that patch accordingly).