Internet NAT64 gateway #684

High-Level Summary

Add NAT64 to Galactic VPC's Internet Gateway (IGW): a stateful IPv6-to-IPv4 translation service that lets IPv6-only compute instances reach the legacy IPv4 internet without a dual-stack NIC, a bump-in-the-wire NAT appliance, or any change to the instance's networking config. Tenants provision IPv6-only instances as they do today; outbound traffic to IPv4-only destinations is translated at the IGW and returned untranslated to the originating instance.

Motivation

Galactic VPC's IPv6-only instance type has no path to the IPv4 internet today, and a meaningful chunk of the internet — legacy APIs, vendor endpoints, CDNs without AAAA records — is still IPv4-only. Tenants adopting IPv6-only compute to cut address management overhead currently have to choose between reverting to dual-stack (defeating the point) or running their own NAT64 translator inside the VPC, which pushes an operational burden onto the tenant that we're better positioned to run centrally and correctly. This is table-stakes connectivity for any provider offering IPv6-only compute; without it, IPv6-only is a curiosity, not a real deployment option. RFC 6146 defines the mechanism — nothing novel required on the standards side, this is about integrating it cleanly into our SRv6/IGW data plane and making it operate at Datum scale.

Goals

Phase 1 (ships first — closes the gap; nothing in the fabric provides IPv4 egress today):

• IPv6-only instances can reach IPv4-only destinations on the internet without any tenant-side configuration, NAT64 prefix handling, or client-side awareness that translation is happening
• NAT64 translation reuses the exact operational pattern our existing NAT66 tier already proves out in production: node-local, sharded translation gateways, with a tenant VRF's traffic routed to an assigned shard at attachment time
• Per-tenant session isolation is enforced via the SRv6 Argument field on the shard's NAT64 locator, so no tenant's translation table or session load can affect another tenant's
• Tenants get visibility into NAT64 session counts and can see when they're approaching a documented per-tenant session limit, with the limit enforced before it degrades other tenants
• This ships and is validated alongside DNS64 (#792): an IPv6-only instance resolving an IPv4-only name via DNS64 must successfully connect through this NAT64 path end to end

Phase 2 (deferred until Phase 1's one real limitation — a shard restart breaks the sessions it was servicing — is a demonstrated operational problem, not built speculatively ahead of that evidence):

• NAT64 translation is advertised via an anycast SID so any gateway node in-region can service a session, rather than a session being pinned to whichever shard a tenant's VRF was assigned to
• Translation sessions are held as regional state — a session survives failover between gateway nodes within a region without breaking the connection

Non-Goals

• Anycast SID advertisement and regional session state in Phase 1 — explicitly deferred to Phase 2, not silently dropped. Phase 1 accepts the same per-shard failure mode our existing NAT66 tier already accepts today.
• No support for inbound NAT64 (IPv4-only clients initiating connections to IPv6-only instances), in either phase — this is outbound-only, matching the actual tenant demand signal
• No NAT64 across regions, in either phase — a session is regional-at-most state even once Phase 2 ships; cross-region session-state replication is a materially larger problem neither phase takes on
• No tenant-configurable translation prefix or custom NAT64 behavior — one Datum-managed well-known prefix, no per-tenant customization in either phase
• No changes to the DNS64 resolver behavior itself — that's a separate enhancement (#792); this enhancement is scoped to the translation data path and its session/SID architecture