Summary
Once the NAT64 gateway design in
enhancements/networking/nat64-gateway-for-vpc-networks.md
(the design deliverable for #866)
is implemented, update that document — or add operator/tenant-facing
docs alongside it — to reflect the as-built solution rather than the
proposed design. The design is phased (Phase 1: node-local shards
mirroring galactic-nat66; Phase 2: anycast SID + regional session
state, deferred until demonstrated need), so the as-built write-up should
be explicit about which phase actually shipped and where the
implementation diverged from the proposal.
Scope
- Reconcile the design doc's Design Details
section (data-plane integration point, shard/CRD shape, SRv6 Argument
usage, session-limit enforcement) against what was actually built —
update the doc, or note divergences with rationale, rather than leaving
a stale proposal as the only record.
- Fill in the sections the design doc explicitly left as
TBD /
open questions once real decisions were made during implementation:
- The per-tenant session visibility API/CRD surface (left open in
Per-tenant session limits)
- Whether
NAT64Shard shipped as its own CRD or was generalized with
NAT66Shard into a shared EgressShard-style type
- The final choice of NAT64 prefix (RFC 6052 well-known
64:ff9b::/96
vs. a Datum-operated NSP)
- Monitoring/SLIs actually exposed (the design doc flags these as
entirely missing pre-implementation)
- Update the Production Readiness Review Questionnaire
answers marked "not yet" / "TBD" with real answers from the shipped
implementation and its rollout.
- Update the design doc's front-matter
status/stage fields
(currently provisional/alpha) to reflect implemented status.
- Record whether Phase 2 (anycast + regional session state) was
triggered, and if so, document its as-built shape as well — this issue
covers documenting whichever phase(s) actually ship.
Additional Context
- Parent enhancement: #791
- Design/discovery: #866
- Related: #792 (DNS64 — document its as-built state under its own issue, not here)
Summary
Once the NAT64 gateway design in
enhancements/networking/nat64-gateway-for-vpc-networks.md
(the design deliverable for #866)
is implemented, update that document — or add operator/tenant-facing
docs alongside it — to reflect the as-built solution rather than the
proposed design. The design is phased (Phase 1: node-local shards
mirroring
galactic-nat66; Phase 2: anycast SID + regional sessionstate, deferred until demonstrated need), so the as-built write-up should
be explicit about which phase actually shipped and where the
implementation diverged from the proposal.
Scope
section (data-plane integration point, shard/CRD shape, SRv6 Argument
usage, session-limit enforcement) against what was actually built —
update the doc, or note divergences with rationale, rather than leaving
a stale proposal as the only record.
TBD/open questions once real decisions were made during implementation:
Per-tenant session limits)
NAT64Shardshipped as its own CRD or was generalized withNAT66Shardinto a sharedEgressShard-style type64:ff9b::/96vs. a Datum-operated NSP)
entirely missing pre-implementation)
answers marked "not yet" / "TBD" with real answers from the shipped
implementation and its rollout.
status/stagefields(currently
provisional/alpha) to reflect implemented status.triggered, and if so, document its as-built shape as well — this issue
covers documenting whichever phase(s) actually ship.
Additional Context