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

[Christopher Morrow <morrowc.lists () gmail com>]

Why is this conversation even still going on?
It's been established ~100 messages ago that the plan here is nonsense.
it's been established ~80 messages ago that the 'lemme swap subjects to
confuse the issue' is nonsense.

stop feeding the troll.

On Thu, Jan 18, 2024 at 11:20 PM Christopher Hawker <chris () thesysadmin au>
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)
> >
> >
> > On 2024-01-15 18:33, Christopher Hawker wrote:
> >
> > If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> > not rename something that already exists and attempt to claim it as a new
> > idea.
> >
> > It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
> > reasons why:
> >
> >    1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
> >    /24 from this to be used for CGNAT gateways, load balancing, etc. this
> >    still allows for 4,194,048 usable addresses for CPE. When performing NAT,
> >    you would need to allocate each subscriber approximately 1000 ports for NAT
> >    to work successfully. The entire /10 (less the /24) would require the
> >    equivalent of a /16 public IPv4 prefix to use the entire 100.64/10 space in
> >    one region. To put this into comparison, you would use the entire 100.64/10
> >    space in a city the size of New York or Los Angeles allowing for one
> >    internet service per 4 or 2 people respectively. It's not practical.
> >    2. Multiple CGNAT regions that are at capacity would not have a need
> >    for uniquely routable IP space between them. It's heavily designed for
> >    traffic from the user to the wider internet, not for inter-region routing.
> >    Carriers already have systems in place where subscribers can request a
> >    public address if they need it (such as working from home with advanced
> >    corporate networks, etc).
> >
> > 100.64/10 is not public IP space, because it is not usable in the DFZ. I
> > don't believe there is any confusion or ambiguity about this space because
> > if you do a Whois lookup on 100.64.0.0/10 at any one of the five RIRs,
> > it reflects that it is IANA shared address space for service providers.
> > Footnote 6 on the page you referenced reads "100.64.0.0/10 reserved for
> > Shared Address Space". It has not been delegated to ARIN. Rather clear as
> > to its use case.
> >
> > I don't think you quite grasp the concept that OpenWRT is not compatible
> > with devices that do not support it. It would only work on routers for
> > which it is compatible and it would not be appropriate to expect every
> > device vendor to support it. To add-on to this, why would vendors need to
> > enable 240/4 CGNAT support when their customers don't have a need for it?
> >
> > 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.
> >
> > I'm all for discussing ideas and suggestions and working towards proper
> > IPv6 deployment. It certainly appears to be the case that the community
> > does not support your proposed "EzIP" solution. If you are recommending
> > that 240/4 space be used for CGNAT space under RFC6598, then call it as it
> > is instead of inventing new terminology.
> >
> > Regards,
> > Christopher Hawker
> >
> > On Tue, 16 Jan 2024 at 03:27, Abraham Y. Chen <aychen () avinta com> wrote:
> >
> > > Hi, Christopher:
> > >
> > > 1)    " Hang on... So EzIP is now about using 240/4 as CGNAT space?
> > > Wait, I'm lost...   ":
> > >
> > >     Correct. This is one way to visualize the EzIP deployment. This
> > > configuration is so far the most concise manner to describe the the EzIP
> > > building block, RAN (Regional Area Network). The nice thing about this
> > > approach is that everything exists and is already working daily in each
> > > CG-NAT cluster. All needed to expand its capability is a larger netblock.
> > > Since 240/4 is fundamentally not an outlier in the overall IPv4 address
> > > pool, except being classified as "Reserved" for a long time, enabling it to
> > > work in a CG-NAT should not be any big challenge.
> > > 2)    "   ... There is no such thing as "semi-private" space in the
> > > world of CGNAT, ... ":
> > >
> > >     Correct. However, not distinguishing 100.64/10 netblock from the
> > > common public and private parts of the IPv4 space made it vague as which
> > > function does it provide. That is, in terms of re-usability for each
> > > isolated geographical area, it is like another RFC1918 private netblock. On
> > > the other hand, CG-NAT is clearly used in geographically public areas. So,
> > > 100.64/10 should be classified as "public". In addition, 100.64/10 is
> > > listed according to "IANA IPv4 Address Space Registry" as part of the 100/8
> > > netblock under ARIN, but now used by everyone worldwide. To avoid similar
> > > ambiguity that leads to confusions, we decided to call 240/4 as
> > > "semi-public" to more explicitly convey the concept. (Actually, we
> > > initially called 240/4 "semi-private" thinking that it could be the fourth
> > > RFC1918 netblock, until we realized that the RFC6589 environment was a much
> > > better fit.)
> > >
> > > 3)    " Your "solution" to residential gateways not supporting the use
> > > of 240/4 space being upgraded to OpenWrt won't work, because not all CPE
> > > supports OpenWrt.   ":
> > >
> > >     OpenWrt is just an open source RG code that can replace that in
> > > commercial RGs that have been supporting CPEs. Like the EzIP concept, the
> > > OpenWrt upgrade of RG-NAT is an enhancement to the existing RG
> > > functionality. Thus, OpenWrt enabled RGs can operate with the combination
> > > of public (including RFC6589) with 240/4 netblocks on the upstream (WAN)
> > > side, and private (RFC1918) with 240/4 netblocks on the downstream (LAN)
> > > side. So, there is no compatibility change that a CPE (on-premises IoT) can
> > > sense. This critical characteristics was the result of an OpenWrt core code
> > > upgrade in 2019 contributed by Dave Taht of "IPv4 Unicast Extensions
> > > Project". Before that, EzIP was just a theoretically feasible scheme.
> > >
> > > 4)    In addition,  OpenWrt at least works with one network router by
> > > D-Link (see URL below). This means that, with both WAN and LAN sides of a
> > > router supporting 240/4, a beginner's reference RAN can be built and
> > > experimented with it:
> > >
> > >
> > > https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch
> > >
> > > 5)    " Instead of attempting to use a larger prefix for CGNAT, IPv6 is
> > > definitely the easier solution to implement as the vast majority of vendors
> > > already support v6. ":
> > >
> > >     Since the general consensus is that for moving ahead, we will rely
> > > on Dual-Stack to bridge IPv6 and IPv4 worlds enabling them to coexist for
> > > the foreseeable future, it would more expedient for the community as a
> > > whole, if we could focus on technical discussions for each camp
> > > respectively, while minimizing invitation messages from the other side. I
> > > hope you do agree.
> > >
> > > Regards,
> > >
> > >
> > > Abe (2024-01-15 11:27)
> > >
> > >
> > >
> > >
> > > <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_6838144186223039214_m_-3116000417587349579_m_3753820813357424668_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>