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, although I understand why some operators use it.

or unnumbered and route them the single /32 to use for their NAT on say a loopback interface.

Same as the CPE issue I described above.

And the /29 ? I would reserve it but not assign it without a formal request.

We have some products that can be considered sub-DIA that do not come with the /29 as standard. Those tend to be the majority of the market.

Either you have lots of fallow ground or very few customers.

A bit of both. Our main business is wholesale IP Transit. The Enterprise piece is growing, but we are not trying to save the world. It's a specific focus, and we don't do consumer.

I dont see how this strategy would work elsewhere.

To be honest, we'll keep using IPv4 for as long as we have it, and for as long as we can get it from AFRINIC. But it's not where we are betting the farm - that is for IPv6.

Your sales people are right. Since you can deliver quite usable service that enables them to operate just as they have before with a single /32, and with technical advantages to yourself, all the extra wasted integers should be bringing in value.

At the risk of using IP addresses to prop uo sales numbers, and then you run out sooner because one customer decided to pay lots of $$ for a /22, even when they don't need it. Not the kind of potato I want to taste, because we have seen that proposed far too many times to know it will become a reality when the commissions are due. Mark.

On Nov 18, 2022, at 03:44, Joe Maimon <jmaimon@jmaimon.com> 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 designs per customer does not scale well.

its almost 2023. /31 support is easily mandatory. You should make it mandatory.

Much of Africa in 2023 runs on what the US put into the resale market in the late 1990s, tragically.

Its 2023, your folk should be able to handle addressing more advanced than from the 90s. And your betting the future on IPv6?

They don’t really have a lot of alternatives.

...

To be honest, we'll keep using IPv4 for as long as we have it, and for as long as we can get it from AFRINIC. But it's not where we are betting the farm - that is for IPv6.

And yet you wonder why I consider AFRINIC’s artificial extension of the free pool through draconian austerity measures to be a global problem?

Its on Afrinic to try and preserve their pool if they wish to by doing things such as getting it across that progress in addressing efficiency is an important consideration in fulfilling requests for additional resources.

Instead of this, they’re mostly ignoring policy, implementing draconian restrictions on people getting space from the free pool, and buying into various forms of reality avoidance.

But see the crux above. If your RiR isnt frowning on such behavior then its poor strategy to implement it.

So far, AFRINIC has given a complete pass to Tinka’s organization and their documented excessive unused address space despite policy that prohibits them from doing so. However, AFRINIC management and board seem to have extreme difficulty with reading their governing documents in anything resembling a logical interpretation. Owen

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 folk just can't help themselves. Mark.

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen <aychen@avinta.com> 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, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12 versions of your Internet draft to IETF ? https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ Rubens

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, IETF does not need be involved. Especially, its first step of disabling one line of existing networking program code empowers any party to begin deploying EzIP stealthily for mitigating the IPv4 address pool depletion issues. Note that EzIP is a generic solution applicable to everyone, not limited to Africa.

2)  Of course, constructive criticism is always appreciated. However, unspecific comments that confuse and distract the readers only provide dis-service to those disadvantaged population who are enduring the handicaps of being the late-comers to the Internet.

My comment was not directed at you. Sorry. I have nothing against the EzIP proposal. It just does not add any real value in solving the IPv4 depletion problem for the amount of effort required to implement it, in my view. I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. Mark.

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 in the case of internet standards, also always going to end up being wrong. On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:

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 resources on IPv6, 464XLAT, e.t.c. ... ": Since EzIP is still being further refined, it may not be clear in our documentation about how much work is required to get the IPv4 out of the current depletion mode. 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." In fact, we have found examples that this means commenting out one line code that searches for then discards packets with 240/4 addressing. It seems to me that there is no easier task than this.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)

On 2022-11-20 23:56, Mark Tinka wrote:

...

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, IETF does not need be involved. Especially, its first step of disabling one line of existing networking program code empowers any party to begin deploying EzIP stealthily for mitigating the IPv4 address pool depletion issues. Note that EzIP is a generic solution applicable to everyone, not limited to Africa.

2) Of course, constructive criticism is always appreciated. However, unspecific comments that confuse and distract the readers only provide dis-service to those disadvantaged population who are enduring the handicaps of being the late-comers to the Internet.

My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any real value in solving the IPv4 depletion problem for the amount of effort required to implement it, in my view. I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c.

Mark.

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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 people to adopt IPv6 widely for 30 years with very limited success so perhaps that's a pretty time to shoot for, for example. Anything less than 30 years would be an improvement. I suppose some might leap on that as evidence of the above cautions but it's really not. It's just being argumentative. It feels like a reasonable argument pattern but it's not because it ignores why that previous attempt mostly failed and tries to equate them (we failed for 30 years so therefore you will fail for 30 years???) That said, what's needed is a working demo preferably within both a simulation environment and live because the devil is always in the details and the only way to vet that is by testing working code. A mere proposal is of some value, one can glance at it and try to spot any fatal flaws for example. But it's only a tiny step along the path. However, that it might take a while to become adopted is, to me, like saying forget trying to mitigate climate change, it'll take decades and require hundreds of govts, thousands of industries, and billions of people to change their behavior which is all true but hardly an argument as to why not to try. Aside: A pretty good rule of thumb with replacement technologies is that something has to be 10x better than what it replaces to get wide adoption. Ok maybe not 10, that's a figure of speech, but a lot, and certainly not introduce impediments to its own adoption and use. On November 21, 2022 at 12:00 beecher@beecher.cc (Tom Beecher) wrote:

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 in the case of internet standards, also always going to end up being wrong. 

On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:

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 resources on IPv6, 464XLAT, e.t.c. ... ": Since EzIP is still being further refined, it may not be clear in our documentation about how much work is required to get the IPv4 out of the current depletion mode. 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." In fact, we have found examples that this means commenting out one line code that searches for then discards packets with 240/4 addressing. It seems to me that there is no easier task than this.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)

On 2022-11-20 23:56, Mark Tinka wrote: > > > 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, IETF does not need be involved. >> Especially, its first step of disabling one line of existing >> networking program code empowers any party to begin deploying EzIP >> stealthily for mitigating the IPv4 address pool depletion issues. >> Note that EzIP is a generic solution applicable to everyone, not >> limited to Africa. >> >> 2)  Of course, constructive criticism is always appreciated. However, >> unspecific comments that confuse and distract the readers only >> provide dis-service to those disadvantaged population who are >> enduring the handicaps of being the late-comers to the Internet. > > My comment was not directed at you. Sorry. > > I have nothing against the EzIP proposal. It just does not add any > real value in solving the IPv4 depletion problem for the amount of > effort required to implement it, in my view. I'd, rather, expend those > resources on IPv6, 464XLAT, e.t.c. > > Mark. >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Much of India operates this way today. Owen

On Nov 21, 2022, at 15:06, Rubens Kuhl <rubensk@gmail.com> 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 long time?

Rubens

---------- Forwarded message --------- From: <bzs@theworld.com> Date: Mon, Nov 21, 2022 at 8:02 PM Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC To: NANOG <nanog@nanog.org>

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 people to adopt IPv6 widely for 30 years with very limited success so perhaps that's a pretty time to shoot for, for example. Anything less than 30 years would be an improvement.

I suppose some might leap on that as evidence of the above cautions but it's really not. It's just being argumentative. It feels like a reasonable argument pattern but it's not because it ignores why that previous attempt mostly failed and tries to equate them (we failed for 30 years so therefore you will fail for 30 years???)

That said, what's needed is a working demo preferably within both a simulation environment and live because the devil is always in the details and the only way to vet that is by testing working code.

A mere proposal is of some value, one can glance at it and try to spot any fatal flaws for example. But it's only a tiny step along the path.

However, that it might take a while to become adopted is, to me, like saying forget trying to mitigate climate change, it'll take decades and require hundreds of govts, thousands of industries, and billions of people to change their behavior which is all true but hardly an argument as to why not to try.

Aside: A pretty good rule of thumb with replacement technologies is that something has to be 10x better than what it replaces to get wide adoption. Ok maybe not 10, that's a figure of speech, but a lot, and certainly not introduce impediments to its own adoption and use.

On November 21, 2022 at 12:00 beecher@beecher.cc (Tom Beecher) wrote:

...

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 in the case of internet standards, also always going to end up being wrong.

On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:

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 resources on IPv6, 464XLAT, e.t.c. ... ": Since EzIP is still being further refined, it may not be clear in our documentation about how much work is required to get the IPv4 out of the current depletion mode. 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." In fact, we have found examples that this means commenting out one line code that searches for then discards packets with 240/4 addressing. It seems to me that there is no easier task than this.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)

On 2022-11-20 23:56, Mark Tinka wrote:

...

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, IETF does not need be involved. Especially, its first step of disabling one line of existing networking program code empowers any party to begin deploying EzIP stealthily for mitigating the IPv4 address pool depletion issues. Note that EzIP is a generic solution applicable to everyone, not limited to Africa.

2) Of course, constructive criticism is always appreciated. However, unspecific comments that confuse and distract the readers only provide dis-service to those disadvantaged population who are enduring the handicaps of being the late-comers to the Internet.

My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any real value in solving the IPv4 depletion problem for the amount of effort required to implement it, in my view. I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c.

Mark.

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Barry, On Nov 21, 2022, at 3:01 PM, bzs@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.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me. But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious. Regards, -drc

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 convincing those in a position to influence change is what is in question. 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. META: Can whoever is doing so please stop creating new time-stamped subject lines for the same topic? It makes things hard to follow. -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

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

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

John Curran wrote:

...

On Nov 22, 2022, at 9:09 AM, John Curran <jcurran@istaff.org> 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 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…)

Joe -

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 the IPv6 folks found out the hard way… I will confess that I was a member of the IETF's IPng Directorate and thus inherently complicit in that particular fiasco –

John, Flags days on the internet of today have proven to be of limited value. Suppose complete interoperability is never actually solved. Why does 240/4 utilitarian value have to be binary? I think we should be trying to discover these things instead of using them to handwave away any attempt. The part I feel bad about is that I am actually un-involved in much of anyway with the 240/4 or other ideas, my sole input has been to attempt to encourage serious consideration and to rebut naysaying. Yes, a standards update is only the beginning of a real effort, although plenty has changed even without that. Yes, there may and likely will be a large extent of interoperability and usability challenges for quite some time, perhaps even enough time that the issue becomes moot. Yes, it may be insurmountable. Yes, it may render 240/4 unusable and undesirable to the extent that it has little contributory effect on IPv4. However it may not and discouraging serious consideration is actually a contributing factor preventing any such potential. And to the extent that you and others have discussed and aired various points of views and insights, I think I have had some success with my efforts thus far.

With IPv6, the first answer to interoperability was “let’s do tunnels between IPng islands”; i.e. helpful for lab environments but useless otherwise. We then declared that transition was a problem “to be solved later” but that shouldn’t get in the way of the declaration of IPng as the new IPv6. Finally, after failing to solve the problem, we reverted to “ships in the night”; i.e. IPv4 and IPv6 running in parallel on the same infrastructure – it works, but defeats the entire idea of IPv6 as a functional substitute for IPv4 for connecting new customers and infrastructure to the existing IPv4-based Internet (Luckily, the service provider industry that was growing most rapidly realized that they really needed IPv6, and they really needed transition solutions that allowed IPv6 to interoperate for IPv4 for new connections, and so we eventually saw real solutions such as 464xlat, ds-lite, etc.)

I feel there is some value for the internet record to contain as much as possible real debate and consideration instead of group think, short-sightedness, idealouges and top down approaches which may not look pretty in hindsight. Such as contained in the much larger details of your brief recap and that you and others have expanded upon here and elsewhere in the past. In other words, a loyal opposition.

Maintaining interoperability with the existing base is hard - far harder than just “updating the standard” -

Without a standard update, there is a bit of a chicken and egg problem with pursuing interoperability with any seriousness. I think 100.64/10 was a missed opportunity to incentivize the industry to pursue interoperability.

but is absolutely essential if you want viable reuse of 240/4. Of course, it does raise the question of whether the total effort will be worth the purported gain, but that really can’t be assessed until there's some specification of the proposed solution for interoperability with the existing deployed devices that don’t know about the 240/4 change.

Thanks, /John

p.s. Disclaimer(s): my views alone. Warning: may cause dizziness, headaches, or nausea.

Best, Joe

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 the most direct: - Redesignate 240/4 from RESERVED - Future Use to be available for allocation as 'standard' IPv4 addresses. I personally disagree with their position, as does the IETF, so it doesn't appear there will be any more movement on it, but I do believe that the idea itself was serious. Of course, I also agree with you that there have been plenty of un-serious proposals floated too which don't really require discussion. :) On Tue, Nov 22, 2022 at 1:48 PM John Curran <jcurran@istaff.org> wrote:

On Nov 22, 2022, at 1:19 PM, Joe Maimon <jmaimon@jmaimon.com> 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 the IPv6 folks found out the hard way… I will confess that I was a member of the IETF's IPng Directorate and thus inherently complicit in that particular fiasco –

John,

Flags days on the internet of today have proven to be of limited value.

Joe -

I am not suggesting a flag day for 240/4 (or any other particular approach) - merely noting that anyone who wishes to promote 240/4 has a wide range of options to consider when they decide to get serious and actually consider interoperability approaches.

The part I feel bad about is that I am actually un-involved in much of anyway with the 240/4 or other ideas, my sole input has been to attempt to encourage serious consideration and to rebut naysaying.

Serious consideration requires a serious proposal - I don’t think we’ve seen one yet.

Yes, a standards update is only the beginning of a real effort, although plenty has changed even without that.

Yes, there may and likely will be a large extent of interoperability and usability challenges for quite some time, perhaps even enough time that the issue becomes moot.

Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it has little contributory effect on IPv4.

However it may not and discouraging serious consideration is actually a contributing factor preventing any such potential.

I certainly am not discouraging serious consideration… simply awaiting something sufficient complete to discuss.

(Saying that “this proposal likely will create interoperability and usability challenges – but let’s all talk about the merits of it while ignoring that detail for now” doesn’t cut it – I’ve seen that approach once before and hasn’t turned out particularly well for anyone involved…)

Best wishes, /John

p.s. Disclaimer(s) - my views alone - please remember to have your arms and legs fully inside before the ride starts...

John Curran <jcurran@istaff.org> 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 all recent Cisco routers. We know that this step is safe, because it was already done a decade ago, and the Internet did not descend into flames (except on mailing lists ;-). The draft is just trying to help the paperwork catch up with the implementations. So it seems that John Curran was criticizing a strawman rather than the draft above (which I co-authored). Perhaps the confusion is that John thought that the draft would actually allocate 240/4 addresses to end-users for end-user purposes. Doing that would be unsafe in today's big Internet (though major squatters are already using these addresses in private clouds, as RIPE and Google have documented). Allocating these addresses would be far more controversial than just updating the code in IPv4 implementations. Therefore, the draft doesn't do that. Instead it would just clear out the cobwebs in implementations, which would some years later, after more work, allow a responsible party to make such allocations. John's suggestion that "it's unsafe to do this safe change, because we don't yet know *when* some later change will be safe" is simply incorrect. Perhaps what the draft failed to explain is that "Merely implementing unicast treatment of 240/4 addresses in routers and operating systems, as this draft proposes, does not cause any interoperability issues. Hundreds of millions of IPv4 nodes currently contain this unicast treatment, and all are interoperating successfully with each other and with non-updated nodes." We'll add something like that to the next version. John Gilmore IPv4 Unicast Extensions Project

Hi Abraham, Let me clarify a little bit on statistics - I did an investigation last year. Google and APNIC report very similar numbers. APNIC permits drilling down deep details. Then it is possible to understand that they see only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives Internet population by country - it permits to construct proportion. Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this year. I spent a decent time finding traffic statics. I have found one DPI vendor who has it. Unfortunately, they sell it for money. ARCEP has got it for France and published it in their "Barometer". Almost 70% of application requests are possible to serve from IPv6. Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide because France is typical. My boss told me "No-No" for this logic. His example is China where we had reliable data for only 20% of application requests served on IPv6 (China has a very low IPv6 adoption by OTTs). My response was: But India has a much better IPv6 adoption on the web server side. China and a few other countries are not representative. The majority are like France. Unfortunately, we do not have per-country IPv6 adoption on the web server side. OK. We could estimate 60% of the application readiness as a minimum. Then 60%*48%=28.8%. Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6. IX data shows much low IPv6 adoption because the biggest OTTs have many caches installed directly on Carriers' sites. Sorry for not the exact science. But it is all that I have. It is better than nothing. PS: 60% of requests served by web servers does not mean "60% of servers". For servers themselves we have statistics - it is just 20%+. But it is for the biggest web resources. Eduard -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Abraham Y. Chen Sent: Thursday, November 24, 2022 11:53 AM To: Joe Maimon <jmaimon@jmaimon.com> Cc: NANOG <nanog@nanog.org>; bzs@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’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be deceiving.   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.   B. If you read closely, the statement  "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.   C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.) https://stats.ams-ix.net/sflow/ether_type.html   D.  One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.   E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion. 2)  "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...":  My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface. https://en.wikipedia.org/wiki/APL_(programming_language) 3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for  inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress. Regards, Abe (2022-11-24 03:53 EST) On 2022-11-21 19:30, Joe Maimon wrote:

David Conrad wrote:

...

Barry,

On Nov 21, 2022, at 3:01 PM, bzs@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.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

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.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Hi Abe, the problem is that the AMS-IX data only covers the public fabric, but the peering connections between the big CDNs/clouds and the large ISPs all happen on private dedicated circuits as it is so much traffic that it does not make sense to run it over a public IX fabric (in addition to local caches which dillute the stats even more). Thus that data you are referring to is heavily biased and should not be used for this generalized purpose. Regards, Chris On 24.11.22 18:01, Abraham Y. Chen wrote:

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity issue of the data in this particular type of statistics. Any data that is based on a limited number of countries, regions, businesses, industry segments, etc. will always be rebutted with a counter example of some sort. So, we put more trust into those general service cases with continuous reports for consistency, such as AMS-IX. If you know any better sources, I would like to look into them.

Regards,

Abe (2022-11-24 11:59 EST)

On 2022-11-24 04:43, Vasilenko Eduard wrote:

...

Hi Abraham, Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep details. Then it is possible to understand that they see only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives Internet population by country - it permits to construct proportion. Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this year.

I spent a decent time finding traffic statics. I have found one DPI vendor who has it. Unfortunately, they sell it for money. ARCEP has got it for France and published it in their "Barometer". Almost 70% of application requests are possible to serve from IPv6. Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide because France is typical. My boss told me "No-No" for this logic. His example is China where we had reliable data for only 20% of application requests served on IPv6 (China has a very low IPv6 adoption by OTTs). My response was: But India has a much better IPv6 adoption on the web server side. China and a few other countries are not representative. The majority are like France. Unfortunately, we do not have per-country IPv6 adoption on the web server side. OK. We could estimate 60% of the application readiness as a minimum. Then 60%*48%=28.8%. Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For servers themselves we have statistics - it is just 20%+. But it is for the biggest web resources.

Eduard -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Abraham Y. Chen Sent: Thursday, November 24, 2022 11:53 AM To: Joe Maimon<jmaimon@jmaimon.com> Cc: NANOG<nanog@nanog.org>;bzs@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’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be deceiving.

    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

    B. If you read closely, the statement  "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

    C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

    D.  One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.

    E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.

2) "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...":  My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for  inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.

Regards,

Abe (2022-11-24 03:53 EST)

On 2022-11-21 19:30, Joe Maimon wrote:

...

David Conrad wrote:

...

Barry,

...

We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According tohttps://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6  has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a

On Nov 21, 2022, at 3:01 PM,bzs@theworld.com  wrote: transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

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.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Big OTTs installed caches all over the world. Big OTTs support IPv6. Hosts prefer IPv6. Hence, traffic becomes IPv6 to big OTTs. It is not visible for IXes. IXes statistics on IPv6 are not representative. Ed/ -----Original Message----- From: Abraham Y. Chen [mailto:aychen@avinta.com] Sent: Sunday, November 27, 2022 12:35 AM To: Chris Welti <chris.welti@switch.ch> Cc: NANOG <nanog@nanog.org>; bzs@theworld.com; Vasilenko Eduard <vasilenko.eduard@huawei.com> 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 that I have no knowledge about. However, you did not clarify how IPv6 and IPv4 are treated differently by these considerations which was the key parameter that we are trying to sort out. Thanks. Regards, Abe (2022-11-24 15:40) On 2022-11-24 12:23, Chris Welti wrote:

Hi Abe,

the problem is that the AMS-IX data only covers the public fabric, but the peering connections between the big CDNs/clouds and the large ISPs all happen on private dedicated circuits as it is so much traffic that it does not make sense to run it over a public IX fabric (in addition to local caches which dillute the stats even more). Thus that data you are referring to is heavily biased and should not be used for this generalized purpose.

Regards, Chris

On 24.11.22 18:01, Abraham Y. Chen wrote:

...

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity issue of the data in this particular type of statistics. Any data that is based on a limited number of countries, regions, businesses, industry segments, etc. will always be rebutted with a counter example of some sort. So, we put more trust into those general service cases with continuous reports for consistency, such as AMS-IX. If you know any better sources, I would like to look into them.

Regards,

Abe (2022-11-24 11:59 EST)

On 2022-11-24 04:43, Vasilenko Eduard wrote:

...

Hi Abraham, Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep details. Then it is possible to understand that they see only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives Internet population by country - it permits to construct proportion. Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this year.

I spent a decent time finding traffic statics. I have found one DPI vendor who has it. Unfortunately, they sell it for money. ARCEP has got it for France and published it in their "Barometer". Almost 70% of application requests are possible to serve from IPv6. Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide because France is typical. My boss told me "No-No" for this logic. His example is China where we had reliable data for only 20% of application requests served on IPv6 (China has a very low IPv6 adoption by OTTs). My response was: But India has a much better IPv6 adoption on the web server side. China and a few other countries are not representative. The majority are like France. Unfortunately, we do not have per-country IPv6 adoption on the web server side. OK. We could estimate 60% of the application readiness as a minimum. Then 60%*48%=28.8%. Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For servers themselves we have statistics - it is just 20%+. But it is for the biggest web resources.

Eduard -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Abraham Y. Chen Sent: Thursday, November 24, 2022 11:53 AM To: Joe Maimon<jmaimon@jmaimon.com> Cc: NANOG<nanog@nanog.org>;bzs@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’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may be deceiving.

    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

    B. If you read closely, the statement  "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

    C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

    D.  One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.

    E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.

2) "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...":  My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for  inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.

Regards,

Abe (2022-11-24 03:53 EST)

On 2022-11-21 19:30, Joe Maimon wrote:

...

David Conrad wrote:

...

Barry,

...

We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According tohttps://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a

On Nov 21, 2022, at 3:01 PM,bzs@theworld.com wrote: transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, IPv6+but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

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.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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. Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen <aychen@avinta.com> escreveu:

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 on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

B. If you read closely, the statement "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

D. One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.

E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.

2) "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...": My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.

Regards,

Abe (2022-11-24 03:53 EST)

On 2022-11-21 19:30, Joe Maimon wrote:

...

David Conrad wrote:

...

Barry,

On Nov 21, 2022, at 3:01 PM, bzs@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.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

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.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

-- Douglas Fernando Fischer Engº de Controle e Automação

On 24 Nov 2022, at 19:53, Abraham Y. Chen <aychen@avinta.com> 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 may be deceiving.

A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

Which doesn’t change that fact that the traffic to Google has gone from ~0% to 40% in 12 years. No one claimed that Google has been measuring IPv6 traffic since the very beginning nor does it really matter how long it has been since IPv6 was defined. What we are seeing is strong continuing growth in IPv6 usage where the S curve is a long way from flattening off.

B. If you read closely, the statement "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

If you read it correctly Google is measuring actual traffic. Thats actual data flowing to and from Google's servers be it Gmail, YouTube, search traffic or anything else. It does mean that the owners of the devices are using IPv6.

C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

What makes that “more meaningful” data. I just see different populations of users being measured. 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.

D. One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.

E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.

2) "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...": My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.

Regards,

Abe (2022-11-24 03:53 EST)

On 2022-11-21 19:30, Joe Maimon wrote:

...

David Conrad wrote:

...

Barry,

On Nov 21, 2022, at 3:01 PM, bzs@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.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

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.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, bzs@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.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards, -drc

Re-replying. Changing the standards is not what is intended to drive vendor changes. Userbase requests and projected needs do that. The standards are not responsible for the business case. However, they should not unreasonably impede it. Joe

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 opinion on it... People should go look at some of the WISPs in the Philippines for an example of ISPs building last and middle mile infrastructure on extremely limited budgets. Or really just about anywhere else where the residential broadband market has households where the entire household monthly income is the equivalent of $500 USD. On Sat, 19 Nov 2022 at 04:59, Mark Tinka <mark@tinka.africa> wrote:

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 folk just can't help themselves.

Mark.

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. Trying to extend the use of ipv4 space resources for a few more years is directly analogous to building sand castles on the beach when the tide is obviously coming in. On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen <aychen@avinta.com> wrote:

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 management that applies across the board. This subject is normally designed by system planners. The result is given to the product development engineers who usually do not have enough knowledge to question it.

1) The IPv4 address pool depletion issue was caused by the poor "resources management" concepts. In this case, the insistence on the Internet addressing should be flat (instead of hierarchical) led to the quick depletion of the finite sized 32-bit pool. The fact is that the current prevalent CDN (Content Delivery Network) business model based on CG-NAT configuration is a clear hierarchical network, anyway. All what EzIP proposes is to make it explicit and universal for improving the performance.

2) To create a viable hierarchical network with depleted address pool like IPv4 was practically an impossible task. Fortunately, the 240/4 netblock is available because it was "reserved for future use" ever since 1981-09, yet no clear application cases could be found. So, this is a natural resources that will benefit everyone without reference to financial status, although the developing regions can benefit more by utilizing it to leap frog out of the current disadvantaged situations.

Hope this explanation makes sense to you.

Regards,

Abe (2022-11-21 10:29 EST)

On 2022-11-20 17:56, Eric Kuhnke wrote:

...

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 opinion on it...

People should go look at some of the WISPs in the Philippines for an example of ISPs building last and middle mile infrastructure on extremely limited budgets. Or really just about anywhere else where the residential broadband market has households where the entire household monthly income is the equivalent of $500 USD.

On Sat, 19 Nov 2022 at 04:59, Mark Tinka <mark@tinka.africa> wrote:

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 folk just can't help themselves.

Mark.

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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

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 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.

This is know a false dichotomy. There is no actual reason to believe that any effort on option A detracts from available effort of option B. And when you purchase your new gear, or update the software, with its many many lines of code changes, it is not unreasonable to expect that at least some might be IPv4 related and that the removal of restriction on 240/4 would be the more trivial of those. 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. 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. Respectively, amusing and alarming. To be clear, the only thing preventing the Internet in freely organizing its own efforts is the unwillingness of curmudgeons to remove the reserved status in this particular instance. As no-one is requesting that you (or others of this persuasion) lend their personal efforts, your concern on the budgeting of efforts is out of place and worse, of dictatorial bend. For the sake of argument, ignoring above, presuming our control over the internet engineering efforts et al. Were I to propose to you that 240/4 be utilized only for new or existing organizations with less than /20 total resources or some other useful constraint, it would be easy to see that 240/4 would last a very long time and potentially have quite a significant impact. Earlier in this thread I contrasted a reduction from 12 to 1 of ip address consumption per new customer, depending on the practices employed by the service provider. As you can see, consumption rate is actually quite flexible, even now, today. So the answer to your question is it depends how freely it is handed out. Certainly not very long if it is business as usual prior to runout. Potentially much longer if not. And in a nod to your concern over effort expenditure, but even more so, conscious of 240/4 being the 32bit space last big easy gasp, I would be a strong proponent that it NOT be. However, even if it were, what exactly are we saving it for, if not for use by those who need it? Or is it to be a hedge over some eventuality where IPv6 has failed to the point of abandonment? I might actually respect that position, even as I doubt (and fear and hope against) such an eventualities actual occurrence. The more galling aspect of the 240/4 wars is that "it will take too long and then Ipv6 will be deployed" crowd that managed to stifle it initially continue to reuse that line again, in essence blase self perpetuation. Its only taking that long because of this attitude. Joe

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 LTE network operator with 5+ million customers globally. It is not a long term solution or even a good medium term solution.

To to the LM LTE Operator with 5+ mill. customer globally, it is not. Agreed. Also, I think they have already sorted themselves out sufficiently in a variety of ways. I am not concerned with them, at all. Which is why I did not offer that as an example of useful constraint. Re-run your projections with what I actually discussed, I think you will have a different conclusion. Joe

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 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP, MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on the scale of regional mid sized operators with 300,000 last mile broadband subscribers, or mobile network operators, nevermind top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of customers. One /16 is a tiny drop in the bucket compared to the demand for IP space for indivudual-customer DHCP pool usage by an ISP the size of Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is entirely exhausted.

Unrealistic? Halve it so that each network operator waiting for IP space reources gets one/ 17, one time only, I would still bet good money that there's 8000 ASes out there that right now would happily take their "free "single /17 , and you'd still have immediate complete exhaustion of 240/8.

Right now the IPv4 scarcity is a barrier of entry to new entities and a major speedbump in basic growth to small entities. So my constraint has much wider, lasting and meaningful impact than either of your thought exercises which essentially involve how to enable existing entities to resume business as usual for some amount of time. I am sure there many other much more meaningful ways to consider using 240/4 than that. New IPv4 resources to go towards addressing customers in the same fashion as was done ten years ago, I wouldn't bother with 240/4 for that either. Best, Joe

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 RFC1918. There will be nothing for corporate to grab. 2)  In addition, it is implicitly stated that the addresses in 240/4 will be assigned within a geographical Region, much like telephone numbers that are administrated by governments of respective jurisdictions as natural resources, not by global businesses as private properties. 3)  This may sound like against the "Internet way", but likely can eliminate the negative consequences of the current IP address allocation / assignment practices. Regards, Abe (2022-11-23 15:25 EST) On 2022-11-21 19:43, 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 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP, MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on the scale of regional mid sized operators with 300,000 last mile broadband subscribers, or mobile network operators, nevermind top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of customers. One /16 is a tiny drop in the bucket compared to the demand for IP space for indivudual-customer DHCP pool usage by an ISP the size of Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is entirely exhausted.

Unrealistic?  Halve it so that each network operator waiting for IP space reources gets one/ 17, one time only, I would still bet good money that there's 8000 ASes out there that right now would happily take their "free "single /17 , and you'd still have immediate complete exhaustion of 240/8.

On Mon, 21 Nov 2022 at 16:33, Joe Maimon <jmaimon@jmaimon.com> wrote:

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 LTE network operator with 5+ million customers globally. It is > not a long term solution or even a good medium term solution. > To to the LM LTE Operator with 5+ mill. customer globally, it is not. Agreed. Also, I think they have already sorted themselves out sufficiently in a variety of ways. I am not concerned with them, at all.

Which is why I did not offer that as an example of useful constraint. Re-run your projections with what I actually discussed, I think you will have a different conclusion.

Joe

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

On Nov 21, 2022, at 7:18 PM, Joe Maimon <jmaimon@jmaimon.com> 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 important aspect of the Internet that is rather germane to this discussion – ii.e. that we really don’t really have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent” –, but then you don’t really work through what that fact means for realistic outcomes of class E space re-utilization… First, I want to be really clear: I don’t particular care one way or the other regarding the proposal to “de-reserve” 240/4… I don't run a network (nor has the ARIN community discussed the matter and directed that ARIN take a position either way.) However, I do think the operator community should be thinking hard about how such de-reserving and redefinition into general purpose space will impact the Internet operations community and whether such space can realistically ever be utilized in production manner in the public Internet. As you alluded to, we really don’t have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent”, and the practical implications of this fact is that there will always be many devices out there in production that will not pass IP packets with class E addresses in them… (just as there’s always going to be some devices, somewhere that don’t know about IPv6.) Of course, the difference is that with IPv6 we can attempt a connection and then fall back to IPv4, and further that devices out there either support and are configured for IPv6 routing, or they are not - networks rather quickly learn not to announce (via routing & DNS) IPv6 connectivity for devices without it actually being in place and operational or having solid IPv4 fall-back and relying fast fallback/happy eyeballs. With your using repurposed class E address space in the headers, your customers with such addresses are rather unlikely to ever know why a connection won’t establish – or why existing connections sometime fail mid-stream – as it only takes a single non-conforming device along the ever-changing path through any number of network operators to resulting in the silent drop of that packet. 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 will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet. If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid. Thanks, /John p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.

On Nov 21, 2022, at 11:12 PM, Joe Maimon <jmaimon@jmaimon.com> 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 will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.

If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.

Thanks, /John

p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.

Right now the gossiped growing use of 240/4 in private and non standardized fashions jeopardizes any potential use of it just as much as the factors you describe.

Joe - That may be the case - I have no data either way, but it would not be surprising if some folks were paying very careful attention to their vendor support of 240/4 routing so that they can use this address space in a private context. However, I still have not heard any reasonable explanation for how connections using de-reserved 240/4 space in a public scope will be operationally viable, given that there will always be devices which do not forward such packets…

In either event, my main point of contention is in the lack of willingness for serious and prudent consideration. Such as along the lines of what you have brought up.

You have an opportunity now - please explain how such connections will not pose an operations nightmare for the rest of the public Internet – it is not at all apparent how such is avoided if 240/4 is changed from reserved to general purpose (if that’s what you are suggesting that we should be doing.) Of course the other alternative is what Abe has been suggesting (repeatedly): note that it is _not_ using 240/4 for general purpose address space, but rather for their "Adaptive IPv4 Address Space” <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/> mapping protocol. It seems to suffer from the same assumption of unmolested 240/4 transit in the public Internet (despite the current specification of such addresses as invalid) but then adds some further complication… something akin to CG-NAT but with their new EZ-IP protocol and “semi-public routers” as gateways doing the address mapping function. I am all for serious discussion of either of these interesting proposals, but if we’re going to seriously discuss such being deployed in the real-world then it had best start with the question of how they will handle the current Internet which frequently drops packets containing 240/4 addresses as invalid and will be doing so in places for many years to come. The upgrades in the real world to address that invalid-drop situation will take quite a while to happen (and note that time starts only after there’s an actual consensus for change in this regard), so – just as it was with IPv6 – it's incumbent on those proposing change to explain how interoperability occurs during the transition period. Thanks, /John p.s. Disclaimer(s): my views alone - this message made from 100% recycled electrons.

Lincoln Dale wrote:

On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <jmaimon@jmaimon.com <mailto:jmaimon@jmaimon.com>> 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 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 class E traffic, for which there is no fix. https://seclists.org/nanog/2021/Nov/272 is where I list one of them. There are many, many other devices where we have seen interesting behavior, some of which has been fixed, some of which has not.

cheers,

lincoln.

And I am sure you would agree that un-reserving a decade ago would have more than likely resulted in a greatly improved situation now. Along the lines that doing so now could still result in a greatly improved situation a decade hence. Should we still need it. Joe

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 characteristics. For example:    A. The activation of 240/4 netblocks is very scalable. It can be as small as starting from a residential home as evidenced by our initial realization of this technique via expanding the address pool by 256 folds utilizing 192.168.K/24, or as big as or even multiple of 100.64/4 netblocks that have been deployed all over the places for CG-NAT.   B. Since the enhancement to use 240/4 is from the last-mile equipment and up, equipment capable of the program change can be enhanced without coordinating with any router nearby. In fact, they can continue to communicate through the originally established setup. This is a selective incremental process. There is no requirement to upgrade them all at the same time, such as what happened to IPv6. (I hope that you would not tell me that the routers whose programs were modified to handle the 100.64/4 netblocks for CG-NAT operation only about one decade ago are now too old to accept 240/4.)   C. Once a router is enhanced to use 240/4, its original capability set continues with the addition of end-to-end connectivity within an area served by that router. No other routers would know about this change.   D. This gives incentives to other regions to upgrade at their own paces, respectively. Note that we are talking about a generic program enhancement which can be downloaded to routers of the same model series through maintenance update cycles. So, we should not be discouraged by counting how many total routers are out there.   E. Since the first phase of the EzIP deployment is to enhance CG-NAT, there is no expansion of global routing table. 2) "... directly analogous to building sand castles on the beach when the tide is obviously coming in. ":  This is the same as "the train has left the station" metaphor that we were told when we first started to look into this issue. So, we decided that our work was just for academic fun. As time went on, however, we learned that the Dual-Stack configuration was not just necessary but also going to last for a long time. Recently, we even heard (see the APNIC blog below as an example) that the IPv4 to IP6 transition may never end. So, I believe that it would be prudent for everyone to focus on improving his/her preferred version. There is no more reason to waste energy in discrediting the other camp's efforts. The transition to IPv6: Are we there yet? https://blog.apnic.net/2022/05/04/the-transition-to-ipv6-are-we-there-yet/ 3)  " ... Trying to extend the use of ipv4 space resources for a few more years ...  ":  Unlike other proposals that we are aware of, EzIP is an enhancement to RF6598 which applies to CG-NAT that is a hierarchical network. Following such a configuration, the manageable public IPv4 pool is extended to roughly 983MB addresses (see the last paragraph of Sub-Section 2.1 in the EzIP Draft). Administrated in the traditional communication system identification discipline and supplemented by RFC1918 netblocks, this resources can last for a really long time. Regards, Abe (2022-11-21 22:59 EST) On 2022-11-21 17:04, 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.

Trying to extend the use of ipv4 space resources for a few more years is directly analogous to building sand castles on the beach when the tide is obviously coming in.

On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen <aychen@avinta.com> wrote:

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 management that applies across the board. This subject is normally designed by system planners. The result is given to the product development engineers who usually do not have enough knowledge to question it.

1)  The IPv4 address pool depletion issue was caused by the poor "resources management" concepts. In this case, the insistence on the Internet addressing should be flat (instead of hierarchical) led to the quick depletion of the finite sized 32-bit pool. The fact is that the current prevalent CDN (Content Delivery Network) business model based on CG-NAT configuration is a clear hierarchical network, anyway. All what EzIP proposes is to make it explicit and universal for improving the performance.

2)  To create a viable hierarchical network with depleted address pool like IPv4 was practically an impossible task. Fortunately, the 240/4 netblock is available because it was "reserved for future use" ever since 1981-09, yet no clear application cases could be found. So, this is a natural resources that will benefit everyone without reference to financial status, although the developing regions can benefit more by utilizing it to leap frog out of the current disadvantaged situations.

Hope this explanation makes sense to you.

Regards,

Abe (2022-11-21 10:29 EST)

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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 conditioned into. If one practices "think out of the box" while examining EzIP, as marketers frequently like to say, you may come to a totally different perspective. That is, if you do not mind to flip a few coins along the way, even though individually may seem insignificant by itself, the accumulated effect can change the story. Allow me to go through the analysis that helped us to solidify the EzIP plan. 1) What you identified was a serious hurdle that stumbled us for quite awhile after we initially worked out the scheme of making use of the long-reserved 240/4 netblock to expand the publicly assignable IPv4 pool. It turned out that being a novice to the Internet, we tried too hard by trapping ourselves into literally attempting to achieve the end-to-end connectivity as well, immediately. By approaching the issue via the "Divide and Conquer" principle, the latest EzIP deployment strategy has been broken into two phases. The first is basic (obvious necessity) and straightforward. The second is optional (since it is more than the current Internet capable of) and requiring some efforts. However, both bypass the "top 50 websites" issue that you are concerned with. In a nutshell, they will never see EzIP, if they do not intend to be involved. 2)  The above is hard to visualize if you followed the bulk of the EzIP IETF Draft because its initial intent was to present the full EzIP technique and configuration for the long term which may not be universally needed based on our latest analysis. If you start reading the EzIP Draft from Appendix F and on that were added upon our realization of the above trade-off, you will get the sense that the "top 50 websites" are not necessarily part of the considerations. This is because the RAN (Regional Area Network) which is architecturally the same as an existing CG-NAT "module" (pardon me for not knowing the correct terminology of an area served by a 100.64/10 netblock), but much (64 times) larger. Consequently, a RAN can be self-contained for all practical purposes and collectively behave as a Sub-Internet. That is, the port translation at the highest level of a CG-NAT module does not need be disturbed upon the address transition. Similarly, the "Revamp The Internet" whitepaper was written after we realized this two-phase approach. So, it focused only on phase one. 3)  The first phase of EzIP deployment will be only replacing the 100.64/4 netblock of RFC6598 with the 240/4 netblock. This process can be achieved by just activating the use of the 240/4 netblock by the existing networking equipment. (This could be as simple as disabling one line of the code in a networking program that has been disabling the use of the 240/4 addresses.) The CG-NAT operations will not be perturbed. Since this transition will be confined within a RAN (replacing a few CG-NAT modules), the operation of distributed caching proxies used by the "top 50 websites" to support the CDN (Content Delivery Network) business configuration remain the same. So, the "top 50 websites" would not sense any changes due to EzIP deployment. One important benefit of this step is that static addresses may now be administrated to streamline daily operations that harden the defense against cyber intrusions. 4)  Once the above is done, there is a practical intermediate phase before attempting the worldwide end-to-end connectivity which has been elusive for the existing Internet. That is, since each RAN can be fairly large (Even without making use of private netblocks from RFC1918, each 240/4 can serve an area with the population as big as Tokyo Metro or over 75% of smaller countries around the world.), subscribers within each RAN can begin to enjoy end-to-end connectivity such as direct eMail exchanges. This is equivalent to domestic postal mails and telephony calls which are what ordinary citizens would care about most of the time, anyway. At this phase, no new capability is offered across RAN boundaries. Current eMail facility (which is by store and forward anyway) and similar will continue for such needs. 5)  Next, if anyone really cares for exchange messages directly with someone remote (beyond the local RAN), the full EzIP header format will be utilized (Remember the dial-up modem supported direct PC connections via international phone calls over the worldwide PSTN?). Still, the "top 50 websites" can continue their operations unaffected, unless they want to be more directly interacting with individuals in such activities. 6) Since the root of each RAN is connected to the Internet core via a public IPv4 address channel, the former can be regarded as a private network. This does not preclude RANs from establishing direct links (via 240/4 or spare public IPv4 address) among one another. With such, an overlay network covering the entire globe can be formed with its own "top websites" that will function as a cyberspace that is parallel to, but practically independent of, the existing Internet. 7)  In summary, the EzIP deployment is consciously planned to be incremental while avoiding disturbing the existing Internet configurations and practices. 8) Since we are still refining the EzIP scheme, the above outline may not be fully self-consistent. Please let me know any parts that are not clear. I will try to improve them. Regards, Abe (2022-11-21 09:49 EST) On 2022-11-20 16:15, Matthew Petach wrote:

On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen <aychen@avinta.com> 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:

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-s...

Hi Abraham,

I know I'm not the sharpest tool in the shed, but I'm having some trouble understanding the deployment model for EzIP. Perhaps you could help clear it up for me?

A non-EzIP web server is only going to see the global destination IP address and TCP port number as the unique session identifiers for communication, so the vast amount of additional IP space you postulate existing behind the SPR functionally collapses down into the 64K TCP port range available today in traditional port-based NAT setups.  As long as the top 50 websites aren't EzIP-aware, there appears to be no benefit for an ISP to deploy EzIP, because it doesn't actually gain them anything beyond what existing CG-NAT devices already provide as far as their web-browsing customer base is concerned. Most of their communication will still be port-based-NAT, with all the headaches and restrictions inherent in that.

And for the top 50 websites, there's a lot of expense and absolutely no upside involved in deploying EzIP.  They don't care about how much IP space you have behind your NAT device, and whether it's uniquely identifiable within your local realm; it's not information they can access for tracking users, as they don't know what your internal mapping is, so they'll continue to rely on browser cookies and the like for tracking actual user sessions, regardless of the IP addressing format being used.

So, you've got a model where there's functionally almost no benefit to the end user until the major websites start deploying EzIP-aware infrastructure, and there's pretty much no incentive for major websites to spend money upgrading their infrastructure to support EzIP, because it provides no additional benefit for them.

This is pretty much exactly the same conundrum that IPv6 faced (and still faces today).  I don't see why EzIP is any better than IPv6 or CG-NAT in terms of solving the IPv4 address shortage problem, and it seems to involve more expense for web providers, because it requires them to deploy additional SPR mapping routers into their infrastructure in order to use it, with essentially no additional benefit.

Is there a piece to the picture I'm not understanding correctly?

Thanks!

Matt

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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’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-s...

For the benefit of anyone who may not understand, this is not an 'alternative'. This is an idea that was initially proposed by the authors almost exactly 6 years ago. It's received almost no interest from anyone involved in internet standards, and for various technical reasons , likely never will.

On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen <aychen@avinta.com> 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:

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-s...

2)  If this looks a bit too technical due to the nature of such a document, there is a distilled version that provides a bird-eye's view of the solution:

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

3)  All of the above can start from making use of the 240/4 netblock as a reusable (by region / country) unicast IP address resources that could be accomplished by as simple as commenting out one line of the existing network router program code. I will be glad to go into the specifics if you can bring their attention to this almost mystic topic.

Regards,

Abe (2022-11-19 22:50 EST)

On 2022-11-18 18:20, Owen DeLong via NANOG wrote: > >> On Nov 18, 2022, at 03:44, Joe Maimon <jmaimon@jmaimon.com> 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 designs per customer does not scale well. >> its almost 2023. /31 support is easily mandatory. You should make it mandatory. > Much of Africa in 2023 runs on what the US put into the resale market in the late 1990s, tragically. > >> Its 2023, your folk should be able to handle addressing more advanced than from the 90s. And your betting the future on IPv6? > They don’t really have a lot of alternatives. > >>> To be honest, we'll keep using IPv4 for as long as we have it, and for as long as we can get it from AFRINIC. But it's not where we are betting the farm - that is for IPv6. > And yet you wonder why I consider AFRINIC’s artificial extension of the free pool through draconian austerity measures to be a global problem? > >> Its on Afrinic to try and preserve their pool if they wish to by doing things such as getting it across that progress in addressing efficiency is an important consideration in fulfilling requests for additional resources. > Instead of this, they’re mostly ignoring policy, implementing draconian restrictions on people getting space from the free pool, and buying into various forms of reality avoidance. > >> But see the crux above. If your RiR isnt frowning on such behavior then its poor strategy to implement it. > So far, AFRINIC has given a complete pass to Tinka’s organization and their documented excessive unused address space despite policy that prohibits them from doing so. However, AFRINIC management and board seem to have extreme difficulty with reading their governing documents in anything resembling a logical interpretation. > > Owen >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com>

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 good memory, I do not leave a loose end to any  technical discussion with substance. The revisions of the EzIP documentation have always been improving the presentation style for easing the reader's efforts, not about modifying our basic scheme. So, you need to be clear about the topics that you are referring to. Thanks. Regards, Abe (2022-11-21 17:16 EST) On 2022-11-21 13:23, Tom Beecher wrote:

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, Nov 21, 2022 at 12:29 PM Abraham Y. Chen <aychen@avinta.com> wrote:

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’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-s... > > > For the benefit of anyone who may not understand, this is not an > 'alternative'. This is an idea that was initially proposed by the > authors almost exactly 6 years ago. It's received almost no interest > from anyone involved in internet standards, and for various technical > reasons , likely never will. > > On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen <aychen@avinta.com> > 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: > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-s... > >     2)  If this looks a bit too technical due to the nature of such a >     document, there is a distilled version that provides a bird-eye's >     view >     of the solution: > > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf > >     3)  All of the above can start from making use of the 240/4 >     netblock as >     a reusable (by region / country) unicast IP address resources that >     could >     be accomplished by as simple as commenting out one line of the >     existing >     network router program code. I will be glad to go into the >     specifics if >     you can bring their attention to this almost mystic topic. > >     Regards, > > >     Abe (2022-11-19 22:50 EST) > > >     On 2022-11-18 18:20, Owen DeLong via NANOG wrote: >     > >     >> On Nov 18, 2022, at 03:44, Joe Maimon <jmaimon@jmaimon.com> 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 designs per >     customer does not scale well. >     >> its almost 2023. /31 support is easily mandatory. You should >     make it mandatory. >     > Much of Africa in 2023 runs on what the US put into the resale >     market in the late 1990s, tragically. >     > >     >> Its 2023, your folk should be able to handle addressing more >     advanced than from the 90s. And your betting the future on IPv6? >     > They don’t really have a lot of alternatives. >     > >     >>> To be honest, we'll keep using IPv4 for as long as we have it, >     and for as long as we can get it from AFRINIC. But it's not where >     we are betting the farm - that is for IPv6. >     > And yet you wonder why I consider AFRINIC’s artificial extension >     of the free pool through draconian austerity measures to be a >     global problem? >     > >     >> Its on Afrinic to try and preserve their pool if they wish to >     by doing things such as getting it across that progress in >     addressing efficiency is an important consideration in fulfilling >     requests for additional resources. >     > Instead of this, they’re mostly ignoring policy, implementing >     draconian restrictions on people getting space from the free pool, >     and buying into various forms of reality avoidance. >     > >     >> But see the crux above. If your RiR isnt frowning on such >     behavior then its poor strategy to implement it. >     > So far, AFRINIC has given a complete pass to Tinka’s >     organization and their documented excessive unused address space >     despite policy that prohibits them from doing so. However, AFRINIC >     management and board seem to have extreme difficulty with reading >     their governing documents in anything resembling a logical >     interpretation. >     > >     > Owen >     > > > >     -- >     This email has been checked for viruses by Avast antivirus software. > www.avast.com <http://www.avast.com> <http://www.avast.com> >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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 Boston sidewalk and then delivered it.), eMails are fast (Once my eMail monitoring account started to receive a long message that I was sending out, even before it was fully sent.) but unpredictable from time to time. Unfortunately, most of us are conditioned with the normal speed and do not suspect the electronic system hiccups (As Andrew Grove once said, "It is the software, not the hardware.). To deal with this kind of issues in none-real time communication, I practice a discipline started from VM and FAX that I will respond within 24 hours. I encourage colleagues to start reminding me (either repeat the MSG or using alternative channels, such as SkyPe - My handle is A"Abraham.Y.Chen"), if they do not hear from me on topics expecting responses after 48 hours. This convention prevented much of the disruptions. Looking at your comments, I definitely would have responded back then if I saw it. One possibility is that I was in the middle of trying to get used to NANOG posting protocols. I was probably overwhelmed by the digest mode, uni-code,etc. issues. Anyway, allow me to try carry on. 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 serve a very large area (such as Tokyo Metro and such) that becomes the RAN in EzIP terminology. Each RAN is tethered from the existing Internet core by an umbilical core based on one IPv4 public address. This is like a kite floating in the sky which is basic building block of the overlaying Sub-Internet when they expand to cover the entire world. Throughout this entire process, the Option Word mechanism in the IP head doe not need be used at all. (It turns out that utilizing the CG-NAT configuration as the starting point, the only time that the Option Word may be used is when subscribers in two separate RANs wishing to have end-to-end communication, such as direct private eMail exchanges. On 2022-11-21 18:46, Tom Beecher wrote:

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  technical discussion with substance.

With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues with your proposal. Others have commented on non-technical, but practical considerations. In all cases, you have simply handwaved them away or not commented on them further.

On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <aychen@avinta.com> wrote:

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 good memory, I do not leave a loose end to any technical discussion with substance. The revisions of the EzIP documentation have always been improving the presentation style for easing the reader's efforts, not about modifying our basic scheme. So, you need to be clear about the topics that you are referring to. Thanks.

Regards,

Abe (2022-11-21 17:16 EST)

On 2022-11-21 13:23, Tom Beecher wrote: > >     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, Nov 21, 2022 at 12:29 PM Abraham Y. Chen <aychen@avinta.com> > wrote: > >     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’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-s... >     > >     > >     > For the benefit of anyone who may not understand, this is not an >     > 'alternative'. This is an idea that was initially proposed by the >     > authors almost exactly 6 years ago. It's received almost no >     interest >     > from anyone involved in internet standards, and for >     various technical >     > reasons , likely never will. >     > >     > On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen >     <aychen@avinta.com> >     > 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: >     > >     > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-s... >     > >     >     2)  If this looks a bit too technical due to the nature of >     such a >     >     document, there is a distilled version that provides a >     bird-eye's >     >     view >     >     of the solution: >     > >     > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf >     > >     >     3)  All of the above can start from making use of the 240/4 >     >     netblock as >     >     a reusable (by region / country) unicast IP address >     resources that >     >     could >     >     be accomplished by as simple as commenting out one line of the >     >     existing >     >     network router program code. I will be glad to go into the >     >     specifics if >     >     you can bring their attention to this almost mystic topic. >     > >     >     Regards, >     > >     > >     >     Abe (2022-11-19 22:50 EST) >     > >     > >     >     On 2022-11-18 18:20, Owen DeLong via NANOG wrote: >     >     > >     >     >> On Nov 18, 2022, at 03:44, Joe Maimon >     <jmaimon@jmaimon.com> 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 >     designs per >     >     customer does not scale well. >     >     >> its almost 2023. /31 support is easily mandatory. You should >     >     make it mandatory. >     >     > Much of Africa in 2023 runs on what the US put into the resale >     >     market in the late 1990s, tragically. >     >     > >     >     >> Its 2023, your folk should be able to handle addressing more >     >     advanced than from the 90s. And your betting the future on IPv6? >     >     > They don’t really have a lot of alternatives. >     >     > >     >     >>> To be honest, we'll keep using IPv4 for as long as we >     have it, >     >     and for as long as we can get it from AFRINIC. But it's not >     where >     >     we are betting the farm - that is for IPv6. >     >     > And yet you wonder why I consider AFRINIC’s artificial >     extension >     >     of the free pool through draconian austerity measures to be a >     >     global problem? >     >     > >     >     >> Its on Afrinic to try and preserve their pool if they wish to >     >     by doing things such as getting it across that progress in >     >     addressing efficiency is an important consideration in >     fulfilling >     >     requests for additional resources. >     >     > Instead of this, they’re mostly ignoring policy, implementing >     >     draconian restrictions on people getting space from the free >     pool, >     >     and buying into various forms of reality avoidance. >     >     > >     >     >> But see the crux above. If your RiR isnt frowning on such >     >     behavior then its poor strategy to implement it. >     >     > So far, AFRINIC has given a complete pass to Tinka’s >     >     organization and their documented excessive unused address space >     >     despite policy that prohibits them from doing so. However, >     AFRINIC >     >     management and board seem to have extreme difficulty with >     reading >     >     their governing documents in anything resembling a logical >     >     interpretation. >     >     > >     >     > Owen >     >     > >     > >     > >     >     -- >     >     This email has been checked for viruses by Avast antivirus >     software. >     > www.avast.com <http://www.avast.com> <http://www.avast.com> <http://www.avast.com> >     > >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com>

On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen <aychen@avinta.com> 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 serve a very large area (such as Tokyo Metro and such) that becomes the RAN in EzIP terminology. Since each RAN is tethered from the existing Internet core by an umbilical cord operating on one IPv4 public address, this is like a kite floating in the sky which is the basic building block for the overlaying EzIP Sub-Internet when they expand wide enough to begin covering significant areas of the world. Note that throughout this entire process, the Option Word mechanism in the IP header does not need be used at all. (It turns out that utilizing the CG-NAT configuration as the EzIP deployment vehicle, the only time that the Option Word may be used is when subscribers in two separate RANs wishing to have end-to-end communication, such as direct private eMail exchanges.)

Hi Abraham, I notice you never replied to my earlier questions about EzIP deployment. I'll assume for the moment that means my concerns were without merit, and will leave them aside. But in reading this new message, I find myself again rather confused. You stated: "Since each RAN is tethered from the existing Internet core by an umbilical cord operating on one IPv4 public address," I find myself staring at that statement, and puzzling over and over again at how multi-homing would work in the EzIP world. Would a given ISP anycast their single global public IPv4 address to all their upstream providers from all of their edge routers, and simply trust stable routing in the DFZ to ensure packets arrived at the correct ingress location to be mapped from the public internet into the RAN? Or do you really mean that every RAN will have one giant single point of failure, a single uplink through which all traffic must pass in order to reach the DFZ public internet? If your regional network is a housing subdivision, I can understand the model of a single uplink connection for it; but for anything much larger, a single uplink seems like an unsustainable model. You mention Tokyo Metro in your message as an example. What size single uplink do. you think would be sufficient to support all the users in the Tokyo Metro region? And how unhappy would they be if the single router their 1 public IP address lived on happened to have a hardware failure? Wouldn't it be better if the proposed model built in support for multihoming from day one, to provide a similar level of redundancy to what is currently available on the Internet today? Or is EzIP designed solely for small, singled-homed residential customers, and is not intended at all for enterprise customers who desire a more resilient level of connectivity? As I noted in my previous message, this seems like an awful lot of work to go through for relatively little benefit--but this may simply be due to a lack of essential clue on my part. I would very much like to be enlightened. Thank you! Matt

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: **** 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 story that USPS found a forty years old letter stuck in one of the mail collection boxes on Boston sidewalk and then delivered it.), eMails are fast (Once my eMail monitoring account started to receive a long message that I was sending out, even before it was fully sent.) but unpredictable from time to time. Unfortunately, most of us are conditioned with its daily behavior and do not suspect the electronic system hiccups (As Andrew Grove once said, "It is the software, not the hardware."). To deal with this kind of issues in none-real-time communications, I practice a discipline, started from VM and FAX, that I will do my best to respond within 24 hours. I encourage my colleagues to start reminding me (either repeat the MSG or using alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), if they do not hear from me after 48 hours on topics that they expect my response. This convention prevented much of the disruptions. Looking at your comments, I definitely would have responded back then if I saw them. One possibility is that I was in the midst of being overwhelmed by NANOG posting protocols, such as the digest mode, uni-code, personal writing styles, etc. and miseed your MSG. Anyway, allow me to try carrying on.

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 serve a very large area (such as Tokyo Metro and such) that becomes the RAN in EzIP terminology. Since each RAN is tethered from the existing Internet core by an umbilical cord operating on one IPv4 public address, this is like a kite floating in the sky which is the basic building block for the overlaying EzIP Sub-Internet when they expand wide enough to begin covering significant areas of the world. Note that throughout this entire process, the Option Word mechanism in the IP header does not need be used at all. (It turns out that utilizing the CG-NAT configuration as the EzIP deployment vehicle, the only time that the Option Word may be used is when subscribers in two separate RANs wishing to have end-to-end communication, such as direct private eMail exchanges.)

3) " ... to drop any packet with an IP option set that you don't explicitly want because a significant number of routers kick every packet with options to CPU, ... ": Yes, this was what we were reminded of when we started our study. However, this appears to be another Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's Refernce 13) told me that his team had successfully sent packets with Option Words. Again, even if the existing routers do knock out packs with Option words, the overlay architecture of the RANs allows the search for those do allow this operation. Since the use of the Option Word turns out to be an option to superceed IPv4's capabilities, we should treat it as a consideration for future premium services.

4) " ...Any device that still treated 240/4 differently would need to be updated to treat it like anything else. .. ": Yes, this applies to regions that desire to enjoy the EzIP characteristics. Since the root of each RAN (or sub-RAN) still appears to be one of the current CG-NAT modules, there is no change can be detected by other CG-NAT modules. This avoids interoperability issues during the incremental deployment.

5) "  ...Any existing filters that dropped packets with *any* IP option set would have to be modified to permit the ones you define for EzIP....":  Since EzIP is not going to activate Option Words initially for enhancing the CG-NAT, this should not be a concern. In the future, inter-RAN communication by subscribers would use Option words. But, by that time, finite number of backbone / gateway routers among RANs capable of preserving Option Words would have been identified. This approach takes advantage of the hierarchical network configuration that CG-NAT has already been practicing implicitly.

6) "... ( At one point in the past, one big router vendor only allowed you to configure an ip-options filter based on the IANA defined values, not others. ) ...": Well, you are talking about the overly intertwined relationship between one big roouter vendor and the IANA which is sponsored by the former. So, this is not a technical but a "busniess" issue. We have talked with "white box" vendors. One assured us that EzIP can be quickly activated in thier programs if customers do ask for it.

7) "... This is a LOT of work and time for an overlay. ...": You are probably visualizing a complete overlay network right from the beginning. The EzIP approach is gradual and incremental as outlined in the above descriptions. An EzIP deployment can be as small as a residential network because it was how we initially figured out this solution. It is based on parties who desire to participate, case by case. Those who don't, do not need to do anything, nor could notice any difference. All of these turn out to be the result of the fundametal Internet characteristics that can transmit every bit of compatible signals. Then, a sub-group of routers can link up with compatible nodes to form a new network on their own, which can coexist with, yet independent of the others (such as IPv4, IPv6, ARP, other as reported by AMS-IX).

I look forward to your thoughts,

Regards,

Abe (2022-11-22 23:22 EST)

On 2022-11-21 18:46, Tom Beecher wrote:

...

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  technical discussion with substance.

With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues with your proposal. Others have commented on non-technical, but practical considerations. In all cases, you have simply handwaved them away or not commented on them further.

On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <aychen@avinta.com> wrote:

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 good memory, I do not leave a loose end to any technical discussion with substance. The revisions of the EzIP documentation have always been improving the presentation style for easing the reader's efforts, not about modifying our basic scheme. So, you need to be clear about the topics that you are referring to. Thanks.

Regards,

Abe (2022-11-21 17:16 EST)

On 2022-11-21 13:23, Tom Beecher wrote:

...

     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, Nov 21, 2022 at 12:29 PM Abraham Y. Chen &lt;aychen@avinta.com> > wrote: > >     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’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 understand, this is not an      > 'alternative'. This is an idea that was initially proposed by the      > authors almost exactly 6 years ago. It's received almost no      interest      > from anyone involved in internet standards, and for      various technical      > reasons , likely never will.      >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

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 provided the missing information that made the difference. I would appreciate very much if you could confirm. Regards, Abe (2022-12-02 22:35 EST) On 2022-12-01 16:34, Tom Beecher wrote:

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 <aychen@avinta.com> 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 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: **** 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 story that USPS > found a forty years old letter stuck in one of the mail collection > boxes on Boston sidewalk and then delivered it.), eMails are fast > (Once my eMail monitoring account started to receive a long message > that I was sending out, even before it was fully sent.) but > unpredictable from time to time. Unfortunately, most of us are > conditioned with its daily behavior and do not suspect the electronic > system hiccups (As Andrew Grove once said, "It is the software, not > the hardware."). To deal with this kind of issues in none-real-time > communications, I practice a discipline, started from VM and FAX, that > I will do my best to respond within 24 hours. I encourage my > colleagues to start reminding me (either repeat the MSG or using > alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), > if they do not hear from me after 48 hours on topics that they expect > my response. This convention prevented much of the disruptions. > Looking at your comments, I definitely would have responded back then > if I saw them. One possibility is that I was in the midst of being > overwhelmed by NANOG posting protocols, such as the digest mode, > uni-code, personal writing styles, etc. and miseed your MSG. Anyway, > allow me to try carrying on. > > 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 > serve a very large area (such as Tokyo Metro and such) that becomes > the RAN in EzIP terminology. Since each RAN is tethered from the > existing Internet core by an umbilical cord operating on one IPv4 > public address, this is like a kite floating in the sky which is the > basic building block for the overlaying EzIP Sub-Internet when they > expand wide enough to begin covering significant areas of the world. > Note that throughout this entire process, the Option Word mechanism in > the IP header does not need be used at all. (It turns out that > utilizing the CG-NAT configuration as the EzIP deployment vehicle, the > only time that the Option Word may be used is when subscribers in two > separate RANs wishing to have end-to-end communication, such as direct > private eMail exchanges.) > > 3) " ... to drop any packet with an IP option set that you don't > explicitly want because a significant number of routers kick every > packet with options to CPU, ... ": Yes, this was what we were reminded > of when we started our study. However, this appears to be another > Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's > Refernce 13) told me that his team had successfully sent packets with > Option Words. Again, even if the existing routers do knock out packs > with Option words, the overlay architecture of the RANs allows the > search for those do allow this operation. Since the use of the Option > Word turns out to be an option to superceed IPv4's capabilities, we > should treat it as a consideration for future premium services. > > 4) " ...Any device that still treated 240/4 differently would need to > be updated to treat it like anything else. .. ": Yes, this applies to > regions that desire to enjoy the EzIP characteristics. Since the root > of each RAN (or sub-RAN) still appears to be one of the current CG-NAT > modules, there is no change can be detected by other CG-NAT modules. > This avoids interoperability issues during the incremental deployment. > > 5) "  ...Any existing filters that dropped packets with *any* IP > option set would have to be modified to permit the ones you define for > EzIP....":  Since EzIP is not going to activate Option Words initially > for enhancing the CG-NAT, this should not be a concern. In the future, > inter-RAN communication by subscribers would use Option words. But, by > that time, finite number of backbone / gateway routers among RANs > capable of preserving Option Words would have been identified. This > approach takes advantage of the hierarchical network configuration > that CG-NAT has already been practicing implicitly. > > 6) "... ( At one point in the past, one big router vendor only allowed > you to configure an ip-options filter based on the IANA defined > values, not others. ) ...": Well, you are talking about the overly > intertwined relationship between one big roouter vendor and the IANA > which is sponsored by the former. So, this is not a technical but a > "busniess" issue. We have talked with "white box" vendors. One assured > us that EzIP can be quickly activated in thier programs if customers > do ask for it. > > 7) "... This is a LOT of work and time for an overlay. ...": You are > probably visualizing a complete overlay network right from the > beginning. The EzIP approach is gradual and incremental as outlined in > the above descriptions. An EzIP deployment can be as small as a > residential network because it was how we initially figured out this > solution. It is based on parties who desire to participate, case by > case. Those who don't, do not need to do anything, nor could notice > any difference. All of these turn out to be the result of the > fundametal Internet characteristics that can transmit every bit of > compatible signals. Then, a sub-group of routers can link up with > compatible nodes to form a new network on their own, which can coexist > with, yet independent of the others (such as IPv4, IPv6, ARP, other as > reported by AMS-IX). > > I look forward to your thoughts, > > Regards, > > > Abe (2022-11-22 23:22 EST) > > > > > > On 2022-11-21 18:46, Tom Beecher wrote: >> >> 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  technical >> discussion with substance. >> >> >> With the utmost amount of respect, you do. >> >> Many people on this list have provided specific , technical issues >> with your proposal. Others have commented on non-technical, but >> practical considerations. In all cases, you have simply handwaved >> them away or not commented on them further. >> >> >> >> On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <aychen@avinta.com> >> wrote: >> >> 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 good memory, I do not leave a loose end to any technical >> discussion with substance. The revisions of the EzIP documentation >> have >> always been improving the presentation style for easing the reader's >> efforts, not about modifying our basic scheme. So, you need to be >> clear >> about the topics that you are referring to. Thanks. >> >> Regards, >> >> >> Abe (2022-11-21 17:16 EST) >> >> >> >> On 2022-11-21 13:23, Tom Beecher wrote: >> > >> >     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, Nov 21, 2022 at 12:29 PM Abraham Y. Chen >> <aychen@avinta.com> >> > wrote: >> > >> >     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’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-s...

>> >> >     > >> >     > >> >     > For the benefit of anyone who may not understand, this is >> not an >> >     > 'alternative'. This is an idea that was initially proposed >> by the >> >     > authors almost exactly 6 years ago. It's received almost no >> >     interest >> >     > from anyone involved in internet standards, and for >> >     various technical >> >     > reasons , likely never will. >> >     > >

-- This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com>

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, your folk should be able to handle addressing more advanced than from the 90s.

Customers will do what they do.

And your betting the future on IPv6?

Actually, yeah.

The only issue with it is traceroute although that isnt necessarily a problem.

We and some of our customers find that useful.

And the CPE sourced traffic should either be all internal or sourced from the loopback.

It's not my CPE, I don't get to make the rules.

OTOH CoPP protection becomes a lot easier when fewer of the CP addressing is globally routed.

As does not connecting any cables to the device. Seriously, all good points. We just have more pressing issues to deal with.

Truth is the real issue isnt CPE support, its user support. Most users(even their "IT" folk) really cant wrap their brain around more than the bare basic concepts, if that much.

And you can simply say, IPv4 is limited, this is the base model addressing included with the service, if your inabilities are preventing you from using networking techniques that have been standardized and usable for decades, then feel free to pony up for either for your comfort level or for support of your inabilities.

Okay.

This is the crux. So long as you can obtain more, justifiable consumption is rewarded with additional resources, dis-incentivizing any addressing efficiency progress from the ancient /30 p2p + /29(or larger) routed block.

You may wish to lay groundwork to nibble backwards when runout occurs for you.

Its on Afrinic to try and preserve their pool if they wish to by doing things such as getting it across that progress in addressing efficiency is an important consideration in fulfilling requests for additional resources.

We aren't really going to expend too many resources on trying to delay the use of IPv6. I understand that I am speaking from a place of priviledge, having as much IPv4 as we do, but even then, we will connect as many as we connect using either "efficient" or "inefficient" techniques, and neither will prevent run-out, eventually. We want to be able to keep servicing customers, long after we are gone. That is what we care about.

If they need more, they pay more and they get more. Most of the rest of the world is operating or moving to operate in that fashion.

It's fine for most of the world to do what it wants. I won't begrudge them that. Over here, we will do what we feel works for us.

You would still require them to submit a formal request documenting their need. And paying more is likely to mean that its a more honest request.

We do this already, only without asking them for cash.

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.

Although, if you can get away with it, allocating the /30 + /29 and implementing it in an easy-to-clawback approach might be a good strategy.

There is reasonable customer movement between competitors that address space comes and goes.

Thats a question of internal discipline without motivating external factors. Odds are those factors will arrive and I would advise preparedness for them.

Have you ever been in sales :-)? Mark.

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 we did soon afterwards, and to get a decent histogram for our trie emulations of what real customer traffic might look like once we started scaling past 40Gbit. (the XDP trie lookup is pretty expensive for us currently, but a lot cheaper than the /32s) Some idea of failover mechanisms other than BGP (igps are all over the map) came from this conversation also. I would certainly like to learn more about how well that works. A new question I have... is there any decent rules for CGNAT vs bandwidth vs customer allocations of ipv4 space? I've had a few horror stories shared with me privately about that, of note was 9000 *fiber* users behind a single /32. with no way to haul ipv6 or more ips there....

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. /31 support is easily mandatory. You should make it mandatory.

Mikrotik still doesn't support /31 addressing. I had a customer who was configuring their "router" the other day and we found this out. Has to move to a /30 on the link.

You cannot configure a /31 on a Mikrotik yet you can play with /32 to overcome this limit.

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 subnet config to my customer of 255.255.255.254 and it wouldn't take it. I reconfigured it to a /30 (.252) and it worked for them. This was a on a RB2011 about 3 months ago. I search at the time showed it was a know issue. We laughed about it and moved on. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

...

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