feat(network): support policy DNS IPv6 egress across the sandbox–supervisor boundary #3716

User Story

As an operator of an IPv6-only sandbox host, I want policy-approved native TCP clients to resolve and connect through the sandbox–supervisor boundary, so that they can reach approved services without adding an IPv4 route or changing the client to use an explicit proxy.

Problem Statement

Policy DNS currently suppresses AAAA answers in production. On an IPv6-only host using DNS64/NAT64, an allowed hostname may have no usable A answer, so a native TCP client cannot connect. IPv6 support needs an end-to-end contract for DNS answers, destination validation, TCP mediation, and runtime capability across the sandbox–supervisor topology. PR #3702 proposes the first implementation but does not yet establish that full contract with automated integration coverage.

Impact / Why This Matters

Today an operator must supply a working IPv4 path, use an application-specific proxy configuration, or avoid native TCP clients. Those workarounds may be unavailable on IPv6-only hosts and do not preserve the intended protocol: tcp workflow. Enabling AAAA without equivalent destination checks and isolation evidence would make behavior differ between address families.

Proposed Design

For a runtime with usable IPv6 egress, an eligible protocol: tcp hostname can return a supervisor-owned synthetic AAAA answer. Connecting to it must follow the same hostname, port, process, policy-generation, destination-validation, and pinned-dial contract as an A answer. A runtime without usable IPv6 egress continues to provide a working A-record path where available. The selected AAAA behavior is applied consistently across supported policy DNS transports and sandbox runtimes, and operators can see the active behavior in diagnostics. Unsupported configurations fail clearly.

Acceptance Criteria

• On an IPv6-only DNS64/NAT64 host, a sandbox native TCP client resolves an allowed hostname via both UDP and TCP DNS, connects through the sandbox–supervisor boundary, and reaches a pinned approved destination with proxy variables unset.
• IPv4-only and dual-stack hosts retain their working A-record behavior; explicit IPv6 mode selection has the documented effect on every supported policy DNS runtime.
• A and AAAA answers enforce equivalent destination and SSRF controls, including private, loopback, link-local, metadata, allowed-IP, exact-host, and translated-destination cases, with review through the private security process where appropriate.
• Direct real-IP connections, unknown or expired synthetic addresses, wrong ports, stale policy generations, denied process identities, and unavailable mediation fail closed for both address families.
• IPv6 traffic cannot bypass the sandbox's mandatory outer fence or the supervisor's authoritative authorization and pinned dialing.
• Automated unit and end-to-end tests cover the IPv6-only sandbox–supervisor path, negative cases, and IPv4/dual-stack regressions on applicable runtimes. A live smoke test alone is insufficient.
• Published documentation states runtime support, automatic and explicit mode behavior, and failure behavior accurately.

Alternatives Considered

Always returning AAAA answers would cause clients on runtimes without working IPv6 egress to select unusable destinations. Returning real DNS addresses would lose the synthetic mapping that keeps hostname and policy identity distinct when services share an IP. Application-specific proxy configuration does not meet the native TCP user story.

Agent Investigation

• PR feat(supervisor): IPv6 policy DNS egress and NAT64-aware SSRF checks #3702 adds route-based AAAA mode selection and tests DNS response mapping plus a supervisor-side authorized TCP open. Its PR description reports one live IPv6-only smoke test, but no IPv6-only automated end-to-end lane.
• The sandbox broker accepts AF_INET6 sockets and mediates nonlocal TCP opens; the new PR tests do not exercise the complete socket-to-relay path from an IPv6 sandbox client.
• Existing issue feat(network): enable policy DNS and transparent TCP egress #2712 tracks the broader original policy DNS/native TCP implementation and is closed. This issue tracks the IPv6 enhancement and its acceptance evidence.