Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

["Abraham Y. Chen" <aychen () avinta com>]

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, sronan () 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 <aychen () 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 <aychen () 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
> > > >     <aychen () 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