IPv6 Only

Thu Mar 31 21:01:23 UTC 2022

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

> On 1 Apr 2022, at 05:53, Matthew Petach <mpetach at netflight.com> wrote:
> 
> 
> 
> 
>> On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <Jacques.Latour at 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:
> 
> https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm
> "
> 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220401/b6e8ab25/attachment.html>