Re: IPv6 woes - RFC

[Owen DeLong via NANOG <nanog () nanog org>]

> On Sep 18, 2021, at 12:34 , Victor Kuarsingh <victor () jvknet com> wrote:
>
>
>
> On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl () iecc com <mailto:johnl () iecc com>> wrote:
> It appears that Owen DeLong via NANOG <owen () delong com <mailto:owen () 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