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

Tue Jan 16 00:45:29 UTC 2024

>From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
address space as RFC6598 shared address space for service providers and
adding another gateway into a network to make it look like a new
technology, nothing more. It does absolutely nothing more than what is
already available and in use today. It's a solid NO from me, in case it's
not already clear.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 11:16, <sronan at ronan-online.com> wrote:

> 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 <aychen at 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:
>
>     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>
> <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_9148722380134320577_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240116/db1ff701/attachment.html>