Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

["Forrest Christian (List Account)" <lists () packetflux com>]

On Mon, Jan 15, 2024, 3:08 PM Abraham Y. Chen <aychen () avinta com> wrote:

> 1)    Re: Ur. Pt. 1):    The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
> don't see how an upgrade of such equipment to IPv6 could be simpler and
> less work. Please elaborate.

I started to type a big long reply, but I realized that I'm not really sure
how to convince you any further.

Let me try this statement:  Networks made of relatively modern equipment
are likely able to just have IPv6 turned on.   Your solution requires
software engineering and then a whole bunch of software deployed.   And
only then have the 240/4 turned on.

Whether the middle of the network is IPv4 or IPv6 (the portion that 240/4
would replace) is largely irrelevant to the public IPv4 network and to IPv4
devices in residential settings.   With the right configuration, a
residential user can have IPv4 devices talking across a 100% IPv6 network
to the rest of the IPv4 internet.  This software exists and works today.
 And, as a big advantage, once this is done, IPv6-enabled devices can talk
native IPv6 to the IPv6 internet, bypassing all of the CG-NAT mess.

As has been pointed out, IPv6 is not without its challenges.  But so would
be trying to deploy 240/4.

In addition, to support the 'overlay' portion of your solution a lot of
additional work will need to be done.   Explain how I, as a residential
user on RAN #1, can know about and connect to a service on RAN #2.   None
of that work has been done, and in order for your solution to be useful,
you need to do that work.   By contrast, all of that work is already done
with IPv6, and is working today.