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
<http://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 <http://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_3753820813357424668_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
