> On Sep 18, 2021, at 12:34 , Victor Kuarsingh <vic...@jvknet.com> wrote: > > > > On Sat, Sep 18, 2021 at 2:39 PM John Levine <jo...@iecc.com > <mailto:jo...@iecc.com>> wrote: > It appears that Owen DeLong via NANOG <o...@delong.com > <mailto:o...@delong.com>> said: > >> The cost of putting flyers in the bills rounds to zero, so yes, really. I > >> expect these companies all have plans > >to support v6 eventually, someday, once they're retired and replaced all of > >the old junk that handles v6 poorly or > >not at all, but you know about accountants and depreciation. > > > >Unless their infrastructure runs significantly on hardware and software > >pre-2004 (unlikely), so does the cost of > >adding IPv6 to their content servers. Especially if they’re using a CDN such > >as Akamai. > > I wasn't talking about switches and routers. I was talking about every > single piece of software and equipment that > they use for support and marketing and customer service and all the other > stuff that big companies do. > > 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. > > 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.
It’s certainly not purely hardware, but it also doesn’t require solving the entire problem across the entire backend. What is urgently needed is to fix the customer-facing front end so that it speaks both protocols (or at least speaks IPv6). > 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. Why do those systems have to be updated in order to deliver the service to the customer in both protocols? 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. > 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. I agree there are some systems that may make this more complex in some environments, but I don’t agree that it’s impossible (or even particularly difficult) for a content provider to deliver their content on both protocols today even if they don’t upgrade their back-end systems. Owen
