Feature: Implement IPv6 Networking Stack in the Cluster

[m-brando]

Motivation

Current claudie setup is using public IPv4 IPs for all nodes. Also internal communication between nodes is utilized using this public IPv4 address. Using public facing IPv4 potentially opens room for some security risks.

Description

Restrict ipv4 usage only for external access (e.g., client-facing services - kubeapi) and for internal communication use IPv6. To maintain backward compatibility, implement a dual-stack configuration for externally exposed services.

Exit criteria

• [ ] Implement IPv6 in the Claudie cluster

[m-brando]

After further evaluation, we've decided to postpone IPv6 implementation for now.

Below are the key pros and cons of using IPv6 in the Claudie setup:

✅ Advantages

• Built-in IPsec support: IPv6 natively supports IPsec for encryption and authentication. This means we could potentially avoid building an overlay network (e.g., WireGuard tunnels with tun interfaces) for internal communication, which might theoretically improve throughput

• No need for 1:1 NAT: With IPv6, we can avoid the 1:1 NAT mapping that some providers (e.g., GCP) require to expose VMs to the internet.

• Cost aspect: In most cases, cloud providers offer IPv6 addresses for free, unlike IPv4 addresses, which are often rented at an additional cost.

⚠️ Challenges

• Manual IPsec setup still required: Despite native support in IPv6, you still need a tool (e.g., StrongSwan, Racoon, etc.) to configure and manage IPsec tunnels. We'd also need to establish a full mesh across all sites.

• Performance concerns: Benchmarks show that IPsec is generally slower than WireGuard (WireGuard performance), which could impact cluster communication performance.

• Provider limitations: RunPod currently does not support IPv6, limiting our deployment options.

💬 Additional Discussion (Slack Huddle) We also discussed the implications of using private IPv4 addresses behind NAT (with no possibility to do DNAT) when IPv6 is not used:

In this case, we would deploy a hub instance (VPN concentrator) using public IPv4 that accepts connections from other nodes.
In this scenario nodes without public IPv4 address could still connect to the overlay network (e.g., via WireGuard), ensuring successful communication within the cluster.