<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <<a href="mailto:Jacques.Latour@cira.ca">Jacques.Latour@cira.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Exactly what I was asking, when and how will we collectively turn off the lights on IPv4?<br></blockquote><div><br></div><div>Working on the World IPv6 Launch {day|week|forever} efforts, </div><div>I noticed an interesting pattern of companies that put up IPv6 </div><div>resources, with all the associated quad-As, and patted themselves </div><div>on the back for making themselves available via IPv6; but I couldn't </div><div>request those quad-A records via anything but IPv4 transport to their </div><div>DNS servers.</div><div><br></div><div>I've seen similar behaviour with hardware vendors.  They have great </div><div>IPv6 support, their boxes forward and accept IPv6 packets just fine; </div><div>but, the deeper you dig, the more you find oddities, like syslog host </div><div>destinations that only accept v4 IP addresses, or a requirement for </div><div>an IPv4 router ID to be configured. </div><div><br></div><div>I don't think we fully grasp just how wide the chasm is between </div><div>"we support IPv6" and "we can fully turn off IPv4".</div><div><br></div><div>There's a whole lot of "we support IPv6" in the world right now that </div><div>comes with lingering IPv4 tendrils that are often under the surface, </div><div>or in the darker corners of the config, that just keep working because </div><div>most of the IPv6 world is still either dual-stacked, or has a translation </div><div>layer that allows the lurking v4 bits to not cause issues.</div><div><br></div><div>I don't think we'll be nearly as close to being ready to turn off the lights </div><div>on IPv4 as we think we are, not just because of old customer CPE and </div><div>legacy boxes, but because of embedded assumptions deep in software </div><div>and firmware stacks.  For example, let's take a relatively modern </div><div>enterprise wireless platform:</div><div><br></div><div><a href="https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm">https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm</a><br></div><div>"</div><ul style="box-sizing:border-box;font-family:"Open Sans",sans-serif;font-size:10pt;color:rgb(0,0,0);line-height:13pt"><li value="3" style="box-sizing:border-box;margin:0pt;padding-top:2pt;padding-bottom:2pt;font-size:10pt;letter-spacing:0em;list-style-type:square">ZTP operations are supported over IPv4 connections only. IPv6 connections are not supported for ZTP operations."</li></ul><div> Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4 <br></div><div>network around so the devices can configure themselves after powering on.</div><div><br></div><div>There's a *lot* of code out there that's been carried forward for years, </div><div>with dark corners that haven't been touched for a while.  I think we're </div><div>going to be stumbling over "can't do that over IPv6 yet" areas for years </div><div>and years to come, not because of any willful myopia around the migration </div><div>from IPv4 to IPv6, but simply because it's code that doesn't get used very </div><div>often, and in dual-stack networks, it just keeps working the few times it </div><div>gets exercised.  The only time it would run into a problem is in a pure </div><div>IPv6-only network; and how many of those really exist in the world to </div><div>flag it as an issue?</div><div><br></div><div>And yet, in order to "turn off the lights on IPv4", we're going to have to </div><div>root through all those dark corners of code that haven't been touched </div><div>in years to update them to work in an IPv6-only world; and that's *really* </div><div>pushing the rock uphill, because that's work that isn't going to see any </div><div>cost recovery for it at all.  No customer is going to say "I won't buy your </div><div>product until you've rooted out every bit of IPv4-only code in your software".</div><div>So, there's really no financial incentive for companies to work towards </div><div>getting their software ready for an IPv6-only world.</div><div><br></div><div>So--the tl;dr version of my answer to you?</div><div>"when" is likely to be "not in any of our lifetimes"--because the "how" </div><div>requires completely non-monetizable effort on the part of companies </div><div>that have legacy codebases they're carrying forward.</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div><div><br></div></div></div>