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