Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”
Shane On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen <ayc...@avinta.com> wrote:
Hi, Forrest:
1) Re: Ur. Pt. 1):
The initial deployment of EzIP overlay is only applying 240/4 to
existing (IPv4 based) CG-NAT facility to become the overlaying
RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
OpenWrt. So that none of the on-premises IoTs will sense any
changes. I don't see how an upgrade of such equipment to IPv6
could be simpler and less work. Please elaborate.
2) Re: Ur. Pt. 2):
Since the RAN still appear to be the original CG-NAT to the
Internet through the same IPv4 link to the Internet core,
services from Google, YouTube, etc. will not know something has
changed either.
3) " ... someone with
enough market power is going to basically say "enough is
enough" ... ":
We need to look at
this transition with a "Divide and Conquer" perspective. That
is, the CG-NAT and consequently the RAN are part of IAP
(Internet Access Provider) facility. While Google, YouTube, etc.
are ICPs (Internet Content Providers). Relatively speaking, the
IAP is like the hardware part of a system, while ICP is the
software. They are two separate parts when combined will provide
the service that customers want. Normally, these two parts are
separate businesses, although some may be under the same owner
in some situations. The scenario that you are proposing is like
back to the old Bell System days when AT&T decided
everything. I am sure that Internet players will try very hard
to avoid being labelled as such.
Regards,
Abe (2024-01-15 00:02)
On 2024-01-13 03:30, Forrest Christian
(List Account) wrote:
A couple of points:
1) There is less work needed to support IPv6
than your proposed solution. I'm not taking about 230/4. I'm
talking about your EzIP overlay.
2) Assume that Google decided that they would no
longer support IPv4 for any of their services at a specific
date a couple of years in the future. That is, you either
needed an IPv6 address or you couldn't reach Google, youtube,
Gmail and the rest of the public services. I bet that in this
scenario every eyeball provider in the country all of a sudden
would be extremely motivated to deploy IPv6, even if the IPv4
providers end up natting their IPv4 customers to IPv6. I
really expect something like this to be the next part of the
end game for IPv4.
Or stated differently: at some point someone
with enough market power is going to basically say "enough is
enough" and make the decision for the rest of us that IPv4 is
effectively done on the public internet. The large tech
companies all have a history of sunsetting things when it
becomes a bigger problem to support than it's worth. Try
getting a modern browser that works on 32 bit windows. Same
with encryption protocols, Java in the browser, Shockwave and
flash, and on and on.
I see no reason why IPv4 should be any
different.
Hi, Forrest:
0) You put out more than one topic,
all at one time. Allow me to address each briefly.
1) " The existence of that CG-NAT
box is a thorn in every provider's side and every
provider that has one wants to make it go away as
quickly as possible. ":
The feeling and desire are
undeniable facts. However, the existing
configuration was evolved from various
considerations through a long time. There is a
tremendous inertia accumulated on it. There is no
magic bullet to get rid of it quickly. We must study carefully to evolve it
further incrementally. Otherwise, an even bigger
headache or disaster will happen.
2) " The
quickest and most straightforward way to eliminate
the need for any CG-NAT is to move to a bigger
address space. ":
The obvious answer was IPv6.
However, its performance after near two decades of
deployment has not been convincing. EzIP is an
alternative, requiring hardly any development, to
address this need immediately.
3) " Until
the cost (or pain) to stay on IPv4 is greater than
the cost to move, we're going to see continued
resistance to doing so. ":
This strategy is easily said than
done. It reminds me of my system planning work for
the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their
facility by just gradually raising the cost of
owning the old equipment by assuming fewer would be
be used, while the newer version would cost less
because growing number of deployments. Looking at
resultant financial forecast, the BOC decisions were
easy. Originally trained as a hardware radio
engineer, I was totally stunned. But, it worked well
under the regulated monopoly environment.
Fast forward by half a century,
the Internet promotes distributed approaches. Few
things can be controlled by limited couple parties.
The decision of go or no-go is made by parties in
the field who have their own respective
considerations. Accumulated, they set the direction
of the Internet. In this case, IPv6 has had the
opportunity of over four decades of planning and
nearly two decades of deployment. Its future growth
rate is set by its own performance merits. No one
can force its rate by persuasion
tactic of any kind. Hoping so is wishful thinking
which contributes to wasteful activities. So, we
need realistic planning.
Regards,
Abe (2024-01-12 18:42)
On 2024-01-12 01:34, Forrest
Christian (List Account) wrote:
The problem isn't the quantity of
"inside" CG-NAT address space. It's the existence
of CG-NAT at all.
It doesn't matter if the available
space is a /12 or a /4, you still need something
to translate it to the public internet. The
existence of that CG-NAT box is a thorn in every
provider's side and every provider that has one
wants to make it go away as quickly as possible.
The quickest and most
straightforward way to eliminate the need for any
CG-NAT is to move to a bigger address space. As I
pointed out, IPv6 is already ready and proven to
work so moving to IPv6 is a straightforward
process technically. What isn't straightforward
is convincing IPv4 users to move. Until the cost
(or pain) to stay on IPv4 is greater than the cost
to move, we're going to see continued resistance
to doing so.
Hi, Forrest:
0) Thanks for your
in-depth analysis.
1) However, my
apologies for not presenting the EzIP
concept clearer. That is, one way to look
at the EzIP scheme is to substitute the
current 100.64/10 netblock in the CG-NAT
with 240/4. Everything else in the current
CG-NAT setup stays unchanged. This makes
each CG-NAT cluster 64 fold bigger. And,
various capabilities become available.
Regards,
Abe (2024-01-11 22:35)
|
