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:
"
- ZTP operations are supported over IPv4 connections only. IPv6 connections are not supported for ZTP operations."
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
The part that you might be missing is that those dark corners are also where the vulnerabilities hide.
If a piece of software can’t do v6, it probably hasn’t been maintained for a long time.
With software bills of materials coming up, we may have a bit more leverage on these graveyard decks than we have had until now.
Your main argument unfortunately does hold water; the timeline you propose, maybe not so much.
Grüße, Carsten
You have to try running IPv6 only occasionally to weed out the dependencies. You can do this on a per node basis. Just turn off the IPv4 interface and see how you run. I do this periodically on my Mac and disable IPv4. This also makes my recursive nameserver IPv6 only as well. You then see what breaks like sites where one of the cdn’s is IPv4 only despite the page itself being reachable over IPv6. Or the nameservers are not reachable over IPv6.
Write down what you find is broken and report it.
Mark Andrews wrote:
Write down what you find is broken and report it.
According to your logic, it is a lot more constructive
to write down what we find are broken with IPv6 and
report it to IETF, which will make IETF obsolete IPv6.
Masataka Ohta
This reminds me of days gone by, when NANOG used to have an IPv6-only hour in the agenda, where IPv4 connectivity would be turned off, so people could identify problem areas.
Unfortunately, it tended to mostly be an excuse to head to the coffee bar, or enable “offline” mode in your mail client before it started, with little active engagement in the room.
It might be interesting for NANOG86 in Hollywood to make it a formal part of the agenda; not just an hour with no IPv4, but a focused half-an-hour in which the focus of the room is on identifying problem areas; display an anonymized “word cloud” on the screens in the room and remotely that people can list sites, vendors, protocols, anything that they observe failing to function from the point of view of an IPv6-only client.
We’ve talked about the need for people to “name-and-shame” in order to get movement from some software and hardware vendors, but people are often understandably reluctant to put their name on a ‘name-and-shame’ post that could jeopardize their job. Would doing it through an anonymized word cloud give people more air coverage to list items they see that don’t work in an IPv6-only world? (Clearly, there’s limits; if you’re the only employee of a company, and you discover your employer’s VPN endpoints don’t work from a v6-only network, you might think twice about listing it in the word cloud–anonymization can only do so much to protect you!)
A forum leader at the microphone, making suggestions for services people should test, functions they could try to exercise, sites they could try to reach to start the ball rolling; and then as the word cloud starts to fill in, solicit people’s input on similar services to see if they fare any better. In fact, having two word clouds, red (doesn’t work) and green (does work) might be an even better idea, so that it’s not just a name-and-shame, but also a name-and-praise session, thanking those who have done the work to make v6-only connectivity work, and calling out those who still have work to do.
Or is this a ship that has already sailed, and attempting to resurrect it will do nothing more than goose coffee sales for a brief interval?
Thoughts and feedback welcome!
Matt