atenet: bind the Envoy sockets and Services dual-stack

[Yuan Gao (ygao-g)]

Fixes #910
Part of #246

It's a good idea to open an issue first for discussion.

• Tests pass
• Appropriate changes to documentation are included in the PR (none needed — no flags, APIs, or user-facing behaviour change)

---

The router and egress manifests bind the IPv4 wildcard on every Envoy socket, and neither gateway's Service asks for a second IP family. On a dual-stack cluster the router answers on its IPv4 ClusterIP and on nothing at all for IPv6; on an IPv6-primary cluster the kubelet cannot probe the pod on its only address, so atenet-egress crashloops while Envoy itself starts fine.

Both gateways now bind :: as well, and both Services ask for PreferDualStack. A new hack/verify check guards the ipv4_compat flag that the in-pod loopback callers depend on, since nothing else in the tree reads these manifests. The experimental atenet-egress-with-sdsmint.yaml variant is deliberately out of scope.

This makes both gateways accept IPv6; it does not make them reach IPv6 destinations. The egress dns_lookup_family, the DNS AAAA path, and atunnel's original-destination lookup stay IPv4, and are tracked in #246 and #686.

Testing

CI has no IP-family matrix, so the green e2e run here is the IPv4 regression check and nothing more. The other two families were verified by hand on kind, using IP_FAMILY from #877.

• Dual-stack. The networking suite passes with zero skips: an actor is reached over each of the router's ClusterIPs, and an IPv4 actor transits the egress [::]:443 socket. Reverting only the two bind lines turns those assertions red, so they are not passing vacuously. ipv4_compat was read from /config_dump — /listeners never emits it.
• IPv6-only, with the kind CoreDNS fix from hack: fix DNS on IPv6-only kind clusters #958 underneath. atenet-egress goes from 1/2 CrashLoopBackOff (64 restarts, startup probe refused) to 2/2 Running, and TestActorDirectAccess passes, including through the router's ingress. TestActorEgress still fails inside the actor's netns, which is ateomnet: enable IPv6 forwarding in worker pod netns #979's scope.

🤖 Generated with Claude Code

[Yuan Gao (ygao-g)]

Bowei Du (@bowei) mind taking a look?

[Bowei Du (bowei)]

Do we want to sync up the configuration in the YAML with the configuration here?

[Bowei Du (bowei)]

Actually, the comment here might have confused me. This is talking about two different sockets? If it is, can you remove the comment above.

[Yuan Gao (ygao-g)]

Yes, two different sockets. And I have removed the confusing comments.

This is the router's ingress data-plane listener; the ipv4_compat: true you saw in the YAML is the Envoy admin socket on 9901. I've cut the comment down to the one line explaining why Ipv4Compat is false here — the cross-reference to the admin socket was the confusing part and it's gone.

On the original question: the admin sockets can't take this shape anyway, since bootstrap.v3.Admin has a single address field and no additional_addresses — one :: socket with ipv4_compat is the only way to serve both families there. The egress :443 listener is a real Listener, so that one could match the ingress shape if you'd rather have a single idiom across listeners. Happy to do it; it's a few lines plus the test that asserts the current shape.

[Yuan Gao (ygao-g)]

Happy to switch if you'd rather have it — but I think the two shapes are equivalent here, so it's a style call rather than a correctness one.

The reason to keep an IPv4 primary is to stop v4 peers arriving as ::ffff:-mapped addresses. Nothing on either path reads the downstream peer: ingress ext_proc requests one attribute, the authority filter-state (xds.go:1016), and egress requests one, xds.filter_chain_name (atenet-egress.yaml:134-135). There's no use_remote_address, no XFF config and no DOWNSTREAM_REMOTE_ADDRESS in cmd/atenet or either manifest, and the original_dst on ingress is the destination ext_proc supplies in dynamic metadata, not the source.

I kept egress as one socket to match the admin listener in the same file, which is :: + ipv4_compat: true and where the flag is load-bearing — the drain sequence dials 127.0.0.1:15000 (atenet-egress.yaml:310), as the comment at line 40 already notes. The symmetric move doesn't exist: ingress can't take ipv4_compat while keeping its 0.0.0.0 primary, because both would bind IPv4:port — that's what "collide with that primary" means at xds.go:1113.

So it's one idiom within the file against one across the component, and I don't have a strong preference. Say which you'd rather see and I'll match it — a few lines plus the test.