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

Fri Jan 12 23:42:32 UTC 2024

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)
>

-- 
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/20240112/de7b867a/attachment-0001.html>