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

Sat Jan 20 16:56:02 UTC 2024

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

-- 
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/20240120/525246a0/attachment.html>