Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[James R Cutler <james.cutler () consultant com>]

On Jan 20, 2024, at 11:56 AM, Abraham Y. Chen <aychen () avinta com> wrote:
> Hi, Christopher:
>
> 1)     "    ... It would simply increase the workload of their support and provisioning teams. Right now, in cases 
> where ISPs use DHCP, they can simply ship a router to an end-user, the user plugs it in, turns it on, and away they 
> go. ":  
>
>     I do understand the current practice that you are describing. However, there is nothing wrong by instructing a 
> subscriber to attempt accessing the ISP's sign-up website with his browser when first turning on the router, so that 
> a process of checking the credentials of the subscriber can go through, then a static WAN (240/4) address is assigned 
> to the router. From there on, everything should operate normally  as far as the subscriber is concrned. This process 
> is not special. For example, when a traveler checks into a hotel these days, he would go through pretty much the same 
> steps with minimal identification (Certain hotel network even knew which room I was in by popping my name on the 
> screen, perhaps because the WiFi access point was fed by wired Ethernet! Only password provided by the front desk was 
> needed.) Then, everything works just like at home.
>
> 2)    "   ...  If an end-user has a router that does not support OpenWrt, it will require the end-user to replace 
> their router with one that does in order to connect to an EzIP-enabled network. ":
>
>     Correct. But, RAN is an overlay network that provides a parallel route to the same services as the current 
> CG-NAT. So, an end-user has the option to use it. Nothing hurts, if he decides to ignore the RAN.
>
> 3)    "  A carrier would not have a need for more than ~4.1m devices on a single regional access network ...   ":
>     This is a system level planning consideration. That is, even if some carriers do not need EzIP, it does not mean 
> that the capability should not be presented to the general audience. Let's hold this off for the moment.
>
> Regards,
>
>
>
> Abe (2024-01-20 11:55)
>
>
>
>
>
> On 2024-01-18 23:19, Christopher Hawker wrote:
> > According to the diagram on page 8 of the presentation on your website at 
> > https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf, it simply identifies 240/4 as CGNAT space. Routing 
> > between regional access networks typically doesn't take place when using such space on an ISP network, and most ISPs 
> > (that I know of) will offer public addressing when it is required. Further, if you think the need for DHCP will be 
> > eliminated through the use of your solution, I hate to say it, but ISPs will not statically configure WAN addressing 
> > on CPE for residential services. It would simply increase the workload of their support and provisioning teams. 
> > Right now, in cases where ISPs use DHCP, they can simply ship a router to an end-user, the user plugs it in, turns 
> > it on, and away they go. Connectivity to the internet.
> >
> > If an end-user has a router that does not support OpenWRT, it will require the end-user to replace their router with 
> > one that does in order to connect to an EzIP-enabled network. This is not reasonably practical. This would also 
> > require router vendors to support connectivity to a proprietary "semi-public router".
> >
> > Again, for the sake of completeness, this solution is a waste of time and resources. A carrier would not have a need 
> > for more than ~4.1m devices on a single regional access network and some may run more than one in a single region, 
> > so as not to put all of their proverbial eggs into the same basket.
> >
> > Regards,
> > Christopher Hawker
> >
> > On Fri, 19 Jan 2024 at 14:49, Abraham Y. Chen <aychen () avinta com <mailto:aychen () avinta com>> wrote:
> > > Hi, Christopher:
> > >
> > > 1)    " If "EzIP" is about using 240/4 as CGNAT space, ...   ": 
> > >     This correlation is just the starting point for EzIP deployment, so that it would not be regarded as a 
> > > base-less crazy dream. Once a 240/4 enabled RAN is established as a new network overlaying on the CG-NAT 
> > > infrastructure, the benefits of making use of the 240/4 resources can begin to be considered. For example, with 
> > > sufficient addresses, static address administration can be practiced within a RAN which will remove the need for 
> > > DHCP service. From this, related consequences may be discussed.
> > >
> > >
> > > 2)    " I don't think you quite grasp the concept that OpenWRT is not compatible with devices that do not support 
> > > it. .... it would not be appropriate to expect every device vendor to support it.  ...   ":
> > >     Perhaps we have some offset about the terminology of "who supports whom?" My understanding of the OpenWrt 
> > > project is that it is an open-source program code that supports a long list (but not all) of primarily commercial 
> > > RGs (Residential/Routing Gateways) and WiFi routers that serve / support CPE devices (on-premises IoTs). Its basic 
> > > purpose is to let private network owners to replace the firmware code in the RGs with the OpenWrt equivalent so 
> > > that they will have full control of their RGs and then modify them if desired. Thus, the basic release of each 
> > > OpenWrt code maintains most of the original functionalities in the OEM device. So, neither the original RG nor any 
> > > IoT manufacturers need be involved with the OpenWrt, let alone supporting it. My reference to its V19.07.3 was the 
> > > version that expanded its usable address pool to include 240/4. That was all.
> > >
> > >     For sure, OpenWrt does not run on all RGs in the field. But, this does not restrict an overlay network like RAN 
> > > from starting to network only those premises with RGs that run on OpenWrt (plus those RGs compatible with 240/4 
> > > from the factories). Since the existing CG-NAT is not disturbed and daily Internet services are going normally, RAN 
> > > growth can take its time.
> > >
> > > 3)    " You've provided a link to a D-Link managed switch, not a router. Just because it can support L2 routing, 
> > > doesn't make it a router.   ":
> > >     Correct, this is just a basic example for networking the RGs to experiment the RAN configuration. It is not 
> > > intended to be a full-fledged router which will have other considerations that are way beyond what EzIP should be 
> > > involved with.
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > > Abe (2024-01-18 22:48)


Wow, changes happen when one is busy. When was the acronym "RAN" applied to a "Stealthy Overlay Network"? In my 
experience RAN is most often a Radio Access Network (military and cellular nets). Return Authorization Number is 
accepted usage in commerce.  I now have several questions:

Shouldn't the acronym be SON, except that is also used many places?
Why are we discussing a "Stealthy Overlay Network" anyway? If truly is stealthy, it is probably not guided by RFC.
What does OpenWRT have to do with this? 
I saw the beginning of this discussion long long ago. I still do not understand the merits of messing with IPv4 address 
allocations, especially comparing cost of a limited lifetime "Stealthy Overlay Network" as comparted to actually 
deploying and using IPv6. Where will be the long term savings? IPv6 has an expected lifetime far in excess of any hacks 
to extend IPv4 lifetime.
Show me the money.
-
James R Cutler
James.cutler () consultant com