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

Tue Nov 22 04:00:16 UTC 2022

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