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

Tue Nov 22 01:09:28 UTC 2022

Joe,

On Nov 21, 2022, at 4:30 PM, Joe Maimon <jmaimon at jmaimon.com> wrote:
> As I and others have pointed out, it depends on how it is used.

Sure, and with enough thrust and an appropriate trajectory, pigs fly quite well, although the landing can get messy.  With enough constraints, any problem becomes trivially solvable. Whether it is a useful problem to solve is the question.

> And perhaps the attempt should be made regardless of knowing in advance which it will be.

You’ll get no argument from me. In the past, I’ve suggested a Cloudflare 1.1.1.1-like experiment would provide useful data.

> You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.

How trivial would the change be in a product by a company that no longer exists or a product line that is no longer supported? Will Microsoft update all previous versions of Windows?  Will the myriad of deployed embedded systems sitting forgotten in closets be updated? And if you’re going to the trouble to update those systems (in most cases, by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

> Especially as we have examples of what that type of effort might look like.

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.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221121/1aa7ffa8/attachment.sig>