nanog mailing list archives
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC
From: Eric Kuhnke <eric.kuhnke () gmail com>
Date: Mon, 21 Nov 2022 15:38:33 -0800
Option A) Spend engineering time and equipment purchases to implement 240/4 as unicast globally. At present consumption rates and based on the number of entities in ARIN, RIPE, APNIC regions that could *immediately* take /18 to /16 sized blocks of it, please quantify exactly how many years this amount of "new" IP space you predict to be useful before once again reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy of building a sand castle while the tide is coming in. Option B) Spend engineering time and equipment purchases (yes, very possibly much more time and more costly) to implement ipv6. Even if option B is much more costly and time consuming, the end result will be much better. On Mon, 21 Nov 2022 at 14:48, Joe Maimon <jmaimon () jmaimon com> wrote:
Eric Kuhnke wrote:Quite simply, expecting the vast amount of legacy ipv4-only equipment out there in the world that is 10, 15, 20 years old to magically become compatible with the use of 240/4 in the global routing table is a non viable solution. It is not a financial reality for many small to medium sized ISPs in lower income countries. The amount of time and effort that would be required to implement your proposal is much better spent on ipv6 implementation and various forms of improved cgnat.In specific focus on 240/4 Simultaneously claiming that enabling 240/4 as unicast involves difficulty that in comparison makes IPv6 (and then you add in CGNAT!) somehow more achievable is ridiculous. Regardless of the exact scenario. Joe
Current thread:
- Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC, (continued)
- Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Masataka Ohta (Nov 28)
- Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Douglas Fischer (Nov 24)
- Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Abraham Y. Chen (Nov 26)
- Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Mark Andrews (Nov 27)
- Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC Joe Maimon (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC Dave Taht (Nov 27)
- Re: Alternative Re: ipv4/25s and above Eric Kuhnke (Nov 20)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Abraham Y. Chen (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Eric Kuhnke (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Joe Maimon (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Eric Kuhnke (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Tom Beecher (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Joe Maimon (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Eric Kuhnke (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Joe Maimon (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Eric Kuhnke (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC Joe Maimon (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC bzs (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211231506.AYC Abraham Y. Chen (Nov 23)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC John Curran (Nov 21)
- Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC John Curran (Nov 21)