The reality is your whole concept for EzIP is so impractical and so unlikely to be implemented by any service provider with half a clue, that I’m not sure why I would even try to explain to you why a Radio Access Network is relevant to the Internet. You obviously have decided you are smarter than everyone else on NANOG.
Shane On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen <ayc...@avinta.com> wrote:
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:
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)
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
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)
|