Internet Egress & NAT64 (IPv6 / IPv4)

The Berkelium cluster runs on an IPv6-native network architecture with transparent DNS64 and NAT64 translation. Your pods can connect directly to both native IPv6 endpoints and IPv4-only Internet services—including GitHub (github.com), PyPI (pypi.org), Hugging Face (huggingface.co), Docker Hub, and OS package repositories—out of the box without configuring any HTTP proxy environment variables.

Network Architecture Overview

Component	Address / Prefix	Purpose
Pod IPv6 Subnet (ULA)	`fdf5:542c:f102:92cf:1000::/100`	RFC 4193 Unique Local Addresses assigned to all pods (`eth0`).
Service IPv6 Subnet (ULA)	`fdf5:542c:f102:92cf:2000::/112`	Primary IPv6 `ClusterIP` range for Kubernetes Services.
Service IPv4 Subnet	`172.24.0.0/16`	Secondary IPv4 `ClusterIP` range for dual-stack Services (`PreferDualStack`).
Cluster DNS (CoreDNS + DNS64)	`fdf5:542c:f102:92cf:2000::a` `172.24.0.10`	Resolves cluster services and synthesizes `AAAA` records for IPv4-only domains.
LBNL NAT64 Prefix	`2620:83:8000:64::/96`	Wire-speed stateful NAT64 gateway translating synthesized IPv6 packets to external IPv4 hosts.

How DNS64 & NAT64 Work Together

Because Berkelium pods use RFC 4193 Unique Local Addresses (fdf5:542c:f102:92cf:1000::/100) and single-stack IPv6 pod interfaces:

Native IPv6 Destinations (e.g., google.com, cloudflare.com, registry.k8s.io):
- CoreDNS returns the upstream AAAA record.
- Traffic routes directly over LBNL’s high-speed IPv6 network (100 Gbps backbone).
IPv4-Only Destinations (e.g., github.com, api.github.com, files.pythonhosted.org):
- When an application queries a domain that only publishes an IPv4 A record (for example, github.com → 140.82.113.4), CoreDNS’s dns64 plugin automatically synthesizes an IPv6 AAAA record by embedding the 32-bit IPv4 address into LBNL’s NAT64 prefix (2620:83:8000:64::8c52:7104).
- Because pods have an IPv6 default route and no IPv4 route on eth0, Linux’s standard resolver (getaddrinfo) automatically selects the reachable synthesized IPv6 AAAA address.
- The LBNL border NAT64 router translates the packet between IPv6 and IPv4 transparently at line rate—supporting HTTPS, SSH (git@github.com), and arbitrary TCP/UDP protocols.

Example: Cloning from GitHub & Installing Packages in a Pod

No HTTP proxy configuration is required. Standard tools (git, pip, uv, conda, curl, wget, apt) work unmodified:

apiVersion: v1
kind: Pod
metadata:
  name: github-nat64-example
  namespace: <your-namespace>
spec:
  restartPolicy: OnFailure
  containers:
    - name: worker
      image: python:3.11-slim
      command: ["/bin/bash", "-c"]
      args:
        - |
          set -euo pipefail
          git clone https://github.com/octocat/Hello-World.git
          pip install --no-cache-dir requests numpy
          python -c "import requests; print(requests.get('https://api.github.com/zen').text)"

Best Practices for IPv6-First Workloads

1. Use DNS Hostnames Instead of Hardcoded IPv4 Literals

DNS64 relies on DNS resolution to synthesize 2620:83:8000:64::/96 addresses. Always configure external endpoints using their DNS hostname (e.g., https://api.example.com) rather than a raw IPv4 literal (e.g., https://198.51.100.42).

If you ever need to connect to an external IPv4 host that has no DNS hostname (for example, 140.82.113.4), you can embed the dotted-quad IPv4 address directly at the end of the LBNL NAT64 prefix:

curl -I https://[2620:83:8000:64::140.82.113.4]

Standard Linux and BSD socket libraries automatically parse the mixed IPv6+IPv4 notation (2620:83:8000:64::a.b.c.d).

2. Listening on Dual-Stack Sockets Inside Containers

When running a web server, API, or dashboard inside a pod (e.g., FastAPI, Uvicorn, Flask, Node.js, or Gunicorn) that will be exposed via a Kubernetes Service or HTTPRoute, bind your server to :: (which accepts both IPv6 and IPv4-mapped connections on Linux) or use dual-stack Service allocation:

# Uvicorn / FastAPI listening on IPv6/dual-stack
uvicorn app:main --host :: --port 8000

3. Legacy Frameworks Requiring IPv4 ClusterIPs (`PreferDualStack`)

Some distributed frameworks (such as Ray) hardcode IPv4 socket assumptions for internal node-to-node communication. For those Services, set ipFamilyPolicy: PreferDualStack in your Service manifest so Kubernetes allocates both an IPv6 (fdf5:542c:f102:92cf:2000::/112) and an IPv4 (172.24.0.0/16) ClusterIP. See the Distributed Ray Clusters Guide for an example.