Alternative Re: ipv4/25s and above Re: 202211201009.AYC

John Curran jcurran at istaff.org
Tue Nov 22 14:09:37 UTC 2022


> On Nov 22, 2022, at 2:09 AM, Joe Maimon <jmaimon at jmaimon.com> wrote:
> 
> David Conrad wrote:
>> 
>> Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.
> 
> Lets agree to stop conflating the issue of products under active support and refresh cycles with the issue of those that are obsolete and only subject to attrition.

Joe - 

<chuckle>  Ah, if it were only that simple…   service providers have a _huge_ amount of installed infrastructure, and it’s in various phases of support (i.e. can get new updates, or critical fixes only, or is self-maintained, etc.) 

Vendors supporting 240/4 as general purpose space does not automatically equate to Internet infrastructure supporting 240/2, as it requires service providers to make conscious decisions to do maintenance on gear that may (in many cases) have been effectively frozen in terms of software updates that aren’t critical… customer installs and capacity upgrades almost always get first cut at resources, and so no, it is not just a case of updating the standards - even presuming that the provider has the equipment under software updates, availability of such doesn’t mean it will be installed.   You are talking about a long period between standards update and actual deployment, and that’s presuming actively supported gear. 

> The former, yes it is trivial. An update in standards could yield rapid results here.

Absolutely – but only if you are talking about an equally trivial network infrastructure or pure lab environment – otherwise, the standards change is the very _beginning_ of a lengthy process for network operators of any size. 

You once again have avoided the question of interoperability during the transition period.

Interoperability isn’t insurmountable, but does take some investment of effort.  One can imagine any number of techniques (e.g.  flag day after which “production devices” on the Internet must support 240/4, or DNS resolver hacks that fail to return “A” records with 240/4 addresses unless a flag is set that says “we’re in the 240/4 routable Internet” [ick], etc., etc.)  It doesn’t seem particularly hard to come up with some approaches to solve the interoperability problem, but completely ignoring it is not an answer (and makes it rather difficult to take your proposal seriously...) 

Thanks,
/John

p.s.  disclaimer: my views alone (little chance any one else would risk blame for them!) 
 





More information about the NANOG mailing list