Is there a status page for this initiative?
“Develop an IPv6 implementation plan by the end of FY 2021, and update the Information Resources Management (IRM) Strategic Plan as appropriate, to update all networked Federal information systems (and the IP-enabled assets associated with
these systems) to fully enable native IPv6 operation. The plan shall describe the agency transition process and include the following milestones and actions:
“Cisco IT is Customer Zero for IPv6-only inside our networks” -
Transitioning to IPv6 for Simplicity, Efficiency, and Modernization - Cisco Blogs
From: Matthew Petach <mpetach@netflight.com>
Sent: March 31, 2022 2:54 PM
To: Jacques Latour <Jacques.Latour@cira.ca>
Cc: Mark Andrews <marka@isc.org>; NANOG <nanog@nanog.org>
Subject: [EXT] Re: IPv6 Only
On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <Jacques.Latour@cira.ca> wrote:
Exactly what I was asking, when and how will we collectively turn off the lights on IPv4?
Working on the World IPv6 Launch {day|week|forever} efforts,
I noticed an interesting pattern of companies that put up IPv6
resources, with all the associated quad-As, and patted themselves
on the back for making themselves available via IPv6; but I couldn't
request those quad-A records via anything but IPv4 transport to their
DNS servers.
I've seen similar behaviour with hardware vendors. They have great
IPv6 support, their boxes forward and accept IPv6 packets just fine;
but, the deeper you dig, the more you find oddities, like syslog host
destinations that only accept v4 IP addresses, or a requirement for
an IPv4 router ID to be configured.
I don't think we fully grasp just how wide the chasm is between
"we support IPv6" and "we can fully turn off IPv4".
There's a whole lot of "we support IPv6" in the world right now that
comes with lingering IPv4 tendrils that are often under the surface,
or in the darker corners of the config, that just keep working because
most of the IPv6 world is still either dual-stacked, or has a translation
layer that allows the lurking v4 bits to not cause issues.
I don't think we'll be nearly as close to being ready to turn off the lights
on IPv4 as we think we are, not just because of old customer CPE and
legacy boxes, but because of embedded assumptions deep in software
and firmware stacks. For example, let's take a relatively modern
enterprise wireless platform:
"
Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4
network around so the devices can configure themselves after powering on.
There's a *lot* of code out there that's been carried forward for years,
with dark corners that haven't been touched for a while. I think we're
going to be stumbling over "can't do that over IPv6 yet" areas for years
and years to come, not because of any willful myopia around the migration
from IPv4 to IPv6, but simply because it's code that doesn't get used very
often, and in dual-stack networks, it just keeps working the few times it
gets exercised. The only time it would run into a problem is in a pure
IPv6-only network; and how many of those really exist in the world to
flag it as an issue?
And yet, in order to "turn off the lights on IPv4", we're going to have to
root through all those dark corners of code that haven't been touched
in years to update them to work in an IPv6-only world; and that's *really*
pushing the rock uphill, because that's work that isn't going to see any
cost recovery for it at all. No customer is going to say "I won't buy your
product until you've rooted out every bit of IPv4-only code in your software".
So, there's really no financial incentive for companies to work towards
getting their software ready for an IPv6-only world.
So--the tl;dr version of my answer to you?
"when" is likely to be "not in any of our lifetimes"--because the "how"
requires completely non-monetizable effort on the part of companies
that have legacy codebases they're carrying forward.
Thanks!
Matt