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

Tue Jan 16 03:00:01 UTC 2024

If I remember correctly, quite a few years ago, "EzIP" was something else
entirely.

I vaguely remember them talking about having some kind of extended IPv4
address or to use an extension header or something like that. It was
something that would essentially require the entire Internet to be reworked
in order to work. Kind of like this, but even more so because these
modified bastardized packets would be sent across the DFZ.

And it seems now it's morphed into simply opening up and reusing 240/4

Brandon Jackson
bjackson at napshome.net

On Mon, Jan 15, 2024, 19:47 Christopher Hawker <chris at thesysadmin.au> wrote:

> 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_2399351866883432329_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/20240115/5a7f9e48/attachment.html>