>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, <[email protected]> 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 <[email protected]> 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, [email protected] 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 <[email protected]> > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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> >> > > >
