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

Tom Beecher beecher at beecher.cc
Tue Jan 16 19:36:52 UTC 2024


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

Yes he is essentially re-creating NAT/CGNAT, but in a worse way.

If you ignore all the multitude of technical issues, if you grabbed an
"EZIP packet" in flight from the DFZ, you would STILL see SRC and DST as
normal IPv4 addresses, just with extra stuff in the options field.
Translations still happen at what he calls 'SPRs' , just differently.


On Mon, Jan 15, 2024 at 6:35 PM Christopher Hawker <chris at thesysadmin.au>
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 at 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)
>>
>>
>>
>> On 2024-01-15 00:09, Christopher Hawker wrote:
>>
>> Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait, I'm
>> lost...
>>
>> With CGNAT, there is either public IP space in front of the gateway, or
>> private space behind it. There is no such thing as "semi-private" space in
>> the world of CGNAT, as devices with public IPs can't directly access
>> devices behind a CGNAT gateway with a 100.64/10 address. It's either a
>> public address, or a private address (not to be confused with an RFC1918
>> private address).
>>
>> Let's talk hypothetically for a minute and assume that 240/4 is used as
>> CGNAT space. 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.
>>
>> 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.
>>
>> Regards,
>> Christopher Hawker
>>
>> On Mon, 15 Jan 2024 at 15:06, Abraham Y. Chen <aychen at avinta.com> wrote:
>>
>>> Hi, Mike:
>>>
>>> 1)   "... only private use. ...":
>>>
>>>     The EzIP deployment plan is to use 240/4 netblock as "Semi-Public"
>>> addresses for the existing CG-NAT facility. With many RG-NATs (Routing /
>>> Residential Gateway -NATs) already capable of being 240/4 clients thru the
>>> upgrade to OpenWrt, no IoT on any private premises will sense any change.
>>>
>>> Regards,
>>>
>>>
>>> Abe (2024-01-14 23:04)
>>>
>>>
>>> On 2024-01-12 15:16, Mike Hammett wrote:
>>>
>>> I'm not talking about global, public use, only private use.
>>>
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions <http://www.ics-il.com/>
>>> <https://www.facebook.com/ICSIL>
>>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>>> <https://twitter.com/ICSIL>
>>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>>> <https://www.facebook.com/mdwestix>
>>> <https://www.linkedin.com/company/midwest-internet-exchange>
>>> <https://twitter.com/mdwestix>
>>> The Brothers WISP <http://www.thebrotherswisp.com/>
>>> <https://www.facebook.com/thebrotherswisp>
>>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>>> ------------------------------
>>>
>>>
>>
>>
>> <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_4516043769261218358_m_3753820813357424668_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240116/4755068f/attachment.html>


More information about the NANOG mailing list