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 <ch...@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 <ayc...@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 <ayc...@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> >>> >> >>
