ipv4/25s and above

Mailman List Mirror (Read Only)
21

Dear Rubens:

0) Very good question. It is right to the point!

1) Initially, we thought that we were doing conventional protocol development engineering that was triggered by our curiosity about why IPv4 address pool was depleted. So, IETF Draft was the natural place to report what we were doing.

2) As time went on, it became evident that our scheme was rather unorthodox. That is, it was surprisingly simpler than any other known techniques. As well, the benefits were more and better than we could have dreamed for. At the same time, developed countries such as US where I was in, were not in any material need for IPv4 addresses, yet promoting IPv6. Not being able to sort out this contradiction, it was necessary to keep a continuous public record as IETF Draft revisions of EzIP evolution as we continued to refine our scheme which had turned into a concise system engineering solution, or almost appeared to be a marketing trick.

3) In a sense, we have been purposely publishing our work on the web (beyond IETF Draft) to invite critiques. So far, we have not received any explicit feedback pointing to its flaws, while there have been more than a couple subtle confirmations from rather senior Internet experts. I am sure that you would understand that we can not disclose the latter on our own. Nevertheless, they do enforce our confidence in the EzIP plan.

4) In anticipation of your next question, I would like to add the following. To be sure that our discovery is protected from being claimed by others and then its fair use discouraged, the essence of the EzIP concept was submitted to US Patent Office and has been granted with US Pat. No. 11,159,425. This assures that EzIP may be openly discussed to reach as much general public as possible.

Hope the above background recap is sufficient to clear your concerns. I look forward to our additional exchanges.

Regards,

Abe (2022-11-20 17:00 EST)

22

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.

23

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.

24

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)

25

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)

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

27

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.

Regards,

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

28

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.

29

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)

30

Dear Tom:

0) Thanks for your advice.

1) What I wrote was just informal online chatting. I was not attempting to make a water-tight legal statement. The fact is, we have identified at least one concise case of how this task could be done easily, as reported in Appendix D of the EzIP IETF Draft. Although no references have been published, I believe that colleagues on the IPv4 Unicast Extensions Project have seen similar situations. Even without the latter, a "there exists one reference" should be sufficient to encourage other software engineers to review their own work. They should question the quality of their own programs if they are more complex, instead of ridiculing the concise example on the table.

Regards,

Abe (2022-11-21 12:54 EST)

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

32

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.

33

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)

34

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

35

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.

36

(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

37

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.

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

39

This is basically exactly what has come out of the IETF for this and similar ideas.

I doubt it will ever stop them from being put forth though.

40

Barry,