It was always about using 240/4 as shared service provider space, just a roundabout way of doing it.
You can call a horse a horse, or you can call it "an animal that pulls a wagon which carries people and items from A to B". At the end of the day, it's still a horse. Regards, Christopher Hawker On Tue, 16 Jan 2024 at 14:00, Brandon Jackson <bjack...@napshome.net> wrote: > 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 > bjack...@napshome.net > > > On Mon, Jan 15, 2024, 19:47 Christopher Hawker <ch...@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, <sro...@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 <ayc...@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, sro...@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 <ayc...@avinta.com> >>> <ayc...@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 <ayc...@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 <ayc...@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_1923872705776870626_m_2399351866883432329_m_9148722380134320577_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>> >>> >>> >>>
