<div dir="ltr"><div dir="ltr">According to the diagram on page 8 of the presentation on your website at <a href="https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf">https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf</a>, 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.</div><div dir="ltr"><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Christopher Hawker</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 19 Jan 2024 at 14:49, Abraham Y. Chen <<a href="mailto:aychen@avinta.com">aychen@avinta.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div><font size="4" face="monospace">Hi,
Christopher:</font></div>
<div><font size="4" face="monospace"><br>
</font></div>
<div><font size="4" face="monospace">1)
" If "EzIP" is about using 240/4 as CGNAT space, ... ": </font></div>
<p><font size="4" face="monospace"> 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. </font></p>
<font size="4" face="monospace"><br>
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.
... ":<br>
</font>
<p><font size="4" face="monospace"> 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.</font></p>
<p><font size="4" face="monospace"> 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.<br>
</font></p>
<font size="4" face="monospace"> 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. ":<br>
</font>
<p><font size="4" face="monospace"> 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.<br>
</font></p>
<font size="4" face="monospace"><br>
<br>
Regards,<br>
<br>
<br>
Abe (2024-01-18 22:48)</font><br>
<div><font size="4"><br>
</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">On 2024-01-15 18:33,
Christopher Hawker wrote:</font><br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">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.
<div><br>
</div>
<div>It is completely unnecessary to use 240/4 as CGNAT
space. Here are a few reasons why:</div>
<div>
<ol>
<li>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.</li>
<li>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).</li>
</ol>
<div>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 <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a> 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 "<a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a>
reserved for Shared Address Space". It has not been
delegated to ARIN. Rather clear as to its use case.</div>
<div><br>
</div>
<div>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?</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Christopher Hawker</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 16 Jan 2024 at 03:27,
Abraham Y. Chen <<a href="mailto:aychen@avinta.com" target="_blank">aychen@avinta.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><font size="4">Hi, Christopher:</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">1) " Hang on... So EzIP is now about
using 240/4 as CGNAT space? Wait, I'm lost... ": <br>
</font></div>
<p><font size="4"> 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.</font></p>
<div><font size="4">2) " ... There is no such thing as
"semi-private" space in the world of CGNAT, ... ":</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"> 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.)<br>
</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">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. ":</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"> 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.</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">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:</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"> <a href="https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch" target="_blank">https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch</a></font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">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. ":</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"> 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.</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">Regards,</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">Abe (2024-01-15 11:27) <br>
</font></div>
<div><font size="4"><br>
</font></div>
<br>
<div id="m_-3116000417587349579m_3753820813357424668DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid rgb(211,212,222)">
<tbody>
<tr>
<td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" style="width: 46px; height: 29px;" width="46" height="29"></a></td>
<td style="width:470px;padding-top:12px;color:rgb(65,66,78);font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free.<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" style="color:rgb(68,83,234)" target="_blank">www.avast.com</a></td>
</tr>
</tbody>
</table>
<a href="#m_-3116000417587349579_m_3753820813357424668_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div>
</div>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div>