<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 18, 2021, at 12:34 , Victor Kuarsingh <<a href="mailto:victor@jvknet.com" class="">victor@jvknet.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 18, 2021 at 2:39 PM John Levine <<a href="mailto:johnl@iecc.com" class="">johnl@iecc.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It appears that Owen DeLong via NANOG <<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>> said:<br class="">
>> The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans<br class="">
>to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or<br class="">
>not at all, but you know about accountants and depreciation.<br class="">
><br class="">
>Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of<br class="">
>adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.<br class="">
<br class="">
I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that<br class="">
they use for support and marketing and customer service and all the other stuff that big companies do.<br class="">
<br class="">
As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath.<br class=""></blockquote><div class=""><br class=""></div><div class="">Glad you noted this. Thinking this was/is purely a hardware cycle problem related to normal/forced upgrade strategies. On that point, most hardware I know of from 2004 in larger networks is long fully depreciated and sweating assets 15+ years can happen, but I don't personally think this is the biggest issue.</div></div></div></div></blockquote><div><br class=""></div>It’s certainly not purely hardware, but it also doesn’t require solving the entire problem across the entire backend.</div><div><br class=""></div><div>What is urgently needed is to fix the customer-facing front end so that it speaks both protocols (or at least speaks IPv6).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. I recall looking back when leading IPv6 turn-up, those were the biger problems to solve for. Often such systems are extremely expensive to touch and working on them required prioritization against direct revenue generating projects (opportunity cost) . Replacing routers was just a money problem.</div></div></div></div></blockquote><div><br class=""></div>Why do those systems have to be updated in order to deliver the service to the customer in both protocols?</div><div><br class=""></div><div>I mean sure, you’ll probably need to fix some logging databases that think that a customers address can be logged as a uint32_t, but that’s a relatively small number of systems that need to be updated in that case and it’s not like expanding the field to uint128_t in the database is incompatible with the old software during the upgrade process.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">I am by far not saying I agree with choices made by hold-outs, but I also understand this is for many, not just an engineering problem to solve. </div></div></div></div></blockquote><div><br class=""></div>I agree there are some systems that may make this more complex in some environments, but I don’t agree that it’s</div><div>impossible (or even particularly difficult) for a content provider to deliver their content on both protocols today even</div><div>if they don’t upgrade their back-end systems.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></body></html>