Hi, Sronan:
1) “Radio Access Network”:
Thanks for bringing this up. Being an RF engineer by training, I am
aware of this terminology. However, how specific is its claimed
applicable domain?
2) I went to search on an acronym site and found a long list of
expressions that abbreviate to RAN. It starts with Royal Australian Navy
and Rainforest Action Network as the third. Then, Return Authorization
Number is the fourth:
https://www.acronymfinder.com/RAN.html
3) In fact, "Regional Area Network" is about twentieth on it! So,
unless there is some kind of Registered Trademark conflict, this
probably is on my low priority to-do list for the time being.
4) Of course, if you have any alternative to suggest, my ears are
all yours.
Regards,
Abe (2024-01-15 18:48)
On 2024-01-15 17:14, sro...@ronan-online.com wrote:
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.
On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <ayc...@avinta.com> wrote:
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.
On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen
<ayc...@avinta.com> wrote:
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)
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
