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

Nothing you have said has changed my thoughts or opinions on this proposal. It still has many direct technical deficiencies , not to mention continuing to rely on a status change of 240/4, of which there is no forward movement on actually happening. I no longer have interest in continuing the

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

Dear Mark: 1) "... Google's data also shows businesses making at about 4% if you look at the weekly trends that show IPv6 usage spiking on the weekend as business users traffic drops off. ...": Perhaps the better interpretation of this fluctuation is because the residential use (more IPv6)

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

Dear Mr. Beecher: 0) Thanks for your reply to close the loop. 1)    " I don't have any interest in continuing this discussion on this topic.":    I am quite surprised by your nearly 180 degree turn of your position from your last MSG. The only thing that I could think of is that my last MSG

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

Mr. Chen- I don't have any interest in continuing this discussion on this topic. Best of luck to you. On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen wrote: > Dear Tom: > > Have not heard from you since the below MSG. Could you please let me > know if you have seen it, so that we can carry on

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

Dear Tom: Have not heard from you since the below MSG. Could you please let me know if you have seen it, so that we can carry on by avoiding the repeated open-loop situation with this thread? Regards, Abe (2022-12-01 07:44 EST) On 2022-11-22 23:23, Abraham Y. Chen wrote: Dear Tom:

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

Vasilenko Eduard via NANOG wrote: Big OTTs installed caches all over the world. Big OTTs support IPv6. As large network operational cost to support IPv6 is negligible for OTTs spending a lot more money at the application layer, they may. Hosts prefer IPv6. No. As many retail ISPs can not

RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

, November 27, 2022 12:35 AM To: Chris Welti Cc: NANOG ; b...@theworld.com; Vasilenko Eduard Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Hi, Chris: 1) "... public fabric ... private dedicated circuits ... heavily biased ...":   You brought up an aspect t

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

> On 24 Nov 2022, at 19:53, Abraham Y. Chen wrote: > > Dear Joe: > > 0) Allow me to share my understanding of the two topics that you brought up. > > 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like > we’ve gone from ~0% to ~40% in 12 years ": Your numbers

Re: ipv4/25s and above

Before this conversation forked off in a direction I didn't want it to go, I'd like to thank everyone, privately and publicly, that gave me a hint as to the distribution of /25s and greater in their networks. I was at the time, trying to get "libreqos.io" to crack the 32k customer barrier, which

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

On Mon, Nov 21, 2022 at 4:05 PM 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

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

John Curran wrote: >> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > ... this Internet draft ... can't be safely deployed in the actual > real-world Internet The draft *has been* safely deployed in the actual real-world Internet. It is in all Linux nodes since 2008, and

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

braham Y. Chen Sent: Thursday, November 24, 2022 11:53 AM To: Joe Maimon Cc: NANOG;b...@theworld.com Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Dear Joe: 0) Allow me to share my understanding of the two topics that you brought up. 1) "...https://www.google.com

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

Hi, Douglas: 0) Thanks for the feedback. 1)  I do not sort eMail with any tools. Other than important ones that do I save a copy off the system as a document for long term reference, I only flag those of substance for the keeps and allow the rest to "expire" (I do house cleaning every three

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

> What's the group's current thought on emergence or prevalence of > IPv6-only hosts ? They aren’t needed; dual stack hosts will work just fine in a single stack network. When they’re needed, they will be normal but nobody will care.

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

om Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Dear Joe: 0) Allow me to share my understanding of the two topics that you brought up. 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years

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

ay, November 24, 2022 11:53 AM To: Joe Maimon Cc: NANOG;b...@theworld.com Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Dear Joe: 0) Allow me to share my understanding of the two topics that you brought up. 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it loo

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

Hello Abraham! I believe your e-mail client (MUA) is splitting every message on a new thread. I'm not sure if it is happening with everyone, but using Gmail as MUA, it isn't aggregating the mails on the same thread. Cloud you please check the confs of your tool to avoid it? Thanks in advance.

RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

22 11:53 AM To: Joe Maimon Cc: NANOG ; b...@theworld.com Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC Dear Joe: 0) Allow me to share my understanding of the two topics that you brought up. 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’v

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

Dear Mathew: 0) Appreciate very much for your professionalism. Technical discussions over cyberspace like this are very challenging because the lack of instant feedback. One person could write a long essay without knowing that it is already off the track. Compounded with not knowing the other

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

Dear Joe: 0) Allow me to share my understanding of the two topics that you brought up. 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.   A. The IPv6 was introduced in 1995-12, launched

Re: Alternative Re: ipv4/25s and above

On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen wrote: > Dear Tom: * > [...] > > 2) "...Your proposal appears to rely on a specific value in the IP > option header to create your overlay": Not really, as soon as the > 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can >

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

Dear Eric: 0) Your analysis may have started from an assumption that is different from that of the EzIP. That is, 1)  The EzIP proposes to use the 240/4 as a replacement of the 100.64/10 of RFC6598 for enhancing the CG-NAT. Thus, 240/4 will be used as reusable netblocks like those in

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

Dear Tom: Please disregard an earlier partial transmission of this MSG, caused by operator error. *** 1) One look at the NANOG archive that you retrieved tells me that we are the victims of the idiosyncrasies of the eMail system. Unlike snail mails that are slow but reliable (There was a

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

Dear Tom: 1)  One look at the NANOG archive that you retrieved tells me that we are the victims of the idiosyncrasies of the eMail system. Unlike the snail mails are slow but reliable (There was a story that USPS found a forty years old letter stuck in one of the mail collection boxes on

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

> On Nov 22, 2022, at 2:13 PM, Tom Beecher wrote: > >> Serious consideration requires a serious proposal - I don’t think we’ve seen >> one yet. > > I would posit that draft-schoen-intarea-unicast-240-03 ( > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should > be

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

> > Serious consideration requires a serious proposal - I don’t think we’ve > seen one yet. > I would posit that draft-schoen-intarea-unicast-240-03 ( https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should be considered a serious proposal, in so much as what is proposing is

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

> On Nov 22, 2022, at 1:19 PM, Joe Maimon wrote: > > John Curran wrote: >> >> By the way, you shouldn’t feel particularly bad about skipping out on the >> interoperability requirement – anything involving interworking with the >> installed Internet is hard, and this is the same lesson that

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

John Curran wrote: On Nov 22, 2022, at 9:09 AM, John Curran wrote: ... 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

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

> On Nov 22, 2022, at 9:09 AM, John Curran wrote: > ... > 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

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

> On Nov 22, 2022, at 2:09 AM, Joe Maimon 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

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

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

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?

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

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

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

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

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

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

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

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

me or in a very long > time? > > > Rubens > > > -- Forwarded message - > From: > Date: Mon, Nov 21, 2022 at 8:02 PM > Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC > To: NANOG > > > > My suggestion is igno

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

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

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

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

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

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

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

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

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.

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

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

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

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

Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC To: NANOG 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 /

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

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

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

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

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,

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

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

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

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

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

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

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

On 11/20/22 19:02, Abraham Y. Chen wrote: Dear Mark: 0)  I am surprised at your apparently sarcastic opinion. 1)  The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development,

Re: Alternative Re: ipv4/25s and above

If I had a dollar for every person who has lived their entire life in a high-income western country (US, Canada, western Europe, etc) and has zero personal experience in developing-nation telecom/ISP operations and their unique operational requirements, yet thinks they've qualified to offer an

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

Dear Rubens: 0) Very good question. It is right to the point! 1) Initially, we thought that we were doing conventional protocol development engineering that was triggered by our curiosity about why IPv4 address pool was depleted. So, IETF Draft was the natural place to report what we were

Re: Alternative Re: ipv4/25s and above

On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen wrote: > Dear Owen: > > 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: > > >

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

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen wrote: > > Dear Mark: > > 0) I am surprised at your apparently sarcastic opinion. > > 1) The EzIP proposal as referenced by my last MSG is the result of an > in-depth system engineering effort. Since the resultant schemes do not > rely on any

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

Dear Mark: 0)  I am surprised at your apparently sarcastic opinion. 1)  The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development, IETF does not need be involved. Especially, its

Re: ipv4/25s and above

>> But see the crux above. If your RiR isnt frowning on such behavior then its >> poor strategy to implement it. > > I might have missed the part where RIR's tell me how to operate. Allow me to help: https://afrinic.net/ast/pdf/services/afrinic-rsa-en-201801.pdf afrinic-rsa-en-201801 PDF

Re: ipv4/25s and above

On Sat, Nov 19, 2022 at 5:13 PM Douglas Fischer wrote: > > I do not like mikrotik, but I need to say that RouterOS does support /31. > > All that you need to do, beyond set /31 at address for netmask, is check if > the other address is defined at the network address. Is /31 supported only in

Re: ipv4/25s and above

On 11/19/22 3:12 PM, Douglas Fischer wrote: > I do not like mikrotik, but I need to say that RouterOS does support /31. > > All that you need to do, beyond set /31 at address for netmask, is check if > the other address is defined at the network address. Can you show some docs on this? I gave a

Re: ipv4/25s and above

I do not like mikrotik, but I need to say that RouterOS does support /31. All that you need to do, beyond set /31 at address for netmask, is check if the other address is defined at the network address. Em sáb., 19 de nov. de 2022 15:58, Denis Fondras escreveu: > Le Sat, Nov 19, 2022 at

Re: ipv4/25s and above

Le Sat, Nov 19, 2022 at 01:39:59PM -0500, Bryan Fields a écrit : > On 11/18/22 6:44 AM, Joe Maimon wrote: > >> We could, but many of our DIA customers have all manner of CPE's that > >> may or may not support this. Having unique designs per customer does > >> not scale well. > > its almost 2023.

Re: ipv4/25s and above

On 11/18/22 6:44 AM, Joe Maimon wrote: >> We could, but many of our DIA customers have all manner of CPE's that >> may or may not support this. Having unique designs per customer does >> not scale well. > its almost 2023. /31 support is easily mandatory. You should make it > mandatory.

ipv4/25s and above

Dear NANOG-ers, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le samedi 19 novembre 2022, Owen DeLong via NANOG a écrit : > > > >> Either you have lots of fallow ground or very few customers. > > > > A bit of both. > > Regarding the former, perhaps

Re: Alternative Re: ipv4/25s and above

On 11/19/22 05:50, Abraham Y. Chen wrote: Dear Owen: 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: It's most amusing, to me, how Africa needs to be told how to be... Some

Re: ipv4/25s and above

On 11/18/22 13:44, Joe Maimon wrote: its almost 2023. /31 support is easily mandatory. You should make it mandatory. I don't make the gear. How many customer addressing designs does that total, 2? So that would be 1 more than you have already? Dont buy it. That's fine. Its 2023,

Alternative Re: ipv4/25s and above

Dear Owen: 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 2)  If this looks a bit too technical

Re: ipv4/25s and above

> On Nov 18, 2022, at 03:44, Joe Maimon wrote: > > > > Mark Tinka wrote: >> >> >> On 11/17/22 19:55, Joe Maimon wrote: >> >>> >>> You could instead use a /31. >> >> We could, but many of our DIA customers have all manner of CPE's that may or >> may not support this. Having unique

Re: ipv4/25s and above

> >> Either you have lots of fallow ground or very few customers. > > A bit of both. Regarding the former, perhaps you should return some of that to AFRINIC as required in your RSA before throwing stones at other providers in the region. Owen

Re: ipv4/25s and above

Mark Tinka wrote: On 11/17/22 19:55, Joe Maimon wrote: You could instead use a /31. We could, but many of our DIA customers have all manner of CPE's that may or may not support this. Having unique designs per customer does not scale well. its almost 2023. /31 support is easily

Re: ipv4/25s and above

On 11/17/22 19:55, Joe Maimon wrote: You could instead use a /31. We could, but many of our DIA customers have all manner of CPE's that may or may not support this. Having unique designs per customer does not scale well. Or private/enterprise-private Yeah, don't like that,

Re: ipv4/25s and above

Mark Tinka wrote: For our DIA/Enterprise business, we offer customers a /30 for p2p link, and a /29 as initial standard for onward assignment within their LAN. You could instead use a /31. Or private/enterprise-private or unnumbered and route them the single /32 to use for their NAT on

Re: ipv4/25s and above

On 11/16/22 16:39, Dave Taht wrote: I am kind of curious as to the distribution of connections to smaller companies and other entities that need more than one ipv4 address, but don't run BGP. So, for as an ISP or infrastructure provider, what is the typical percentage nowadays of /32s /31s

Re: ipv4/25s and above

Dave, I work for a smaller ISP in the Midwest with clients coast-to-coast. I deliver internet to about 2/3 rds of them over private ethernet circuits, the rest I deliver private addressed SIP service. Aside a handful of them who advertise their own /24 to me over BGP, the rest are exclusively

ipv4/25s and above

I am kind of curious as to the distribution of connections to smaller companies and other entities that need more than one ipv4 address, but don't run BGP. So, for as an ISP or infrastructure provider, what is the typical percentage nowadays of /32s /31s /30s... /25s of stuff that gets run