By Yair Knijn · August 27, 2025
The IPv6-only mandate had a date. Your procurement team treated it as optional.
The infrastructure director read OMB M-21-07 the way most people read a five-year plan: a direction of travel, something the architecture team would get to once the dual-stack pilots looked clean. The memo said IPv6-only. He heard "eventually IPv6." So the procurement team kept renewing on IPv4, kept the pilots in a corner of the lab, and treated the milestone as a maturity score nobody grades.
Then a contract renewal came back with an IPv6-only operating requirement attached, and the gap stopped being a roadmap line. It became a disqualifier.
What OMB M-21-07 actually mandated, and the FY2025 deadline
M-21-07 is not aspirational. It set a dated target: at least 80% of IP-enabled assets on federal networks operating in IPv6-only environments by the end of fiscal 2025, which closed on September 30, 2025. Not dual-stack. IPv6-only, with IPv4 retired from those assets rather than parked alongside. Agencies that missed FY2025 didn't get a reprieve; they inherited a harder staircase: 60% by FY2026, 80% by FY2027, 100% by FY2028. The deadline moved the penalty, not the requirement.
How the IPv6-only requirement flows down to contractors
The part directors miss is the reach. M-21-07 covers systems used, managed, or operated by a contractor on the government's behalf, and it pairs with FAR 11.002(g), which obligates agencies to require IPv6 capability when procuring new networked IT products and services. That is the flow-down mechanism. An agency under the mandate cannot buy non-conforming capability, so the requirement lands in the solicitation, then in the prime's subcontract, then on the desk of whoever runs your network. If your IP-enabled service can't operate IPv6-only, you are not a low score on a scorecard. You are non-responsive.
Dual-stack pilot purgatory: why orgs stall here for years
Dual-stack feels like progress because everything keeps working. You add AAAA records, light up IPv6 on a few segments, and call it momentum. The trap is that dual-stack is the easy 40%, and the mandate measures IPv6-only. Getting to "only" means the part teams avoid:
- Hardcoded
IPv4literals in firewall rules, application configs, and monitoring checks that nobody documented. - An addressing plan improvised per-pilot, so two segments overlap inside the same
/48and no one can prove which prefix is authoritative. - Vendors and internal tools that "support IPv6" in a datasheet but break when
IPv4is actually removed.
So the pilot never graduates. Each segment is a one-off, the address space is a guess, and the org spends years at 30-40% because it never built the inventory that turning off IPv4 demands.
An IPAM that can plan, allocate, and audit IPv6 space
Getting out of purgatory is an addressing-discipline problem before it is a routing problem. You need a single plan for the /48 you were assigned, allocations carved from it on purpose instead of per-pilot, and an audit trail that reconciles what you intended against what DHCPv6 and DNS actually serve. Without that, "are we IPv6-only on this asset" is an opinion, and an opinion does not pass a contract gate.
Spot IPAM treats the IPv6 transition as a tracked allocation problem, not a spreadsheet someone updates after the fact. Plan a prefix hierarchy from your assigned /48, allocate without overlap, and audit each Environment against live DHCP and DNS so "IPv6-only" is a state you can demonstrate, segment by segment, on the day procurement asks. See how the allocation and audit model works on the features page.