Summary

Federal agencies are under a clear mandate to move to IPv6, but doing it inside a live, security-controlled cloud enclave without disrupting the applications running on it is a genuine engineering challenge. When Samtek took on the IPv6 enablement for the Centers for Clinical Standards and Quality (CCSQ) Cloud (QNET) environment, we set out to modernize the network without redesigning it, without weakening security, and without interrupting the application teams who depend on it every day.

Over an 18-month, phased rollout, Samtek layered a dual-stack IPv6 architecture onto the existing hub-and-spoke environment, automated every change through Terraform, and centrally governed IPv6 addressing with AWS IPAM. The result was a future-proofed network that meets federal IPv6 direction, preserves the same security controls that governed IPv4, and is ready for the next wave of cloud and AI-driven workloads.

The Challenge: Modernize the Network Without Breaking It

IPv4 addresses are running out, and federal guidance (OMB M-21-07) directs agencies to move toward IPv6-only environments. For CCSQ, the drivers were practical as well as regulatory: scalability, better end-to-end connectivity, and room to grow.

The difficulty is that CCSQ Cloud is not a greenfield. It is an established, tightly governed enclave built on a hub-and-spoke topology, where all traffic flows through centralized routing and security-inspection VPCs, and no application VPC is allowed direct internet access. Any IPv6 effort had to respect three hard constraints:

• No topology redesign. The existing hub-and-spoke security model had to stay intact.
• No security bypass. IPv6 traffic could not be allowed to slip around the controls that governed IPv4.
• Minimal disruption. Application Development Organizations (ADOs) needed to keep working throughout.

Our Approach: A Phased, Automated, Security-First Migration

Samtek executed the enablement as a deliberate, phased program aligned to the Agile Program Increment (PI) cadence. Each phase had defined milestones, testing, validation, and end-of-sprint demonstrations before the next phase began. Here is how we did it.

Dual-stack first, IPv6-only as the destination

Rather than a risky “big bang” cutover, we enabled IPv6 alongside the existing IPv4 addressing (dual-stack). This preserved backward compatibility and minimized disruption, while positioning the environment for eventual IPv6-only operation in line with OMB M-21-07. We layered IPv6 in incrementally at each tier — Transit Gateway, hub VPC, inspection VPC, spoke VPCs, subnets, and finally instances.

Security parity, by design

A core principle was that IPv6 traffic would be subject to the exact same inspection, firewall, and F5 SSL-orchestration policies as IPv4 — with no bypass paths. All IPv6 outbound traffic continued to route through the centralized outbound gateway VPC, consistent with the existing governance model. Security group and NACL rules were explicitly authored for IPv6 rather than inherited, following a least-privilege, compliance-by-design approach.

Centralized, standardized addressing with AWS IPAM

We used AWS IPAM to centrally allocate IPv6 Global Unicast Address space, cascading from an organization-wide pool down to regional and account-level pools. Addressing followed consistent, non-overlapping Classless Inter-Domain Routing (CIDR) standards — a /56 per VPC and /64 per subnet — and separate IPAM pools per lifecycle kept environments like sandbox and production properly isolated. Utilization monitoring and pool-exhaustion alerting supported ongoing capacity planning.

Infrastructure as Code, no manual changes

Every architectural change was implemented and version-controlled in Terraform — no manual console edits. We extended our VPC, subnet, route table, IPAM, and Transit Gateway modules for dual-stack support, using backward-compatible versioning so existing IPv4-only deployments kept working during the transition. We also updated Golden Image AMIs (Windows and Linux) and EC2 bootstrap scripts to bake in IPv6 support at both management and functional interfaces.

Clear roles and constant communication

To coordinate across many teams, we built and socialized a Responsible, Accountable, Supportive, Informed, and Consulted (RASIC) responsibility matrix spanning the ADOs, Cloud Operations, Cloud Architecture, and Solutions Engineering. Regular communications kept the ADO community informed of upcoming activities and set expectations for each phase, and we provided IPv6 resources, training, and guides to help teams enable IPv6 in their own workloads.

Lessons From the Field

An honest migration story includes the hard parts, and this one surfaced several that are worth sharing:

• Dual-stack is not “set it and forget it.” It requires continuous validation, not a one-time switch.
• ICMPv6 matters. Initially blocking it broke Neighbor Discovery and Path MTU Discovery (PMTUD) — a reminder that IPv6 behaves differently than IPv4.
• Not every tool is ready. We worked around third-party gaps, including IPv6 support limitations in identity and security-inspection tooling.
• Automation must be IPv6-aware from the start, and strong governance is needed to prevent quiet fallback to IPv4-only habits.
• Early engagement with security, compliance, and application owners avoids rework later.

Results

Samtek delivered a fully dual-stack IPv6 capability across the CCSQ Cloud enclave while keeping the environment’s security posture and hub-and-spoke governance model fully intact. Qualitatively, by the close of the effort:

• IPv6 was extended across the enterprise — from Transit Gateway and gateways down to subnets and instances — with dual-stack Golden Image AMIs for both Windows and Linux.
• The same centralized inspection and egress controls that governed IPv4 now govern IPv6, with no bypass paths.
• Addressing is centrally governed and standardized through AWS IPAM, and the entire configuration is codified in Terraform for repeatable, auditable change.

Results by the Numbers

• 138 AWS accounts and 170 VPCs dual-stack IPv6 enabled
• 29 application teams (ADOs) enabled with IPv6 resources, training, and guides
• 26 Network Appliances dual stack enabled
• 100% Terraform modules extended for dual-stack and successfully deployed via IaC (no manual console edits)
• 100% of the enclave dual-stacked enabled with zero unplanned outages / 0 hours of downtime
• IPV6 Migration completed across 6 Program Increments over 16 months, on schedule

Conclusion

Enabling IPv6 across a live, security-governed cloud enclave to IPv6 is as much an exercise in coordination and governance as it is in networking. By pairing a disciplined, phased approach with automation-first execution and an uncompromising stance on security parity, Samtek modernized CCSQ’s network while keeping operations steady for the teams that rely on it.

If your organization is planning an IPv6 transition — or wants to modernize cloud networking at scale without disrupting the mission — Samtek is ready to help. Reach out to start the conversation.