nanog mailing list archives

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


From: "Abraham Y. Chen" <aychen () avinta com>
Date: Sat, 20 Jan 2024 11:56:02 -0500

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

Current thread: