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

Mon Jan 15 23:46:52 UTC 2024

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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240115/8dbaa1cd/attachment.html>