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

I'm not opposed to making 240/4 unicast but I'd agree it wouldn't solve much globally. Nonetheless it might help for example some new org which can't get an IPv4 allocation (or not sufficient.) They may really need to do both IPv4 and IPv6 for example. (ok, here we go, point by point alternativ

Re: Alternative Re: ipv4/25s and above

Jay Hennigan wrote: On 11/21/22 16:30, Joe Maimon wrote: IMNSHO, if such a proposal were to gain traction, by the time that gear capable of using 240/4 as unicast were to be widely deployed, IPv6-capable gear would be much more widely deployed. Considering that is already the situatio

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

David Conrad wrote: 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

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

> > > As someone who has been involved in the deployment of network gear > > into class E space (extensively, for our own internal reasons, which > > doesn't preclude public use of class E), "largely supported" != > > "universally supported". > > > > There remains hardware devices that blackhole cl

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

> On Nov 21, 2022, at 11:12 PM, Joe Maimon wrote: > > John Curran wrote: >> .. >> That may (or may not) lead to you experiencing what you consider reasonable >> support costs for your customers, but as we all know, everyone else has >> customers who are the other ends of those connections who

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

David Conrad wrote: Barry, On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 ye

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

Lincoln Dale wrote: On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon > wrote: Indeed that is exactly what has been happening since the initial proposals regarding 240/4. To the extent that it is now largely supported or available across a wide variety of gea

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

Eric Kuhnke wrote: Assume the following theoretical scenario: You have a large number of existing RIPE, ARIN, APNIC ASes which will take any ipv4 resources they can get. They're all on waiting lists or have been informed no new blocks will be forthcoming. 240/4 is something like 256 milli

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

John Curran wrote: On Nov 21, 2022, at 7:18 PM, Joe Maimon wrote: … Further, presentment of options in this fashion presumes that we have some ability to control or decide how engineering efforts across the entirety of the internet should be spent. Joe - In the snippet above you allude

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

Dear Eric: 1)  " ... 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 ... ":    It is apparent that you do not recognize a few unorthodox EzIP characteri

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

Much of India operates this way today. Owen > On Nov 21, 2022, at 15:06, Rubens Kuhl wrote: > > (forwarded to break thread since this is a different topic) > What's the group's current thought on emergence or prevalence of > IPv6-only hosts ? Will they exist soon, in some time or in a very lon

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

On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon wrote: > Indeed that is exactly what has been happening since the initial > proposals regarding 240/4. To the extent that it is now largely > supported or available across a wide variety of gear, much of it not > even modern in any way. > As someone wh

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

> On Nov 21, 2022, at 7:18 PM, Joe Maimon wrote: > … Further, presentment of options in this fashion presumes that we have some > ability to control or decide how engineering efforts across the entirety of > the internet should be spent. Joe - In the snippet above you allude to a very import

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

Joe, On Nov 21, 2022, at 4:30 PM, Joe Maimon 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 sol

Re: Alternative Re: ipv4/25s and above

On 11/21/22 16:30, Joe Maimon wrote: 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. One can and indeed some do attempt to do just that. The likelihood of these attempts actually co

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

Assume the following theoretical scenario: You have a large number of existing RIPE, ARIN, APNIC ASes which will take any ipv4 resources they can get. They're all on waiting lists or have been informed no new blocks will be forthcoming. 240/4 is something like 256 million IPs. Let's say that the

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

On Nov 21, 2022, at 7:18 PM, Joe Maimon wrote: ... It’s only taking that long because of this attitude. Of course, Joe, that attitude might also be cited of IPv6 deployment laggards! ;-) i.e., the mumbling of those in the periphery of Internet regarding why they’re not doing IPv6... (It's n

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

Eric Kuhnke wrote: In a theoretical scenario where somebody was global benevolent dictator of ipv4 space, even applying a policy which limited block size to a few /14 per ISP, it would be possible to exhaust 240/4/in one week/ if they handed out /14 sized pieces to every existing last mile

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

David Conrad wrote: Barry, On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 ye

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

In a theoretical scenario where somebody was global benevolent dictator of ipv4 space, even applying a policy which limited block size to a few /14 per ISP, it would be possible to exhaust 240/4* in one week* if they handed out /14 sized pieces to every existing last mile LTE network operator with

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

Eric, I appreciate your willingness to actual consider this rationally. Every facet of this debate has been fully aired on this forum (and others), numerous times. Allow me to pick it apart again. Apologies to those who are ad nausem. Eric Kuhnke wrote: Option A) Spend engineering time and e

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

Barry, On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: > We've been trying to get people to adopt IPv6 widely for 30 years with very > limited success According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.lab

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

This is basically exactly what has come out of the IETF for this and similar ideas. I doubt it will ever stop them from being put forth though. On Mon, Nov 21, 2022 at 6:39 PM Eric Kuhnke wrote: > Option A) Spend engineering time and equipment purchases to implement > 240/4 as unicast globally.

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

> > 1) As requested, please be specific and speak only for yourself. So > that we can carry on a professional dialog meaningfully. > I will start by citing one of my own responses to you : https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html I do not leave a loose end to any techni

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

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 amo

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

(forwarded to break thread since this is a different topic) What's the group's current thought on emergence or prevalence of IPv6-only hosts ? Will they exist soon, in some time or in a very long time? Rubens -- Forwarded message - From: Date: Mon, Nov 21, 2022 at 8:02 PM Subje

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

My suggestion is ignore anyone who says it would be too difficult to get people to adopt a change or take too long. Someone always says that, a reasonable riposte is "what would be a reasonable number of people / years?" Surely they must have some numbers in mind, no? We've been trying to get pe

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

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

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

Dear Tom: 1)  As requested, please be specific and speak only for yourself. So that we can carry on a professional dialog meaningfully. 2) Hint: I signed up to NANOG.org only early this year. So, whatever you have in mind might be from somewhere else. In addition, even though I do not have g

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

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 l

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

> > 1) "... for various technical reasons , ...": Please give a couple > examples, and be specific preferably using expressions that colleagues > on this forum can understand. > Myself and multiple others provided specific technical rebuttals to the proposal in the past on this list. On Mon, N

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

Dear Tom: 0) Thanks for your advice. 1) What I wrote was just informal online chatting. I was not attempting to make a water-tight legal statement. The fact is, we have identified at least one concise case of how this task could be done easily, as reported in Appendix D of the EzIP IETF Draft

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

Dear Tom: 1) "... for various technical reasons , ...":  Please give a couple examples, and be specific preferably using expressions that colleagues on this forum can understand. Thanks, Abe (2022-11-21 12:29 EST) On 2022-11-21 10:44, Tom Beecher wrote: 1) "... Africa ... They don

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

> > As stated in Subsection 4.A. of the "Revamp The > Internet" whitepaper, all need be done is "Simply disable the existing > software codes that have been disabling the use of the 240/4 netblock." > Some friendly feedback. The phrase "all that needs to be done" , is exceptionally reductive, and

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

Dear Mark: 0) Thanks for the clarification. I understand. A short message through the cyberspace, especially between parties who have never met can be easily skewed. I am glad that I asked you, instead of taking it negatively without raising my hand. 1) "...I'd, rather, expend those resource

Re: Alternative Re: ipv4/25s and above

> > 1) "... Africa ... They don’t really have a lot of alternatives. ...": > Actually, there is, simple and in plain sight. Please have a look at the > below IETF Draft: > > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space For the benefit of anyone who may not un

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

Dear Eric: 0) Your opinion by itself is very valid and much appreciate. However, it is from a very remotely related perspective. That is, you are looking at the financial disadvantage of the less developed regions. What I am talking about is the generic issue of communication system address m

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

Dear Mathew: 0) Thanks for raising a very valid observation. Your line of reasoning and conclusion including the conundrum that IPv6 faces do conform with my understanding of the current Internet conventions and practices. However, this is only following the track that most people have been c